2005-04-28 00:17:58 +04:00
|
|
|
/*
|
2009-08-31 23:42:16 +04:00
|
|
|
* Block driver for Connectix / Microsoft Virtual PC images
|
2007-09-17 01:08:06 +04:00
|
|
|
*
|
2005-04-28 00:17:58 +04:00
|
|
|
* Copyright (c) 2005 Alex Beregszaszi
|
2009-01-26 23:27:02 +03:00
|
|
|
* Copyright (c) 2009 Kevin Wolf <kwolf@suse.de>
|
2007-09-17 01:08:06 +04:00
|
|
|
*
|
2005-04-28 00:17:58 +04:00
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
2018-02-01 14:18:46 +03:00
|
|
|
|
2016-01-18 21:01:42 +03:00
|
|
|
#include "qemu/osdep.h"
|
include/qemu/osdep.h: Don't include qapi/error.h
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the
Error typedef. Since then, we've moved to include qemu/osdep.h
everywhere. Its file comment explains: "To avoid getting into
possible circular include dependencies, this file should not include
any other QEMU headers, with the exceptions of config-host.h,
compiler.h, os-posix.h and os-win32.h, all of which are doing a
similar job to this file and are under similar constraints."
qapi/error.h doesn't do a similar job, and it doesn't adhere to
similar constraints: it includes qapi-types.h. That's in excess of
100KiB of crap most .c files don't actually need.
Add the typedef to qemu/typedefs.h, and include that instead of
qapi/error.h. Include qapi/error.h in .c files that need it and don't
get it now. Include qapi-types.h in qom/object.h for uint16List.
Update scripts/clean-includes accordingly. Update it further to match
reality: replace config.h by config-target.h, add sysemu/os-posix.h,
sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h
comment quoted above similarly.
This reduces the number of objects depending on qapi/error.h from "all
of them" to less than a third. Unfortunately, the number depending on
qapi-types.h shrinks only a little. More work is needed for that one.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-14 11:01:28 +03:00
|
|
|
#include "qapi/error.h"
|
2012-12-17 21:19:44 +04:00
|
|
|
#include "block/block_int.h"
|
2018-06-14 22:14:28 +03:00
|
|
|
#include "block/qdict.h"
|
2016-03-08 17:57:05 +03:00
|
|
|
#include "sysemu/block-backend.h"
|
2012-12-17 21:20:00 +04:00
|
|
|
#include "qemu/module.h"
|
2018-02-01 14:18:46 +03:00
|
|
|
#include "qemu/option.h"
|
2017-04-06 13:00:28 +03:00
|
|
|
#include "migration/blocker.h"
|
2016-03-15 19:22:36 +03:00
|
|
|
#include "qemu/bswap.h"
|
2016-09-21 07:27:18 +03:00
|
|
|
#include "qemu/uuid.h"
|
2022-02-26 21:07:23 +03:00
|
|
|
#include "qemu/memalign.h"
|
2018-03-09 21:53:19 +03:00
|
|
|
#include "qapi/qmp/qdict.h"
|
|
|
|
#include "qapi/qobject-input-visitor.h"
|
|
|
|
#include "qapi/qapi-visit-block-core.h"
|
2005-04-28 00:17:58 +04:00
|
|
|
|
|
|
|
/**************************************************************/
|
|
|
|
|
|
|
|
//#define CACHE
|
|
|
|
|
2009-01-26 23:26:49 +03:00
|
|
|
enum vhd_type {
|
|
|
|
VHD_FIXED = 2,
|
|
|
|
VHD_DYNAMIC = 3,
|
|
|
|
VHD_DIFFERENCING = 4,
|
|
|
|
};
|
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Seconds since Jan 1, 2000 0:00:00 (UTC) */
|
2009-01-26 23:27:06 +03:00
|
|
|
#define VHD_TIMESTAMP_BASE 946684800
|
|
|
|
|
block/vpc: give option to force the current_size field in .bdrv_create
When QEMU creates a VHD image, it goes by the original spec,
calculating the current_size based on the nearest CHS geometry (with an
exception for disks > 127GB).
Apparently, Azure will only allow images that are sized to the nearest
MB, and the current_size as calculated from CHS cannot guarantee that.
Allow QEMU to create images similar to how Hyper-V creates images, by
setting current_size to the specified virtual disk size. This
introduces an option, force_size, to be passed to the vpc format during
image creation, e.g.:
qemu-img convert -f raw -o force_size -O vpc test.img test.vhd
When using the "force_size" option, the creator app field used by
QEMU will be "qem2" instead of "qemu", to indicate the difference.
In light of this, we also add parsing of the "qem2" field during
vpc_open.
Bug reference: https://bugs.launchpad.net/qemu/+bug/1490611
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:29 +03:00
|
|
|
#define VHD_CHS_MAX_C 65535LL
|
|
|
|
#define VHD_CHS_MAX_H 16
|
|
|
|
#define VHD_CHS_MAX_S 255
|
|
|
|
|
2016-03-23 06:33:41 +03:00
|
|
|
#define VHD_MAX_SECTORS 0xff000000 /* 2040 GiB max image size */
|
block/vpc: give option to force the current_size field in .bdrv_create
When QEMU creates a VHD image, it goes by the original spec,
calculating the current_size based on the nearest CHS geometry (with an
exception for disks > 127GB).
Apparently, Azure will only allow images that are sized to the nearest
MB, and the current_size as calculated from CHS cannot guarantee that.
Allow QEMU to create images similar to how Hyper-V creates images, by
setting current_size to the specified virtual disk size. This
introduces an option, force_size, to be passed to the vpc format during
image creation, e.g.:
qemu-img convert -f raw -o force_size -O vpc test.img test.vhd
When using the "force_size" option, the creator app field used by
QEMU will be "qem2" instead of "qemu", to indicate the difference.
In light of this, we also add parsing of the "qem2" field during
vpc_open.
Bug reference: https://bugs.launchpad.net/qemu/+bug/1490611
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:29 +03:00
|
|
|
#define VHD_MAX_GEOMETRY (VHD_CHS_MAX_C * VHD_CHS_MAX_H * VHD_CHS_MAX_S)
|
|
|
|
|
|
|
|
#define VPC_OPT_FORCE_SIZE "force_size"
|
2014-03-26 16:05:36 +04:00
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* always big-endian */
|
2013-09-25 20:08:49 +04:00
|
|
|
typedef struct vhd_footer {
|
2016-03-23 06:33:44 +03:00
|
|
|
char creator[8]; /* "conectix" */
|
2009-01-26 23:26:49 +03:00
|
|
|
uint32_t features;
|
|
|
|
uint32_t version;
|
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Offset of next header structure, 0xFFFFFFFF if none */
|
2009-01-26 23:26:49 +03:00
|
|
|
uint64_t data_offset;
|
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Seconds since Jan 1, 2000 0:00:00 (UTC) */
|
2009-01-26 23:26:49 +03:00
|
|
|
uint32_t timestamp;
|
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
char creator_app[4]; /* e.g., "vpc " */
|
2009-01-26 23:26:49 +03:00
|
|
|
uint16_t major;
|
|
|
|
uint16_t minor;
|
2016-03-23 06:33:44 +03:00
|
|
|
char creator_os[4]; /* "Wi2k" */
|
2009-01-26 23:26:49 +03:00
|
|
|
|
|
|
|
uint64_t orig_size;
|
2015-03-03 13:41:55 +03:00
|
|
|
uint64_t current_size;
|
2009-01-26 23:26:49 +03:00
|
|
|
|
|
|
|
uint16_t cyls;
|
|
|
|
uint8_t heads;
|
|
|
|
uint8_t secs_per_cyl;
|
|
|
|
|
|
|
|
uint32_t type;
|
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Checksum of the Hard Disk Footer ("one's complement of the sum of all
|
|
|
|
the bytes in the footer without the checksum field") */
|
2009-01-26 23:26:49 +03:00
|
|
|
uint32_t checksum;
|
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* UUID used to identify a parent hard disk (backing file) */
|
2016-09-21 07:27:18 +03:00
|
|
|
QemuUUID uuid;
|
2009-01-26 23:26:49 +03:00
|
|
|
|
|
|
|
uint8_t in_saved_state;
|
2020-12-17 19:20:01 +03:00
|
|
|
uint8_t reserved[427];
|
2013-09-25 20:08:49 +04:00
|
|
|
} QEMU_PACKED VHDFooter;
|
2009-01-26 23:26:46 +03:00
|
|
|
|
2020-12-17 19:20:01 +03:00
|
|
|
QEMU_BUILD_BUG_ON(sizeof(VHDFooter) != 512);
|
|
|
|
|
2013-09-25 20:08:49 +04:00
|
|
|
typedef struct vhd_dyndisk_header {
|
2016-03-23 06:33:44 +03:00
|
|
|
char magic[8]; /* "cxsparse" */
|
2009-01-26 23:26:49 +03:00
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Offset of next header structure, 0xFFFFFFFF if none */
|
2009-01-26 23:26:49 +03:00
|
|
|
uint64_t data_offset;
|
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Offset of the Block Allocation Table (BAT) */
|
2009-01-26 23:26:49 +03:00
|
|
|
uint64_t table_offset;
|
|
|
|
|
|
|
|
uint32_t version;
|
2016-03-23 06:33:44 +03:00
|
|
|
uint32_t max_table_entries; /* 32bit/entry */
|
2009-01-26 23:26:49 +03:00
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* 2 MB by default, must be a power of two */
|
2009-01-26 23:26:49 +03:00
|
|
|
uint32_t block_size;
|
|
|
|
|
|
|
|
uint32_t checksum;
|
|
|
|
uint8_t parent_uuid[16];
|
|
|
|
uint32_t parent_timestamp;
|
|
|
|
uint32_t reserved;
|
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Backing file name (in UTF-16) */
|
2009-01-26 23:26:49 +03:00
|
|
|
uint8_t parent_name[512];
|
|
|
|
|
|
|
|
struct {
|
|
|
|
uint32_t platform;
|
|
|
|
uint32_t data_space;
|
|
|
|
uint32_t data_length;
|
|
|
|
uint32_t reserved;
|
|
|
|
uint64_t data_offset;
|
|
|
|
} parent_locator[8];
|
2020-12-17 19:19:59 +03:00
|
|
|
uint8_t reserved2[256];
|
2013-09-25 20:08:49 +04:00
|
|
|
} QEMU_PACKED VHDDynDiskHeader;
|
2005-04-28 00:17:58 +04:00
|
|
|
|
2020-12-17 19:19:59 +03:00
|
|
|
QEMU_BUILD_BUG_ON(sizeof(VHDDynDiskHeader) != 1024);
|
|
|
|
|
2005-04-28 00:17:58 +04:00
|
|
|
typedef struct BDRVVPCState {
|
2011-10-20 15:16:21 +04:00
|
|
|
CoMutex lock;
|
2020-12-17 19:20:01 +03:00
|
|
|
VHDFooter footer;
|
2009-01-26 23:27:02 +03:00
|
|
|
uint64_t free_data_block_offset;
|
2009-01-26 23:26:49 +03:00
|
|
|
int max_table_entries;
|
2005-04-28 00:17:58 +04:00
|
|
|
uint32_t *pagetable;
|
2009-01-26 23:27:02 +03:00
|
|
|
uint64_t bat_offset;
|
|
|
|
uint64_t last_bitmap_offset;
|
2005-04-28 00:17:58 +04:00
|
|
|
|
2009-01-26 23:26:49 +03:00
|
|
|
uint32_t block_size;
|
2009-01-26 23:27:02 +03:00
|
|
|
uint32_t bitmap_size;
|
block/vpc: choose size calculation method based on creator_app field
The VHD file format is used by both Virtual PC, and Hyper-V. However,
how the virtual disk size is calculated varies between the two.
Virtual PC uses the CHS drive parameters to determine the drive size.
Hyper-V, on the other hand, uses the current_size field in the footer
when determining image size.
This is problematic for a few reasons:
* VHD images from Hyper-V, using CHS calculations, will likely be
trunctated.
* If we just rely always on current_size, then QEMU may have data
compatibility issues with Virtual PC (we may write too much data
into a VHD file to be used by Virtual PC, for instance).
* Existing VHD images created by QEMU have used the CHS calculations,
except for images exceeding the 127GB limit. We want to remain
compatible with our own generated images.
Luckily, the VHD specification defines a 'Creator App' field, that is
used to indicate what software created the VHD file.
This patch does two things:
1. Uses the 'Creator App' field to help determine how to calculate
size, and
2. Adds a VPC format option 'force_size_calc', so that the user can
override the 'Creator App' auto-detection, in case there exist
VHD images with unknown or contradictory 'Creator App' entries.
N.B.: We currently use the maximum CHS value as an indication to use the
current_size field. This patch does not change that, even with the
'force_size_calc' option.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:27 +03:00
|
|
|
bool force_use_chs;
|
|
|
|
bool force_use_sz;
|
2009-01-26 23:27:02 +03:00
|
|
|
|
2005-04-28 00:17:58 +04:00
|
|
|
#ifdef CACHE
|
|
|
|
uint8_t *pageentry_u8;
|
|
|
|
uint32_t *pageentry_u32;
|
|
|
|
uint16_t *pageentry_u16;
|
2007-09-17 12:09:54 +04:00
|
|
|
|
2005-04-28 00:17:58 +04:00
|
|
|
uint64_t last_bitmap;
|
|
|
|
#endif
|
2011-11-22 19:51:12 +04:00
|
|
|
|
|
|
|
Error *migration_blocker;
|
2005-04-28 00:17:58 +04:00
|
|
|
} BDRVVPCState;
|
|
|
|
|
block/vpc: choose size calculation method based on creator_app field
The VHD file format is used by both Virtual PC, and Hyper-V. However,
how the virtual disk size is calculated varies between the two.
Virtual PC uses the CHS drive parameters to determine the drive size.
Hyper-V, on the other hand, uses the current_size field in the footer
when determining image size.
This is problematic for a few reasons:
* VHD images from Hyper-V, using CHS calculations, will likely be
trunctated.
* If we just rely always on current_size, then QEMU may have data
compatibility issues with Virtual PC (we may write too much data
into a VHD file to be used by Virtual PC, for instance).
* Existing VHD images created by QEMU have used the CHS calculations,
except for images exceeding the 127GB limit. We want to remain
compatible with our own generated images.
Luckily, the VHD specification defines a 'Creator App' field, that is
used to indicate what software created the VHD file.
This patch does two things:
1. Uses the 'Creator App' field to help determine how to calculate
size, and
2. Adds a VPC format option 'force_size_calc', so that the user can
override the 'Creator App' auto-detection, in case there exist
VHD images with unknown or contradictory 'Creator App' entries.
N.B.: We currently use the maximum CHS value as an indication to use the
current_size field. This patch does not change that, even with the
'force_size_calc' option.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:27 +03:00
|
|
|
#define VPC_OPT_SIZE_CALC "force_size_calc"
|
|
|
|
static QemuOptsList vpc_runtime_opts = {
|
|
|
|
.name = "vpc-runtime-opts",
|
|
|
|
.head = QTAILQ_HEAD_INITIALIZER(vpc_runtime_opts.head),
|
|
|
|
.desc = {
|
|
|
|
{
|
|
|
|
.name = VPC_OPT_SIZE_CALC,
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help = "Force disk size calculation to use either CHS geometry, "
|
|
|
|
"or use the disk current_size specified in the VHD footer. "
|
|
|
|
"{chs, current_size}"
|
|
|
|
},
|
|
|
|
{ /* end of list */ }
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2018-03-09 21:53:19 +03:00
|
|
|
static QemuOptsList vpc_create_opts;
|
|
|
|
|
2020-12-17 19:19:58 +03:00
|
|
|
static uint32_t vpc_checksum(void *p, size_t size)
|
2009-01-26 23:27:06 +03:00
|
|
|
{
|
2020-12-17 19:19:58 +03:00
|
|
|
uint8_t *buf = p;
|
2009-01-26 23:27:06 +03:00
|
|
|
uint32_t res = 0;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < size; i++)
|
|
|
|
res += buf[i];
|
|
|
|
|
|
|
|
return ~res;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-04-28 00:17:58 +04:00
|
|
|
static int vpc_probe(const uint8_t *buf, int buf_size, const char *filename)
|
|
|
|
{
|
2007-12-16 06:16:05 +03:00
|
|
|
if (buf_size >= 8 && !strncmp((char *)buf, "conectix", 8))
|
2018-12-14 01:37:37 +03:00
|
|
|
return 100;
|
2005-04-28 00:17:58 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
block/vpc: choose size calculation method based on creator_app field
The VHD file format is used by both Virtual PC, and Hyper-V. However,
how the virtual disk size is calculated varies between the two.
Virtual PC uses the CHS drive parameters to determine the drive size.
Hyper-V, on the other hand, uses the current_size field in the footer
when determining image size.
This is problematic for a few reasons:
* VHD images from Hyper-V, using CHS calculations, will likely be
trunctated.
* If we just rely always on current_size, then QEMU may have data
compatibility issues with Virtual PC (we may write too much data
into a VHD file to be used by Virtual PC, for instance).
* Existing VHD images created by QEMU have used the CHS calculations,
except for images exceeding the 127GB limit. We want to remain
compatible with our own generated images.
Luckily, the VHD specification defines a 'Creator App' field, that is
used to indicate what software created the VHD file.
This patch does two things:
1. Uses the 'Creator App' field to help determine how to calculate
size, and
2. Adds a VPC format option 'force_size_calc', so that the user can
override the 'Creator App' auto-detection, in case there exist
VHD images with unknown or contradictory 'Creator App' entries.
N.B.: We currently use the maximum CHS value as an indication to use the
current_size field. This patch does not change that, even with the
'force_size_calc' option.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:27 +03:00
|
|
|
static void vpc_parse_options(BlockDriverState *bs, QemuOpts *opts,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
BDRVVPCState *s = bs->opaque;
|
|
|
|
const char *size_calc;
|
|
|
|
|
|
|
|
size_calc = qemu_opt_get(opts, VPC_OPT_SIZE_CALC);
|
|
|
|
|
|
|
|
if (!size_calc) {
|
|
|
|
/* no override, use autodetect only */
|
|
|
|
} else if (!strcmp(size_calc, "current_size")) {
|
|
|
|
s->force_use_sz = true;
|
|
|
|
} else if (!strcmp(size_calc, "chs")) {
|
|
|
|
s->force_use_chs = true;
|
|
|
|
} else {
|
|
|
|
error_setg(errp, "Invalid size calculation mode: '%s'", size_calc);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-05 16:22:29 +04:00
|
|
|
static int vpc_open(BlockDriverState *bs, QDict *options, int flags,
|
|
|
|
Error **errp)
|
2005-04-28 00:17:58 +04:00
|
|
|
{
|
|
|
|
BDRVVPCState *s = bs->opaque;
|
2010-04-14 16:17:38 +04:00
|
|
|
int i;
|
2013-09-25 20:08:49 +04:00
|
|
|
VHDFooter *footer;
|
block/vpc: choose size calculation method based on creator_app field
The VHD file format is used by both Virtual PC, and Hyper-V. However,
how the virtual disk size is calculated varies between the two.
Virtual PC uses the CHS drive parameters to determine the drive size.
Hyper-V, on the other hand, uses the current_size field in the footer
when determining image size.
This is problematic for a few reasons:
* VHD images from Hyper-V, using CHS calculations, will likely be
trunctated.
* If we just rely always on current_size, then QEMU may have data
compatibility issues with Virtual PC (we may write too much data
into a VHD file to be used by Virtual PC, for instance).
* Existing VHD images created by QEMU have used the CHS calculations,
except for images exceeding the 127GB limit. We want to remain
compatible with our own generated images.
Luckily, the VHD specification defines a 'Creator App' field, that is
used to indicate what software created the VHD file.
This patch does two things:
1. Uses the 'Creator App' field to help determine how to calculate
size, and
2. Adds a VPC format option 'force_size_calc', so that the user can
override the 'Creator App' auto-detection, in case there exist
VHD images with unknown or contradictory 'Creator App' entries.
N.B.: We currently use the maximum CHS value as an indication to use the
current_size field. This patch does not change that, even with the
'force_size_calc' option.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:27 +03:00
|
|
|
QemuOpts *opts = NULL;
|
|
|
|
Error *local_err = NULL;
|
|
|
|
bool use_chs;
|
2020-12-17 19:19:59 +03:00
|
|
|
VHDDynDiskHeader dyndisk_header;
|
2009-01-26 23:27:06 +03:00
|
|
|
uint32_t checksum;
|
2014-03-26 16:05:36 +04:00
|
|
|
uint64_t computed_size;
|
2015-07-24 17:26:51 +03:00
|
|
|
uint64_t pagetable_size;
|
2012-02-06 20:22:30 +04:00
|
|
|
int disk_type = VHD_DYNAMIC;
|
2013-01-25 20:07:29 +04:00
|
|
|
int ret;
|
2017-08-09 23:38:04 +03:00
|
|
|
int64_t bs_size;
|
2005-04-28 00:17:58 +04:00
|
|
|
|
2022-07-26 23:11:21 +03:00
|
|
|
ret = bdrv_open_file_child(NULL, options, "file", bs, errp);
|
|
|
|
if (ret < 0) {
|
|
|
|
return ret;
|
2016-12-16 20:52:37 +03:00
|
|
|
}
|
|
|
|
|
2023-10-27 18:53:32 +03:00
|
|
|
GRAPH_RDLOCK_GUARD_MAINLOOP();
|
|
|
|
|
block/vpc: choose size calculation method based on creator_app field
The VHD file format is used by both Virtual PC, and Hyper-V. However,
how the virtual disk size is calculated varies between the two.
Virtual PC uses the CHS drive parameters to determine the drive size.
Hyper-V, on the other hand, uses the current_size field in the footer
when determining image size.
This is problematic for a few reasons:
* VHD images from Hyper-V, using CHS calculations, will likely be
trunctated.
* If we just rely always on current_size, then QEMU may have data
compatibility issues with Virtual PC (we may write too much data
into a VHD file to be used by Virtual PC, for instance).
* Existing VHD images created by QEMU have used the CHS calculations,
except for images exceeding the 127GB limit. We want to remain
compatible with our own generated images.
Luckily, the VHD specification defines a 'Creator App' field, that is
used to indicate what software created the VHD file.
This patch does two things:
1. Uses the 'Creator App' field to help determine how to calculate
size, and
2. Adds a VPC format option 'force_size_calc', so that the user can
override the 'Creator App' auto-detection, in case there exist
VHD images with unknown or contradictory 'Creator App' entries.
N.B.: We currently use the maximum CHS value as an indication to use the
current_size field. This patch does not change that, even with the
'force_size_calc' option.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:27 +03:00
|
|
|
opts = qemu_opts_create(&vpc_runtime_opts, NULL, 0, &error_abort);
|
2020-07-07 19:06:03 +03:00
|
|
|
if (!qemu_opts_absorb_qdict(opts, options, errp)) {
|
block/vpc: choose size calculation method based on creator_app field
The VHD file format is used by both Virtual PC, and Hyper-V. However,
how the virtual disk size is calculated varies between the two.
Virtual PC uses the CHS drive parameters to determine the drive size.
Hyper-V, on the other hand, uses the current_size field in the footer
when determining image size.
This is problematic for a few reasons:
* VHD images from Hyper-V, using CHS calculations, will likely be
trunctated.
* If we just rely always on current_size, then QEMU may have data
compatibility issues with Virtual PC (we may write too much data
into a VHD file to be used by Virtual PC, for instance).
* Existing VHD images created by QEMU have used the CHS calculations,
except for images exceeding the 127GB limit. We want to remain
compatible with our own generated images.
Luckily, the VHD specification defines a 'Creator App' field, that is
used to indicate what software created the VHD file.
This patch does two things:
1. Uses the 'Creator App' field to help determine how to calculate
size, and
2. Adds a VPC format option 'force_size_calc', so that the user can
override the 'Creator App' auto-detection, in case there exist
VHD images with unknown or contradictory 'Creator App' entries.
N.B.: We currently use the maximum CHS value as an indication to use the
current_size field. This patch does not change that, even with the
'force_size_calc' option.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:27 +03:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
vpc_parse_options(bs, opts, &local_err);
|
|
|
|
if (local_err) {
|
|
|
|
error_propagate(errp, local_err);
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
block: Change bdrv_{pread,pwrite,pwrite_sync}() param order
Swap 'buf' and 'bytes' around for consistency with
bdrv_co_{pread,pwrite}(), and in preparation to implement these
functions using generated_co_wrapper.
Callers were updated using this Coccinelle script:
@@ expression child, offset, buf, bytes, flags; @@
- bdrv_pread(child, offset, buf, bytes, flags)
+ bdrv_pread(child, offset, bytes, buf, flags)
@@ expression child, offset, buf, bytes, flags; @@
- bdrv_pwrite(child, offset, buf, bytes, flags)
+ bdrv_pwrite(child, offset, bytes, buf, flags)
@@ expression child, offset, buf, bytes, flags; @@
- bdrv_pwrite_sync(child, offset, buf, bytes, flags)
+ bdrv_pwrite_sync(child, offset, bytes, buf, flags)
Resulting overly-long lines were then fixed by hand.
Signed-off-by: Alberto Faria <afaria@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-Id: <20220609152744.3891847-3-afaria@redhat.com>
Reviewed-by: Hanna Reitz <hreitz@redhat.com>
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
2022-06-09 18:27:36 +03:00
|
|
|
ret = bdrv_pread(bs->file, 0, sizeof(s->footer), &s->footer, 0);
|
2013-01-25 20:07:29 +04:00
|
|
|
if (ret < 0) {
|
2016-03-23 06:33:43 +03:00
|
|
|
error_setg(errp, "Unable to read VHD header");
|
2005-04-28 00:17:58 +04:00
|
|
|
goto fail;
|
2013-01-25 20:07:29 +04:00
|
|
|
}
|
2005-04-28 00:17:58 +04:00
|
|
|
|
2020-12-17 19:20:01 +03:00
|
|
|
footer = &s->footer;
|
2012-02-06 20:22:30 +04:00
|
|
|
if (strncmp(footer->creator, "conectix", 8)) {
|
2015-06-16 15:19:22 +03:00
|
|
|
int64_t offset = bdrv_getlength(bs->file->bs);
|
2013-01-25 20:07:29 +04:00
|
|
|
if (offset < 0) {
|
|
|
|
ret = offset;
|
2016-03-23 06:33:43 +03:00
|
|
|
error_setg(errp, "Invalid file size");
|
2013-01-25 20:07:29 +04:00
|
|
|
goto fail;
|
2020-12-17 19:20:03 +03:00
|
|
|
} else if (offset < sizeof(*footer)) {
|
2013-01-25 20:07:29 +04:00
|
|
|
ret = -EINVAL;
|
2016-03-23 06:33:43 +03:00
|
|
|
error_setg(errp, "File too small for a VHD header");
|
2012-02-06 20:22:30 +04:00
|
|
|
goto fail;
|
|
|
|
}
|
2013-01-25 20:07:29 +04:00
|
|
|
|
2012-02-06 20:22:30 +04:00
|
|
|
/* If a fixed disk, the footer is found only at the end of the file */
|
block: Change bdrv_{pread,pwrite,pwrite_sync}() param order
Swap 'buf' and 'bytes' around for consistency with
bdrv_co_{pread,pwrite}(), and in preparation to implement these
functions using generated_co_wrapper.
Callers were updated using this Coccinelle script:
@@ expression child, offset, buf, bytes, flags; @@
- bdrv_pread(child, offset, buf, bytes, flags)
+ bdrv_pread(child, offset, bytes, buf, flags)
@@ expression child, offset, buf, bytes, flags; @@
- bdrv_pwrite(child, offset, buf, bytes, flags)
+ bdrv_pwrite(child, offset, bytes, buf, flags)
@@ expression child, offset, buf, bytes, flags; @@
- bdrv_pwrite_sync(child, offset, buf, bytes, flags)
+ bdrv_pwrite_sync(child, offset, bytes, buf, flags)
Resulting overly-long lines were then fixed by hand.
Signed-off-by: Alberto Faria <afaria@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-Id: <20220609152744.3891847-3-afaria@redhat.com>
Reviewed-by: Hanna Reitz <hreitz@redhat.com>
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
2022-06-09 18:27:36 +03:00
|
|
|
ret = bdrv_pread(bs->file, offset - sizeof(*footer), sizeof(*footer),
|
|
|
|
footer, 0);
|
2013-01-25 20:07:29 +04:00
|
|
|
if (ret < 0) {
|
2012-02-06 20:22:30 +04:00
|
|
|
goto fail;
|
|
|
|
}
|
2021-10-12 11:27:02 +03:00
|
|
|
if (strncmp(footer->creator, "conectix", 8) ||
|
|
|
|
be32_to_cpu(footer->type) != VHD_FIXED) {
|
2014-02-17 17:44:06 +04:00
|
|
|
error_setg(errp, "invalid VPC image");
|
|
|
|
ret = -EINVAL;
|
2012-02-06 20:22:30 +04:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
disk_type = VHD_FIXED;
|
|
|
|
}
|
2005-04-28 00:17:58 +04:00
|
|
|
|
2009-01-26 23:27:06 +03:00
|
|
|
checksum = be32_to_cpu(footer->checksum);
|
|
|
|
footer->checksum = 0;
|
2020-12-17 19:20:03 +03:00
|
|
|
if (vpc_checksum(footer, sizeof(*footer)) != checksum) {
|
2018-10-17 11:27:02 +03:00
|
|
|
error_setg(errp, "Incorrect header checksum");
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2012-03-13 18:38:13 +04:00
|
|
|
/* Write 'checksum' back to footer, or else will leave it with zero. */
|
2014-09-23 13:40:55 +04:00
|
|
|
footer->checksum = cpu_to_be32(checksum);
|
2012-03-13 18:38:13 +04:00
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* The visible size of a image in Virtual PC depends on the geometry
|
|
|
|
rather than on the size stored in the footer (the size in the footer
|
|
|
|
is too large usually) */
|
2013-02-12 15:25:15 +04:00
|
|
|
bs->total_sectors = (int64_t)
|
|
|
|
be16_to_cpu(footer->cyls) * footer->heads * footer->secs_per_cyl;
|
2009-01-26 23:26:54 +03:00
|
|
|
|
block/vpc: choose size calculation method based on creator_app field
The VHD file format is used by both Virtual PC, and Hyper-V. However,
how the virtual disk size is calculated varies between the two.
Virtual PC uses the CHS drive parameters to determine the drive size.
Hyper-V, on the other hand, uses the current_size field in the footer
when determining image size.
This is problematic for a few reasons:
* VHD images from Hyper-V, using CHS calculations, will likely be
trunctated.
* If we just rely always on current_size, then QEMU may have data
compatibility issues with Virtual PC (we may write too much data
into a VHD file to be used by Virtual PC, for instance).
* Existing VHD images created by QEMU have used the CHS calculations,
except for images exceeding the 127GB limit. We want to remain
compatible with our own generated images.
Luckily, the VHD specification defines a 'Creator App' field, that is
used to indicate what software created the VHD file.
This patch does two things:
1. Uses the 'Creator App' field to help determine how to calculate
size, and
2. Adds a VPC format option 'force_size_calc', so that the user can
override the 'Creator App' auto-detection, in case there exist
VHD images with unknown or contradictory 'Creator App' entries.
N.B.: We currently use the maximum CHS value as an indication to use the
current_size field. This patch does not change that, even with the
'force_size_calc' option.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:27 +03:00
|
|
|
/* 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)
|
block/vpc: give option to force the current_size field in .bdrv_create
When QEMU creates a VHD image, it goes by the original spec,
calculating the current_size based on the nearest CHS geometry (with an
exception for disks > 127GB).
Apparently, Azure will only allow images that are sized to the nearest
MB, and the current_size as calculated from CHS cannot guarantee that.
Allow QEMU to create images similar to how Hyper-V creates images, by
setting current_size to the specified virtual disk size. This
introduces an option, force_size, to be passed to the vpc format during
image creation, e.g.:
qemu-img convert -f raw -o force_size -O vpc test.img test.vhd
When using the "force_size" option, the creator app field used by
QEMU will be "qem2" instead of "qemu", to indicate the difference.
In light of this, we also add parsing of the "qem2" field during
vpc_open.
Bug reference: https://bugs.launchpad.net/qemu/+bug/1490611
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:29 +03:00
|
|
|
* 'qem2' : current_size QEMU (uses current_size)
|
block/vpc: choose size calculation method based on creator_app field
The VHD file format is used by both Virtual PC, and Hyper-V. However,
how the virtual disk size is calculated varies between the two.
Virtual PC uses the CHS drive parameters to determine the drive size.
Hyper-V, on the other hand, uses the current_size field in the footer
when determining image size.
This is problematic for a few reasons:
* VHD images from Hyper-V, using CHS calculations, will likely be
trunctated.
* If we just rely always on current_size, then QEMU may have data
compatibility issues with Virtual PC (we may write too much data
into a VHD file to be used by Virtual PC, for instance).
* Existing VHD images created by QEMU have used the CHS calculations,
except for images exceeding the 127GB limit. We want to remain
compatible with our own generated images.
Luckily, the VHD specification defines a 'Creator App' field, that is
used to indicate what software created the VHD file.
This patch does two things:
1. Uses the 'Creator App' field to help determine how to calculate
size, and
2. Adds a VPC format option 'force_size_calc', so that the user can
override the 'Creator App' auto-detection, in case there exist
VHD images with unknown or contradictory 'Creator App' entries.
N.B.: We currently use the maximum CHS value as an indication to use the
current_size field. This patch does not change that, even with the
'force_size_calc' option.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:27 +03:00
|
|
|
* 'win ' : current_size Hyper-V
|
|
|
|
* 'd2v ' : current_size Disk2vhd
|
2016-03-23 06:33:39 +03:00
|
|
|
* 'tap\0' : current_size XenServer
|
2016-03-23 06:33:40 +03:00
|
|
|
* 'CTXS' : current_size XenConverter
|
block/vpc: choose size calculation method based on creator_app field
The VHD file format is used by both Virtual PC, and Hyper-V. However,
how the virtual disk size is calculated varies between the two.
Virtual PC uses the CHS drive parameters to determine the drive size.
Hyper-V, on the other hand, uses the current_size field in the footer
when determining image size.
This is problematic for a few reasons:
* VHD images from Hyper-V, using CHS calculations, will likely be
trunctated.
* If we just rely always on current_size, then QEMU may have data
compatibility issues with Virtual PC (we may write too much data
into a VHD file to be used by Virtual PC, for instance).
* Existing VHD images created by QEMU have used the CHS calculations,
except for images exceeding the 127GB limit. We want to remain
compatible with our own generated images.
Luckily, the VHD specification defines a 'Creator App' field, that is
used to indicate what software created the VHD file.
This patch does two things:
1. Uses the 'Creator App' field to help determine how to calculate
size, and
2. Adds a VPC format option 'force_size_calc', so that the user can
override the 'Creator App' auto-detection, in case there exist
VHD images with unknown or contradictory 'Creator App' entries.
N.B.: We currently use the maximum CHS value as an indication to use the
current_size field. This patch does not change that, even with the
'force_size_calc' option.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:27 +03:00
|
|
|
*
|
|
|
|
* 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) &&
|
block/vpc: give option to force the current_size field in .bdrv_create
When QEMU creates a VHD image, it goes by the original spec,
calculating the current_size based on the nearest CHS geometry (with an
exception for disks > 127GB).
Apparently, Azure will only allow images that are sized to the nearest
MB, and the current_size as calculated from CHS cannot guarantee that.
Allow QEMU to create images similar to how Hyper-V creates images, by
setting current_size to the specified virtual disk size. This
introduces an option, force_size, to be passed to the vpc format during
image creation, e.g.:
qemu-img convert -f raw -o force_size -O vpc test.img test.vhd
When using the "force_size" option, the creator app field used by
QEMU will be "qem2" instead of "qemu", to indicate the difference.
In light of this, we also add parsing of the "qem2" field during
vpc_open.
Bug reference: https://bugs.launchpad.net/qemu/+bug/1490611
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:29 +03:00
|
|
|
!!strncmp(footer->creator_app, "qem2", 4) &&
|
2016-03-23 06:33:39 +03:00
|
|
|
!!strncmp(footer->creator_app, "d2v ", 4) &&
|
2016-03-23 06:33:40 +03:00
|
|
|
!!strncmp(footer->creator_app, "CTXS", 4) &&
|
2016-03-23 06:33:39 +03:00
|
|
|
!!memcmp(footer->creator_app, "tap", 4)) || s->force_use_chs;
|
block/vpc: choose size calculation method based on creator_app field
The VHD file format is used by both Virtual PC, and Hyper-V. However,
how the virtual disk size is calculated varies between the two.
Virtual PC uses the CHS drive parameters to determine the drive size.
Hyper-V, on the other hand, uses the current_size field in the footer
when determining image size.
This is problematic for a few reasons:
* VHD images from Hyper-V, using CHS calculations, will likely be
trunctated.
* If we just rely always on current_size, then QEMU may have data
compatibility issues with Virtual PC (we may write too much data
into a VHD file to be used by Virtual PC, for instance).
* Existing VHD images created by QEMU have used the CHS calculations,
except for images exceeding the 127GB limit. We want to remain
compatible with our own generated images.
Luckily, the VHD specification defines a 'Creator App' field, that is
used to indicate what software created the VHD file.
This patch does two things:
1. Uses the 'Creator App' field to help determine how to calculate
size, and
2. Adds a VPC format option 'force_size_calc', so that the user can
override the 'Creator App' auto-detection, in case there exist
VHD images with unknown or contradictory 'Creator App' entries.
N.B.: We currently use the maximum CHS value as an indication to use the
current_size field. This patch does not change that, even with the
'force_size_calc' option.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:27 +03:00
|
|
|
|
|
|
|
if (!use_chs || bs->total_sectors == VHD_MAX_GEOMETRY || s->force_use_sz) {
|
2015-03-03 13:41:55 +03:00
|
|
|
bs->total_sectors = be64_to_cpu(footer->current_size) /
|
block/vpc: choose size calculation method based on creator_app field
The VHD file format is used by both Virtual PC, and Hyper-V. However,
how the virtual disk size is calculated varies between the two.
Virtual PC uses the CHS drive parameters to determine the drive size.
Hyper-V, on the other hand, uses the current_size field in the footer
when determining image size.
This is problematic for a few reasons:
* VHD images from Hyper-V, using CHS calculations, will likely be
trunctated.
* If we just rely always on current_size, then QEMU may have data
compatibility issues with Virtual PC (we may write too much data
into a VHD file to be used by Virtual PC, for instance).
* Existing VHD images created by QEMU have used the CHS calculations,
except for images exceeding the 127GB limit. We want to remain
compatible with our own generated images.
Luckily, the VHD specification defines a 'Creator App' field, that is
used to indicate what software created the VHD file.
This patch does two things:
1. Uses the 'Creator App' field to help determine how to calculate
size, and
2. Adds a VPC format option 'force_size_calc', so that the user can
override the 'Creator App' auto-detection, in case there exist
VHD images with unknown or contradictory 'Creator App' entries.
N.B.: We currently use the maximum CHS value as an indication to use the
current_size field. This patch does not change that, even with the
'force_size_calc' option.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:27 +03:00
|
|
|
BDRV_SECTOR_SIZE;
|
2013-10-21 18:00:18 +04:00
|
|
|
}
|
|
|
|
|
2016-03-23 06:33:41 +03:00
|
|
|
/* Allow a maximum disk size of 2040 GiB */
|
|
|
|
if (bs->total_sectors > VHD_MAX_SECTORS) {
|
2013-01-25 20:07:29 +04:00
|
|
|
ret = -EFBIG;
|
2011-07-25 22:34:35 +04:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2012-02-06 20:22:30 +04:00
|
|
|
if (disk_type == VHD_DYNAMIC) {
|
2020-12-17 19:19:55 +03:00
|
|
|
ret = bdrv_pread(bs->file, be64_to_cpu(footer->data_offset),
|
block: Change bdrv_{pread,pwrite,pwrite_sync}() param order
Swap 'buf' and 'bytes' around for consistency with
bdrv_co_{pread,pwrite}(), and in preparation to implement these
functions using generated_co_wrapper.
Callers were updated using this Coccinelle script:
@@ expression child, offset, buf, bytes, flags; @@
- bdrv_pread(child, offset, buf, bytes, flags)
+ bdrv_pread(child, offset, bytes, buf, flags)
@@ expression child, offset, buf, bytes, flags; @@
- bdrv_pwrite(child, offset, buf, bytes, flags)
+ bdrv_pwrite(child, offset, bytes, buf, flags)
@@ expression child, offset, buf, bytes, flags; @@
- bdrv_pwrite_sync(child, offset, buf, bytes, flags)
+ bdrv_pwrite_sync(child, offset, bytes, buf, flags)
Resulting overly-long lines were then fixed by hand.
Signed-off-by: Alberto Faria <afaria@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-Id: <20220609152744.3891847-3-afaria@redhat.com>
Reviewed-by: Hanna Reitz <hreitz@redhat.com>
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
2022-06-09 18:27:36 +03:00
|
|
|
sizeof(dyndisk_header), &dyndisk_header, 0);
|
2013-01-25 20:07:29 +04:00
|
|
|
if (ret < 0) {
|
2016-03-23 06:33:43 +03:00
|
|
|
error_setg(errp, "Error reading dynamic VHD header");
|
2012-02-06 20:22:30 +04:00
|
|
|
goto fail;
|
|
|
|
}
|
2009-01-26 23:26:46 +03:00
|
|
|
|
2020-12-17 19:19:59 +03:00
|
|
|
if (strncmp(dyndisk_header.magic, "cxsparse", 8)) {
|
2016-03-23 06:33:43 +03:00
|
|
|
error_setg(errp, "Invalid header magic");
|
2013-01-25 20:07:29 +04:00
|
|
|
ret = -EINVAL;
|
2012-02-06 20:22:30 +04:00
|
|
|
goto fail;
|
|
|
|
}
|
2005-04-28 00:17:58 +04:00
|
|
|
|
2020-12-17 19:19:59 +03:00
|
|
|
s->block_size = be32_to_cpu(dyndisk_header.block_size);
|
2014-03-26 16:05:37 +04:00
|
|
|
if (!is_power_of_2(s->block_size) || s->block_size < BDRV_SECTOR_SIZE) {
|
|
|
|
error_setg(errp, "Invalid block size %" PRIu32, s->block_size);
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
2012-02-06 20:22:30 +04:00
|
|
|
s->bitmap_size = ((s->block_size / (8 * 512)) + 511) & ~511;
|
2009-01-26 23:27:02 +03:00
|
|
|
|
2020-12-17 19:19:59 +03:00
|
|
|
s->max_table_entries = be32_to_cpu(dyndisk_header.max_table_entries);
|
2014-03-26 16:05:36 +04:00
|
|
|
|
|
|
|
if ((bs->total_sectors * 512) / s->block_size > 0xffffffffU) {
|
2016-03-23 06:33:43 +03:00
|
|
|
error_setg(errp, "Too many blocks");
|
2014-03-26 16:05:36 +04:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
computed_size = (uint64_t) s->max_table_entries * s->block_size;
|
|
|
|
if (computed_size < bs->total_sectors * 512) {
|
2016-03-23 06:33:43 +03:00
|
|
|
error_setg(errp, "Page table too small");
|
2014-03-26 16:05:36 +04:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2015-07-24 17:26:51 +03:00
|
|
|
if (s->max_table_entries > SIZE_MAX / 4 ||
|
|
|
|
s->max_table_entries > (int) INT_MAX / 4) {
|
|
|
|
error_setg(errp, "Max Table Entries too large (%" PRId32 ")",
|
|
|
|
s->max_table_entries);
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
pagetable_size = (uint64_t) s->max_table_entries * 4;
|
|
|
|
|
2015-06-16 15:19:22 +03:00
|
|
|
s->pagetable = qemu_try_blockalign(bs->file->bs, pagetable_size);
|
2014-05-21 20:08:38 +04:00
|
|
|
if (s->pagetable == NULL) {
|
2016-03-23 06:33:43 +03:00
|
|
|
error_setg(errp, "Unable to allocate memory for page table");
|
2014-05-21 20:08:38 +04:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto fail;
|
|
|
|
}
|
2009-01-26 23:26:58 +03:00
|
|
|
|
2020-12-17 19:19:59 +03:00
|
|
|
s->bat_offset = be64_to_cpu(dyndisk_header.table_offset);
|
2013-01-25 20:07:29 +04:00
|
|
|
|
block: Change bdrv_{pread,pwrite,pwrite_sync}() param order
Swap 'buf' and 'bytes' around for consistency with
bdrv_co_{pread,pwrite}(), and in preparation to implement these
functions using generated_co_wrapper.
Callers were updated using this Coccinelle script:
@@ expression child, offset, buf, bytes, flags; @@
- bdrv_pread(child, offset, buf, bytes, flags)
+ bdrv_pread(child, offset, bytes, buf, flags)
@@ expression child, offset, buf, bytes, flags; @@
- bdrv_pwrite(child, offset, buf, bytes, flags)
+ bdrv_pwrite(child, offset, bytes, buf, flags)
@@ expression child, offset, buf, bytes, flags; @@
- bdrv_pwrite_sync(child, offset, buf, bytes, flags)
+ bdrv_pwrite_sync(child, offset, bytes, buf, flags)
Resulting overly-long lines were then fixed by hand.
Signed-off-by: Alberto Faria <afaria@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-Id: <20220609152744.3891847-3-afaria@redhat.com>
Reviewed-by: Hanna Reitz <hreitz@redhat.com>
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
2022-06-09 18:27:36 +03:00
|
|
|
ret = bdrv_pread(bs->file, s->bat_offset, pagetable_size,
|
|
|
|
s->pagetable, 0);
|
2013-01-25 20:07:29 +04:00
|
|
|
if (ret < 0) {
|
2016-03-23 06:33:43 +03:00
|
|
|
error_setg(errp, "Error reading pagetable");
|
2012-02-06 20:22:30 +04:00
|
|
|
goto fail;
|
|
|
|
}
|
2009-01-26 23:26:58 +03:00
|
|
|
|
2012-02-06 20:22:30 +04:00
|
|
|
s->free_data_block_offset =
|
2015-07-24 17:26:51 +03:00
|
|
|
ROUND_UP(s->bat_offset + pagetable_size, 512);
|
2009-01-26 23:27:02 +03:00
|
|
|
|
2012-02-06 20:22:30 +04:00
|
|
|
for (i = 0; i < s->max_table_entries; i++) {
|
|
|
|
be32_to_cpus(&s->pagetable[i]);
|
|
|
|
if (s->pagetable[i] != 0xFFFFFFFF) {
|
|
|
|
int64_t next = (512 * (int64_t) s->pagetable[i]) +
|
|
|
|
s->bitmap_size + s->block_size;
|
2009-01-26 23:27:02 +03:00
|
|
|
|
2012-02-06 20:22:30 +04:00
|
|
|
if (next > s->free_data_block_offset) {
|
|
|
|
s->free_data_block_offset = next;
|
|
|
|
}
|
|
|
|
}
|
2009-01-26 23:27:02 +03:00
|
|
|
}
|
|
|
|
|
2017-08-09 23:38:04 +03:00
|
|
|
bs_size = bdrv_getlength(bs->file->bs);
|
|
|
|
if (bs_size < 0) {
|
|
|
|
error_setg_errno(errp, -bs_size, "Unable to learn image size");
|
|
|
|
ret = bs_size;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
if (s->free_data_block_offset > bs_size) {
|
2013-10-24 11:16:03 +04:00
|
|
|
error_setg(errp, "block-vpc: free_data_block_offset points after "
|
|
|
|
"the end of file. The image has been truncated.");
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2012-02-06 20:22:30 +04:00
|
|
|
s->last_bitmap_offset = (int64_t) -1;
|
2005-04-28 00:17:58 +04:00
|
|
|
|
|
|
|
#ifdef CACHE
|
2012-02-06 20:22:30 +04:00
|
|
|
s->pageentry_u8 = g_malloc(512);
|
|
|
|
s->pageentry_u32 = s->pageentry_u8;
|
|
|
|
s->pageentry_u16 = s->pageentry_u8;
|
|
|
|
s->last_pagetable = -1;
|
2005-04-28 00:17:58 +04:00
|
|
|
#endif
|
2012-02-06 20:22:30 +04:00
|
|
|
}
|
2005-04-28 00:17:58 +04:00
|
|
|
|
2011-11-22 19:51:12 +04:00
|
|
|
/* Disable migration when VHD images are used */
|
2015-04-08 12:29:19 +03:00
|
|
|
error_setg(&s->migration_blocker, "The vpc format used by node '%s' "
|
|
|
|
"does not support live migration",
|
|
|
|
bdrv_get_device_or_node_name(bs));
|
2023-09-29 17:51:47 +03:00
|
|
|
|
2023-10-25 22:44:26 +03:00
|
|
|
ret = migrate_add_blocker_normal(&s->migration_blocker, errp);
|
error: Avoid error_propagate() after migrate_add_blocker()
When migrate_add_blocker(blocker, &errp) is followed by
error_propagate(errp, err), we can often just as well do
migrate_add_blocker(..., errp).
Do that with this Coccinelle script:
@@
expression blocker, err, errp;
expression ret;
@@
- ret = migrate_add_blocker(blocker, &err);
- if (err) {
+ ret = migrate_add_blocker(blocker, errp);
+ if (ret < 0) {
... when != err;
- error_propagate(errp, err);
...
}
@@
expression blocker, err, errp;
@@
- migrate_add_blocker(blocker, &err);
- if (err) {
+ if (migrate_add_blocker(blocker, errp) < 0) {
... when != err;
- error_propagate(errp, err);
...
}
Double-check @err is not used afterwards. Dereferencing it would be
use after free, but checking whether it's null would be legitimate.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200707160613.848843-43-armbru@redhat.com>
2020-07-07 19:06:10 +03:00
|
|
|
if (ret < 0) {
|
2017-01-16 14:31:53 +03:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
qemu_co_mutex_init(&s->lock);
|
2018-10-17 16:33:14 +03:00
|
|
|
qemu_opts_del(opts);
|
2011-11-22 19:51:12 +04:00
|
|
|
|
2005-04-28 00:17:58 +04:00
|
|
|
return 0;
|
2013-01-25 20:07:29 +04:00
|
|
|
|
|
|
|
fail:
|
2018-10-17 16:33:14 +03:00
|
|
|
qemu_opts_del(opts);
|
2014-03-26 16:05:36 +04:00
|
|
|
qemu_vfree(s->pagetable);
|
2013-01-25 20:07:29 +04:00
|
|
|
#ifdef CACHE
|
|
|
|
g_free(s->pageentry_u8);
|
|
|
|
#endif
|
|
|
|
return ret;
|
2005-04-28 00:17:58 +04:00
|
|
|
}
|
|
|
|
|
2012-09-20 23:13:33 +04:00
|
|
|
static int vpc_reopen_prepare(BDRVReopenState *state,
|
|
|
|
BlockReopenQueue *queue, Error **errp)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-01-26 23:26:58 +03:00
|
|
|
/*
|
|
|
|
* Returns the absolute byte offset of the given sector in the image file.
|
|
|
|
* If the sector is not allocated, -1 is returned instead.
|
2017-07-10 00:07:17 +03:00
|
|
|
* If an error occurred trying to write an updated block bitmap back to
|
|
|
|
* the file, -2 is returned, and the error value is written to *err.
|
|
|
|
* This can only happen for a write operation.
|
2009-01-26 23:27:02 +03:00
|
|
|
*
|
|
|
|
* The parameter write must be 1 if the offset will be used for a write
|
|
|
|
* operation (the block bitmaps is updated then), 0 otherwise.
|
2017-07-10 00:07:17 +03:00
|
|
|
* If write is true then err must not be NULL.
|
2009-01-26 23:26:58 +03:00
|
|
|
*/
|
2023-06-01 14:51:36 +03:00
|
|
|
static int64_t coroutine_fn GRAPH_RDLOCK
|
|
|
|
get_image_offset(BlockDriverState *bs, uint64_t offset, bool write, int *err)
|
2005-04-28 00:17:58 +04:00
|
|
|
{
|
|
|
|
BDRVVPCState *s = bs->opaque;
|
|
|
|
uint64_t bitmap_offset, block_offset;
|
2016-04-26 17:24:46 +03:00
|
|
|
uint32_t pagetable_index, offset_in_block;
|
2005-04-28 00:17:58 +04:00
|
|
|
|
2017-07-10 00:07:17 +03:00
|
|
|
assert(!(write && err == NULL));
|
|
|
|
|
2009-01-26 23:26:49 +03:00
|
|
|
pagetable_index = offset / s->block_size;
|
2016-04-26 17:24:46 +03:00
|
|
|
offset_in_block = offset % s->block_size;
|
2007-09-17 12:09:54 +04:00
|
|
|
|
2009-01-26 23:27:02 +03:00
|
|
|
if (pagetable_index >= s->max_table_entries || s->pagetable[pagetable_index] == 0xffffffff)
|
2016-03-23 06:33:44 +03:00
|
|
|
return -1; /* not allocated */
|
2005-04-28 00:17:58 +04:00
|
|
|
|
2009-01-27 17:29:15 +03:00
|
|
|
bitmap_offset = 512 * (uint64_t) s->pagetable[pagetable_index];
|
2016-04-26 17:24:46 +03:00
|
|
|
block_offset = bitmap_offset + s->bitmap_size + offset_in_block;
|
2009-01-26 23:27:02 +03:00
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* We must ensure that we don't write to any sectors which are marked as
|
|
|
|
unused in the bitmap. We get away with setting all bits in the block
|
|
|
|
bitmap each time we write to a new block. This might cause Virtual PC to
|
|
|
|
miss sparse read optimization, but it's not a problem in terms of
|
|
|
|
correctness. */
|
2009-01-26 23:27:02 +03:00
|
|
|
if (write && (s->last_bitmap_offset != bitmap_offset)) {
|
2023-08-11 20:52:29 +03:00
|
|
|
g_autofree uint8_t *bitmap = g_malloc(s->bitmap_size);
|
2017-07-10 00:07:17 +03:00
|
|
|
int r;
|
2009-01-26 23:27:02 +03:00
|
|
|
|
|
|
|
s->last_bitmap_offset = bitmap_offset;
|
|
|
|
memset(bitmap, 0xff, s->bitmap_size);
|
2023-06-01 14:51:36 +03:00
|
|
|
r = bdrv_co_pwrite_sync(bs->file, bitmap_offset, s->bitmap_size, bitmap, 0);
|
2017-07-10 00:07:17 +03:00
|
|
|
if (r < 0) {
|
|
|
|
*err = r;
|
|
|
|
return -2;
|
|
|
|
}
|
2009-01-26 23:27:02 +03:00
|
|
|
}
|
2007-09-17 12:09:54 +04:00
|
|
|
|
2009-01-26 23:26:58 +03:00
|
|
|
return block_offset;
|
2005-04-28 00:17:58 +04:00
|
|
|
}
|
|
|
|
|
2009-01-26 23:27:02 +03:00
|
|
|
/*
|
|
|
|
* Writes the footer to the end of the image file. This is needed when the
|
|
|
|
* file grows as it overwrites the old footer
|
|
|
|
*
|
|
|
|
* Returns 0 on success and < 0 on error
|
|
|
|
*/
|
2023-06-01 14:51:36 +03:00
|
|
|
static int coroutine_fn GRAPH_RDLOCK rewrite_footer(BlockDriverState *bs)
|
2009-01-26 23:27:02 +03:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
BDRVVPCState *s = bs->opaque;
|
|
|
|
int64_t offset = s->free_data_block_offset;
|
|
|
|
|
2023-06-01 14:51:36 +03:00
|
|
|
ret = bdrv_co_pwrite_sync(bs->file, offset, sizeof(s->footer), &s->footer, 0);
|
2009-01-26 23:27:02 +03:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocates a new block. This involves writing a new footer and updating
|
|
|
|
* the Block Allocation Table to use the space at the old end of the image
|
|
|
|
* file (overwriting the old footer)
|
|
|
|
*
|
|
|
|
* Returns the sectors' offset in the image file on success and < 0 on error
|
|
|
|
*/
|
2023-06-01 14:51:36 +03:00
|
|
|
static int64_t coroutine_fn GRAPH_RDLOCK
|
|
|
|
alloc_block(BlockDriverState *bs, int64_t offset)
|
2009-01-26 23:27:02 +03:00
|
|
|
{
|
|
|
|
BDRVVPCState *s = bs->opaque;
|
|
|
|
int64_t bat_offset;
|
|
|
|
uint32_t index, bat_value;
|
|
|
|
int ret;
|
2023-08-11 20:52:29 +03:00
|
|
|
g_autofree uint8_t *bitmap = g_malloc(s->bitmap_size);
|
2009-01-26 23:27:02 +03:00
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Check if sector_num is valid */
|
2016-04-26 17:24:46 +03:00
|
|
|
if ((offset < 0) || (offset > bs->total_sectors * BDRV_SECTOR_SIZE)) {
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2009-01-26 23:27:02 +03:00
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Write entry into in-memory BAT */
|
2016-04-26 17:24:46 +03:00
|
|
|
index = offset / s->block_size;
|
|
|
|
assert(s->pagetable[index] == 0xFFFFFFFF);
|
2009-01-26 23:27:02 +03:00
|
|
|
s->pagetable[index] = s->free_data_block_offset / 512;
|
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Initialize the block's bitmap */
|
2009-01-26 23:27:02 +03:00
|
|
|
memset(bitmap, 0xff, s->bitmap_size);
|
2023-06-01 14:51:36 +03:00
|
|
|
ret = bdrv_co_pwrite_sync(bs->file, s->free_data_block_offset,
|
|
|
|
s->bitmap_size, bitmap, 0);
|
2011-11-23 14:38:01 +04:00
|
|
|
if (ret < 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
2009-01-26 23:27:02 +03:00
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Write new footer (the old one will be overwritten) */
|
2009-01-26 23:27:02 +03:00
|
|
|
s->free_data_block_offset += s->block_size + s->bitmap_size;
|
|
|
|
ret = rewrite_footer(bs);
|
|
|
|
if (ret < 0)
|
|
|
|
goto fail;
|
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Write BAT entry to disk */
|
2009-01-26 23:27:02 +03:00
|
|
|
bat_offset = s->bat_offset + (4 * index);
|
2014-09-23 13:40:55 +04:00
|
|
|
bat_value = cpu_to_be32(s->pagetable[index]);
|
2023-06-01 14:51:36 +03:00
|
|
|
ret = bdrv_co_pwrite_sync(bs->file, bat_offset, 4, &bat_value, 0);
|
2009-01-26 23:27:02 +03:00
|
|
|
if (ret < 0)
|
|
|
|
goto fail;
|
|
|
|
|
2017-07-10 00:07:17 +03:00
|
|
|
return get_image_offset(bs, offset, false, NULL);
|
2009-01-26 23:27:02 +03:00
|
|
|
|
|
|
|
fail:
|
|
|
|
s->free_data_block_offset -= (s->block_size + s->bitmap_size);
|
2016-04-26 17:24:46 +03:00
|
|
|
return ret;
|
2009-01-26 23:27:02 +03:00
|
|
|
}
|
|
|
|
|
2023-01-13 23:42:08 +03:00
|
|
|
static int coroutine_fn
|
|
|
|
vpc_co_get_info(BlockDriverState *bs, BlockDriverInfo *bdi)
|
2013-11-22 16:39:49 +04:00
|
|
|
{
|
|
|
|
BDRVVPCState *s = (BDRVVPCState *)bs->opaque;
|
|
|
|
|
2020-12-17 19:20:01 +03:00
|
|
|
if (be32_to_cpu(s->footer.type) != VHD_FIXED) {
|
2013-11-22 16:39:49 +04:00
|
|
|
bdi->cluster_size = s->block_size;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-02-03 18:21:50 +03:00
|
|
|
static int coroutine_fn GRAPH_RDLOCK
|
block: use int64_t instead of uint64_t in driver read handlers
We are generally moving to int64_t for both offset and bytes parameters
on all io paths.
Main motivation is realization of 64-bit write_zeroes operation for
fast zeroing large disk chunks, up to the whole disk.
We chose signed type, to be consistent with off_t (which is signed) and
with possibility for signed return type (where negative value means
error).
So, convert driver read handlers parameters which are already 64bit to
signed type.
While being here, convert also flags parameter to be BdrvRequestFlags.
Now let's consider all callers. Simple
git grep '\->bdrv_\(aio\|co\)_preadv\(_part\)\?'
shows that's there three callers of driver function:
bdrv_driver_preadv() in block/io.c, passes int64_t, checked by
bdrv_check_qiov_request() to be non-negative.
qcow2_load_vmstate() does bdrv_check_qiov_request().
do_perform_cow_read() has uint64_t argument. And a lot of things in
qcow2 driver are uint64_t, so converting it is big job. But we must
not work with requests that don't satisfy bdrv_check_qiov_request(),
so let's just assert it here.
Still, the functions may be called directly, not only by drv->...
Let's check:
git grep '\.bdrv_\(aio\|co\)_preadv\(_part\)\?\s*=' | \
awk '{print $4}' | sed 's/,//' | sed 's/&//' | sort | uniq | \
while read func; do git grep "$func(" | \
grep -v "$func(BlockDriverState"; done
The only one such caller:
QEMUIOVector qiov = QEMU_IOVEC_INIT_BUF(qiov, &data, 1);
...
ret = bdrv_replace_test_co_preadv(bs, 0, 1, &qiov, 0);
in tests/unit/test-bdrv-drain.c, and it's OK obviously.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20210903102807.27127-4-vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: fix typos]
Signed-off-by: Eric Blake <eblake@redhat.com>
2021-09-03 13:27:59 +03:00
|
|
|
vpc_co_preadv(BlockDriverState *bs, int64_t offset, int64_t bytes,
|
|
|
|
QEMUIOVector *qiov, BdrvRequestFlags flags)
|
2005-04-28 00:17:58 +04:00
|
|
|
{
|
2010-06-04 11:49:04 +04:00
|
|
|
BDRVVPCState *s = bs->opaque;
|
2005-04-28 00:17:58 +04:00
|
|
|
int ret;
|
2016-04-26 17:24:46 +03:00
|
|
|
int64_t image_offset;
|
|
|
|
int64_t n_bytes;
|
|
|
|
int64_t bytes_done = 0;
|
|
|
|
QEMUIOVector local_qiov;
|
2005-04-28 00:17:58 +04:00
|
|
|
|
2020-12-17 19:20:01 +03:00
|
|
|
if (be32_to_cpu(s->footer.type) == VHD_FIXED) {
|
2016-06-20 22:31:46 +03:00
|
|
|
return bdrv_co_preadv(bs->file, offset, bytes, qiov, 0);
|
2012-02-06 20:22:30 +04:00
|
|
|
}
|
2009-01-26 23:26:58 +03:00
|
|
|
|
2016-04-26 17:24:46 +03:00
|
|
|
qemu_co_mutex_lock(&s->lock);
|
|
|
|
qemu_iovec_init(&local_qiov, qiov->niov);
|
2010-06-04 11:49:04 +04:00
|
|
|
|
2016-04-26 17:24:46 +03:00
|
|
|
while (bytes > 0) {
|
2017-07-10 00:07:17 +03:00
|
|
|
image_offset = get_image_offset(bs, offset, false, NULL);
|
2016-04-26 17:24:46 +03:00
|
|
|
n_bytes = MIN(bytes, s->block_size - (offset % s->block_size));
|
|
|
|
|
|
|
|
if (image_offset == -1) {
|
|
|
|
qemu_iovec_memset(qiov, bytes_done, 0, n_bytes);
|
2009-01-26 23:26:58 +03:00
|
|
|
} else {
|
2016-04-26 17:24:46 +03:00
|
|
|
qemu_iovec_reset(&local_qiov);
|
|
|
|
qemu_iovec_concat(&local_qiov, qiov, bytes_done, n_bytes);
|
|
|
|
|
2019-03-15 17:04:38 +03:00
|
|
|
qemu_co_mutex_unlock(&s->lock);
|
2016-06-20 22:31:46 +03:00
|
|
|
ret = bdrv_co_preadv(bs->file, image_offset, n_bytes,
|
2016-04-26 17:24:46 +03:00
|
|
|
&local_qiov, 0);
|
2019-03-15 17:04:38 +03:00
|
|
|
qemu_co_mutex_lock(&s->lock);
|
2016-04-26 17:24:46 +03:00
|
|
|
if (ret < 0) {
|
|
|
|
goto fail;
|
2010-06-04 11:49:04 +04:00
|
|
|
}
|
2009-01-26 23:26:58 +03:00
|
|
|
}
|
|
|
|
|
2016-04-26 17:24:46 +03:00
|
|
|
bytes -= n_bytes;
|
|
|
|
offset += n_bytes;
|
|
|
|
bytes_done += n_bytes;
|
2005-04-28 00:17:58 +04:00
|
|
|
}
|
|
|
|
|
2016-04-26 17:24:46 +03:00
|
|
|
ret = 0;
|
|
|
|
fail:
|
|
|
|
qemu_iovec_destroy(&local_qiov);
|
2011-10-20 15:16:22 +04:00
|
|
|
qemu_co_mutex_unlock(&s->lock);
|
2016-04-26 17:24:46 +03:00
|
|
|
|
2011-10-20 15:16:22 +04:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2023-02-03 18:21:50 +03:00
|
|
|
static int coroutine_fn GRAPH_RDLOCK
|
block: use int64_t instead of uint64_t in driver write handlers
We are generally moving to int64_t for both offset and bytes parameters
on all io paths.
Main motivation is realization of 64-bit write_zeroes operation for
fast zeroing large disk chunks, up to the whole disk.
We chose signed type, to be consistent with off_t (which is signed) and
with possibility for signed return type (where negative value means
error).
So, convert driver write handlers parameters which are already 64bit to
signed type.
While being here, convert also flags parameter to be BdrvRequestFlags.
Now let's consider all callers. Simple
git grep '\->bdrv_\(aio\|co\)_pwritev\(_part\)\?'
shows that's there three callers of driver function:
bdrv_driver_pwritev() and bdrv_driver_pwritev_compressed() in
block/io.c, both pass int64_t, checked by bdrv_check_qiov_request() to
be non-negative.
qcow2_save_vmstate() does bdrv_check_qiov_request().
Still, the functions may be called directly, not only by drv->...
Let's check:
git grep '\.bdrv_\(aio\|co\)_pwritev\(_part\)\?\s*=' | \
awk '{print $4}' | sed 's/,//' | sed 's/&//' | sort | uniq | \
while read func; do git grep "$func(" | \
grep -v "$func(BlockDriverState"; done
shows several callers:
qcow2:
qcow2_co_truncate() write at most up to @offset, which is checked in
generic qcow2_co_truncate() by bdrv_check_request().
qcow2_co_pwritev_compressed_task() pass the request (or part of the
request) that already went through normal write path, so it should
be OK
qcow:
qcow_co_pwritev_compressed() pass int64_t, it's updated by this patch
quorum:
quorum_co_pwrite_zeroes() pass int64_t and int - OK
throttle:
throttle_co_pwritev_compressed() pass int64_t, it's updated by this
patch
vmdk:
vmdk_co_pwritev_compressed() pass int64_t, it's updated by this
patch
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20210903102807.27127-5-vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
2021-09-03 13:28:00 +03:00
|
|
|
vpc_co_pwritev(BlockDriverState *bs, int64_t offset, int64_t bytes,
|
|
|
|
QEMUIOVector *qiov, BdrvRequestFlags flags)
|
2009-01-26 23:27:02 +03:00
|
|
|
{
|
2010-06-04 11:49:04 +04:00
|
|
|
BDRVVPCState *s = bs->opaque;
|
2016-04-26 17:24:46 +03:00
|
|
|
int64_t image_offset;
|
|
|
|
int64_t n_bytes;
|
|
|
|
int64_t bytes_done = 0;
|
2017-07-21 11:21:05 +03:00
|
|
|
int ret = 0;
|
2016-04-26 17:24:46 +03:00
|
|
|
QEMUIOVector local_qiov;
|
2009-01-26 23:27:02 +03:00
|
|
|
|
2020-12-17 19:20:01 +03:00
|
|
|
if (be32_to_cpu(s->footer.type) == VHD_FIXED) {
|
2016-06-20 22:31:46 +03:00
|
|
|
return bdrv_co_pwritev(bs->file, offset, bytes, qiov, 0);
|
2012-02-06 20:22:30 +04:00
|
|
|
}
|
2009-01-26 23:27:02 +03:00
|
|
|
|
2016-04-26 17:24:46 +03:00
|
|
|
qemu_co_mutex_lock(&s->lock);
|
|
|
|
qemu_iovec_init(&local_qiov, qiov->niov);
|
|
|
|
|
|
|
|
while (bytes > 0) {
|
2017-07-10 00:07:17 +03:00
|
|
|
image_offset = get_image_offset(bs, offset, true, &ret);
|
|
|
|
if (image_offset == -2) {
|
|
|
|
/* Failed to write block bitmap: can't proceed with write */
|
|
|
|
goto fail;
|
|
|
|
}
|
2016-04-26 17:24:46 +03:00
|
|
|
n_bytes = MIN(bytes, s->block_size - (offset % s->block_size));
|
2010-06-04 11:49:04 +04:00
|
|
|
|
2016-04-26 17:24:46 +03:00
|
|
|
if (image_offset == -1) {
|
|
|
|
image_offset = alloc_block(bs, offset);
|
|
|
|
if (image_offset < 0) {
|
|
|
|
ret = image_offset;
|
|
|
|
goto fail;
|
|
|
|
}
|
2009-01-26 23:27:02 +03:00
|
|
|
}
|
|
|
|
|
2016-04-26 17:24:46 +03:00
|
|
|
qemu_iovec_reset(&local_qiov);
|
|
|
|
qemu_iovec_concat(&local_qiov, qiov, bytes_done, n_bytes);
|
|
|
|
|
2019-03-15 17:04:38 +03:00
|
|
|
qemu_co_mutex_unlock(&s->lock);
|
2016-06-20 22:31:46 +03:00
|
|
|
ret = bdrv_co_pwritev(bs->file, image_offset, n_bytes,
|
2016-04-26 17:24:46 +03:00
|
|
|
&local_qiov, 0);
|
2019-03-15 17:04:38 +03:00
|
|
|
qemu_co_mutex_lock(&s->lock);
|
2016-04-26 17:24:46 +03:00
|
|
|
if (ret < 0) {
|
|
|
|
goto fail;
|
2010-06-04 11:49:04 +04:00
|
|
|
}
|
2009-01-26 23:27:02 +03:00
|
|
|
|
2016-04-26 17:24:46 +03:00
|
|
|
bytes -= n_bytes;
|
|
|
|
offset += n_bytes;
|
|
|
|
bytes_done += n_bytes;
|
2009-01-26 23:27:02 +03:00
|
|
|
}
|
|
|
|
|
2016-04-26 17:24:46 +03:00
|
|
|
ret = 0;
|
|
|
|
fail:
|
|
|
|
qemu_iovec_destroy(&local_qiov);
|
2011-10-20 15:16:23 +04:00
|
|
|
qemu_co_mutex_unlock(&s->lock);
|
2016-04-26 17:24:46 +03:00
|
|
|
|
2011-10-20 15:16:23 +04:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2023-06-01 14:51:36 +03:00
|
|
|
static int coroutine_fn GRAPH_RDLOCK
|
|
|
|
vpc_co_block_status(BlockDriverState *bs, bool want_zero,
|
|
|
|
int64_t offset, int64_t bytes,
|
|
|
|
int64_t *pnum, int64_t *map,
|
|
|
|
BlockDriverState **file)
|
2015-02-11 17:56:01 +03:00
|
|
|
{
|
|
|
|
BDRVVPCState *s = bs->opaque;
|
2018-02-13 23:26:59 +03:00
|
|
|
int64_t image_offset;
|
2015-02-11 17:56:01 +03:00
|
|
|
bool allocated;
|
2018-02-13 23:26:59 +03:00
|
|
|
int ret;
|
|
|
|
int64_t n;
|
2015-02-11 17:56:01 +03:00
|
|
|
|
2020-12-17 19:20:01 +03:00
|
|
|
if (be32_to_cpu(s->footer.type) == VHD_FIXED) {
|
2018-02-13 23:26:59 +03:00
|
|
|
*pnum = bytes;
|
|
|
|
*map = offset;
|
2016-01-26 06:58:57 +03:00
|
|
|
*file = bs->file->bs;
|
2019-07-25 18:55:12 +03:00
|
|
|
return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_RECURSE;
|
2015-02-11 17:56:01 +03:00
|
|
|
}
|
|
|
|
|
2017-06-29 16:27:42 +03:00
|
|
|
qemu_co_mutex_lock(&s->lock);
|
|
|
|
|
2018-02-13 23:26:59 +03:00
|
|
|
image_offset = get_image_offset(bs, offset, false, NULL);
|
|
|
|
allocated = (image_offset != -1);
|
2015-02-11 17:56:01 +03:00
|
|
|
*pnum = 0;
|
block/vpc: return ZERO block-status when appropriate
In case when get_image_offset() returns -1, we do zero out the
corresponding chunk of qiov. So, this should be reported as ZERO.
Note that this changes visible output of "qemu-img map --output=json"
and "qemu-io -c map" commands. For qemu-img map, the change is obvious:
we just mark as zero what is really zero. For qemu-io it's less
obvious: what was unallocated now is allocated.
There is an inconsistency in understanding of unallocated regions in
Qemu: backing-supporting format-drivers return 0 block-status to report
go-to-backing logic for this area. Some protocol-drivers (iscsi) return
0 to report fs-unallocated-non-zero status (i.e., don't occupy space on
disk, read result is undefined).
BDRV_BLOCK_ALLOCATED is defined as something more close to
go-to-backing logic. Still it is calculated as ZERO | DATA, so 0 from
iscsi is treated as unallocated. It doesn't influence backing-chain
behavior, as iscsi can't have backing file. But it does influence
"qemu-io -c map".
We should solve this inconsistency at some future point. Now, let's
just make backing-not-supporting format drivers (vdi in the previous
patch and vpc now) to behave more like backing-supporting drivers
and not report 0 block-status. More over, returning ZERO status is
absolutely valid thing, and again, corresponds to how the other
format-drivers (backing-supporting) work.
After block-status update, it never reports 0, so setting
unallocated_blocks_are_zero doesn't make sense (as the only user of it
is bdrv_co_block_status and it checks unallocated_blocks_are_zero only
for unallocated areas). Drop it.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200528094405.145708-5-vsementsov@virtuozzo.com>
[mreitz: qemu-io -c map as used by iotest 146 now reports everything as
allocated; in order to make the test do something useful, we
use qemu-img map --output=json now]
Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-05-28 12:43:59 +03:00
|
|
|
ret = BDRV_BLOCK_ZERO;
|
2015-02-11 17:56:01 +03:00
|
|
|
|
|
|
|
do {
|
|
|
|
/* All sectors in a block are contiguous (without using the bitmap) */
|
2018-02-13 23:26:59 +03:00
|
|
|
n = ROUND_UP(offset + 1, s->block_size) - offset;
|
|
|
|
n = MIN(n, bytes);
|
2015-02-11 17:56:01 +03:00
|
|
|
|
|
|
|
*pnum += n;
|
2018-02-13 23:26:59 +03:00
|
|
|
offset += n;
|
|
|
|
bytes -= n;
|
2015-03-03 13:41:52 +03:00
|
|
|
/* *pnum can't be greater than one block for allocated
|
|
|
|
* sectors since there is always a bitmap in between. */
|
|
|
|
if (allocated) {
|
2016-01-26 06:58:57 +03:00
|
|
|
*file = bs->file->bs;
|
2018-02-13 23:26:59 +03:00
|
|
|
*map = image_offset;
|
|
|
|
ret = BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID;
|
2017-06-29 16:27:42 +03:00
|
|
|
break;
|
2015-03-03 13:41:52 +03:00
|
|
|
}
|
2018-02-13 23:26:59 +03:00
|
|
|
if (bytes == 0) {
|
2015-02-11 17:56:01 +03:00
|
|
|
break;
|
|
|
|
}
|
2018-02-13 23:26:59 +03:00
|
|
|
image_offset = get_image_offset(bs, offset, false, NULL);
|
|
|
|
} while (image_offset == -1);
|
2015-02-11 17:56:01 +03:00
|
|
|
|
2017-06-29 16:27:42 +03:00
|
|
|
qemu_co_mutex_unlock(&s->lock);
|
|
|
|
return ret;
|
2015-02-11 17:56:01 +03:00
|
|
|
}
|
|
|
|
|
2009-01-26 23:27:06 +03:00
|
|
|
/*
|
|
|
|
* Calculates the number of cylinders, heads and sectors per cylinder
|
|
|
|
* based on a given number of sectors. This is the algorithm described
|
|
|
|
* in the VHD specification.
|
|
|
|
*
|
|
|
|
* Note that the geometry doesn't always exactly match total_sectors but
|
|
|
|
* may round it down.
|
2009-04-15 18:42:46 +04:00
|
|
|
*
|
2016-03-23 06:33:41 +03:00
|
|
|
* Returns 0 on success, -EFBIG if the size is larger than 2040 GiB. Override
|
2012-10-31 06:59:32 +04:00
|
|
|
* the hardware EIDE and ATA-2 limit of 16 heads (max disk size of 127 GB)
|
|
|
|
* and instead allow up to 255 heads.
|
2009-01-26 23:27:06 +03:00
|
|
|
*/
|
2020-10-30 06:35:12 +03:00
|
|
|
static int calculate_geometry(int64_t total_sectors, uint16_t *cyls,
|
|
|
|
uint8_t *heads, uint8_t *secs_per_cyl)
|
2009-01-26 23:27:06 +03:00
|
|
|
{
|
|
|
|
uint32_t cyls_times_heads;
|
|
|
|
|
2015-03-03 13:41:54 +03:00
|
|
|
total_sectors = MIN(total_sectors, VHD_MAX_GEOMETRY);
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2015-03-03 13:41:54 +03:00
|
|
|
if (total_sectors >= 65535LL * 16 * 63) {
|
2009-01-26 23:27:06 +03:00
|
|
|
*secs_per_cyl = 255;
|
2015-03-03 13:41:54 +03:00
|
|
|
*heads = 16;
|
2009-01-26 23:27:06 +03:00
|
|
|
cyls_times_heads = total_sectors / *secs_per_cyl;
|
|
|
|
} else {
|
|
|
|
*secs_per_cyl = 17;
|
|
|
|
cyls_times_heads = total_sectors / *secs_per_cyl;
|
2017-06-22 14:04:16 +03:00
|
|
|
*heads = DIV_ROUND_UP(cyls_times_heads, 1024);
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2015-03-03 13:41:54 +03:00
|
|
|
if (*heads < 4) {
|
2009-01-26 23:27:06 +03:00
|
|
|
*heads = 4;
|
2015-03-03 13:41:54 +03:00
|
|
|
}
|
2009-01-26 23:27:06 +03:00
|
|
|
|
|
|
|
if (cyls_times_heads >= (*heads * 1024) || *heads > 16) {
|
|
|
|
*secs_per_cyl = 31;
|
|
|
|
*heads = 16;
|
|
|
|
cyls_times_heads = total_sectors / *secs_per_cyl;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cyls_times_heads >= (*heads * 1024)) {
|
|
|
|
*secs_per_cyl = 63;
|
|
|
|
*heads = 16;
|
|
|
|
cyls_times_heads = total_sectors / *secs_per_cyl;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-05-10 23:46:26 +04:00
|
|
|
*cyls = cyls_times_heads / *heads;
|
2009-04-15 18:42:46 +04:00
|
|
|
|
|
|
|
return 0;
|
2009-01-26 23:27:06 +03:00
|
|
|
}
|
|
|
|
|
2023-06-01 14:51:36 +03:00
|
|
|
static int coroutine_fn create_dynamic_disk(BlockBackend *blk, VHDFooter *footer,
|
|
|
|
int64_t total_sectors)
|
2009-01-26 23:27:06 +03:00
|
|
|
{
|
2020-12-17 19:19:59 +03:00
|
|
|
VHDDynDiskHeader dyndisk_header;
|
2020-12-17 19:19:56 +03:00
|
|
|
uint8_t bat_sector[512];
|
2009-01-26 23:27:06 +03:00
|
|
|
size_t block_size, num_bat_entries;
|
2012-02-06 20:22:30 +04:00
|
|
|
int i;
|
2014-07-24 01:23:00 +04:00
|
|
|
int ret;
|
|
|
|
int64_t offset = 0;
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Write the footer (twice: at the beginning and at the end) */
|
2009-01-26 23:27:06 +03:00
|
|
|
block_size = 0x200000;
|
2020-04-02 12:36:03 +03:00
|
|
|
num_bat_entries = DIV_ROUND_UP(total_sectors, block_size / 512);
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2023-06-01 14:51:36 +03:00
|
|
|
ret = blk_co_pwrite(blk, offset, sizeof(*footer), footer, 0);
|
2016-04-07 17:52:34 +03:00
|
|
|
if (ret < 0) {
|
2011-01-12 22:49:00 +03:00
|
|
|
goto fail;
|
|
|
|
}
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2014-07-24 01:23:00 +04:00
|
|
|
offset = 1536 + ((num_bat_entries * 4 + 511) & ~511);
|
2023-06-01 14:51:36 +03:00
|
|
|
ret = blk_co_pwrite(blk, offset, sizeof(*footer), footer, 0);
|
2014-07-24 01:23:00 +04:00
|
|
|
if (ret < 0) {
|
2011-01-12 22:49:00 +03:00
|
|
|
goto fail;
|
|
|
|
}
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Write the initial BAT */
|
2014-07-24 01:23:00 +04:00
|
|
|
offset = 3 * 512;
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2020-12-17 19:19:56 +03:00
|
|
|
memset(bat_sector, 0xFF, 512);
|
2017-06-22 14:04:16 +03:00
|
|
|
for (i = 0; i < DIV_ROUND_UP(num_bat_entries * 4, 512); i++) {
|
2023-06-01 14:51:36 +03:00
|
|
|
ret = blk_co_pwrite(blk, offset, 512, bat_sector, 0);
|
2014-07-24 01:23:00 +04:00
|
|
|
if (ret < 0) {
|
2011-01-12 22:49:00 +03:00
|
|
|
goto fail;
|
|
|
|
}
|
2014-07-24 01:23:00 +04:00
|
|
|
offset += 512;
|
2011-01-12 22:49:00 +03:00
|
|
|
}
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Prepare the Dynamic Disk Header */
|
2020-12-17 19:20:00 +03:00
|
|
|
memset(&dyndisk_header, 0, sizeof(dyndisk_header));
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2020-12-17 19:19:59 +03:00
|
|
|
memcpy(dyndisk_header.magic, "cxsparse", 8);
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2011-11-09 20:32:25 +04:00
|
|
|
/*
|
|
|
|
* Note: The spec is actually wrong here for data_offset, it says
|
|
|
|
* 0xFFFFFFFF, but MS tools expect all 64 bits to be set.
|
|
|
|
*/
|
2020-12-17 19:19:59 +03:00
|
|
|
dyndisk_header.data_offset = cpu_to_be64(0xFFFFFFFFFFFFFFFFULL);
|
|
|
|
dyndisk_header.table_offset = cpu_to_be64(3 * 512);
|
|
|
|
dyndisk_header.version = cpu_to_be32(0x00010000);
|
|
|
|
dyndisk_header.block_size = cpu_to_be32(block_size);
|
|
|
|
dyndisk_header.max_table_entries = cpu_to_be32(num_bat_entries);
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2020-12-17 19:20:00 +03:00
|
|
|
dyndisk_header.checksum = cpu_to_be32(
|
|
|
|
vpc_checksum(&dyndisk_header, sizeof(dyndisk_header)));
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2016-03-23 06:33:44 +03:00
|
|
|
/* Write the header */
|
2014-07-24 01:23:00 +04:00
|
|
|
offset = 512;
|
2009-01-26 23:27:06 +03:00
|
|
|
|
2023-06-01 14:51:36 +03:00
|
|
|
ret = blk_co_pwrite(blk, offset, sizeof(dyndisk_header), &dyndisk_header, 0);
|
2014-07-24 01:23:00 +04:00
|
|
|
if (ret < 0) {
|
2011-01-12 22:49:00 +03:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2019-09-02 22:33:16 +03:00
|
|
|
ret = 0;
|
2012-02-06 20:22:30 +04:00
|
|
|
fail:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2023-06-01 14:51:36 +03:00
|
|
|
static int coroutine_fn create_fixed_disk(BlockBackend *blk, VHDFooter *footer,
|
|
|
|
int64_t total_size, Error **errp)
|
2012-02-06 20:22:30 +04:00
|
|
|
{
|
2014-07-24 01:23:00 +04:00
|
|
|
int ret;
|
2012-02-06 20:22:30 +04:00
|
|
|
|
|
|
|
/* Add footer to total size */
|
2020-12-17 19:20:03 +03:00
|
|
|
total_size += sizeof(*footer);
|
2014-07-24 01:23:00 +04:00
|
|
|
|
2023-06-01 14:51:36 +03:00
|
|
|
ret = blk_co_truncate(blk, total_size, false, PREALLOC_MODE_OFF, 0, errp);
|
2014-07-24 01:23:00 +04:00
|
|
|
if (ret < 0) {
|
|
|
|
return ret;
|
2012-02-06 20:22:30 +04:00
|
|
|
}
|
|
|
|
|
2023-06-01 14:51:36 +03:00
|
|
|
ret = blk_co_pwrite(blk, total_size - sizeof(*footer), sizeof(*footer),
|
|
|
|
footer, 0);
|
2014-07-24 01:23:00 +04:00
|
|
|
if (ret < 0) {
|
2017-03-28 23:51:27 +03:00
|
|
|
error_setg_errno(errp, -ret, "Unable to write VHD header");
|
2014-07-24 01:23:00 +04:00
|
|
|
return ret;
|
|
|
|
}
|
2012-02-06 20:22:30 +04:00
|
|
|
|
2019-09-02 22:33:16 +03:00
|
|
|
return 0;
|
2012-02-06 20:22:30 +04:00
|
|
|
}
|
|
|
|
|
2018-03-13 17:37:40 +03:00
|
|
|
static int calculate_rounded_image_size(BlockdevCreateOptionsVpc *vpc_opts,
|
|
|
|
uint16_t *out_cyls,
|
|
|
|
uint8_t *out_heads,
|
|
|
|
uint8_t *out_secs_per_cyl,
|
|
|
|
int64_t *out_total_sectors,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
int64_t total_size = vpc_opts->size;
|
|
|
|
uint16_t cyls = 0;
|
|
|
|
uint8_t heads = 0;
|
|
|
|
uint8_t secs_per_cyl = 0;
|
|
|
|
int64_t total_sectors;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate matching total_size and geometry. Increase the number of
|
|
|
|
* sectors requested until we get enough (or fail). This ensures that
|
|
|
|
* qemu-img convert doesn't truncate images, but rather rounds up.
|
|
|
|
*
|
|
|
|
* If the image size can't be represented by a spec conformant CHS geometry,
|
|
|
|
* we set the geometry to 65535 x 16 x 255 (CxHxS) sectors and use
|
|
|
|
* the image size from the VHD footer to calculate total_sectors.
|
|
|
|
*/
|
|
|
|
if (vpc_opts->force_size) {
|
|
|
|
/* This will force the use of total_size for sector count, below */
|
|
|
|
cyls = VHD_CHS_MAX_C;
|
|
|
|
heads = VHD_CHS_MAX_H;
|
|
|
|
secs_per_cyl = VHD_CHS_MAX_S;
|
|
|
|
} else {
|
|
|
|
total_sectors = MIN(VHD_MAX_GEOMETRY, total_size / BDRV_SECTOR_SIZE);
|
|
|
|
for (i = 0; total_sectors > (int64_t)cyls * heads * secs_per_cyl; i++) {
|
|
|
|
calculate_geometry(total_sectors + i, &cyls, &heads, &secs_per_cyl);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((int64_t)cyls * heads * secs_per_cyl == VHD_MAX_GEOMETRY) {
|
|
|
|
total_sectors = total_size / BDRV_SECTOR_SIZE;
|
|
|
|
/* Allow a maximum disk size of 2040 GiB */
|
|
|
|
if (total_sectors > VHD_MAX_SECTORS) {
|
|
|
|
error_setg(errp, "Disk size is too large, max size is 2040 GiB");
|
|
|
|
return -EFBIG;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
total_sectors = (int64_t) cyls * heads * secs_per_cyl;
|
|
|
|
}
|
|
|
|
|
|
|
|
*out_total_sectors = total_sectors;
|
|
|
|
if (out_cyls) {
|
|
|
|
*out_cyls = cyls;
|
|
|
|
*out_heads = heads;
|
|
|
|
*out_secs_per_cyl = secs_per_cyl;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-05-10 23:35:54 +03:00
|
|
|
static int coroutine_fn GRAPH_UNLOCKED
|
|
|
|
vpc_co_create(BlockdevCreateOptions *opts, Error **errp)
|
2012-02-06 20:22:30 +04:00
|
|
|
{
|
2018-03-09 21:53:19 +03:00
|
|
|
BlockdevCreateOptionsVpc *vpc_opts;
|
|
|
|
BlockBackend *blk = NULL;
|
|
|
|
BlockDriverState *bs = NULL;
|
|
|
|
|
2020-12-17 19:20:01 +03:00
|
|
|
VHDFooter footer;
|
2012-02-06 20:22:30 +04:00
|
|
|
uint16_t cyls = 0;
|
|
|
|
uint8_t heads = 0;
|
|
|
|
uint8_t secs_per_cyl = 0;
|
|
|
|
int64_t total_sectors;
|
|
|
|
int64_t total_size;
|
|
|
|
int disk_type;
|
|
|
|
int ret = -EIO;
|
2018-12-10 14:26:47 +03:00
|
|
|
QemuUUID uuid;
|
2012-02-06 20:22:30 +04:00
|
|
|
|
2018-03-09 21:53:19 +03:00
|
|
|
assert(opts->driver == BLOCKDEV_DRIVER_VPC);
|
|
|
|
vpc_opts = &opts->u.vpc;
|
|
|
|
|
|
|
|
/* Validate options and set default values */
|
|
|
|
total_size = vpc_opts->size;
|
|
|
|
|
|
|
|
if (!vpc_opts->has_subformat) {
|
|
|
|
vpc_opts->subformat = BLOCKDEV_VPC_SUBFORMAT_DYNAMIC;
|
|
|
|
}
|
|
|
|
switch (vpc_opts->subformat) {
|
|
|
|
case BLOCKDEV_VPC_SUBFORMAT_DYNAMIC:
|
2012-02-06 20:22:30 +04:00
|
|
|
disk_type = VHD_DYNAMIC;
|
2018-03-09 21:53:19 +03:00
|
|
|
break;
|
|
|
|
case BLOCKDEV_VPC_SUBFORMAT_FIXED:
|
|
|
|
disk_type = VHD_FIXED;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
g_assert_not_reached();
|
2012-02-06 20:22:30 +04:00
|
|
|
}
|
|
|
|
|
2018-03-09 21:53:19 +03:00
|
|
|
/* Create BlockBackend to write to the image */
|
2023-01-26 20:24:30 +03:00
|
|
|
bs = bdrv_co_open_blockdev_ref(vpc_opts->file, errp);
|
2018-03-09 21:53:19 +03:00
|
|
|
if (bs == NULL) {
|
|
|
|
return -EIO;
|
2012-02-06 20:22:30 +04:00
|
|
|
}
|
2016-03-08 17:57:05 +03:00
|
|
|
|
2023-01-26 20:24:30 +03:00
|
|
|
blk = blk_co_new_with_bs(bs, BLK_PERM_WRITE | BLK_PERM_RESIZE, BLK_PERM_ALL,
|
|
|
|
errp);
|
2020-04-28 22:26:46 +03:00
|
|
|
if (!blk) {
|
|
|
|
ret = -EPERM;
|
2014-07-24 01:23:00 +04:00
|
|
|
goto out;
|
qemu-img create: add 'nocow' option
Add 'nocow' option so that users could have a chance to set NOCOW flag to
newly created files. It's useful on btrfs file system to enhance performance.
Btrfs has low performance when hosting VM images, even more when the guest
in those VM are also using btrfs as file system. One way to mitigate this bad
performance is to turn off COW attributes on VM files. Generally, there are
two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then
all newly created files will be NOCOW. b) per file. Add the NOCOW file
attribute. It could only be done to empty or new files.
This patch tries the second way, according to the option, it could add NOCOW
per file.
For most block drivers, since the create file step is in raw-posix.c, so we
can do setting NOCOW flag ioctl in raw-posix.c only.
But there are some exceptions, like block/vpc.c and block/vdi.c, they are
creating file by calling qemu_open directly. For them, do the same setting
NOCOW flag ioctl work in them separately.
[Fixed up 082.out due to the new 'nocow' creation option
--Stefan]
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
|
|
|
}
|
2016-03-08 17:57:05 +03:00
|
|
|
blk_set_allow_write_beyond_eof(blk, true);
|
|
|
|
|
2018-03-13 17:37:40 +03:00
|
|
|
/* Get geometry and check that it matches the image size*/
|
|
|
|
ret = calculate_rounded_image_size(vpc_opts, &cyls, &heads, &secs_per_cyl,
|
|
|
|
&total_sectors, errp);
|
|
|
|
if (ret < 0) {
|
|
|
|
goto out;
|
2015-03-03 13:41:54 +03:00
|
|
|
}
|
|
|
|
|
2018-03-13 17:37:40 +03:00
|
|
|
if (total_size != total_sectors * BDRV_SECTOR_SIZE) {
|
|
|
|
error_setg(errp, "The requested image size cannot be represented in "
|
|
|
|
"CHS geometry");
|
|
|
|
error_append_hint(errp, "Try size=%llu or force-size=on (the "
|
|
|
|
"latter makes the image incompatible with "
|
|
|
|
"Virtual PC)",
|
|
|
|
total_sectors * BDRV_SECTOR_SIZE);
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
2012-02-06 20:22:30 +04:00
|
|
|
}
|
2012-02-07 13:15:47 +04:00
|
|
|
|
2012-02-06 20:22:30 +04:00
|
|
|
/* Prepare the Hard Disk Footer */
|
2020-12-17 19:20:03 +03:00
|
|
|
memset(&footer, 0, sizeof(footer));
|
2012-02-06 20:22:30 +04:00
|
|
|
|
2020-12-17 19:20:01 +03:00
|
|
|
memcpy(footer.creator, "conectix", 8);
|
2018-03-09 21:53:19 +03:00
|
|
|
if (vpc_opts->force_size) {
|
2020-12-17 19:20:01 +03:00
|
|
|
memcpy(footer.creator_app, "qem2", 4);
|
block/vpc: give option to force the current_size field in .bdrv_create
When QEMU creates a VHD image, it goes by the original spec,
calculating the current_size based on the nearest CHS geometry (with an
exception for disks > 127GB).
Apparently, Azure will only allow images that are sized to the nearest
MB, and the current_size as calculated from CHS cannot guarantee that.
Allow QEMU to create images similar to how Hyper-V creates images, by
setting current_size to the specified virtual disk size. This
introduces an option, force_size, to be passed to the vpc format during
image creation, e.g.:
qemu-img convert -f raw -o force_size -O vpc test.img test.vhd
When using the "force_size" option, the creator app field used by
QEMU will be "qem2" instead of "qemu", to indicate the difference.
In light of this, we also add parsing of the "qem2" field during
vpc_open.
Bug reference: https://bugs.launchpad.net/qemu/+bug/1490611
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:29 +03:00
|
|
|
} else {
|
2020-12-17 19:20:01 +03:00
|
|
|
memcpy(footer.creator_app, "qemu", 4);
|
block/vpc: give option to force the current_size field in .bdrv_create
When QEMU creates a VHD image, it goes by the original spec,
calculating the current_size based on the nearest CHS geometry (with an
exception for disks > 127GB).
Apparently, Azure will only allow images that are sized to the nearest
MB, and the current_size as calculated from CHS cannot guarantee that.
Allow QEMU to create images similar to how Hyper-V creates images, by
setting current_size to the specified virtual disk size. This
introduces an option, force_size, to be passed to the vpc format during
image creation, e.g.:
qemu-img convert -f raw -o force_size -O vpc test.img test.vhd
When using the "force_size" option, the creator app field used by
QEMU will be "qem2" instead of "qemu", to indicate the difference.
In light of this, we also add parsing of the "qem2" field during
vpc_open.
Bug reference: https://bugs.launchpad.net/qemu/+bug/1490611
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:29 +03:00
|
|
|
}
|
2020-12-17 19:20:01 +03:00
|
|
|
memcpy(footer.creator_os, "Wi2k", 4);
|
2012-02-06 20:22:30 +04:00
|
|
|
|
2020-12-17 19:20:01 +03:00
|
|
|
footer.features = cpu_to_be32(0x02);
|
|
|
|
footer.version = cpu_to_be32(0x00010000);
|
2012-02-06 20:22:30 +04:00
|
|
|
if (disk_type == VHD_DYNAMIC) {
|
2020-12-17 19:20:03 +03:00
|
|
|
footer.data_offset = cpu_to_be64(sizeof(footer));
|
2012-02-06 20:22:30 +04:00
|
|
|
} else {
|
2020-12-17 19:20:01 +03:00
|
|
|
footer.data_offset = cpu_to_be64(0xFFFFFFFFFFFFFFFFULL);
|
2012-02-06 20:22:30 +04:00
|
|
|
}
|
2020-12-17 19:20:01 +03:00
|
|
|
footer.timestamp = cpu_to_be32(time(NULL) - VHD_TIMESTAMP_BASE);
|
2012-02-06 20:22:30 +04:00
|
|
|
|
|
|
|
/* Version of Virtual PC 2007 */
|
2020-12-17 19:20:01 +03:00
|
|
|
footer.major = cpu_to_be16(0x0005);
|
|
|
|
footer.minor = cpu_to_be16(0x0003);
|
|
|
|
footer.orig_size = cpu_to_be64(total_size);
|
|
|
|
footer.current_size = cpu_to_be64(total_size);
|
|
|
|
footer.cyls = cpu_to_be16(cyls);
|
|
|
|
footer.heads = heads;
|
|
|
|
footer.secs_per_cyl = secs_per_cyl;
|
2012-02-06 20:22:30 +04:00
|
|
|
|
2020-12-17 19:20:01 +03:00
|
|
|
footer.type = cpu_to_be32(disk_type);
|
2012-02-06 20:22:30 +04:00
|
|
|
|
2018-12-10 14:26:47 +03:00
|
|
|
qemu_uuid_generate(&uuid);
|
2020-12-17 19:20:01 +03:00
|
|
|
footer.uuid = uuid;
|
2012-02-06 20:22:30 +04:00
|
|
|
|
2020-12-17 19:20:03 +03:00
|
|
|
footer.checksum = cpu_to_be32(vpc_checksum(&footer, sizeof(footer)));
|
2012-02-06 20:22:30 +04:00
|
|
|
|
|
|
|
if (disk_type == VHD_DYNAMIC) {
|
2020-12-17 19:20:02 +03:00
|
|
|
ret = create_dynamic_disk(blk, &footer, total_sectors);
|
2017-03-28 23:51:27 +03:00
|
|
|
if (ret < 0) {
|
|
|
|
error_setg(errp, "Unable to create or write VHD header");
|
|
|
|
}
|
2012-02-06 20:22:30 +04:00
|
|
|
} else {
|
2020-12-17 19:20:02 +03:00
|
|
|
ret = create_fixed_disk(blk, &footer, total_size, errp);
|
2016-03-23 06:33:38 +03:00
|
|
|
}
|
2012-02-06 20:22:30 +04:00
|
|
|
|
2014-06-05 13:21:10 +04:00
|
|
|
out:
|
2023-05-04 14:57:33 +03:00
|
|
|
blk_co_unref(blk);
|
|
|
|
bdrv_co_unref(bs);
|
2018-03-09 21:53:19 +03:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2023-05-10 23:35:54 +03:00
|
|
|
static int coroutine_fn GRAPH_UNLOCKED
|
2023-02-03 18:21:55 +03:00
|
|
|
vpc_co_create_opts(BlockDriver *drv, const char *filename,
|
|
|
|
QemuOpts *opts, Error **errp)
|
2018-03-09 21:53:19 +03:00
|
|
|
{
|
|
|
|
BlockdevCreateOptions *create_options = NULL;
|
2018-06-14 22:14:32 +03:00
|
|
|
QDict *qdict;
|
2018-03-09 21:53:19 +03:00
|
|
|
Visitor *v;
|
|
|
|
BlockDriverState *bs = NULL;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
static const QDictRenames opt_renames[] = {
|
|
|
|
{ VPC_OPT_FORCE_SIZE, "force-size" },
|
|
|
|
{ NULL, NULL },
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Parse options and convert legacy syntax */
|
|
|
|
qdict = qemu_opts_to_qdict_filtered(opts, NULL, &vpc_create_opts, true);
|
|
|
|
|
|
|
|
if (!qdict_rename_keys(qdict, opt_renames, errp)) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Create and open the file (protocol layer) */
|
2022-11-28 17:23:31 +03:00
|
|
|
ret = bdrv_co_create_file(filename, opts, errp);
|
2018-03-09 21:53:19 +03:00
|
|
|
if (ret < 0) {
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2023-01-26 20:24:30 +03:00
|
|
|
bs = bdrv_co_open(filename, NULL, NULL,
|
|
|
|
BDRV_O_RDWR | BDRV_O_RESIZE | BDRV_O_PROTOCOL, errp);
|
2018-03-09 21:53:19 +03:00
|
|
|
if (bs == NULL) {
|
|
|
|
ret = -EIO;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now get the QAPI type BlockdevCreateOptions */
|
|
|
|
qdict_put_str(qdict, "driver", "vpc");
|
|
|
|
qdict_put_str(qdict, "file", bs->node_name);
|
|
|
|
|
2018-06-14 22:14:33 +03:00
|
|
|
v = qobject_input_visitor_new_flat_confused(qdict, errp);
|
|
|
|
if (!v) {
|
2018-03-09 21:53:19 +03:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2020-07-07 19:06:07 +03:00
|
|
|
visit_type_BlockdevCreateOptions(v, NULL, &create_options, errp);
|
2018-03-09 21:53:19 +03:00
|
|
|
visit_free(v);
|
2020-07-07 19:06:07 +03:00
|
|
|
if (!create_options) {
|
2018-03-09 21:53:19 +03:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Silently round up size */
|
|
|
|
assert(create_options->driver == BLOCKDEV_DRIVER_VPC);
|
|
|
|
create_options->u.vpc.size =
|
|
|
|
ROUND_UP(create_options->u.vpc.size, BDRV_SECTOR_SIZE);
|
|
|
|
|
2018-03-13 17:37:40 +03:00
|
|
|
if (!create_options->u.vpc.force_size) {
|
|
|
|
int64_t total_sectors;
|
|
|
|
ret = calculate_rounded_image_size(&create_options->u.vpc, NULL, NULL,
|
|
|
|
NULL, &total_sectors, errp);
|
|
|
|
if (ret < 0) {
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
create_options->u.vpc.size = total_sectors * BDRV_SECTOR_SIZE;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-03-09 21:53:19 +03:00
|
|
|
/* Create the vpc image (format layer) */
|
|
|
|
ret = vpc_co_create(create_options, errp);
|
|
|
|
|
|
|
|
fail:
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2023-05-04 14:57:33 +03:00
|
|
|
bdrv_co_unref(bs);
|
2018-03-09 21:53:19 +03:00
|
|
|
qapi_free_BlockdevCreateOptions(create_options);
|
2011-01-12 22:49:00 +03:00
|
|
|
return ret;
|
2009-01-26 23:27:06 +03:00
|
|
|
}
|
|
|
|
|
2018-03-09 21:53:19 +03:00
|
|
|
|
2023-10-27 18:53:11 +03:00
|
|
|
static int GRAPH_RDLOCK vpc_has_zero_init(BlockDriverState *bs)
|
2013-06-28 12:21:00 +04:00
|
|
|
{
|
|
|
|
BDRVVPCState *s = bs->opaque;
|
|
|
|
|
2020-12-17 19:20:01 +03:00
|
|
|
if (be32_to_cpu(s->footer.type) == VHD_FIXED) {
|
2015-06-16 15:19:22 +03:00
|
|
|
return bdrv_has_zero_init(bs->file->bs);
|
2013-06-28 12:21:00 +04:00
|
|
|
} else {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-28 00:17:58 +04:00
|
|
|
static void vpc_close(BlockDriverState *bs)
|
|
|
|
{
|
|
|
|
BDRVVPCState *s = bs->opaque;
|
2014-03-26 16:05:36 +04:00
|
|
|
qemu_vfree(s->pagetable);
|
2005-04-28 00:17:58 +04:00
|
|
|
#ifdef CACHE
|
2011-08-21 07:09:37 +04:00
|
|
|
g_free(s->pageentry_u8);
|
2005-04-28 00:17:58 +04:00
|
|
|
#endif
|
2011-11-22 19:51:12 +04:00
|
|
|
|
2023-10-18 16:03:36 +03:00
|
|
|
migrate_del_blocker(&s->migration_blocker);
|
2005-04-28 00:17:58 +04:00
|
|
|
}
|
|
|
|
|
2014-06-05 13:21:10 +04:00
|
|
|
static QemuOptsList vpc_create_opts = {
|
|
|
|
.name = "vpc-create-opts",
|
|
|
|
.head = QTAILQ_HEAD_INITIALIZER(vpc_create_opts.head),
|
|
|
|
.desc = {
|
|
|
|
{
|
|
|
|
.name = BLOCK_OPT_SIZE,
|
|
|
|
.type = QEMU_OPT_SIZE,
|
|
|
|
.help = "Virtual disk size"
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = BLOCK_OPT_SUBFMT,
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
.help =
|
|
|
|
"Type of virtual hard disk format. Supported formats are "
|
|
|
|
"{dynamic (default) | fixed} "
|
|
|
|
},
|
block/vpc: give option to force the current_size field in .bdrv_create
When QEMU creates a VHD image, it goes by the original spec,
calculating the current_size based on the nearest CHS geometry (with an
exception for disks > 127GB).
Apparently, Azure will only allow images that are sized to the nearest
MB, and the current_size as calculated from CHS cannot guarantee that.
Allow QEMU to create images similar to how Hyper-V creates images, by
setting current_size to the specified virtual disk size. This
introduces an option, force_size, to be passed to the vpc format during
image creation, e.g.:
qemu-img convert -f raw -o force_size -O vpc test.img test.vhd
When using the "force_size" option, the creator app field used by
QEMU will be "qem2" instead of "qemu", to indicate the difference.
In light of this, we also add parsing of the "qem2" field during
vpc_open.
Bug reference: https://bugs.launchpad.net/qemu/+bug/1490611
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 20:27:29 +03:00
|
|
|
{
|
|
|
|
.name = VPC_OPT_FORCE_SIZE,
|
|
|
|
.type = QEMU_OPT_BOOL,
|
|
|
|
.help = "Force disk size calculation to use the actual size "
|
|
|
|
"specified, rather than using the nearest CHS-based "
|
|
|
|
"calculation"
|
|
|
|
},
|
2014-06-05 13:21:10 +04:00
|
|
|
{ /* end of list */ }
|
|
|
|
}
|
2009-05-18 18:42:10 +04:00
|
|
|
};
|
|
|
|
|
2019-02-01 22:29:25 +03:00
|
|
|
static const char *const vpc_strong_runtime_opts[] = {
|
|
|
|
VPC_OPT_SIZE_CALC,
|
|
|
|
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2009-05-10 02:03:42 +04:00
|
|
|
static BlockDriver bdrv_vpc = {
|
2010-10-22 18:17:57 +04:00
|
|
|
.format_name = "vpc",
|
|
|
|
.instance_size = sizeof(BDRVVPCState),
|
2011-11-10 20:25:44 +04:00
|
|
|
|
2013-06-28 12:21:00 +04:00
|
|
|
.bdrv_probe = vpc_probe,
|
|
|
|
.bdrv_open = vpc_open,
|
|
|
|
.bdrv_close = vpc_close,
|
|
|
|
.bdrv_reopen_prepare = vpc_reopen_prepare,
|
2020-05-13 14:05:39 +03:00
|
|
|
.bdrv_child_perm = bdrv_default_perms,
|
2018-03-09 21:53:19 +03:00
|
|
|
.bdrv_co_create = vpc_co_create,
|
2018-01-18 15:43:45 +03:00
|
|
|
.bdrv_co_create_opts = vpc_co_create_opts,
|
2009-05-18 18:42:10 +04:00
|
|
|
|
2016-04-26 17:24:46 +03:00
|
|
|
.bdrv_co_preadv = vpc_co_preadv,
|
2016-04-26 17:24:46 +03:00
|
|
|
.bdrv_co_pwritev = vpc_co_pwritev,
|
2018-02-13 23:26:59 +03:00
|
|
|
.bdrv_co_block_status = vpc_co_block_status,
|
2011-11-10 20:25:44 +04:00
|
|
|
|
2023-01-13 23:42:08 +03:00
|
|
|
.bdrv_co_get_info = vpc_co_get_info,
|
2013-11-22 16:39:49 +04:00
|
|
|
|
2020-05-13 14:05:12 +03:00
|
|
|
.is_format = true,
|
2014-06-05 13:21:10 +04:00
|
|
|
.create_opts = &vpc_create_opts,
|
2013-06-28 12:21:00 +04:00
|
|
|
.bdrv_has_zero_init = vpc_has_zero_init,
|
2019-02-01 22:29:25 +03:00
|
|
|
.strong_runtime_opts = vpc_strong_runtime_opts,
|
2005-04-28 00:17:58 +04:00
|
|
|
};
|
2009-05-10 02:03:42 +04:00
|
|
|
|
|
|
|
static void bdrv_vpc_init(void)
|
|
|
|
{
|
|
|
|
bdrv_register(&bdrv_vpc);
|
|
|
|
}
|
|
|
|
|
|
|
|
block_init(bdrv_vpc_init);
|