Currently all disk types that are supported are defined in a header
file private to blktapctrl and tapdisk. When restoring ioemu as a
backend for blktap these constants are needed by ioemu, so move them
to a more public header file.
Signed-off-by: Kevin Wolf <kwolf@suse.de>
This patch adds support for specifying the backend (tapdisk or ioemu)
to blktapctrl. Images can be specified e.g. as tap:tapdisk:aio,
tap:ioemu:qcow2 or tap:vmdk. When omitting the backend, a default is
chosen based on the image type (currently always tapdisk because ioemu
as a backend is broken until a follow-up patch series against qemu-xen
is applied)
Signed-off-by: Kevin Wolf <kwolf@suse.de>
When a domain wants to use a tap:ioemu disk but has no device model,
start a tapdisk-ioemu instance as provider. Also, move the creation
and removal of communication pipes to xend so that qemu-dm doesn't
need the unwanted SIGHUP handler anymore.
Signed-off-by: Kevin Wolf <kwolf@suse.de>
When a domain wants to use a tap:ioemu disk but has no device model,
start a tapdisk-ioemu instance as provider. Also, move the creation
and removal of communication pipes to xend so that qemu-dm doesn't
need the unwanted SIGHUP handler anymore.
Signed-off-by: Kevin Wolf <kwolf@suse.de>
Add support for a tap:ioemu pseudo driver. Devices using this driver
won't use tapdisk (containing the code duplication) any more, but will
connect to the qemu-dm of the domain. In this way no working
configuration should be broken right now as you can still choose to
use the tapdisk drivers.
Signed-off-by: Kevin Wolf <kwolf@suse.de>
This patch adds support for the qcow2 image format to blktap. It
consists mostly of qemu code, adapted to the blktap interfaces.
Snapshots and compressed images are supported.
The qcow2 driver may be used by either specifying tap:qcow2 or by
using tap:qcow which will detect that you have a version 2 image and
will call the qcow2 driver.
Signed-off-by: Kevin Wolf <kwolf@suse.de>
Enables tapdisk to chain an arbitrary number of VDIs, propagating reads of
holes in children to their parent images. Introduces two new functions to the
tapdisk interface to facilitate this. Modifies the QCoW plugin to take
advantage of these changes, thus providing support for arbitrarily long chains
of QCoW image types.
While the kernel side of blktap drivers is using 64-bit sector numbers
correctly when reporting disk sizing, the userspace parts where this
dat is actually generated is truncating at 32-bit. There are 3 variables
related to disk sizing which are used in the kernel/userspace code
'size', 'sector size' & 'info'. In kernel space these are treated as being
unsigned long long, unsigned long, and unsigned int, respectively. In
the blktap userspace code this were all varyingly long, unsigned long.
This mismatch caused 32-bit wraparound on large disks. The attached
patch updates the blktap userspace to use the same data types as
kernel space for all these params, thus both fixing the 32-bit bug &
giving the code consistency.
This patch has been tested both by comparing /proc/partitions in the
guest, with the image size seen in the host, and by using Stephen
Tweedie's 'verify-data' tool on a variety of multi-TB sized disks.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
- remove magic number 8 and 64.
page size / sector size is 8 on x86, however on ia64 page size is
16kb.
blkring size is 64 on x86. however it's 128 on ia64.
- replace 0xFFFF with INVALID_GRANT_HANDLE
- don't map io ring into user space with uncachable.
kernel access the page with cacable and tapdisk uses memory barrier
so that it isn't necessary.
- remove printk warning and inserted new line.
- remove unused variable, page.
- add one BUG()
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Keir Fraser
Jake Wires
kfraser@localhost.localdomain
jchesterfield@dhcp92.uk.xensource.com