From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754115AbdLHPGb (ORCPT <rfc822;w@1wt.eu>);
        Fri, 8 Dec 2017 10:06:31 -0500
Received: from userp2120.oracle.com ([156.151.31.85]:54674 "EHLO
        userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753940AbdLHPG2 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 8 Dec 2017 10:06:28 -0500
Date: Fri, 8 Dec 2017 10:06:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Quan Xu <quan.xu0@gmail.com>
Cc: pbonzini@redhat.com, rkrcmar@redhat.com, yang.zhang.wz@gmail.com,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        Ben Luo <bn0418@gmail.com>
Subject: Re: [PATCH RFC 3/7] KVM: timer: synchronize tsc-deadline timestamp
 for guest
Message-ID: <20171208150618.GD12069@x230.dumpdata.com>
References: <1512722390-3654-1-git-send-email-quan.xu0@gmail.com>
 <1512722390-3654-4-git-send-email-quan.xu0@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1512722390-3654-4-git-send-email-quan.xu0@gmail.com>
User-Agent: Mutt/1.9.0 (2017-09-02)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8738 signatures=668644
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0
 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=596
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.0.1-1711220000 definitions=main-1712080208
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Dec 08, 2017 at 04:39:46PM +0800, Quan Xu wrote:
> From: Ben Luo <bn0418@gmail.com>
> 
> In general, KVM guest programs tsc-deadline timestamp to
> MSR_IA32_TSC_DEADLINE MSR. This will cause a VM-exit, and
> then KVM handles this timer for guest.
> 
> The tsc-deadline timestamp is mostly recorded in share page
> with less VM-exit. We Introduce a periodically working kthread
> to scan share page and synchronize timer setting for guest
> on a dedicated CPU.

That sounds like a race. Meaning the guest may put too small window
and this 'working thread to scan' may not get to it fast enough?

Meaning we miss the deadline to inject the timer in the guest.

Or is this part of this PV MSR semantics - that it will only work
for certain amount of values and anything less than say 1ms
should not use the PV MSR?