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.
smime.p7s
Description: S/MIME cryptographic signature
