Re: [PATCH] KVM: add KVM_CAP_VMX_APICV to advertise hardware apic-v support

[Stefan Fritsch <sf@sfritsch.de>]

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.