[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 1/5] x86: suppress XPTI-related TLB flushes when possible



On 22/05/2020 12:13, Roger Pau Monné wrote:
> On Fri, May 22, 2020 at 12:00:14PM +0100, Andrew Cooper wrote:
>> On 25/09/2019 16:23, Jan Beulich wrote:
>>> When there's no XPTI-enabled PV domain at all, there's no need to issue
>>> respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
>>> record the creation of PV domains by bumping opt_xpti_* accordingly.
>>>
>>> As to the sticky opt_xpti_domu vs increment/decrement of opt_xpti_hwdom,
>>> this is done this way to avoid
>>> (a) widening the former variable,
>>> (b) any risk of a missed flush, which would result in an XSA if a DomU
>>>     was able to exercise it, and
>>> (c) any races updating the variable.
>>> Fundamentally the TLB flush done when context switching out the domain's
>>> vCPU-s the last time before destroying the domain ought to be
>>> sufficient, so in principle DomU handling could be made match hwdom's.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> I am still concerned about the added complexity for no obvious use case.
>>
>> Under what circumstances do we expect to XPTI-ness come and go on a
>> system, outside of custom dev-testing scenarios?
> XPTI-ness will be sticky, in the sense that once enabled cannot be
> disabled anymore.

I guess the question was a little too rhetorical, so lets spell it out.

You're either on Meltdown vulnerable hardware, or not.  If not, none of
this logic is relevant (AFAICT).

If you're on Meltdown-vulnerable hardware and in a production
environment, your running with XPTI (at which point none of this
complexity is relevant).

The only plausible case I can see where this would make a difference is
a dev environment starting with a non-XPTI dom0, then booting an XPTI
guest, which which point can we seriously justify bizarre logic like:

    opt_xpti_hwdom -= IS_ENABLED(CONFIG_LATE_HWDOM) &&
                      !d->domain_id && opt_xpti_hwdom;

just for an alleged perf improvement in a development corner case?

~Andrew



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.