From: Max Reitz <mreitz@redhat.com>
To: Peter Lieven <pl@kamp.de>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Weil <sw@weilnetz.de>,
Jeff Cody <jcody@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] block/vdi: Limit maximum size even futher
Date: Mon, 27 Oct 2014 12:40:12 +0100 [thread overview]
Message-ID: <544E2F1C.10309@redhat.com> (raw)
In-Reply-To: <544E2F03.7050304@redhat.com>
On 2014-10-27 at 12:39, Max Reitz wrote:
> On 2014-10-27 at 12:10, Peter Lieven wrote:
>> On 27.10.2014 11:56, Max Reitz wrote:
>>> The block layer read and write functions do not like requests which are
>>> bigger than INT_MAX bytes. Since the VDI bmap is read and written in a
>>> single operation, its size is therefore limited accordingly. This
>>> reduces the maximum VDI image size supported by QEMU to half of what it
>>> currently is (down to approximately 512 TB).
>>>
>>> The VDI test 084 has to be adapted accordingly. Actually, one could
>>> clearly see that it was broken from the "Could not open
>>> 'TEST_DIR/t.IMGFMT': Invalid argument" line for an image which was
>>> supposed to work just fine.
>>>
>>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>>> ---
>>> The really funny thing about this is that test 084 still fails after
>>> this patch for me because the computer I am currently working on only
>>> has 4G of main memory (which is exactly what VDI requires for a 512T
>>> image). Any reviewer is therefore kindly asked to test this test
>>> him-/herself; I will do so once I am home (and once I remember to do
>>> it).
>>> ---
>>> block/vdi.c | 6 ++++--
>>> tests/qemu-iotests/084 | 14 +++++++-------
>>> tests/qemu-iotests/084.out | 13 ++++++++-----
>>> 3 files changed, 19 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/block/vdi.c b/block/vdi.c
>>> index 19701ee..f25e4b5 100644
>>> --- a/block/vdi.c
>>> +++ b/block/vdi.c
>>> @@ -120,8 +120,10 @@ typedef unsigned char uuid_t[16];
>>> #define VDI_IS_ALLOCATED(X) ((X) < VDI_DISCARDED)
>>> -/* max blocks in image is (0xffffffff / 4) */
>>> -#define VDI_BLOCKS_IN_IMAGE_MAX 0x3fffffff
>>> +/* The bmap will take up VDI_BLOCKS_IN_IMAGE_MAX * sizeof(uint32_t)
>>> bytes; since
>>> + * the bmap is read and written in a single operation, its size
>>> needs to be
>>> + * limited to INT_MAX */
>>> +#define VDI_BLOCKS_IN_IMAGE_MAX ((unsigned)(INT_MAX /
>>> sizeof(uint32_t)))
>> Test 084 doesn't work:
>>
>> lieven@lieven-pc:~/git/qemu/tests/qemu-iotests$ ./check -vdi 084
>> QEMU -- ./qemu
>> QEMU_IMG -- ./qemu-img
>> QEMU_IO -- ./qemu-io
>> QEMU_NBD -- /home/lieven/git/qemu/tests/qemu-iotests/../../qemu-nbd
>> IMGFMT -- vdi
>> IMGPROTO -- file
>> PLATFORM -- Linux/x86_64 lieven-pc 3.13.0-38-generic
>> SOCKET_SCM_HELPER --
>> /home/lieven/git/qemu/tests/qemu-iotests/socket_scm_helper
>>
>> 084 4s ... - output mismatch (see 084.out.bad)
>> --- /home/lieven/git/qemu/tests/qemu-iotests/084.out 2014-10-27
>> 12:08:40.229116502 +0100
>> +++ 084.out.bad 2014-10-27 12:09:01.516700174 +0100
>> @@ -18,10 +18,7 @@
>> cluster_size: 1048576
>> disk image file size in bytes: 1024
>> Test 1: Maximum size (512 TB):
>> -image: TEST_DIR/t.IMGFMT
>> -file format: IMGFMT
>> -virtual size: 512T (562949952372736 bytes)
>> -cluster_size: 1048576
>> +qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Could not open
>> 'TEST_DIR/t.IMGFMT': Invalid argument
>
> Thanks, than NACK and I'll see to it at home.
*then
(I can't resist)
> Max
>
>> Test 2: Size too large (512TB + 1)
>> qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Unsupported VDI image
>> size (size is 0x1fffffff10000, max supported is 0x1fffffff00000)
>> Failures: 084
>> Failed 1 of 1 tests
>>
>> Peter
>>
>>> #define VDI_DISK_SIZE_MAX ((uint64_t)VDI_BLOCKS_IN_IMAGE_MAX * \
>>> (uint64_t)DEFAULT_CLUSTER_SIZE)
>>> diff --git a/tests/qemu-iotests/084 b/tests/qemu-iotests/084
>>> index 2712c02..9b710e5 100755
>>> --- a/tests/qemu-iotests/084
>>> +++ b/tests/qemu-iotests/084
>>> @@ -66,15 +66,15 @@ stat -c"disk image file size in bytes: %s"
>>> "${TEST_IMG}"
>>> # check for image size too large
>>> # poke max image size, and appropriate blocks_in_image value
>>> -echo "Test 1: Maximum size (1024 TB):"
>>> -poke_file "$TEST_IMG" "$ds_offset" "\x00\x00\xf0\xff\xff\xff\x03\x00"
>>> -poke_file "$TEST_IMG" "$bii_offset" "\xff\xff\xff\x3f"
>>> +echo "Test 1: Maximum size (512 TB):"
>>> +poke_file "$TEST_IMG" "$ds_offset" "\x00\x00\xf0\xff\xff\xff\x01\x00"
>>> +poke_file "$TEST_IMG" "$bii_offset" "\xff\xff\xff\x1f"
>>> _img_info
>>> echo
>>> -echo "Test 2: Size too large (1024TB + 1)"
>>> +echo "Test 2: Size too large (512TB + 1)"
>>> # This should be too large (-EINVAL):
>>> -poke_file "$TEST_IMG" "$ds_offset" "\x00\x00\xf1\xff\xff\xff\x03\x00"
>>> +poke_file "$TEST_IMG" "$ds_offset" "\x00\x00\xf1\xff\xff\xff\x01\x00"
>>> _img_info
>>> echo
>>> @@ -89,9 +89,9 @@ _img_info
>>> echo
>>> echo "Test 4: Size valid (64M), but Blocks In Image exceeds max
>>> allowed"
>>> -# Now check the bounds of blocks_in_image - 0x3fffffff should be
>>> the max
>>> +# Now check the bounds of blocks_in_image - 0x1fffffff should be
>>> the max
>>> # value here, and we should get -ENOTSUP
>>> -poke_file "$TEST_IMG" "$bii_offset" "\x00\x00\x00\x40"
>>> +poke_file "$TEST_IMG" "$bii_offset" "\x00\x00\x00\x20"
>>> _img_info
>>> # Finally, 1MB is the only block size supported. Verify that
>>> diff --git a/tests/qemu-iotests/084.out b/tests/qemu-iotests/084.out
>>> index ea29ae0..4ac0157 100644
>>> --- a/tests/qemu-iotests/084.out
>>> +++ b/tests/qemu-iotests/084.out
>>> @@ -17,17 +17,20 @@ file format: IMGFMT
>>> virtual size: 64M (67108864 bytes)
>>> cluster_size: 1048576
>>> disk image file size in bytes: 1024
>>> -Test 1: Maximum size (1024 TB):
>>> -qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Could not open
>>> 'TEST_DIR/t.IMGFMT': Invalid argument
>>> +Test 1: Maximum size (512 TB):
>>> +image: TEST_DIR/t.IMGFMT
>>> +file format: IMGFMT
>>> +virtual size: 512T (562949952372736 bytes)
>>> +cluster_size: 1048576
>>> -Test 2: Size too large (1024TB + 1)
>>> -qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Unsupported VDI image
>>> size (size is 0x3fffffff10000, max supported is 0x3fffffff00000)
>>> +Test 2: Size too large (512TB + 1)
>>> +qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Unsupported VDI image
>>> size (size is 0x1fffffff10000, max supported is 0x1fffffff00000)
>>> Test 3: Size valid (64M), but Blocks In Image too small (63)
>>> qemu-img: Could not open 'TEST_DIR/t.IMGFMT': unsupported VDI
>>> image (disk size 67108864, image bitmap has room for 66060288)
>>> Test 4: Size valid (64M), but Blocks In Image exceeds max allowed
>>> -qemu-img: Could not open 'TEST_DIR/t.IMGFMT': unsupported VDI image
>>> (too many blocks 1073741824, max is 1073741823)
>>> +qemu-img: Could not open 'TEST_DIR/t.IMGFMT': unsupported VDI image
>>> (too many blocks 536870912, max is 536870911)
>>> Test 5: Valid Image: 64MB, Blocks In Image 64, Block Size 1MB
>>> image: TEST_DIR/t.IMGFMT
>>
>>
>
prev parent reply other threads:[~2014-10-27 11:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-27 10:56 [Qemu-devel] [PATCH] block/vdi: Limit maximum size even futher Max Reitz
2014-10-27 11:10 ` Peter Lieven
2014-10-27 11:39 ` Max Reitz
2014-10-27 11:40 ` Max Reitz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=544E2F1C.10309@redhat.com \
--to=mreitz@redhat.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=pl@kamp.de \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=sw@weilnetz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).