On Thu, 2020-10-08 at 14:05 +0200, Thomas Gleixner wrote: > Why MSI_EXT_DEST_ID? It's enabling that for MSI and IO/APIC. The > underlying mechanism might be the same, but APIC_EXT_DEST_ID is more > general and then you might also make the explanation of that bit > match the changelog. It's enabling it for *everything* that generates MSI cycles — which includes IOAPIC, HPET, and MSI-capable PCI devices. Hell, and anything else which feels like generating a physical address cycle to 0xFEExxxxx addresses. Again, the IOAPIC is just a device for turning pin-based interrupts into MSIs. Bits 19-4 of the address it writes to are taken directly from bits 63-48 of the IOAPIC RTE. There's complexity elsewhere but for *those* bits, It just uses the bits it's given, just like a PCI device or an HPET would. When I implemented this in qemu I didn't even *touch* the IOAPIC support; it doesn't affect the IOAPIC at all, just like it doesn't affect the HPET or any of the MSI-capable PCI devices that qemu emulates. They just put the bits on the bus that they're told to, when they want to generate an interrupt. This feature is an MSI feature. Not an HPET feature. Not a PCI feature. Not an IOAPIC feature. The fact that a *Linux* guest has special-case knowledge in its IOAPIC driver that duplicates what the MSI message composition does, is not a good justification for naming the feature bit bizarrely. In fact I'm really tempted to make Linux's io_apic.c just use irq_chip_compose_msi_msg() and swizzle the bits out of the message identically for IR and non-IR alike (modulo the pin hack), and delete the IR_IO_APIC_route_entry struct completely. That also completely removes the ext_dest_id trick from visibility in io_apic.c. And might avoid further confusion.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
