[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 4/4] x86/hvm: Indicate avaliability of HW support of APIC virtualization to HVM guests

On 03/16/2014 08:40 PM, Zhang, Yang Z wrote:
Boris Ostrovsky wrote on 2014-03-14:
On 03/13/2014 09:48 PM, Zhang, Yang Z wrote:

+ * Leaf 5 (0x40000004)
+ * HVM-specific features
+ */
+/* EAX Features */
+#define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized
registers */
+#define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized
x2APIC accesses */
I still wonder why expose the x2APIC? I guess you only want to know
the APICv is used and all platforms that support APICv must also
support virtualized x2apic. What can guest do if he knows there is
only virtuazliaed x2apic but no APICv?

You mean if it has virtualized x2APIC but not virtualized APIC
registers (i.e. bit 4 in VMCS secondary controls is set but bit 8 is
not)? I thought that term APICv encompasses both of these features.

Then it's up to the guest to decide whether to use APIC or pirqs:

* If the guest is in APIC mode then it probably should stick to pirqs
since memory-mapped accesses to APIC will cause VMEXIT.
* If it is in x2APIC mode then it makes sense for it to not use pirqs
and go with APIC (x2APIC, really) since accesses will be handled transparently.

Does x2apic mode faster than pirq?

In terms of the number of VMEXITs -- yes, it results in far fewer of them. For example, eoi_pirq() may end up in a hypercall, something that will be avoided with virtualized x2APIC.


I said in the cover letter I am not particularly happy about having
two bits for this but I thought it is justified in this case.


Best regards,

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.