On Fri, 2023-10-20 at 07:39 -0700, Dongli Zhang wrote:
>
> 1. Capture boottime_wallclock_01.
> 2. Wait for 10-second by default (configurable, e.g., max 60-second)
> 3. Capture boottime_wallclock_02.
> 4. Report error if drift.
>
>
> I have another pvclock vCPU hotplug test with the same flow.
From: David Woodhouse
Using -MD without -MP causes build failures when a header file is deleted
or moved. With -MP, the compiler will emit phony targets for the header
files it lists as dependencies, and the Makefiles won't refuse to attempt
to rebuild a C unit which no longer include
On Sun, 2023-10-29 at 21:13 +, David Laight wrote:
> From: David Woodhouse
> > Sent: 28 October 2023 20:35
> >
> > Using -MD without -MP causes build failures when a header file is deleted
> > or moved. With -MP, the compiler will emit phony targets for the h
On Mon, 2023-10-30 at 10:08 +, David Laight wrote:
> From: David Woodhouse
> > Sent: 30 October 2023 09:46
> >
> > On Sun, 2023-10-29 at 21:13 +, David Laight wrote:
> > > From: David Woodhouse
> > > > Sent: 28 October 2023 20:35
> >
age dirty.
> + */
> + wall_nsec = ktime_get_real_ns() - get_kvmclock_ns(kvm);
(Hint: it's commit 5d6d6a7d7e66a)
With that fixed,
Reviewed-by: David Woodhouse
smime.p7s
Description: S/MIME cryptographic signature
ode is either done explicitly by the VMM via the
> KVM_XEN_ATTR_TYPE_LONG_MODE attribute, or implicitly when the guest writes
> the MSR to set up the hypercall page.
>
> Signed-off-by: Paul Durrant
Reviewed-by: David Woodhouse
smime.p7s
Description: S/MIME cryptographic signature
On Mon, 2023-12-04 at 14:43 +, Paul Durrant wrote:
> From: Paul Durrant
>
> The implementation of kvm_xen_set_evtchn_fast() is a rather lengthy piece
> of code that performs two operations: updating of the shared_info
> evtchn_pending mask, and updating of the vcpu_info evtchn_pending_sel
> m
o lock the same as an
> invalid cache.
>
> [1]
> https://lore.kernel.org/lkml/99771ef3a4966a01fefd3adbb2ba9c3a75f97cf2.ca...@infradead.org/T/#mbd06e5a04534ce9c0ee94bd8f1e8d942b2d45bd6
>
> Signed-off-by: Paul Durrant
Reviewed-by: David Woodhouse
Although I would prefer the co
r a match; only taking a
> write lock to actually perform an invalidation (after a another check).
>
> Signed-off-by: Paul Durrant
Reviewed-by: David Woodhouse
In particular, the previous 'don't block on pfncache locks in
kvm_xen_set_evtchn_fast()' patch in this series is ea
On Thu, 2023-12-14 at 14:00 +, David Woodhouse wrote:
>
> > + if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode) {
> > + struct vcpu_info *vcpu_info = gpc->khva;
> > + u32 port_word_bit = port / 32;
>
> Shouldn
On 19 December 2023 16:11:06 GMT, Paul Durrant wrote:
>From: Paul Durrant
>
>The implementation of kvm_xen_set_evtchn_fast() is a rather lengthy piece
>of code that performs two operations: updating of the shared_info
>evtchn_pending mask, and updating of the vcpu_info evtchn_pending_sel
>mask. I
> >
> > The v11 patch failed to set the return code of the ioctl if the mode
> > was not actually changed, leading to a spurious failure.
> >
> > This version of the series also contains a new bug-fix to the pfncache
> > code from David Woodhouse.
> &
On Tue, 2024-02-06 at 19:17 -0800, Sean Christopherson wrote:
> KVM: x86/xen: for the scope please. A few commits have "KVM: xen:", but
> "x86/xen"
> is the overwhelming favorite.
Paul's been using "KVM: xen:" in this patch series since first posting
it in September of last year. If there aren't
On Tue, 2024-02-06 at 20:03 -0800, Sean Christopherson wrote:
> +s390 folks (question on kvm_is_error_gpa() for ya)
>
> On Mon, Jan 15, 2024, Paul Durrant wrote:
> > @@ -1398,7 +1414,9 @@ void kvm_gpc_deactivate(struct gfn_to_pfn_cache *gpc);
> > static inline void kvm_gpc_mark_dirty(struct gfn_
On Tue, 2024-02-06 at 20:17 -0800, Sean Christopherson wrote:
> On Mon, Jan 15, 2024, Paul Durrant wrote:
> > From: Paul Durrant
> >
> > As described in [1] compiling with CONFIG_PROVE_RAW_LOCK_NESTING shows that
> > kvm_xen_set_evtchn_fast() is blocking on pfncache locks in IRQ context.
> > Ther
On Tue, 2024-02-06 at 20:22 -0800, Sean Christopherson wrote:
> On Mon, Jan 15, 2024, Paul Durrant wrote:
> > From: Paul Durrant
> >
> > Taking a write lock on a pfncache will be disruptive if the cache is
>
> *Unnecessarily* taking a write lock.
No. Taking a write lock will be disrupting.
Unn
On Tue, 2024-02-06 at 20:47 -0800, Sean Christopherson wrote:
>
> I'm saying this:
>
> When processing mmu_notifier invalidations for gpc caches, pre-check for
> overlap with the invalidation event while holding gpc->lock for read, and
> only take gpc->lock for write if the cache needs to b
On Thu, 2024-02-08 at 16:51 +, Paul Durrant wrote:
> On 08/02/2024 16:48, Sean Christopherson wrote:
> > On Thu, Feb 08, 2024, Paul Durrant wrote:
> > > With the benefit of some sleep, I'm wondering why 0 is a 'ridiculous'
> > > invalid value for a *virtual* address? Surely it's essentially a n
On Thu, 2024-02-15 at 15:29 +, Paul Durrant wrote:
> From: David Woodhouse
>
> This function can race with kvm_gpc_deactivate(), which does not take
> the ->refresh_lock. This means kvm_gpc_deactivate() can wipe the ->pfn
> and ->khva fields, and unmap the latter
On Fri, 2024-02-16 at 07:52 -0800, Sean Christopherson wrote:
>
> FWIW, I'm not opposed to overhauling the gpc locking, I agree it's a mess. I
> just
> want to proceed slower than I would for a fix, it's a lot to digest.
Agreed. I'll do a *really* simple expansion of ->refresh_lock for the fix,
On 20 February 2024 17:15:06 CET, Sean Christopherson wrote:
>On Tue, Feb 20, 2024, Paul Durrant wrote:
>> On 20/02/2024 15:55, Sean Christopherson wrote:
>> > On Thu, 15 Feb 2024 15:28:55 +, Paul Durrant wrote:
>> > > From: Paul Durrant
>> > >
>> > > This series contains a new patch from Se
On Sat, 2024-01-06 at 00:33 -0800, Dongli Zhang wrote:
> There is kvmclock drift issue during the vCPU hotplug. It has been fixed by
> the commit c52ffadc65e2 ("KVM: x86: Don't unnecessarily force masterclock
> update on vCPU hotplug").
>
> This is to add the test to verify if the master clock is
On Mon, 2024-04-08 at 17:43 -0700, Dongli Zhang wrote:
> Hi Jack,
>
> On 4/8/24 15:07, Jack Allister wrote:
> > This test proves that there is an inherent KVM/PV clock drift away from the
> > guest TSC when KVM decides to update the PV time information structure due
> > to a KVM_REQ_MASTERCLOCK_UP
On Fri, 2024-06-21 at 22:14 +0200, Roman Kagan wrote:
>
> Compared to the approach used in the orignal series, where a dedicated kernel
> address range and thus a dedicated PGD was used for mm-local allocations, the
> one proposed here may have certain drawbacks, in particular
>
> - using user ad
On Wed, 2024-04-10 at 10:15 +, Allister, Jack wrote:
> > AFAIR, I copied check_clocksource() from existing code during that >
> time.
>
> > The commit e440c5f2e ("KVM: selftests: Generalize check_clocksource()
> > from kvm_clock_test") has introduced sys_clocksource_is_tsc(). Later
> > it is r
From: David Woodhouse
Commit 53fafdbb8b21 ("KVM: x86: switch KVMCLOCK base to monotonic raw
clock") did so only for 64-bit hosts, by capturing the boot offset from
within the existing clocksource notifier update_pvclock_gtod().
That notifier was added in commit 16e8d74d2da9 ("KVM
37 corrected=5038374945
* delta_uncorrected=3509 delta_corrected=1
Signed-off-by: Jack Allister
Signed-off-by: David Woodhouse
CC: Paul Durrant
CC: Dongli Zhang
---
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/x86_64/pvclock_test.c | 192 ++
2 files changed, 19
From: David Woodhouse
The kvm_guest_time_update() function scales the host TSC frequency to
the guest's using kvm_scale_tsc() and the v->arch.l1_tsc_scaling_ratio
scaling ratio previously calculated for that vCPU. Then calcuates the
scaling factors for the KVM clock itself based on th
From: David Woodhouse
The documentation on TSC migration using KVM_VCPU_TSC_OFFSET is woefully
inadequate. It ignores TSC scaling, and ignores the fact that the host
TSC may differ from one host to the next (and in fact because of the way
the kernel calibrates it, it generally differs from one
from
VMMs, but I think it's ready for some heckling at least.
https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/clocks
David Woodhouse (8):
KVM: x86/xen: Do not corrupt KVM clock in kvm_xen_shared_info_init()
KVM: x86: Improve accuracy of KVM clock when TSC s
From: David Woodhouse
The KVM clock is an interesting thing. It is defined as "nanoseconds
since the guest was created", but in practice it runs at two *different*
rates — or three different rates, if you count implementation bugs.
Definition A is that it runs synchronousl
From: David Woodhouse
KVM does make an attempt to cope with non-constant TSC, and has notifiers
to handle host TSC frequency changes. However, it *only* adjusts the KVM
clock, and doesn't adjust TSC frequency scaling when the host changes.
This is presumably because non-constant TSCs were
From: David Woodhouse
This effectively reverts commit 332967a3eac0 ("x86: kvm: introduce
periodic global clock updates"). The periodic update was introduced to
propagate NTP corrections to the guest KVM clock, when the KVM clock was
based on CLOCK_MONOTONIC.
However, commit 53fafdbb
From: David Woodhouse
This was introduced in commit 0061d53daf26 ("KVM: x86: limit difference
between kvmclock updates") to reduce cross-vCPU differences which arose
because the KVM clock was based on CLOCK_MONOTONIC and thus subject to
NTP frequency corrections.
However, commit 53
From: David Woodhouse
When in 'master clock mode' (i.e. when host and guest TSCs are behaving
sanely and in sync), the KVM clock is defined in terms of the guest TSC.
When TSC scaling is used, calculating the KVM clock directly from *host*
TSC cycles leads to a systemic drift from
way. The
explicit fallback allows userspace to deliberately fail migration to a host
with misbehaving TSC where master clock mode wouldn't be active.)
Co-developed-by: David Woodhouse
Signed-off-by: Jack Allister
Signed-off-by: David Woodhouse
CC: Paul Durrant
CC: Dongli Zhang
---
From: David Woodhouse
There was some confusion in kvm_update_guest_time() when software needs
to advance the guest TSC.
In master clock mode, there are two points of time which need to be taken
into account. First there is the master clock reference point, stored in
kvm->arch.master_kernel
On Thu, 2024-04-18 at 20:34 +0100, David Woodhouse wrote:
>
> KVM: x86: Remove periodic global clock updates
> KVM: x86: Kill KVM_REQ_GLOBAL_CLOCK_UPDATE
Meh, I might have to put those back. They were originally introduced to
cope with NTP frequency skew which is no longer
On Fri, 2024-04-19 at 16:40 +0100, Paul Durrant wrote:
>
> > + * If KVM_REQ_CLOCK_UPDATE is already pending, or if the
> > hv_clock has
> > + * never been generated at all, call
> > kvm_guest_time_update() to do so.
> > + * Might as well use the PVCLOCK_TSC_STABLE_BIT as the
>
On Fri, 2024-04-19 at 16:49 +0100, Paul Durrant wrote:
> On 18/04/2024 20:34, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > The documentation on TSC migration using KVM_VCPU_TSC_OFFSET is woefully
> > inadequate. It ignores TSC scaling, and ignores the fac
On 19 April 2024 19:40:06 BST, David Woodhouse wrote:
>On 19 April 2024 18:13:16 BST, "Chen, Zide" wrote:
>>I'm wondering what's the underling theory that we definitely can achieve
>>±1ns accuracy? I tested it on a Sapphire Rapids @2100MHz TSC frequency,
>
On 19 April 2024 18:13:16 BST, "Chen, Zide" wrote:
>I'm wondering what's the underling theory that we definitely can achieve
>±1ns accuracy? I tested it on a Sapphire Rapids @2100MHz TSC frequency,
>and I can see delta_corrected=2 in ~2% cases.
Hm. Thanks for testing!
So the KVM clock is based o
On 20 April 2024 00:54:05 BST, "Chen, Zide" wrote:
>
>
>On 4/19/2024 11:43 AM, David Woodhouse wrote:
>> On 19 April 2024 19:40:06 BST, David Woodhouse wrote:
>>> On 19 April 2024 18:13:16 BST, "Chen, Zide" wrote:
>>>> I'm wonderi
On Fri, 2024-04-19 at 16:54 -0700, Chen, Zide wrote:
>
> However, the selftest hangs:
>
> [Apr19 16:15] kselftest: Running tests in kvm
> [Apr19 16:16] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ +0.000628] rcu: 78-...0: (1 GPs behind)
> idle=3c8c/1/0x4000 softirq
On Mon, 2024-04-22 at 16:11 +0200, Paolo Bonzini wrote:
> On Thu, Apr 18, 2024 at 9:46 PM David Woodhouse wrote:
> > + curr_tsc_hz = get_cpu_tsc_khz() * 1000LL;
> > + if (unlikely(curr_tsc_hz == 0)) {
> > + rc = -EINVAL;
> &g
On Mon, 2024-04-22 at 14:22 +0200, Paolo Bonzini wrote:
> On Thu, Apr 18, 2024 at 9:51 PM David Woodhouse wrote:
> > gpa_t time;
> > struct pvclock_vcpu_time_info hv_clock;
> > - unsigned int hw_tsc_khz;
> > + unsigned int hw_tsc_hz;
>
On Mon, 2024-04-22 at 17:54 +0200, Paolo Bonzini wrote:
> On Mon, Apr 22, 2024 at 5:39 PM David Woodhouse wrote:
>
> > > ... especially considering that you did use a 64-bit integer here
> > > (though---please use u64 not uint64_t; and BTW if you want to add
On Mon, 2024-04-22 at 15:02 -0700, Chen, Zide wrote:
>
>
> On 4/20/2024 9:03 AM, David Woodhouse wrote:
> > On Fri, 2024-04-19 at 16:54 -0700, Chen, Zide wrote:
> > >
> > > However, the selftest hangs:
> > >
> > > [Apr19 16:15] kselftest:
On 23 April 2024 18:59:21 BST, "Chen, Zide" wrote:
>
>
>On 4/23/2024 12:49 AM, David Woodhouse wrote:
>>> If I restored the KVM_REQ_GLOBAL_CLOCK_UPDATE request from
>>> kvm_arch_vcpu_load(), the selftest works for me, and I ran the test for
>>>
On Mon, 2024-04-22 at 15:02 -0700, Chen, Zide wrote:
> the selftest works for me, and I ran the test for 1000+ iterations,
> w/ or w/o TSC scaling, the TEST_ASSERT(delta_corrected <= ±1) never
> got hit. This is awesome!
I think that with further care we can get even better than that.
Let's look
From: David Woodhouse
KVM does make an attempt to cope with non-constant TSC, and has notifiers
to handle host TSC frequency changes. However, it *only* adjusts the KVM
clock, and doesn't adjust TSC frequency scaling when the host changes.
This is presumably because non-constant TSCs were
37 corrected=5038374945
* delta_uncorrected=3509 delta_corrected=1
Signed-off-by: Jack Allister
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
CC: Dongli Zhang
---
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/x86_64/pvclock_test.c | 192 ++
2 files
From: David Woodhouse
Let the callers pass the host TSC value in as an explicit parameter.
This leaves some fairly obviously stupid code, which using this function
to compare the guest TSC at some *other* time, with the newly-minted TSC
value from rdtsc(). Unless it's being used to me
From: David Woodhouse
When synchronizing to an existing TSC (either by explicitly writing zero,
or the legacy hack where the TSC is written within one second's worth of
the previously written TSC), the last_tsc_write and last_tsc_nsec values
were being misrecorded by __kvm_synchronize_tsc()
From: David Woodhouse
There was some confusion in kvm_update_guest_time() when software needs
to advance the guest TSC.
In master clock mode, there are two points of time which need to be taken
into account. First there is the master clock reference point, stored in
kvm->arch.master_kernel
IME} without even *caring* about the eponymous
KVM clock. Especially as this information is (a) fundamentally what the
vDSO gettimeofday() exposes to us anyway, (b) using CLOCK_REALTIME not
TAI, (c) not available on other platforms, for example for migrating
the Arm arch counter.)
David Woodhouse (13
From: David Woodhouse
Commit 53fafdbb8b21 ("KVM: x86: switch KVMCLOCK base to monotonic raw
clock") did so only for 64-bit hosts, by capturing the boot offset from
within the existing clocksource notifier update_pvclock_gtod().
That notifier was added in commit 16e8d74d2da9 ("KVM
From: David Woodhouse
There is no reason why the KVM clock cannot be in masterclock mode when
the TSCs are not in sync, as long as they are at the same *frequency*.
Running at a different frequency would lead to a systemic skew between
the clock(s) as observed by different vCPUs due to
From: David Woodhouse
These pointlessly duplicate of the last_tsc_{nsec,offset,write} values.
The only place they were used was where the TSC is stable and a new vCPU
is being synchronized to the previous setting, in which case the 'last_'
value is definitely identical.
Signed-off
From: David Woodhouse
The kvm_guest_time_update() function scales the host TSC frequency to
the guest's using kvm_scale_tsc() and the v->arch.l1_tsc_scaling_ratio
scaling ratio previously calculated for that vCPU. Then calcuates the
scaling factors for the KVM clock itself based on th
From: David Woodhouse
When in 'master clock mode' (i.e. when host and guest TSCs are behaving
sanely and in sync), the KVM clock is defined in terms of the guest TSC.
When TSC scaling is used, calculating the KVM clock directly from *host*
TSC cycles leads to a systemic drift from
From: David Woodhouse
The KVM clock is an interesting thing. It is defined as "nanoseconds
since the guest was created", but in practice it runs at two *different*
rates — or three different rates, if you count implementation bugs.
Definition A is that it runs synchronousl
From: David Woodhouse
Both kvm_track_tsc_matching() and pvclock_update_vm_gtod_copy() make a
decision about whether the KVM clock should be in master clock mode.
They use *different* criteria for the decision though. This isn't really
a problem; it only has the potential to cause unnece
From: David Woodhouse
Commit 3ae13faac400 ("KVM: x86: pass kvm_get_time_scale arguments in hertz")
made this function take 64-bit values in Hz rather than 32-bit kHz. Thus
making it entrely pointless to shadow its arguments into local 64-bit
variables. Just use scaled_hz and base_h
From: David Woodhouse
The documentation on TSC migration using KVM_VCPU_TSC_OFFSET is woefully
inadequate. It ignores TSC scaling, and ignores the fact that the host
TSC may differ from one host to the next (and in fact because of the way
the kernel calibrates it, it generally differs from one
way. The
explicit fallback allows userspace to deliberately fail migration to a host
with misbehaving TSC where master clock mode wouldn't be active.)
Co-developed-by: David Woodhouse
Signed-off-by: Jack Allister
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
CC: Dongli Zhang
---
On Wed, 2024-05-01 at 10:55 -0700, Chen, Zide wrote:
>
> > +static bool kvm_use_master_clock(strut kvm *kvm)
>
> typo: 'strut' -> 'struct'
Yeah, sorry about that. Apparently I forgot to *commit* the fixups for
that last-minute cleanup, before mailing the series out.
Fixed in
https://git.infrade
On Sat, 2024-05-04 at 04:42 -0300, Marcelo Tosatti wrote:
> On Sat, Apr 27, 2024 at 12:04:58PM +0100, David Woodhouse wrote:
> >
> > In particular, KVM_REQ_MASTERCLOCK_UPDATE will take a new snapshot of
> > time as the reference in master_kernel_ns and master_cycle_now, ya
On Fri, 2024-05-10 at 17:03 +0800, Chenyi Qiang wrote:
>
> Do we need to track vcpu->arch.this_tsc_nsec/this_tsc_write? At least
> they are still used in compute_guest_tsc() to calculate the guest
> tsc.
Ah yes, that's true. Good catch; thanks.
That should be caught by a test case which runs the
69 matches
Mail list logo
