linux-kernel - Re: [PATCH v5] KVM x86/xen: add an override for PVCLOCK_TSC_STABLE

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]

Message-ID: <9718326e9b187b075de2df1059325aaa58cac900.camel@infradead.org>
Date:   Thu, 30 Nov 2023 19:41:58 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     paul@....org, Sean Christopherson <seanjc@...gle.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, kvm@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Andrew Cooper <andrew.cooper3@...rix.com>
Subject: Re: [PATCH v5] KVM x86/xen: add an override for
 PVCLOCK_TSC_STABLE_BIT

On Thu, 2023-11-30 at 16:41 +0000, Paul Durrant wrote:
> On 30/11/2023 16:36, Sean Christopherson wrote:
> > +Andrew
> > 
> > On Thu, Nov 02, 2023, Paul Durrant wrote:
> > > From: Paul Durrant <pdurrant@...zon.com>
> > > 
> > > Unless explicitly told to do so (by passing 'clocksource=tsc' and
> > > 'tsc=stable:socket', and then jumping through some hoops concerning
> > > potential CPU hotplug) Xen will never use TSC as its clocksource.
> > > Hence, by default, a Xen guest will not see PVCLOCK_TSC_STABLE_BIT set
> > > in either the primary or secondary pvclock memory areas. This has
> > > led to bugs in some guest kernels which only become evident if
> > > PVCLOCK_TSC_STABLE_BIT *is* set in the pvclocks. Hence, to support
> > > such guests, give the VMM a new Xen HVM config flag to tell KVM to
> > > forcibly clear the bit in the Xen pvclocks.
> > 
> > ...
> > 
> > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > > index 7025b3751027..a9bdd25826d1 100644
> > > --- a/Documentation/virt/kvm/api.rst
> > > +++ b/Documentation/virt/kvm/api.rst
> > > @@ -8374,6 +8374,7 @@ PVHVM guests. Valid flags are::
> > >     #define KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL            (1 << 4)
> > >     #define KVM_XEN_HVM_CONFIG_EVTCHN_SEND              (1 << 5)
> > >     #define KVM_XEN_HVM_CONFIG_RUNSTATE_UPDATE_FLAG     (1 << 6)
> > > +  #define KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE      (1 << 7)
> > 
> > Does Xen actually support PVCLOCK_TSC_STABLE_BIT?  I.e. do we need new uAPI to
> > fix this, or can/should KVM simply _never_ set PVCLOCK_TSC_STABLE_BIT for Xen
> > clocks?  At a glance, PVCLOCK_TSC_STABLE_BIT looks like it was added as a purely
> > Linux/KVM-only thing.
> 
> It's certainly tested in arch/x86/xen/time.c, in 
> xen_setup_vsyscall_time_info() and xen_time_init(), so I'd guess it is 
> considered to be supported.

And yes, Xen does set it, if you jump through the right hoops to make
Xen actually use the TSC as its clocksource.

The new uAPI is just a single bit in the KVM_XEN_HVM_CONFIG
capabilities; I think it's reasonable enough.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)