projects / mirror_edk2.git / blame
| Commit | Line | Data |
|---|---|---|
| 5cce8524 ST |
1 | /******************************************************************************\r |
| 2 | * blkif.h\r | |
| 3 | *\r | |
| 4 | * Unified block-device I/O interface for Xen guest OSes.\r | |
| 5 | *\r | |
| 6 | * Permission is hereby granted, free of charge, to any person obtaining a copy\r | |
| 7 | * of this software and associated documentation files (the "Software"), to\r | |
| 8 | * deal in the Software without restriction, including without limitation the\r | |
| 9 | * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\r | |
| 10 | * sell copies of the Software, and to permit persons to whom the Software is\r | |
| 11 | * furnished to do so, subject to the following conditions:\r | |
| 12 | *\r | |
| 13 | * The above copyright notice and this permission notice shall be included in\r | |
| 14 | * all copies or substantial portions of the Software.\r | |
| 15 | *\r | |
| 16 | * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\r | |
| 17 | * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\r | |
| 18 | * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\r | |
| 19 | * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\r | |
| 20 | * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\r | |
| 21 | * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER\r | |
| 22 | * DEALINGS IN THE SOFTWARE.\r | |
| 23 | *\r | |
| 24 | * Copyright (c) 2003-2004, Keir Fraser\r | |
| 25 | * Copyright (c) 2012, Spectra Logic Corporation\r | |
| 26 | */\r | |
| 27 | \r | |
| 28 | #ifndef __XEN_PUBLIC_IO_BLKIF_H__\r | |
| 29 | #define __XEN_PUBLIC_IO_BLKIF_H__\r | |
| 30 | \r | |
| 31 | #include "ring.h"\r | |
| 32 | #include "../grant_table.h"\r | |
| 33 | \r | |
| 34 | /*\r | |
| 35 | * Front->back notifications: When enqueuing a new request, sending a\r | |
| 36 | * notification can be made conditional on req_event (i.e., the generic\r | |
| 37 | * hold-off mechanism provided by the ring macros). Backends must set\r | |
| 38 | * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).\r | |
| 39 | *\r | |
| 40 | * Back->front notifications: When enqueuing a new response, sending a\r | |
| 41 | * notification can be made conditional on rsp_event (i.e., the generic\r | |
| 42 | * hold-off mechanism provided by the ring macros). Frontends must set\r | |
| 43 | * rsp_event appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()).\r | |
| 44 | */\r | |
| 45 | \r | |
| 46 | #ifndef blkif_vdev_t\r | |
| 47 | #define blkif_vdev_t UINT16\r | |
| 48 | #endif\r | |
| 49 | #define blkif_sector_t UINT64\r | |
| 50 | \r | |
| 51 | /*\r | |
| 52 | * Feature and Parameter Negotiation\r | |
| 53 | * =================================\r | |
| 54 | * The two halves of a Xen block driver utilize nodes within the XenStore to\r | |
| 55 | * communicate capabilities and to negotiate operating parameters. This\r | |
| 56 | * section enumerates these nodes which reside in the respective front and\r | |
| 57 | * backend portions of the XenStore, following the XenBus convention.\r | |
| 58 | *\r | |
| 59 | * All data in the XenStore is stored as strings. Nodes specifying numeric\r | |
| 60 | * values are encoded in decimal. Integer value ranges listed below are\r | |
| 61 | * expressed as fixed sized integer types capable of storing the conversion\r | |
| b6b33f67 | 62 | * of a properly formatted node string, without loss of information.\r |
| 5cce8524 ST |
63 | *\r |
| 64 | * Any specified default value is in effect if the corresponding XenBus node\r | |
| 65 | * is not present in the XenStore.\r | |
| 66 | *\r | |
| 67 | * XenStore nodes in sections marked "PRIVATE" are solely for use by the\r | |
| 68 | * driver side whose XenBus tree contains them.\r | |
| 69 | *\r | |
| 70 | * XenStore nodes marked "DEPRECATED" in their notes section should only be\r | |
| 71 | * used to provide interoperability with legacy implementations.\r | |
| 72 | *\r | |
| 73 | * See the XenBus state transition diagram below for details on when XenBus\r | |
| 74 | * nodes must be published and when they can be queried.\r | |
| 75 | *\r | |
| 76 | *****************************************************************************\r | |
| 77 | * Backend XenBus Nodes\r | |
| 78 | *****************************************************************************\r | |
| 79 | *\r | |
| 80 | *------------------ Backend Device Identification (PRIVATE) ------------------\r | |
| 81 | *\r | |
| 82 | * mode\r | |
| 83 | * Values: "r" (read only), "w" (writable)\r | |
| 84 | *\r | |
| 85 | * The read or write access permissions to the backing store to be\r | |
| 86 | * granted to the frontend.\r | |
| 87 | *\r | |
| 88 | * params\r | |
| 89 | * Values: string\r | |
| 90 | *\r | |
| 91 | * A free formatted string providing sufficient information for the\r | |
| 92 | * backend driver to open the backing device. (e.g. the path to the\r | |
| 93 | * file or block device representing the backing store.)\r | |
| 94 | *\r | |
| 95 | * type\r | |
| 96 | * Values: "file", "phy", "tap"\r | |
| 97 | *\r | |
| 98 | * The type of the backing device/object.\r | |
| 99 | *\r | |
| 100 | *--------------------------------- Features ---------------------------------\r | |
| 101 | *\r | |
| 102 | * feature-barrier\r | |
| 103 | * Values: 0/1 (boolean)\r | |
| 104 | * Default Value: 0\r | |
| 105 | *\r | |
| 106 | * A value of "1" indicates that the backend can process requests\r | |
| 107 | * containing the BLKIF_OP_WRITE_BARRIER request opcode. Requests\r | |
| 108 | * of this type may still be returned at any time with the\r | |
| 109 | * BLKIF_RSP_EOPNOTSUPP result code.\r | |
| 110 | *\r | |
| 111 | * feature-flush-cache\r | |
| 112 | * Values: 0/1 (boolean)\r | |
| 113 | * Default Value: 0\r | |
| 114 | *\r | |
| 115 | * A value of "1" indicates that the backend can process requests\r | |
| 116 | * containing the BLKIF_OP_FLUSH_DISKCACHE request opcode. Requests\r | |
| 117 | * of this type may still be returned at any time with the\r | |
| 118 | * BLKIF_RSP_EOPNOTSUPP result code.\r | |
| 119 | *\r | |
| 120 | * feature-discard\r | |
| 121 | * Values: 0/1 (boolean)\r | |
| 122 | * Default Value: 0\r | |
| 123 | *\r | |
| 124 | * A value of "1" indicates that the backend can process requests\r | |
| 125 | * containing the BLKIF_OP_DISCARD request opcode. Requests\r | |
| 126 | * of this type may still be returned at any time with the\r | |
| 127 | * BLKIF_RSP_EOPNOTSUPP result code.\r | |
| 128 | *\r | |
| 129 | * feature-persistent\r | |
| 130 | * Values: 0/1 (boolean)\r | |
| 131 | * Default Value: 0\r | |
| 132 | * Notes: 7\r | |
| 133 | *\r | |
| 134 | * A value of "1" indicates that the backend can keep the grants used\r | |
| 135 | * by the frontend driver mapped, so the same set of grants should be\r | |
| 136 | * used in all transactions. The maximum number of grants the backend\r | |
| 137 | * can map persistently depends on the implementation, but ideally it\r | |
| 138 | * should be RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST. Using this\r | |
| 139 | * feature the backend doesn't need to unmap each grant, preventing\r | |
| 140 | * costly TLB flushes. The backend driver should only map grants\r | |
| 141 | * persistently if the frontend supports it. If a backend driver chooses\r | |
| 142 | * to use the persistent protocol when the frontend doesn't support it,\r | |
| 143 | * it will probably hit the maximum number of persistently mapped grants\r | |
| 144 | * (due to the fact that the frontend won't be reusing the same grants),\r | |
| 145 | * and fall back to non-persistent mode. Backend implementations may\r | |
| 146 | * shrink or expand the number of persistently mapped grants without\r | |
| 147 | * notifying the frontend depending on memory constraints (this might\r | |
| 148 | * cause a performance degradation).\r | |
| 149 | *\r | |
| 150 | * If a backend driver wants to limit the maximum number of persistently\r | |
| 151 | * mapped grants to a value less than RING_SIZE *\r | |
| 152 | * BLKIF_MAX_SEGMENTS_PER_REQUEST a LRU strategy should be used to\r | |
| 153 | * discard the grants that are less commonly used. Using a LRU in the\r | |
| 154 | * backend driver paired with a LIFO queue in the frontend will\r | |
| 155 | * allow us to have better performance in this scenario.\r | |
| 156 | *\r | |
| 157 | *----------------------- Request Transport Parameters ------------------------\r | |
| 158 | *\r | |
| 159 | * max-ring-page-order\r | |
| 160 | * Values: <UINT32>\r | |
| 161 | * Default Value: 0\r | |
| 162 | * Notes: 1, 3\r | |
| 163 | *\r | |
| 164 | * The maximum supported size of the request ring buffer in units of\r | |
| 165 | * lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,\r | |
| 166 | * etc.).\r | |
| 167 | *\r | |
| 168 | * max-ring-pages\r | |
| 169 | * Values: <UINT32>\r | |
| 170 | * Default Value: 1\r | |
| 171 | * Notes: DEPRECATED, 2, 3\r | |
| 172 | *\r | |
| 173 | * The maximum supported size of the request ring buffer in units of\r | |
| 174 | * machine pages. The value must be a power of 2.\r | |
| 175 | *\r | |
| 176 | *------------------------- Backend Device Properties -------------------------\r | |
| 177 | *\r | |
| 178 | * discard-alignment\r | |
| 179 | * Values: <UINT32>\r | |
| 180 | * Default Value: 0\r | |
| 181 | * Notes: 4, 5\r | |
| 182 | *\r | |
| 183 | * The offset, in bytes from the beginning of the virtual block device,\r | |
| 184 | * to the first, addressable, discard extent on the underlying device.\r | |
| 185 | *\r | |
| 186 | * discard-granularity\r | |
| 187 | * Values: <UINT32>\r | |
| 188 | * Default Value: <"sector-size">\r | |
| 189 | * Notes: 4\r | |
| 190 | *\r | |
| 191 | * The size, in bytes, of the individually addressable discard extents\r | |
| 192 | * of the underlying device.\r | |
| 193 | *\r | |
| 194 | * discard-secure\r | |
| 195 | * Values: 0/1 (boolean)\r | |
| 196 | * Default Value: 0\r | |
| 197 | * Notes: 10\r | |
| 198 | *\r | |
| 199 | * A value of "1" indicates that the backend can process BLKIF_OP_DISCARD\r | |
| 200 | * requests with the BLKIF_DISCARD_SECURE flag set.\r | |
| 201 | *\r | |
| 202 | * info\r | |
| 203 | * Values: <UINT32> (bitmap)\r | |
| 204 | *\r | |
| 205 | * A collection of bit flags describing attributes of the backing\r | |
| 206 | * device. The VDISK_* macros define the meaning of each bit\r | |
| 207 | * location.\r | |
| 208 | *\r | |
| 209 | * sector-size\r | |
| 210 | * Values: <UINT32>\r | |
| 211 | *\r | |
| 212 | * The logical sector size, in bytes, of the backend device.\r | |
| 213 | *\r | |
| 214 | * physical-sector-size\r | |
| 215 | * Values: <UINT32>\r | |
| 216 | *\r | |
| 217 | * The physical sector size, in bytes, of the backend device.\r | |
| 218 | *\r | |
| 219 | * sectors\r | |
| 220 | * Values: <UINT64>\r | |
| 221 | *\r | |
| 222 | * The size of the backend device, expressed in units of its logical\r | |
| 223 | * sector size ("sector-size").\r | |
| 224 | *\r | |
| 225 | *****************************************************************************\r | |
| 226 | * Frontend XenBus Nodes\r | |
| 227 | *****************************************************************************\r | |
| 228 | *\r | |
| 229 | *----------------------- Request Transport Parameters -----------------------\r | |
| 230 | *\r | |
| 231 | * event-channel\r | |
| 232 | * Values: <UINT32>\r | |
| 233 | *\r | |
| 234 | * The identifier of the Xen event channel used to signal activity\r | |
| 235 | * in the ring buffer.\r | |
| 236 | *\r | |
| 237 | * ring-ref\r | |
| 238 | * Values: <UINT32>\r | |
| 239 | * Notes: 6\r | |
| 240 | *\r | |
| 241 | * The Xen grant reference granting permission for the backend to map\r | |
| 242 | * the sole page in a single page sized ring buffer.\r | |
| 243 | *\r | |
| 244 | * ring-ref%u\r | |
| 245 | * Values: <UINT32>\r | |
| 246 | * Notes: 6\r | |
| 247 | *\r | |
| 248 | * For a frontend providing a multi-page ring, a "number of ring pages"\r | |
| 249 | * sized list of nodes, each containing a Xen grant reference granting\r | |
| 250 | * permission for the backend to map the page of the ring located\r | |
| 251 | * at page index "%u". Page indexes are zero based.\r | |
| 252 | *\r | |
| 253 | * protocol\r | |
| 254 | * Values: string (XEN_IO_PROTO_ABI_*)\r | |
| 255 | * Default Value: XEN_IO_PROTO_ABI_NATIVE\r | |
| 256 | *\r | |
| 257 | * The machine ABI rules governing the format of all ring request and\r | |
| 258 | * response structures.\r | |
| 259 | *\r | |
| 260 | * ring-page-order\r | |
| 261 | * Values: <UINT32>\r | |
| 262 | * Default Value: 0\r | |
| 263 | * Maximum Value: MAX(ffs(max-ring-pages) - 1, max-ring-page-order)\r | |
| 264 | * Notes: 1, 3\r | |
| 265 | *\r | |
| 266 | * The size of the frontend allocated request ring buffer in units\r | |
| 267 | * of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,\r | |
| 268 | * etc.).\r | |
| 269 | *\r | |
| 270 | * num-ring-pages\r | |
| 271 | * Values: <UINT32>\r | |
| 272 | * Default Value: 1\r | |
| 273 | * Maximum Value: MAX(max-ring-pages,(0x1 << max-ring-page-order))\r | |
| 274 | * Notes: DEPRECATED, 2, 3\r | |
| 275 | *\r | |
| 276 | * The size of the frontend allocated request ring buffer in units of\r | |
| 277 | * machine pages. The value must be a power of 2.\r | |
| 278 | *\r | |
| 279 | * feature-persistent\r | |
| 280 | * Values: 0/1 (boolean)\r | |
| 281 | * Default Value: 0\r | |
| 282 | * Notes: 7, 8, 9\r | |
| 283 | *\r | |
| 284 | * A value of "1" indicates that the frontend will reuse the same grants\r | |
| 285 | * for all transactions, allowing the backend to map them with write\r | |
| 286 | * access (even when it should be read-only). If the frontend hits the\r | |
| 287 | * maximum number of allowed persistently mapped grants, it can fallback\r | |
| 288 | * to non persistent mode. This will cause a performance degradation,\r | |
| 289 | * since the the backend driver will still try to map those grants\r | |
| 290 | * persistently. Since the persistent grants protocol is compatible with\r | |
| 291 | * the previous protocol, a frontend driver can choose to work in\r | |
| 292 | * persistent mode even when the backend doesn't support it.\r | |
| 293 | *\r | |
| 294 | * It is recommended that the frontend driver stores the persistently\r | |
| 295 | * mapped grants in a LIFO queue, so a subset of all persistently mapped\r | |
| 296 | * grants gets used commonly. This is done in case the backend driver\r | |
| 297 | * decides to limit the maximum number of persistently mapped grants\r | |
| 298 | * to a value less than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST.\r | |
| 299 | *\r | |
| 300 | *------------------------- Virtual Device Properties -------------------------\r | |
| 301 | *\r | |
| 302 | * device-type\r | |
| 303 | * Values: "disk", "cdrom", "floppy", etc.\r | |
| 304 | *\r | |
| 305 | * virtual-device\r | |
| 306 | * Values: <UINT32>\r | |
| 307 | *\r | |
| 308 | * A value indicating the physical device to virtualize within the\r | |
| 309 | * frontend's domain. (e.g. "The first ATA disk", "The third SCSI\r | |
| 310 | * disk", etc.)\r | |
| 311 | *\r | |
| 312 | * See docs/misc/vbd-interface.txt for details on the format of this\r | |
| 313 | * value.\r | |
| 314 | *\r | |
| 315 | * Notes\r | |
| 316 | * -----\r | |
| 317 | * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer\r | |
| 318 | * PV drivers.\r | |
| 319 | * (2) Multi-page ring buffer scheme first used in some RedHat distributions\r | |
| 320 | * including a distribution deployed on certain nodes of the Amazon\r | |
| 321 | * EC2 cluster.\r | |
| 322 | * (3) Support for multi-page ring buffers was implemented independently,\r | |
| 323 | * in slightly different forms, by both Citrix and RedHat/Amazon.\r | |
| 324 | * For full interoperability, block front and backends should publish\r | |
| 325 | * identical ring parameters, adjusted for unit differences, to the\r | |
| 326 | * XenStore nodes used in both schemes.\r | |
| 327 | * (4) Devices that support discard functionality may internally allocate space\r | |
| 328 | * (discardable extents) in units that are larger than the exported logical\r | |
| 329 | * block size. If the backing device has such discardable extents the\r | |
| 330 | * backend should provide both discard-granularity and discard-alignment.\r | |
| 331 | * Providing just one of the two may be considered an error by the frontend.\r | |
| 332 | * Backends supporting discard should include discard-granularity and\r | |
| 333 | * discard-alignment even if it supports discarding individual sectors.\r | |
| 334 | * Frontends should assume discard-alignment == 0 and discard-granularity\r | |
| 335 | * == sector size if these keys are missing.\r | |
| 336 | * (5) The discard-alignment parameter allows a physical device to be\r | |
| 337 | * partitioned into virtual devices that do not necessarily begin or\r | |
| 338 | * end on a discardable extent boundary.\r | |
| 339 | * (6) When there is only a single page allocated to the request ring,\r | |
| 340 | * 'ring-ref' is used to communicate the grant reference for this\r | |
| 341 | * page to the backend. When using a multi-page ring, the 'ring-ref'\r | |
| 342 | * node is not created. Instead 'ring-ref0' - 'ring-refN' are used.\r | |
| 343 | * (7) When using persistent grants data has to be copied from/to the page\r | |
| 344 | * where the grant is currently mapped. The overhead of doing this copy\r | |
| 345 | * however doesn't suppress the speed improvement of not having to unmap\r | |
| 346 | * the grants.\r | |
| 347 | * (8) The frontend driver has to allow the backend driver to map all grants\r | |
| 348 | * with write access, even when they should be mapped read-only, since\r | |
| 349 | * further requests may reuse these grants and require write permissions.\r | |
| 350 | * (9) Linux implementation doesn't have a limit on the maximum number of\r | |
| 351 | * grants that can be persistently mapped in the frontend driver, but\r | |
| 352 | * due to the frontent driver implementation it should never be bigger\r | |
| 353 | * than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST.\r | |
| 354 | *(10) The discard-secure property may be present and will be set to 1 if the\r | |
| 355 | * backing device supports secure discard.\r | |
| 356 | */\r | |
| 357 | \r | |
| 358 | /*\r | |
| 359 | * STATE DIAGRAMS\r | |
| 360 | *\r | |
| 361 | *****************************************************************************\r | |
| 362 | * Startup *\r | |
| 363 | *****************************************************************************\r | |
| 364 | *\r | |
| 365 | * Tool stack creates front and back nodes with state XenbusStateInitialising.\r | |
| 366 | *\r | |
| 367 | * Front Back\r | |
| 368 | * ================================= =====================================\r | |
| 369 | * XenbusStateInitialising XenbusStateInitialising\r | |
| 370 | * o Query virtual device o Query backend device identification\r | |
| 371 | * properties. data.\r | |
| 372 | * o Setup OS device instance. o Open and validate backend device.\r | |
| 373 | * o Publish backend features and\r | |
| 374 | * transport parameters.\r | |
| 375 | * |\r | |
| 376 | * |\r | |
| 377 | * V\r | |
| 378 | * XenbusStateInitWait\r | |
| 379 | *\r | |
| 380 | * o Query backend features and\r | |
| 381 | * transport parameters.\r | |
| 382 | * o Allocate and initialize the\r | |
| 383 | * request ring.\r | |
| 384 | * o Publish transport parameters\r | |
| 385 | * that will be in effect during\r | |
| 386 | * this connection.\r | |
| 387 | * |\r | |
| 388 | * |\r | |
| 389 | * V\r | |
| 390 | * XenbusStateInitialised\r | |
| 391 | *\r | |
| 392 | * o Query frontend transport parameters.\r | |
| 393 | * o Connect to the request ring and\r | |
| 394 | * event channel.\r | |
| 395 | * o Publish backend device properties.\r | |
| 396 | * |\r | |
| 397 | * |\r | |
| 398 | * V\r | |
| 399 | * XenbusStateConnected\r | |
| 400 | *\r | |
| 401 | * o Query backend device properties.\r | |
| 402 | * o Finalize OS virtual device\r | |
| 403 | * instance.\r | |
| 404 | * |\r | |
| 405 | * |\r | |
| 406 | * V\r | |
| 407 | * XenbusStateConnected\r | |
| 408 | *\r | |
| 409 | * Note: Drivers that do not support any optional features, or the negotiation\r | |
| 410 | * of transport parameters, can skip certain states in the state machine:\r | |
| 411 | *\r | |
| 412 | * o A frontend may transition to XenbusStateInitialised without\r | |
| 413 | * waiting for the backend to enter XenbusStateInitWait. In this\r | |
| 414 | * case, default transport parameters are in effect and any\r | |
| 415 | * transport parameters published by the frontend must contain\r | |
| 416 | * their default values.\r | |
| 417 | *\r | |
| 418 | * o A backend may transition to XenbusStateInitialised, bypassing\r | |
| 419 | * XenbusStateInitWait, without waiting for the frontend to first\r | |
| 420 | * enter the XenbusStateInitialised state. In this case, default\r | |
| 421 | * transport parameters are in effect and any transport parameters\r | |
| 422 | * published by the backend must contain their default values.\r | |
| 423 | *\r | |
| 424 | * Drivers that support optional features and/or transport parameter\r | |
| 425 | * negotiation must tolerate these additional state transition paths.\r | |
| 426 | * In general this means performing the work of any skipped state\r | |
| 427 | * transition, if it has not already been performed, in addition to the\r | |
| 428 | * work associated with entry into the current state.\r | |
| 429 | */\r | |
| 430 | \r | |
| 431 | /*\r | |
| 432 | * REQUEST CODES.\r | |
| 433 | */\r | |
| 434 | #define BLKIF_OP_READ 0\r | |
| 435 | #define BLKIF_OP_WRITE 1\r | |
| 436 | /*\r | |
| 437 | * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER\r | |
| 438 | * operation code ("barrier request") must be completed prior to the\r | |
| 439 | * execution of the barrier request. All writes issued after the barrier\r | |
| 440 | * request must not execute until after the completion of the barrier request.\r | |
| 441 | *\r | |
| 442 | * Optional. See "feature-barrier" XenBus node documentation above.\r | |
| 443 | */\r | |
| 444 | #define BLKIF_OP_WRITE_BARRIER 2\r | |
| 445 | /*\r | |
| 446 | * Commit any uncommitted contents of the backing device's volatile cache\r | |
| 447 | * to stable storage.\r | |
| 448 | *\r | |
| 449 | * Optional. See "feature-flush-cache" XenBus node documentation above.\r | |
| 450 | */\r | |
| 451 | #define BLKIF_OP_FLUSH_DISKCACHE 3\r | |
| 452 | /*\r | |
| 453 | * Used in SLES sources for device specific command packet\r | |
| 454 | * contained within the request. Reserved for that purpose.\r | |
| 455 | */\r | |
| 456 | #define BLKIF_OP_RESERVED_1 4\r | |
| 457 | /*\r | |
| 458 | * Indicate to the backend device that a region of storage is no longer in\r | |
| 459 | * use, and may be discarded at any time without impact to the client. If\r | |
| 460 | * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the\r | |
| 461 | * discarded region on the device must be rendered unrecoverable before the\r | |
| 462 | * command returns.\r | |
| 463 | *\r | |
| 464 | * This operation is analogous to performing a trim (ATA) or unamp (SCSI),\r | |
| 465 | * command on a native device.\r | |
| 466 | *\r | |
| 467 | * More information about trim/unmap operations can be found at:\r | |
| 468 | * http://t13.org/Documents/UploadedDocuments/docs2008/\r | |
| 469 | * e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc\r | |
| 470 | * http://www.seagate.com/staticfiles/support/disc/manuals/\r | |
| 471 | * Interface%20manuals/100293068c.pdf\r | |
| 472 | *\r | |
| 473 | * Optional. See "feature-discard", "discard-alignment",\r | |
| 474 | * "discard-granularity", and "discard-secure" in the XenBus node\r | |
| 475 | * documentation above.\r | |
| 476 | */\r | |
| 477 | #define BLKIF_OP_DISCARD 5\r | |
| 478 | \r | |
| 479 | /*\r | |
| 480 | * Recognized if "feature-max-indirect-segments" in present in the backend\r | |
| 481 | * xenbus info. The "feature-max-indirect-segments" node contains the maximum\r | |
| 482 | * number of segments allowed by the backend per request. If the node is\r | |
| 483 | * present, the frontend might use blkif_request_indirect structs in order to\r | |
| 484 | * issue requests with more than BLKIF_MAX_SEGMENTS_PER_REQUEST (11). The\r | |
| 485 | * maximum number of indirect segments is fixed by the backend, but the\r | |
| 486 | * frontend can issue requests with any number of indirect segments as long as\r | |
| 487 | * it's less than the number provided by the backend. The indirect_grefs field\r | |
| 488 | * in blkif_request_indirect should be filled by the frontend with the\r | |
| 489 | * grant references of the pages that are holding the indirect segments.\r | |
| 490 | * These pages are filled with an array of blkif_request_segment that hold the\r | |
| 491 | * information about the segments. The number of indirect pages to use is\r | |
| 492 | * determined by the number of segments an indirect request contains. Every\r | |
| 493 | * indirect page can contain a maximum of\r | |
| 494 | * (PAGE_SIZE / sizeof(struct blkif_request_segment)) segments, so to\r | |
| 495 | * calculate the number of indirect pages to use we have to do\r | |
| 496 | * ceil(indirect_segments / (PAGE_SIZE / sizeof(struct blkif_request_segment))).\r | |
| 497 | *\r | |
| 498 | * If a backend does not recognize BLKIF_OP_INDIRECT, it should *not*\r | |
| 499 | * create the "feature-max-indirect-segments" node!\r | |
| 500 | */\r | |
| 501 | #define BLKIF_OP_INDIRECT 6\r | |
| 502 | \r | |
| 503 | /*\r | |
| 504 | * Maximum scatter/gather segments per request.\r | |
| 505 | * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.\r | |
| 506 | * NB. This could be 12 if the ring indexes weren't stored in the same page.\r | |
| 507 | */\r | |
| 508 | #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11\r | |
| 509 | \r | |
| 510 | /*\r | |
| 511 | * Maximum number of indirect pages to use per request.\r | |
| 512 | */\r | |
| 513 | #define BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST 8\r | |
| 514 | \r | |
| 515 | /*\r | |
| 516 | * NB. first_sect and last_sect in blkif_request_segment, as well as\r | |
| 517 | * sector_number in blkif_request, are always expressed in 512-byte units.\r | |
| 518 | * However they must be properly aligned to the real sector size of the\r | |
| 519 | * physical disk, which is reported in the "physical-sector-size" node in\r | |
| 520 | * the backend xenbus info. Also the xenbus "sectors" node is expressed in\r | |
| 521 | * 512-byte units.\r | |
| 522 | */\r | |
| 523 | struct blkif_request_segment {\r | |
| 524 | grant_ref_t gref; /* reference to I/O buffer frame */\r | |
| 525 | /* @first_sect: first sector in frame to transfer (inclusive). */\r | |
| 526 | /* @last_sect: last sector in frame to transfer (inclusive). */\r | |
| 527 | UINT8 first_sect, last_sect;\r | |
| 528 | };\r | |
| 529 | \r | |
| 530 | /*\r | |
| 531 | * Starting ring element for any I/O request.\r | |
| 532 | */\r | |
| 8f148aee | 533 | #if defined(MDE_CPU_IA32)\r |
| 5cce8524 ST |
534 | //\r |
| 535 | // pack(4) is necessary when these structs are compiled for Ia32.\r | |
| 536 | // Without it, the struct will have a different alignment than the one\r | |
| 537 | // a backend expect for a 32bit guest.\r | |
| 538 | //\r | |
| 539 | #pragma pack(4)\r | |
| 540 | #endif\r | |
| 541 | struct blkif_request {\r | |
| 542 | UINT8 operation; /* BLKIF_OP_??? */\r | |
| 543 | UINT8 nr_segments; /* number of segments */\r | |
| 544 | blkif_vdev_t handle; /* only for read/write requests */\r | |
| 545 | UINT64 id; /* private guest value, echoed in resp */\r | |
| 546 | blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */\r | |
| 547 | struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];\r | |
| 548 | };\r | |
| 549 | typedef struct blkif_request blkif_request_t;\r | |
| 550 | \r | |
| 551 | /*\r | |
| 552 | * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD\r | |
| 553 | * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)\r | |
| 554 | */\r | |
| 555 | struct blkif_request_discard {\r | |
| 556 | UINT8 operation; /* BLKIF_OP_DISCARD */\r | |
| 557 | UINT8 flag; /* BLKIF_DISCARD_SECURE or zero */\r | |
| 558 | #define BLKIF_DISCARD_SECURE (1<<0) /* ignored if discard-secure=0 */\r | |
| 559 | blkif_vdev_t handle; /* same as for read/write requests */\r | |
| 560 | UINT64 id; /* private guest value, echoed in resp */\r | |
| 561 | blkif_sector_t sector_number;/* start sector idx on disk */\r | |
| 562 | UINT64 nr_sectors; /* number of contiguous sectors to discard*/\r | |
| 563 | };\r | |
| 564 | typedef struct blkif_request_discard blkif_request_discard_t;\r | |
| 565 | \r | |
| 566 | struct blkif_request_indirect {\r | |
| 567 | UINT8 operation; /* BLKIF_OP_INDIRECT */\r | |
| 568 | UINT8 indirect_op; /* BLKIF_OP_{READ/WRITE} */\r | |
| 569 | UINT16 nr_segments; /* number of segments */\r | |
| 570 | UINT64 id; /* private guest value, echoed in resp */\r | |
| 571 | blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */\r | |
| 572 | blkif_vdev_t handle; /* same as for read/write requests */\r | |
| 573 | grant_ref_t indirect_grefs[BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST];\r | |
| 8f148aee | 574 | #ifdef MDE_CPU_IA32\r |
| 5cce8524 ST |
575 | UINT64 pad; /* Make it 64 byte aligned on i386 */\r |
| 576 | #endif\r | |
| 577 | };\r | |
| 578 | typedef struct blkif_request_indirect blkif_request_indirect_t;\r | |
| 579 | \r | |
| 580 | struct blkif_response {\r | |
| 581 | UINT64 id; /* copied from request */\r | |
| 582 | UINT8 operation; /* copied from request */\r | |
| 583 | INT16 status; /* BLKIF_RSP_??? */\r | |
| 584 | };\r | |
| 585 | typedef struct blkif_response blkif_response_t;\r | |
| 8f148aee | 586 | #if defined(MDE_CPU_IA32)\r |
| 5cce8524 ST |
587 | #pragma pack()\r |
| 588 | #endif\r | |
| 589 | \r | |
| 590 | /*\r | |
| 591 | * STATUS RETURN CODES.\r | |
| 592 | */\r | |
| 593 | /* Operation not supported (only happens on barrier writes). */\r | |
| 594 | #define BLKIF_RSP_EOPNOTSUPP -2\r | |
| 595 | /* Operation failed for some unspecified reason (-EIO). */\r | |
| 596 | #define BLKIF_RSP_ERROR -1\r | |
| 597 | /* Operation completed successfully. */\r | |
| 598 | #define BLKIF_RSP_OKAY 0\r | |
| 599 | \r | |
| 600 | /*\r | |
| 601 | * Generate blkif ring structures and types.\r | |
| 602 | */\r | |
| 603 | DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);\r | |
| 604 | \r | |
| 605 | #define VDISK_CDROM 0x1\r | |
| 606 | #define VDISK_REMOVABLE 0x2\r | |
| 607 | #define VDISK_READONLY 0x4\r | |
| 608 | \r | |
| 609 | #endif /* __XEN_PUBLIC_IO_BLKIF_H__ */\r | |
| 610 | \r | |
| 611 | /*\r | |
| 612 | * Local variables:\r | |
| 613 | * mode: C\r | |
| 614 | * c-file-style: "BSD"\r | |
| 615 | * c-basic-offset: 4\r | |
| 616 | * tab-width: 4\r | |
| 617 | * indent-tabs-mode: nil\r | |
| 618 | * End:\r | |
| 619 | */\r |