[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 18.05.2020 19:09, Roger Pau Monné wrote: > On Wed, Sep 25, 2019 at 05:23:11PM +0200, Jan Beulich wrote: >> @@ -310,7 +313,16 @@ int pv_domain_initialise(struct domain * >> /* 64-bit PV guest by default. */ >> d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0; >> >> - d->arch.pv.xpti = is_hardware_domain(d) ? opt_xpti_hwdom : >> opt_xpti_domu; >> + if ( is_hardware_domain(d) && opt_xpti_hwdom ) >> + { >> + d->arch.pv.xpti = true; >> + ++opt_xpti_hwdom; >> + } >> + if ( !is_hardware_domain(d) && opt_xpti_domu ) >> + { >> + d->arch.pv.xpti = true; >> + opt_xpti_domu = 2; > > I wonder whether a store fence is needed here in order to guarantee > that opt_xpti_domu is visible to flush_area_local before proceeding > any further with domain creation. The changed behavior of flush_area_local() becomes relevant only once the new domain runs. This being x86 code, the write can't remain invisible for longer than the very latest when the function returns, as the store can't be deferred past that (in reality it can't be deferred even until after the next [real] function call or the next barrier()). And due to x86'es cache coherent nature (for WB memory) the moment the store insn completes the new value is visible to all other CPUs. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |