OvmfPkg: Apply uncrustify changes

[mirror_edk2.git] / OvmfPkg / Include / IndustryStandard / Xen / io / blkif.h

/******************************************************************************\r
 * blkif.h\r
 *\r
 * Unified block-device I/O interface for Xen guest OSes.\r
 *\r
 * SPDX-License-Identifier: MIT\r
 *\r
 * Copyright (c) 2003-2004, Keir Fraser\r
 * Copyright (c) 2012, Spectra Logic Corporation\r
 */\r
\r
#ifndef __XEN_PUBLIC_IO_BLKIF_H__\r
#define __XEN_PUBLIC_IO_BLKIF_H__\r
\r
#include "ring.h"\r
#include "../grant_table.h"\r
\r
/*\r
 * Front->back notifications: When enqueuing a new request, sending a\r
 * notification can be made conditional on req_event (i.e., the generic\r
 * hold-off mechanism provided by the ring macros). Backends must set\r
 * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).\r
 *\r
 * Back->front notifications: When enqueuing a new response, sending a\r
 * notification can be made conditional on rsp_event (i.e., the generic\r
 * hold-off mechanism provided by the ring macros). Frontends must set\r
 * rsp_event appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()).\r
 */\r
\r
#ifndef blkif_vdev_t\r
#define blkif_vdev_t  UINT16\r
#endif\r
#define blkif_sector_t  UINT64\r
\r
/*\r
 * Feature and Parameter Negotiation\r
 * =================================\r
 * The two halves of a Xen block driver utilize nodes within the XenStore to\r
 * communicate capabilities and to negotiate operating parameters.  This\r
 * section enumerates these nodes which reside in the respective front and\r
 * backend portions of the XenStore, following the XenBus convention.\r
 *\r
 * All data in the XenStore is stored as strings.  Nodes specifying numeric\r
 * values are encoded in decimal.  Integer value ranges listed below are\r
 * expressed as fixed sized integer types capable of storing the conversion\r
 * of a properly formatted node string, without loss of information.\r
 *\r
 * Any specified default value is in effect if the corresponding XenBus node\r
 * is not present in the XenStore.\r
 *\r
 * XenStore nodes in sections marked "PRIVATE" are solely for use by the\r
 * driver side whose XenBus tree contains them.\r
 *\r
 * XenStore nodes marked "DEPRECATED" in their notes section should only be\r
 * used to provide interoperability with legacy implementations.\r
 *\r
 * See the XenBus state transition diagram below for details on when XenBus\r
 * nodes must be published and when they can be queried.\r
 *\r
 *****************************************************************************\r
 *                            Backend XenBus Nodes\r
 *****************************************************************************\r
 *\r
 *------------------ Backend Device Identification (PRIVATE) ------------------\r
 *\r
 * mode\r
 *      Values:         "r" (read only), "w" (writable)\r
 *\r
 *      The read or write access permissions to the backing store to be\r
 *      granted to the frontend.\r
 *\r
 * params\r
 *      Values:         string\r
 *\r
 *      A free formatted string providing sufficient information for the\r
 *      backend driver to open the backing device.  (e.g. the path to the\r
 *      file or block device representing the backing store.)\r
 *\r
 * type\r
 *      Values:         "file", "phy", "tap"\r
 *\r
 *      The type of the backing device/object.\r
 *\r
 *--------------------------------- Features ---------------------------------\r
 *\r
 * feature-barrier\r
 *      Values:         0/1 (boolean)\r
 *      Default Value:  0\r
 *\r
 *      A value of "1" indicates that the backend can process requests\r
 *      containing the BLKIF_OP_WRITE_BARRIER request opcode.  Requests\r
 *      of this type may still be returned at any time with the\r
 *      BLKIF_RSP_EOPNOTSUPP result code.\r
 *\r
 * feature-flush-cache\r
 *      Values:         0/1 (boolean)\r
 *      Default Value:  0\r
 *\r
 *      A value of "1" indicates that the backend can process requests\r
 *      containing the BLKIF_OP_FLUSH_DISKCACHE request opcode.  Requests\r
 *      of this type may still be returned at any time with the\r
 *      BLKIF_RSP_EOPNOTSUPP result code.\r
 *\r
 * feature-discard\r
 *      Values:         0/1 (boolean)\r
 *      Default Value:  0\r
 *\r
 *      A value of "1" indicates that the backend can process requests\r
 *      containing the BLKIF_OP_DISCARD request opcode.  Requests\r
 *      of this type may still be returned at any time with the\r
 *      BLKIF_RSP_EOPNOTSUPP result code.\r
 *\r
 * feature-persistent\r
 *      Values:         0/1 (boolean)\r
 *      Default Value:  0\r
 *      Notes: 7\r
 *\r
 *      A value of "1" indicates that the backend can keep the grants used\r
 *      by the frontend driver mapped, so the same set of grants should be\r
 *      used in all transactions. The maximum number of grants the backend\r
 *      can map persistently depends on the implementation, but ideally it\r
 *      should be RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST. Using this\r
 *      feature the backend doesn't need to unmap each grant, preventing\r
 *      costly TLB flushes. The backend driver should only map grants\r
 *      persistently if the frontend supports it. If a backend driver chooses\r
 *      to use the persistent protocol when the frontend doesn't support it,\r
 *      it will probably hit the maximum number of persistently mapped grants\r
 *      (due to the fact that the frontend won't be reusing the same grants),\r
 *      and fall back to non-persistent mode. Backend implementations may\r
 *      shrink or expand the number of persistently mapped grants without\r
 *      notifying the frontend depending on memory constraints (this might\r
 *      cause a performance degradation).\r
 *\r
 *      If a backend driver wants to limit the maximum number of persistently\r
 *      mapped grants to a value less than RING_SIZE *\r
 *      BLKIF_MAX_SEGMENTS_PER_REQUEST a LRU strategy should be used to\r
 *      discard the grants that are less commonly used. Using a LRU in the\r
 *      backend driver paired with a LIFO queue in the frontend will\r
 *      allow us to have better performance in this scenario.\r
 *\r
 *----------------------- Request Transport Parameters ------------------------\r
 *\r
 * max-ring-page-order\r
 *      Values:         <UINT32>\r
 *      Default Value:  0\r
 *      Notes:          1, 3\r
 *\r
 *      The maximum supported size of the request ring buffer in units of\r
 *      lb(machine pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,\r
 *      etc.).\r
 *\r
 * max-ring-pages\r
 *      Values:         <UINT32>\r
 *      Default Value:  1\r
 *      Notes:          DEPRECATED, 2, 3\r
 *\r
 *      The maximum supported size of the request ring buffer in units of\r
 *      machine pages.  The value must be a power of 2.\r
 *\r
 *------------------------- Backend Device Properties -------------------------\r
 *\r
 * discard-alignment\r
 *      Values:         <UINT32>\r
 *      Default Value:  0\r
 *      Notes:          4, 5\r
 *\r
 *      The offset, in bytes from the beginning of the virtual block device,\r
 *      to the first, addressable, discard extent on the underlying device.\r
 *\r
 * discard-granularity\r
 *      Values:         <UINT32>\r
 *      Default Value:  <"sector-size">\r
 *      Notes:          4\r
 *\r
 *      The size, in bytes, of the individually addressable discard extents\r
 *      of the underlying device.\r
 *\r
 * discard-secure\r
 *      Values:         0/1 (boolean)\r
 *      Default Value:  0\r
 *      Notes:          10\r
 *\r
 *      A value of "1" indicates that the backend can process BLKIF_OP_DISCARD\r
 *      requests with the BLKIF_DISCARD_SECURE flag set.\r
 *\r
 * info\r
 *      Values:         <UINT32> (bitmap)\r
 *\r
 *      A collection of bit flags describing attributes of the backing\r
 *      device.  The VDISK_* macros define the meaning of each bit\r
 *      location.\r
 *\r
 * sector-size\r
 *      Values:         <UINT32>\r
 *\r
 *      The logical sector size, in bytes, of the backend device.\r
 *\r
 * physical-sector-size\r
 *      Values:         <UINT32>\r
 *\r
 *      The physical sector size, in bytes, of the backend device.\r
 *\r
 * sectors\r
 *      Values:         <UINT64>\r
 *\r
 *      The size of the backend device, expressed in units of its logical\r
 *      sector size ("sector-size").\r
 *\r
 *****************************************************************************\r
 *                            Frontend XenBus Nodes\r
 *****************************************************************************\r
 *\r
 *----------------------- Request Transport Parameters -----------------------\r
 *\r
 * event-channel\r
 *      Values:         <UINT32>\r
 *\r
 *      The identifier of the Xen event channel used to signal activity\r
 *      in the ring buffer.\r
 *\r
 * ring-ref\r
 *      Values:         <UINT32>\r
 *      Notes:          6\r
 *\r
 *      The Xen grant reference granting permission for the backend to map\r
 *      the sole page in a single page sized ring buffer.\r
 *\r
 * ring-ref%u\r
 *      Values:         <UINT32>\r
 *      Notes:          6\r
 *\r
 *      For a frontend providing a multi-page ring, a "number of ring pages"\r
 *      sized list of nodes, each containing a Xen grant reference granting\r
 *      permission for the backend to map the page of the ring located\r
 *      at page index "%u".  Page indexes are zero based.\r
 *\r
 * protocol\r
 *      Values:         string (XEN_IO_PROTO_ABI_*)\r
 *      Default Value:  XEN_IO_PROTO_ABI_NATIVE\r
 *\r
 *      The machine ABI rules governing the format of all ring request and\r
 *      response structures.\r
 *\r
 * ring-page-order\r
 *      Values:         <UINT32>\r
 *      Default Value:  0\r
 *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)\r
 *      Notes:          1, 3\r
 *\r
 *      The size of the frontend allocated request ring buffer in units\r
 *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,\r
 *      etc.).\r
 *\r
 * num-ring-pages\r
 *      Values:         <UINT32>\r
 *      Default Value:  1\r
 *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))\r
 *      Notes:          DEPRECATED, 2, 3\r
 *\r
 *      The size of the frontend allocated request ring buffer in units of\r
 *      machine pages.  The value must be a power of 2.\r
 *\r
 * feature-persistent\r
 *      Values:         0/1 (boolean)\r
 *      Default Value:  0\r
 *      Notes: 7, 8, 9\r
 *\r
 *      A value of "1" indicates that the frontend will reuse the same grants\r
 *      for all transactions, allowing the backend to map them with write\r
 *      access (even when it should be read-only). If the frontend hits the\r
 *      maximum number of allowed persistently mapped grants, it can fallback\r
 *      to non persistent mode. This will cause a performance degradation,\r
 *      since the backend driver will still try to map those grants\r
 *      persistently. Since the persistent grants protocol is compatible with\r
 *      the previous protocol, a frontend driver can choose to work in\r
 *      persistent mode even when the backend doesn't support it.\r
 *\r
 *      It is recommended that the frontend driver stores the persistently\r
 *      mapped grants in a LIFO queue, so a subset of all persistently mapped\r
 *      grants gets used commonly. This is done in case the backend driver\r
 *      decides to limit the maximum number of persistently mapped grants\r
 *      to a value less than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST.\r
 *\r
 *------------------------- Virtual Device Properties -------------------------\r
 *\r
 * device-type\r
 *      Values:         "disk", "cdrom", "floppy", etc.\r
 *\r
 * virtual-device\r
 *      Values:         <UINT32>\r
 *\r
 *      A value indicating the physical device to virtualize within the\r
 *      frontend's domain.  (e.g. "The first ATA disk", "The third SCSI\r
 *      disk", etc.)\r
 *\r
 *      See docs/misc/vbd-interface.txt for details on the format of this\r
 *      value.\r
 *\r
 * Notes\r
 * -----\r
 * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer\r
 *     PV drivers.\r
 * (2) Multi-page ring buffer scheme first used in some RedHat distributions\r
 *     including a distribution deployed on certain nodes of the Amazon\r
 *     EC2 cluster.\r
 * (3) Support for multi-page ring buffers was implemented independently,\r
 *     in slightly different forms, by both Citrix and RedHat/Amazon.\r
 *     For full interoperability, block front and backends should publish\r
 *     identical ring parameters, adjusted for unit differences, to the\r
 *     XenStore nodes used in both schemes.\r
 * (4) Devices that support discard functionality may internally allocate space\r
 *     (discardable extents) in units that are larger than the exported logical\r
 *     block size. If the backing device has such discardable extents the\r
 *     backend should provide both discard-granularity and discard-alignment.\r
 *     Providing just one of the two may be considered an error by the frontend.\r
 *     Backends supporting discard should include discard-granularity and\r
 *     discard-alignment even if it supports discarding individual sectors.\r
 *     Frontends should assume discard-alignment == 0 and discard-granularity\r
 *     == sector size if these keys are missing.\r
 * (5) The discard-alignment parameter allows a physical device to be\r
 *     partitioned into virtual devices that do not necessarily begin or\r
 *     end on a discardable extent boundary.\r
 * (6) When there is only a single page allocated to the request ring,\r
 *     'ring-ref' is used to communicate the grant reference for this\r
 *     page to the backend.  When using a multi-page ring, the 'ring-ref'\r
 *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.\r
 * (7) When using persistent grants data has to be copied from/to the page\r
 *     where the grant is currently mapped. The overhead of doing this copy\r
 *     however doesn't suppress the speed improvement of not having to unmap\r
 *     the grants.\r
 * (8) The frontend driver has to allow the backend driver to map all grants\r
 *     with write access, even when they should be mapped read-only, since\r
 *     further requests may reuse these grants and require write permissions.\r
 * (9) Linux implementation doesn't have a limit on the maximum number of\r
 *     grants that can be persistently mapped in the frontend driver, but\r
 *     due to the frontent driver implementation it should never be bigger\r
 *     than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST.\r
 *(10) The discard-secure property may be present and will be set to 1 if the\r
 *     backing device supports secure discard.\r
 */\r
\r
/*\r
 * STATE DIAGRAMS\r
 *\r
 *****************************************************************************\r
 *                                   Startup                                 *\r
 *****************************************************************************\r
 *\r
 * Tool stack creates front and back nodes with state XenbusStateInitialising.\r
 *\r
 * Front                                Back\r
 * =================================    =====================================\r
 * XenbusStateInitialising              XenbusStateInitialising\r
 *  o Query virtual device               o Query backend device identification\r
 *    properties.                          data.\r
 *  o Setup OS device instance.          o Open and validate backend device.\r
 *                                       o Publish backend features and\r
 *                                         transport parameters.\r
 *                                                      |\r
 *                                                      |\r
 *                                                      V\r
 *                                      XenbusStateInitWait\r
 *\r
 * o Query backend features and\r
 *   transport parameters.\r
 * o Allocate and initialize the\r
 *   request ring.\r
 * o Publish transport parameters\r
 *   that will be in effect during\r
 *   this connection.\r
 *              |\r
 *              |\r
 *              V\r
 * XenbusStateInitialised\r
 *\r
 *                                       o Query frontend transport parameters.\r
 *                                       o Connect to the request ring and\r
 *                                         event channel.\r
 *                                       o Publish backend device properties.\r
 *                                                      |\r
 *                                                      |\r
 *                                                      V\r
 *                                      XenbusStateConnected\r
 *\r
 *  o Query backend device properties.\r
 *  o Finalize OS virtual device\r
 *    instance.\r
 *              |\r
 *              |\r
 *              V\r
 * XenbusStateConnected\r
 *\r
 * Note: Drivers that do not support any optional features, or the negotiation\r
 *       of transport parameters, can skip certain states in the state machine:\r
 *\r
 *       o A frontend may transition to XenbusStateInitialised without\r
 *         waiting for the backend to enter XenbusStateInitWait.  In this\r
 *         case, default transport parameters are in effect and any\r
 *         transport parameters published by the frontend must contain\r
 *         their default values.\r
 *\r
 *       o A backend may transition to XenbusStateInitialised, bypassing\r
 *         XenbusStateInitWait, without waiting for the frontend to first\r
 *         enter the XenbusStateInitialised state.  In this case, default\r
 *         transport parameters are in effect and any transport parameters\r
 *         published by the backend must contain their default values.\r
 *\r
 *       Drivers that support optional features and/or transport parameter\r
 *       negotiation must tolerate these additional state transition paths.\r
 *       In general this means performing the work of any skipped state\r
 *       transition, if it has not already been performed, in addition to the\r
 *       work associated with entry into the current state.\r
 */\r
\r
/*\r
 * REQUEST CODES.\r
 */\r
#define BLKIF_OP_READ   0\r
#define BLKIF_OP_WRITE  1\r
\r
/*\r
 * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER\r
 * operation code ("barrier request") must be completed prior to the\r
 * execution of the barrier request.  All writes issued after the barrier\r
 * request must not execute until after the completion of the barrier request.\r
 *\r
 * Optional.  See "feature-barrier" XenBus node documentation above.\r
 */\r
#define BLKIF_OP_WRITE_BARRIER  2\r
\r
/*\r
 * Commit any uncommitted contents of the backing device's volatile cache\r
 * to stable storage.\r
 *\r
 * Optional.  See "feature-flush-cache" XenBus node documentation above.\r
 */\r
#define BLKIF_OP_FLUSH_DISKCACHE  3\r
\r
/*\r
 * Used in SLES sources for device specific command packet\r
 * contained within the request. Reserved for that purpose.\r
 */\r
#define BLKIF_OP_RESERVED_1  4\r
\r
/*\r
 * Indicate to the backend device that a region of storage is no longer in\r
 * use, and may be discarded at any time without impact to the client.  If\r
 * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the\r
 * discarded region on the device must be rendered unrecoverable before the\r
 * command returns.\r
 *\r
 * This operation is analogous to performing a trim (ATA) or unamp (SCSI),\r
 * command on a native device.\r
 *\r
 * More information about trim/unmap operations can be found at:\r
 * http://t13.org/Documents/UploadedDocuments/docs2008/\r
 *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc\r
 * http://www.seagate.com/staticfiles/support/disc/manuals/\r
 *     Interface%20manuals/100293068c.pdf\r
 *\r
 * Optional.  See "feature-discard", "discard-alignment",\r
 * "discard-granularity", and "discard-secure" in the XenBus node\r
 * documentation above.\r
 */\r
#define BLKIF_OP_DISCARD  5\r
\r
/*\r
 * Recognized if "feature-max-indirect-segments" in present in the backend\r
 * xenbus info. The "feature-max-indirect-segments" node contains the maximum\r
 * number of segments allowed by the backend per request. If the node is\r
 * present, the frontend might use blkif_request_indirect structs in order to\r
 * issue requests with more than BLKIF_MAX_SEGMENTS_PER_REQUEST (11). The\r
 * maximum number of indirect segments is fixed by the backend, but the\r
 * frontend can issue requests with any number of indirect segments as long as\r
 * it's less than the number provided by the backend. The indirect_grefs field\r
 * in blkif_request_indirect should be filled by the frontend with the\r
 * grant references of the pages that are holding the indirect segments.\r
 * These pages are filled with an array of blkif_request_segment that hold the\r
 * information about the segments. The number of indirect pages to use is\r
 * determined by the number of segments an indirect request contains. Every\r
 * indirect page can contain a maximum of\r
 * (PAGE_SIZE / sizeof(struct blkif_request_segment)) segments, so to\r
 * calculate the number of indirect pages to use we have to do\r
 * ceil(indirect_segments / (PAGE_SIZE / sizeof(struct blkif_request_segment))).\r
 *\r
 * If a backend does not recognize BLKIF_OP_INDIRECT, it should *not*\r
 * create the "feature-max-indirect-segments" node!\r
 */\r
#define BLKIF_OP_INDIRECT  6\r
\r
/*\r
 * Maximum scatter/gather segments per request.\r
 * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.\r
 * NB. This could be 12 if the ring indexes weren't stored in the same page.\r
 */\r
#define BLKIF_MAX_SEGMENTS_PER_REQUEST  11\r
\r
/*\r
 * Maximum number of indirect pages to use per request.\r
 */\r
#define BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST  8\r
\r
/*\r
 * NB. first_sect and last_sect in blkif_request_segment, as well as\r
 * sector_number in blkif_request, are always expressed in 512-byte units.\r
 * However they must be properly aligned to the real sector size of the\r
 * physical disk, which is reported in the "physical-sector-size" node in\r
 * the backend xenbus info. Also the xenbus "sectors" node is expressed in\r
 * 512-byte units.\r
 */\r
struct blkif_request_segment {\r
  grant_ref_t    gref;       /* reference to I/O buffer frame        */\r
  /* @first_sect: first sector in frame to transfer (inclusive).   */\r
  /* @last_sect: last sector in frame to transfer (inclusive).     */\r
  UINT8          first_sect, last_sect;\r
};\r
\r
/*\r
 * Starting ring element for any I/O request.\r
 */\r
#if defined (MDE_CPU_IA32)\r
//\r
// pack(4) is necessary when these structs are compiled for Ia32.\r
// Without it, the struct will have a different alignment than the one\r
// a backend expect for a 32bit guest.\r
//\r
  #pragma pack(4)\r
#endif\r
struct blkif_request {\r
  UINT8                           operation;     /* BLKIF_OP_???                         */\r
  UINT8                           nr_segments;   /* number of segments                   */\r
  blkif_vdev_t                    handle;        /* only for read/write requests         */\r
  UINT64                          id;            /* private guest value, echoed in resp  */\r
  blkif_sector_t                  sector_number; /* start sector idx on disk (r/w only)  */\r
  struct blkif_request_segment    seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];\r
};\r
\r
typedef struct blkif_request blkif_request_t;\r
\r
/*\r
 * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD\r
 * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)\r
 */\r
struct blkif_request_discard {\r
  UINT8             operation;         /* BLKIF_OP_DISCARD                     */\r
  UINT8             flag;              /* BLKIF_DISCARD_SECURE or zero         */\r
  #define BLKIF_DISCARD_SECURE  (1<<0) /* ignored if discard-secure=0      */\r
  blkif_vdev_t      handle;            /* same as for read/write requests      */\r
  UINT64            id;                /* private guest value, echoed in resp  */\r
  blkif_sector_t    sector_number;     /* start sector idx on disk             */\r
  UINT64            nr_sectors;        /* number of contiguous sectors to discard*/\r
};\r
\r
typedef struct blkif_request_discard blkif_request_discard_t;\r
\r
struct blkif_request_indirect {\r
  UINT8             operation;     /* BLKIF_OP_INDIRECT                    */\r
  UINT8             indirect_op;   /* BLKIF_OP_{READ/WRITE}                */\r
  UINT16            nr_segments;   /* number of segments                   */\r
  UINT64            id;            /* private guest value, echoed in resp  */\r
  blkif_sector_t    sector_number; /* start sector idx on disk (r/w only)  */\r
  blkif_vdev_t      handle;        /* same as for read/write requests      */\r
  grant_ref_t       indirect_grefs[BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST];\r
 #ifdef MDE_CPU_IA32\r
  UINT64            pad;       /* Make it 64 byte aligned on i386      */\r
 #endif\r
};\r
\r
typedef struct blkif_request_indirect blkif_request_indirect_t;\r
\r
struct blkif_response {\r
  UINT64    id;                    /* copied from request */\r
  UINT8     operation;             /* copied from request */\r
  INT16     status;                /* BLKIF_RSP_???       */\r
};\r
\r
typedef struct blkif_response blkif_response_t;\r
#if defined (MDE_CPU_IA32)\r
  #pragma pack()\r
#endif\r
\r
/*\r
 * STATUS RETURN CODES.\r
 */\r
/* Operation not supported (only happens on barrier writes). */\r
#define BLKIF_RSP_EOPNOTSUPP  -2\r
/* Operation failed for some unspecified reason (-EIO). */\r
#define BLKIF_RSP_ERROR  -1\r
/* Operation completed successfully. */\r
#define BLKIF_RSP_OKAY  0\r
\r
/*\r
 * Generate blkif ring structures and types.\r
 */\r
DEFINE_RING_TYPES (blkif, struct blkif_request, struct blkif_response);\r
\r
#define VDISK_CDROM      0x1\r
#define VDISK_REMOVABLE  0x2\r
#define VDISK_READONLY   0x4\r
\r
#endif /* __XEN_PUBLIC_IO_BLKIF_H__ */\r
\r
/*\r
 * Local variables:\r
 * mode: C\r
 * c-file-style: "BSD"\r
 * c-basic-offset: 4\r
 * tab-width: 4\r
 * indent-tabs-mode: nil\r
 * End:\r
 */\r