Changes since v3:

- Split the change into two patches [Philippe Mathieu-Daude].

It was found that 'qemu-nbd' is not able to work with some disk images

exported from Azure as it uses a currently unknown 'wa\0\0' 'creator app'

signature. QEMU currently supports two methods for determining the image

size: CHS and 'current_size' and the list of known 'creator app's is used

to decide between the two. Invert the logic in QEMU and make 'current_size'

the default as it seems that VPC and old QEMU are the only two legacy apps

where preferring CHS makes sense.

Vitaly Kuznetsov (2):

vpc: Split off vpc_ignore_current_size() helper

vpc: Read images exported from Azure correctly

block/vpc.c | 65 ++++++++++++++++++++++++++++-------------------------

1 file changed, 35 insertions(+), 30 deletions(-)

--

2.47.0

In preparation to making changes to the logic deciding whether CHS or

'current_size' need to be used in determining the image size, split off

vpc_ignore_current_size() helper.

No functional change intended.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>

---

block/vpc.c | 67 +++++++++++++++++++++++++++++------------------------

1 file changed, 37 insertions(+), 30 deletions(-)

diff --git a/block/vpc.c b/block/vpc.c

index XXXXXXX..XXXXXXX 100644

--- a/block/vpc.c

+++ b/block/vpc.c

@@ -XXX,XX +XXX,XX @@ static void vpc_parse_options(BlockDriverState *bs, QemuOpts *opts,

}

}

+/*

+ * Microsoft Virtual PC and Microsoft Hyper-V produce and read

+ * VHD image sizes differently. VPC will rely on CHS geometry,

+ * while Hyper-V and disk2vhd use the size specified in the footer.

+ *

+ * We use a couple of approaches to try and determine the correct method:

+ * look at the Creator App field, and look for images that have CHS

+ * geometry that is the maximum value.

+ *

+ * If the CHS geometry is the maximum CHS geometry, then we assume that

+ * the size is the footer->current_size to avoid truncation. Otherwise,

+ * we follow the table based on footer->creator_app:

+ *

+ * Known creator apps:

+ * 'vpc ' : CHS Virtual PC (uses disk geometry)

+ * 'qemu' : CHS QEMU (uses disk geometry)

+ * 'qem2' : current_size QEMU (uses current_size)

+ * 'win ' : current_size Hyper-V

+ * 'd2v ' : current_size Disk2vhd

+ * 'tap\0' : current_size XenServer

+ * 'CTXS' : current_size XenConverter

+ *

+ * The user can override the table values via drive options, however

+ * even with an override we will still use current_size for images

+ * that have CHS geometry of the maximum size.

+ */

+static bool vpc_ignore_current_size(VHDFooter *footer)

+{

+ return !!strncmp(footer->creator_app, "win ", 4) &&

+ !!strncmp(footer->creator_app, "qem2", 4) &&

+ !!strncmp(footer->creator_app, "d2v ", 4) &&

+ !!strncmp(footer->creator_app, "CTXS", 4) &&

+ !!memcmp(footer->creator_app, "tap", 4));

+}

+

static int vpc_open(BlockDriverState *bs, QDict *options, int flags,

Error **errp)

{

@@ -XXX,XX +XXX,XX @@ static int vpc_open(BlockDriverState *bs, QDict *options, int flags,

bs->total_sectors = (int64_t)

be16_to_cpu(footer->cyls) * footer->heads * footer->secs_per_cyl;

- /* Microsoft Virtual PC and Microsoft Hyper-V produce and read

- * VHD image sizes differently. VPC will rely on CHS geometry,

- * while Hyper-V and disk2vhd use the size specified in the footer.

- *

- * We use a couple of approaches to try and determine the correct method:

- * look at the Creator App field, and look for images that have CHS

- * geometry that is the maximum value.

- *

- * If the CHS geometry is the maximum CHS geometry, then we assume that

- * the size is the footer->current_size to avoid truncation. Otherwise,

- * we follow the table based on footer->creator_app:

- *

- * Known creator apps:

- * 'vpc ' : CHS Virtual PC (uses disk geometry)

- * 'qemu' : CHS QEMU (uses disk geometry)

- * 'qem2' : current_size QEMU (uses current_size)

- * 'win ' : current_size Hyper-V

- * 'd2v ' : current_size Disk2vhd

- * 'tap\0' : current_size XenServer

- * 'CTXS' : current_size XenConverter

- *

- * The user can override the table values via drive options, however

- * even with an override we will still use current_size for images

- * that have CHS geometry of the maximum size.

- */

- use_chs = (!!strncmp(footer->creator_app, "win ", 4) &&

- !!strncmp(footer->creator_app, "qem2", 4) &&

- !!strncmp(footer->creator_app, "d2v ", 4) &&

- !!strncmp(footer->creator_app, "CTXS", 4) &&

- !!memcmp(footer->creator_app, "tap", 4)) || s->force_use_chs;

+ /* Use CHS or current_size to determine the image size. */

+ use_chs = vpc_ignore_current_size(footer) || s->force_use_chs;

if (!use_chs || bs->total_sectors == VHD_MAX_GEOMETRY || s->force_use_sz) {

bs->total_sectors = be64_to_cpu(footer->current_size) /

--

2.47.0

Overall, it seems that only VPC and old QEMUs need to be ignored as all new

creator apps seem to have reliable current_size. Invert the logic and make

'current_size' method the default to avoid adding every new creator app to

the list.