26 May, 2016

1 commit

  • Pull VFIO updates from Alex Williamson:

    - Hide INTx on certain known broken devices (Alex Williamson)

    - Additional backdoor reset detection (Alex Williamson)

    - Remove unused iommudata reference (Alexey Kardashevskiy)

    - Use cfg_size to avoid probing extended config space (Alexey
    Kardashevskiy)

    * tag 'vfio-v4.7-rc1' of git://github.com/awilliam/linux-vfio:
    vfio_pci: Test for extended capabilities if config space > 256 bytes
    vfio_iommu_spapr_tce: Remove unneeded iommu_group_get_iommudata
    vfio/pci: Add test for BAR restore
    vfio/pci: Hide broken INTx support from user

    Linus Torvalds
     

21 May, 2016

1 commit

  • Pull powerpc updates from Michael Ellerman:
    "Highlights:
    - Support for Power ISA 3.0 (Power9) Radix Tree MMU from Aneesh Kumar K.V
    - Live patching support for ppc64le (also merged via livepatching.git)

    Various cleanups & minor fixes from:
    - Aaro Koskinen, Alexey Kardashevskiy, Andrew Donnellan, Aneesh Kumar K.V,
    Chris Smart, Daniel Axtens, Frederic Barrat, Gavin Shan, Ian Munsie,
    Lennart Sorensen, Madhavan Srinivasan, Mahesh Salgaonkar, Markus Elfring,
    Michael Ellerman, Oliver O'Halloran, Paul Gortmaker, Paul Mackerras,
    Rashmica Gupta, Russell Currey, Suraj Jitindar Singh, Thiago Jung
    Bauermann, Valentin Rothberg, Vipin K Parashar.

    General:
    - Update LMB associativity index during DLPAR add/remove from Nathan
    Fontenot
    - Fix branching to OOL handlers in relocatable kernel from Hari Bathini
    - Add support for userspace Power9 copy/paste from Chris Smart
    - Always use STRICT_MM_TYPECHECKS from Michael Ellerman
    - Add mask of possible MMU features from Michael Ellerman

    PCI:
    - Enable pass through of NVLink to guests from Alexey Kardashevskiy
    - Cleanups in preparation for powernv PCI hotplug from Gavin Shan
    - Don't report error in eeh_pe_reset_and_recover() from Gavin Shan
    - Restore initial state in eeh_pe_reset_and_recover() from Gavin Shan
    - Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell"
    from Guilherme G Piccoli
    - Remove the dependency on EEH struct in DDW mechanism from Guilherme
    G Piccoli

    selftests:
    - Test cp_abort during context switch from Chris Smart
    - Add several tests for transactional memory support from Rashmica
    Gupta

    perf:
    - Add support for sampling interrupt register state from Anju T
    - Add support for unwinding perf-stackdump from Chandan Kumar

    cxl:
    - Configure the PSL for two CAPI ports on POWER8NVL from Philippe
    Bergheaud
    - Allow initialization on timebase sync failures from Frederic Barrat
    - Increase timeout for detection of AFU mmio hang from Frederic
    Barrat
    - Handle num_of_processes larger than can fit in the SPA from Ian
    Munsie
    - Ensure PSL interrupt is configured for contexts with no AFU IRQs
    from Ian Munsie
    - Add kernel API to allow a context to operate with relocate disabled
    from Ian Munsie
    - Check periodically the coherent platform function's state from
    Christophe Lombard

    Freescale:
    - Updates from Scott: "Contains 86xx fixes, minor device tree fixes,
    an erratum workaround, and a kconfig dependency fix."

    * tag 'powerpc-4.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: (192 commits)
    powerpc/86xx: Fix PCI interrupt map definition
    powerpc/86xx: Move pci1 definition to the include file
    powerpc/fsl: Fix build of the dtb embedded kernel images
    powerpc/fsl: Fix rcpm compatible string
    powerpc/fsl: Remove FSL_SOC dependency from FSL_LBC
    powerpc/fsl-pci: Add a workaround for PCI 5 errata
    powerpc/fsl: Fix SPI compatible on t208xrdb and t1040rdb
    powerpc/powernv/npu: Add PE to PHB's list
    powerpc/powernv: Fix insufficient memory allocation
    powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism
    Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell"
    powerpc/eeh: Drop unnecessary label in eeh_pe_change_owner()
    powerpc/eeh: Ignore handlers in eeh_pe_reset_and_recover()
    powerpc/eeh: Restore initial state in eeh_pe_reset_and_recover()
    powerpc/eeh: Don't report error in eeh_pe_reset_and_recover()
    Revert "powerpc/powernv: Exclude root bus in pnv_pci_reset_secondary_bus()"
    powerpc/powernv/npu: Enable NVLink pass through
    powerpc/powernv/npu: Rework TCE Kill handling
    powerpc/powernv/npu: Add set/unset window helpers
    powerpc/powernv/ioda2: Export debug helper pe_level_printk()
    ...

    Linus Torvalds
     

20 May, 2016

1 commit

  • PCI-Express spec says that reading 4 bytes at offset 100h should return
    zero if there is no extended capability so VFIO reads this dword to
    know if there are extended capabilities.

    However it is not always possible to access the extended space so
    generic PCI code in pci_cfg_space_size_ext() checks if
    pci_read_config_dword() can read beyond 100h and if the check fails,
    it sets the config space size to 100h.

    VFIO does its own extended capabilities check by reading at offset 100h
    which may produce 0xffffffff which VFIO treats as the extended config
    space presense and calls vfio_ecap_init() which fails to parse
    capabilities (which is expected) but right before the exit, it writes
    zero at offset 100h which is beyond the buffer allocated for
    vdev->vconfig (which is 256 bytes) which leads to random memory
    corruption.

    This makes VFIO only check for the extended capabilities if
    the discovered config size is more than 256 bytes.

    Signed-off-by: Alexey Kardashevskiy
    Signed-off-by: Alex Williamson

    Alexey Kardashevskiy
     

11 May, 2016

1 commit

  • We are going to have multiple different types of PHB on the same system
    with POWER8 + NVLink and PHBs will have different IOMMU ops. However
    we only really care about one callback - create_table - so we can
    relax the compatibility check here.

    Signed-off-by: Alexey Kardashevskiy
    Reviewed-by: David Gibson
    Acked-by: Alex Williamson
    Signed-off-by: Michael Ellerman

    Alexey Kardashevskiy
     

09 May, 2016

1 commit

  • Many IOMMUs support multiple page table formats, meaning that any given
    domain may only support a subset of the hardware page sizes presented in
    iommu_ops->pgsize_bitmap. There are also certain use-cases where the
    creator of a domain may want to control which page sizes are used, for
    example to force the use of hugepage mappings to reduce pagetable walk
    depth.

    To this end, add a per-domain pgsize_bitmap to represent the subset of
    page sizes actually in use, to make it possible for domains with
    different requirements to coexist.

    Signed-off-by: Will Deacon
    [rm: hijacked and rebased original patch with new commit message]
    Signed-off-by: Robin Murphy
    Acked-by: Will Deacon
    Signed-off-by: Joerg Roedel

    Robin Murphy
     

29 Apr, 2016

3 commits

  • This removes iommu_group_get_iommudata() as the result is never used.
    As this is a minor cleanup, no change in behavior is expected.

    Signed-off-by: Alexey Kardashevskiy
    Reviewed-by: David Gibson
    Signed-off-by: Alex Williamson

    Alexey Kardashevskiy
     
  • If a device is reset without the memory or i/o bits enabled in the
    command register we may not detect it, potentially leaving the device
    without valid BAR programming. Add an additional test to check the
    BARs on each write to the command register.

    Signed-off-by: Alex Williamson

    Alex Williamson
     
  • INTx masking has two components, the first is that we need the ability
    to prevent the device from continuing to assert INTx. This is
    provided via the DisINTx bit in the command register and is the only
    thing we can really probe for when testing if INTx masking is
    supported. The second component is that the device needs to indicate
    if INTx is asserted via the interrupt status bit in the device status
    register. With these two features we can generically determine if one
    of the devices we own is asserting INTx, signal the user, and mask the
    interrupt while the user services the device.

    Generally if one or both of these components is broken we resort to
    APIC level interrupt masking, which requires an exclusive interrupt
    since we have no way to determine the source of the interrupt in a
    shared configuration. This often makes it difficult or impossible to
    configure the system for userspace use of the device, for an interrupt
    mode that the user may not need.

    One possible configuration of broken INTx masking is that the DisINTx
    support is fully functional, but the interrupt status bit never
    signals interrupt assertion. In this case we do have the ability to
    prevent the device from asserting INTx, but lack the ability to
    identify the interrupt source. For this case we can simply pretend
    that the device lacks INTx support entirely, keeping DisINTx set on
    the physical device, virtualizing this bit for the user, and
    virtualizing the interrupt pin register to indicate no INTx support.
    We already support virtualization of the DisINTx bit and already
    virtualize the interrupt pin for platforms without INTx support. By
    tying these components together, setting DisINTx on open and reset,
    and identifying devices broken in this particular way, we can provide
    support for them w/o the handicap of APIC level INTx masking.

    Intel i40e (XL710/X710) 10/20/40GbE NICs have been identified as being
    broken in this specific way. We leave the vfio-pci.nointxmask option
    as a mechanism to bypass this support, enabling INTx on the device
    with all the requirements of APIC level masking.

    Signed-off-by: Alex Williamson
    Cc: John Ronciak
    Cc: Jesse Brandeburg

    Alex Williamson
     

18 Mar, 2016

1 commit

  • Pull VFIO updates from Alex Williamson:
    "Various enablers for assignment of Intel graphics devices and future
    support of vGPU devices (Alex Williamson). This includes

    - Handling the vfio type1 interface as an API rather than a specific
    implementation, allowing multiple type1 providers.

    - Capability chains, similar to PCI device capabilities, that allow
    extending ioctls. Extensions here include device specific regions
    and sparse mmap descriptions. The former is used to expose non-PCI
    regions for IGD, including the OpRegion (particularly the Video
    BIOS Table), and read only PCI config access to the host and LPC
    bridge as drivers often depend on identifying those devices.

    Sparse mmaps here are used to describe the MSIx vector table, which
    vfio has always protected from mmap, but never had an API to
    explicitly define that protection. In future vGPU support this is
    expected to allow the description of PCI BARs that may mix direct
    access and emulated access within a single region.

    - The ability to expose the shadow ROM as an option ROM as IGD use
    cases may rely on the ROM even though the physical device does not
    make use of a PCI option ROM BAR"

    * tag 'vfio-v4.6-rc1' of git://github.com/awilliam/linux-vfio:
    vfio/pci: return -EFAULT if copy_to_user fails
    vfio/pci: Expose shadow ROM as PCI option ROM
    vfio/pci: Intel IGD host and LCP bridge config space access
    vfio/pci: Intel IGD OpRegion support
    vfio/pci: Enable virtual register in PCI config space
    vfio/pci: Add infrastructure for additional device specific regions
    vfio: Define device specific region type capability
    vfio/pci: Include sparse mmap capability for MSI-X table regions
    vfio: Define sparse mmap capability for regions
    vfio: Add capability chain helpers
    vfio: Define capability chains
    vfio: If an IOMMU backend fails, keep looking
    vfio/pci: Fix unsigned comparison overflow

    Linus Torvalds
     

28 Feb, 2016

1 commit

  • Calling return copy_to_user(...) in an ioctl will not
    do the right thing if there's a pagefault:
    copy_to_user returns the number of bytes not copied
    in this case.

    Fix up vfio to do
    return copy_to_user(...)) ?
    -EFAULT : 0;

    everywhere.

    Cc: stable@vger.kernel.org
    Signed-off-by: Michael S. Tsirkin
    Signed-off-by: Alex Williamson

    Michael S. Tsirkin
     

26 Feb, 2016

1 commit


23 Feb, 2016

9 commits

  • Integrated graphics may have their ROM shadowed at 0xc0000 rather than
    implement a PCI option ROM. Make this ROM appear to the user using
    the ROM BAR.

    Signed-off-by: Alex Williamson

    Alex Williamson
     
  • Provide read-only access to PCI config space of the PCI host bridge
    and LPC bridge through device specific regions. This may be used to
    configure a VM with matching register contents to satisfy driver
    requirements. Providing this through the vfio file descriptor removes
    an additional userspace requirement for access through pci-sysfs and
    removes the CAP_SYS_ADMIN requirement that doesn't appear to apply to
    the specific devices we're accessing.

    Signed-off-by: Alex Williamson

    Alex Williamson
     
  • This 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

    Alex Williamson
     
  • Typically config space for a device is mapped out into capability
    specific handlers and unassigned space. The latter allows direct
    read/write access to config space. Sometimes we know about registers
    living in this void space and would like an easy way to virtualize
    them, similar to how BAR registers are managed. To do this, create
    one more pseudo (fake) PCI capability to be handled as purely virtual
    space. Reads and writes are serviced entirely from virtual config
    space.

    Signed-off-by: Alex Williamson

    Alex Williamson
     
  • Add support for additional regions with indexes started after the
    already defined fixed regions. Device specific code can register
    these regions with the new vfio_pci_register_dev_region() function.
    The ops structure per region currently only includes read/write
    access and a release function, allowing automatic cleanup when the
    device is closed. mmap support is only missing here because it's
    not needed by the first user queued for this support.

    Signed-off-by: Alex Williamson

    Alex Williamson
     
  • vfio-pci has never allowed the user to directly mmap the MSI-X vector
    table, but we've always relied on implicit knowledge of the user that
    they cannot do this. Now that we have capability chains that we can
    expose in the region info ioctl and a sparse mmap capability that
    represents the sub-areas within the region that can be mmap'd, we can
    make the mmap constraints more explicit.

    Signed-off-by: Alex Williamson

    Alex Williamson
     
  • Allow sub-modules to easily reallocate a buffer for managing
    capability chains for info ioctls.

    Signed-off-by: Alex Williamson

    Alex Williamson
     
  • Consider an IOMMU to be an API rather than an implementation, we might
    have multiple implementations supporting the same API, so try another
    if one fails. The expectation here is that we'll really only have
    one implementation per device type. For instance the existing type1
    driver works with any PCI device where the IOMMU API is available. A
    vGPU vendor may have a virtual PCI device which provides DMA isolation
    and mapping through other mechanisms, but can re-use userspaces that
    make use of the type1 VFIO IOMMU API. This allows that to work.

    Signed-off-by: Alex Williamson

    Alex Williamson
     
  • Signed versus unsigned comparisons are implicitly cast to unsigned,
    which result in a couple possible overflows. For instance (start +
    count) might overflow and wrap, getting through our validation test.
    Also when unwinding setup, -1 being compared as unsigned doesn't
    produce the intended stop condition. Fix both of these and also fix
    vfio_msi_set_vector_signal() to validate parameters before using the
    vector index, though none of the callers should pass bad indexes
    anymore.

    Reported-by: Eric Auger
    Reviewed-by: Eric Auger
    Tested-by: Eric Auger
    Signed-off-by: Alex Williamson

    Alex Williamson
     

28 Jan, 2016

1 commit

  • Using iommu_present() to determine whether an IOMMU group is real or
    fake has some problems. First, apparently Power systems don't
    register an IOMMU on the device bus, so the groups and containers get
    marked as noiommu and then won't bind to their actual IOMMU driver.
    Second, I expect we'll run into the same issue as we try to support
    vGPUs through vfio, since they're likely to emulate this behavior of
    creating an IOMMU group on a virtual device and then providing a vfio
    IOMMU backend tailored to the sort of isolation they provide, which
    won't necessarily be fully compatible with the IOMMU API.

    The solution here is to use the existing iommudata interface to IOMMU
    groups, which allows us to easily identify the fake groups we've
    created for noiommu purposes. The iommudata we set is purely
    arbitrary since we're only comparing the address, so we use the
    address of the noiommu switch itself.

    Reported-by: Alexey Kardashevskiy
    Reviewed-by: Alexey Kardashevskiy
    Tested-by: Alexey Kardashevskiy
    Tested-by: Anatoly Burakov
    Tested-by: Santosh Shukla
    Fixes: 03a76b60f8ba ("vfio: Include No-IOMMU mode")
    Signed-off-by: Alex Williamson

    Alex Williamson
     

05 Jan, 2016

1 commit

  • The flags entry is there to tell the user that some
    optional information is available.

    Since we report the iova_pgsizes signal it to the user
    by setting the flags to VFIO_IOMMU_INFO_PGSIZES.

    Signed-off-by: Pierre Morel
    Signed-off-by: Alex Williamson

    Pierre Morel
     

22 Dec, 2015

2 commits

  • There is really no way to safely give a user full access to a DMA
    capable device without an IOMMU to protect the host system. There is
    also no way to provide DMA translation, for use cases such as device
    assignment to virtual machines. However, there are still those users
    that want userspace drivers even under those conditions. The UIO
    driver exists for this use case, but does not provide the degree of
    device access and programming that VFIO has. In an effort to avoid
    code duplication, this introduces a No-IOMMU mode for VFIO.

    This mode requires building VFIO with CONFIG_VFIO_NOIOMMU and enabling
    the "enable_unsafe_noiommu_mode" option on the vfio driver. This
    should make it very clear that this mode is not safe. Additionally,
    CAP_SYS_RAWIO privileges are necessary to work with groups and
    containers using this mode. Groups making use of this support are
    named /dev/vfio/noiommu-$GROUP and can only make use of the special
    VFIO_NOIOMMU_IOMMU for the container. Use of this mode, specifically
    binding a device without a native IOMMU group to a VFIO bus driver
    will taint the kernel and should therefore not be considered
    supported. This patch includes no-iommu support for the vfio-pci bus
    driver only.

    Signed-off-by: Alex Williamson
    Acked-by: Michael S. Tsirkin

    Alex Williamson
     
  • This loop ends with count set to -1 and not zero so the warning message
    isn't printed when it should be. I've fixed this by change the postop
    to a preop.

    Fixes: 0990822c9866 ('VFIO: platform: reset: AMD xgbe reset module')
    Signed-off-by: Dan Carpenter
    Reviewed-by: Eric Auger
    Signed-off-by: Alex Williamson

    Dan Carpenter
     

04 Dec, 2015

1 commit

  • Revert commit 033291eccbdb ("vfio: Include No-IOMMU mode") due to lack
    of a user. This was originally intended to fill a need for the DPDK
    driver, but uptake has been slow so rather than support an unproven
    kernel interface revert it and revisit when userspace catches up.

    Signed-off-by: Alex Williamson

    Alex Williamson
     

21 Nov, 2015

2 commits


20 Nov, 2015

2 commits


14 Nov, 2015

1 commit

  • Pull VFIO updates from Alex Williamson:
    - Use kernel interfaces for VPD emulation (Alex Williamson)
    - Platform fix for releasing IRQs (Eric Auger)
    - Type1 IOMMU always advertises PAGE_SIZE support when smaller mapping
    sizes are available (Eric Auger)
    - Platform fixes for incorrectly using copies of structures rather than
    pointers to structures (James Morse)
    - Rework platform reset modules, fix leak, and add AMD xgbe reset
    module (Eric Auger)
    - Fix vfio_device_get_from_name() return value (Joerg Roedel)
    - No-IOMMU interface (Alex Williamson)
    - Fix potential out of bounds array access in PCI config handling (Dan
    Carpenter)

    * tag 'vfio-v4.4-rc1' of git://github.com/awilliam/linux-vfio:
    vfio/pci: make an array larger
    vfio: Include No-IOMMU mode
    vfio: Fix bug in vfio_device_get_from_name()
    VFIO: platform: reset: AMD xgbe reset module
    vfio: platform: reset: calxedaxgmac: fix ioaddr leak
    vfio: platform: add dev_info on device reset
    vfio: platform: use list of registered reset function
    vfio: platform: add compat in vfio_platform_device
    vfio: platform: reset: calxedaxgmac: add reset function registration
    vfio: platform: introduce module_vfio_reset_handler macro
    vfio: platform: add capability to register a reset function
    vfio: platform: introduce vfio-platform-base module
    vfio/platform: store mapped memory in region, instead of an on-stack copy
    vfio/type1: handle case where IOMMU does not support PAGE_SIZE size
    VFIO: platform: clear IRQ_NOAUTOEN when de-assigning the IRQ
    vfio/pci: Use kernel VPD access functions
    vfio: Whitelist PCI bridges

    Linus Torvalds
     

09 Nov, 2015

1 commit


05 Nov, 2015

2 commits

  • There is really no way to safely give a user full access to a DMA
    capable device without an IOMMU to protect the host system. There is
    also no way to provide DMA translation, for use cases such as device
    assignment to virtual machines. However, there are still those users
    that want userspace drivers even under those conditions. The UIO
    driver exists for this use case, but does not provide the degree of
    device access and programming that VFIO has. In an effort to avoid
    code duplication, this introduces a No-IOMMU mode for VFIO.

    This mode requires building VFIO with CONFIG_VFIO_NOIOMMU and enabling
    the "enable_unsafe_noiommu_mode" option on the vfio driver. This
    should make it very clear that this mode is not safe. Additionally,
    CAP_SYS_RAWIO privileges are necessary to work with groups and
    containers using this mode. Groups making use of this support are
    named /dev/vfio/noiommu-$GROUP and can only make use of the special
    VFIO_NOIOMMU_IOMMU for the container. Use of this mode, specifically
    binding a device without a native IOMMU group to a VFIO bus driver
    will taint the kernel and should therefore not be considered
    supported. This patch includes no-iommu support for the vfio-pci bus
    driver only.

    Signed-off-by: Alex Williamson
    Acked-by: Michael S. Tsirkin

    Alex Williamson
     
  • The vfio_device_get_from_name() function might return a
    non-NULL pointer, when called with a device name that is not
    found in the list. This causes undefined behavior, in my
    case calling an invalid function pointer later on:

    kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
    BUG: unable to handle kernel paging request at ffff8800cb3ddc08

    [...]

    Call Trace:
    [] ? vfio_group_fops_unl_ioctl+0x253/0x410 [vfio]
    [] do_vfs_ioctl+0x2cd/0x4c0
    [] ? __fget+0x77/0xb0
    [] SyS_ioctl+0x79/0x90
    [] ? syscall_return_slowpath+0x50/0x130
    [] entry_SYSCALL_64_fastpath+0x16/0x75

    Fix the issue by returning NULL when there is no device with
    the requested name in the list.

    Cc: stable@vger.kernel.org # v4.2+
    Fixes: 4bc94d5dc95d ("vfio: Fix lockdep issue")
    Signed-off-by: Joerg Roedel
    Signed-off-by: Alex Williamson

    Joerg Roedel
     

04 Nov, 2015

7 commits

  • This patch introduces a module that registers and implements a low-level
    reset function for the AMD XGBE device.

    it performs the following actions:
    - reset the PHY
    - disable auto-negotiation
    - disable & clear auto-negotiation IRQ
    - soft-reset the MAC

    Those tiny pieces of code are inherited from the native xgbe driver.

    Signed-off-by: Eric Auger
    Reviewed-by: Arnd Bergmann
    Signed-off-by: Alex Williamson

    Eric Auger
     
  • In the current code the vfio_platform_region is copied on the stack.
    As a consequence the ioaddr address is not iounmapped in the vfio
    platform driver (vfio_platform_regions_cleanup). The patch uses the
    pointer to the region instead.

    Signed-off-by: Eric Auger
    Signed-off-by: Alex Williamson

    Eric Auger
     
  • It might be helpful for the end-user to check the device reset
    function was found by the vfio platform reset framework.

    Lets store a pointer to the struct device in vfio_platform_device
    and trace when the reset function is called or not found.

    Signed-off-by: Eric Auger
    Signed-off-by: Alex Williamson

    Eric Auger
     
  • Remove the static lookup table and use the dynamic list of registered
    reset functions instead. Also load the reset module through its alias.
    The reset struct module pointer is stored in vfio_platform_device.

    We also remove the useless struct device pointer parameter in
    vfio_platform_get_reset.

    This patch fixes the issue related to the usage of __symbol_get, which
    besides from being moot, prevented compilation with CONFIG_MODULES
    disabled.

    Also usage of MODULE_ALIAS makes possible to add a new reset module
    without needing to update the framework. This was suggested by Arnd.

    Signed-off-by: Eric Auger
    Reported-by: Arnd Bergmann
    Reviewed-by: Arnd Bergmann
    Signed-off-by: Alex Williamson

    Eric Auger
     
  • Let's retrieve the compatibility string on probe and store it
    in the vfio_platform_device struct

    Signed-off-by: Eric Auger
    Signed-off-by: Alex Williamson

    Eric Auger
     
  • This patch adds the reset function registration/unregistration.
    This is handled through the module_vfio_reset_handler macro. This
    latter also defines a MODULE_ALIAS which simplifies the load from
    vfio-platform.

    Signed-off-by: Eric Auger
    Reviewed-by: Arnd Bergmann
    Signed-off-by: Alex Williamson

    Eric Auger
     
  • The module_vfio_reset_handler macro
    - define a module alias
    - implement module init/exit function which respectively registers
    and unregisters the reset function.

    Signed-off-by: Eric Auger
    Reviewed-by: Arnd Bergmann
    Signed-off-by: Alex Williamson

    Eric Auger