[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v7 3/3] x86/hvm: Indicate avaliability of HW support of APIC virtualization to HVM guests
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 VMMCALLWithout 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 VMMCALLWithout 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 VMMCALLIn other words, if the guest is unaware of the fact that x2apic is not virtualized, it will disable pirqs for no good reason. -boris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |