mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 10:11:27 +01:00
Paul Durrant
b38d426ad0
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@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
xen-bugtool =========== The xen-bugtool command line application will collate the Xen dmesg output, details of the hardware configuration of your machine, information about the build of Xen that you are using, plus, if you allow it, various logs. The information collated can either be posted to a Xen Bugzilla bug (this bug must already exist in the system, and you must be a registered user there), or it can be saved as a .tar.bz2 for sending or archiving. The collated logs may contain private information, and if you are at all worried about that, you should not use this tool, or you should explicitly exclude those logs from the archive. xen-bugtool is wholly interactive, so simply run it, and answer the questions.