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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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 APIC
> 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 whether 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.

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.

-boris