On Thursday 11 December 2014 18:15:39, Paolo Bonzini wrote: > On 11/12/2014 13:53, zhanghailiang wrote: > >> I think it's a Windows bug---it should prefer x2apic to hv-vapic > >> if both are available. > > > > No, i don't think it is a windows bug, it has nothing to do with > > x2apic, > hv-vapic MSRs doesn't provide any performance improvement over > x2apic MSRs. So Windows should use x2apic MSRs if both are > available. Windows can use x2apic MSRs together with its EOI > optimization, like Linux does. > > There definitely are Windows versions that know how to use x2apic > (e.g. 2008R2). > The Hyper-V specification (V3) has different bits for "supported" and "recommended". qemu always sets this bit (HV_X64_APIC_ACCESS_RECOMMENDED): Bit 3: Recommend using MSRs for accessing APIC registers EOI, ICR and TPR rather than their memory-mapped counterparts. But it does not seem to set this bit: Bit 8: Recommend using x2APIC MSRs. I guess that is why Windows does not use x2apic and qemu should always set this bit. But the HV_X64_APIC_ACCESS_RECOMMENDED bit should probably not be set if the host supports apic-v. I havn't done any testing, though. > > but apic-v (need hardware support, i.e. Haswell cpu). > > APICv can use the x2apic MSRs. > > > When we don't passthough host cpu model to Guest os, > > it has no idea about whether it supports apic-v in host, > > The presence of APICv should be totally transparent to the guest. > > > Actually, qemu has a option 'hv_vapic' for -cpu, we can choose not > > to configure it if we know there is apic-v support in host. But > > IMHO, we'd better to do it automatically. > > ... and cause the CPUID to change under the guest's feet if you > migrate from a non-APICv to an APICv machines, or vice versa. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
