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

[Paolo Bonzini]

On 19/10/20 14:21, David Woodhouse wrote:
> On Thu, 2020-10-08 at 09:53 +0200, Paolo Bonzini wrote:
>> 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?

Yeah, that seems fine.

> 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.

> 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?

It would be 5.11-rc1 because of the KVM_FEATURE_MSI_EXT_DEST_ID
definition which would not be in your patch but rather synchronized from
the Linux tree by scripts/update-linux-headers.sh.

If you send me the doc patch any time before 5.10-rc7, it will be in 5.10.

Paolo