On Wed, 2022-02-16 at 16:43 +0100, Jan Beulich wrote: On 16.02.2022 11:30, Roger Pau Monne wrote: --- a/xen/include/public/arch-x86/cpuid.h +++ b/xen/include/public/arch-x86/cpuid.h @@ -102,6 +102,12 @@ #define XEN_HVM_CPUID_IOMMU_MAPPINGS (1u << 2) #define XEN_HVM_CPUID_VCPU_ID_PRESENT (1u << 3) /* vcpu id is present in EBX */ #define XEN_HVM_CPUID_DOMID_PRESENT (1u << 4) /* domid is present in ECX */ +/* + * 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)
Would the comment perhaps better include "in the absence of (guest visible) interrupt remapping", since otherwise the layout / meaning changes anyway? Apart from this I'd be fine with this going in ahead of the rest of this series.
No, this still works even if the guest has a vIOMMU with interrupt remapping. The Compatibility Format and Remappable Format MSI messages are distinct because the low bit of the Ext Dest ID is used to indicate Remappable Format.
If you wanted to add "… without having to use interrupt remapping in the guest" to the end of the comment then I suppose you could, but I don't think it adds much.
| 
