2019-06-04 11:11:33 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2012-07-31 18:16:24 +04:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2012 Red Hat, Inc. All rights reserved.
|
|
|
|
|
* Author: Alex Williamson <alex.williamson@redhat.com>
|
|
|
|
|
*
|
|
|
|
|
* Derived from original vfio:
|
|
|
|
|
* Copyright 2010 Cisco Systems, Inc. All rights reserved.
|
|
|
|
|
* Author: Tom Lyon, pugs@cisco.com
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/mutex.h>
|
|
|
|
|
#include <linux/pci.h>
|
2021-08-26 13:39:04 +03:00
|
|
|
#include <linux/vfio.h>
|
2015-09-18 17:29:50 +03:00
|
|
|
#include <linux/irqbypass.h>
|
2016-02-23 02:02:39 +03:00
|
|
|
#include <linux/types.h>
|
vfio/pci: Introduce VF token
If we enable SR-IOV on a vfio-pci owned PF, the resulting VFs are not
fully isolated from the PF. The PF can always cause a denial of service
to the VF, even if by simply resetting itself. The degree to which a PF
can access the data passed through a VF or interfere with its operation
is dependent on a given SR-IOV implementation. Therefore we want to
avoid a scenario where an existing vfio-pci based userspace driver might
assume the PF driver is trusted, for example assigning a PF to one VM
and VF to another with some expectation of isolation. IOMMU grouping
could be a solution to this, but imposes an unnecessarily strong
relationship between PF and VF drivers if they need to operate with the
same IOMMU context. Instead we introduce a "VF token", which is
essentially just a shared secret between PF and VF drivers, implemented
as a UUID.
The VF token can be set by a vfio-pci based PF driver and must be known
by the vfio-pci based VF driver in order to gain access to the device.
This allows the degree to which this VF token is considered secret to be
determined by the applications and environment. For example a VM might
generate a random UUID known only internally to the hypervisor while a
userspace networking appliance might use a shared, or even well know,
UUID among the application drivers.
To incorporate this VF token, the VFIO_GROUP_GET_DEVICE_FD interface is
extended to accept key=value pairs in addition to the device name. This
allows us to most easily deny user access to the device without risk
that existing userspace drivers assume region offsets, IRQs, and other
device features, leading to more elaborate error paths. The format of
these options are expected to take the form:
"$DEVICE_NAME $OPTION1=$VALUE1 $OPTION2=$VALUE2"
Where the device name is always provided first for compatibility and
additional options are specified in a space separated list. The
relation between and requirements for the additional options will be
vfio bus driver dependent, however unknown or unused option within this
schema should return error. This allow for future use of unknown
options as well as a positive indication to the user that an option is
used.
An example VF token option would take this form:
"0000:03:00.0 vf_token=2ab74924-c335-45f4-9b16-8569e5b08258"
When accessing a VF where the PF is making use of vfio-pci, the user
MUST provide the current vf_token. When accessing a PF, the user MUST
provide the current vf_token IF there are active VF users or MAY provide
a vf_token in order to set the current VF token when no VF users are
active. The former requirement assures VF users that an unassociated
driver cannot usurp the PF device. These semantics also imply that a
VF token MUST be set by a PF driver before VF drivers can access their
device, the default token is random and mechanisms to read the token are
not provided in order to protect the VF token of previous users. Use of
the vf_token option outside of these cases will return an error, as
discussed above.
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-03-24 18:28:27 +03:00
|
|
|
#include <linux/uuid.h>
|
2020-03-24 18:28:28 +03:00
|
|
|
#include <linux/notifier.h>
|
2012-07-31 18:16:24 +04:00
|
|
|
|
2021-08-26 13:39:01 +03:00
|
|
|
#ifndef VFIO_PCI_CORE_H
|
|
|
|
|
#define VFIO_PCI_CORE_H
|
2012-07-31 18:16:24 +04:00
|
|
|
|
|
|
|
|
#define VFIO_PCI_OFFSET_SHIFT 40
|
|
|
|
|
#define VFIO_PCI_OFFSET_TO_INDEX(off) (off >> VFIO_PCI_OFFSET_SHIFT)
|
|
|
|
|
#define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) << VFIO_PCI_OFFSET_SHIFT)
|
|
|
|
|
#define VFIO_PCI_OFFSET_MASK (((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
|
|
|
|
|
|
2021-08-26 13:39:02 +03:00
|
|
|
struct vfio_pci_core_device;
|
2016-02-23 02:02:39 +03:00
|
|
|
struct vfio_pci_region;
|
|
|
|
|
|
|
|
|
|
struct vfio_pci_regops {
|
2021-08-26 13:39:02 +03:00
|
|
|
ssize_t (*rw)(struct vfio_pci_core_device *vdev, char __user *buf,
|
2016-02-23 02:02:39 +03:00
|
|
|
size_t count, loff_t *ppos, bool iswrite);
|
2021-08-26 13:39:02 +03:00
|
|
|
void (*release)(struct vfio_pci_core_device *vdev,
|
2016-02-23 02:02:39 +03:00
|
|
|
struct vfio_pci_region *region);
|
2021-08-26 13:39:02 +03:00
|
|
|
int (*mmap)(struct vfio_pci_core_device *vdev,
|
2018-12-19 11:52:30 +03:00
|
|
|
struct vfio_pci_region *region,
|
|
|
|
|
struct vm_area_struct *vma);
|
2021-08-26 13:39:02 +03:00
|
|
|
int (*add_capability)(struct vfio_pci_core_device *vdev,
|
2018-12-19 11:52:31 +03:00
|
|
|
struct vfio_pci_region *region,
|
|
|
|
|
struct vfio_info_cap *caps);
|
2016-02-23 02:02:39 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct vfio_pci_region {
|
|
|
|
|
u32 type;
|
|
|
|
|
u32 subtype;
|
|
|
|
|
const struct vfio_pci_regops *ops;
|
|
|
|
|
void *data;
|
|
|
|
|
size_t size;
|
|
|
|
|
u32 flags;
|
|
|
|
|
};
|
|
|
|
|
|
2021-08-26 13:39:02 +03:00
|
|
|
struct vfio_pci_core_device {
|
2021-03-30 18:53:07 +03:00
|
|
|
struct vfio_device vdev;
|
2012-07-31 18:16:24 +04:00
|
|
|
struct pci_dev *pdev;
|
2019-09-28 02:43:08 +03:00
|
|
|
void __iomem *barmap[PCI_STD_NUM_BARS];
|
|
|
|
|
bool bar_mmap_supported[PCI_STD_NUM_BARS];
|
2012-07-31 18:16:24 +04:00
|
|
|
u8 *pci_config_map;
|
|
|
|
|
u8 *vconfig;
|
|
|
|
|
struct perm_bits *msi_perm;
|
|
|
|
|
spinlock_t irqlock;
|
|
|
|
|
struct mutex igate;
|
|
|
|
|
struct vfio_pci_irq_ctx *ctx;
|
|
|
|
|
int num_ctx;
|
|
|
|
|
int irq_type;
|
2016-02-23 02:02:39 +03:00
|
|
|
int num_regions;
|
|
|
|
|
struct vfio_pci_region *region;
|
2012-07-31 18:16:24 +04:00
|
|
|
u8 msi_qmax;
|
|
|
|
|
u8 msix_bar;
|
|
|
|
|
u16 msix_size;
|
|
|
|
|
u32 msix_offset;
|
|
|
|
|
u32 rbar[7];
|
|
|
|
|
bool pci_2_3;
|
|
|
|
|
bool virq_disabled;
|
|
|
|
|
bool reset_works;
|
|
|
|
|
bool extended_caps;
|
|
|
|
|
bool bardirty;
|
2013-02-18 21:11:13 +04:00
|
|
|
bool has_vga;
|
2014-08-07 21:12:07 +04:00
|
|
|
bool needs_reset;
|
vfio/pci: Hide broken INTx support from user
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 <alex.williamson@redhat.com>
Cc: John Ronciak <john.ronciak@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
2016-03-24 22:05:18 +03:00
|
|
|
bool nointx;
|
2019-02-09 23:43:30 +03:00
|
|
|
bool needs_pm_restore;
|
vfio/pci: Mask INTx during runtime suspend
This patch adds INTx handling during runtime suspend/resume.
All the suspend/resume related code for the user to put the device
into the low power state will be added in subsequent patches.
The INTx lines may be shared among devices. Whenever any INTx
interrupt comes for the VFIO devices, then vfio_intx_handler() will be
called for each device sharing the interrupt. Inside vfio_intx_handler(),
it calls pci_check_and_mask_intx() and checks if the interrupt has
been generated for the current device. Now, if the device is already
in the D3cold state, then the config space can not be read. Attempt
to read config space in D3cold state can cause system unresponsiveness
in a few systems. To prevent this, mask INTx in runtime suspend callback,
and unmask the same in runtime resume callback. If INTx has been already
masked, then no handling is needed in runtime suspend/resume callbacks.
'pm_intx_masked' tracks this, and vfio_pci_intx_mask() has been updated
to return true if the INTx vfio_pci_irq_ctx.masked value is changed
inside this function.
For the runtime suspend which is triggered for the no user of VFIO
device, the 'irq_type' will be VFIO_PCI_NUM_IRQS and these
callbacks won't do anything.
The MSI/MSI-X are not shared so similar handling should not be
needed for MSI/MSI-X. vfio_msihandler() triggers eventfd_signal()
without doing any device-specific config access. When the user performs
any config access or IOCTL after receiving the eventfd notification,
then the device will be moved to the D0 state first before
servicing any request.
Another option was to check this flag 'pm_intx_masked' inside
vfio_intx_handler() instead of masking the interrupts. This flag
is being set inside the runtime_suspend callback but the device
can be in non-D3cold state (for example, if the user has disabled D3cold
explicitly by sysfs, the D3cold is not supported in the platform, etc.).
Also, in D3cold supported case, the device will be in D0 till the
PCI core moves the device into D3cold. In this case, there is
a possibility that the device can generate an interrupt. Adding check
in the IRQ handler will not clear the IRQ status and the interrupt
line will still be asserted. This can cause interrupt flooding.
Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
Link: https://lore.kernel.org/r/20220829114850.4341-4-abhsahu@nvidia.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2022-08-29 14:48:48 +03:00
|
|
|
bool pm_intx_masked;
|
vfio/pci: Implement VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY/EXIT
Currently, if the runtime power management is enabled for vfio-pci
based devices in the guest OS, then the guest OS will do the register
write for PCI_PM_CTRL register. This write request will be handled in
vfio_pm_config_write() where it will do the actual register write of
PCI_PM_CTRL register. With this, the maximum D3hot state can be
achieved for low power. If we can use the runtime PM framework, then
we can achieve the D3cold state (on the supported systems) which will
help in saving maximum power.
1. D3cold state can't be achieved by writing PCI standard
PM config registers. This patch implements the following
newly added low power related device features:
- VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY
- VFIO_DEVICE_FEATURE_LOW_POWER_EXIT
The VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY feature will allow the
device to make use of low power platform states on the host
while the VFIO_DEVICE_FEATURE_LOW_POWER_EXIT will prevent
further use of those power states.
2. The vfio-pci driver uses runtime PM framework for low power entry and
exit. On the platforms where D3cold state is supported, the runtime
PM framework will put the device into D3cold otherwise, D3hot or some
other power state will be used.
There are various cases where the device will not go into the runtime
suspended state. For example,
- The runtime power management is disabled on the host side for
the device.
- The user keeps the device busy after calling LOW_POWER_ENTRY.
- There are dependent devices that are still in runtime active state.
For these cases, the device will be in the same power state that has
been configured by the user through PCI_PM_CTRL register.
3. The hypervisors can implement virtual ACPI methods. For example,
in guest linux OS if PCI device ACPI node has _PR3 and _PR0 power
resources with _ON/_OFF method, then guest linux OS invokes
the _OFF method during D3cold transition and then _ON during D0
transition. The hypervisor can tap these virtual ACPI calls and then
call the low power device feature IOCTL.
4. The 'pm_runtime_engaged' flag tracks the entry and exit to
runtime PM. This flag is protected with 'memory_lock' semaphore.
5. All the config and other region access are wrapped under
pm_runtime_resume_and_get() and pm_runtime_put(). So, if any
device access happens while the device is in the runtime suspended
state, then the device will be resumed first before access. Once the
access has been finished, then the device will again go into the
runtime suspended state.
6. The memory region access through mmap will not be allowed in the low
power state. Since __vfio_pci_memory_enabled() is a common function,
so check for 'pm_runtime_engaged' has been added explicitly in
vfio_pci_mmap_fault() to block only mmap'ed access.
Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
Link: https://lore.kernel.org/r/20220829114850.4341-5-abhsahu@nvidia.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2022-08-29 14:48:49 +03:00
|
|
|
bool pm_runtime_engaged;
|
2012-07-31 18:16:24 +04:00
|
|
|
struct pci_saved_state *pci_saved_state;
|
2019-02-09 23:43:30 +03:00
|
|
|
struct pci_saved_state *pm_save;
|
2018-03-21 21:46:21 +03:00
|
|
|
int ioeventfds_nr;
|
2013-03-11 19:31:22 +04:00
|
|
|
struct eventfd_ctx *err_trigger;
|
2015-02-07 01:05:08 +03:00
|
|
|
struct eventfd_ctx *req_trigger;
|
vfio/pci: Implement VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY_WITH_WAKEUP
This patch implements VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY_WITH_WAKEUP
device feature. In the VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY, if there is
any access for the VFIO device on the host side, then the device will
be moved out of the low power state without the user's guest driver
involvement. Once the device access has been finished, then the host
can move the device again into low power state. With the low power
entry happened through VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY_WITH_WAKEUP,
the device will not be moved back into the low power state and
a notification will be sent to the user by triggering wakeup eventfd.
vfio_pci_core_pm_entry() will be called for both the variants of low
power feature entry so add an extra argument for wakeup eventfd context
and store locally in 'struct vfio_pci_core_device'.
For the entry happened without wakeup eventfd, all the exit related
handling will be done by the LOW_POWER_EXIT device feature only.
When the LOW_POWER_EXIT will be called, then the vfio core layer
vfio_device_pm_runtime_get() will increment the usage count and will
resume the device. In the driver runtime_resume callback, the
'pm_wake_eventfd_ctx' will be NULL. Then vfio_pci_core_pm_exit()
will call vfio_pci_runtime_pm_exit() and all the exit related handling
will be done.
For the entry happened with wakeup eventfd, in the driver resume
callback, eventfd will be triggered and all the exit related handling will
be done. When vfio_pci_runtime_pm_exit() will be called by
vfio_pci_core_pm_exit(), then it will return early.
But if the runtime suspend has not happened on the host side, then
all the exit related handling will be done in vfio_pci_core_pm_exit()
only.
Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
Link: https://lore.kernel.org/r/20220829114850.4341-6-abhsahu@nvidia.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2022-08-29 14:48:50 +03:00
|
|
|
struct eventfd_ctx *pm_wake_eventfd_ctx;
|
2016-06-30 10:21:24 +03:00
|
|
|
struct list_head dummy_resources_list;
|
2018-03-21 21:46:21 +03:00
|
|
|
struct mutex ioeventfds_lock;
|
|
|
|
|
struct list_head ioeventfds_list;
|
vfio/pci: Introduce VF token
If we enable SR-IOV on a vfio-pci owned PF, the resulting VFs are not
fully isolated from the PF. The PF can always cause a denial of service
to the VF, even if by simply resetting itself. The degree to which a PF
can access the data passed through a VF or interfere with its operation
is dependent on a given SR-IOV implementation. Therefore we want to
avoid a scenario where an existing vfio-pci based userspace driver might
assume the PF driver is trusted, for example assigning a PF to one VM
and VF to another with some expectation of isolation. IOMMU grouping
could be a solution to this, but imposes an unnecessarily strong
relationship between PF and VF drivers if they need to operate with the
same IOMMU context. Instead we introduce a "VF token", which is
essentially just a shared secret between PF and VF drivers, implemented
as a UUID.
The VF token can be set by a vfio-pci based PF driver and must be known
by the vfio-pci based VF driver in order to gain access to the device.
This allows the degree to which this VF token is considered secret to be
determined by the applications and environment. For example a VM might
generate a random UUID known only internally to the hypervisor while a
userspace networking appliance might use a shared, or even well know,
UUID among the application drivers.
To incorporate this VF token, the VFIO_GROUP_GET_DEVICE_FD interface is
extended to accept key=value pairs in addition to the device name. This
allows us to most easily deny user access to the device without risk
that existing userspace drivers assume region offsets, IRQs, and other
device features, leading to more elaborate error paths. The format of
these options are expected to take the form:
"$DEVICE_NAME $OPTION1=$VALUE1 $OPTION2=$VALUE2"
Where the device name is always provided first for compatibility and
additional options are specified in a space separated list. The
relation between and requirements for the additional options will be
vfio bus driver dependent, however unknown or unused option within this
schema should return error. This allow for future use of unknown
options as well as a positive indication to the user that an option is
used.
An example VF token option would take this form:
"0000:03:00.0 vf_token=2ab74924-c335-45f4-9b16-8569e5b08258"
When accessing a VF where the PF is making use of vfio-pci, the user
MUST provide the current vf_token. When accessing a PF, the user MUST
provide the current vf_token IF there are active VF users or MAY provide
a vf_token in order to set the current VF token when no VF users are
active. The former requirement assures VF users that an unassociated
driver cannot usurp the PF device. These semantics also imply that a
VF token MUST be set by a PF driver before VF drivers can access their
device, the default token is random and mechanisms to read the token are
not provided in order to protect the VF token of previous users. Use of
the vf_token option outside of these cases will return an error, as
discussed above.
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-03-24 18:28:27 +03:00
|
|
|
struct vfio_pci_vf_token *vf_token;
|
2022-04-13 16:10:36 +03:00
|
|
|
struct list_head sriov_pfs_item;
|
|
|
|
|
struct vfio_pci_core_device *sriov_pf_core_dev;
|
2020-03-24 18:28:28 +03:00
|
|
|
struct notifier_block nb;
|
2020-04-28 22:12:20 +03:00
|
|
|
struct mutex vma_lock;
|
|
|
|
|
struct list_head vma_list;
|
vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
Accessing the disabled memory space of a PCI device would typically
result in a master abort response on conventional PCI, or an
unsupported request on PCI express. The user would generally see
these as a -1 response for the read return data and the write would be
silently discarded, possibly with an uncorrected, non-fatal AER error
triggered on the host. Some systems however take it upon themselves
to bring down the entire system when they see something that might
indicate a loss of data, such as this discarded write to a disabled
memory space.
To avoid this, we want to try to block the user from accessing memory
spaces while they're disabled. We start with a semaphore around the
memory enable bit, where writers modify the memory enable state and
must be serialized, while readers make use of the memory region and
can access in parallel. Writers include both direct manipulation via
the command register, as well as any reset path where the internal
mechanics of the reset may both explicitly and implicitly disable
memory access, and manipulation of the MSI-X configuration, where the
MSI-X vector table resides in MMIO space of the device. Readers
include the read and write file ops to access the vfio device fd
offsets as well as memory mapped access. In the latter case, we make
use of our new vma list support to zap, or invalidate, those memory
mappings in order to force them to be faulted back in on access.
Our semaphore usage will stall user access to MMIO spaces across
internal operations like reset, but the user might experience new
behavior when trying to access the MMIO space while disabled via the
PCI command register. Access via read or write while disabled will
return -EIO and access via memory maps will result in a SIGBUS. This
is expected to be compatible with known use cases and potentially
provides better error handling capabilities than present in the
hardware, while avoiding the more readily accessible and severe
platform error responses that might otherwise occur.
Fixes: CVE-2020-12888
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-04-22 22:48:11 +03:00
|
|
|
struct rw_semaphore memory_lock;
|
2012-07-31 18:16:24 +04:00
|
|
|
};
|
|
|
|
|
|
2022-08-26 22:34:01 +03:00
|
|
|
/* Will be exported for vfio pci drivers usage */
|
2022-08-26 22:34:02 +03:00
|
|
|
int vfio_pci_core_register_dev_region(struct vfio_pci_core_device *vdev,
|
|
|
|
|
unsigned int type, unsigned int subtype,
|
|
|
|
|
const struct vfio_pci_regops *ops,
|
|
|
|
|
size_t size, u32 flags, void *data);
|
2021-08-26 13:39:07 +03:00
|
|
|
void vfio_pci_core_set_params(bool nointxmask, bool is_disable_vga,
|
|
|
|
|
bool is_disable_idle_d3);
|
2021-08-26 13:39:05 +03:00
|
|
|
void vfio_pci_core_close_device(struct vfio_device *core_vdev);
|
2022-09-21 13:43:48 +03:00
|
|
|
int vfio_pci_core_init_dev(struct vfio_device *core_vdev);
|
|
|
|
|
void vfio_pci_core_release_dev(struct vfio_device *core_vdev);
|
2021-08-26 13:39:05 +03:00
|
|
|
int vfio_pci_core_register_device(struct vfio_pci_core_device *vdev);
|
|
|
|
|
void vfio_pci_core_unregister_device(struct vfio_pci_core_device *vdev);
|
|
|
|
|
extern const struct pci_error_handlers vfio_pci_core_err_handlers;
|
2022-05-11 22:19:07 +03:00
|
|
|
int vfio_pci_core_sriov_configure(struct vfio_pci_core_device *vdev,
|
|
|
|
|
int nr_virtfn);
|
2021-08-26 13:39:05 +03:00
|
|
|
long vfio_pci_core_ioctl(struct vfio_device *core_vdev, unsigned int cmd,
|
|
|
|
|
unsigned long arg);
|
2022-02-24 17:20:17 +03:00
|
|
|
int vfio_pci_core_ioctl_feature(struct vfio_device *device, u32 flags,
|
|
|
|
|
void __user *arg, size_t argsz);
|
2021-08-26 13:39:05 +03:00
|
|
|
ssize_t vfio_pci_core_read(struct vfio_device *core_vdev, char __user *buf,
|
|
|
|
|
size_t count, loff_t *ppos);
|
|
|
|
|
ssize_t vfio_pci_core_write(struct vfio_device *core_vdev, const char __user *buf,
|
|
|
|
|
size_t count, loff_t *ppos);
|
|
|
|
|
int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma);
|
|
|
|
|
void vfio_pci_core_request(struct vfio_device *core_vdev, unsigned int count);
|
|
|
|
|
int vfio_pci_core_match(struct vfio_device *core_vdev, char *buf);
|
2021-08-26 13:39:06 +03:00
|
|
|
int vfio_pci_core_enable(struct vfio_pci_core_device *vdev);
|
|
|
|
|
void vfio_pci_core_disable(struct vfio_pci_core_device *vdev);
|
|
|
|
|
void vfio_pci_core_finish_enable(struct vfio_pci_core_device *vdev);
|
2022-02-24 17:20:23 +03:00
|
|
|
pci_ers_result_t vfio_pci_core_aer_err_detected(struct pci_dev *pdev,
|
|
|
|
|
pci_channel_state_t state);
|
2021-08-26 13:39:06 +03:00
|
|
|
|
2021-08-26 13:39:01 +03:00
|
|
|
#endif /* VFIO_PCI_CORE_H */
|
