From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiieZ-00045N-QV for qemu-devel@nongnu.org; Mon, 27 Oct 2014 07:40:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XiieT-0001Ss-Lj for qemu-devel@nongnu.org; Mon, 27 Oct 2014 07:40:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiieT-0001Sl-Du for qemu-devel@nongnu.org; Mon, 27 Oct 2014 07:39:57 -0400 Message-ID: <544E2F03.7050304@redhat.com> Date: Mon, 27 Oct 2014 12:39:47 +0100 From: Max Reitz MIME-Version: 1.0 References: <1414407405-20895-1-git-send-email-mreitz@redhat.com> <544E2812.2000301@kamp.de> In-Reply-To: <544E2812.2000301@kamp.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] block/vdi: Limit maximum size even futher List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Weil , Jeff Cody , Stefan Hajnoczi 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 >> --- >> 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. 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 > >