On Mon, Mar 06, 2023 at 05:28:24PM +0000, David Woodhouse wrote: > Indeed, I don't think we care about the in-kernel I/OAPIC. I don't > think we care about the kernel knowing about e.g. "GSI #11" at all. We > can just deliver it as MSI (for the I/OAPIC) or using KVM_INTERRUPT and > the interrupt window as we do for the PIC. Which is why I'd happily rip > that out and let it be delivered via the APIC intercept at 0xfeexxxxx. > > The existing code which just keeps IRQ routes updated when they're > valid is kind of OK, and well-behaved guests can function. But it isn't > *right* in the case where they aren't valid. > > What *ought* to happen is that the IOMMU should raise a fault at the > moment the interrupt occurs, if the translation isn't valid. And we > don't have that at all.
Right, that's definitely not ideal as an emulator. > > As for why I care? I don't really *need* it, as I have everything I > need for Xen PIRQ support already merged in > https://gitlab.com/qemu-project/qemu/-/commit/6096cf7877 > > So while the thread at > https://lore.kernel.org/qemu-devel/aaef9961d210ac1873153bf3cf01d984708744fc.ca...@infradead.org/ > was partly driven by expecting to need this for Xen PIRQ support > (because in $DAYJOB I did those things in the other order and the PIRQ > support ended up just being a trivial different translator like the > IOMMU's IR)... I'd still quite like to fix it up in QEMU anyway, just > for correctness and fidelity in the faulting cases. > > We can do more efficient invalidation too, rather than blowing away the > entire routing table every time. Just disconnect the IRQFD for the > specific interrupts that get invalidated, and let them get fixed up > again next time they occur. I'm curious whether there's anything else beside the "correctness of emulation" reason. I would think it nice if it existed or trivial to have as what you said. I just don't know whether it's as easy, at least so far a new kernel interface seems still needed, allowing a kernel irq to be paused until being translated by QEMU from some channel we provide. So, IMHO it's about whether the reason that "we want to have a complete emulation of IR" can properly justify the complexity of at least the kernel interface (I don't worry on the qemu side a lot). After all, even if it can completes the emulation, 99.99% of people will not use it. :( -- Peter Xu