[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
On 06.04.2020 12:57, Roger Pau Monne wrote: > Introduce a specific flag to request a HVM guest linear TLB flush, > which is an ASID/VPID tickle that forces a guest linear to guest > physical TLB flush for all HVM guests. > > This was previously unconditionally done in each pre_flush call, but > that's not required: HVM guests not using shadow don't require linear > TLB flushes as Xen doesn't modify the guest page tables in that case > (ie: when using HAP). Note that shadow paging code already takes care > of issuing the necessary flushes when the shadow page tables are > modified. > > In order to keep the previous behavior modify all shadow code TLB > flushes to also flush the guest linear to physical TLB if the guest is > HVM. I haven't looked at each specific shadow code TLB flush in order > to figure out whether it actually requires a guest TLB flush or not, > so there might be room for improvement in that regard. > > Also perform ASID/VPID flushes when modifying the p2m tables as it's a > requirement for AMD hardware. Finally keep the flush in > switch_cr3_cr4, as it's not clear whether code could rely on > switch_cr3_cr4 also performing a guest linear TLB flush. A following > patch can remove the ASID/VPID tickle from switch_cr3_cr4 if found to > not be necessary. > > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> with one really minor remark: > --- a/xen/arch/x86/mm/paging.c > +++ b/xen/arch/x86/mm/paging.c > @@ -613,7 +613,8 @@ void paging_log_dirty_range(struct domain *d, > > p2m_unlock(p2m); > > - flush_tlb_mask(d->dirty_cpumask); > + flush_mask(d->dirty_cpumask, (!hap_enabled(d) ? FLUSH_TLB : 0) | > + FLUSH_HVM_ASID_CORE); In cases where one case is assumed to be more likely than the other putting the more likely one first can be viewed as a mild hint to the compiler, and hence an extra ! may be warranted in an if() or a conditional expression. Here, however, I don't think we can really consider one case more likely than the other, and hence I'd suggest to avoid the !, flipping the other two expressions accordingly. I may take the liberty to adjust this while committing (if I'm to be the one). Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |