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

[zhanghailiang <zhang.zhanghailiang@huawei.com>]

On 2014/12/18 6:17, Stefan Fritsch wrote:
> 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

I have test it when set bit 8, it seems that it is useless. The result
is no difference, compared with not setting this bit.

> 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

That is what this patch want to do ;)

> 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.
>
>
> .
>