From: Thomas Gleixner <tglx@linutronix.de>
To: Jim Mattson <jmattson@google.com>, Maxim Levitsky <mlevitsk@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Marc Zyngier <maz@kernel.org>,
Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: RFC: NTP adjustments interfere with KVM emulation of TSC deadline timers
Date: Wed, 22 May 2024 22:20:13 +0200 [thread overview]
Message-ID: <87cypdha4i.ffs@tglx> (raw)
In-Reply-To: <CALMp9eSPXP-9u7Fd+QMmeKzO6+fbTfn3iAHUn83Og+F=SvcQ4A@mail.gmail.com>
On Thu, May 16 2024 at 09:53, Jim Mattson wrote:
> On Wed, May 15, 2024 at 2:03 PM Maxim Levitsky <mlevitsk@redhat.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
next prev parent reply other threads:[~2024-05-22 20:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 16:51 RFC: NTP adjustments interfere with KVM emulation of TSC deadline timers Maxim Levitsky
2023-12-21 19:09 ` Jim Mattson
2024-01-02 22:21 ` Maxim Levitsky
2024-01-02 23:49 ` Jim Mattson
2024-05-15 21:03 ` Maxim Levitsky
2024-05-16 16:53 ` Jim Mattson
2024-05-22 20:20 ` Thomas Gleixner [this message]
2024-05-23 17:21 ` Jim Mattson
2024-05-22 21:07 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cypdha4i.ffs@tglx \
--to=tglx@linutronix.de \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=vkuznets@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox