[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3] x86/hvm/viridian: flush remote tlbs by hypercall
>>> On 19.11.15 at 14:19, <paul.durrant@xxxxxxxxxx> wrote: > The Microsoft Hypervisor Top Level Functional Spec. (section 3.4) defines > two bits in CPUID leaf 0x40000004:EAX for the hypervisor to recommend > whether or not to issue a hypercall for local or remote TLB flush. > > Whilst it's doubtful whether using a hypercall for local TLB flush would > be any more efficient than a specific INVLPG VMEXIT, a remote TLB flush > may well be more efficiently done. This is because the alternative > mechanism is to IPI all the vCPUs in question which (in the absence of > APIC virtualisation) will require emulation and scheduling of the vCPUs > only to have them immediately VMEXIT for local TLB flush. > > This patch therefore adds a viridian option which, if selected, enables > the hypercall for remote TLB flush and implements it using ASID > invalidation for targetted vCPUs followed by an IPI only to the set of > CPUs that happened to be running a targetted vCPU (which may be the empty > set). The flush may be more severe than requested since the hypercall can > request flush only for a specific address space (CR3) but Xen neither > keeps a mapping of ASID to guest CR3 nor allows invalidation of a specific > ASID, but on a host with contended CPUs performance is still likely to > be better than a more specific flush using IPIs. > > The implementation of the patch introduces per-vCPU viridian_init() and > viridian_deinit() functions to allow a scratch cpumask to be allocated. > This avoids needing to put this potentially large data structure on stack > during hypercall processing. It also modifies the hypercall input and > output bit-fields to allow a check for the 'fast' calling convention, > and a white-space fix in the definition of HVMPV_feature_mask (to remove > hard tabs). > > Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |