[0/3] Pin the hrtimer used for VMX-preemption timer emulation

Message

Jim Mattson May 8, 2020, 8:36 p.m. UTC

I'm still not entirely convinced that the Linux hrtimer can be used to
accurately emulate the VMX-preemption timer, but it definitely doesn't
work if the hrtimer is on a different logical processor from the vCPU
thread that needs to get kicked out of VMX non-root operation.

With these changes, the kvm-unit-test (sent separately) that verifies
that a guest can't actually observe a delayed VMX-preemption timer
VM-exit passes 99.999% of the time on a 2GHz Skylake system.

It might be possible to improve that pass rate even more by increasing
the scaling factor in the virtual IA32_VMX_MISC[4:0], but you'd have
to be even more of a stickler than I to go to that extreme.

By the way, what is the point of migrating the hrtimers for the APIC
and the PIT, since they aren't even pinned to begin with?

The subject line of the first patch was crafted for you, Sean. :-D

Jim Mattson (3):
  KVM: nVMX: Really make emulated nested preemption timer pinned
  KVM: nVMX: Change emulated VMX-preemption timer hrtimer to absolute
  KVM: nVMX: Migrate the VMX-preemption timer

 arch/x86/include/asm/kvm_host.h |  2 ++
 arch/x86/kvm/irq.c              |  2 ++
 arch/x86/kvm/vmx/nested.c       |  5 +++--
 arch/x86/kvm/vmx/vmx.c          | 11 +++++++++++
 4 files changed, 18 insertions(+), 2 deletions(-)

Comments

Paolo Bonzini May 9, 2020, 1:14 p.m. UTC | #1

On 08/05/20 22:36, Jim Mattson wrote:
> 
> It might be possible to improve that pass rate even more by increasing
> the scaling factor in the virtual IA32_VMX_MISC[4:0], but you'd have
> to be even more of a stickler than I to go to that extreme.
> 
> By the way, what is the point of migrating the hrtimers for the APIC
> and the PIT, since they aren't even pinned to begin with?

Unless housekeeping CPUs for timers are configured, the timer will run
on the CPU it is started on, even without pinning; see
get_nohz_timer_target.

Paolo

Jim Mattson June 19, 2020, 6:49 p.m. UTC | #2

On Fri, May 8, 2020 at 1:36 PM Jim Mattson <[e-mail]> wrote:
>
> I'm still not entirely convinced that the Linux hrtimer can be used to
> accurately emulate the VMX-preemption timer...

It can't, for several reasons:

1) The conversion between wall-clock time and TSC frequency, based on
tsc_khz, isn't precise enough.
2) The base clock for the hrtimer, CLOCK_MONOTONIC, can be slewed,
whereas the TSC cannot.
3) The VMX-preemption timer is suspended during MWAIT; the hrtimer is not.

Is there any reason that VMX-preemption timer emulation shouldn't just
be a second client of the hv_timer, along with lapic timer emulation?

Paolo Bonzini June 19, 2020, 10:52 p.m. UTC | #3

On 19/06/20 20:49, Jim Mattson wrote:
> On Fri, May 8, 2020 at 1:36 PM Jim Mattson <[e-mail]> wrote:
>>
>> I'm still not entirely convinced that the Linux hrtimer can be used to
>> accurately emulate the VMX-preemption timer...
> 
> It can't, for several reasons:
> 
> 1) The conversion between wall-clock time and TSC frequency, based on
> tsc_khz, isn't precise enough.
> 2) The base clock for the hrtimer, CLOCK_MONOTONIC, can be slewed,
> whereas the TSC cannot.
> 3) The VMX-preemption timer is suspended during MWAIT; the hrtimer is not.
> 
> Is there any reason that VMX-preemption timer emulation shouldn't just
> be a second client of the hv_timer, along with lapic timer emulation?

I don't think so, you'd just need logic to multiplex it.

Paolo