2016-09-29 15:19+0200, Paolo Bonzini: > On 29/09/2016 13:23, Radim Krčmář wrote: >> QEMU 2.7 allowed EIM even in configurations that were forbidden in the >> last patch because they were not working, like old KVM or userspace >> APIC. In order to keep backward compatibility, we again allow guests to >> misbehave in non-obvious ways, and make it the default. >> >> Signed-off-by: Radim Krčmář <rkrc...@redhat.com> > > Ugh, I misremembered that VTD_ECAP_EIM was not set in 2.7. :( Perhaps > it's better to drop this patch...
I think that adding this backward compatibility hack into code that is supposed to be developed is not a good idea. 2016-09-29 12:01-0300, Eduardo Habkost: > If you break compatibility and fix it in separate patches, you > break bisectability (even for people that are bisecting bugs > unrelated to EIM). I'd keep it as a separate patch and let maintainers decide whether they want to squish or drop it. > (But I still don't understand if patch 6/7 really breaks > anything, or not.) Nothing useful. It "breaks" three cases: 1) If user configured -machine kernel_irqchip=off -device intel_iommu,intremap=on QEMU 2.7 pc-q35-2.7 enabled (broken) EIM, but 2.8 wouldn't, leading to a different machine. (The same with new KVM and split irqchip.) 2) If user had old KVM and configured -machine kernel_irqchip=split -device intel_iommu,intremap=on QEMU 2.7 pc-q35-2.7 enabled (broken) EIM, but after offline migration to 2.8, QEMU would refuse to start. 3) If user started a pc-q35-2.7 with QEMU 2.8 on a new KVM, then they could use cluster x2APIC without a problem, but the guest wouldn't work after offline migration to QEMU 2.7 (I'm not sure if this case is supported). Luckily, the intel-iommu device doesn't support live migration. :)