@@ -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
@@ -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"
@@ -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
@@ -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;
@@ -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"
@@ -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"
/* ------------------------------------------------------------- */
@@ -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
deleted file mode 100644
@@ -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__ */
deleted file mode 100644
@@ -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: <uint32_t>
- * 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: <uint32_t>
- * 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: <uint32_t>
- * 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: <uint32_t>
- * 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: <uint32_t> (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: <uint32_t>
- *
- * 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: <uint32_t>
- * 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: <uint64_t>
- *
- * 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: <uint32_t>
- *
- * The identifier of the Xen event channel used to signal activity
- * in the ring buffer.
- *
- * ring-ref
- * Values: <uint32_t>
- * 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: <uint32_t>
- * 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: <uint32_t>
- * 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: <uint32_t>
- * 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: <uint32_t>
- *
- * 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 = "<ring-ref#0>"
- * /local/domain/1/device/vbd/0/queue-0/event-channel = "<evtchn#0>"
- * /local/domain/1/device/vbd/0/queue-1 = ""
- * /local/domain/1/device/vbd/0/queue-1/ring-ref = "<ring-ref#1>"
- * /local/domain/1/device/vbd/0/queue-1/event-channel = "<evtchn#1>"
- *
- * 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 = "<ring-ref#0>"
- * /local/domain/1/device/vbd/0/queue-0/ring-ref1 = "<ring-ref#1>"
- * /local/domain/1/device/vbd/0/queue-0/event-channel = "<evtchn#0>"
- * /local/domain/1/device/vbd/0/queue-1 = ""
- * /local/domain/1/device/vbd/0/queue-1/ring-ref0 = "<ring-ref#2>"
- * /local/domain/1/device/vbd/0/queue-1/ring-ref1 = "<ring-ref#3>"
- * /local/domain/1/device/vbd/0/queue-1/event-channel = "<evtchn#1>"
- *
- */
-
-/*
- * 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__ */
deleted file mode 100644
@@ -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__ */
deleted file mode 100644
@@ -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 <aliguori@us.ibm.com>
- * Copyright (C) 2006 Red Hat, Inc., Markus Armbruster <armbru@redhat.com>
- */
-
-#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
deleted file mode 100644
@@ -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 <aliguori@us.ibm.com>
- * Copyright (C) 2006 Red Hat, Inc., Markus Armbruster <armbru@redhat.com>
- */
-
-#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: <uint>
- *
- * 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: <uint>
- *
- * 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: <uint>
- *
- * Backends, which support reporting of absolute coordinates for pointer
- * device should set this to 1.
- *
- * feature-multi-touch
- * Values: <uint>
- *
- * Backends, which support reporting of multi-touch events
- * should set this to 1.
- *
- * feature-raw-pointer
- * Values: <uint>
- *
- * 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: <string>
- *
- * 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: <uint>
- *
- * Maximum X coordinate (width) to be used by the frontend
- * while reporting input events, pixels, [0; UINT32_MAX].
- *
- * height
- * Values: <uint>
- *
- * 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: <uint>
- *
- * Number of simultaneous touches reported.
- *
- * multi-touch-width
- * Values: <uint>
- *
- * Width of the touch area to be used by the frontend
- * while reporting input events, pixels, [0; UINT32_MAX].
- *
- * multi-touch-height
- * Values: <uint>
- *
- * 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: <uint>
- *
- * Request backend to report absolute pointer coordinates
- * (XENKBD_TYPE_POS) instead of relative ones (XENKBD_TYPE_MOTION).
- *
- * request-multi-touch
- * Values: <uint>
- *
- * Request backend to report multi-touch events.
- *
- * request-raw-pointer
- * Values: <uint>
- *
- * 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: <uint>
- *
- * The identifier of the Xen event channel used to signal activity
- * in the ring buffer.
- *
- * page-gref
- * Values: <uint>
- *
- * 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: <uint>
- *
- * 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__ */
deleted file mode 100644
@@ -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 = "<ring-ref-tx0>"
- * /local/domain/1/device/vif/0/queue-0/rx-ring-ref = "<ring-ref-rx0>"
- * /local/domain/1/device/vif/0/queue-0/event-channel-tx = "<evtchn-tx0>"
- * /local/domain/1/device/vif/0/queue-0/event-channel-rx = "<evtchn-rx0>"
- * /local/domain/1/device/vif/0/queue-1 = ""
- * /local/domain/1/device/vif/0/queue-1/tx-ring-ref = "<ring-ref-tx1>"
- * /local/domain/1/device/vif/0/queue-1/rx-ring-ref = "<ring-ref-rx1"
- * /local/domain/1/device/vif/0/queue-1/event-channel-tx = "<evtchn-tx1>"
- * /local/domain/1/device/vif/0/queue-1/event-channel-rx = "<evtchn-rx1>"
- *
- * If there is any inconsistency in the XenStore data, the backend may
- * choose not to connect any queues, instead treating the request as an
- * error. This includes scenarios where more (or fewer) queues were
- * requested than the frontend provided details for.
- *
- * Mapping of packets to queues is considered to be a function of the
- * transmitting system (backend or frontend) and is not negotiated
- * between the two. Guests are free to transmit packets on any queue
- * they choose, provided it has been set up correctly. Guests must be
- * prepared to receive packets on any queue they have requested be set up.
- */
-
-/*
- * "feature-no-csum-offload" should be used to turn IPv4 TCP/UDP checksum
- * offload off or on. If it is missing then the feature is assumed to be on.
- * "feature-ipv6-csum-offload" should be used to turn IPv6 TCP/UDP checksum
- * offload on or off. If it is missing then the feature is assumed to be off.
- */
-
-/*
- * "feature-gso-tcpv4" and "feature-gso-tcpv6" advertise the capability to
- * handle large TCP packets (in IPv4 or IPv6 form respectively). Neither
- * frontends nor backends are assumed to be capable unless the flags are
- * present.
- */
-
-/*
- * "feature-multicast-control" and "feature-dynamic-multicast-control"
- * advertise the capability to filter ethernet multicast packets in the
- * backend. If the frontend wishes to take advantage of this feature then
- * it may set "request-multicast-control". If the backend only advertises
- * "feature-multicast-control" then "request-multicast-control" must be set
- * before the frontend moves into the connected state. The backend will
- * sample the value on this state transition and any subsequent change in
- * value will have no effect. However, if the backend also advertises
- * "feature-dynamic-multicast-control" then "request-multicast-control"
- * may be set by the frontend at any time. In this case, the backend will
- * watch the value and re-sample on watch events.
- *
- * If the sampled value of "request-multicast-control" is set then the
- * backend transmit side should no longer flood multicast packets to the
- * frontend, it should instead drop any multicast packet that does not
- * match in a filter list.
- * The list is amended by the frontend by sending dummy transmit requests
- * containing XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL} extra-info fragments as
- * specified below.
- * Note that the filter list may be amended even if the sampled value of
- * "request-multicast-control" is not set, however the filter should only
- * be applied if it is set.
- */
-
-/*
- * Control ring
- * ============
- *
- * Some features, such as hashing (detailed below), require a
- * significant amount of out-of-band data to be passed from frontend to
- * backend. Use of xenstore is not suitable for large quantities of data
- * because of quota limitations and so a dedicated 'control ring' is used.
- * The ability of the backend to use a control ring is advertised by
- * setting:
- *
- * /local/domain/X/backend/<domid>/<vif>/feature-ctrl-ring = "1"
- *
- * The frontend provides a control ring to the backend by setting:
- *
- * /local/domain/<domid>/device/vif/<vif>/ctrl-ring-ref = <gref>
- * /local/domain/<domid>/device/vif/<vif>/event-channel-ctrl = <port>
- *
- * where <gref> is the grant reference of the shared page used to
- * implement the control ring and <port> 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
deleted file mode 100644
@@ -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
deleted file mode 100644
@@ -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:
- */
deleted file mode 100644
@@ -1,254 +0,0 @@
-/*
- * usbif.h
- *
- * USB I/O interface for Xen guest OSes.
- *
- * Copyright (C) 2009, FUJITSU LABORATORIES LTD.
- * Author: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
- *
- * 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__ */
deleted file mode 100644
@@ -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 */