Re: [Qemu-devel] [PATCH for-4.1 v2] q35: Revert to kernel irqchip

["Daniel P. Berrangé" <berrange@redhat.com>]

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.williamson@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 :|