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