qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
>>
>>
>

      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).