This series aims to provide a means to render the iommu driver support for x86
configurable. Currently, irrespectively of the target platform, both AMD and
Intel iommu drivers are built. This is the case because the existent Kconfig
infrastructure does not provide any facilities for finer-grained configuration.

The series adds two new Kconfig options, AMD_IOMMU and INTEL_VTD, that can be
used to generate a tailored iommu configuration for a given platform.

This series will be part of a broader effort to separate platform specific
code and it is sent as an RFC to gather feedback regarding the way the
separation should be performed.

Xenia Ragiadakou (7):
  x86/iommu: make AMD-Vi and Intel VT-d support configurable
  x86/iommu: amd_iommu_perdev_intremap is AMD-Vi specific
  x86/iommu: iommu_igfx, iommu_qinval and iommu_snoop are VT-d specific
  x86/acpi: separate AMD-Vi and VT-d specific functions
  x86/iommu: the code addressing CVE-2011-1898 is VT-d specific
  x86/iommu: call pi_update_irte through an hvm_function callback
  x86/dpci: move hvm_dpci_isairq_eoi() to generic HVM code

 xen/arch/x86/hvm/vmx/vmx.c               | 10 ++++
 xen/arch/x86/include/asm/acpi.h          | 14 ++++++
 xen/arch/x86/include/asm/hvm/hvm.h       | 22 ++++++++
 xen/arch/x86/include/asm/hvm/io.h        |  1 +
 xen/arch/x86/include/asm/hvm/vmx/vmx.h   | 11 ++++
 xen/arch/x86/include/asm/iommu.h         |  5 +-
 xen/arch/x86/pv/hypercall.c              |  2 +
 xen/arch/x86/x86_64/entry.S              |  2 +
 xen/drivers/passthrough/Kconfig          | 16 ++++++
 xen/drivers/passthrough/Makefile         |  4 +-
 xen/drivers/passthrough/amd/iommu_init.c |  2 +
 xen/drivers/passthrough/iommu.c          |  7 ++-
 xen/drivers/passthrough/vtd/x86/Makefile |  1 -
 xen/drivers/passthrough/vtd/x86/hvm.c    | 64 ------------------------
 xen/drivers/passthrough/x86/hvm.c        | 47 +++++++++++++++--
 xen/include/xen/acpi.h                   |  3 --
 xen/include/xen/iommu.h                  | 11 ++--
 17 files changed, 141 insertions(+), 81 deletions(-)
 delete mode 100644 xen/drivers/passthrough/vtd/x86/hvm.c

-- 
2.37.2

On 19/12/2022 6:34 am, Xenia Ragiadakou wrote:
> This series aims to provide a means to render the iommu driver support for x86
> configurable. Currently, irrespectively of the target platform, both AMD and
> Intel iommu drivers are built. This is the case because the existent Kconfig
> infrastructure does not provide any facilities for finer-grained configuration.
>
> The series adds two new Kconfig options, AMD_IOMMU and INTEL_VTD, that can be
> used to generate a tailored iommu configuration for a given platform.
>
> This series will be part of a broader effort to separate platform specific
> code and it is sent as an RFC to gather feedback regarding the way the
> separation should be performed.

Hello,

Thanks for the series.

From discussions in the past, we do want CONFIG_INTEL/AMD/etc and we do
want these to be selectable and available for randconfig to test.

Some sub-features are more complicated, because e.g. Centaur have CPUs
with a VT-x implementation.  This will need expressing in whatever
Kconfig scheme we end up with.

IOMMUs are more tricky still.  They are (for most intents and purposes)
mandatory on systems with >254 CPUs.  We could in principle start
supporting asymmetric IRQ routing on large systems, but Xen doesn't
currently and it would be a lot work that's definitely not high on the
priority list.  At a minimum, this will need expressing in the Kconfig
help text.

We need to decide whether it is sensible to allow users to turn off
IOMMU support.  It probably is, because you could trivially do this by
selecting CONFIG_INTEL only, and booting the result on an AMD system.


For the names, I don't think AMD_IOMMU vs INTEL_VTD is a sensible. 
Probably wants to be INTEL_IOMMU to match.

~Andrew

Hi,

On 12/19/22 20:28, Andrew Cooper wrote:
> On 19/12/2022 6:34 am, Xenia Ragiadakou wrote:
>> This series aims to provide a means to render the iommu driver support for x86
>> configurable. Currently, irrespectively of the target platform, both AMD and
>> Intel iommu drivers are built. This is the case because the existent Kconfig
>> infrastructure does not provide any facilities for finer-grained configuration.
>>
>> The series adds two new Kconfig options, AMD_IOMMU and INTEL_VTD, that can be
>> used to generate a tailored iommu configuration for a given platform.
>>
>> This series will be part of a broader effort to separate platform specific
>> code and it is sent as an RFC to gather feedback regarding the way the
>> separation should be performed.
> 
> Hello,
> 
> Thanks for the series.
> 
>  From discussions in the past, we do want CONFIG_INTEL/AMD/etc and we do
> want these to be selectable and available for randconfig to test.
> 
> Some sub-features are more complicated, because e.g. Centaur have CPUs
> with a VT-x implementation.  This will need expressing in whatever
> Kconfig scheme we end up with.
> 

What about having configuration per cpu vendor, per virtualization 
technology and per IOMMU technology? I mean sth like [CPU_AMD, 
CPU_HYGON, CPU_INTEL, CPU_SHANGHAI, CPU_CENTAUR], [AMD_SVM, INTEL_VMX] 
and [AMD_IOMMU, INTEL_IOMMU], respectively?

> IOMMUs are more tricky still.  They are (for most intents and purposes)
> mandatory on systems with >254 CPUs.  We could in principle start
> supporting asymmetric IRQ routing on large systems, but Xen doesn't
> currently and it would be a lot work that's definitely not high on the
> priority list.  At a minimum, this will need expressing in the Kconfig
> help text.
>

Ok.

> We need to decide whether it is sensible to allow users to turn off
> IOMMU support.  It probably is, because you could trivially do this by
> selecting CONFIG_INTEL only, and booting the result on an AMD system.
> 

I cannot understand. I guess that if the code for the target system is 
disabled, Xen won't boot ... hopefully :).

If users are not allowed to turn off the IOMMU support, it can be always 
enabled unconditionally via Kconfig select based on the virtualization 
technology or other.

> 
> For the names, I don't think AMD_IOMMU vs INTEL_VTD is a sensible.
> Probably wants to be INTEL_IOMMU to match.
> 

Ok.

> ~Andrew

-- 
Xenia

On Tue, 20 Dec 2022, Xenia Ragiadakou wrote:
> > We need to decide whether it is sensible to allow users to turn off
> > IOMMU support.  It probably is, because you could trivially do this by
> > selecting CONFIG_INTEL only, and booting the result on an AMD system.
> > 
> 
> I cannot understand. I guess that if the code for the target system is
> disabled, Xen won't boot ... hopefully :).
> 
> If users are not allowed to turn off the IOMMU support, it can be always
> enabled unconditionally via Kconfig select based on the virtualization
> technology or other.

Just wanted to say that it should be fine either way. If we don't want
to provide an option to disable the IOMMU, then it could be handled at
the kconfig level.

On 19.12.2022 19:28, Andrew Cooper wrote:
> IOMMUs are more tricky still.  They are (for most intents and purposes)
> mandatory on systems with >254 CPUs.  We could in principle start
> supporting asymmetric IRQ routing on large systems, but Xen doesn't
> currently and it would be a lot work that's definitely not high on the
> priority list.  At a minimum, this will need expressing in the Kconfig
> help text.
> 
> We need to decide whether it is sensible to allow users to turn off
> IOMMU support.  It probably is, because you could trivially do this by
> selecting CONFIG_INTEL only, and booting the result on an AMD system.

One other thing Andrew and I have been talking about: We probably do
not want to tie the IOMMU vendor control to CPU vendor one. IOW we'd
like to be able to e.g. build a hypervisor supporting Intel (only) as
the CPU vendor, but at the same time having support for an AMD IOMMU.

> For the names, I don't think AMD_IOMMU vs INTEL_VTD is a sensible. 
> Probably wants to be INTEL_IOMMU to match.

Or simply VTD, covering the case than some other vendor comes up with a
clone. But of course we have that same issue with "AMD" and Hygon ...

Jan

On 12/20/22 12:09, Jan Beulich wrote:
> On 19.12.2022 19:28, Andrew Cooper wrote:
>> IOMMUs are more tricky still.  They are (for most intents and purposes)
>> mandatory on systems with >254 CPUs.  We could in principle start
>> supporting asymmetric IRQ routing on large systems, but Xen doesn't
>> currently and it would be a lot work that's definitely not high on the
>> priority list.  At a minimum, this will need expressing in the Kconfig
>> help text.
>>
>> We need to decide whether it is sensible to allow users to turn off
>> IOMMU support.  It probably is, because you could trivially do this by
>> selecting CONFIG_INTEL only, and booting the result on an AMD system.
> 
> One other thing Andrew and I have been talking about: We probably do
> not want to tie the IOMMU vendor control to CPU vendor one. IOW we'd
> like to be able to e.g. build a hypervisor supporting Intel (only) as
> the CPU vendor, but at the same time having support for an AMD IOMMU.
> 

I totally understand. I am not aiming to tie the AMD/INTEL IOMMU support 
to any particular CPU vendor.

>> For the names, I don't think AMD_IOMMU vs INTEL_VTD is a sensible.
>> Probably wants to be INTEL_IOMMU to match.
> 
> Or simply VTD, covering the case than some other vendor comes up with a
> clone. But of course we have that same issue with "AMD" and Hygon ...
> 

I prefer INTEL_IOMMU over VTD, I think.

> Jan

-- 
Xenia