linux/include/xen/interface/io/blkif.h
<<
>>
Prefs
   1/******************************************************************************
   2 * blkif.h
   3 *
   4 * Unified block-device I/O interface for Xen guest OSes.
   5 *
   6 * Copyright (c) 2003-2004, Keir Fraser
   7 */
   8
   9#ifndef __XEN_PUBLIC_IO_BLKIF_H__
  10#define __XEN_PUBLIC_IO_BLKIF_H__
  11
  12#include <xen/interface/io/ring.h>
  13#include <xen/interface/grant_table.h>
  14
  15/*
  16 * Front->back notifications: When enqueuing a new request, sending a
  17 * notification can be made conditional on req_event (i.e., the generic
  18 * hold-off mechanism provided by the ring macros). Backends must set
  19 * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
  20 *
  21 * Back->front notifications: When enqueuing a new response, sending a
  22 * notification can be made conditional on rsp_event (i.e., the generic
  23 * hold-off mechanism provided by the ring macros). Frontends must set
  24 * rsp_event appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()).
  25 */
  26
  27typedef uint16_t blkif_vdev_t;
  28typedef uint64_t blkif_sector_t;
  29
  30/*
  31 * REQUEST CODES.
  32 */
  33#define BLKIF_OP_READ              0
  34#define BLKIF_OP_WRITE             1
  35/*
  36 * Recognised only if "feature-barrier" is present in backend xenbus info.
  37 * The "feature_barrier" node contains a boolean indicating whether barrier
  38 * requests are likely to succeed or fail. Either way, a barrier request
  39 * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
  40 * the underlying block-device hardware. The boolean simply indicates whether
  41 * or not it is worthwhile for the frontend to attempt barrier requests.
  42 * If a backend does not recognise BLKIF_OP_WRITE_BARRIER, it should *not*
  43 * create the "feature-barrier" node!
  44 */
  45#define BLKIF_OP_WRITE_BARRIER     2
  46
  47/*
  48 * Recognised if "feature-flush-cache" is present in backend xenbus
  49 * info.  A flush will ask the underlying storage hardware to flush its
  50 * non-volatile caches as appropriate.  The "feature-flush-cache" node
  51 * contains a boolean indicating whether flush requests are likely to
  52 * succeed or fail. Either way, a flush request may fail at any time
  53 * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
  54 * block-device hardware. The boolean simply indicates whether or not it
  55 * is worthwhile for the frontend to attempt flushes.  If a backend does
  56 * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
  57 * "feature-flush-cache" node!
  58 */
  59#define BLKIF_OP_FLUSH_DISKCACHE   3
  60
  61/*
  62 * Recognised only if "feature-discard" is present in backend xenbus info.
  63 * The "feature-discard" node contains a boolean indicating whether trim
  64 * (ATA) or unmap (SCSI) - conviently called discard requests are likely
  65 * to succeed or fail. Either way, a discard request
  66 * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
  67 * the underlying block-device hardware. The boolean simply indicates whether
  68 * or not it is worthwhile for the frontend to attempt discard requests.
  69 * If a backend does not recognise BLKIF_OP_DISCARD, it should *not*
  70 * create the "feature-discard" node!
  71 *
  72 * Discard operation is a request for the underlying block device to mark
  73 * extents to be erased. However, discard does not guarantee that the blocks
  74 * will be erased from the device - it is just a hint to the device
  75 * controller that these blocks are no longer in use. What the device
  76 * controller does with that information is left to the controller.
  77 * Discard operations are passed with sector_number as the
  78 * sector index to begin discard operations at and nr_sectors as the number of
  79 * sectors to be discarded. The specified sectors should be discarded if the
  80 * underlying block device supports trim (ATA) or unmap (SCSI) operations,
  81 * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
  82 * More information about trim/unmap operations at:
  83 * http://t13.org/Documents/UploadedDocuments/docs2008/
  84 *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
  85 * http://www.seagate.com/staticfiles/support/disc/manuals/
  86 *     Interface%20manuals/100293068c.pdf
  87 * The backend can optionally provide three extra XenBus attributes to
  88 * further optimize the discard functionality:
  89 * 'discard-aligment' - Devices that support discard functionality may
  90 * internally allocate space in units that are bigger than the exported
  91 * logical block size. The discard-alignment parameter indicates how many bytes
  92 * the beginning of the partition is offset from the internal allocation unit's
  93 * natural alignment.
  94 * 'discard-granularity'  - Devices that support discard functionality may
  95 * internally allocate space using units that are bigger than the logical block
  96 * size. The discard-granularity parameter indicates the size of the internal
  97 * allocation unit in bytes if reported by the device. Otherwise the
  98 * discard-granularity will be set to match the device's physical block size.
  99 * 'discard-secure' - All copies of the discarded sectors (potentially created
 100 * by garbage collection) must also be erased.  To use this feature, the flag
 101 * BLKIF_DISCARD_SECURE must be set in the blkif_request_trim.
 102 */
 103#define BLKIF_OP_DISCARD           5
 104
 105/*
 106 * Recognized if "feature-max-indirect-segments" in present in the backend
 107 * xenbus info. The "feature-max-indirect-segments" node contains the maximum
 108 * number of segments allowed by the backend per request. If the node is
 109 * present, the frontend might use blkif_request_indirect structs in order to
 110 * issue requests with more than BLKIF_MAX_SEGMENTS_PER_REQUEST (11). The
 111 * maximum number of indirect segments is fixed by the backend, but the
 112 * frontend can issue requests with any number of indirect segments as long as
 113 * it's less than the number provided by the backend. The indirect_grefs field
 114 * in blkif_request_indirect should be filled by the frontend with the
 115 * grant references of the pages that are holding the indirect segments.
 116 * These pages are filled with an array of blkif_request_segment that hold the
 117 * information about the segments. The number of indirect pages to use is
 118 * determined by the number of segments an indirect request contains. Every
 119 * indirect page can contain a maximum of
 120 * (PAGE_SIZE / sizeof(struct blkif_request_segment)) segments, so to
 121 * calculate the number of indirect pages to use we have to do
 122 * ceil(indirect_segments / (PAGE_SIZE / sizeof(struct blkif_request_segment))).
 123 *
 124 * If a backend does not recognize BLKIF_OP_INDIRECT, it should *not*
 125 * create the "feature-max-indirect-segments" node!
 126 */
 127#define BLKIF_OP_INDIRECT          6
 128
 129/*
 130 * Maximum scatter/gather segments per request.
 131 * This is carefully chosen so that sizeof(struct blkif_ring) <= PAGE_SIZE.
 132 * NB. This could be 12 if the ring indexes weren't stored in the same page.
 133 */
 134#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 135
 136#define BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST 8
 137
 138struct blkif_request_segment {
 139                grant_ref_t gref;        /* reference to I/O buffer frame        */
 140                /* @first_sect: first sector in frame to transfer (inclusive).   */
 141                /* @last_sect: last sector in frame to transfer (inclusive).     */
 142                uint8_t     first_sect, last_sect;
 143};
 144
 145struct blkif_request_rw {
 146        uint8_t        nr_segments;  /* number of segments                   */
 147        blkif_vdev_t   handle;       /* only for read/write requests         */
 148#ifdef CONFIG_X86_64
 149        uint32_t       _pad1;        /* offsetof(blkif_request,u.rw.id) == 8 */
 150#endif
 151        uint64_t       id;           /* private guest value, echoed in resp  */
 152        blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
 153        struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 154} __attribute__((__packed__));
 155
 156struct blkif_request_discard {
 157        uint8_t        flag;         /* BLKIF_DISCARD_SECURE or zero.        */
 158#define BLKIF_DISCARD_SECURE (1<<0)  /* ignored if discard-secure=0          */
 159        blkif_vdev_t   _pad1;        /* only for read/write requests         */
 160#ifdef CONFIG_X86_64
 161        uint32_t       _pad2;        /* offsetof(blkif_req..,u.discard.id)==8*/
 162#endif
 163        uint64_t       id;           /* private guest value, echoed in resp  */
 164        blkif_sector_t sector_number;
 165        uint64_t       nr_sectors;
 166        uint8_t        _pad3;
 167} __attribute__((__packed__));
 168
 169struct blkif_request_other {
 170        uint8_t      _pad1;
 171        blkif_vdev_t _pad2;        /* only for read/write requests         */
 172#ifdef CONFIG_X86_64
 173        uint32_t     _pad3;        /* offsetof(blkif_req..,u.other.id)==8*/
 174#endif
 175        uint64_t     id;           /* private guest value, echoed in resp  */
 176} __attribute__((__packed__));
 177
 178struct blkif_request_indirect {
 179        uint8_t        indirect_op;
 180        uint16_t       nr_segments;
 181#ifdef CONFIG_X86_64
 182        uint32_t       _pad1;        /* offsetof(blkif_...,u.indirect.id) == 8 */
 183#endif
 184        uint64_t       id;
 185        blkif_sector_t sector_number;
 186        blkif_vdev_t   handle;
 187        uint16_t       _pad2;
 188        grant_ref_t    indirect_grefs[BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST];
 189#ifdef CONFIG_X86_64
 190        uint32_t      _pad3;         /* make it 64 byte aligned */
 191#else
 192        uint64_t      _pad3;         /* make it 64 byte aligned */
 193#endif
 194} __attribute__((__packed__));
 195
 196struct blkif_request {
 197        uint8_t        operation;    /* BLKIF_OP_???                         */
 198        union {
 199                struct blkif_request_rw rw;
 200                struct blkif_request_discard discard;
 201                struct blkif_request_other other;
 202                struct blkif_request_indirect indirect;
 203        } u;
 204} __attribute__((__packed__));
 205
 206struct blkif_response {
 207        uint64_t        id;              /* copied from request */
 208        uint8_t         operation;       /* copied from request */
 209        int16_t         status;          /* BLKIF_RSP_???       */
 210};
 211
 212/*
 213 * STATUS RETURN CODES.
 214 */
 215 /* Operation not supported (only happens on barrier writes). */
 216#define BLKIF_RSP_EOPNOTSUPP  -2
 217 /* Operation failed for some unspecified reason (-EIO). */
 218#define BLKIF_RSP_ERROR       -1
 219 /* Operation completed successfully. */
 220#define BLKIF_RSP_OKAY         0
 221
 222/*
 223 * Generate blkif ring structures and types.
 224 */
 225
 226DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 227
 228#define VDISK_CDROM        0x1
 229#define VDISK_REMOVABLE    0x2
 230#define VDISK_READONLY     0x4
 231
 232/* Xen-defined major numbers for virtual disks, they look strangely
 233 * familiar */
 234#define XEN_IDE0_MAJOR  3
 235#define XEN_IDE1_MAJOR  22
 236#define XEN_SCSI_DISK0_MAJOR    8
 237#define XEN_SCSI_DISK1_MAJOR    65
 238#define XEN_SCSI_DISK2_MAJOR    66
 239#define XEN_SCSI_DISK3_MAJOR    67
 240#define XEN_SCSI_DISK4_MAJOR    68
 241#define XEN_SCSI_DISK5_MAJOR    69
 242#define XEN_SCSI_DISK6_MAJOR    70
 243#define XEN_SCSI_DISK7_MAJOR    71
 244#define XEN_SCSI_DISK8_MAJOR    128
 245#define XEN_SCSI_DISK9_MAJOR    129
 246#define XEN_SCSI_DISK10_MAJOR   130
 247#define XEN_SCSI_DISK11_MAJOR   131
 248#define XEN_SCSI_DISK12_MAJOR   132
 249#define XEN_SCSI_DISK13_MAJOR   133
 250#define XEN_SCSI_DISK14_MAJOR   134
 251#define XEN_SCSI_DISK15_MAJOR   135
 252
 253#endif /* __XEN_PUBLIC_IO_BLKIF_H__ */
 254