From: David Woodhouse Date: Tue, 10 Jan 2023 01:35:33 +0000 (+0000) Subject: hw/xen: Remove old version of Xen headers X-Git-Url: http://xenbits.xensource.com/gitweb?a=commitdiff_plain;h=0e0084082eb2b392ee4f8171341497d9ad96b982;p=people%2Fpauldu%2Fqemu.git hw/xen: Remove old version of Xen headers For Xen emulation support, a full set of Xen headers was imported to include/standard-headers/xen. This renders the original partial set in include/hw/xen/interface redundant. Now that the header ordering and handling of __XEN_INTERFACE_VERSION__ vs. __XEN_TOOLS__ is all untangled, remove the old set of headers and use only the new ones. Signed-off-by: David Woodhouse --- diff --git a/hw/9pfs/xen-9pfs.h b/hw/9pfs/xen-9pfs.h index 241e2216a4..2eb369b262 100644 --- a/hw/9pfs/xen-9pfs.h +++ b/hw/9pfs/xen-9pfs.h @@ -13,8 +13,8 @@ #ifndef HW_9PFS_XEN_9PFS_H #define HW_9PFS_XEN_9PFS_H -#include "hw/xen/interface/io/protocols.h" -#include "hw/xen/interface/io/ring.h" +#include "standard-headers/xen/io/protocols.h" +#include "standard-headers/xen/io/ring.h" /* * Do not merge into xen-9p-backend.c: clang doesn't allow unused static diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c index d44e39e2a1..8fa1b3ab83 100644 --- a/hw/block/dataplane/xen-block.c +++ b/hw/block/dataplane/xen-block.c @@ -25,7 +25,7 @@ #include "qapi/error.h" #include "hw/block/xen_blkif.h" #include "hw/xen/xen.h" -#include "hw/xen/interface/io/ring.h" +#include "standard-headers/xen/io/ring.h" #include "sysemu/block-backend.h" #include "sysemu/iothread.h" #include "xen-block.h" diff --git a/hw/block/xen_blkif.h b/hw/block/xen_blkif.h index 99733529c1..465e4097b7 100644 --- a/hw/block/xen_blkif.h +++ b/hw/block/xen_blkif.h @@ -1,8 +1,9 @@ #ifndef XEN_BLKIF_H #define XEN_BLKIF_H -#include "hw/xen/interface/io/blkif.h" -#include "hw/xen/interface/io/protocols.h" +#include "hw/xen/xen.h" +#include "standard-headers/xen/io/blkif.h" +#include "standard-headers/xen/io/protocols.h" /* * Not a real protocol. Used to generate ring structs which contain diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c index c7a19c0e7c..15265099a3 100644 --- a/hw/char/xen_console.c +++ b/hw/char/xen_console.c @@ -28,7 +28,7 @@ #include "chardev/char-fe.h" #include "hw/xen/xen-legacy-backend.h" -#include "hw/xen/interface/io/console.h" +#include "standard-headers/xen/io/console.h" struct buffer { uint8_t *data; diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c index 0074a9b6f8..62b3db14c5 100644 --- a/hw/display/xenfb.c +++ b/hw/display/xenfb.c @@ -31,9 +31,9 @@ #include "ui/console.h" #include "hw/xen/xen-legacy-backend.h" -#include "hw/xen/interface/io/fbif.h" -#include "hw/xen/interface/io/kbdif.h" -#include "hw/xen/interface/io/protocols.h" +#include "standard-headers/xen/io/fbif.h" +#include "standard-headers/xen/io/kbdif.h" +#include "standard-headers/xen/io/protocols.h" #include "trace.h" diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c index 9bbf6599fc..9df09dc3a4 100644 --- a/hw/net/xen_nic.c +++ b/hw/net/xen_nic.c @@ -29,7 +29,7 @@ #include "net/util.h" #include "hw/xen/xen-legacy-backend.h" -#include "hw/xen/interface/io/netif.h" +#include "standard-headers/xen/io/netif.h" /* ------------------------------------------------------------- */ diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c index 66cb3f7c24..5889ea0a3c 100644 --- a/hw/usb/xen-usb.c +++ b/hw/usb/xen-usb.c @@ -33,7 +33,7 @@ #include "qapi/qmp/qdict.h" #include "qapi/qmp/qstring.h" -#include "hw/xen/interface/io/usbif.h" +#include "standard-headers/xen/io/usbif.h" /* * Check for required support of usbif.h: USBIF_SHORT_NOT_OK was the last diff --git a/include/hw/xen/interface/grant_table.h b/include/hw/xen/interface/grant_table.h deleted file mode 100644 index 2af0cbdde3..0000000000 --- a/include/hw/xen/interface/grant_table.h +++ /dev/null @@ -1,36 +0,0 @@ -/****************************************************************************** - * grant_table.h - * - * Interface for granting foreign access to page frames, and receiving - * page-ownership transfers. - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to - * deal in the Software without restriction, including without limitation the - * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. - * - * Copyright (c) 2004, K A Fraser - */ - -#ifndef __XEN_PUBLIC_GRANT_TABLE_H__ -#define __XEN_PUBLIC_GRANT_TABLE_H__ - -/* - * Reference to a grant entry in a specified domain's grant table. - */ -typedef uint32_t grant_ref_t; - -#endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */ diff --git a/include/hw/xen/interface/io/blkif.h b/include/hw/xen/interface/io/blkif.h deleted file mode 100644 index d07fa1e078..0000000000 --- a/include/hw/xen/interface/io/blkif.h +++ /dev/null @@ -1,712 +0,0 @@ -/****************************************************************************** - * blkif.h - * - * Unified block-device I/O interface for Xen guest OSes. - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to - * deal in the Software without restriction, including without limitation the - * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. - * - * Copyright (c) 2003-2004, Keir Fraser - * Copyright (c) 2012, Spectra Logic Corporation - */ - -#ifndef __XEN_PUBLIC_IO_BLKIF_H__ -#define __XEN_PUBLIC_IO_BLKIF_H__ - -#include "ring.h" -#include "../grant_table.h" - -/* - * Front->back notifications: When enqueuing a new request, sending a - * notification can be made conditional on req_event (i.e., the generic - * hold-off mechanism provided by the ring macros). Backends must set - * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()). - * - * Back->front notifications: When enqueuing a new response, sending a - * notification can be made conditional on rsp_event (i.e., the generic - * hold-off mechanism provided by the ring macros). Frontends must set - * rsp_event appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()). - */ - -#ifndef blkif_vdev_t -#define blkif_vdev_t uint16_t -#endif -#define blkif_sector_t uint64_t - -/* - * Feature and Parameter Negotiation - * ================================= - * The two halves of a Xen block driver utilize nodes within the XenStore to - * communicate capabilities and to negotiate operating parameters. This - * section enumerates these nodes which reside in the respective front and - * backend portions of the XenStore, following the XenBus convention. - * - * All data in the XenStore is stored as strings. Nodes specifying numeric - * values are encoded in decimal. Integer value ranges listed below are - * expressed as fixed sized integer types capable of storing the conversion - * of a properly formated node string, without loss of information. - * - * Any specified default value is in effect if the corresponding XenBus node - * is not present in the XenStore. - * - * XenStore nodes in sections marked "PRIVATE" are solely for use by the - * driver side whose XenBus tree contains them. - * - * XenStore nodes marked "DEPRECATED" in their notes section should only be - * used to provide interoperability with legacy implementations. - * - * See the XenBus state transition diagram below for details on when XenBus - * nodes must be published and when they can be queried. - * - ***************************************************************************** - * Backend XenBus Nodes - ***************************************************************************** - * - *------------------ Backend Device Identification (PRIVATE) ------------------ - * - * mode - * Values: "r" (read only), "w" (writable) - * - * The read or write access permissions to the backing store to be - * granted to the frontend. - * - * params - * Values: string - * - * A free formatted string providing sufficient information for the - * hotplug script to attach the device and provide a suitable - * handler (ie: a block device) for blkback to use. - * - * physical-device - * Values: "MAJOR:MINOR" - * Notes: 11 - * - * MAJOR and MINOR are the major number and minor number of the - * backing device respectively. - * - * physical-device-path - * Values: path string - * - * A string that contains the absolute path to the disk image. On - * NetBSD and Linux this is always a block device, while on FreeBSD - * it can be either a block device or a regular file. - * - * type - * Values: "file", "phy", "tap" - * - * The type of the backing device/object. - * - * - * direct-io-safe - * Values: 0/1 (boolean) - * Default Value: 0 - * - * The underlying storage is not affected by the direct IO memory - * lifetime bug. See: - * http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html - * - * Therefore this option gives the backend permission to use - * O_DIRECT, notwithstanding that bug. - * - * That is, if this option is enabled, use of O_DIRECT is safe, - * in circumstances where we would normally have avoided it as a - * workaround for that bug. This option is not relevant for all - * backends, and even not necessarily supported for those for - * which it is relevant. A backend which knows that it is not - * affected by the bug can ignore this option. - * - * This option doesn't require a backend to use O_DIRECT, so it - * should not be used to try to control the caching behaviour. - * - *--------------------------------- Features --------------------------------- - * - * feature-barrier - * Values: 0/1 (boolean) - * Default Value: 0 - * - * A value of "1" indicates that the backend can process requests - * containing the BLKIF_OP_WRITE_BARRIER request opcode. Requests - * of this type may still be returned at any time with the - * BLKIF_RSP_EOPNOTSUPP result code. - * - * feature-flush-cache - * Values: 0/1 (boolean) - * Default Value: 0 - * - * A value of "1" indicates that the backend can process requests - * containing the BLKIF_OP_FLUSH_DISKCACHE request opcode. Requests - * of this type may still be returned at any time with the - * BLKIF_RSP_EOPNOTSUPP result code. - * - * feature-discard - * Values: 0/1 (boolean) - * Default Value: 0 - * - * A value of "1" indicates that the backend can process requests - * containing the BLKIF_OP_DISCARD request opcode. Requests - * of this type may still be returned at any time with the - * BLKIF_RSP_EOPNOTSUPP result code. - * - * feature-persistent - * Values: 0/1 (boolean) - * Default Value: 0 - * Notes: 7 - * - * A value of "1" indicates that the backend can keep the grants used - * by the frontend driver mapped, so the same set of grants should be - * used in all transactions. The maximum number of grants the backend - * can map persistently depends on the implementation, but ideally it - * should be RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST. Using this - * feature the backend doesn't need to unmap each grant, preventing - * costly TLB flushes. The backend driver should only map grants - * persistently if the frontend supports it. If a backend driver chooses - * to use the persistent protocol when the frontend doesn't support it, - * it will probably hit the maximum number of persistently mapped grants - * (due to the fact that the frontend won't be reusing the same grants), - * and fall back to non-persistent mode. Backend implementations may - * shrink or expand the number of persistently mapped grants without - * notifying the frontend depending on memory constraints (this might - * cause a performance degradation). - * - * If a backend driver wants to limit the maximum number of persistently - * mapped grants to a value less than RING_SIZE * - * BLKIF_MAX_SEGMENTS_PER_REQUEST a LRU strategy should be used to - * discard the grants that are less commonly used. Using a LRU in the - * backend driver paired with a LIFO queue in the frontend will - * allow us to have better performance in this scenario. - * - *----------------------- Request Transport Parameters ------------------------ - * - * max-ring-page-order - * Values: - * Default Value: 0 - * Notes: 1, 3 - * - * The maximum supported size of the request ring buffer in units of - * lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages, - * etc.). - * - * max-ring-pages - * Values: - * Default Value: 1 - * Notes: DEPRECATED, 2, 3 - * - * The maximum supported size of the request ring buffer in units of - * machine pages. The value must be a power of 2. - * - *------------------------- Backend Device Properties ------------------------- - * - * discard-enable - * Values: 0/1 (boolean) - * Default Value: 1 - * - * This optional property, set by the toolstack, instructs the backend - * to offer (or not to offer) discard to the frontend. If the property - * is missing the backend should offer discard if the backing storage - * actually supports it. - * - * discard-alignment - * Values: - * Default Value: 0 - * Notes: 4, 5 - * - * The offset, in bytes from the beginning of the virtual block device, - * to the first, addressable, discard extent on the underlying device. - * - * discard-granularity - * Values: - * Default Value: <"sector-size"> - * Notes: 4 - * - * The size, in bytes, of the individually addressable discard extents - * of the underlying device. - * - * discard-secure - * Values: 0/1 (boolean) - * Default Value: 0 - * Notes: 10 - * - * A value of "1" indicates that the backend can process BLKIF_OP_DISCARD - * requests with the BLKIF_DISCARD_SECURE flag set. - * - * info - * Values: (bitmap) - * - * A collection of bit flags describing attributes of the backing - * device. The VDISK_* macros define the meaning of each bit - * location. - * - * sector-size - * Values: - * - * The logical block size, in bytes, of the underlying storage. This - * must be a power of two with a minimum value of 512. - * - * NOTE: Because of implementation bugs in some frontends this must be - * set to 512, unless the frontend advertizes a non-zero value - * in its "feature-large-sector-size" xenbus node. (See below). - * - * physical-sector-size - * Values: - * Default Value: <"sector-size"> - * - * The physical block size, in bytes, of the backend storage. This - * must be an integer multiple of "sector-size". - * - * sectors - * Values: - * - * The size of the backend device, expressed in units of "sector-size". - * The product of "sector-size" and "sectors" must also be an integer - * multiple of "physical-sector-size", if that node is present. - * - ***************************************************************************** - * Frontend XenBus Nodes - ***************************************************************************** - * - *----------------------- Request Transport Parameters ----------------------- - * - * event-channel - * Values: - * - * The identifier of the Xen event channel used to signal activity - * in the ring buffer. - * - * ring-ref - * Values: - * Notes: 6 - * - * The Xen grant reference granting permission for the backend to map - * the sole page in a single page sized ring buffer. - * - * ring-ref%u - * Values: - * Notes: 6 - * - * For a frontend providing a multi-page ring, a "number of ring pages" - * sized list of nodes, each containing a Xen grant reference granting - * permission for the backend to map the page of the ring located - * at page index "%u". Page indexes are zero based. - * - * protocol - * Values: string (XEN_IO_PROTO_ABI_*) - * Default Value: XEN_IO_PROTO_ABI_NATIVE - * - * The machine ABI rules governing the format of all ring request and - * response structures. - * - * ring-page-order - * Values: - * Default Value: 0 - * Maximum Value: MAX(ffs(max-ring-pages) - 1, max-ring-page-order) - * Notes: 1, 3 - * - * The size of the frontend allocated request ring buffer in units - * of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages, - * etc.). - * - * num-ring-pages - * Values: - * Default Value: 1 - * Maximum Value: MAX(max-ring-pages,(0x1 << max-ring-page-order)) - * Notes: DEPRECATED, 2, 3 - * - * The size of the frontend allocated request ring buffer in units of - * machine pages. The value must be a power of 2. - * - *--------------------------------- Features --------------------------------- - * - * feature-persistent - * Values: 0/1 (boolean) - * Default Value: 0 - * Notes: 7, 8, 9 - * - * A value of "1" indicates that the frontend will reuse the same grants - * for all transactions, allowing the backend to map them with write - * access (even when it should be read-only). If the frontend hits the - * maximum number of allowed persistently mapped grants, it can fallback - * to non persistent mode. This will cause a performance degradation, - * since the backend driver will still try to map those grants - * persistently. Since the persistent grants protocol is compatible with - * the previous protocol, a frontend driver can choose to work in - * persistent mode even when the backend doesn't support it. - * - * It is recommended that the frontend driver stores the persistently - * mapped grants in a LIFO queue, so a subset of all persistently mapped - * grants gets used commonly. This is done in case the backend driver - * decides to limit the maximum number of persistently mapped grants - * to a value less than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST. - * - * feature-large-sector-size - * Values: 0/1 (boolean) - * Default Value: 0 - * - * A value of "1" indicates that the frontend will correctly supply and - * interpret all sector-based quantities in terms of the "sector-size" - * value supplied in the backend info, whatever that may be set to. - * If this node is not present or its value is "0" then it is assumed - * that the frontend requires that the logical block size is 512 as it - * is hardcoded (which is the case in some frontend implementations). - * - *------------------------- Virtual Device Properties ------------------------- - * - * device-type - * Values: "disk", "cdrom", "floppy", etc. - * - * virtual-device - * Values: - * - * A value indicating the physical device to virtualize within the - * frontend's domain. (e.g. "The first ATA disk", "The third SCSI - * disk", etc.) - * - * See docs/misc/vbd-interface.txt for details on the format of this - * value. - * - * Notes - * ----- - * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer - * PV drivers. - * (2) Multi-page ring buffer scheme first used in some RedHat distributions - * including a distribution deployed on certain nodes of the Amazon - * EC2 cluster. - * (3) Support for multi-page ring buffers was implemented independently, - * in slightly different forms, by both Citrix and RedHat/Amazon. - * For full interoperability, block front and backends should publish - * identical ring parameters, adjusted for unit differences, to the - * XenStore nodes used in both schemes. - * (4) Devices that support discard functionality may internally allocate space - * (discardable extents) in units that are larger than the exported logical - * block size. If the backing device has such discardable extents the - * backend should provide both discard-granularity and discard-alignment. - * Providing just one of the two may be considered an error by the frontend. - * Backends supporting discard should include discard-granularity and - * discard-alignment even if it supports discarding individual sectors. - * Frontends should assume discard-alignment == 0 and discard-granularity - * == sector size if these keys are missing. - * (5) The discard-alignment parameter allows a physical device to be - * partitioned into virtual devices that do not necessarily begin or - * end on a discardable extent boundary. - * (6) When there is only a single page allocated to the request ring, - * 'ring-ref' is used to communicate the grant reference for this - * page to the backend. When using a multi-page ring, the 'ring-ref' - * node is not created. Instead 'ring-ref0' - 'ring-refN' are used. - * (7) When using persistent grants data has to be copied from/to the page - * where the grant is currently mapped. The overhead of doing this copy - * however doesn't suppress the speed improvement of not having to unmap - * the grants. - * (8) The frontend driver has to allow the backend driver to map all grants - * with write access, even when they should be mapped read-only, since - * further requests may reuse these grants and require write permissions. - * (9) Linux implementation doesn't have a limit on the maximum number of - * grants that can be persistently mapped in the frontend driver, but - * due to the frontent driver implementation it should never be bigger - * than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST. - *(10) The discard-secure property may be present and will be set to 1 if the - * backing device supports secure discard. - *(11) Only used by Linux and NetBSD. - */ - -/* - * Multiple hardware queues/rings: - * If supported, the backend will write the key "multi-queue-max-queues" to - * the directory for that vbd, and set its value to the maximum supported - * number of queues. - * Frontends that are aware of this feature and wish to use it can write the - * key "multi-queue-num-queues" with the number they wish to use, which must be - * greater than zero, and no more than the value reported by the backend in - * "multi-queue-max-queues". - * - * For frontends requesting just one queue, the usual event-channel and - * ring-ref keys are written as before, simplifying the backend processing - * to avoid distinguishing between a frontend that doesn't understand the - * multi-queue feature, and one that does, but requested only one queue. - * - * Frontends requesting two or more queues must not write the toplevel - * event-channel and ring-ref keys, instead writing those keys under sub-keys - * having the name "queue-N" where N is the integer ID of the queue/ring for - * which those keys belong. Queues are indexed from zero. - * For example, a frontend with two queues must write the following set of - * queue-related keys: - * - * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2" - * /local/domain/1/device/vbd/0/queue-0 = "" - * /local/domain/1/device/vbd/0/queue-0/ring-ref = "" - * /local/domain/1/device/vbd/0/queue-0/event-channel = "" - * /local/domain/1/device/vbd/0/queue-1 = "" - * /local/domain/1/device/vbd/0/queue-1/ring-ref = "" - * /local/domain/1/device/vbd/0/queue-1/event-channel = "" - * - * It is also possible to use multiple queues/rings together with - * feature multi-page ring buffer. - * For example, a frontend requests two queues/rings and the size of each ring - * buffer is two pages must write the following set of related keys: - * - * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2" - * /local/domain/1/device/vbd/0/ring-page-order = "1" - * /local/domain/1/device/vbd/0/queue-0 = "" - * /local/domain/1/device/vbd/0/queue-0/ring-ref0 = "" - * /local/domain/1/device/vbd/0/queue-0/ring-ref1 = "" - * /local/domain/1/device/vbd/0/queue-0/event-channel = "" - * /local/domain/1/device/vbd/0/queue-1 = "" - * /local/domain/1/device/vbd/0/queue-1/ring-ref0 = "" - * /local/domain/1/device/vbd/0/queue-1/ring-ref1 = "" - * /local/domain/1/device/vbd/0/queue-1/event-channel = "" - * - */ - -/* - * STATE DIAGRAMS - * - ***************************************************************************** - * Startup * - ***************************************************************************** - * - * Tool stack creates front and back nodes with state XenbusStateInitialising. - * - * Front Back - * ================================= ===================================== - * XenbusStateInitialising XenbusStateInitialising - * o Query virtual device o Query backend device identification - * properties. data. - * o Setup OS device instance. o Open and validate backend device. - * o Publish backend features and - * transport parameters. - * | - * | - * V - * XenbusStateInitWait - * - * o Query backend features and - * transport parameters. - * o Allocate and initialize the - * request ring. - * o Publish transport parameters - * that will be in effect during - * this connection. - * | - * | - * V - * XenbusStateInitialised - * - * o Query frontend transport parameters. - * o Connect to the request ring and - * event channel. - * o Publish backend device properties. - * | - * | - * V - * XenbusStateConnected - * - * o Query backend device properties. - * o Finalize OS virtual device - * instance. - * | - * | - * V - * XenbusStateConnected - * - * Note: Drivers that do not support any optional features, or the negotiation - * of transport parameters, can skip certain states in the state machine: - * - * o A frontend may transition to XenbusStateInitialised without - * waiting for the backend to enter XenbusStateInitWait. In this - * case, default transport parameters are in effect and any - * transport parameters published by the frontend must contain - * their default values. - * - * o A backend may transition to XenbusStateInitialised, bypassing - * XenbusStateInitWait, without waiting for the frontend to first - * enter the XenbusStateInitialised state. In this case, default - * transport parameters are in effect and any transport parameters - * published by the backend must contain their default values. - * - * Drivers that support optional features and/or transport parameter - * negotiation must tolerate these additional state transition paths. - * In general this means performing the work of any skipped state - * transition, if it has not already been performed, in addition to the - * work associated with entry into the current state. - */ - -/* - * REQUEST CODES. - */ -#define BLKIF_OP_READ 0 -#define BLKIF_OP_WRITE 1 -/* - * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER - * operation code ("barrier request") must be completed prior to the - * execution of the barrier request. All writes issued after the barrier - * request must not execute until after the completion of the barrier request. - * - * Optional. See "feature-barrier" XenBus node documentation above. - */ -#define BLKIF_OP_WRITE_BARRIER 2 -/* - * Commit any uncommitted contents of the backing device's volatile cache - * to stable storage. - * - * Optional. See "feature-flush-cache" XenBus node documentation above. - */ -#define BLKIF_OP_FLUSH_DISKCACHE 3 -/* - * Used in SLES sources for device specific command packet - * contained within the request. Reserved for that purpose. - */ -#define BLKIF_OP_RESERVED_1 4 -/* - * Indicate to the backend device that a region of storage is no longer in - * use, and may be discarded at any time without impact to the client. If - * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the - * discarded region on the device must be rendered unrecoverable before the - * command returns. - * - * This operation is analogous to performing a trim (ATA) or unamp (SCSI), - * command on a native device. - * - * More information about trim/unmap operations can be found at: - * http://t13.org/Documents/UploadedDocuments/docs2008/ - * e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc - * http://www.seagate.com/staticfiles/support/disc/manuals/ - * Interface%20manuals/100293068c.pdf - * - * Optional. See "feature-discard", "discard-alignment", - * "discard-granularity", and "discard-secure" in the XenBus node - * documentation above. - */ -#define BLKIF_OP_DISCARD 5 - -/* - * Recognized if "feature-max-indirect-segments" in present in the backend - * xenbus info. The "feature-max-indirect-segments" node contains the maximum - * number of segments allowed by the backend per request. If the node is - * present, the frontend might use blkif_request_indirect structs in order to - * issue requests with more than BLKIF_MAX_SEGMENTS_PER_REQUEST (11). The - * maximum number of indirect segments is fixed by the backend, but the - * frontend can issue requests with any number of indirect segments as long as - * it's less than the number provided by the backend. The indirect_grefs field - * in blkif_request_indirect should be filled by the frontend with the - * grant references of the pages that are holding the indirect segments. - * These pages are filled with an array of blkif_request_segment that hold the - * information about the segments. The number of indirect pages to use is - * determined by the number of segments an indirect request contains. Every - * indirect page can contain a maximum of - * (PAGE_SIZE / sizeof(struct blkif_request_segment)) segments, so to - * calculate the number of indirect pages to use we have to do - * ceil(indirect_segments / (PAGE_SIZE / sizeof(struct blkif_request_segment))). - * - * If a backend does not recognize BLKIF_OP_INDIRECT, it should *not* - * create the "feature-max-indirect-segments" node! - */ -#define BLKIF_OP_INDIRECT 6 - -/* - * Maximum scatter/gather segments per request. - * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE. - * NB. This could be 12 if the ring indexes weren't stored in the same page. - */ -#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11 - -/* - * Maximum number of indirect pages to use per request. - */ -#define BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST 8 - -/* - * NB. 'first_sect' and 'last_sect' in blkif_request_segment, as well as - * 'sector_number' in blkif_request, blkif_request_discard and - * blkif_request_indirect are sector-based quantities. See the description - * of the "feature-large-sector-size" frontend xenbus node above for - * more information. - */ -struct blkif_request_segment { - grant_ref_t gref; /* reference to I/O buffer frame */ - /* @first_sect: first sector in frame to transfer (inclusive). */ - /* @last_sect: last sector in frame to transfer (inclusive). */ - uint8_t first_sect, last_sect; -}; - -/* - * Starting ring element for any I/O request. - */ -struct blkif_request { - uint8_t operation; /* BLKIF_OP_??? */ - uint8_t nr_segments; /* number of segments */ - blkif_vdev_t handle; /* only for read/write requests */ - uint64_t id; /* private guest value, echoed in resp */ - blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */ - struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST]; -}; -typedef struct blkif_request blkif_request_t; - -/* - * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD - * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request) - */ -struct blkif_request_discard { - uint8_t operation; /* BLKIF_OP_DISCARD */ - uint8_t flag; /* BLKIF_DISCARD_SECURE or zero */ -#define BLKIF_DISCARD_SECURE (1<<0) /* ignored if discard-secure=0 */ - blkif_vdev_t handle; /* same as for read/write requests */ - uint64_t id; /* private guest value, echoed in resp */ - blkif_sector_t sector_number;/* start sector idx on disk */ - uint64_t nr_sectors; /* number of contiguous sectors to discard*/ -}; -typedef struct blkif_request_discard blkif_request_discard_t; - -struct blkif_request_indirect { - uint8_t operation; /* BLKIF_OP_INDIRECT */ - uint8_t indirect_op; /* BLKIF_OP_{READ/WRITE} */ - uint16_t nr_segments; /* number of segments */ - uint64_t id; /* private guest value, echoed in resp */ - blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */ - blkif_vdev_t handle; /* same as for read/write requests */ - grant_ref_t indirect_grefs[BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST]; -#ifdef __i386__ - uint64_t pad; /* Make it 64 byte aligned on i386 */ -#endif -}; -typedef struct blkif_request_indirect blkif_request_indirect_t; - -struct blkif_response { - uint64_t id; /* copied from request */ - uint8_t operation; /* copied from request */ - int16_t status; /* BLKIF_RSP_??? */ -}; -typedef struct blkif_response blkif_response_t; - -/* - * STATUS RETURN CODES. - */ - /* Operation not supported (only happens on barrier writes). */ -#define BLKIF_RSP_EOPNOTSUPP -2 - /* Operation failed for some unspecified reason (-EIO). */ -#define BLKIF_RSP_ERROR -1 - /* Operation completed successfully. */ -#define BLKIF_RSP_OKAY 0 - -/* - * Generate blkif ring structures and types. - */ -DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response); - -#define VDISK_CDROM 0x1 -#define VDISK_REMOVABLE 0x2 -#define VDISK_READONLY 0x4 - -#endif /* __XEN_PUBLIC_IO_BLKIF_H__ */ diff --git a/include/hw/xen/interface/io/console.h b/include/hw/xen/interface/io/console.h deleted file mode 100644 index e2155d1cf5..0000000000 --- a/include/hw/xen/interface/io/console.h +++ /dev/null @@ -1,46 +0,0 @@ -/****************************************************************************** - * console.h - * - * Console I/O interface for Xen guest OSes. - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to - * deal in the Software without restriction, including without limitation the - * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. - * - * Copyright (c) 2005, Keir Fraser - */ - -#ifndef __XEN_PUBLIC_IO_CONSOLE_H__ -#define __XEN_PUBLIC_IO_CONSOLE_H__ - -typedef uint32_t XENCONS_RING_IDX; - -#define MASK_XENCONS_IDX(idx, ring) ((idx) & (sizeof(ring)-1)) - -struct xencons_interface { - char in[1024]; - char out[2048]; - XENCONS_RING_IDX in_cons, in_prod; - XENCONS_RING_IDX out_cons, out_prod; -}; - -#ifdef XEN_WANT_FLEX_CONSOLE_RING -#include "ring.h" -DEFINE_XEN_FLEX_RING(xencons); -#endif - -#endif /* __XEN_PUBLIC_IO_CONSOLE_H__ */ diff --git a/include/hw/xen/interface/io/fbif.h b/include/hw/xen/interface/io/fbif.h deleted file mode 100644 index ea87ebec0a..0000000000 --- a/include/hw/xen/interface/io/fbif.h +++ /dev/null @@ -1,156 +0,0 @@ -/* - * fbif.h -- Xen virtual frame buffer device - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to - * deal in the Software without restriction, including without limitation the - * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. - * - * Copyright (C) 2005 Anthony Liguori - * Copyright (C) 2006 Red Hat, Inc., Markus Armbruster - */ - -#ifndef __XEN_PUBLIC_IO_FBIF_H__ -#define __XEN_PUBLIC_IO_FBIF_H__ - -/* Out events (frontend -> backend) */ - -/* - * Out events may be sent only when requested by backend, and receipt - * of an unknown out event is an error. - */ - -/* Event type 1 currently not used */ -/* - * Framebuffer update notification event - * Capable frontend sets feature-update in xenstore. - * Backend requests it by setting request-update in xenstore. - */ -#define XENFB_TYPE_UPDATE 2 - -struct xenfb_update -{ - uint8_t type; /* XENFB_TYPE_UPDATE */ - int32_t x; /* source x */ - int32_t y; /* source y */ - int32_t width; /* rect width */ - int32_t height; /* rect height */ -}; - -/* - * Framebuffer resize notification event - * Capable backend sets feature-resize in xenstore. - */ -#define XENFB_TYPE_RESIZE 3 - -struct xenfb_resize -{ - uint8_t type; /* XENFB_TYPE_RESIZE */ - int32_t width; /* width in pixels */ - int32_t height; /* height in pixels */ - int32_t stride; /* stride in bytes */ - int32_t depth; /* depth in bits */ - int32_t offset; /* offset of the framebuffer in bytes */ -}; - -#define XENFB_OUT_EVENT_SIZE 40 - -union xenfb_out_event -{ - uint8_t type; - struct xenfb_update update; - struct xenfb_resize resize; - char pad[XENFB_OUT_EVENT_SIZE]; -}; - -/* In events (backend -> frontend) */ - -/* - * Frontends should ignore unknown in events. - */ - -/* - * Framebuffer refresh period advice - * Backend sends it to advise the frontend their preferred period of - * refresh. Frontends that keep the framebuffer constantly up-to-date - * just ignore it. Frontends that use the advice should immediately - * refresh the framebuffer (and send an update notification event if - * those have been requested), then use the update frequency to guide - * their periodical refreshs. - */ -#define XENFB_TYPE_REFRESH_PERIOD 1 -#define XENFB_NO_REFRESH 0 - -struct xenfb_refresh_period -{ - uint8_t type; /* XENFB_TYPE_UPDATE_PERIOD */ - uint32_t period; /* period of refresh, in ms, - * XENFB_NO_REFRESH if no refresh is needed */ -}; - -#define XENFB_IN_EVENT_SIZE 40 - -union xenfb_in_event -{ - uint8_t type; - struct xenfb_refresh_period refresh_period; - char pad[XENFB_IN_EVENT_SIZE]; -}; - -/* shared page */ - -#define XENFB_IN_RING_SIZE 1024 -#define XENFB_IN_RING_LEN (XENFB_IN_RING_SIZE / XENFB_IN_EVENT_SIZE) -#define XENFB_IN_RING_OFFS 1024 -#define XENFB_IN_RING(page) \ - ((union xenfb_in_event *)((char *)(page) + XENFB_IN_RING_OFFS)) -#define XENFB_IN_RING_REF(page, idx) \ - (XENFB_IN_RING((page))[(idx) % XENFB_IN_RING_LEN]) - -#define XENFB_OUT_RING_SIZE 2048 -#define XENFB_OUT_RING_LEN (XENFB_OUT_RING_SIZE / XENFB_OUT_EVENT_SIZE) -#define XENFB_OUT_RING_OFFS (XENFB_IN_RING_OFFS + XENFB_IN_RING_SIZE) -#define XENFB_OUT_RING(page) \ - ((union xenfb_out_event *)((char *)(page) + XENFB_OUT_RING_OFFS)) -#define XENFB_OUT_RING_REF(page, idx) \ - (XENFB_OUT_RING((page))[(idx) % XENFB_OUT_RING_LEN]) - -struct xenfb_page -{ - uint32_t in_cons, in_prod; - uint32_t out_cons, out_prod; - - int32_t width; /* the width of the framebuffer (in pixels) */ - int32_t height; /* the height of the framebuffer (in pixels) */ - uint32_t line_length; /* the length of a row of pixels (in bytes) */ - uint32_t mem_length; /* the length of the framebuffer (in bytes) */ - uint8_t depth; /* the depth of a pixel (in bits) */ - - /* - * Framebuffer page directory - * - * Each directory page holds PAGE_SIZE / sizeof(*pd) - * framebuffer pages, and can thus map up to PAGE_SIZE * - * PAGE_SIZE / sizeof(*pd) bytes. With PAGE_SIZE == 4096 and - * sizeof(unsigned long) == 4/8, that's 4 Megs 32 bit and 2 Megs - * 64 bit. 256 directories give enough room for a 512 Meg - * framebuffer with a max resolution of 12,800x10,240. Should - * be enough for a while with room leftover for expansion. - */ - unsigned long pd[256]; -}; - -#endif diff --git a/include/hw/xen/interface/io/kbdif.h b/include/hw/xen/interface/io/kbdif.h deleted file mode 100644 index 1d68cd458e..0000000000 --- a/include/hw/xen/interface/io/kbdif.h +++ /dev/null @@ -1,566 +0,0 @@ -/* - * kbdif.h -- Xen virtual keyboard/mouse - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to - * deal in the Software without restriction, including without limitation the - * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. - * - * Copyright (C) 2005 Anthony Liguori - * Copyright (C) 2006 Red Hat, Inc., Markus Armbruster - */ - -#ifndef __XEN_PUBLIC_IO_KBDIF_H__ -#define __XEN_PUBLIC_IO_KBDIF_H__ - -/* - ***************************************************************************** - * Feature and Parameter Negotiation - ***************************************************************************** - * - * The two halves of a para-virtual driver utilize nodes within - * XenStore to communicate capabilities and to negotiate operating parameters. - * This section enumerates these nodes which reside in the respective front and - * backend portions of XenStore, following XenBus convention. - * - * All data in XenStore is stored as strings. Nodes specifying numeric - * values are encoded in decimal. Integer value ranges listed below are - * expressed as fixed sized integer types capable of storing the conversion - * of a properly formated node string, without loss of information. - * - ***************************************************************************** - * Backend XenBus Nodes - ***************************************************************************** - * - *---------------------------- Features supported ---------------------------- - * - * Capable backend advertises supported features by publishing - * corresponding entries in XenStore and puts 1 as the value of the entry. - * If a feature is not supported then 0 must be set or feature entry omitted. - * - * feature-disable-keyboard - * Values: - * - * If there is no need to expose a virtual keyboard device by the - * frontend then this must be set to 1. - * - * feature-disable-pointer - * Values: - * - * If there is no need to expose a virtual pointer device by the - * frontend then this must be set to 1. - * - * feature-abs-pointer - * Values: - * - * Backends, which support reporting of absolute coordinates for pointer - * device should set this to 1. - * - * feature-multi-touch - * Values: - * - * Backends, which support reporting of multi-touch events - * should set this to 1. - * - * feature-raw-pointer - * Values: - * - * Backends, which support reporting raw (unscaled) absolute coordinates - * for pointer devices should set this to 1. Raw (unscaled) values have - * a range of [0, 0x7fff]. - * - *----------------------- Device Instance Parameters ------------------------ - * - * unique-id - * Values: - * - * After device instance initialization it is assigned a unique ID, - * so every instance of the frontend can be identified by the backend - * by this ID. This can be UUID or such. - * - *------------------------- Pointer Device Parameters ------------------------ - * - * width - * Values: - * - * Maximum X coordinate (width) to be used by the frontend - * while reporting input events, pixels, [0; UINT32_MAX]. - * - * height - * Values: - * - * Maximum Y coordinate (height) to be used by the frontend - * while reporting input events, pixels, [0; UINT32_MAX]. - * - *----------------------- Multi-touch Device Parameters ---------------------- - * - * multi-touch-num-contacts - * Values: - * - * Number of simultaneous touches reported. - * - * multi-touch-width - * Values: - * - * Width of the touch area to be used by the frontend - * while reporting input events, pixels, [0; UINT32_MAX]. - * - * multi-touch-height - * Values: - * - * Height of the touch area to be used by the frontend - * while reporting input events, pixels, [0; UINT32_MAX]. - * - ***************************************************************************** - * Frontend XenBus Nodes - ***************************************************************************** - * - *------------------------------ Feature request ----------------------------- - * - * Capable frontend requests features from backend via setting corresponding - * entries to 1 in XenStore. Requests for features not advertised as supported - * by the backend have no effect. - * - * request-abs-pointer - * Values: - * - * Request backend to report absolute pointer coordinates - * (XENKBD_TYPE_POS) instead of relative ones (XENKBD_TYPE_MOTION). - * - * request-multi-touch - * Values: - * - * Request backend to report multi-touch events. - * - * request-raw-pointer - * Values: - * - * Request backend to report raw unscaled absolute pointer coordinates. - * This option is only valid if request-abs-pointer is also set. - * Raw unscaled coordinates have the range [0, 0x7fff] - * - *----------------------- Request Transport Parameters ----------------------- - * - * event-channel - * Values: - * - * The identifier of the Xen event channel used to signal activity - * in the ring buffer. - * - * page-gref - * Values: - * - * The Xen grant reference granting permission for the backend to map - * a sole page in a single page sized event ring buffer. - * - * page-ref - * Values: - * - * OBSOLETE, not recommended for use. - * PFN of the shared page. - */ - -/* - * EVENT CODES. - */ - -#define XENKBD_TYPE_MOTION 1 -#define XENKBD_TYPE_RESERVED 2 -#define XENKBD_TYPE_KEY 3 -#define XENKBD_TYPE_POS 4 -#define XENKBD_TYPE_MTOUCH 5 - -/* Multi-touch event sub-codes */ - -#define XENKBD_MT_EV_DOWN 0 -#define XENKBD_MT_EV_UP 1 -#define XENKBD_MT_EV_MOTION 2 -#define XENKBD_MT_EV_SYN 3 -#define XENKBD_MT_EV_SHAPE 4 -#define XENKBD_MT_EV_ORIENT 5 - -/* - * CONSTANTS, XENSTORE FIELD AND PATH NAME STRINGS, HELPERS. - */ - -#define XENKBD_DRIVER_NAME "vkbd" - -#define XENKBD_FIELD_FEAT_DSBL_KEYBRD "feature-disable-keyboard" -#define XENKBD_FIELD_FEAT_DSBL_POINTER "feature-disable-pointer" -#define XENKBD_FIELD_FEAT_ABS_POINTER "feature-abs-pointer" -#define XENKBD_FIELD_FEAT_RAW_POINTER "feature-raw-pointer" -#define XENKBD_FIELD_FEAT_MTOUCH "feature-multi-touch" -#define XENKBD_FIELD_REQ_ABS_POINTER "request-abs-pointer" -#define XENKBD_FIELD_REQ_RAW_POINTER "request-raw-pointer" -#define XENKBD_FIELD_REQ_MTOUCH "request-multi-touch" -#define XENKBD_FIELD_RING_GREF "page-gref" -#define XENKBD_FIELD_EVT_CHANNEL "event-channel" -#define XENKBD_FIELD_WIDTH "width" -#define XENKBD_FIELD_HEIGHT "height" -#define XENKBD_FIELD_MT_WIDTH "multi-touch-width" -#define XENKBD_FIELD_MT_HEIGHT "multi-touch-height" -#define XENKBD_FIELD_MT_NUM_CONTACTS "multi-touch-num-contacts" -#define XENKBD_FIELD_UNIQUE_ID "unique-id" - -/* OBSOLETE, not recommended for use */ -#define XENKBD_FIELD_RING_REF "page-ref" - -/* - ***************************************************************************** - * Description of the protocol between frontend and backend driver. - ***************************************************************************** - * - * The two halves of a Para-virtual driver communicate with - * each other using a shared page and an event channel. - * Shared page contains a ring with event structures. - * - * All reserved fields in the structures below must be 0. - * - ***************************************************************************** - * Backend to frontend events - ***************************************************************************** - * - * Frontends should ignore unknown in events. - * All event packets have the same length (40 octets) - * All event packets have common header: - * - * 0 octet - * +-----------------+ - * | type | - * +-----------------+ - * type - uint8_t, event code, XENKBD_TYPE_??? - * - * - * Pointer relative movement event - * 0 1 2 3 octet - * +----------------+----------------+----------------+----------------+ - * | _TYPE_MOTION | reserved | 4 - * +----------------+----------------+----------------+----------------+ - * | rel_x | 8 - * +----------------+----------------+----------------+----------------+ - * | rel_y | 12 - * +----------------+----------------+----------------+----------------+ - * | rel_z | 16 - * +----------------+----------------+----------------+----------------+ - * | reserved | 20 - * +----------------+----------------+----------------+----------------+ - * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| - * +----------------+----------------+----------------+----------------+ - * | reserved | 40 - * +----------------+----------------+----------------+----------------+ - * - * rel_x - int32_t, relative X motion - * rel_y - int32_t, relative Y motion - * rel_z - int32_t, relative Z motion (wheel) - */ - -struct xenkbd_motion -{ - uint8_t type; - int32_t rel_x; - int32_t rel_y; - int32_t rel_z; -}; - -/* - * Key event (includes pointer buttons) - * 0 1 2 3 octet - * +----------------+----------------+----------------+----------------+ - * | _TYPE_KEY | pressed | reserved | 4 - * +----------------+----------------+----------------+----------------+ - * | keycode | 8 - * +----------------+----------------+----------------+----------------+ - * | reserved | 12 - * +----------------+----------------+----------------+----------------+ - * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| - * +----------------+----------------+----------------+----------------+ - * | reserved | 40 - * +----------------+----------------+----------------+----------------+ - * - * pressed - uint8_t, 1 if pressed; 0 otherwise - * keycode - uint32_t, KEY_* from linux/input.h - */ - -struct xenkbd_key -{ - uint8_t type; - uint8_t pressed; - uint32_t keycode; -}; - -/* - * Pointer absolute position event - * 0 1 2 3 octet - * +----------------+----------------+----------------+----------------+ - * | _TYPE_POS | reserved | 4 - * +----------------+----------------+----------------+----------------+ - * | abs_x | 8 - * +----------------+----------------+----------------+----------------+ - * | abs_y | 12 - * +----------------+----------------+----------------+----------------+ - * | rel_z | 16 - * +----------------+----------------+----------------+----------------+ - * | reserved | 20 - * +----------------+----------------+----------------+----------------+ - * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| - * +----------------+----------------+----------------+----------------+ - * | reserved | 40 - * +----------------+----------------+----------------+----------------+ - * - * abs_x - int32_t, absolute X position (in FB pixels) - * abs_y - int32_t, absolute Y position (in FB pixels) - * rel_z - int32_t, relative Z motion (wheel) - */ - -struct xenkbd_position -{ - uint8_t type; - int32_t abs_x; - int32_t abs_y; - int32_t rel_z; -}; - -/* - * Multi-touch event and its sub-types - * - * All multi-touch event packets have common header: - * - * 0 1 2 3 octet - * +----------------+----------------+----------------+----------------+ - * | _TYPE_MTOUCH | event_type | contact_id | reserved | 4 - * +----------------+----------------+----------------+----------------+ - * | reserved | 8 - * +----------------+----------------+----------------+----------------+ - * - * event_type - unt8_t, multi-touch event sub-type, XENKBD_MT_EV_??? - * contact_id - unt8_t, ID of the contact - * - * Touch interactions can consist of one or more contacts. - * For each contact, a series of events is generated, starting - * with a down event, followed by zero or more motion events, - * and ending with an up event. Events relating to the same - * contact point can be identified by the ID of the sequence: contact ID. - * Contact ID may be reused after XENKBD_MT_EV_UP event and - * is in the [0; XENKBD_FIELD_NUM_CONTACTS - 1] range. - * - * For further information please refer to documentation on Wayland [1], - * Linux [2] and Windows [3] multi-touch support. - * - * [1] https://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml - * [2] https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt - * [3] https://msdn.microsoft.com/en-us/library/jj151564(v=vs.85).aspx - * - * - * Multi-touch down event - sent when a new touch is made: touch is assigned - * a unique contact ID, sent with this and consequent events related - * to this touch. - * 0 1 2 3 octet - * +----------------+----------------+----------------+----------------+ - * | _TYPE_MTOUCH | _MT_EV_DOWN | contact_id | reserved | 4 - * +----------------+----------------+----------------+----------------+ - * | reserved | 8 - * +----------------+----------------+----------------+----------------+ - * | abs_x | 12 - * +----------------+----------------+----------------+----------------+ - * | abs_y | 16 - * +----------------+----------------+----------------+----------------+ - * | reserved | 20 - * +----------------+----------------+----------------+----------------+ - * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| - * +----------------+----------------+----------------+----------------+ - * | reserved | 40 - * +----------------+----------------+----------------+----------------+ - * - * abs_x - int32_t, absolute X position, in pixels - * abs_y - int32_t, absolute Y position, in pixels - * - * Multi-touch contact release event - * 0 1 2 3 octet - * +----------------+----------------+----------------+----------------+ - * | _TYPE_MTOUCH | _MT_EV_UP | contact_id | reserved | 4 - * +----------------+----------------+----------------+----------------+ - * | reserved | 8 - * +----------------+----------------+----------------+----------------+ - * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| - * +----------------+----------------+----------------+----------------+ - * | reserved | 40 - * +----------------+----------------+----------------+----------------+ - * - * Multi-touch motion event - * 0 1 2 3 octet - * +----------------+----------------+----------------+----------------+ - * | _TYPE_MTOUCH | _MT_EV_MOTION | contact_id | reserved | 4 - * +----------------+----------------+----------------+----------------+ - * | reserved | 8 - * +----------------+----------------+----------------+----------------+ - * | abs_x | 12 - * +----------------+----------------+----------------+----------------+ - * | abs_y | 16 - * +----------------+----------------+----------------+----------------+ - * | reserved | 20 - * +----------------+----------------+----------------+----------------+ - * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| - * +----------------+----------------+----------------+----------------+ - * | reserved | 40 - * +----------------+----------------+----------------+----------------+ - * - * abs_x - int32_t, absolute X position, in pixels, - * abs_y - int32_t, absolute Y position, in pixels, - * - * Multi-touch input synchronization event - shows end of a set of events - * which logically belong together. - * 0 1 2 3 octet - * +----------------+----------------+----------------+----------------+ - * | _TYPE_MTOUCH | _MT_EV_SYN | contact_id | reserved | 4 - * +----------------+----------------+----------------+----------------+ - * | reserved | 8 - * +----------------+----------------+----------------+----------------+ - * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| - * +----------------+----------------+----------------+----------------+ - * | reserved | 40 - * +----------------+----------------+----------------+----------------+ - * - * Multi-touch shape event - touch point's shape has changed its shape. - * Shape is approximated by an ellipse through the major and minor axis - * lengths: major is the longer diameter of the ellipse and minor is the - * shorter one. Center of the ellipse is reported via - * XENKBD_MT_EV_DOWN/XENKBD_MT_EV_MOTION events. - * 0 1 2 3 octet - * +----------------+----------------+----------------+----------------+ - * | _TYPE_MTOUCH | _MT_EV_SHAPE | contact_id | reserved | 4 - * +----------------+----------------+----------------+----------------+ - * | reserved | 8 - * +----------------+----------------+----------------+----------------+ - * | major | 12 - * +----------------+----------------+----------------+----------------+ - * | minor | 16 - * +----------------+----------------+----------------+----------------+ - * | reserved | 20 - * +----------------+----------------+----------------+----------------+ - * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| - * +----------------+----------------+----------------+----------------+ - * | reserved | 40 - * +----------------+----------------+----------------+----------------+ - * - * major - unt32_t, length of the major axis, pixels - * minor - unt32_t, length of the minor axis, pixels - * - * Multi-touch orientation event - touch point's shape has changed - * its orientation: calculated as a clockwise angle between the major axis - * of the ellipse and positive Y axis in degrees, [-180; +180]. - * 0 1 2 3 octet - * +----------------+----------------+----------------+----------------+ - * | _TYPE_MTOUCH | _MT_EV_ORIENT | contact_id | reserved | 4 - * +----------------+----------------+----------------+----------------+ - * | reserved | 8 - * +----------------+----------------+----------------+----------------+ - * | orientation | reserved | 12 - * +----------------+----------------+----------------+----------------+ - * | reserved | 16 - * +----------------+----------------+----------------+----------------+ - * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| - * +----------------+----------------+----------------+----------------+ - * | reserved | 40 - * +----------------+----------------+----------------+----------------+ - * - * orientation - int16_t, clockwise angle of the major axis - */ - -struct xenkbd_mtouch { - uint8_t type; /* XENKBD_TYPE_MTOUCH */ - uint8_t event_type; /* XENKBD_MT_EV_??? */ - uint8_t contact_id; - uint8_t reserved[5]; /* reserved for the future use */ - union { - struct { - int32_t abs_x; /* absolute X position, pixels */ - int32_t abs_y; /* absolute Y position, pixels */ - } pos; - struct { - uint32_t major; /* length of the major axis, pixels */ - uint32_t minor; /* length of the minor axis, pixels */ - } shape; - int16_t orientation; /* clockwise angle of the major axis */ - } u; -}; - -#define XENKBD_IN_EVENT_SIZE 40 - -union xenkbd_in_event -{ - uint8_t type; - struct xenkbd_motion motion; - struct xenkbd_key key; - struct xenkbd_position pos; - struct xenkbd_mtouch mtouch; - char pad[XENKBD_IN_EVENT_SIZE]; -}; - -/* - ***************************************************************************** - * Frontend to backend events - ***************************************************************************** - * - * Out events may be sent only when requested by backend, and receipt - * of an unknown out event is an error. - * No out events currently defined. - - * All event packets have the same length (40 octets) - * All event packets have common header: - * 0 octet - * +-----------------+ - * | type | - * +-----------------+ - * type - uint8_t, event code - */ - -#define XENKBD_OUT_EVENT_SIZE 40 - -union xenkbd_out_event -{ - uint8_t type; - char pad[XENKBD_OUT_EVENT_SIZE]; -}; - -/* - ***************************************************************************** - * Shared page - ***************************************************************************** - */ - -#define XENKBD_IN_RING_SIZE 2048 -#define XENKBD_IN_RING_LEN (XENKBD_IN_RING_SIZE / XENKBD_IN_EVENT_SIZE) -#define XENKBD_IN_RING_OFFS 1024 -#define XENKBD_IN_RING(page) \ - ((union xenkbd_in_event *)((char *)(page) + XENKBD_IN_RING_OFFS)) -#define XENKBD_IN_RING_REF(page, idx) \ - (XENKBD_IN_RING((page))[(idx) % XENKBD_IN_RING_LEN]) - -#define XENKBD_OUT_RING_SIZE 1024 -#define XENKBD_OUT_RING_LEN (XENKBD_OUT_RING_SIZE / XENKBD_OUT_EVENT_SIZE) -#define XENKBD_OUT_RING_OFFS (XENKBD_IN_RING_OFFS + XENKBD_IN_RING_SIZE) -#define XENKBD_OUT_RING(page) \ - ((union xenkbd_out_event *)((char *)(page) + XENKBD_OUT_RING_OFFS)) -#define XENKBD_OUT_RING_REF(page, idx) \ - (XENKBD_OUT_RING((page))[(idx) % XENKBD_OUT_RING_LEN]) - -struct xenkbd_page -{ - uint32_t in_cons, in_prod; - uint32_t out_cons, out_prod; -}; - -#endif /* __XEN_PUBLIC_IO_KBDIF_H__ */ diff --git a/include/hw/xen/interface/io/netif.h b/include/hw/xen/interface/io/netif.h deleted file mode 100644 index 48fa530950..0000000000 --- a/include/hw/xen/interface/io/netif.h +++ /dev/null @@ -1,1010 +0,0 @@ -/****************************************************************************** - * netif.h - * - * Unified network-device I/O interface for Xen guest OSes. - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to - * deal in the Software without restriction, including without limitation the - * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. - * - * Copyright (c) 2003-2004, Keir Fraser - */ - -#ifndef __XEN_PUBLIC_IO_NETIF_H__ -#define __XEN_PUBLIC_IO_NETIF_H__ - -#include "ring.h" -#include "../grant_table.h" - -/* - * Older implementation of Xen network frontend / backend has an - * implicit dependency on the MAX_SKB_FRAGS as the maximum number of - * ring slots a skb can use. Netfront / netback may not work as - * expected when frontend and backend have different MAX_SKB_FRAGS. - * - * A better approach is to add mechanism for netfront / netback to - * negotiate this value. However we cannot fix all possible - * frontends, so we need to define a value which states the minimum - * slots backend must support. - * - * The minimum value derives from older Linux kernel's MAX_SKB_FRAGS - * (18), which is proved to work with most frontends. Any new backend - * which doesn't negotiate with frontend should expect frontend to - * send a valid packet using slots up to this value. - */ -#define XEN_NETIF_NR_SLOTS_MIN 18 - -/* - * Notifications after enqueuing any type of message should be conditional on - * the appropriate req_event or rsp_event field in the shared ring. - * If the client sends notification for rx requests then it should specify - * feature 'feature-rx-notify' via xenbus. Otherwise the backend will assume - * that it cannot safely queue packets (as it may not be kicked to send them). - */ - -/* - * "feature-split-event-channels" is introduced to separate guest TX - * and RX notification. Backend either doesn't support this feature or - * advertises it via xenstore as 0 (disabled) or 1 (enabled). - * - * To make use of this feature, frontend should allocate two event - * channels for TX and RX, advertise them to backend as - * "event-channel-tx" and "event-channel-rx" respectively. If frontend - * doesn't want to use this feature, it just writes "event-channel" - * node as before. - */ - -/* - * Multiple transmit and receive queues: - * If supported, the backend will write the key "multi-queue-max-queues" to - * the directory for that vif, and set its value to the maximum supported - * number of queues. - * Frontends that are aware of this feature and wish to use it can write the - * key "multi-queue-num-queues", set to the number they wish to use, which - * must be greater than zero, and no more than the value reported by the backend - * in "multi-queue-max-queues". - * - * Queues replicate the shared rings and event channels. - * "feature-split-event-channels" may optionally be used when using - * multiple queues, but is not mandatory. - * - * Each queue consists of one shared ring pair, i.e. there must be the same - * number of tx and rx rings. - * - * For frontends requesting just one queue, the usual event-channel and - * ring-ref keys are written as before, simplifying the backend processing - * to avoid distinguishing between a frontend that doesn't understand the - * multi-queue feature, and one that does, but requested only one queue. - * - * Frontends requesting two or more queues must not write the toplevel - * event-channel (or event-channel-{tx,rx}) and {tx,rx}-ring-ref keys, - * instead writing those keys under sub-keys having the name "queue-N" where - * N is the integer ID of the queue for which those keys belong. Queues - * are indexed from zero. For example, a frontend with two queues and split - * event channels must write the following set of queue-related keys: - * - * /local/domain/1/device/vif/0/multi-queue-num-queues = "2" - * /local/domain/1/device/vif/0/queue-0 = "" - * /local/domain/1/device/vif/0/queue-0/tx-ring-ref = "" - * /local/domain/1/device/vif/0/queue-0/rx-ring-ref = "" - * /local/domain/1/device/vif/0/queue-0/event-channel-tx = "" - * /local/domain/1/device/vif/0/queue-0/event-channel-rx = "" - * /local/domain/1/device/vif/0/queue-1 = "" - * /local/domain/1/device/vif/0/queue-1/tx-ring-ref = "" - * /local/domain/1/device/vif/0/queue-1/rx-ring-ref = "//feature-ctrl-ring = "1" - * - * The frontend provides a control ring to the backend by setting: - * - * /local/domain//device/vif//ctrl-ring-ref = - * /local/domain//device/vif//event-channel-ctrl = - * - * where is the grant reference of the shared page used to - * implement the control ring and is an event channel to be used - * as a mailbox interrupt. These keys must be set before the frontend - * moves into the connected state. - * - * The control ring uses a fixed request/response message size and is - * balanced (i.e. one request to one response), so operationally it is much - * the same as a transmit or receive ring. - * Note that there is no requirement that responses are issued in the same - * order as requests. - */ - -/* - * Hash types - * ========== - * - * For the purposes of the definitions below, 'Packet[]' is an array of - * octets containing an IP packet without options, 'Array[X..Y]' means a - * sub-array of 'Array' containing bytes X thru Y inclusive, and '+' is - * used to indicate concatenation of arrays. - */ - -/* - * A hash calculated over an IP version 4 header as follows: - * - * Buffer[0..8] = Packet[12..15] (source address) + - * Packet[16..19] (destination address) - * - * Result = Hash(Buffer, 8) - */ -#define _XEN_NETIF_CTRL_HASH_TYPE_IPV4 0 -#define XEN_NETIF_CTRL_HASH_TYPE_IPV4 \ - (1 << _XEN_NETIF_CTRL_HASH_TYPE_IPV4) - -/* - * A hash calculated over an IP version 4 header and TCP header as - * follows: - * - * Buffer[0..12] = Packet[12..15] (source address) + - * Packet[16..19] (destination address) + - * Packet[20..21] (source port) + - * Packet[22..23] (destination port) - * - * Result = Hash(Buffer, 12) - */ -#define _XEN_NETIF_CTRL_HASH_TYPE_IPV4_TCP 1 -#define XEN_NETIF_CTRL_HASH_TYPE_IPV4_TCP \ - (1 << _XEN_NETIF_CTRL_HASH_TYPE_IPV4_TCP) - -/* - * A hash calculated over an IP version 6 header as follows: - * - * Buffer[0..32] = Packet[8..23] (source address ) + - * Packet[24..39] (destination address) - * - * Result = Hash(Buffer, 32) - */ -#define _XEN_NETIF_CTRL_HASH_TYPE_IPV6 2 -#define XEN_NETIF_CTRL_HASH_TYPE_IPV6 \ - (1 << _XEN_NETIF_CTRL_HASH_TYPE_IPV6) - -/* - * A hash calculated over an IP version 6 header and TCP header as - * follows: - * - * Buffer[0..36] = Packet[8..23] (source address) + - * Packet[24..39] (destination address) + - * Packet[40..41] (source port) + - * Packet[42..43] (destination port) - * - * Result = Hash(Buffer, 36) - */ -#define _XEN_NETIF_CTRL_HASH_TYPE_IPV6_TCP 3 -#define XEN_NETIF_CTRL_HASH_TYPE_IPV6_TCP \ - (1 << _XEN_NETIF_CTRL_HASH_TYPE_IPV6_TCP) - -/* - * Hash algorithms - * =============== - */ - -#define XEN_NETIF_CTRL_HASH_ALGORITHM_NONE 0 - -/* - * Toeplitz hash: - */ - -#define XEN_NETIF_CTRL_HASH_ALGORITHM_TOEPLITZ 1 - -/* - * Control requests (struct xen_netif_ctrl_request) - * ================================================ - * - * All requests have the following format: - * - * 0 1 2 3 4 5 6 7 octet - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | id | type | data[0] | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | data[1] | data[2] | - * +-----+-----+-----+-----+-----------------------+ - * - * id: the request identifier, echoed in response. - * type: the type of request (see below) - * data[]: any data associated with the request (determined by type) - */ - -struct xen_netif_ctrl_request { - uint16_t id; - uint16_t type; - -#define XEN_NETIF_CTRL_TYPE_INVALID 0 -#define XEN_NETIF_CTRL_TYPE_GET_HASH_FLAGS 1 -#define XEN_NETIF_CTRL_TYPE_SET_HASH_FLAGS 2 -#define XEN_NETIF_CTRL_TYPE_SET_HASH_KEY 3 -#define XEN_NETIF_CTRL_TYPE_GET_HASH_MAPPING_SIZE 4 -#define XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING_SIZE 5 -#define XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING 6 -#define XEN_NETIF_CTRL_TYPE_SET_HASH_ALGORITHM 7 -#define XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE 8 -#define XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING 9 -#define XEN_NETIF_CTRL_TYPE_DEL_GREF_MAPPING 10 - - uint32_t data[3]; -}; - -/* - * Control responses (struct xen_netif_ctrl_response) - * ================================================== - * - * All responses have the following format: - * - * 0 1 2 3 4 5 6 7 octet - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | id | type | status | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | data | - * +-----+-----+-----+-----+ - * - * id: the corresponding request identifier - * type: the type of the corresponding request - * status: the status of request processing - * data: any data associated with the response (determined by type and - * status) - */ - -struct xen_netif_ctrl_response { - uint16_t id; - uint16_t type; - uint32_t status; - -#define XEN_NETIF_CTRL_STATUS_SUCCESS 0 -#define XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED 1 -#define XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER 2 -#define XEN_NETIF_CTRL_STATUS_BUFFER_OVERFLOW 3 - - uint32_t data; -}; - -/* - * Static Grants (struct xen_netif_gref) - * ===================================== - * - * A frontend may provide a fixed set of grant references to be mapped on - * the backend. The message of type XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING - * prior its usage in the command ring allows for creation of these mappings. - * The backend will maintain a fixed amount of these mappings. - * - * XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE lets a frontend query how many - * of these mappings can be kept. - * - * Each entry in the XEN_NETIF_CTRL_TYPE_{ADD,DEL}_GREF_MAPPING input table has - * the following format: - * - * 0 1 2 3 4 5 6 7 octet - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | grant ref | flags | status | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * - * grant ref: grant reference (IN) - * flags: flags describing the control operation (IN) - * status: XEN_NETIF_CTRL_STATUS_* (OUT) - * - * 'status' is an output parameter which does not require to be set to zero - * prior to its usage in the corresponding control messages. - */ - -struct xen_netif_gref { - grant_ref_t ref; - uint16_t flags; - -#define _XEN_NETIF_CTRLF_GREF_readonly 0 -#define XEN_NETIF_CTRLF_GREF_readonly (1U<<_XEN_NETIF_CTRLF_GREF_readonly) - - uint16_t status; -}; - -/* - * Control messages - * ================ - * - * XEN_NETIF_CTRL_TYPE_SET_HASH_ALGORITHM - * -------------------------------------- - * - * This is sent by the frontend to set the desired hash algorithm. - * - * Request: - * - * type = XEN_NETIF_CTRL_TYPE_SET_HASH_ALGORITHM - * data[0] = a XEN_NETIF_CTRL_HASH_ALGORITHM_* value - * data[1] = 0 - * data[2] = 0 - * - * Response: - * - * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not - * supported - * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - The algorithm is not - * supported - * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful - * - * NOTE: Setting data[0] to XEN_NETIF_CTRL_HASH_ALGORITHM_NONE disables - * hashing and the backend is free to choose how it steers packets - * to queues (which is the default behaviour). - * - * XEN_NETIF_CTRL_TYPE_GET_HASH_FLAGS - * ---------------------------------- - * - * This is sent by the frontend to query the types of hash supported by - * the backend. - * - * Request: - * - * type = XEN_NETIF_CTRL_TYPE_GET_HASH_FLAGS - * data[0] = 0 - * data[1] = 0 - * data[2] = 0 - * - * Response: - * - * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not supported - * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful - * data = supported hash types (if operation was successful) - * - * NOTE: A valid hash algorithm must be selected before this operation can - * succeed. - * - * XEN_NETIF_CTRL_TYPE_SET_HASH_FLAGS - * ---------------------------------- - * - * This is sent by the frontend to set the types of hash that the backend - * should calculate. (See above for hash type definitions). - * Note that the 'maximal' type of hash should always be chosen. For - * example, if the frontend sets both IPV4 and IPV4_TCP hash types then - * the latter hash type should be calculated for any TCP packet and the - * former only calculated for non-TCP packets. - * - * Request: - * - * type = XEN_NETIF_CTRL_TYPE_SET_HASH_FLAGS - * data[0] = bitwise OR of XEN_NETIF_CTRL_HASH_TYPE_* values - * data[1] = 0 - * data[2] = 0 - * - * Response: - * - * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not - * supported - * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - One or more flag - * value is invalid or - * unsupported - * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful - * data = 0 - * - * NOTE: A valid hash algorithm must be selected before this operation can - * succeed. - * Also, setting data[0] to zero disables hashing and the backend - * is free to choose how it steers packets to queues. - * - * XEN_NETIF_CTRL_TYPE_SET_HASH_KEY - * -------------------------------- - * - * This is sent by the frontend to set the key of the hash if the algorithm - * requires it. (See hash algorithms above). - * - * Request: - * - * type = XEN_NETIF_CTRL_TYPE_SET_HASH_KEY - * data[0] = grant reference of page containing the key (assumed to - * start at beginning of grant) - * data[1] = size of key in octets - * data[2] = 0 - * - * Response: - * - * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not - * supported - * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Key size is invalid - * XEN_NETIF_CTRL_STATUS_BUFFER_OVERFLOW - Key size is larger - * than the backend - * supports - * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful - * data = 0 - * - * NOTE: Any key octets not specified are assumed to be zero (the key - * is assumed to be empty by default) and specifying a new key - * invalidates any previous key, hence specifying a key size of - * zero will clear the key (which ensures that the calculated hash - * will always be zero). - * The maximum size of key is algorithm and backend specific, but - * is also limited by the single grant reference. - * The grant reference may be read-only and must remain valid until - * the response has been processed. - * - * XEN_NETIF_CTRL_TYPE_GET_HASH_MAPPING_SIZE - * ----------------------------------------- - * - * This is sent by the frontend to query the maximum size of mapping - * table supported by the backend. The size is specified in terms of - * table entries. - * - * Request: - * - * type = XEN_NETIF_CTRL_TYPE_GET_HASH_MAPPING_SIZE - * data[0] = 0 - * data[1] = 0 - * data[2] = 0 - * - * Response: - * - * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not supported - * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful - * data = maximum number of entries allowed in the mapping table - * (if operation was successful) or zero if a mapping table is - * not supported (i.e. hash mapping is done only by modular - * arithmetic). - * - * XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING_SIZE - * ------------------------------------- - * - * This is sent by the frontend to set the actual size of the mapping - * table to be used by the backend. The size is specified in terms of - * table entries. - * Any previous table is invalidated by this message and any new table - * is assumed to be zero filled. - * - * Request: - * - * type = XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING_SIZE - * data[0] = number of entries in mapping table - * data[1] = 0 - * data[2] = 0 - * - * Response: - * - * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not - * supported - * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Table size is invalid - * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful - * data = 0 - * - * NOTE: Setting data[0] to 0 means that hash mapping should be done - * using modular arithmetic. - * - * XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING - * ------------------------------------ - * - * This is sent by the frontend to set the content of the table mapping - * hash value to queue number. The backend should calculate the hash from - * the packet header, use it as an index into the table (modulo the size - * of the table) and then steer the packet to the queue number found at - * that index. - * - * Request: - * - * type = XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING - * data[0] = grant reference of page containing the mapping (sub-)table - * (assumed to start at beginning of grant) - * data[1] = size of (sub-)table in entries - * data[2] = offset, in entries, of sub-table within overall table - * - * Response: - * - * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not - * supported - * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Table size or content - * is invalid - * XEN_NETIF_CTRL_STATUS_BUFFER_OVERFLOW - Table size is larger - * than the backend - * supports - * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful - * data = 0 - * - * NOTE: The overall table has the following format: - * - * 0 1 2 3 4 5 6 7 octet - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | mapping[0] | mapping[1] | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | . | - * | . | - * | . | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | mapping[N-2] | mapping[N-1] | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * - * where N is specified by a XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING_SIZE - * message and each mapping must specifies a queue between 0 and - * "multi-queue-num-queues" (see above). - * The backend may support a mapping table larger than can be - * mapped by a single grant reference. Thus sub-tables within a - * larger table can be individually set by sending multiple messages - * with differing offset values. Specifying a new sub-table does not - * invalidate any table data outside that range. - * The grant reference may be read-only and must remain valid until - * the response has been processed. - * - * XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE - * ----------------------------------------- - * - * This is sent by the frontend to fetch the number of grefs that can be kept - * mapped in the backend. - * - * Request: - * - * type = XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE - * data[0] = queue index (assumed 0 for single queue) - * data[1] = 0 - * data[2] = 0 - * - * Response: - * - * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not - * supported - * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - The queue index is - * out of range - * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful - * data = maximum number of entries allowed in the gref mapping table - * (if operation was successful) or zero if it is not supported. - * - * XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING - * ------------------------------------ - * - * This is sent by the frontend for backend to map a list of grant - * references. - * - * Request: - * - * type = XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING - * data[0] = queue index - * data[1] = grant reference of page containing the mapping list - * (r/w and assumed to start at beginning of page) - * data[2] = size of list in entries - * - * Response: - * - * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not - * supported - * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Operation failed - * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful - * - * NOTE: Each entry in the input table has the format outlined - * in struct xen_netif_gref. - * Contrary to XEN_NETIF_CTRL_TYPE_DEL_GREF_MAPPING, the struct - * xen_netif_gref 'status' field is not used and therefore the response - * 'status' determines the success of this operation. In case of - * failure none of grants mappings get added in the backend. - * - * XEN_NETIF_CTRL_TYPE_DEL_GREF_MAPPING - * ------------------------------------ - * - * This is sent by the frontend for backend to unmap a list of grant - * references. - * - * Request: - * - * type = XEN_NETIF_CTRL_TYPE_DEL_GREF_MAPPING - * data[0] = queue index - * data[1] = grant reference of page containing the mapping list - * (r/w and assumed to start at beginning of page) - * data[2] = size of list in entries - * - * Response: - * - * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not - * supported - * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - Operation failed - * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful - * data = number of entries that were unmapped - * - * NOTE: Each entry in the input table has the format outlined in struct - * xen_netif_gref. - * The struct xen_netif_gref 'status' field determines if the entry - * was successfully removed. - * The entries used are only the ones representing grant references that - * were previously the subject of a XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING - * operation. Any other entries will have their status set to - * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER upon completion. - */ - -DEFINE_RING_TYPES(xen_netif_ctrl, - struct xen_netif_ctrl_request, - struct xen_netif_ctrl_response); - -/* - * Guest transmit - * ============== - * - * This is the 'wire' format for transmit (frontend -> backend) packets: - * - * Fragment 1: netif_tx_request_t - flags = NETTXF_* - * size = total packet size - * [Extra 1: netif_extra_info_t] - (only if fragment 1 flags include - * NETTXF_extra_info) - * ... - * [Extra N: netif_extra_info_t] - (only if extra N-1 flags include - * XEN_NETIF_EXTRA_MORE) - * ... - * Fragment N: netif_tx_request_t - (only if fragment N-1 flags include - * NETTXF_more_data - flags on preceding - * extras are not relevant here) - * flags = 0 - * size = fragment size - * - * NOTE: - * - * This format slightly is different from that used for receive - * (backend -> frontend) packets. Specifically, in a multi-fragment - * packet the actual size of fragment 1 can only be determined by - * subtracting the sizes of fragments 2..N from the total packet size. - * - * Ring slot size is 12 octets, however not all request/response - * structs use the full size. - * - * tx request data (netif_tx_request_t) - * ------------------------------------ - * - * 0 1 2 3 4 5 6 7 octet - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | grant ref | offset | flags | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | id | size | - * +-----+-----+-----+-----+ - * - * grant ref: Reference to buffer page. - * offset: Offset within buffer page. - * flags: NETTXF_*. - * id: request identifier, echoed in response. - * size: packet size in bytes. - * - * tx response (netif_tx_response_t) - * --------------------------------- - * - * 0 1 2 3 4 5 6 7 octet - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | id | status | unused | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | unused | - * +-----+-----+-----+-----+ - * - * id: reflects id in transmit request - * status: NETIF_RSP_* - * - * Guest receive - * ============= - * - * This is the 'wire' format for receive (backend -> frontend) packets: - * - * Fragment 1: netif_rx_request_t - flags = NETRXF_* - * size = fragment size - * [Extra 1: netif_extra_info_t] - (only if fragment 1 flags include - * NETRXF_extra_info) - * ... - * [Extra N: netif_extra_info_t] - (only if extra N-1 flags include - * XEN_NETIF_EXTRA_MORE) - * ... - * Fragment N: netif_rx_request_t - (only if fragment N-1 flags include - * NETRXF_more_data - flags on preceding - * extras are not relevant here) - * flags = 0 - * size = fragment size - * - * NOTE: - * - * This format slightly is different from that used for transmit - * (frontend -> backend) packets. Specifically, in a multi-fragment - * packet the size of the packet can only be determined by summing the - * sizes of fragments 1..N. - * - * Ring slot size is 8 octets. - * - * rx request (netif_rx_request_t) - * ------------------------------- - * - * 0 1 2 3 4 5 6 7 octet - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | id | pad | gref | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * - * id: request identifier, echoed in response. - * gref: reference to incoming granted frame. - * - * rx response (netif_rx_response_t) - * --------------------------------- - * - * 0 1 2 3 4 5 6 7 octet - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | id | offset | flags | status | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * - * id: reflects id in receive request - * offset: offset in page of start of received packet - * flags: NETRXF_* - * status: -ve: NETIF_RSP_*; +ve: Rx'ed pkt size. - * - * NOTE: Historically, to support GSO on the frontend receive side, Linux - * netfront does not make use of the rx response id (because, as - * described below, extra info structures overlay the id field). - * Instead it assumes that responses always appear in the same ring - * slot as their corresponding request. Thus, to maintain - * compatibility, backends must make sure this is the case. - * - * Extra Info - * ========== - * - * Can be present if initial request or response has NET{T,R}XF_extra_info, - * or previous extra request has XEN_NETIF_EXTRA_MORE. - * - * The struct therefore needs to fit into either a tx or rx slot and - * is therefore limited to 8 octets. - * - * NOTE: Because extra info data overlays the usual request/response - * structures, there is no id information in the opposite direction. - * So, if an extra info overlays an rx response the frontend can - * assume that it is in the same ring slot as the request that was - * consumed to make the slot available, and the backend must ensure - * this assumption is true. - * - * extra info (netif_extra_info_t) - * ------------------------------- - * - * General format: - * - * 0 1 2 3 4 5 6 7 octet - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * |type |flags| type specific data | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * | padding for tx | - * +-----+-----+-----+-----+ - * - * type: XEN_NETIF_EXTRA_TYPE_* - * flags: XEN_NETIF_EXTRA_FLAG_* - * padding for tx: present only in the tx case due to 8 octet limit - * from rx case. Not shown in type specific entries - * below. - * - * XEN_NETIF_EXTRA_TYPE_GSO: - * - * 0 1 2 3 4 5 6 7 octet - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * |type |flags| size |type | pad | features | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * - * type: Must be XEN_NETIF_EXTRA_TYPE_GSO - * flags: XEN_NETIF_EXTRA_FLAG_* - * size: Maximum payload size of each segment. For example, - * for TCP this is just the path MSS. - * type: XEN_NETIF_GSO_TYPE_*: This determines the protocol of - * the packet and any extra features required to segment the - * packet properly. - * features: EN_NETIF_GSO_FEAT_*: This specifies any extra GSO - * features required to process this packet, such as ECN - * support for TCPv4. - * - * XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL}: - * - * 0 1 2 3 4 5 6 7 octet - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * |type |flags| addr | - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * - * type: Must be XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL} - * flags: XEN_NETIF_EXTRA_FLAG_* - * addr: address to add/remove - * - * XEN_NETIF_EXTRA_TYPE_HASH: - * - * A backend that supports teoplitz hashing is assumed to accept - * this type of extra info in transmit packets. - * A frontend that enables hashing is assumed to accept - * this type of extra info in receive packets. - * - * 0 1 2 3 4 5 6 7 octet - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * |type |flags|htype| alg |LSB ---- value ---- MSB| - * +-----+-----+-----+-----+-----+-----+-----+-----+ - * - * type: Must be XEN_NETIF_EXTRA_TYPE_HASH - * flags: XEN_NETIF_EXTRA_FLAG_* - * htype: Hash type (one of _XEN_NETIF_CTRL_HASH_TYPE_* - see above) - * alg: The algorithm used to calculate the hash (one of - * XEN_NETIF_CTRL_HASH_TYPE_ALGORITHM_* - see above) - * value: Hash value - */ - -/* Protocol checksum field is blank in the packet (hardware offload)? */ -#define _NETTXF_csum_blank (0) -#define NETTXF_csum_blank (1U<<_NETTXF_csum_blank) - -/* Packet data has been validated against protocol checksum. */ -#define _NETTXF_data_validated (1) -#define NETTXF_data_validated (1U<<_NETTXF_data_validated) - -/* Packet continues in the next request descriptor. */ -#define _NETTXF_more_data (2) -#define NETTXF_more_data (1U<<_NETTXF_more_data) - -/* Packet to be followed by extra descriptor(s). */ -#define _NETTXF_extra_info (3) -#define NETTXF_extra_info (1U<<_NETTXF_extra_info) - -#define XEN_NETIF_MAX_TX_SIZE 0xFFFF -struct netif_tx_request { - grant_ref_t gref; - uint16_t offset; - uint16_t flags; - uint16_t id; - uint16_t size; -}; -typedef struct netif_tx_request netif_tx_request_t; - -/* Types of netif_extra_info descriptors. */ -#define XEN_NETIF_EXTRA_TYPE_NONE (0) /* Never used - invalid */ -#define XEN_NETIF_EXTRA_TYPE_GSO (1) /* u.gso */ -#define XEN_NETIF_EXTRA_TYPE_MCAST_ADD (2) /* u.mcast */ -#define XEN_NETIF_EXTRA_TYPE_MCAST_DEL (3) /* u.mcast */ -#define XEN_NETIF_EXTRA_TYPE_HASH (4) /* u.hash */ -#define XEN_NETIF_EXTRA_TYPE_MAX (5) - -/* netif_extra_info_t flags. */ -#define _XEN_NETIF_EXTRA_FLAG_MORE (0) -#define XEN_NETIF_EXTRA_FLAG_MORE (1U<<_XEN_NETIF_EXTRA_FLAG_MORE) - -/* GSO types */ -#define XEN_NETIF_GSO_TYPE_NONE (0) -#define XEN_NETIF_GSO_TYPE_TCPV4 (1) -#define XEN_NETIF_GSO_TYPE_TCPV6 (2) - -/* - * This structure needs to fit within both netif_tx_request_t and - * netif_rx_response_t for compatibility. - */ -struct netif_extra_info { - uint8_t type; - uint8_t flags; - union { - struct { - uint16_t size; - uint8_t type; - uint8_t pad; - uint16_t features; - } gso; - struct { - uint8_t addr[6]; - } mcast; - struct { - uint8_t type; - uint8_t algorithm; - uint8_t value[4]; - } hash; - uint16_t pad[3]; - } u; -}; -typedef struct netif_extra_info netif_extra_info_t; - -struct netif_tx_response { - uint16_t id; - int16_t status; -}; -typedef struct netif_tx_response netif_tx_response_t; - -struct netif_rx_request { - uint16_t id; /* Echoed in response message. */ - uint16_t pad; - grant_ref_t gref; -}; -typedef struct netif_rx_request netif_rx_request_t; - -/* Packet data has been validated against protocol checksum. */ -#define _NETRXF_data_validated (0) -#define NETRXF_data_validated (1U<<_NETRXF_data_validated) - -/* Protocol checksum field is blank in the packet (hardware offload)? */ -#define _NETRXF_csum_blank (1) -#define NETRXF_csum_blank (1U<<_NETRXF_csum_blank) - -/* Packet continues in the next request descriptor. */ -#define _NETRXF_more_data (2) -#define NETRXF_more_data (1U<<_NETRXF_more_data) - -/* Packet to be followed by extra descriptor(s). */ -#define _NETRXF_extra_info (3) -#define NETRXF_extra_info (1U<<_NETRXF_extra_info) - -/* Packet has GSO prefix. Deprecated but included for compatibility */ -#define _NETRXF_gso_prefix (4) -#define NETRXF_gso_prefix (1U<<_NETRXF_gso_prefix) - -struct netif_rx_response { - uint16_t id; - uint16_t offset; - uint16_t flags; - int16_t status; -}; -typedef struct netif_rx_response netif_rx_response_t; - -/* - * Generate netif ring structures and types. - */ - -DEFINE_RING_TYPES(netif_tx, struct netif_tx_request, struct netif_tx_response); -DEFINE_RING_TYPES(netif_rx, struct netif_rx_request, struct netif_rx_response); - -#define NETIF_RSP_DROPPED -2 -#define NETIF_RSP_ERROR -1 -#define NETIF_RSP_OKAY 0 -/* No response: used for auxiliary requests (e.g., netif_extra_info_t). */ -#define NETIF_RSP_NULL 1 - -#endif diff --git a/include/hw/xen/interface/io/protocols.h b/include/hw/xen/interface/io/protocols.h deleted file mode 100644 index 52b4de0f81..0000000000 --- a/include/hw/xen/interface/io/protocols.h +++ /dev/null @@ -1,42 +0,0 @@ -/****************************************************************************** - * protocols.h - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to - * deal in the Software without restriction, including without limitation the - * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. - * - * Copyright (c) 2008, Keir Fraser - */ - -#ifndef __XEN_PROTOCOLS_H__ -#define __XEN_PROTOCOLS_H__ - -#define XEN_IO_PROTO_ABI_X86_32 "x86_32-abi" -#define XEN_IO_PROTO_ABI_X86_64 "x86_64-abi" -#define XEN_IO_PROTO_ABI_ARM "arm-abi" - -#if defined(__i386__) -# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32 -#elif defined(__x86_64__) -# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_64 -#elif defined(__arm__) || defined(__aarch64__) -# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM -#else -# error arch fixup needed here -#endif - -#endif diff --git a/include/hw/xen/interface/io/ring.h b/include/hw/xen/interface/io/ring.h deleted file mode 100644 index 115705f3f4..0000000000 --- a/include/hw/xen/interface/io/ring.h +++ /dev/null @@ -1,474 +0,0 @@ -/****************************************************************************** - * ring.h - * - * Shared producer-consumer ring macros. - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to - * deal in the Software without restriction, including without limitation the - * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. - * - * Tim Deegan and Andrew Warfield November 2004. - */ - -#ifndef __XEN_PUBLIC_IO_RING_H__ -#define __XEN_PUBLIC_IO_RING_H__ - -/* - * When #include'ing this header, you need to provide the following - * declaration upfront: - * - standard integers types (uint8_t, uint16_t, etc) - * They are provided by stdint.h of the standard headers. - * - * Before using the different macros, you need to provide the following - * macros: - * - xen_mb() a memory barrier - * - xen_rmb() a read memory barrier - * - xen_wmb() a write memory barrier - * Example of those can be found in xenctrl.h. - * - * In addition, if you intend to use the FLEX macros, you also need to - * provide the following, before invoking the FLEX macros: - * - size_t - * - memcpy - * - grant_ref_t - * These declarations are provided by string.h of the standard headers, - * and grant_table.h from the Xen public headers. - */ - -typedef unsigned int RING_IDX; - -/* Round a 32-bit unsigned constant down to the nearest power of two. */ -#define __RD2(_x) (((_x) & 0x00000002) ? 0x2 : ((_x) & 0x1)) -#define __RD4(_x) (((_x) & 0x0000000c) ? __RD2((_x)>>2)<<2 : __RD2(_x)) -#define __RD8(_x) (((_x) & 0x000000f0) ? __RD4((_x)>>4)<<4 : __RD4(_x)) -#define __RD16(_x) (((_x) & 0x0000ff00) ? __RD8((_x)>>8)<<8 : __RD8(_x)) -#define __RD32(_x) (((_x) & 0xffff0000) ? __RD16((_x)>>16)<<16 : __RD16(_x)) - -/* - * Calculate size of a shared ring, given the total available space for the - * ring and indexes (_sz), and the name tag of the request/response structure. - * A ring contains as many entries as will fit, rounded down to the nearest - * power of two (so we can mask with (size-1) to loop around). - */ -#define __CONST_RING_SIZE(_s, _sz) \ - (__RD32(((_sz) - offsetof(struct _s##_sring, ring)) / \ - sizeof_field(struct _s##_sring, ring[0]))) -/* - * The same for passing in an actual pointer instead of a name tag. - */ -#define __RING_SIZE(_s, _sz) \ - (__RD32(((_sz) - (long)(_s)->ring + (long)(_s)) / sizeof((_s)->ring[0]))) - -/* - * Macros to make the correct C datatypes for a new kind of ring. - * - * To make a new ring datatype, you need to have two message structures, - * let's say request_t, and response_t already defined. - * - * In a header where you want the ring datatype declared, you then do: - * - * DEFINE_RING_TYPES(mytag, request_t, response_t); - * - * These expand out to give you a set of types, as you can see below. - * The most important of these are: - * - * mytag_sring_t - The shared ring. - * mytag_front_ring_t - The 'front' half of the ring. - * mytag_back_ring_t - The 'back' half of the ring. - * - * To initialize a ring in your code you need to know the location and size - * of the shared memory area (PAGE_SIZE, for instance). To initialise - * the front half: - * - * mytag_front_ring_t front_ring; - * SHARED_RING_INIT((mytag_sring_t *)shared_page); - * FRONT_RING_INIT(&front_ring, (mytag_sring_t *)shared_page, PAGE_SIZE); - * - * Initializing the back follows similarly (note that only the front - * initializes the shared ring): - * - * mytag_back_ring_t back_ring; - * BACK_RING_INIT(&back_ring, (mytag_sring_t *)shared_page, PAGE_SIZE); - */ - -#define DEFINE_RING_TYPES(__name, __req_t, __rsp_t) \ - \ -/* Shared ring entry */ \ -union __name##_sring_entry { \ - __req_t req; \ - __rsp_t rsp; \ -}; \ - \ -/* Shared ring page */ \ -struct __name##_sring { \ - RING_IDX req_prod, req_event; \ - RING_IDX rsp_prod, rsp_event; \ - union { \ - struct { \ - uint8_t smartpoll_active; \ - } netif; \ - struct { \ - uint8_t msg; \ - } tapif_user; \ - uint8_t pvt_pad[4]; \ - } pvt; \ - uint8_t __pad[44]; \ - union __name##_sring_entry ring[1]; /* variable-length */ \ -}; \ - \ -/* "Front" end's private variables */ \ -struct __name##_front_ring { \ - RING_IDX req_prod_pvt; \ - RING_IDX rsp_cons; \ - unsigned int nr_ents; \ - struct __name##_sring *sring; \ -}; \ - \ -/* "Back" end's private variables */ \ -struct __name##_back_ring { \ - RING_IDX rsp_prod_pvt; \ - RING_IDX req_cons; \ - unsigned int nr_ents; \ - struct __name##_sring *sring; \ -}; \ - \ -/* Syntactic sugar */ \ -typedef struct __name##_sring __name##_sring_t; \ -typedef struct __name##_front_ring __name##_front_ring_t; \ -typedef struct __name##_back_ring __name##_back_ring_t - -/* - * Macros for manipulating rings. - * - * FRONT_RING_whatever works on the "front end" of a ring: here - * requests are pushed on to the ring and responses taken off it. - * - * BACK_RING_whatever works on the "back end" of a ring: here - * requests are taken off the ring and responses put on. - * - * N.B. these macros do NO INTERLOCKS OR FLOW CONTROL. - * This is OK in 1-for-1 request-response situations where the - * requestor (front end) never has more than RING_SIZE()-1 - * outstanding requests. - */ - -/* Initialising empty rings */ -#define SHARED_RING_INIT(_s) do { \ - (_s)->req_prod = (_s)->rsp_prod = 0; \ - (_s)->req_event = (_s)->rsp_event = 1; \ - (void)memset((_s)->pvt.pvt_pad, 0, sizeof((_s)->pvt.pvt_pad)); \ - (void)memset((_s)->__pad, 0, sizeof((_s)->__pad)); \ -} while(0) - -#define FRONT_RING_INIT(_r, _s, __size) do { \ - (_r)->req_prod_pvt = 0; \ - (_r)->rsp_cons = 0; \ - (_r)->nr_ents = __RING_SIZE(_s, __size); \ - (_r)->sring = (_s); \ -} while (0) - -#define BACK_RING_INIT(_r, _s, __size) do { \ - (_r)->rsp_prod_pvt = 0; \ - (_r)->req_cons = 0; \ - (_r)->nr_ents = __RING_SIZE(_s, __size); \ - (_r)->sring = (_s); \ -} while (0) - -/* How big is this ring? */ -#define RING_SIZE(_r) \ - ((_r)->nr_ents) - -/* Number of free requests (for use on front side only). */ -#define RING_FREE_REQUESTS(_r) \ - (RING_SIZE(_r) - ((_r)->req_prod_pvt - (_r)->rsp_cons)) - -/* Test if there is an empty slot available on the front ring. - * (This is only meaningful from the front. ) - */ -#define RING_FULL(_r) \ - (RING_FREE_REQUESTS(_r) == 0) - -/* Test if there are outstanding messages to be processed on a ring. */ -#define RING_HAS_UNCONSUMED_RESPONSES(_r) \ - ((_r)->sring->rsp_prod - (_r)->rsp_cons) - -#define RING_HAS_UNCONSUMED_REQUESTS(_r) ({ \ - unsigned int req = (_r)->sring->req_prod - (_r)->req_cons; \ - unsigned int rsp = RING_SIZE(_r) - \ - ((_r)->req_cons - (_r)->rsp_prod_pvt); \ - req < rsp ? req : rsp; \ -}) - -/* Direct access to individual ring elements, by index. */ -#define RING_GET_REQUEST(_r, _idx) \ - (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req)) - -/* - * Get a local copy of a request. - * - * Use this in preference to RING_GET_REQUEST() so all processing is - * done on a local copy that cannot be modified by the other end. - * - * Note that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 may cause this - * to be ineffective where _req is a struct which consists of only bitfields. - */ -#define RING_COPY_REQUEST(_r, _idx, _req) do { \ - /* Use volatile to force the copy into _req. */ \ - *(_req) = *(volatile typeof(_req))RING_GET_REQUEST(_r, _idx); \ -} while (0) - -#define RING_GET_RESPONSE(_r, _idx) \ - (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].rsp)) - -/* Loop termination condition: Would the specified index overflow the ring? */ -#define RING_REQUEST_CONS_OVERFLOW(_r, _cons) \ - (((_cons) - (_r)->rsp_prod_pvt) >= RING_SIZE(_r)) - -/* Ill-behaved frontend determination: Can there be this many requests? */ -#define RING_REQUEST_PROD_OVERFLOW(_r, _prod) \ - (((_prod) - (_r)->rsp_prod_pvt) > RING_SIZE(_r)) - -#define RING_PUSH_REQUESTS(_r) do { \ - xen_wmb(); /* back sees requests /before/ updated producer index */ \ - (_r)->sring->req_prod = (_r)->req_prod_pvt; \ -} while (0) - -#define RING_PUSH_RESPONSES(_r) do { \ - xen_wmb(); /* front sees resps /before/ updated producer index */ \ - (_r)->sring->rsp_prod = (_r)->rsp_prod_pvt; \ -} while (0) - -/* - * Notification hold-off (req_event and rsp_event): - * - * When queueing requests or responses on a shared ring, it may not always be - * necessary to notify the remote end. For example, if requests are in flight - * in a backend, the front may be able to queue further requests without - * notifying the back (if the back checks for new requests when it queues - * responses). - * - * When enqueuing requests or responses: - * - * Use RING_PUSH_{REQUESTS,RESPONSES}_AND_CHECK_NOTIFY(). The second argument - * is a boolean return value. True indicates that the receiver requires an - * asynchronous notification. - * - * After dequeuing requests or responses (before sleeping the connection): - * - * Use RING_FINAL_CHECK_FOR_REQUESTS() or RING_FINAL_CHECK_FOR_RESPONSES(). - * The second argument is a boolean return value. True indicates that there - * are pending messages on the ring (i.e., the connection should not be put - * to sleep). - * - * These macros will set the req_event/rsp_event field to trigger a - * notification on the very next message that is enqueued. If you want to - * create batches of work (i.e., only receive a notification after several - * messages have been enqueued) then you will need to create a customised - * version of the FINAL_CHECK macro in your own code, which sets the event - * field appropriately. - */ - -#define RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(_r, _notify) do { \ - RING_IDX __old = (_r)->sring->req_prod; \ - RING_IDX __new = (_r)->req_prod_pvt; \ - xen_wmb(); /* back sees requests /before/ updated producer index */ \ - (_r)->sring->req_prod = __new; \ - xen_mb(); /* back sees new requests /before/ we check req_event */ \ - (_notify) = ((RING_IDX)(__new - (_r)->sring->req_event) < \ - (RING_IDX)(__new - __old)); \ -} while (0) - -#define RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(_r, _notify) do { \ - RING_IDX __old = (_r)->sring->rsp_prod; \ - RING_IDX __new = (_r)->rsp_prod_pvt; \ - xen_wmb(); /* front sees resps /before/ updated producer index */ \ - (_r)->sring->rsp_prod = __new; \ - xen_mb(); /* front sees new resps /before/ we check rsp_event */ \ - (_notify) = ((RING_IDX)(__new - (_r)->sring->rsp_event) < \ - (RING_IDX)(__new - __old)); \ -} while (0) - -#define RING_FINAL_CHECK_FOR_REQUESTS(_r, _work_to_do) do { \ - (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r); \ - if (_work_to_do) break; \ - (_r)->sring->req_event = (_r)->req_cons + 1; \ - xen_mb(); \ - (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r); \ -} while (0) - -#define RING_FINAL_CHECK_FOR_RESPONSES(_r, _work_to_do) do { \ - (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r); \ - if (_work_to_do) break; \ - (_r)->sring->rsp_event = (_r)->rsp_cons + 1; \ - xen_mb(); \ - (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r); \ -} while (0) - - -/* - * DEFINE_XEN_FLEX_RING_AND_INTF defines two monodirectional rings and - * functions to check if there is data on the ring, and to read and - * write to them. - * - * DEFINE_XEN_FLEX_RING is similar to DEFINE_XEN_FLEX_RING_AND_INTF, but - * does not define the indexes page. As different protocols can have - * extensions to the basic format, this macro allow them to define their - * own struct. - * - * XEN_FLEX_RING_SIZE - * Convenience macro to calculate the size of one of the two rings - * from the overall order. - * - * $NAME_mask - * Function to apply the size mask to an index, to reduce the index - * within the range [0-size]. - * - * $NAME_read_packet - * Function to read data from the ring. The amount of data to read is - * specified by the "size" argument. - * - * $NAME_write_packet - * Function to write data to the ring. The amount of data to write is - * specified by the "size" argument. - * - * $NAME_get_ring_ptr - * Convenience function that returns a pointer to read/write to the - * ring at the right location. - * - * $NAME_data_intf - * Indexes page, shared between frontend and backend. It also - * contains the array of grant refs. - * - * $NAME_queued - * Function to calculate how many bytes are currently on the ring, - * ready to be read. It can also be used to calculate how much free - * space is currently on the ring (XEN_FLEX_RING_SIZE() - - * $NAME_queued()). - */ - -#ifndef XEN_PAGE_SHIFT -/* The PAGE_SIZE for ring protocols and hypercall interfaces is always - * 4K, regardless of the architecture, and page granularity chosen by - * operating systems. - */ -#define XEN_PAGE_SHIFT 12 -#endif -#define XEN_FLEX_RING_SIZE(order) \ - (1UL << ((order) + XEN_PAGE_SHIFT - 1)) - -#define DEFINE_XEN_FLEX_RING(name) \ -static inline RING_IDX name##_mask(RING_IDX idx, RING_IDX ring_size) \ -{ \ - return idx & (ring_size - 1); \ -} \ - \ -static inline unsigned char *name##_get_ring_ptr(unsigned char *buf, \ - RING_IDX idx, \ - RING_IDX ring_size) \ -{ \ - return buf + name##_mask(idx, ring_size); \ -} \ - \ -static inline void name##_read_packet(void *opaque, \ - const unsigned char *buf, \ - size_t size, \ - RING_IDX masked_prod, \ - RING_IDX *masked_cons, \ - RING_IDX ring_size) \ -{ \ - if (*masked_cons < masked_prod || \ - size <= ring_size - *masked_cons) { \ - memcpy(opaque, buf + *masked_cons, size); \ - } else { \ - memcpy(opaque, buf + *masked_cons, ring_size - *masked_cons); \ - memcpy((unsigned char *)opaque + ring_size - *masked_cons, buf, \ - size - (ring_size - *masked_cons)); \ - } \ - *masked_cons = name##_mask(*masked_cons + size, ring_size); \ -} \ - \ -static inline void name##_write_packet(unsigned char *buf, \ - const void *opaque, \ - size_t size, \ - RING_IDX *masked_prod, \ - RING_IDX masked_cons, \ - RING_IDX ring_size) \ -{ \ - if (*masked_prod < masked_cons || \ - size <= ring_size - *masked_prod) { \ - memcpy(buf + *masked_prod, opaque, size); \ - } else { \ - memcpy(buf + *masked_prod, opaque, ring_size - *masked_prod); \ - memcpy(buf, (unsigned char *)opaque + (ring_size - *masked_prod), \ - size - (ring_size - *masked_prod)); \ - } \ - *masked_prod = name##_mask(*masked_prod + size, ring_size); \ -} \ - \ -static inline RING_IDX name##_queued(RING_IDX prod, \ - RING_IDX cons, \ - RING_IDX ring_size) \ -{ \ - RING_IDX size; \ - \ - if (prod == cons) \ - return 0; \ - \ - prod = name##_mask(prod, ring_size); \ - cons = name##_mask(cons, ring_size); \ - \ - if (prod == cons) \ - return ring_size; \ - \ - if (prod > cons) \ - size = prod - cons; \ - else \ - size = ring_size - (cons - prod); \ - return size; \ -} \ - \ -struct name##_data { \ - unsigned char *in; /* half of the allocation */ \ - unsigned char *out; /* half of the allocation */ \ -} - -#define DEFINE_XEN_FLEX_RING_AND_INTF(name) \ -struct name##_data_intf { \ - RING_IDX in_cons, in_prod; \ - \ - uint8_t pad1[56]; \ - \ - RING_IDX out_cons, out_prod; \ - \ - uint8_t pad2[56]; \ - \ - RING_IDX ring_order; \ - grant_ref_t ref[]; \ -}; \ -DEFINE_XEN_FLEX_RING(name) - -#endif /* __XEN_PUBLIC_IO_RING_H__ */ - -/* - * Local variables: - * mode: C - * c-file-style: "BSD" - * c-basic-offset: 4 - * tab-width: 4 - * indent-tabs-mode: nil - * End: - */ diff --git a/include/hw/xen/interface/io/usbif.h b/include/hw/xen/interface/io/usbif.h deleted file mode 100644 index c6a58639d6..0000000000 --- a/include/hw/xen/interface/io/usbif.h +++ /dev/null @@ -1,254 +0,0 @@ -/* - * usbif.h - * - * USB I/O interface for Xen guest OSes. - * - * Copyright (C) 2009, FUJITSU LABORATORIES LTD. - * Author: Noboru Iwamatsu - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to - * deal in the Software without restriction, including without limitation the - * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. - */ - -#ifndef __XEN_PUBLIC_IO_USBIF_H__ -#define __XEN_PUBLIC_IO_USBIF_H__ - -#include "ring.h" -#include "../grant_table.h" - -/* - * Feature and Parameter Negotiation - * ================================= - * The two halves of a Xen pvUSB driver utilize nodes within the XenStore to - * communicate capabilities and to negotiate operating parameters. This - * section enumerates these nodes which reside in the respective front and - * backend portions of the XenStore, following the XenBus convention. - * - * Any specified default value is in effect if the corresponding XenBus node - * is not present in the XenStore. - * - * XenStore nodes in sections marked "PRIVATE" are solely for use by the - * driver side whose XenBus tree contains them. - * - ***************************************************************************** - * Backend XenBus Nodes - ***************************************************************************** - * - *------------------ Backend Device Identification (PRIVATE) ------------------ - * - * num-ports - * Values: unsigned [1...31] - * - * Number of ports for this (virtual) USB host connector. - * - * usb-ver - * Values: unsigned [1...2] - * - * USB version of this host connector: 1 = USB 1.1, 2 = USB 2.0. - * - * port/[1...31] - * Values: string - * - * Physical USB device connected to the given port, e.g. "3-1.5". - * - ***************************************************************************** - * Frontend XenBus Nodes - ***************************************************************************** - * - *----------------------- Request Transport Parameters ----------------------- - * - * event-channel - * Values: unsigned - * - * The identifier of the Xen event channel used to signal activity - * in the ring buffer. - * - * urb-ring-ref - * Values: unsigned - * - * The Xen grant reference granting permission for the backend to map - * the sole page in a single page sized ring buffer. This is the ring - * buffer for urb requests. - * - * conn-ring-ref - * Values: unsigned - * - * The Xen grant reference granting permission for the backend to map - * the sole page in a single page sized ring buffer. This is the ring - * buffer for connection/disconnection requests. - * - * protocol - * Values: string (XEN_IO_PROTO_ABI_*) - * Default Value: XEN_IO_PROTO_ABI_NATIVE - * - * The machine ABI rules governing the format of all ring request and - * response structures. - * - */ - -enum usb_spec_version { - USB_VER_UNKNOWN = 0, - USB_VER_USB11, - USB_VER_USB20, - USB_VER_USB30, /* not supported yet */ -}; - -/* - * USB pipe in usbif_request - * - * - port number: bits 0-4 - * (USB_MAXCHILDREN is 31) - * - * - operation flag: bit 5 - * (0 = submit urb, - * 1 = unlink urb) - * - * - direction: bit 7 - * (0 = Host-to-Device [Out] - * 1 = Device-to-Host [In]) - * - * - device address: bits 8-14 - * - * - endpoint: bits 15-18 - * - * - pipe type: bits 30-31 - * (00 = isochronous, 01 = interrupt, - * 10 = control, 11 = bulk) - */ - -#define USBIF_PIPE_PORT_MASK 0x0000001f -#define USBIF_PIPE_UNLINK 0x00000020 -#define USBIF_PIPE_DIR 0x00000080 -#define USBIF_PIPE_DEV_MASK 0x0000007f -#define USBIF_PIPE_DEV_SHIFT 8 -#define USBIF_PIPE_EP_MASK 0x0000000f -#define USBIF_PIPE_EP_SHIFT 15 -#define USBIF_PIPE_TYPE_MASK 0x00000003 -#define USBIF_PIPE_TYPE_SHIFT 30 -#define USBIF_PIPE_TYPE_ISOC 0 -#define USBIF_PIPE_TYPE_INT 1 -#define USBIF_PIPE_TYPE_CTRL 2 -#define USBIF_PIPE_TYPE_BULK 3 - -#define usbif_pipeportnum(pipe) ((pipe) & USBIF_PIPE_PORT_MASK) -#define usbif_setportnum_pipe(pipe, portnum) ((pipe) | (portnum)) - -#define usbif_pipeunlink(pipe) ((pipe) & USBIF_PIPE_UNLINK) -#define usbif_pipesubmit(pipe) (!usbif_pipeunlink(pipe)) -#define usbif_setunlink_pipe(pipe) ((pipe) | USBIF_PIPE_UNLINK) - -#define usbif_pipein(pipe) ((pipe) & USBIF_PIPE_DIR) -#define usbif_pipeout(pipe) (!usbif_pipein(pipe)) - -#define usbif_pipedevice(pipe) \ - (((pipe) >> USBIF_PIPE_DEV_SHIFT) & USBIF_PIPE_DEV_MASK) - -#define usbif_pipeendpoint(pipe) \ - (((pipe) >> USBIF_PIPE_EP_SHIFT) & USBIF_PIPE_EP_MASK) - -#define usbif_pipetype(pipe) \ - (((pipe) >> USBIF_PIPE_TYPE_SHIFT) & USBIF_PIPE_TYPE_MASK) -#define usbif_pipeisoc(pipe) (usbif_pipetype(pipe) == USBIF_PIPE_TYPE_ISOC) -#define usbif_pipeint(pipe) (usbif_pipetype(pipe) == USBIF_PIPE_TYPE_INT) -#define usbif_pipectrl(pipe) (usbif_pipetype(pipe) == USBIF_PIPE_TYPE_CTRL) -#define usbif_pipebulk(pipe) (usbif_pipetype(pipe) == USBIF_PIPE_TYPE_BULK) - -#define USBIF_MAX_SEGMENTS_PER_REQUEST (16) -#define USBIF_MAX_PORTNR 31 -#define USBIF_RING_SIZE 4096 - -/* - * RING for transferring urbs. - */ -struct usbif_request_segment { - grant_ref_t gref; - uint16_t offset; - uint16_t length; -}; - -struct usbif_urb_request { - uint16_t id; /* request id */ - uint16_t nr_buffer_segs; /* number of urb->transfer_buffer segments */ - - /* basic urb parameter */ - uint32_t pipe; - uint16_t transfer_flags; -#define USBIF_SHORT_NOT_OK 0x0001 - uint16_t buffer_length; - union { - uint8_t ctrl[8]; /* setup_packet (Ctrl) */ - - struct { - uint16_t interval; /* maximum (1024*8) in usb core */ - uint16_t start_frame; /* start frame */ - uint16_t number_of_packets; /* number of ISO packet */ - uint16_t nr_frame_desc_segs; /* number of iso_frame_desc segments */ - } isoc; - - struct { - uint16_t interval; /* maximum (1024*8) in usb core */ - uint16_t pad[3]; - } intr; - - struct { - uint16_t unlink_id; /* unlink request id */ - uint16_t pad[3]; - } unlink; - - } u; - - /* urb data segments */ - struct usbif_request_segment seg[USBIF_MAX_SEGMENTS_PER_REQUEST]; -}; -typedef struct usbif_urb_request usbif_urb_request_t; - -struct usbif_urb_response { - uint16_t id; /* request id */ - uint16_t start_frame; /* start frame (ISO) */ - int32_t status; /* status (non-ISO) */ - int32_t actual_length; /* actual transfer length */ - int32_t error_count; /* number of ISO errors */ -}; -typedef struct usbif_urb_response usbif_urb_response_t; - -DEFINE_RING_TYPES(usbif_urb, struct usbif_urb_request, struct usbif_urb_response); -#define USB_URB_RING_SIZE __CONST_RING_SIZE(usbif_urb, USBIF_RING_SIZE) - -/* - * RING for notifying connect/disconnect events to frontend - */ -struct usbif_conn_request { - uint16_t id; -}; -typedef struct usbif_conn_request usbif_conn_request_t; - -struct usbif_conn_response { - uint16_t id; /* request id */ - uint8_t portnum; /* port number */ - uint8_t speed; /* usb_device_speed */ -#define USBIF_SPEED_NONE 0 -#define USBIF_SPEED_LOW 1 -#define USBIF_SPEED_FULL 2 -#define USBIF_SPEED_HIGH 3 -}; -typedef struct usbif_conn_response usbif_conn_response_t; - -DEFINE_RING_TYPES(usbif_conn, struct usbif_conn_request, struct usbif_conn_response); -#define USB_CONN_RING_SIZE __CONST_RING_SIZE(usbif_conn, USBIF_RING_SIZE) - -#endif /* __XEN_PUBLIC_IO_USBIF_H__ */ diff --git a/include/hw/xen/interface/io/xenbus.h b/include/hw/xen/interface/io/xenbus.h deleted file mode 100644 index 2fbf2a7fdc..0000000000 --- a/include/hw/xen/interface/io/xenbus.h +++ /dev/null @@ -1,70 +0,0 @@ -/***************************************************************************** - * xenbus.h - * - * Xenbus protocol details. - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to - * deal in the Software without restriction, including without limitation the - * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. - * - * Copyright (C) 2005 XenSource Ltd. - */ - -#ifndef _XEN_PUBLIC_IO_XENBUS_H -#define _XEN_PUBLIC_IO_XENBUS_H - -/* - * The state of either end of the Xenbus, i.e. the current communication - * status of initialisation across the bus. States here imply nothing about - * the state of the connection between the driver and the kernel's device - * layers. - */ -enum xenbus_state { - XenbusStateUnknown = 0, - - XenbusStateInitialising = 1, - - /* - * InitWait: Finished early initialisation but waiting for information - * from the peer or hotplug scripts. - */ - XenbusStateInitWait = 2, - - /* - * Initialised: Waiting for a connection from the peer. - */ - XenbusStateInitialised = 3, - - XenbusStateConnected = 4, - - /* - * Closing: The device is being closed due to an error or an unplug event. - */ - XenbusStateClosing = 5, - - XenbusStateClosed = 6, - - /* - * Reconfiguring: The device is being reconfigured. - */ - XenbusStateReconfiguring = 7, - - XenbusStateReconfigured = 8 -}; -typedef enum xenbus_state XenbusState; - -#endif /* _XEN_PUBLIC_IO_XENBUS_H */