Loading...
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 "ring.h"
13#include "../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 * Maximum scatter/gather segments per request.
62 * This is carefully chosen so that sizeof(struct blkif_ring) <= PAGE_SIZE.
63 * NB. This could be 12 if the ring indexes weren't stored in the same page.
64 */
65#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
66
67struct blkif_request_rw {
68 blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */
69 struct blkif_request_segment {
70 grant_ref_t gref; /* reference to I/O buffer frame */
71 /* @first_sect: first sector in frame to transfer (inclusive). */
72 /* @last_sect: last sector in frame to transfer (inclusive). */
73 uint8_t first_sect, last_sect;
74 } seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
75};
76
77struct blkif_request {
78 uint8_t operation; /* BLKIF_OP_??? */
79 uint8_t nr_segments; /* number of segments */
80 blkif_vdev_t handle; /* only for read/write requests */
81 uint64_t id; /* private guest value, echoed in resp */
82 union {
83 struct blkif_request_rw rw;
84 } u;
85};
86
87struct blkif_response {
88 uint64_t id; /* copied from request */
89 uint8_t operation; /* copied from request */
90 int16_t status; /* BLKIF_RSP_??? */
91};
92
93/*
94 * STATUS RETURN CODES.
95 */
96 /* Operation not supported (only happens on barrier writes). */
97#define BLKIF_RSP_EOPNOTSUPP -2
98 /* Operation failed for some unspecified reason (-EIO). */
99#define BLKIF_RSP_ERROR -1
100 /* Operation completed successfully. */
101#define BLKIF_RSP_OKAY 0
102
103/*
104 * Generate blkif ring structures and types.
105 */
106
107DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
108
109#define VDISK_CDROM 0x1
110#define VDISK_REMOVABLE 0x2
111#define VDISK_READONLY 0x4
112
113/* Xen-defined major numbers for virtual disks, they look strangely
114 * familiar */
115#define XEN_IDE0_MAJOR 3
116#define XEN_IDE1_MAJOR 22
117#define XEN_SCSI_DISK0_MAJOR 8
118#define XEN_SCSI_DISK1_MAJOR 65
119#define XEN_SCSI_DISK2_MAJOR 66
120#define XEN_SCSI_DISK3_MAJOR 67
121#define XEN_SCSI_DISK4_MAJOR 68
122#define XEN_SCSI_DISK5_MAJOR 69
123#define XEN_SCSI_DISK6_MAJOR 70
124#define XEN_SCSI_DISK7_MAJOR 71
125#define XEN_SCSI_DISK8_MAJOR 128
126#define XEN_SCSI_DISK9_MAJOR 129
127#define XEN_SCSI_DISK10_MAJOR 130
128#define XEN_SCSI_DISK11_MAJOR 131
129#define XEN_SCSI_DISK12_MAJOR 132
130#define XEN_SCSI_DISK13_MAJOR 133
131#define XEN_SCSI_DISK14_MAJOR 134
132#define XEN_SCSI_DISK15_MAJOR 135
133
134#endif /* __XEN_PUBLIC_IO_BLKIF_H__ */
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#ifndef CONFIG_X86_32
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#ifndef CONFIG_X86_32
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#ifndef CONFIG_X86_32
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#ifndef CONFIG_X86_32
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#ifndef CONFIG_X86_32
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__ */