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
