]>
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 | |
62 | * of a properly formated node string, without loss of information.\r | |
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 |