Changes in Kconfig

888bd832 - s390/pci: Introduce pdev->non_mappable_bars and replace VFIO_PCI_MMAP

Wed, 26 Feb 2025 12:07:46 +0000

s390/pci: Introduce pdev->non_mappable_bars and replace VFIO_PCI_MMAPThe ability to map PCI resources to user-space is controlled by globaldefines. For vfio there is VFIO_PCI_MMAP which is only disabled on s390 andcontrols mapping of PCI resources using vfio-pci with a fallback option viathe pread()/pwrite() interface.For the PCI core there is ARCH_GENERIC_PCI_MMAP_RESOURCE which enables ageneric implementation for mapping PCI resources plus the newer sysfsinterface. Then there is HAVE_PCI_MMAP which can be used with customdefinitions of pci_mmap_resource_range() and the historical /proc/bus/pciinterface. Both mechanisms are all or nothing.For s390 mapping PCI resources is possible and useful for testing andcertain applications such as QEMU's vfio-pci based user-space NVMe driver.For certain devices, however access to PCI resources via mappings touser-space is not possible and these must be excluded from the general PCIresource mapping mechanisms.Introduce pdev->non_mappable_bars to indicate that a PCI device's BARs cannot be accessed via mappings to user-space. In the future this enablesper-device restrictions of PCI resource mapping.For now, set this flag for all PCI devices on s390 in line with theexisting, general disable of PCI resource mapping. As s390 is the only userof the VFI_PCI_MMAP Kconfig options this can already be replaced with acheck of this new flag. Also add similar checks in the other code protectedby HAVE_PCI_MMAP respectively ARCH_GENERIC_PCI_MMAP in preparation forenabling these for supported devices.Link: https://lore.kernel.org/lkml/20250212132808.08dcf03c.alex.williamson@redhat.com/Link: https://lore.kernel.org/r/20250226-vfio_pci_mmap-v7-2-c5c0f1d26efd@linux.ibm.comSigned-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas List of files: /linux-6.15/drivers/vfio/pci/Kconfig

bb208810 - vfio/qat: Add vfio_pci driver for Intel QAT SR-IOV VF devices

Fri, 26 Apr 2024 06:40:51 +0000

vfio/qat: Add vfio_pci driver for Intel QAT SR-IOV VF devicesAdd vfio pci variant driver for Intel QAT SR-IOV VF devices. This driverregisters to the vfio subsystem through the interfaces exposed by thesubsystem. It follows the live migration protocol v2 defined inuapi/linux/vfio.h and interacts with Intel QAT PF driver through a setof interfaces defined in qat/qat_mig_dev.h to support live migration ofIntel QAT VF devices.This version only covers migration for Intel QAT GEN4 VF devices.Co-developed-by: Yahui Cao Signed-off-by: Yahui Cao Signed-off-by: Xin Zeng Reviewed-by: Giovanni Cabiddu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20240426064051.2859652-1-xin.zeng@intel.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

701ab935 - vfio/nvgrace-gpu: Add vfio pci variant module for grace hopper

Tue, 20 Feb 2024 11:50:55 +0000

vfio/nvgrace-gpu: Add vfio pci variant module for grace hopperNVIDIA's upcoming Grace Hopper Superchip provides a PCI-like devicefor the on-chip GPU that is the logical OS representation of theinternal proprietary chip-to-chip cache coherent interconnect.The device is peculiar compared to a real PCI device in that whilstthere is a real 64b PCI BAR1 (comprising region 2 & region 3) on thedevice, it is not used to access device memory once the fasterchip-to-chip interconnect is initialized (occurs at the time of hostsystem boot). The device memory is accessed instead using the chip-to-chipinterconnect that is exposed as a contiguous physically addressableregion on the host. This device memory aperture can be obtained from hostACPI table using device_property_read_u64(), according to the FWspecification. Since the device memory is cache coherent with the CPU,it can be mmap into the user VMA with a cacheable mapping usingremap_pfn_range() and used like a regular RAM. The device memoryis not added to the host kernel, but mapped directly as this reducesmemory wastage due to struct pages.There is also a requirement of a minimum reserved 1G uncached region(termed as resmem) to support the Multi-Instance GPU (MIG) feature [1].This is to work around a HW defect. Based on [2], the requisite properties(uncached, unaligned access) can be achieved through a VM mapping (S1)of NORMAL_NC and host (S2) mapping with MemAttr[2:0]=0b101. To providea different non-cached property to the reserved 1G region, it needs tobe carved out from the device memory and mapped as a separate regionin Qemu VMA with pgprot_writecombine(). pgprot_writecombine() sets theQemu VMA page properties (pgprot) as NORMAL_NC.Provide a VFIO PCI variant driver that adapts the unique device memoryrepresentation into a more standard PCI representation facing userspace.The variant driver exposes these two regions - the non-cached reserved(resmem) and the cached rest of the device memory (termed as usemem) asseparate VFIO 64b BAR regions. This is divergent from the baremetalapproach, where the device memory is exposed as a device memory region.The decision for a different approach was taken in view of the fact thatit would necessiate additional code in Qemu to discover and insert thoseregions in the VM IPA, along with the additional VM ACPI DSDT changes tocommunicate the device memory region IPA to the VM workloads. Moreover,this behavior would have to be added to a variety of emulators (beyondtop of tree Qemu) out there desiring grace hopper support.Since the device implements 64-bit BAR0, the VFIO PCI variant drivermaps the uncached carved out region to the next available PCI BAR (i.e.comprising of region 2 and 3). The cached device memory aperture isassigned BAR region 4 and 5. Qemu will then naturally generate a PCIdevice in the VM with the uncached aperture reported as BAR2 region,the cacheable as BAR4. The variant driver provides emulation for thesefake BARs' PCI config space offset registers.The hardware ensures that the system does not crash when the memoryis accessed with the memory enable turned off. It synthesis ~0 readsand dropped writes on such access. So there is no need to support thedisablement/enablement of BAR through PCI_COMMAND config space register.The memory layout on the host looks like the following: devmem (memlength)|--------------------------------------------------||-------------cached------------------------|--NC--|| |usemem.memphys resmem.memphysPCI BARs need to be aligned to the power-of-2, but the actual memory on thedevice may not. A read or write access to the physical address from thelast device PFN up to the next power-of-2 aligned physical addressresults in reading ~0 and dropped writes. Note that the GPU devicedriver [6] is capable of knowing the exact device memory size throughseparate means. The device memory size is primarily kept in the systemACPI tables for use by the VFIO PCI variant module.Note that the usemem memory is added by the VM Nvidia device driver [5]to the VM kernel as memblocks. Hence make the usable memory size memblock(MEMBLK_SIZE) aligned. This is a hardwired ABI value between the GPU FW andVFIO driver. The VM device driver make use of the same value for itscalculation to determine USEMEM size.Currently there is no provision in KVM for a S2 mapping withMemAttr[2:0]=0b101, but there is an ongoing effort to provide the same [3].As previously mentioned, resmem is mapped pgprot_writecombine(), thatsets the Qemu VMA page properties (pgprot) as NORMAL_NC. Using theproposed changes in [3] and [4], KVM marks the region withMemAttr[2:0]=0b101 in S2.If the device memory properties are not present, the driver registers thevfio-pci-core function pointers. Since there are no ACPI memory propertiesgenerated for the VM, the variant driver inside the VM will only usethe vfio-pci-core ops and hence try to map the BARs as non cached. Thisis not a problem as the CPUs have FWB enabled which blocks the VMmapping's ability to override the cacheability set by the host mapping.This goes along with a qemu series [6] to provides the necessaryimplementation of the Grace Hopper Superchip firmware specification sothat the guest operating system can see the correct ACPI modeling forthe coherent GPU device. Verified with the CUDA workload in the VM.[1] https://www.nvidia.com/en-in/technologies/multi-instance-gpu/[2] section D8.5.5 of https://developer.arm.com/documentation/ddi0487/latest/[3] https://lore.kernel.org/all/20240211174705.31992-1-ankita@nvidia.com/[4] https://lore.kernel.org/all/20230907181459.18145-2-ankita@nvidia.com/[5] https://github.com/NVIDIA/open-gpu-kernel-modules[6] https://lore.kernel.org/all/20231203060245.31593-1-ankita@nvidia.com/Reviewed-by: Kevin Tian Reviewed-by: Yishai Hadas Reviewed-by: Zhi Wang Signed-off-by: Aniket Agashe Signed-off-by: Ankit Agrawal Link: https://lore.kernel.org/r/20240220115055.23546-4-ankita@nvidia.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

eb61eca0 - vfio/virtio: Introduce a vfio driver over virtio devices

Tue, 19 Dec 2023 09:32:47 +0000

vfio/virtio: Introduce a vfio driver over virtio devicesIntroduce a vfio driver over virtio devices to support the legacyinterface functionality for VFs.Background, from the virtio spec [1].--------------------------------------------------------------------In some systems, there is a need to support a virtio legacy driver witha device that does not directly support the legacy interface. In suchscenarios, a group owner device can provide the legacy interfacefunctionality for the group member devices. The driver of the ownerdevice can then access the legacy interface of a member device on behalfof the legacy member device driver.For example, with the SR-IOV group type, group members (VFs) can notpresent the legacy interface in an I/O BAR in BAR0 as expected by thelegacy pci driver. If the legacy driver is running inside a virtualmachine, the hypervisor executing the virtual machine can present avirtual device with an I/O BAR in BAR0. The hypervisor intercepts thelegacy driver accesses to this I/O BAR and forwards them to the groupowner device (PF) using group administration commands.--------------------------------------------------------------------Specifically, this driver adds support for a virtio-net VF to be exposedas a transitional device to a guest driver and allows the legacy IO BARfunctionality on top.This allows a VM which uses a legacy virtio-net driver in the guest towork transparently over a VF which its driver in the host is that newdriver.The driver can be extended easily to support some other types of virtiodevices (e.g virtio-blk), by adding in a few places the specific typeproperties as was done for virtio-net.For now, only the virtio-net use case was tested and as such we introducethe support only for such a device.Practically,Upon probing a VF for a virtio-net device, in case its PF supportslegacy access over the virtio admin commands and the VF doesn't have BAR0, we set some specific 'vfio_device_ops' to be able to simulate in SW atransitional device with I/O BAR in BAR 0.The existence of the simulated I/O bar is reported later on byoverwriting the VFIO_DEVICE_GET_REGION_INFO command and the deviceexposes itself as a transitional device by overwriting some propertiesupon reading its config space.Once we report the existence of I/O BAR as BAR 0 a legacy driver in theguest may use it via read/write calls according to the virtiospecification.Any read/write towards the control parts of the BAR will be captured bythe new driver and will be translated into admin commands towards thedevice.In addition, any data path read/write access (i.e. virtio drivernotifications) will be captured by the driver and forwarded to thephysical BAR which its properties were supplied by the admin commandVIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO upon the probing/init flow.With that code in place a legacy driver in the guest has the look andfeel as if having a transitional device with legacy support for both itscontrol and data path flows.[1]https://github.com/oasis-tcs/virtio-spec/commit/03c2d32e5093ca9f2a17797242fbef88efe94b8cReviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Signed-off-by: Yishai Hadas Acked-by: Michael S. Tsirkin Link: https://lore.kernel.org/r/20231219093247.170936-10-yishaih@nvidia.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

fc9da661 - vfio/pds: Add Kconfig and documentation

Mon, 07 Aug 2023 20:57:55 +0000

vfio/pds: Add Kconfig and documentationAdd Kconfig entries and pds-vfio-pci.rst. Also, add an entry in theMAINTAINERS file for this new driver.It's not clear where documentation for vendor specific VFIOdrivers should live, so just re-use the current amdethernet location.Signed-off-by: Brett Creeley Signed-off-by: Shannon Nelson Reviewed-by: Simon Horman Reviewed-by: Kevin Tian Reviewed-by: Shameer Kolothum Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20230807205755.29579-9-brett.creeley@amd.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

8cc75183 - vfio/pci: Cleanup Kconfig

Wed, 14 Jun 2023 19:39:46 +0000

vfio/pci: Cleanup KconfigIt should be possible to select vfio-pci variant drivers without buildingvfio-pci itself, which implies each variant driver should selectvfio-pci-core.Fix the top level vfio Makefile to traverse pci based on vfio-pci-corerather than vfio-pci.Mark MMAP and INTX options depending on vfio-pci-core to cleanup resultingconfig if core is not enabled.Push all PCI related vfio options to a sub-menu and make descriptionsconsistent.Reviewed-by: Cédric Le Goater Reviewed-by: Eric Auger Reviewed-by: Shameer Kolothum Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20230614193948.477036-2-alex.williamson@redhat.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

c435c546 - vfio/pci: introduce CONFIG_VFIO_PCI_ZDEV_KVM

Mon, 06 Jun 2022 20:33:14 +0000

vfio/pci: introduce CONFIG_VFIO_PCI_ZDEV_KVMThe current contents of vfio-pci-zdev are today only useful in a KVMenvironment; let's tie everything currently under vfio-pci-zdev tothis Kconfig statement and require KVM in this case, reducing complexity(e.g. symbol lookups).Signed-off-by: Matthew Rosato Acked-by: Alex Williamson Reviewed-by: Pierre Morel Link: https://lore.kernel.org/r/20220606203325.110625-11-mjrosato@linux.ibm.comSigned-off-by: Christian Borntraeger List of files: /linux-6.15/drivers/vfio/pci/Kconfig

ee3a5b23 - hisi_acc_vfio_pci: add new vfio_pci driver for HiSilicon ACC devices

Tue, 08 Mar 2022 18:48:57 +0000

hisi_acc_vfio_pci: add new vfio_pci driver for HiSilicon ACC devicesAdd a vendor-specific vfio_pci driver for HiSilicon ACC devices.This will be extended in subsequent patches to add support for VFIOlive migration feature.Signed-off-by: Shameer Kolothum Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20220308184902.2242-5-shameerali.kolothum.thodi@huawei.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

6fadb021 - vfio/mlx5: Implement vfio_pci driver for mlx5 devices

Thu, 24 Feb 2022 14:20:22 +0000

vfio/mlx5: Implement vfio_pci driver for mlx5 devicesThis patch adds support for vfio_pci driver for mlx5 devices.It uses vfio_pci_core to register to the VFIO subsystem and thenimplements the mlx5 specific logic in the migration area.The migration implementation follows the definition from uapi/vfio.h anduses the mlx5 VF->PF command channel to achieve it.This patch implements the suspend/resume flows.Link: https://lore.kernel.org/all/20220224142024.147653-14-yishaih@nvidia.comReviewed-by: Alex Williamson Signed-off-by: Yishai Hadas Signed-off-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky List of files: /linux-6.15/drivers/vfio/pci/Kconfig

7fa005ca - vfio/pci: Introduce vfio_pci_core.ko

Thu, 26 Aug 2021 10:39:12 +0000

vfio/pci: Introduce vfio_pci_core.koNow that vfio_pci has been split into two source modules, one focusing onthe "struct pci_driver" (vfio_pci.c) and a toolbox library of code(vfio_pci_core.c), complete the split and move them into two differentkernel modules.As before vfio_pci.ko continues to present the same interface under sysfsand this change will have no functional impact.Splitting into another module and adding exports allows creating new HWspecific VFIO PCI drivers that can implement device specificfunctionality, such as VFIO migration interfaces or specialized devicerequirements.Signed-off-by: Max Gurtovoy Signed-off-by: Jason Gunthorpe Reviewed-by: Christoph Hellwig Signed-off-by: Yishai Hadas Link: https://lore.kernel.org/r/20210826103912.128972-14-yishaih@nvidia.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

85c94dcf - vfio: Use kconfig if XX/endif blocks instead of repeating 'depends on'

Thu, 26 Aug 2021 10:39:11 +0000

vfio: Use kconfig if XX/endif blocks instead of repeating 'depends on'This results in less kconfig wordage and a simpler understanding of therequired "depends on" to create the menu structure.The next patch increases the nesting level a lot so this is a nicepreparatory simplification.Signed-off-by: Jason Gunthorpe Reviewed-by: Christoph Hellwig Signed-off-by: Yishai Hadas Link: https://lore.kernel.org/r/20210826103912.128972-13-yishaih@nvidia.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

ca4ddaac - vfio: Use select for eventfd

Thu, 26 Aug 2021 10:39:10 +0000

vfio: Use select for eventfdIf VFIO_VIRQFD is required then turn on eventfd automatically.The majority of kconfig users of the EVENTFD use select not depends on.Signed-off-by: Jason Gunthorpe Reviewed-by: Christoph Hellwig Signed-off-by: Yishai Hadas Link: https://lore.kernel.org/r/20210826103912.128972-12-yishaih@nvidia.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

2a55ca37 - vfio/pci: zap_vma_ptes() needs MMU

Sat, 15 May 2021 19:08:56 +0000

vfio/pci: zap_vma_ptes() needs MMUzap_vma_ptes() is only available when CONFIG_MMU is set/enabled.Without CONFIG_MMU, vfio_pci.o has build errors, so makeVFIO_PCI depend on MMU.riscv64-linux-ld: drivers/vfio/pci/vfio_pci.o: in function `vfio_pci_mmap_open':vfio_pci.c:(.text+0x1ec): undefined reference to `zap_vma_ptes'riscv64-linux-ld: drivers/vfio/pci/vfio_pci.o: in function `.L0 ':vfio_pci.c:(.text+0x165c): undefined reference to `zap_vma_ptes'Fixes: 11c4cd07ba11 ("vfio-pci: Fault mmaps to enable vma tracking")Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Alex Williamson Cc: Cornelia Huck Cc: kvm@vger.kernel.orgCc: Jason Gunthorpe Cc: Eric Auger Message-Id: <20210515190856.2130-1-rdunlap@infradead.org>Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

b392a198 - vfio/pci: remove vfio_pci_nvlink2

Tue, 30 Mar 2021 16:01:18 +0000

vfio/pci: remove vfio_pci_nvlink2This driver never had any open userspace (which for VFIO would includeVM kernel drivers) that use it, and thus should never have been addedby our normal userspace ABI rules.Signed-off-by: Christoph Hellwig Acked-by: Greg Kroah-Hartman Message-Id: <20210326061311.1497642-2-hch@lst.de>Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

e0146a10 - vfio/nvlink: Add missing SPAPR_TCE_IOMMU depends

Mon, 29 Mar 2021 19:00:16 +0000

vfio/nvlink: Add missing SPAPR_TCE_IOMMU dependsCompiling the nvlink stuff relies on the SPAPR_TCE_IOMMU otherwise thereare compile errors: drivers/vfio/pci/vfio_pci_nvlink2.c:101:10: error: implicit declaration of function 'mm_iommu_put' [-Werror,-Wimplicit-function-declaration] ret = mm_iommu_put(data->mm, data->mem);As PPC only defines these functions when the config is set.Previously this wasn't a problem by chance as SPAPR_TCE_IOMMU was the onlyIOMMU that could have satisfied IOMMU_API on POWERNV.Fixes: 179209fa1270 ("vfio: IOMMU_API should be selected")Reported-by: kernel test robot Signed-off-by: Jason Gunthorpe Message-Id: <0-v1-83dba9768fc3+419-vfio_nvlink2_kconfig_jgg@nvidia.com>Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

b9abef43 - vfio/pci: remove CONFIG_VFIO_PCI_ZDEV from Kconfig

Thu, 18 Feb 2021 10:44:35 +0000

vfio/pci: remove CONFIG_VFIO_PCI_ZDEV from KconfigIn case we're running on s390 system always expose the capabilities forconfiguration of zPCI devices. In case we're running on differentplatform, continue as usual.Signed-off-by: Max Gurtovoy Reviewed-by: Matthew Rosato Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

e6b817d4 - vfio-pci/zdev: Add zPCI capabilities to VFIO_DEVICE_GET_INFO

Wed, 07 Oct 2020 18:56:23 +0000

vfio-pci/zdev: Add zPCI capabilities to VFIO_DEVICE_GET_INFODefine a new configuration entry VFIO_PCI_ZDEV for VFIO/PCI.When this s390-only feature is configured we add capabilities to theVFIO_DEVICE_GET_INFO ioctl that describe features of the associatedzPCI device and its underlying hardware.This patch is based on work previously done by Pierre Morel.Signed-off-by: Matthew Rosato Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig

ec8f24b7 - treewide: Add SPDX license identifier - Makefile/Kconfig

Sun, 19 May 2019 12:07:45 +0000

treewide: Add SPDX license identifier - Makefile/KconfigAdd SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any formThese files fall under the project license, GPL v2 only. The resulting SPDXlicense identifier is: GPL-2.0-onlySigned-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/vfio/pci/Kconfig

7f928917 - vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver

Thu, 20 Dec 2018 01:10:36 +0000

vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriverPOWER9 Witherspoon machines come with 4 or 6 V100 GPUs which are notpluggable PCIe devices but still have PCIe links which are usedfor config space and MMIO. In addition to that the GPUs have 6 NVLinkswhich are connected to other GPUs and the POWER9 CPU. POWER9 chipshave a special unit on a die called an NPU which is an NVLink2 host busadapter with p2p connections to 2 to 3 GPUs, 3 or 2 NVLinks to each.These systems also support ATS (address translation services) which isa part of the NVLink2 protocol. Such GPUs also share on-board RAM(16GB or 32GB) to the system via the same NVLink2 so a CPU hascache-coherent access to a GPU RAM.This exports GPU RAM to the userspace as a new VFIO device region. Thispreregisters the new memory as device memory as it might be used for DMA.This inserts pfns from the fault handler as the GPU memory is not onlineduntil the vendor driver is loaded and trained the NVLinks so doing thisearlier causes low level errors which we fence in the firmware soit does not hurt the host system but still better be avoided; for the samereason this does not map GPU RAM into the host kernel (usual thing foremulated access otherwise).This exports an ATSD (Address Translation Shootdown) register of NPU whichallows TLB invalidations inside GPU for an operating system. The registerconveniently occupies a single 64k page. It is also presented tothe userspace as a new VFIO device region. One NPU has 8 ATSD registers,each of them can be used for TLB invalidation in a GPU linked to this NPU.This allocates one ATSD register per an NVLink bridge allowing passingup to 6 registers. Due to the host firmware bug (just recently fixed),only 1 ATSD register per NPU was actually advertised to the host systemso this passes that alone register via the first NVLink bridge device inthe group which is still enough as QEMU collects them all back andpresents to the guest via vPHB to mimic the emulated NPU PHB on the host.In order to provide the userspace with the information about GPU-to-NVLinkconnections, this exports an additional capability called "tgt"(which is an abbreviated host system bus address). The "tgt" propertytells the GPU its own system address and allows the guest driver toconglomerate the routing information so each GPU knows how to get directlyto the other GPUs.For ATS to work, the nest MMU (an NVIDIA block in a P9 CPU) needs toknow LPID (a logical partition ID or a KVM guest hardware ID in otherwords) and PID (a memory context ID of a userspace process, not to beconfused with a linux pid). This assigns a GPU to LPID in the NPU andthis is why this adds a listener for KVM on an IOMMU group. A PID comesvia NVLink from a GPU and NPU uses a PID wildcard to pass it through.This requires coherent memory and ATSD to be available on the host asthe GPU vendor only supports configurations with both features enabledand other configurations are known not to work. Because of this andbecause of the ways the features are advertised to the host system(which is a device tree with very platform specific properties),this requires enabled POWERNV platform.The V100 GPUs do not advertise any of these capabilities via the configspace and there are more than just one device ID so this relies onthe platform to tell whether these GPUs have special abilities such asNVLinks.Signed-off-by: Alexey Kardashevskiy Acked-by: Alex Williamson Signed-off-by: Michael Ellerman List of files: /linux-6.15/drivers/vfio/pci/Kconfig

08ca1b52 - vfio/pci: Make IGD support a configurable option

Mon, 18 Jun 2018 22:39:50 +0000

vfio/pci: Make IGD support a configurable optionAllow the code which provides extensions to support direct assignmentof Intel IGD (GVT-d) to be compiled out of the kernel if desired. Theconfig option for this was previously automatically enabled on X86,therefore the default remains Y. This simply provides the option todisable it even for X86.Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Kconfig