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/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
>>> +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.
>>
> 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.


-boris

>
>> 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
>
> Best regards,
> Yang
>
>