linux-kernel - Re: RFC: NTP adjustments interfere with KVM emulation of TSC deadline timers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALMp9eTCu0P79rX4f4j=9NFSy0L5DqoWqruAe95Qq9P1R=ucKA@mail.gmail.com>
Date: Thu, 23 May 2024 10:21:42 -0700
From: Jim Mattson <jmattson@...gle.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Maxim Levitsky <mlevitsk@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Paolo Bonzini <pbonzini@...hat.com>, Sean Christopherson <seanjc@...gle.com>, Marc Zyngier <maz@...nel.org>, 
	Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: RFC: NTP adjustments interfere with KVM emulation of TSC deadline timers

On Wed, May 22, 2024 at 1:20 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> On Thu, May 16 2024 at 09:53, Jim Mattson wrote:
> > On Wed, May 15, 2024 at 2:03 PM Maxim Levitsky <mlevitsk@...hatcom> wrote:
> >> > Today, I believe that we only use the hardware VMX-preemption timer to
> >> > deliver the virtual local APIC timer. However, it shouldn't be that
> >> > hard to pick the first deadline of {VMX-preemption timer, local APIC
> >> > timer} at each emulated VM-entry to L2.
> >>
> >> I assume that this is possible but it might add some complexity.
> >>
> >> AFAIK the design choice here was that L1 uses the hardware VMX preemption timer always,
> >> while L2 uses the software preemption timer which is relatively simple.
> >>
> >> I do agree that this might work and if it does work it might be even worthwhile
> >> change on its own.
> >>
> >> If you agree that this is a good idea, I can prepare a patch series for that.
> >
> > I do think it would be worthwhile to provide the infrastructure for
> > multiple clients of the VMX-preemption timer.
>
> That only solves the problem when the guests are on the CPU, but it does
> not solve anything when they are off the CPU because they are waiting
> for a timer to expire. In that case you are back at square one, no?

If the vCPU is in virtual VMX non-root operation while not running,
and the timer fires late, then we just emulate a VM-exit from L2 to L1
the next time the vCPU gets a chance to run. The L2 guest will not run
past the deadline, nor will the L1 guest run before the deadline.
That's all fine.

> > (Better yet would be to provide a CLOCK_MONOTONIC_RAW hrtimer, but
> > that's outwith our domain.)
>
> That's a non-trivial exercise. I respond to that in a separate mail.
>
> Thanks,
>
>         tglx