qemu/tests/qemu-iotests
Vladimir Sementsov-Ogievskiy 8b1170012b block: introduce BDRV_MAX_LENGTH
We are going to modify block layer to work with 64bit requests. And
first step is moving to int64_t type for both offset and bytes
arguments in all block request related functions.

It's mostly safe (when widening signed or unsigned int to int64_t), but
switching from uint64_t is questionable.

So, let's first establish the set of requests we want to work with.
First signed int64_t should be enough, as off_t is signed anyway. Then,
obviously offset + bytes should not overflow.

And most interesting: (offset + bytes) being aligned up should not
overflow as well. Aligned to what alignment? First thing that comes in
mind is bs->bl.request_alignment, as we align up request to this
alignment. But there is another thing: look at
bdrv_mark_request_serialising(). It aligns request up to some given
alignment. And this parameter may be bdrv_get_cluster_size(), which is
often a lot greater than bs->bl.request_alignment.
Note also, that bdrv_mark_request_serialising() uses signed int64_t for
calculations. So, actually, we already depend on some restrictions.

Happily, bdrv_get_cluster_size() returns int and
bs->bl.request_alignment has 32bit unsigned type, but defined to be a
power of 2 less than INT_MAX. So, we may establish, that INT_MAX is
absolute maximum for any kind of alignment that may occur with the
request.

Note, that bdrv_get_cluster_size() is not documented to return power
of 2, still bdrv_mark_request_serialising() behaves like it is.
Also, backup uses bdi.cluster_size and is not prepared to it not being
power of 2.
So, let's establish that Qemu supports only power-of-2 clusters and
alignments.

So, alignment can't be greater than 2^30.

Finally to be safe with calculations, to not calculate different
maximums for different nodes (depending on cluster size and
request_alignment), let's simply set QEMU_ALIGN_DOWN(INT64_MAX, 2^30)
as absolute maximum bytes length for Qemu. Actually, it's not much less
than INT64_MAX.

OK, then, let's apply it to block/io.

Let's consider all block/io entry points of offset/bytes:

4 bytes/offset interface functions: bdrv_co_preadv_part(),
bdrv_co_pwritev_part(), bdrv_co_copy_range_internal() and
bdrv_co_pdiscard() and we check them all with bdrv_check_request().

We also have one entry point with only offset: bdrv_co_truncate().
Check the offset.

And one public structure: BdrvTrackedRequest. Happily, it has only
three external users:

 file-posix.c: adopted by this patch
 write-threshold.c: only read fields
 test-write-threshold.c: sets obviously small constant values

Better is to make the structure private and add corresponding
interfaces.. Still it's not obvious what kind of interface is needed
for file-posix.c. Let's keep it public but add corresponding
assertions.

After this patch we'll convert functions in block/io.c to int64_t bytes
and offset parameters. We can assume that offset/bytes pair always
satisfy new restrictions, and make
corresponding assertions where needed. If we reach some offset/bytes
point in block/io.c missing bdrv_check_request() it is considered a
bug. As well, if block/io.c modifies a offset/bytes request, expanding
it more then aligning up to request_alignment, it's a bug too.

For all io requests except for discard we keep for now old restriction
of 32bit request length.

iotest 206 output error message changed, as now test disk size is
larger than new limit. Add one more test case with new maximum disk
size to cover too-big-L1 case.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20201203222713.13507-5-vsementsov@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11 17:52:40 +01:00
..
001
2020-05-05 13:17:36 +02:00
002
003
004
005
007
008
009
010
011
012
013
014
015
017
2020-07-17 14:20:57 +02:00
021
022
023
025
2020-12-11 17:52:40 +01:00
026
2020-12-11 17:52:40 +01:00
027
028
2020-12-11 17:52:40 +01:00
2020-12-11 17:52:40 +01:00
029
2020-07-17 14:20:57 +02:00
031
2020-12-11 17:52:40 +01:00
032
033
034
2020-12-11 17:52:40 +01:00
035
036
2020-12-11 17:52:40 +01:00
037
2020-12-11 17:52:40 +01:00
038
2020-12-11 17:52:40 +01:00
039
2020-12-11 17:52:40 +01:00
041
2020-09-08 13:40:49 +02:00
2020-09-08 13:40:49 +02:00
044
045
046
2020-12-11 17:52:40 +01:00
2020-12-11 17:52:40 +01:00
047
048
050
2020-12-11 17:52:40 +01:00
052
2020-05-05 13:17:36 +02:00
053
054
2020-12-11 17:52:40 +01:00
057
058
2020-09-02 16:32:14 -05:00
060
2020-12-11 17:52:40 +01:00
062
063
064
066
068
070
071
2020-12-11 17:52:40 +01:00
072
073
2020-07-17 14:20:57 +02:00
074
075
076
077
078
079
2020-12-11 17:52:40 +01:00
080
2020-12-11 17:52:40 +01:00
083
084
086
087
2020-07-06 08:49:28 +02:00
088
089
2020-12-11 17:52:40 +01:00
2020-12-11 17:52:40 +01:00
090
2020-12-11 17:52:40 +01:00
091
2020-12-11 17:52:40 +01:00
092
093
094
095
2020-12-11 17:52:40 +01:00
096
097
2020-12-11 17:52:40 +01:00
098
2020-12-11 17:52:40 +01:00
099
101
102
2020-12-11 17:52:40 +01:00
103
2020-12-11 17:52:40 +01:00
104
105
106
2020-12-11 17:52:40 +01:00
107
2020-12-11 17:52:40 +01:00
108
2020-12-11 17:52:40 +01:00
111
2020-12-11 17:52:40 +01:00
112
2020-12-11 17:52:40 +01:00
114
2020-07-17 14:20:57 +02:00
115
2020-12-11 17:52:40 +01:00
116
117
2020-12-11 17:52:40 +01:00
119
120
2020-12-11 17:52:40 +01:00
121
2020-12-11 17:52:40 +01:00
123
124
127
2020-12-11 17:52:40 +01:00
128
130
2020-07-17 14:20:57 +02:00
131
132
133
2020-12-11 17:52:40 +01:00
134
2020-07-17 14:20:57 +02:00
135
136
137
2020-12-11 17:52:40 +01:00
138
2020-12-11 17:52:40 +01:00
140
2020-12-11 17:52:40 +01:00
144
145
147
148
2020-05-08 13:26:35 +02:00
149
2020-05-05 13:17:36 +02:00
150
151
152
154
2020-12-11 17:52:40 +01:00
2020-03-11 15:54:38 +01:00
156
2020-07-17 14:20:57 +02:00
157
158
2020-07-17 14:20:57 +02:00
159
160
161
2020-12-11 17:52:40 +01:00
162
163
165
170
171
2020-12-11 17:52:40 +01:00
2020-06-23 16:07:07 +02:00
173
174
2020-12-11 17:52:40 +01:00
175
2020-12-11 17:52:40 +01:00
176
2020-12-11 17:52:40 +01:00
177
2020-12-11 17:52:40 +01:00
178
2020-07-06 08:49:28 +02:00
2020-05-28 13:15:23 -05:00
179
2020-12-11 17:52:40 +01:00
181
182
183
2020-12-11 17:52:40 +01:00
185
186
2020-12-11 17:52:40 +01:00
187
2020-12-11 17:52:40 +01:00
188
2020-07-06 08:49:28 +02:00
191
2020-12-11 17:52:40 +01:00
192
194
2020-09-15 11:05:12 +02:00
195
2020-12-11 17:52:40 +01:00
196
197
2020-07-28 15:28:56 +02:00
2020-07-28 15:28:56 +02:00
200
2020-12-11 17:52:40 +01:00
201
202
2020-05-05 13:17:36 +02:00
203
2020-05-05 13:17:36 +02:00
204
2020-12-11 17:52:40 +01:00
2020-09-07 12:31:31 +02:00
205
206
2020-12-11 17:52:40 +01:00
2020-12-11 17:52:40 +01:00
207
2020-05-05 13:17:36 +02:00
208
2020-09-15 11:05:12 +02:00
209
2020-05-05 13:17:36 +02:00
210
2020-05-05 13:17:36 +02:00
211
2020-05-05 13:17:36 +02:00
212
2020-05-05 13:17:36 +02:00
213
2020-05-05 13:17:36 +02:00
214
2020-12-11 17:52:40 +01:00
215
217
2020-12-11 17:52:40 +01:00
218
2020-05-05 13:17:36 +02:00
219
2020-05-05 13:17:36 +02:00
220
2020-12-11 17:52:40 +01:00
222
2020-09-15 11:05:12 +02:00
226
227
229
2020-12-11 17:52:40 +01:00
231
232
233
234
2020-05-05 13:17:36 +02:00
235
2020-05-05 13:17:36 +02:00
236
2020-05-05 13:17:36 +02:00
237
2020-05-05 13:17:36 +02:00
238
2020-05-05 13:17:36 +02:00
239
240
2020-11-09 15:44:21 +01:00
2020-11-09 15:44:21 +01:00
241
246
2020-05-05 13:17:36 +02:00
247
2020-12-11 17:52:40 +01:00
248
2020-05-05 13:17:36 +02:00
249
2020-12-11 17:52:40 +01:00
250
2020-12-11 17:52:40 +01:00
252
2020-12-11 17:52:40 +01:00
253
254
2020-05-05 13:17:36 +02:00
255
2020-05-05 13:17:36 +02:00
256
2020-05-05 13:17:36 +02:00
257
2020-09-15 11:05:12 +02:00
258
2020-05-05 13:17:36 +02:00
259
2020-09-02 16:32:14 -05:00
260
2020-05-05 13:17:36 +02:00
262
2020-05-05 13:17:36 +02:00
263
2020-07-06 08:49:28 +02:00
265
2020-12-11 17:52:40 +01:00
266
268
2020-12-11 17:52:40 +01:00
272
2020-12-11 17:52:40 +01:00
273
2020-12-11 17:52:40 +01:00
274
2020-10-23 13:42:16 +01:00
277
2020-05-05 13:17:36 +02:00
279
2020-12-11 17:52:40 +01:00
280
2020-05-05 13:17:36 +02:00
281
282
2020-07-17 14:20:57 +02:00
284
2020-07-06 08:49:28 +02:00
286
2020-12-11 17:52:40 +01:00
287
2020-12-11 17:52:40 +01:00
289
2020-12-11 17:52:40 +01:00
290
2020-12-11 17:52:40 +01:00
291
2020-12-11 17:52:40 +01:00
292
2020-12-11 17:52:40 +01:00
293
2020-12-11 17:52:40 +01:00
294
2020-12-11 17:52:40 +01:00
295
2020-07-06 08:49:28 +02:00
2020-07-06 08:49:28 +02:00
296
2020-07-21 10:49:02 +02:00
297
2020-05-18 19:05:25 +02:00
301
2020-07-14 15:18:59 +02:00
303
2020-08-21 08:56:09 -05:00
305
2020-12-11 17:52:40 +01:00
307
2020-10-02 15:46:40 +02:00
308
2020-12-11 17:52:40 +01:00
2020-12-11 17:52:40 +01:00
2020-12-11 17:52:40 +01:00
2020-12-11 17:52:40 +01:00
2020-12-11 17:52:40 +01:00
2020-09-30 19:09:19 +02:00

=== This is the QEMU I/O test suite ===

* Intro

This package contains a simple test suite for the I/O layer of qemu.
It does not require a guest, but only the qemu, qemu-img and qemu-io
binaries.  This does limit it to exercise the low-level I/O path only
but no actual block drivers like ide, scsi or virtio.

* Usage

Just run ./check to run all tests for the raw image format, or ./check
-qcow2 to test the qcow2 image format.  The output of ./check -h explains
additional options to test further image formats or I/O methods.

* Feedback and patches

Please send improvements to the test suite, general feedback or just
reports of failing tests cases to qemu-devel@nongnu.org with a CC:
to qemu-block@nongnu.org.