[Bug 288122] msi_map: unsupported destination APIC ID 257

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 11 Jul 2025 17:29:48 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288122

--- Comment #12 from dwmw2@infradead.org ---
Hm, we should probably do better at documentation. KVM advertises this with the
KVM_FEATURE_MSI_EXT_DEST_ID bit 15 in the KVM_CPUID_FEATURES leaf. But all it
says is 'guest checks this feature bit before using extended destination ID
bits in MSI address bits 11-5.'

Hyper-V advertises it to guests through
HYPERV_VS_PROPERTIES_EAX_EXTENDED_IOAPIC_RTE in the
HYPERV_CPUID_VIRT_STACK_PROPERTIES leaf.

Xen does it through XEN_HVM_CPUID_EXT_DEST_ID in the HVM-specific features
leaf:

/*
 * With interrupt format set to 0 (non-remappable) bits 55:49 from the
 * IO-APIC RTE and bits 11:5 from the MSI address can be used to store
 * high bits for the Destination ID. This expands the Destination ID
 * field from 8 to 15 bits, allowing to target APIC IDs up 32768.
 */
#define XEN_HVM_CPUID_EXT_DEST_ID      (1u << 5)


The principle is really simple: Both MSI and I/O APIC RTEs had an "Extended
Destination ID" field with another 8 bits ever since i686 days. Intel used the
lowest of those as the bit for indicating remappable format MSIs; we just used
the other seven.

Linux patch series at
https://lore.kernel.org/all/20201024213535.443185-1-dwmw2@infradead.org/ -- an
earlier series is much simpler; I got a bit carried away with refactoring
things and making the I/O APIC much more obviously just a tool for generating
MSIs, etc.

> Also, FreeBSD's IOMMU drivers are able (AFAIK) to do interrupt remapping without interposing on DMA in that the DMAR and AMD IOMMU drivers selectively enable features of the respective IOMMUs.


Yes, so it should work nicely with the `-device
intel-iommu,intremap=on,dma-translation=off` support that I added to QEMU (and
the EC2 hypervisor). But the AMD hardware definition doesn't give a way for the
*hardware* (hypervisor) to advertise the lack of DMA translation, and it's not
sufficient just to hope that the guest *won't* use it, of its own volition.
More reading at http://david.woodhou.se/15-bit-msi.pdf and
http://david.woodhou.se/more-than-you-ever-wanted-to-know-about-x86-msis.txt

-- 
You are receiving this mail because:
You are the assignee for the bug.