[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1e6c1b08-d573-fba9-61fd-d40a74427d46@oracle.com>
Date: Fri, 9 Dec 2022 14:32:15 -0500
From: Boris Ostrovsky <boris.ostrovsky@...cle.com>
To: Krister Johansen <kjlx@...pleofstupid.com>,
Juergen Gross <jgross@...e.com>
Cc: 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>, xen-devel@...ts.xenproject.org,
linux-kernel@...r.kernel.org,
Marcelo Tosatti <mtosatti@...hat.com>,
Anthony Liguori <aliguori@...zon.com>,
David Reaver <me@...idreaver.com>,
Brendan Gregg <brendan@...el.com>
Subject: Re: [PATCH linux-next] x86/xen/time: prefer tsc as clocksource when
it is invariant
On 12/8/22 11:36 AM, Krister Johansen wrote:
> + /*
> + * As Dom0 is never moved, no penalty on using TSC there.
> + *
> + * If the guest has invariant tsc, then set xen_clocksource rating
> + * below that of the tsc so that the system prefers tsc instead. This
> + * check excludes PV domains, because PV is unable to guarantee that the
> + * guest's cpuid call has been intercepted by the hypervisor.
> + */
> + if (xen_initial_domain()) {
> xen_clocksource.rating = 275;
> + } else if ((xen_hvm_domain() || xen_pvh_domain()) &&
> + boot_cpu_has(X86_FEATURE_CONSTANT_TSC) &&
> + boot_cpu_has(X86_FEATURE_NONSTOP_TSC) &&
> + !check_tsc_unstable()) {
> + xen_clocksource.rating = 299;
> + }
What if RDTSC is intercepted?
-boris
Powered by blists - more mailing lists