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
017
2020-07-17 14:20:57 +02:00
025
2020-12-11 17:52:40 +01:00
026
2020-12-11 17:52:40 +01:00
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
034
2020-12-11 17:52:40 +01:00
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
2017-07-11 17:45:02 +02:00
046
2020-12-11 17:52:40 +01:00
2020-12-11 17:52:40 +01:00
050
2020-12-11 17:52:40 +01:00
052
2020-05-05 13:17:36 +02:00
054
2020-12-11 17:52:40 +01:00
2020-09-02 16:32:14 -05:00
060
2020-12-11 17:52:40 +01:00
063
2020-01-06 13:43:07 +01:00
2020-01-06 13:43:07 +01:00
2015-01-23 12:41:32 -05:00
2017-05-11 12:08:24 +02:00
2017-09-06 15:19:01 +01:00
071
2020-12-11 17:52:40 +01:00
073
2020-07-17 14:20:57 +02:00
079
2020-12-11 17:52:40 +01:00
080
2020-12-11 17:52:40 +01:00
083
2019-10-28 11:22:31 +01:00
087
2020-07-06 08:49:28 +02:00
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
2020-01-06 13:43:07 +01:00
095
2020-12-11 17:52:40 +01:00
097
2020-12-11 17:52:40 +01:00
098
2020-12-11 17:52:40 +01:00
102
2020-12-11 17:52:40 +01:00
103
2020-12-11 17:52:40 +01:00
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
2018-06-11 16:18:45 +02:00
114
2020-07-17 14:20:57 +02:00
115
2020-12-11 17:52:40 +01:00
117
2020-12-11 17:52:40 +01:00
2019-08-16 10:25:16 +02:00
120
2020-12-11 17:52:40 +01:00
121
2020-12-11 17:52:40 +01:00
127
2020-12-11 17:52:40 +01:00
130
2020-07-17 14:20:57 +02:00
133
2020-12-11 17:52:40 +01:00
134
2020-07-17 14:20:57 +02:00
2016-05-19 16:45:31 +02:00
137
2020-12-11 17:52:40 +01:00
2020-01-06 13:43:07 +01:00
138
2020-12-11 17:52:40 +01:00
140
2020-12-11 17:52:40 +01:00
147
2020-02-20 16:43:42 +01:00
148
2020-05-08 13:26:35 +02:00
149
2020-05-05 13:17:36 +02:00
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
158
2020-07-17 14:20:57 +02:00
2016-09-20 22:10:57 +02:00
2016-09-20 22:10:57 +02:00
161
2020-12-11 17:52:40 +01:00
162
2019-10-10 12:13:23 +02:00
2017-09-26 15:00:32 +02:00
2016-09-20 22:10:57 +02:00
171
2020-12-11 17:52:40 +01:00
2020-06-23 16:07:07 +02:00
174
2020-12-11 17:52:40 +01:00
2017-02-12 00:47:42 +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
183
2020-12-11 17:52:40 +01:00
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
2019-10-28 11:22:31 +01:00
194
2020-09-15 11:05:12 +02:00
195
2020-12-11 17:52:40 +01:00
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
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
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
2019-06-24 16:01:04 +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
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
2019-10-10 10:56:18 +02:00
229
2020-12-11 17:52:40 +01:00
2019-03-19 15:49:29 +01:00
233
2019-06-13 08:50:47 -05:00
234
2020-05-05 13:17:36 +02:00
2019-02-01 13:46:44 +01: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
2019-02-01 13:46:44 +01:00
240
2020-11-09 15:44:21 +01:00
2020-11-09 15:44:21 +01:00
246
2020-05-05 13:17:36 +02:00
247
2020-12-11 17:52:40 +01:00
2019-03-19 15:49:29 +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
2019-06-04 16:55:58 +02:00
252
2020-12-11 17:52:40 +01:00
254
2020-05-05 13:17:36 +02:00
2019-08-16 16:28:03 -04: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
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
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
2019-11-18 16:01:31 -06:00
279
2020-12-11 17:52:40 +01:00
280
2020-05-05 13:17:36 +02:00
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.