From: David Woodhouse <dwmw2@infradead.org>
To: Vitaly Kuznetsov <vkuznets@redhat.com>,
kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>
Cc: Jan Richter <jarichte@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: selftests: Compare wall time from xen shinfo against KVM_GET_CLOCK
Date: Wed, 31 Jan 2024 08:34:18 -0800 [thread overview]
Message-ID: <596b2d7ce6941e5dd6bd7b2da6d3ea7d74f6c95a.camel@infradead.org> (raw)
In-Reply-To: <20240111135901.1785096-1-vkuznets@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]
Sorry for delayed response.
On Thu, 2024-01-11 at 14:59 +0100, Vitaly Kuznetsov wrote:
>
> + vm_ioctl(vm, KVM_GET_CLOCK, &kcdata);
> + delta = (wc->sec * NSEC_PER_SEC + wc->nsec) - (kcdata.realtime - kcdata.clock);
I think you need to check for KVM_CLOCK_REALTIME in the flags here,
don't you? It might not always be set.
And also, nobody should ever be using KVM_CLOCK_REALTIME as it stands
at the moment. It's fundamentally broken because it should always have
used CLOCK_TAI not CLOCK_REALTIME.
I'm in the process of fixing that up as an incremental ABI change,
putting the TAI offset into one of the spare pad fields in the
kvm_clock_data and adding a new KVM_CLOCK_TAI_OFFSET flag.
> + TEST_ASSERT(llabs(delta) < 100,
> + "Guest's epoch from shinfo %d.%09d differs from KVM_GET_CLOCK %lld.%lld",
> + wc->sec, wc->nsec, (kcdata.realtime - kcdata.clock) / NSEC_PER_SEC,
> + (kcdata.realtime - kcdata.clock) % NSEC_PER_SEC);
>
> Replace the check with comparing wall clock data from shinfo to
> KVM_GET_CLOCK. The later gives both realtime and kvmclock so guest's epoch
> can be calculated by subtraction. Note, the computed epoch may still differ
> a few nanoseconds from shinfo as different TSC is used and there are
> rounding errors but 100 nanoseconds margin should be enough to cover
> it (famous last words).
Aren't those just bugs? Surely this *should* be cycle-perfect, if the
host has a stable TSC?
But I suppose this isn't the test case for that. This is just testing
that the Xen shinfo is doing basically the right thing.
And we're going to need a few more fixes like this WIP before we get
get to cycle perfection from the horrid mess that is our kvmclock code:
https://git.infradead.org/?p=users/dwmw2/linux.git;a=commitdiff;h=bc557e5ee4
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]
next prev parent reply other threads:[~2024-01-31 16:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 13:59 Vitaly Kuznetsov
2024-01-29 9:04 ` Vitaly Kuznetsov
2024-01-29 16:06 ` Sean Christopherson
2024-01-31 0:59 ` Sean Christopherson
2024-02-01 17:01 ` Sean Christopherson
2024-02-02 23:27 ` Vitaly Kuznetsov
2024-01-31 16:34 ` David Woodhouse [this message]
2024-02-01 10:19 ` Vitaly Kuznetsov
2024-02-01 16:02 ` David Woodhouse
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=596b2d7ce6941e5dd6bd7b2da6d3ea7d74f6c95a.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=jarichte@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=vkuznets@redhat.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®