[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <013b5425-2a60-e4d4-b846-444a576f2b28@intel.com>
Date: Tue, 8 Mar 2022 16:23:18 +0200
From: Adrian Hunter <adrian.hunter@...el.com>
To: 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,
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,
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,
sdeep@...are.com, pv-drivers@...are.com, pbonzini@...hat.com,
seanjc@...gle.com, kys@...rosoft.com, sthemmin@...rosoft.com,
virtualization@...ts.linux-foundation.org,
Andrew.Cooper3@...rix.com, christopher.s.hall@...el.com
Subject: Re: [PATCH V2 03/11] perf/x86: Add support for TSC in nanoseconds as
a perf event clock
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.
Powered by blists - more mailing lists