Re: [RFC PATCH] KVM: x86: Generate guest PV wall clock info from a single TSC read

Re: [RFC PATCH] KVM: x86: Generate guest PV wall clock info from a single TSC read

[Sean Christopherson]

On Fri, Sep 29, 2023, Woodhouse, David wrote:
> Poking around at various places which calculate the time "now" in some
> clock domain... then maybe get preempted for a while... and then
> compare that with the time "now" in the same or another clock domain. 
> 
> This one with its "ktime_get_real_ns() - get_kvmclock_ns(kvm);" seemed
> like perfect low-hanging fruit to start with.

...

> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 04b57a336b34..0ec989bb61a1 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2317,14 +2317,9 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t wall_clock, int sec_hi_o
>  	if (kvm_write_guest(kvm, wall_clock, &version, sizeof(version)))
>  		return;
>  
> -	/*
> -	 * The guest calculates current wall clock time by adding
> -	 * system time (updated by kvm_guest_time_update below) to the
> -	 * wall clock specified here.  We do the reverse here.
> -	 */
> -	wall_nsec = ktime_get_real_ns() - get_kvmclock_ns(kvm);
> +	wall_nsec = kvm_get_wall_clock_epoch(kvm);

Possibly silly question: why can't preemption simply be disabled for the duration
of the sensitive calculation?

Re: [RFC PATCH] KVM: x86: Generate guest PV wall clock info from a single TSC read

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

On Fri, 2023-09-29 at 15:25 +0000, Sean Christopherson wrote:
> 
> Possibly silly question: why can't preemption simply be disabled for the duration
> of the sensitive calculation?

I suppose it can, but you should still be doing all this from a
*single* TSC read. You might get an interrupt, you might have time
stolen by SMM, or you might be an L1 guest hosting an L2 with nested
virt...

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]