2012-10-13 17:46:48 +08:00
|
|
|
#ifndef _UAPI_LINUX_VIRTIO_CONFIG_H
|
|
|
|
|
#define _UAPI_LINUX_VIRTIO_CONFIG_H
|
|
|
|
|
/* This header, excluding the #ifdef __KERNEL__ part, is BSD licensed so
|
|
|
|
|
* anyone can use the definitions to implement compatible drivers/servers.
|
2011-05-31 01:14:13 +08:00
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
|
* 3. Neither the name of IBM nor the names of its contributors
|
|
|
|
|
* may be used to endorse or promote products derived from this software
|
|
|
|
|
* without specific prior written permission.
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
* SUCH DAMAGE. */
|
2012-10-13 17:46:48 +08:00
|
|
|
|
|
|
|
|
/* Virtio devices use a standardized configuration space to define their
|
|
|
|
|
* features and pass configuration information, but each implementation can
|
|
|
|
|
* store and access that space differently. */
|
2010-08-11 09:01:28 +08:00
|
|
|
#include <linux/types.h>
|
2007-10-24 02:47:31 +08:00
|
|
|
|
2012-10-13 17:46:48 +08:00
|
|
|
/* Status byte for guest to report progress, and synchronize features. */
|
|
|
|
|
/* We have seen device and processed generic fields (VIRTIO_CONFIG_F_VIRTIO) */
|
|
|
|
|
#define VIRTIO_CONFIG_S_ACKNOWLEDGE 1
|
|
|
|
|
/* We have found a driver for the device. */
|
|
|
|
|
#define VIRTIO_CONFIG_S_DRIVER 2
|
|
|
|
|
/* Driver has used its parts of the config, and is happy */
|
|
|
|
|
#define VIRTIO_CONFIG_S_DRIVER_OK 4
|
2014-10-22 22:41:38 +08:00
|
|
|
/* Driver has finished configuring features */
|
|
|
|
|
#define VIRTIO_CONFIG_S_FEATURES_OK 8
|
2016-03-29 23:43:45 +08:00
|
|
|
/* Device entered invalid state, driver must reset it */
|
|
|
|
|
#define VIRTIO_CONFIG_S_NEEDS_RESET 0x40
|
2012-10-13 17:46:48 +08:00
|
|
|
/* We've given up on this device. */
|
|
|
|
|
#define VIRTIO_CONFIG_S_FAILED 0x80
|
2010-03-06 12:44:14 +08:00
|
|
|
|
2018-06-01 19:26:32 +08:00
|
|
|
/*
|
|
|
|
|
* Virtio feature bits VIRTIO_TRANSPORT_F_START through
|
|
|
|
|
* VIRTIO_TRANSPORT_F_END are reserved for the transport
|
|
|
|
|
* being used (e.g. virtio_ring, virtio_pci etc.), the
|
|
|
|
|
* rest are per-device feature bits.
|
|
|
|
|
*/
|
2012-10-13 17:46:48 +08:00
|
|
|
#define VIRTIO_TRANSPORT_F_START 28
|
2018-06-01 12:02:39 +08:00
|
|
|
#define VIRTIO_TRANSPORT_F_END 38
|
2010-03-06 12:44:14 +08:00
|
|
|
|
2015-02-11 12:31:14 +08:00
|
|
|
#ifndef VIRTIO_CONFIG_NO_LEGACY
|
2012-10-13 17:46:48 +08:00
|
|
|
/* Do we get callbacks when the ring is completely used, even if we've
|
|
|
|
|
* suppressed them? */
|
|
|
|
|
#define VIRTIO_F_NOTIFY_ON_EMPTY 24
|
2010-03-06 12:44:14 +08:00
|
|
|
|
2013-07-08 09:03:37 +08:00
|
|
|
/* Can the device handle any descriptor layout? */
|
|
|
|
|
#define VIRTIO_F_ANY_LAYOUT 27
|
2015-02-11 12:31:14 +08:00
|
|
|
#endif /* VIRTIO_CONFIG_NO_LEGACY */
|
2013-07-08 09:03:37 +08:00
|
|
|
|
2014-10-22 20:49:34 +08:00
|
|
|
/* v1.0 compliant. */
|
|
|
|
|
#define VIRTIO_F_VERSION_1 32
|
|
|
|
|
|
virtio: new feature to detect IOMMU device quirk
The interaction between virtio and IOMMUs is messy.
On most systems with virtio, physical addresses match bus addresses,
and it doesn't particularly matter which one we use to program
the device.
On some systems, including Xen and any system with a physical device
that speaks virtio behind a physical IOMMU, we must program the IOMMU
for virtio DMA to work at all.
On other systems, including SPARC and PPC64, virtio-pci devices are
enumerated as though they are behind an IOMMU, but the virtio host
ignores the IOMMU, so we must either pretend that the IOMMU isn't
there or somehow map everything as the identity.
Add a feature bit to detect that quirk: VIRTIO_F_IOMMU_PLATFORM.
Any device with this feature bit set to 0 needs a quirk and has to be
passed physical addresses (as opposed to bus addresses) even though
the device is behind an IOMMU.
Note: it has to be a per-device quirk because for example, there could
be a mix of passed-through and virtual virtio devices. As another
example, some devices could be implemented by an out of process
hypervisor backend (in case of qemu vhost, or vhost-user) and so support
for an IOMMU needs to be coded up separately.
It would be cleanest to handle this in IOMMU core code, but that needs
per-device DMA ops. While we are waiting for that to be implemented, use
a work-around in virtio core.
Note: a "noiommu" feature is a quirk - add a wrapper to make
that clear.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-04-18 17:58:14 +08:00
|
|
|
/*
|
2020-06-25 06:24:33 +08:00
|
|
|
* If clear - device has the platform DMA (e.g. IOMMU) bypass quirk feature.
|
|
|
|
|
* If set - use platform DMA tools to access the memory.
|
virtio: new feature to detect IOMMU device quirk
The interaction between virtio and IOMMUs is messy.
On most systems with virtio, physical addresses match bus addresses,
and it doesn't particularly matter which one we use to program
the device.
On some systems, including Xen and any system with a physical device
that speaks virtio behind a physical IOMMU, we must program the IOMMU
for virtio DMA to work at all.
On other systems, including SPARC and PPC64, virtio-pci devices are
enumerated as though they are behind an IOMMU, but the virtio host
ignores the IOMMU, so we must either pretend that the IOMMU isn't
there or somehow map everything as the identity.
Add a feature bit to detect that quirk: VIRTIO_F_IOMMU_PLATFORM.
Any device with this feature bit set to 0 needs a quirk and has to be
passed physical addresses (as opposed to bus addresses) even though
the device is behind an IOMMU.
Note: it has to be a per-device quirk because for example, there could
be a mix of passed-through and virtual virtio devices. As another
example, some devices could be implemented by an out of process
hypervisor backend (in case of qemu vhost, or vhost-user) and so support
for an IOMMU needs to be coded up separately.
It would be cleanest to handle this in IOMMU core code, but that needs
per-device DMA ops. While we are waiting for that to be implemented, use
a work-around in virtio core.
Note: a "noiommu" feature is a quirk - add a wrapper to make
that clear.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-04-18 17:58:14 +08:00
|
|
|
*
|
|
|
|
|
* Note the reverse polarity (compared to most other features),
|
|
|
|
|
* this is for compatibility with legacy systems.
|
|
|
|
|
*/
|
2020-06-25 06:24:33 +08:00
|
|
|
#define VIRTIO_F_ACCESS_PLATFORM 33
|
|
|
|
|
#ifndef __KERNEL__
|
|
|
|
|
/* Legacy name for VIRTIO_F_ACCESS_PLATFORM (for compatibility with old userspace) */
|
|
|
|
|
#define VIRTIO_F_IOMMU_PLATFORM VIRTIO_F_ACCESS_PLATFORM
|
|
|
|
|
#endif /* __KERNEL__ */
|
2018-06-01 12:02:39 +08:00
|
|
|
|
2018-11-21 18:03:18 +08:00
|
|
|
/* This feature indicates support for the packed virtqueue layout. */
|
|
|
|
|
#define VIRTIO_F_RING_PACKED 34
|
|
|
|
|
|
2019-01-23 17:50:26 +08:00
|
|
|
/*
|
|
|
|
|
* This feature indicates that memory accesses by the driver and the
|
|
|
|
|
* device are ordered in a way described by the platform.
|
|
|
|
|
*/
|
|
|
|
|
#define VIRTIO_F_ORDER_PLATFORM 36
|
|
|
|
|
|
2018-06-01 12:02:39 +08:00
|
|
|
/*
|
|
|
|
|
* Does the device support Single Root I/O Virtualization?
|
|
|
|
|
*/
|
|
|
|
|
#define VIRTIO_F_SR_IOV 37
|
2012-10-13 17:46:48 +08:00
|
|
|
#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */
|