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

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Boris Ostrovsky wrote on 2014-03-25:
> On 03/25/2014 05:45 AM, Jan Beulich wrote:
>>>>> On 25.03.14 at 00:18, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> +void vmx_hypervisor_cpuid_leaf(uint32_t sub_idx,
>>> +                               uint32_t *eax, uint32_t *ebx,
>>> +                               uint32_t *ecx, uint32_t *edx) {
>>> +    if ( sub_idx != 0 )
>>> +        return;
>>> +
>>> +    if ( cpu_has_vmx_apic_reg_virt )
>>> +        *eax |= XEN_HVM_CPUID_APIC_ACCESS_VIRT;
>>> +    if ( cpu_has_vmx_virtualize_x2apic_mode )
>>> +        *eax |= XEN_HVM_CPUID_X2APIC_VIRT; }
>> So did the two of you then settle on (a) needing to expose two bits
>> rather than just one and (b) these being the two relevant features
>> to expose?
> 
> My argument is that we can't know which APIC model a guest uses and so
> both are needed. For PVHVM we default to APIC (MMIO accesses), I can't
> remember what unenlightened HVM Linux would do. And then there are
> other OSs.
> 
> For (b) having either (or both) of these two seems to be sufficient to
> bring down the number of VMEXITs when switching from pirqs to APIC.
> It's more important to agree on (a) since for (b) we can always add another 
> bit.

In currently Xen, virtualize_x2apic_mode takes effect only when APICv is 
enabled. Without APICv, virtualize_x2apic_mode is never set. 
Per your request, you only want to drop the pirqs if guest is using x2apic. So, 
just check it inside guest OS is enough. NB: to use x2apic for guest doesn't 
require the virtualize_x2apic_mode been set. 
 
> 
> -boris


Best regards,
Yang


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel