Re: [Xen-devel] [PATCH v4 12/12] AMD/IOMMU: miscellaneous DTE handling adjustments

[Andrew Cooper <andrew.cooper3@citrix.com>]

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
<andrew.cooper3@citrix.com>

[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
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel