On Wed, May 15, 2019 at 02:15:03PM +0800, Peter Xu wrote: > On Tue, May 14, 2019 at 02:14:41PM -0600, Alex Williamson wrote: > > Commit b2fc91db8447 ("q35: set split kernel irqchip as default") changed > > the default for the pc-q35-4.0 machine type to use split irqchip, which > > turned out to have disasterous effects on vfio-pci INTx support. KVM > > resampling irqfds are registered for handling these interrupts, but > > these are non-functional in split irqchip mode. We can't simply test > > for split irqchip in QEMU as userspace handling of this interrupt is a > > significant performance regression versus KVM handling (GeForce GPUs > > assigned to Windows VMs are non-functional without forcing MSI mode or > > re-enabling kernel irqchip). > > > > The resolution is to revert the change in default irqchip mode in the > > pc-q35-4.1 machine and create a pc-q35-4.0.1 machine for the 4.0-stable > > branch. The qemu-q35-4.0 machine type should not be used in vfio-pci > > configurations for devices requiring legacy INTx support without > > explicitly modifying the VM configuration to use kernel irqchip. > > > > Link: https://bugs.launchpad.net/qemu/+bug/1826422 > > Fixes: b2fc91db8447 ("q35: set split kernel irqchip as default") > > Signed-off-by: Alex Williamson <alex.william...@redhat.com> > > Hi, Alex, > > I have two (probably naive) questions about the patch, possibly due to > lack of context of previous discussions so please let me know if > there's any upstream discussion that I can read. > > Firstly, could I ask why we need this 4.0.1 machine type specific for > fixing this problem? Asked because this seems to be the first time > QEMU introduces the X.Y.Z machine type in master. Could it be somehow > delayed to the release of QEMU 4.1? From the planning page I see that > it's releasing on Aug 06th/13th, a bit far away but not really that > much imho. I'm perfectly fine with this, but I just want to make sure > I have the correct understanding of the motivations.
> The second question is about our previous decision to introduce QEMU > 4.1 machine type before it's released (which is not related to the > patch at all). Is it really correct to do so before releasing of 4.1? > So now even with a development QEMU 4.0 branch the user will be able > to create 4.1 machines using "-M pc-q35-4.1", then what if the user > migrated a real 4.1 machine (with the to-be-released QEMU 4.1 binary) > to some 4.1 machine that was run with such an old 4.0 QEMU binary? > The problem is we can add more compatible properties into > pc_q35_4_1_machine_options and future pc_compat_4_1 array before QEMU > 4.1 is finally released and then "-M pc-q35-4.1" will actually have > different combination of properties IMHO, which seems to break > compatibility. Am I wrong somewhere? You are correct - we can't release a pc-q35-4.1 machine type to stable because this machine type may change arbitrarily again before release. Alex's suggestion of a pc-q35-4.0.1 is best thought of as releasing a point in time snapshot of the pc-q35-4.1 machine type to stable. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|