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
