| Message ID | 20221219063456.2017996-1-burzalodowa@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Proposal to make x86 IOMMU driver support configurable | expand |
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
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
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
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
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.