On Mon, 2023-03-06 at 11:43 +0100, Igor Mammedov wrote:
However, there are still problems while trying to extending support to
APIC ID larger than 255 because there are many places assume APIC ID is
8-bit long.
that's what I was concerned about (i.e. just enabling x2apic without fixing
with all code that just assumes 8bit apicid).
Even before you extend the physical APIC IDs past 254 or 255, there's
still the issue that 255 isn't a broadcast in X2APIC mode. And that
*logical* addressing will use more than 8 bits even when the physical
IDs are lower.
One of that is interrupt remapping which returns 32-bit
destination ID but uses MSI (which has 8-bit destination) to send to
APIC. I will look more into this.
The translated 'output' from the interrupt remapping doesn't "use MSI",
in the sense of a write transaction which happens to go to addresses in
the 0x00000000FEExxxxx range. The *input* to interrupt remapping comes
from that intercept.
The output is already "known" to be an MSI message, with a full 64-bit
address and 32-bit data, and the KVM API puts the high 24 bits of the
target APIC ID into the high word of the address.
If you look at the "generic" x86_iommu_irq_to_msi_message() in
hw/intc/x86-iommu.c you'll see it's also using the same trick:
msg.__addr_hi = irq->dest & 0xffffff00;