Changes in Makefile

2202844e - vfio/migration: Add debugfs to live migration driver

Mon, 06 Nov 2023 07:22:23 +0000

vfio/migration: Add debugfs to live migration driverThere are multiple devices, software and operational steps involvedin the process of live migration. An error occurred on any node maycause the live migration operation to fail.This complex process makes it very difficult to locate and analyzethe cause when the function fails.In order to quickly locate the cause of the problem when thelive migration fails, I added a set of debugfs to the vfiolive migration driver. +-------------------------------------------+ | | | | | QEMU | | | | | +---+----------------------------+----------+ | ^ | ^ | | | | | | | | v | v | +---------+--+ +---------+--+ |src vfio_dev| |dst vfio_dev| +--+---------+ +--+---------+ | ^ | ^ | | | | v | | | +-----------+----+ +-----------+----+ |src dev debugfs | |dst dev debugfs | +----------------+ +----------------+The entire debugfs directory will be based on the definition ofthe CONFIG_DEBUG_FS macro. If this macro is not enabled, theinterfaces in vfio.h will be empty definitions, and the creationand initialization of the debugfs directory will not be executed. vfio | +--- | +---migration | +--state | +--- +---migration +--statedebugfs will create a public root directory "vfio" file.then create a dev_name() file for each live migration device.First, create a unified state acquisition file of "migration"in this device directory.Then, create a public live migration state lookup file "state".Signed-off-by: Longfang Liu Reviewed-by: Cédric Le Goater Link: https://lore.kernel.org/r/20231106072225.28577-2-liulongfang@huawei.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/Makefile

8c9c727b - vfio: Move iova_bitmap into iommufd

Tue, 24 Oct 2023 13:50:53 +0000

vfio: Move iova_bitmap into iommufdBoth VFIO and IOMMUFD will need iova bitmap for storing dirties and walkingthe user bitmaps, so move to the common dependency into IOMMUFD. In doingso, create the symbol IOMMUFD_DRIVER which designates the builtin code thatwill be used by drivers when selected. Today this means MLX5_VFIO_PCI andPDS_VFIO_PCI. IOMMU drivers will do the same (in future patches) whensupporting dirty tracking and select IOMMUFD_DRIVER accordingly.Given that the symbol maybe be disabled, add header definitions iniova_bitmap.h for when IOMMUFD_DRIVER=nLink: https://lore.kernel.org/r/20231024135109.73787-3-joao.m.martins@oracle.comSigned-off-by: Joao Martins Reviewed-by: Jason Gunthorpe Reviewed-by: Brett Creeley Reviewed-by: Kevin Tian Reviewed-by: Alex Williamson Signed-off-by: Jason Gunthorpe List of files: /linux-6.15/drivers/vfio/Makefile

c1cce6d0 - vfio: Compile vfio_group infrastructure optionally

Tue, 18 Jul 2023 13:55:50 +0000

vfio: Compile vfio_group infrastructure optionallyvfio_group is not needed for vfio device cdev, so with vfio device cdevintroduced, the vfio_group infrastructures can be compiled out if onlycdev is needed.Reviewed-by: Jason Gunthorpe Tested-by: Nicolin Chen Tested-by: Matthew Rosato Tested-by: Yanting Jiang Tested-by: Shameer Kolothum Tested-by: Terrence Xu Tested-by: Zhenzhong Duan Signed-off-by: Yi Liu Link: https://lore.kernel.org/r/20230718135551.6592-26-yi.l.liu@intel.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/Makefile

8b6f173a - vfio: Add cdev for vfio_device

Tue, 18 Jul 2023 13:55:43 +0000

vfio: Add cdev for vfio_deviceThis adds cdev support for vfio_device. It allows the user to directlyopen a vfio device w/o using the legacy container/group interface, as aprerequisite for supporting new iommu features like nested translationand etc.The device fd opened in this manner doesn't have the capability to accessthe device as the fops open() doesn't open the device until the successfulVFIO_DEVICE_BIND_IOMMUFD ioctl which will be added in a later patch.With this patch, devices registered to vfio core would have both the legacygroup and the new device interfaces created.- group interface : /dev/vfio/$groupID- device interface: /dev/vfio/devices/vfioX - normal device ("X" is a unique number across vfio devices)For a given device, the user can identify the matching vfioX by searchingthe vfio-dev folder under the sysfs path of the device. Take PCI device(0000:6a:01.0) as an example, /sys/bus/pci/devices/0000\:6a\:01.0/vfio-dev/vfioXimplies the matching vfioX under /dev/vfio/devices/, and vfio-dev/vfioX/devcontains the major:minor number of the matching /dev/vfio/devices/vfioX.The user can get device fd by opening the /dev/vfio/devices/vfioX.The vfio_device cdev logic in this patch:*) __vfio_register_dev() path ends up doing cdev_device_add() for each vfio_device if VFIO_DEVICE_CDEV configured.*) vfio_unregister_group_dev() path does cdev_device_del();cdev interface does not support noiommu devices, so VFIO only creates thelegacy group interface for the physical devices that do not have IOMMU.noiommu users should use the legacy group interface.Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato Tested-by: Yanting Jiang Tested-by: Shameer Kolothum Tested-by: Zhenzhong Duan Signed-off-by: Yi Liu Link: https://lore.kernel.org/r/20230718135551.6592-19-yi.l.liu@intel.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/Makefile

234489ac - vfio/cdx: add support for CDX bus

Wed, 31 May 2023 12:45:57 +0000

vfio/cdx: add support for CDX busvfio-cdx driver enables IOCTLs for user space to queryMMIO regions for CDX devices and mmap them. This changealso adds support for reset of CDX devices. With VFIOenabled on CDX devices, user-space applications can alsoexercise DMA securely via IOMMU on these devices.This change adds the VFIO CDX driver and enables the followingioctls for CDX devices: - VFIO_DEVICE_GET_INFO: - VFIO_DEVICE_GET_REGION_INFO - VFIO_DEVICE_RESETSigned-off-by: Nipun Gupta Reviewed-by: Pieter Jansen van Vuuren Tested-by: Nikhil Agarwal Link: https://lore.kernel.org/r/20230531124557.11009-1-nipun.gupta@amd.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/Makefile

8bee6f00 - vfio/platform: Cleanup Kconfig

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

vfio/platform: Cleanup KconfigLike vfio-pci, there's also a base module here where vfio-amba depends onvfio-platform, when really it only needs vfio-platform-base. Create asub-menu for platform drivers and a nested menu for reset drivers. CleanupMakefile to make use of new CONFIG_VFIO_PLATFORM_BASE for building theshared modules and traversing reset modules.Reviewed-by: Cédric Le Goater Reviewed-by: Eric Auger Link: https://lore.kernel.org/r/20230614193948.477036-3-alex.williamson@redhat.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/Makefile

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

e2d55709 - vfio: Fold vfio_virqfd.ko into vfio.ko

Mon, 05 Dec 2022 15:29:20 +0000

vfio: Fold vfio_virqfd.ko into vfio.koThis is only 1.8k, putting it in its own module is not reallynecessary. The kconfig infrastructure is still there to completely removeit for systems that are trying for small footprint.Put it in the main vfio.ko module now that kbuild can support multiple .cfiles.Signed-off-by: Jason Gunthorpe Reviewed-by: Cornelia Huck Link: https://lore.kernel.org/r/5-v5-fc5346cacfd4+4c482-vfio_modules_jgg@nvidia.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/Makefile

e276e258 - vfio: Move vfio_spapr_iommu_eeh_ioctl into vfio_iommu_spapr_tce.c

Mon, 05 Dec 2022 15:29:18 +0000

vfio: Move vfio_spapr_iommu_eeh_ioctl into vfio_iommu_spapr_tce.cAs with the previous patch EEH is always enabled if SPAPR_TCE_IOMMU, somove this last bit of code into the main module.Now that this function only processes VFIO_EEH_PE_OP remove a level ofindenting as well, it is only called by a case statement that alreadychecked VFIO_EEH_PE_OP.This eliminates an unnecessary module and SPAPR code in a global header.Reviewed-by: Christoph Hellwig Reviewed-by: Cornelia Huck Signed-off-by: Jason Gunthorpe Link: https://lore.kernel.org/r/3-v5-fc5346cacfd4+4c482-vfio_modules_jgg@nvidia.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/Makefile

9eefba80 - vfio: Move vfio group specific code into group.c

Fri, 25 Nov 2022 11:26:42 +0000

vfio: Move vfio group specific code into group.cThis prepares for compiling out vfio group after vfio device cdev isadded. No vfio_group decode code should be in vfio_main.c, and neitherdevice->group reference should be in vfio_main.c.No functional change is intended.Link: https://lore.kernel.org/r/20221201145535.589687-11-yi.l.liu@intel.comReviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Reviewed-by: Alex Williamson Tested-by: Yu He Tested-by: Lixiao Yang Signed-off-by: Yi Liu Signed-off-by: Jason Gunthorpe List of files: /linux-6.15/drivers/vfio/Makefile

e5a9ec7e - vfio: Make vfio_container optionally compiled

Tue, 29 Nov 2022 20:31:54 +0000

vfio: Make vfio_container optionally compiledAdd a kconfig CONFIG_VFIO_CONTAINER that controls compiling the containercode. If 'n' then only iommufd will provide the container service. All thesupport for vfio iommu drivers, including type1, will not be built.This allows a compilation check that no inappropriate dependencies betweenthe device/group and container have been created.Link: https://lore.kernel.org/r/9-v4-42cd2eb0e3eb+335a-vfio_iommufd_jgg@nvidia.comReviewed-by: Kevin Tian Reviewed-by: Alex Williamson Tested-by: Alex Williamson Tested-by: Nicolin Chen Tested-by: Yi Liu Tested-by: Lixiao Yang Tested-by: Matthew Rosato Tested-by: Yu He Signed-off-by: Jason Gunthorpe List of files: /linux-6.15/drivers/vfio/Makefile

a4d1f91d - vfio-iommufd: Support iommufd for physical VFIO devices

Tue, 29 Nov 2022 20:31:51 +0000

vfio-iommufd: Support iommufd for physical VFIO devicesThis creates the iommufd_device for the physical VFIO drivers. These areall the drivers that are calling vfio_register_group_dev() and expect thetype1 code to setup a real iommu_domain against their parent structdevice.The design gives the driver a choice in how it gets connected to iommufdby providing bind_iommufd/unbind_iommufd/attach_ioas callbacks toimplement as required. The core code provides three default callbacks forphysical mode using a real iommu_domain. This is suitable for driversusing vfio_register_group_dev()Link: https://lore.kernel.org/r/6-v4-42cd2eb0e3eb+335a-vfio_iommufd_jgg@nvidia.comReviewed-by: Kevin Tian Reviewed-by: Alex Williamson Tested-by: Alex Williamson Tested-by: Nicolin Chen Tested-by: Yi Liu Tested-by: Lixiao Yang Tested-by: Matthew Rosato Tested-by: Yu He Signed-off-by: Jason Gunthorpe List of files: /linux-6.15/drivers/vfio/Makefile

cdc71fe4 - vfio: Move container code into drivers/vfio/container.c

Thu, 22 Sep 2022 19:20:26 +0000

vfio: Move container code into drivers/vfio/container.cAll the functions that dereference struct vfio_container are moved intocontainer.c.Simple code motion, no functional change.Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Link: https://lore.kernel.org/r/8-v3-297af71838d2+b9-vfio_container_split_jgg@nvidia.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/Makefile

58ccf019 - vfio: Add an IOVA bitmap support

Thu, 08 Sep 2022 18:34:42 +0000

vfio: Add an IOVA bitmap supportThe new facility adds a bunch of wrappers that abstract how an IOVA rangeis represented in a bitmap that is granulated by a given page_size. So ittranslates all the lifting of dealing with user pointers into itscorresponding kernel addresses backing said user memory into doing finallythe (non-atomic) bitmap ops to change various bits.The formula for the bitmap is: data[(iova / page_size) / 64] & (1ULL << (iova % 64))Where 64 is the number of bits in a unsigned long (depending on arch)It introduces an IOVA iterator that uses a windowing scheme to minimize thepinning overhead, as opposed to pinning it on demand 4K at a time. Assuminga 4K kernel page and 4K requested page size, we can use a single kernelpage to hold 512 page pointers, mapping 2M of bitmap, representing 64G ofIOVA space.An example usage of these helpers for a given @base_iova, @page_size,@length and __user @data: bitmap = iova_bitmap_alloc(base_iova, page_size, length, data); if (IS_ERR(bitmap)) return -ENOMEM; ret = iova_bitmap_for_each(bitmap, arg, dirty_reporter_fn); iova_bitmap_free(bitmap);Each iteration of the @dirty_reporter_fn is called with a unique @iovaand @length argument, indicating the current range available through theiova_bitmap. The @dirty_reporter_fn uses iova_bitmap_set() to mark dirtyareas (@iova_length) within that provided range, as following: iova_bitmap_set(bitmap, iova, iova_length);The facility is intended to be used for user bitmaps representing dirtiedIOVAs by IOMMU (via IOMMUFD) and PCI Devices (via vfio-pci).Signed-off-by: Joao Martins Signed-off-by: Yishai Hadas Link: https://lore.kernel.org/r/20220908183448.195262-5-yishaih@nvidia.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/Makefile

0f3e72b5 - vfio: Move vfio.c to vfio_main.c

Sun, 31 Jul 2022 12:54:56 +0000

vfio: Move vfio.c to vfio_main.cIf a source file has the same name as a module then kbuild only supportsa single source file in the module.Rename vfio.c to vfio_main.c so that we can have more that one .c filein vfio.ko.Signed-off-by: Jason Gunthorpe Signed-off-by: Yishai Hadas Link: https://lore.kernel.org/r/20220731125503.142683-5-yishaih@nvidia.comSigned-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/Makefile

fb1ff4c1 - vfio/fsl-mc: Add VFIO framework skeleton for fsl-mc devices

Mon, 05 Oct 2020 17:36:45 +0000

vfio/fsl-mc: Add VFIO framework skeleton for fsl-mc devicesDPAA2 (Data Path Acceleration Architecture) consists inmechanisms for processing Ethernet packets, queue management,accelerators, etc.The Management Complex (mc) is a hardware entity that manages the DPAA2hardware resources. It provides an object-based abstraction for softwaredrivers to use the DPAA2 hardware. The MC mediates operations such ascreate, discover, destroy of DPAA2 objects.The MC provides memory-mapped I/O command interfaces (MC portals) whichDPAA2 software drivers use to operate on DPAA2 objects.A DPRC is a container object that holds other types of DPAA2 objects.Each object in the DPRC is a Linux device and bound to a driver.The MC-bus driver is a platform driver (different from PCI or platformbus). The DPRC driver does runtime management of a bus instance. Itperforms the initial scan of the DPRC and handles changes in the DPRCconfiguration (adding/removing objects).All objects inside a container share the same hardware isolationcontext, meaning that only an entire DPRC can be assigned toa virtual machine.When a container is assigned to a virtual machine, all the objectswithin that container are assigned to that virtual machine.The DPRC container assigned to the virtual machine is not allowedto change contents (add/remove objects) by the guest. The restrictionis set by the host and enforced by the mc hardware.The DPAA2 objects can be directly assigned to the guest. Howeverthe MC portals (the memory mapped command interface to the MC) needto be emulated because there are commands that configure theinterrupts and the isolation IDs which are virtual in the guest.Example:echo vfio-fsl-mc > /sys/bus/fsl-mc/devices/dprc.2/driver_overrideecho dprc.2 > /sys/bus/fsl-mc/drivers/vfio-fsl-mc/bindThe dprc.2 is bound to the VFIO driver and all the objects withindprc.2 are going to be bound to the VFIO driver.This patch adds the infrastructure for VFIO support for fsl-mcdevices. Subsequent patches will add support for binding and secureassigning these devices using VFIO.More details about the DPAA2 objects can be found here:Documentation/networking/device_drivers/freescale/dpaa2/overview.rstSigned-off-by: Bharat Bhushan Signed-off-by: Diana Craciun Reviewed-by: Eric Auger Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/vfio/Makefile

7b96953b - vfio: Mediated device Core driver

Wed, 16 Nov 2016 20:46:13 +0000

vfio: Mediated device Core driverDesign for Mediated Device Driver:Main purpose of this driver is to provide a common interface for mediateddevice management that can be used by different drivers of differentdevices.This module provides a generic interface to create the device, add it tomediated bus, add device to IOMMU group and then add it to vfio group.Below is the high Level block diagram, with Nvidia, Intel and IBM devicesas example, since these are the devices which are going to actively usethis module as of now. +---------------+ | | | +-----------+ | mdev_register_driver() +--------------+ | | | +<------------------------+ __init() | | | mdev | | | | | | bus | +------------------------>+ |<-> VFIO user | | driver | | probe()/remove() | vfio_mdev.ko | APIs | | | | | | | +-----------+ | +--------------+ | | | MDEV CORE | | MODULE | | mdev.ko | | +-----------+ | mdev_register_device() +--------------+ | | | +<------------------------+ | | | | | | nvidia.ko |<-> physical | | | +------------------------>+ | device | | | | callback +--------------+ | | Physical | | | | device | | mdev_register_device() +--------------+ | | interface | |<------------------------+ | | | | | | i915.ko |<-> physical | | | +------------------------>+ | device | | | | callback +--------------+ | | | | | | | | mdev_register_device() +--------------+ | | | +<------------------------+ | | | | | | ccw_device.ko|<-> physical | | | +------------------------>+ | device | | | | callback +--------------+ | +-----------+ | +---------------+Core driver provides two types of registration interfaces:1. Registration interface for mediated bus driver:/** * struct mdev_driver - Mediated device's driver * @name: driver name * @probe: called when new device created * @remove:called when device removed * @driver:device driver structure * **/struct mdev_driver { const char *name; int (*probe) (struct device *dev); void (*remove) (struct device *dev); struct device_driver driver;};Mediated bus driver for mdev device should use this interface to registerand unregister with core driver respectively:int mdev_register_driver(struct mdev_driver *drv, struct module *owner);void mdev_unregister_driver(struct mdev_driver *drv);Mediated bus driver is responsible to add/delete mediated devices to/fromVFIO group when devices are bound and unbound to the driver.2. Physical device driver interfaceThis interface provides vendor driver the set APIs to manage physicaldevice related work in its driver. APIs are :* dev_attr_groups: attributes of the parent device.* mdev_attr_groups: attributes of the mediated device.* supported_type_groups: attributes to define supported type. This is mandatory field.* create: to allocate basic resources in vendor driver for a mediated device. This is mandatory to be provided by vendor driver.* remove: to free resources in vendor driver when mediated device is destroyed. This is mandatory to be provided by vendor driver.* open: open callback of mediated device* release: release callback of mediated device* read : read emulation callback.* write: write emulation callback.* ioctl: ioctl callback.* mmap: mmap emulation callback.Drivers should use these interfaces to register and unregister device tomdev core driver respectively:extern int mdev_register_device(struct device *dev, const struct parent_ops *ops);extern void mdev_unregister_device(struct device *dev);There are no locks to serialize above callbacks in mdev driver andvfio_mdev driver. If required, vendor driver can have locks to serializeabove APIs in their driver.Signed-off-by: Kirti Wankhede Signed-off-by: Neo Jia Reviewed-by: Jike Song Reviewed-by: Dong Jia Shi Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/Makefile

71be3423 - vfio: Split virqfd into a separate module for vfio bus drivers

Tue, 17 Mar 2015 14:33:38 +0000

vfio: Split virqfd into a separate module for vfio bus driversAn unintended consequence of commit 42ac9bd18d4f ("vfio: initializethe virqfd workqueue in VFIO generic code") is that the vfio moduleis renamed to vfio_core so that it can include both vfio and virqfd.That's a user visible change that may break module loading scritpsand it imposes eventfd support as a dependency on the core vfio code,which it's really not. virqfd is intended to be provided as a serviceto vfio bus drivers, so instead of wrapping it into vfio.ko, we canmake it a stand-alone module toggled by vfio bus drivers. This hasthe additional benefit of removing initialization and exit from thecore vfio code.Signed-off-by: Alex Williamson List of files: /linux-6.15/drivers/vfio/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/Makefile