On Fri, May 03, 2019 at 03:42:06PM -0300, Eduardo Habkost wrote: > On Mon, Apr 29, 2019 at 09:22:12AM -0600, Alex Williamson wrote: > [...] > > > > What's a good 4.0.1 strategy to resolve this? Re-instate KVM irqchip > > > > as the Q35 default? I can't see that simply switching to current QEMU > > > > handling is a viable option for performance? What about 4.1? We could > > > > certainly improve EOI support in QEMU, there's essentially no support > > > > currently, but it seems like an uphill battle for an iothread based > > > > userspace ioapic to ever compare to KVM handling? Thanks, > > > > > > irqchip=split and irqchip=kernel aren't guest ABI compatible, are > > > they? That would make it impossible to fix this in pc-q35-4.0 > > > for a 4.0.1 update. > > > > I suppose it would require a pc-q35-4.0.1 machine type :-\ Thanks, > > I wonder if it's possible to untangle this and make the irqchip > option stop affecting guest ABI on 4.1+ machine-types? This way > QEMU could choose smarter defaults in the future without the > compatibility code hassle.
Hi, Eduardo, Do you mean to enable IOMMU IR for kernel-irqchip=on? If so, I would say it's not trivial... The major issue is that we probably need to explicitly kick QEMU for every kernel IOAPIC setups since QEMU is the only one who knows everything about interrupt remapping, while KVM don't even have such a mechanism so far. I'm thinking whether we should try to fix the functional problem first as proposed by Alex? The problem is even if we switch the default mode for Q35 the user could still specify that in the command line and I feel like we'd better fix the functional issue first before we consider the possible performance regression? The worst case I thought of is with the fix we offer a good QEMU 4.1/4.0.1 for users (I believe in most cases for individual users since this issue seems to not affect most enterprise users and with modern hardwares) then we also tell people to explicitly enable kernel-irqchip=on to avoid the potential performance degradation. (Sorry for the late chim-in, and of course sorry for breaking VFIO from the very beginning...) -- Peter Xu