From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>,
Like Xu <like.xu.linux@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Oliver Upton <oliver.upton@linux.dev>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] KVM: x86/tsc: Don't sync user changes to TSC with KVM-initiated change
Date: Wed, 13 Sep 2023 10:10:48 +0200 [thread overview]
Message-ID: <d39a25a85750e99e11f6b8a58dcd0560f5463f97.camel@infradead.org> (raw)
In-Reply-To: <ZNa9QyRmuAjNAonC@google.com>
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
On Fri, 2023-08-11 at 15:59 -0700, Sean Christopherson wrote:
> The problem isn't that the sync code doesn't differentiate between kernel and
> user-initiated writes, because parts of the code *do* differentiate. I think it's
> more accurate to say that the problem is that the sync code doesn't differentiate
> between userspace initializing the TSC and userspace attempting to synchronize the
> TSC.
I'm not utterly sure that *I* differentiate between userspace
"initializing the TSC" and attempting to "synchronize the TSC". What
*is* the difference?
Userspace is merely *setting* the TSC for a given vCPU, regardless of
whether other vCPUs even exist.
But we have to work around the fundamental brokenness of the legacy
API, whose semantics are most accurately described as "Please set the
TSC to precisely <x> because that's what it should have been *some*
time around now, if I wasn't preempted very much between when I
calculated it and when you see this ioctl".
That's why — for the legacy API only — we have this hack to make the
TSCs *actually* in sync if they're close. Because without it, there;s
*no* way the VMM can restore a guest with its TSCs actually in sync.
I think the best answer to the bug report that led to this patch is
just "Don't use the legacy API then". Use KVM_VCPU_TSC_OFFSET which is
defined as "the TSC was <x> at KVM time <y>" and is actually *sane*.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]
next prev parent reply other threads:[~2023-09-13 8:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-01 3:45 Like Xu
2023-08-11 22:59 ` Sean Christopherson
2023-09-13 8:10 ` David Woodhouse [this message]
2023-09-13 8:41 ` Like Xu
2023-09-13 8:44 ` David Woodhouse
2023-09-13 8:31 ` David Woodhouse
2023-09-13 14:50 ` Sean Christopherson
2023-09-13 15:05 ` David Woodhouse
2023-09-13 15:15 ` Sean Christopherson
2023-09-13 15:24 ` David Woodhouse
2023-09-14 3:24 ` Like Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d39a25a85750e99e11f6b8a58dcd0560f5463f97.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=kvm@vger.kernel.org \
--cc=like.xu.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®