@@ -216,6 +216,41 @@ 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)
{
@@ -304,36 +339,8 @@ 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) /
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(-)