On 22.10.2025 11:51, Teddy Astie wrote:
> As VT-d only exists on x86, it doesn't make sense to have a x86-specific
> subdirectory. Moreover, now that vtd.c empty (once we moved the deprecated
> iommu_inclusive_mapping parameter), only ats.c remain which could be moved to
> the upper directory.
> 
> Collapse this directory to make the driver structure clearer.
> 
> Signed-off-by: Teddy Astie <[email protected]>

On top of what Andrew said, ...

> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -57,6 +57,16 @@ bool __read_mostly iommu_hwdom_passthrough;
>  bool __hwdom_initdata iommu_hwdom_inclusive;
>  int8_t __hwdom_initdata iommu_hwdom_reserved = -1;
>  
> +#ifdef CONFIG_X86
> +/*
> + * Deprecated
> + *
> + * iommu_inclusive_mapping: when set, all memory below 4GB is included in 
> dom0
> + * 1:1 iommu mappings except xen and unusable regions.
> + */
> +boolean_param("iommu_inclusive_mapping", iommu_hwdom_inclusive);
> +#endif

... such arch-specific #ifdef-ary is precisely what we'd like to avoid where
possible. Plus the way it's done you're now re-introducing the option even
to INTEL_IOMMU=n builds.

If we were to drop the option, besides editing the command line doc, a
ChangeLog entry would also be needed.

> --- a/xen/drivers/passthrough/vtd/Makefile
> +++ b/xen/drivers/passthrough/vtd/Makefile
> @@ -1,5 +1,4 @@
> -obj-$(CONFIG_X86) += x86/
> -
> +obj-y += ats.o

Losing the CONFIG_X86 dependency is likely right here (ATS is arch-independent
after all), but would imo want to come with explicit justification. The earlier
use of CONFIG_X86 was here for doc purposes (to somewhat help possible future
re-use for another architecture).

Jan

Reply via email to