On 25/07/2019 14:33, Jan Beulich wrote: > --- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h > +++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h > @@ -107,57 +107,60 @@ > #define IOMMU_DEV_TABLE_INT_CONTROL_FORWARDED 0x1 > #define IOMMU_DEV_TABLE_INT_CONTROL_TRANSLATED 0x2 > > +/* For now we always allocate maximum possible interrupt remapping tables. */
/* For now, we always allocate the maximum. 2048 remap entries. */ ? > +#define IOMMU_INTREMAP_LENGTH 0xB Also, LENGTH isn't an appropriate name. This is actually the order of the number of entries. As you're already changing the name, how about s/LENGTH/ORDER/ here? If so, Acked-by: Andrew Cooper <[email protected]> [Not related to this patch...] It has always occurred to me that we allocate silly quantities of memory for interrupt remapping tables. If I've done my sums right, for Intel we allocate 64k entries per IOMMU (256k RAM), whereas for AMD we allocate 2048 entries per PCI function (32k RAM, now with the larger format). The largest Intel system I've encountered (interrupt wise) is a few thousand interrupts, split fairly evenly across the root-complex IOMMUs (the PCH IOMMU not, because its mostly legacy IO behind there). For individual functions, I have never encountered a PCI function with more than a dozen interrupts or so, so I think in practice we can get away with allocating a 4k (32 entry) interrupt remap table in all cases. It would probably make sense to default to allocating less space, and providing a command line option to allocate max. Alternatively, we could work this out as we walk the PCI topology, as it is encoded in standards compliant ways in config space. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
