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
