Re: [Qemu-devel] [PATCH 05/23] hyperv: ensure VP index equal to QEMU cpu_index

[Paolo Bonzini]

On 14/06/2017 20:59, Eduardo Habkost wrote:
> On Wed, Jun 14, 2017 at 09:40:37PM +0300, Roman Kagan wrote:
>> One more data point is that until now there was no use for vp_index in
>> QEMU, so it didn't care how KVM managed it.  In KVM the only
>> vp_index-aware path that the guests could trigger was exactly reading of
>> HV_X64_MSR_VP_INDEX.
>>
>> So let me try to sum up (to make sure I understand it right);
>>
>> 1) we add KVM_CAP_HYPERV_SYNIC2 to KVM; when QEMU enables it KVM
>>    switches to using vcpu_id as vp_index and stops zeroing synic pages
> 
> If we want to keep KVM code simpler, we could make QEMU
> explicitly initialize vp_index using vcpu_id (== arch_id == apic_id)
> if KVM_CAP_HYPERV_SYNIC2 is reported as supported.
>
>> 2) new QEMU refuses to start in non-compat mode when
>>    KVM_CAP_HYPERV_SYNIC2 is not supported
> 
> It depends on which cases are considered "in non-compat mode".
> Getting a VM not runnable just because the machine-type was
> updated is not desirable, especially considering that on most
> cases we will create the VCPUs on the same order and things would
> keep working.  Probably the best we can do on this case is to
> automatically enable compat mode, but print a warning saying
> future QEMU versions might break if the kernel is not upgraded.

Anything that specifies hv_synic can be broken.  There was really no
reason to specify it for anything except experimenting.

So QEMU never has to enable KVM_CAP_HYPERV_SYNIC.  No compat mode is
necessary.  In fact, I don't see any reason to _keep_
KVM_CAP_HYPERV_SYNIC in the kernel, either.  This means that KVM can
also switch unconditionally the vp_index to vcpu_id, because old QEMU +
new kernel won't even start.

Paolo