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] [thread-next>] [day] [month] [year] [list]

Date: Wed, 22 May 2024 22:20:13 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Jim Mattson <jmattson@...gle.com>, Maxim Levitsky <mlevitsk@...hat.com>
Cc: 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 Thu, May 16 2024 at 09:53, Jim Mattson wrote:
> On Wed, May 15, 2024 at 2:03 PM Maxim Levitsky <mlevitsk@...hat.com> 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?

> (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