Changes in Makefile

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/Makefile

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/Makefile

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/Makefile

38fe3975 - vfio/pds: Initial support for pds VFIO driver

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

vfio/pds: Initial support for pds VFIO driverThis is the initial framework for the new pds-vfio-pci device driver.This does the very basics of registering the PDS PCI device andconfiguring it as a VFIO PCI device.With this change, the VF device can be bound to the pds-vfio-pci driveron the host and presented to the VM as an ethernet VF.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-3-brett.creeley@amd.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Makefile

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/Makefile

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/Makefile

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/Makefile

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/Makefile

ff53edf6 - vfio/pci: Split the pci_driver code out of vfio_pci_core.c

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

vfio/pci: Split the pci_driver code out of vfio_pci_core.cSplit the vfio_pci driver into two logical parts, the 'structpci_driver' (vfio_pci.c) which implements "Generic VFIO support for anyPCI device" and a library of code (vfio_pci_core.c) that helpsimplementing a struct vfio_device on top of a PCI device.vfio_pci.ko continues to present the same interface under sysfs and thischange should have no functional impact.Following patches will turn vfio_pci and vfio_pci_core into a separatemodule.This is a preparation for allowing another module to provide thepci_driver and allow that module to customize how VFIO is setup, injectits own operations, and easily extend vendor specific functionality.At this point the vfio_pci_core still contains a lot of vfio_pcifunctionality mixed into it. Following patches will move more of thelarge scale items out, but another cleanup series will be needed to geteverything.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-7-yishaih@nvidia.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Makefile

1cbd70fe - vfio/pci: Rename vfio_pci.c to vfio_pci_core.c

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

vfio/pci: Rename vfio_pci.c to vfio_pci_core.cThis is a preparation patch for separating the vfio_pci driver to asubsystem driver and a generic pci driver. This patch doesn't change anylogic.Signed-off-by: Max Gurtovoy Reviewed-by: Christoph Hellwig Signed-off-by: Yishai Hadas Link: https://lore.kernel.org/r/20210826103912.128972-2-yishaih@nvidia.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Makefile

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/Makefile

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/Makefile

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/Makefile

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/Makefile

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/Makefile

5846ff54 - vfio/pci: Intel IGD OpRegion support

Mon, 22 Feb 2016 23:02:43 +0000

vfio/pci: Intel IGD OpRegion supportThis is the first consumer of vfio device specific resource support,providing read-only access to the OpRegion for Intel graphics devices.Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Makefile

42ac9bd1 - vfio: initialize the virqfd workqueue in VFIO generic code

Mon, 16 Mar 2015 20:08:54 +0000

vfio: initialize the virqfd workqueue in VFIO generic codeNow we have finally completely decoupled virqfd from VFIO_PCI. We caninitialize it from the VFIO generic code, in order to safely use it frommultiple independent VFIO bus drivers.Signed-off-by: Antonios Motakis Signed-off-by: Baptiste Reynal Reviewed-by: Eric Auger Tested-by: Eric Auger Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Makefile

7e992d69 - vfio: move eventfd support code for VFIO_PCI to a separate file

Mon, 16 Mar 2015 20:08:54 +0000

vfio: move eventfd support code for VFIO_PCI to a separate fileThe virqfd functionality that is used by VFIO_PCI to implement interruptmasking and unmasking via an eventfd, is generic enough and can be reusedby another driver. Move it to a separate file in order to allow the codeto be shared.Signed-off-by: Antonios Motakis Signed-off-by: Baptiste Reynal Reviewed-by: Eric Auger Tested-by: Eric Auger Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Makefile

89e1f7d4 - vfio: Add PCI device driver

Tue, 31 Jul 2012 14:16:24 +0000

vfio: Add PCI device driverAdd PCI device support for VFIO. PCI devices expose regionsfor accessing config space, I/O port space, and MMIO areasof the device. PCI config access is virtualized in the kernel,allowing us to ensure the integrity of the system, by preventingvarious accesses while reducing duplicate support across varioususerspace drivers. I/O port supports read/write access whileMMIO also supports mmap of sufficiently sized regions. Supportfor INTx, MSI, and MSI-X interrupts are provided using eventfds touserspace.Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/pci/Makefile