Re: [PATCH 5/5] x86/kvm: Add KVM_FEATURE_MSI_EXT_DEST_ID

[David Woodhouse]

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