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

[Paolo Bonzini <pbonzini@redhat.com>]

On 15/06/2017 13:40, Roman Kagan wrote:
> On Thu, Jun 15, 2017 at 10:26:58AM +0200, Paolo Bonzini wrote:
>> 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.
> 
> Hyper-V SynIC timers depend on it, and they work since QEMU 2.6 / KVM
> 4.5 and even supported by libvirt since 1.3.3.

But who is using them, and why would they be doing that?  What is the
advantage of using SynIC timers?

Paolo

>> 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.
> 
> I'm afraid this is too harsh on users...
> 
> Roman.
>