[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 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. Roger.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |