All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.