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-04-01:
> On 03/25/2014 09:03 PM, Zhang, Yang Z wrote:
>> 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.
> 
> Yang and I talked a bit off-list and I don't think there was an agreement on 
> this.
> 
> Here is a simple experiment to demonstrate why exposing
> virtualize_x2apic_mode is important (with one correction to what I said
> earlier: PVHVM guest will actualy default to x2apic, at least on Intel
> CPUs):
> 
> With existing code (using pirqs, i.e. no APIC/x2apic accesses), VMEXIT
> stats look as follows:
> 
> 14397 HLT
>    22420 INJ_VIRQ
>     8551 INTR
>    29849 INTR_WINDOW
>        4 MMIO_READ 2 MMIO_WRITE 628 TRAP 2 unknown
>    78157 VMENTRY
>    78157 VMEXIT
>    29299 VMMCALL
> Without pirqs (i.e. guest using x2APIC), and with virtualized x2apic,
> virtualized APIC register accesses:
> 
>    15572 HLT
>      164 INJ_VIRQ 4218 INTR 184 INTR_WINDOW 624 TRAP
>    23199 VMENTRY
>    23198 VMEXIT
>     2607 VMMCALL
> Without pirqs (again, guest uses x2APIC), without virtualized x2apic
> support but with virtualized APIC register access (which can be
> simulated by having msr_high of MSR_IA32_VMX_PROCBASED_CTLS2 clear bit 4):
> 
>       53 cpu_change
>    18674 HLT
>      226 INJ_VIRQ 11702 INTR 294 INTR_WINDOW 35186 MSR_WRITE 791 TRAP
>    70441 VMENTRY
>    70440 VMEXIT
> 3823 VMMCALL
> 
> In other words, if the guest is unaware of the fact that x2apic is not
> virtualized, it will disable pirqs for no good reason.

You don't have the data that guest is using x2apic and virtulized_x2apic is set 
but no apicv. But this scenario is not support in Xen. 

> 
> -boris


Best regards,
Yang



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