linux-kernel - RE: [PATCH V2 03/11] perf/x86: Add support for TSC in nanoseconds as a perf event clock

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:   Tue, 8 Mar 2022 21:06:24 +0000
From:   "Hall, Christopher S" <christopher.s.hall@...el.com>
To:     "Hunter, Adrian" <adrian.hunter@...el.com>,
        Peter Zijlstra <peterz@...radead.org>
CC:     Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        "Arnaldo Carvalho de Melo" <acme@...nel.org>,
        Jiri Olsa <jolsa@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "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" <x86@...nel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        H Peter Anvin <hpa@...or.com>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        "Leo Yan" <leo.yan@...aro.org>,
        "jgross@...e.com" <jgross@...e.com>,
        "sdeep@...are.com" <sdeep@...are.com>,
        "pv-drivers@...are.com" <pv-drivers@...are.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        "kys@...rosoft.com" <kys@...rosoft.com>,
        "sthemmin@...rosoft.com" <sthemmin@...rosoft.com>,
        "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>,
        "Andrew.Cooper3@...rix.com" <Andrew.Cooper3@...rix.com>
Subject: RE: [PATCH V2 03/11] perf/x86: Add support for TSC in nanoseconds as
 a perf event clock

Adrian Hunter wrote:
> On 7.3.2022 16.42, Peter Zijlstra wrote:
> > On Mon, Mar 07, 2022 at 02:36:03PM +0200, Adrian Hunter wrote:
> >
> >>> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> >>> index 4420499f7bb4..a1f179ed39bf 100644
> >>> --- a/arch/x86/kernel/paravirt.c
> >>> +++ b/arch/x86/kernel/paravirt.c
> >>> @@ -145,6 +145,15 @@ DEFINE_STATIC_CALL(pv_sched_clock, native_sched_clock);
> >>>
> >>>  void paravirt_set_sched_clock(u64 (*func)(void))
> >>>  {
> >>> +	/*
> >>> +	 * Anything with ART on promises to have sane TSC, otherwise the whole
> >>> +	 * ART thing is useless. In order to make ART useful for guests, we
> >>> +	 * should continue to use the TSC. As such, ignore any paravirt
> >>> +	 * muckery.
> >>> +	 */
> >>> +	if (cpu_feature_enabled(X86_FEATURE_ART))
> >>
> >> Does not seem to work because the feature X86_FEATURE_ART does not seem to get set.
> >> Possibly because detect_art() excludes anything running on a hypervisor.
> >
> > Simple enough to delete that clause I suppose. Christopher, what is
> > needed to make that go away? I suppose the guest needs to be aware of
> > the active TSC scaling parameters to make it work ?
> 
> There is also not X86_FEATURE_NONSTOP_TSC nor values for art_to_tsc_denominator
> or art_to_tsc_numerator.  Also, from the VM's point of view, TSC will jump
> forwards every VM-Exit / VM-Entry unless the hypervisor changes the offset
> every VM-Entry, which KVM does not, so it still cannot be used as a stable
> clocksource.

Translating between ART and the guest TSC can be a difficult problem and ART software
support is disabled by default in a VM.

There are two major issues translating ART to TSC in a VM:

The range of the TSC scaling field in the VMCS is much larger than the range of values
that can be represented using CPUID[15H], i.e., it is not possible to communicate this
to the VM using the current CPUID interface. The range of scaling would need to be
restricted or another para-virtualized method - preferably OS/hypervisor agnostic - to
communicate the scaling factor to the guest needs to be invented.

TSC offsetting may also be a problem. The VMCS TSC offset must be discoverable by the
guest. This can be done via TSC_ADJUST MSR. The offset in the VMCS and the guest
TSC_ADJUST MSR must always be equivalent, i.e. a write to TSC_ADJUST in the guest
must be reflected in the VMCS and any changes to the offset in the VMCS must be
reflected in the TSC_ADJUST MSR. Otherwise a para-virtualized method must
be invented to communicate an arbitrary VMCS TSC offset to the guest.