[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 13:00, 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?

Run a PVH Dom0 with just HVM guests for a while on a system, until you
find a need to run a PV guest there (perhaps because of an emergency).

Jan



 


Rackspace

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