mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2025-01-04 04:44:37 +08:00
2a3dab19a0
This makes VFIO_GROUP_SET_CONTAINER accept both a vfio container FD and an iommufd. In iommufd mode an IOAS will exist after the SET_CONTAINER, but it will not be attached to any groups. For VFIO this means that the VFIO_GROUP_GET_STATUS and VFIO_GROUP_FLAGS_VIABLE works subtly differently. With the container FD the iommu_group_claim_dma_owner() is done during SET_CONTAINER but for IOMMUFD this is done during VFIO_GROUP_GET_DEVICE_FD. Meaning that VFIO_GROUP_FLAGS_VIABLE could be set but GET_DEVICE_FD will fail due to viability. As GET_DEVICE_FD can fail for many reasons already this is not expected to be a meaningful difference. Reorganize the tests for if the group has an assigned container or iommu into a vfio_group_has_iommu() function and consolidate all the duplicated WARN_ON's etc related to this. Call container functions only if a container is actually present on the group. Link: https://lore.kernel.org/r/5-v4-42cd2eb0e3eb+335a-vfio_iommufd_jgg@nvidia.com Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Yi Liu <yi.l.liu@intel.com> Tested-by: Lixiao Yang <lixiao.yang@intel.com> Tested-by: Matthew Rosato <mjrosato@linux.ibm.com> Tested-by: Yu He <yu.he@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
55 lines
1.5 KiB
Plaintext
55 lines
1.5 KiB
Plaintext
# SPDX-License-Identifier: GPL-2.0-only
|
|
menuconfig VFIO
|
|
tristate "VFIO Non-Privileged userspace driver framework"
|
|
select IOMMU_API
|
|
depends on IOMMUFD || !IOMMUFD
|
|
select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
|
|
select INTERVAL_TREE
|
|
help
|
|
VFIO provides a framework for secure userspace device drivers.
|
|
See Documentation/driver-api/vfio.rst for more details.
|
|
|
|
If you don't know what to do here, say N.
|
|
|
|
if VFIO
|
|
config VFIO_IOMMU_TYPE1
|
|
tristate
|
|
default n
|
|
|
|
config VFIO_IOMMU_SPAPR_TCE
|
|
tristate
|
|
depends on SPAPR_TCE_IOMMU
|
|
default VFIO
|
|
|
|
config VFIO_SPAPR_EEH
|
|
tristate
|
|
depends on EEH && VFIO_IOMMU_SPAPR_TCE
|
|
default VFIO
|
|
|
|
config VFIO_VIRQFD
|
|
tristate
|
|
select EVENTFD
|
|
default n
|
|
|
|
config VFIO_NOIOMMU
|
|
bool "VFIO No-IOMMU support"
|
|
help
|
|
VFIO is built on the ability to isolate devices using the IOMMU.
|
|
Only with an IOMMU can userspace access to DMA capable devices be
|
|
considered secure. VFIO No-IOMMU mode enables IOMMU groups for
|
|
devices without IOMMU backing for the purpose of re-using the VFIO
|
|
infrastructure in a non-secure mode. Use of this mode will result
|
|
in an unsupportable kernel and will therefore taint the kernel.
|
|
Device assignment to virtual machines is also not possible with
|
|
this mode since there is no IOMMU to provide DMA translation.
|
|
|
|
If you don't know what to do here, say N.
|
|
|
|
source "drivers/vfio/pci/Kconfig"
|
|
source "drivers/vfio/platform/Kconfig"
|
|
source "drivers/vfio/mdev/Kconfig"
|
|
source "drivers/vfio/fsl-mc/Kconfig"
|
|
endif
|
|
|
|
source "virt/lib/Kconfig"
|