[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 29/41] x86/paravirt: Plumb a return code into __paravirt_set_sched_clock()
- To: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
- From: Sean Christopherson <seanjc@xxxxxxxxxx>
- Date: Thu, 21 May 2026 13:35:53 -0700
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
- Cc: Kiryl Shutsemau <kas@xxxxxxxxxx>, Paolo Bonzini <pbonzini@xxxxxxxxxx>, "K. Y. Srinivasan" <kys@xxxxxxxxxxxxx>, Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>, Wei Liu <wei.liu@xxxxxxxxxx>, Dexuan Cui <decui@xxxxxxxxxxxxx>, Long Li <longli@xxxxxxxxxxxxx>, Ajay Kaher <ajay.kaher@xxxxxxxxxxxx>, Alexey Makhalov <alexey.makhalov@xxxxxxxxxxxx>, Jan Kiszka <jan.kiszka@xxxxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, Andy Lutomirski <luto@xxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxx>, John Stultz <jstultz@xxxxxxxxxx>, Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>, Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>, Broadcom internal kernel review list <bcm-kernel-feedback-list@xxxxxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Stephen Boyd <sboyd@xxxxxxxxxx>, x86@xxxxxxxxxx, linux-coco@xxxxxxxxxxxxxxx, kvm@xxxxxxxxxxxxxxx, linux-hyperv@xxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, Michael Kelley <mhklinux@xxxxxxxxxxx>, Tom Lendacky <thomas.lendacky@xxxxxxx>, Nikunj A Dadhania <nikunj@xxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>
- Delivery-date: Thu, 21 May 2026 20:36:00 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Thu, May 21, 2026, David Woodhouse wrote:
> On Fri, 2026-05-15 at 12:19 -0700, Sean Christopherson wrote:
> > Add a return code to __paravirt_set_sched_clock() so that the kernel can
> > reject attempts to use a PV sched_clock without breaking the caller. E.g.
> > when running as a CoCo VM with a secure TSC, using a PV clock is generally
> > undesirable.
> >
> > Note, kvmclock is the only PV clock that does anything "extra" beyond
> > simply registering itself as sched_clock, i.e. is the only caller that
> > needs to check the new return value.
> >
> > Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
>
> Oooh... can we use this to reject the kvmclock when we have a stable
> and reliable TSC even for non-CoCo guests?
Yes, but I would much rather "fix" kvmclock to not even attempt to register
itself
as the sched_clock (which this series does).
|
