linux-headers: Update to v6.1

Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
This commit is contained in:
Peter Xu 2023-02-07 15:57:10 -05:00 committed by Juan Quintela
parent bca762c2b9
commit 93e0932b7b
13 changed files with 299 additions and 21 deletions

View file

@ -986,6 +986,148 @@ enum vfio_device_mig_state {
VFIO_DEVICE_STATE_RUNNING_P2P = 5,
};
/*
* Upon VFIO_DEVICE_FEATURE_SET, allow the device to be moved into a low power
* state with the platform-based power management. Device use of lower power
* states depends on factors managed by the runtime power management core,
* including system level support and coordinating support among dependent
* devices. Enabling device low power entry does not guarantee lower power
* usage by the device, nor is a mechanism provided through this feature to
* know the current power state of the device. If any device access happens
* (either from the host or through the vfio uAPI) when the device is in the
* low power state, then the host will move the device out of the low power
* state as necessary prior to the access. Once the access is completed, the
* device may re-enter the low power state. For single shot low power support
* with wake-up notification, see
* VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY_WITH_WAKEUP below. Access to mmap'd
* device regions is disabled on LOW_POWER_ENTRY and may only be resumed after
* calling LOW_POWER_EXIT.
*/
#define VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY 3
/*
* This device feature has the same behavior as
* VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY with the exception that the user
* provides an eventfd for wake-up notification. When the device moves out of
* the low power state for the wake-up, the host will not allow the device to
* re-enter a low power state without a subsequent user call to one of the low
* power entry device feature IOCTLs. Access to mmap'd device regions is
* disabled on LOW_POWER_ENTRY_WITH_WAKEUP and may only be resumed after the
* low power exit. The low power exit can happen either through LOW_POWER_EXIT
* or through any other access (where the wake-up notification has been
* generated). The access to mmap'd device regions will not trigger low power
* exit.
*
* The notification through the provided eventfd will be generated only when
* the device has entered and is resumed from a low power state after
* calling this device feature IOCTL. A device that has not entered low power
* state, as managed through the runtime power management core, will not
* generate a notification through the provided eventfd on access. Calling the
* LOW_POWER_EXIT feature is optional in the case where notification has been
* signaled on the provided eventfd that a resume from low power has occurred.
*/
struct vfio_device_low_power_entry_with_wakeup {
__s32 wakeup_eventfd;
__u32 reserved;
};
#define VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY_WITH_WAKEUP 4
/*
* Upon VFIO_DEVICE_FEATURE_SET, disallow use of device low power states as
* previously enabled via VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY or
* VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY_WITH_WAKEUP device features.
* This device feature IOCTL may itself generate a wakeup eventfd notification
* in the latter case if the device had previously entered a low power state.
*/
#define VFIO_DEVICE_FEATURE_LOW_POWER_EXIT 5
/*
* Upon VFIO_DEVICE_FEATURE_SET start/stop device DMA logging.
* VFIO_DEVICE_FEATURE_PROBE can be used to detect if the device supports
* DMA logging.
*
* DMA logging allows a device to internally record what DMAs the device is
* initiating and report them back to userspace. It is part of the VFIO
* migration infrastructure that allows implementing dirty page tracking
* during the pre copy phase of live migration. Only DMA WRITEs are logged,
* and this API is not connected to VFIO_DEVICE_FEATURE_MIG_DEVICE_STATE.
*
* When DMA logging is started a range of IOVAs to monitor is provided and the
* device can optimize its logging to cover only the IOVA range given. Each
* DMA that the device initiates inside the range will be logged by the device
* for later retrieval.
*
* page_size is an input that hints what tracking granularity the device
* should try to achieve. If the device cannot do the hinted page size then
* it's the driver choice which page size to pick based on its support.
* On output the device will return the page size it selected.
*
* ranges is a pointer to an array of
* struct vfio_device_feature_dma_logging_range.
*
* The core kernel code guarantees to support by minimum num_ranges that fit
* into a single kernel page. User space can try higher values but should give
* up if the above can't be achieved as of some driver limitations.
*
* A single call to start device DMA logging can be issued and a matching stop
* should follow at the end. Another start is not allowed in the meantime.
*/
struct vfio_device_feature_dma_logging_control {
__aligned_u64 page_size;
__u32 num_ranges;
__u32 __reserved;
__aligned_u64 ranges;
};
struct vfio_device_feature_dma_logging_range {
__aligned_u64 iova;
__aligned_u64 length;
};
#define VFIO_DEVICE_FEATURE_DMA_LOGGING_START 6
/*
* Upon VFIO_DEVICE_FEATURE_SET stop device DMA logging that was started
* by VFIO_DEVICE_FEATURE_DMA_LOGGING_START
*/
#define VFIO_DEVICE_FEATURE_DMA_LOGGING_STOP 7
/*
* Upon VFIO_DEVICE_FEATURE_GET read back and clear the device DMA log
*
* Query the device's DMA log for written pages within the given IOVA range.
* During querying the log is cleared for the IOVA range.
*
* bitmap is a pointer to an array of u64s that will hold the output bitmap
* with 1 bit reporting a page_size unit of IOVA. The mapping of IOVA to bits
* is given by:
* bitmap[(addr - iova)/page_size] & (1ULL << (addr % 64))
*
* The input page_size can be any power of two value and does not have to
* match the value given to VFIO_DEVICE_FEATURE_DMA_LOGGING_START. The driver
* will format its internal logging to match the reporting page size, possibly
* by replicating bits if the internal page size is lower than requested.
*
* The LOGGING_REPORT will only set bits in the bitmap and never clear or
* perform any initialization of the user provided bitmap.
*
* If any error is returned userspace should assume that the dirty log is
* corrupted. Error recovery is to consider all memory dirty and try to
* restart the dirty tracking, or to abort/restart the whole migration.
*
* If DMA logging is not enabled, an error will be returned.
*
*/
struct vfio_device_feature_dma_logging_report {
__aligned_u64 iova;
__aligned_u64 length;
__aligned_u64 page_size;
__aligned_u64 bitmap;
};
#define VFIO_DEVICE_FEATURE_DMA_LOGGING_REPORT 8
/* -------- API for Type1 VFIO IOMMU -------- */
/**