On Wed, May 22, 2024 at 1:20 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>
> On Thu, May 16 2024 at 09:53, Jim Mattson wrote:
> > On Wed, May 15, 2024 at 2:03 PM Maxim Levitsky <mlevitsk@xxxxxxxxxx> 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
