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