Re: [PATCH] target/i386: Support up to 32768 CPUs without IRQ remapping

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

On Thu, 2020-10-08 at 09:53 +0200, Paolo Bonzini wrote:
> Indeed the nice thing about irqchip=split is that the handling of device
> interrupts is entirely confined within QEMU, no matter if they're IOAPIC
> or MSI.  And because we had to implement interrupt remapping, the IOAPIC
> is effectively using MSIs to deliver its interrupts.
> 
> There's still the hack to communicate IOAPIC routes to KVM and have it
> set the EOI exit bitmap correctly, though.  The code is in
> kvm_scan_ioapic_routes and it uses kvm_set_msi_irq (with irqchip=split
> everything is also an MSI within the kernel).  I think you're not
> handling that correctly for CPUs >255, so after all we _do_ need some
> kernel support.

I think that works out OK.

In QEMU's ioapic_update_kvm_routes() it calls ioapic_entry_parse()
which generates the actual "bus" MSI with the extended dest ID in bits
11-5 of the address.

That MSI message is passed to kvm_irqchip_update_msi_route() which
passes it through translation —  which does interrupt remapping and
shifting the ext bits up into ->address_hi as the KVM X2APIC API
expects.

So when the kernel's kvm_scan_ioapic_routes() goes looking,
kvm_set_msi_irq() fills 'irq' in with the correct dest_id, and
kvm_apic_match_dest() does the right thing.

No?


As far as I can tell, we *do* have a QEMU bug — not related to the ext
dest ID — because for MSIs of assigned devices we don't update the KVM
IRQ routing table when the Interrupt Remapping IEC cache is flushed.

> Paolo
> 
> > > I queued this, though of course it has to wait for the corresponding
> > > kernel patches to be accepted (or separated into doc and non-KVM
> > > parts; we'll see).
> > 
> > Thanks.

So... it'll hit the tip.git tree and thus linux-next as soon as Linus
releases 5.10-rc1, and it'll then get merged into 5.11-rc1 and be in
the 5.11 release.

At which of those three points in time would you be happy to merge it
to QEMU? If it's either of the latter two, maybe it *is* worth doing a
patch which *only* reserves the feature bit, and trying to slip it into
5.10?

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]