On Wed, 30 Jan 2019 at 13:30, Laurent Vivier wrote:
>
> The following changes since commit b4fbe1f65a4769c09e6bf2d79fc84360f840f40e:
>
> Merge remote-tracking branch
> 'remotes/pmaydell/tags/pull-target-arm-20190129' into staging (2019-01-29
> 12:00:19 +)
>
> are available in the Git
Patchew URL:
https://patchew.org/QEMU/20190128173901.3357-1-antonkuc...@yandex-team.ru/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH] block: split block/qapi.c to avoid linking
utilities with qapi
Message-id:
This changes the qcow2 implementation to direct all guest data I/O to
s->data_file rather than bs->file, while metadata I/O still uses
bs->file. At the moment, this is still always the same, but soon we'll
add options to set s->data_file to an external data file.
Signed-off-by: Kevin Wolf
---
Signed-off-by: Kevin Wolf
---
qapi/block-core.json | 1 +
block/qcow2.c| 6 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 060df28797..0eb0637b64 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -74,6
On Thu, Jan 31, 2019 at 7:57 PM Kevin Wolf wrote:
This will be very useful for new oVirt Cinder based storage. Thanks for
working on this!
I did not see any discussion about this here, but I did not follow this
list closely
lately. Do we have more info on this? a feature page describing the use
The cluster allocation code uses 0 as an invalid offset that is used in
case of errors or as "offset not yet determined". With external data
files, a host cluster offset of 0 becomes valid, though.
Define a constant INV_OFFSET (which is not cluster aligned and will
therefore never be a valid
This adds external data file to the qcow2 spec as a new incompatible
feature.
Signed-off-by: Kevin Wolf
---
docs/interop/qcow2.txt | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
index
Signed-off-by: Kevin Wolf
---
block/qcow2.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/block/qcow2.h b/block/qcow2.h
index 2cb763bf11..b17bd502f5 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -519,7 +519,15 @@ static inline QCow2ClusterType
On 1/31/19 11:55 AM, Kevin Wolf wrote:
> This adds external data file to the qcow2 spec as a new incompatible
> feature.
>
> Signed-off-by: Kevin Wolf
> ---
> docs/interop/qcow2.txt | 19 ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> @@ -148,6 +158,7 @@ be stored.
Rather than requiring that the external data file node is passed
explicitly when creating the qcow2 node, store the filename in the
designated header extension during .bdrv_create and read it from there
as a default during .bdrv_open.
Signed-off-by: Kevin Wolf
---
block/qcow2.h |
On 1/31/19 11:55 AM, Kevin Wolf wrote:
> This adds a .bdrv_open option to specify the external data file node.
>
> Signed-off-by: Kevin Wolf
> ---
> qapi/block-core.json | 3 ++-
> block/qcow2.h| 4 +++-
> block/qcow2.c| 25 +++--
> 3 files changed, 28
On Thu, Jan 31, 2019 at 8:43 PM Eric Blake wrote:
...
> > @@ -450,8 +461,10 @@ Standard Cluster Descriptor:
>
> 1 - 8:Reserved (set to 0)
> >
> > 9 - 55:Bits 9-55 of host cluster offset. Must be aligned
> to a
> > -cluster boundary. If the offset
On Thu, Jan 31, 2019 at 8:20 PM Kevin Wolf wrote:
> Rather than requiring that the external data file node is passed
> explicitly when creating the qcow2 node, store the filename in the
> designated header extension during .bdrv_create and read it from there
> as a default during .bdrv_open.
>
On 01/02/19 00:28, Alexandro Sanchez Bach wrote:
> (CC'd Yu Ning @ Intel's HAXM team)
>
> Not sure, if I'm understanding the issue correctly, but isn't
> `HAX_VM_IOCTL_SET_RAM2` with the `HAX_RAM_INFO_ROM` flag precisely
> what you are looking for?
>
> More precisely, HAX_VM_IOCTL_SET_RAM2 maps
On Thu, Jan 31, 2019 at 04:19:13PM +0100, Stefano Garzarella wrote:
> The size of data in the virtio_blk_request must be a multiple
> of 512 bytes for IN and OUT requests, or a multiple of the size
> of struct virtio_blk_discard_write_zeroes for DISCARD and
> WRITE_ZEROES requests.
>
>
On Thu, Jan 31, 2019 at 04:19:12PM +0100, Stefano Garzarella wrote:
> diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> index 542ec52536..34ee676895 100644
> --- a/hw/block/virtio-blk.c
> +++ b/hw/block/virtio-blk.c
> @@ -147,6 +147,30 @@ out:
>
On Thu, Jan 31, 2019 at 11:32:32AM +, Fernando Casas Schössow wrote:
> Sorry for resurrecting this thread after so long but I just upgraded the host
> to Qemu 3.1 and libvirt 4.10 and I'm still facing this problem.
> At the moment I cannot use virtio disks (virtio-blk nor virtio-scsi) with my
On Thu, Jan 31, 2019 at 04:19:11PM +0100, Stefano Garzarella wrote:
> In order to avoid migration issues, we enable DISCARD and
> WRITE ZEROES features only for machine type >= 4.0
Please use two separate properties that correspond to the
VIRTIO_BLK_F_DISCARD and VIRTIO_BLK_F_WRITE_ZEROES
On Thu, Jan 31, 2019 at 04:19:14PM +0100, Stefano Garzarella wrote:
> If the WRITE_ZEROES feature is enabled, we check this command
> in the test_basic().
>
> Signed-off-by: Stefano Garzarella
> ---
> tests/virtio-blk-test.c | 60 +
> 1 file changed, 60
On Thu, Jan 31, 2019 at 04:19:10PM +0100, Stefano Garzarella wrote:
> We add acct_failed param in order to use virtio_blk_handle_rw_error()
> also when is not required to call block_acct_failed(). (eg. a discard
> operation is failed)
>
> Signed-off-by: Stefano Garzarella
> ---
>
On Thu, Jan 31, 2019 at 03:31:51PM +0100, Kevin Wolf wrote:
> bdrv_co_invalidate_cache() clears the BDRV_O_INACTIVE flag before
> actually activating a node so that the correct permissions etc. are
> taken. In case of errors, the flag must be restored so that the next
> call to
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Friday, February 1, 2019 7:55
> To: Alexandro Sanchez Bach ; 'Markus Armbruster'
>
> Cc: 'Peter Maydell' ; 'Peter Krempa'
> ; 'Qemu-block' ; 'Libvirt'
> ; 'QEMU Developers' ;
> 'László Érsek' ; 'Justin Terry
On Thu, Jan 31, 2019 at 02:38:10PM +0200, Alberto Garcia wrote:
> The cmd() method of the QEMUQtestProtocol class sends a qtest command
> to QEMU but doesn't wait for the return message ("OK", "FAIL", "ERR").
> Because of this, it can return control to the caller before the
> command has actually
On 31/01/19 10:41, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 31/01/19 09:40, Markus Armbruster wrote:
Maybe we should just add pflash block properties to the machine? And
then it can create the devices if the properties are set to a non-empty
value.
>>> What
Peter Maydell writes:
> On Thu, 31 Jan 2019 at 08:52, Markus Armbruster wrote:
>> Lesson for the future: when we correct something, but don't dare to
>> touch (some) existing uses (being not "reasonably sure it doesn't
>> actually break guests that used to work"), we should at least have
>>
30.01.2019 22:26, Andrey Shinkevich wrote:
>
>
> On 30/01/2019 21:24, Eric Blake wrote:
>> On 1/30/19 11:51 AM, Andrey Shinkevich wrote:
>>> In the 'Format specific information' section of the 'qemu-img info'
>>> command output, the supplemental information about existing QCOW2
[...]
>>> +##
On Thu, 31 Jan 2019 at 10:24, Markus Armbruster wrote:
> 1. Make the device model default to some "correct" configuration, even
> if that setting is kind of arbitrary. That way, any code using new
> style gets an "incorrect" configuration only if it actively selects one.
I don't think that's
Laszlo Ersek writes:
> On 01/30/19 15:33, Paolo Bonzini wrote:
>> On 30/01/19 15:13, Markus Armbruster wrote:
>>> -global driver=cfi.pflash01,property=secure,value=on
>>>
>>> Affects *all* such devices, but fortunately we have at most two, and
>>> the one we don't want to affect happens to
Paolo Bonzini writes:
> On 31/01/19 09:40, Markus Armbruster wrote:
>>> Maybe we should just add pflash block properties to the machine? And
>>> then it can create the devices if the properties are set to a non-empty
>>> value.
>> What exactly do you have in mind? Something like
>>
>>
31.01.2019 5:26, John Snow wrote:
> It's not enough to order the kwargs for consistent QMP log output,
> we must also sort any sub-dictionaries in lists that appear as values.
>
> Reported-by: Kevin Wolf
> Signed-off-by: John Snow
> ---
> tests/qemu-iotests/236.out| 56
Paolo Bonzini writes:
> On 31/01/19 09:33, Markus Armbruster wrote:
>> I thought secure=on affected only writes (and so wouldn't matter with
>> readonly=on), but I was wrong:
>>
>> static MemTxResult pflash_mem_read_with_attrs(void *opaque, hwaddr addr,
>> uint64_t *value,
>>
On Thu, 31 Jan 2019 at 08:52, Markus Armbruster wrote:
> Lesson for the future: when we correct something, but don't dare to
> touch (some) existing uses (being not "reasonably sure it doesn't
> actually break guests that used to work"), we should at least have
> enough sense to make "incorrect"
Hi,
Sorry for resurrecting this thread after so long but I just upgraded the host
to Qemu 3.1 and libvirt 4.10 and I'm still facing this problem.
At the moment I cannot use virtio disks (virtio-blk nor virtio-scsi) with my
guests in order to avoid this issue so as a workaround I'm using SATA
Paolo Bonzini writes:
> On 30/01/19 15:13, Markus Armbruster wrote:
>> -global driver=cfi.pflash01,property=secure,value=on
>>
>> Affects *all* such devices, but fortunately we have at most two, and the
>> one we don't want to affect happens to ignore the property value.
>
> Is this true?
Am 31.01.2019 um 03:26 hat John Snow geschrieben:
> It's not enough to order the kwargs for consistent QMP log output,
> we must also sort any sub-dictionaries in lists that appear as values.
>
> Reported-by: Kevin Wolf
> Signed-off-by: John Snow
Thanks, applied to the block branch.
Kevin
30.01.2019 22:58, John Snow wrote:
>
>
> On 1/30/19 8:58 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Hi!
>>
>> I have a question about job_pause_point. Now a good job of moving generic
>> things about
>> block-jobs to job.c is done..
>>
>> job_pause_point do visible job-state change, as changing
31.01.2019 4:01, John Snow wrote:
> The meaning of the states has changed subtly over time,
> this should bring the understanding more in-line with the
> current, actual usages.
>
> Reported-by: Eric Blake
> Signed-off-by: John Snow
> ---
> block/dirty-bitmap.c | 19 +--
>
Am 31.01.2019 um 03:03 hat John Snow geschrieben:
> On 1/30/19 12:27 PM, Kevin Wolf wrote:
> > Am 14.01.2019 um 17:25 hat Eric Blake geschrieben:
> >> From: John Snow
> >>
> >> New interface, new smoke test.
> >>
> >> Signed-off-by: John Snow
> >> Reviewed-by: Vladimir Sementsov-Ogievskiy
> >>
Am 31.01.2019 um 00:52 hat Max Reitz geschrieben:
> Without this filter, this test sometimes fails.
>
> Signed-off-by: Max Reitz
Thanks, applied to the block branch.
Kevin
On 31/01/19 09:33, Markus Armbruster wrote:
> I thought secure=on affected only writes (and so wouldn't matter with
> readonly=on), but I was wrong:
>
> static MemTxResult pflash_mem_read_with_attrs(void *opaque, hwaddr addr,
> uint64_t *value,
>
Peter Maydell writes:
> On Wed, 30 Jan 2019 at 16:44, Laszlo Ersek wrote:
>>
>> On 01/30/19 16:24, Peter Maydell wrote:
>>
>> > Well, nobody who does anything with x86 has cared enough to
>> > make the pflash implementation actually correct.
>>
>> I feel sort of included under this umbrella,
On 31/01/19 09:40, Markus Armbruster wrote:
>> Maybe we should just add pflash block properties to the machine? And
>> then it can create the devices if the properties are set to a non-empty
>> value.
> What exactly do you have in mind? Something like
>
> -machine
On 01/31/19 10:19, Paolo Bonzini wrote:
> On 31/01/19 09:40, Markus Armbruster wrote:
>>> Maybe we should just add pflash block properties to the machine? And
>>> then it can create the devices if the properties are set to a non-empty
>>> value.
>> What exactly do you have in mind? Something
Inform a user in case qcow2_get_specific_info fails to obtain
QCOW2 image specific information. This patch is preliminary to
the print of bitmap information in the 'qemu-img info' output.
Signed-off-by: Andrey Shinkevich
Reviewed-by: Eric Blake
---
block.c | 5 +++--
v11:
An assertion was added to the get_bitmap_info_flags() to check the
completed mapping of all the reserved bitmap BME_ flags.
The heading comment of get_bitmap_info_flags() was changed to
describe the function design properly.
In qcow2_get_specific_info(), two function calls to g_free were
On 01/31/19 10:37, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 31/01/19 09:33, Markus Armbruster wrote:
>>> I thought secure=on affected only writes (and so wouldn't matter with
>>> readonly=on), but I was wrong:
>>>
>>> static MemTxResult pflash_mem_read_with_attrs(void
On 31/01/19 10:37, Markus Armbruster wrote:
>>
>>> Hmm, why is it okay to treat all pfl->cmd values the same when
>>> secure=on?
>> But doesn't matter. You just don't want MMIO mode to be active outside
>> SMM: all that non-SMM code want to do with the flash is read and execute
>> it, as far as
Paolo Bonzini writes:
> On 31/01/19 10:41, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> On 31/01/19 09:40, Markus Armbruster wrote:
> Maybe we should just add pflash block properties to the machine? And
> then it can create the devices if the properties are set to a
The cmd() method of the QEMUQtestProtocol class sends a qtest command
to QEMU but doesn't wait for the return message ("OK", "FAIL", "ERR").
Because of this, it can return control to the caller before the
command has actually finished.
In cases like clock_step or clock_set this means that cmd()
Peter Maydell writes:
> On Thu, 31 Jan 2019 at 10:24, Markus Armbruster wrote:
>> 1. Make the device model default to some "correct" configuration, even
>> if that setting is kind of arbitrary. That way, any code using new
>> style gets an "incorrect" configuration only if it actively selects
From: mahaocong
This patch adds possibility to start mirroring with user-created-bitmap.
On full mode, mirror create a non-named-bitmap by scanning whole block-chain,
and on top mode, mirror create a bitmap by scanning the top block layer. So I
think I can copy a user-created-bitmap and use it
Paolo Bonzini writes:
> On 31/01/19 10:37, Markus Armbruster wrote:
>>>
Hmm, why is it okay to treat all pfl->cmd values the same when
secure=on?
>>> But doesn't matter. You just don't want MMIO mode to be active outside
>>> SMM: all that non-SMM code want to do with the flash is read
A new test file 239 added to the qemu-iotests set. It checks
the output format of 'qemu-img info' for bitmaps extension of
qcow2 specific information.
Signed-off-by: Andrey Shinkevich
---
tests/qemu-iotests/239 | 74 ++
tests/qemu-iotests/239.out | 130
ping
On Thu 17 Jan 2019 04:33:51 PM CET, Alberto Garcia wrote:
> Hi,
>
> here's a patch series to implement a QMP command for bdrv_reopen().
> This is not too different from the previous iteration (RFC v2, see
> changes below), but I'm not tagging it as RFC any longer.
>
> The new command is
This patch adds the support of DISCARD and WRITE ZEROES commands,
that have been introduced in the virtio-blk protocol to have
better performance when using SSD backend.
We support only one segment per request since multiple segments
are not widely used and there are no userspace APIs that allow
We add acct_failed param in order to use virtio_blk_handle_rw_error()
also when is not required to call block_acct_failed(). (eg. a discard
operation is failed)
Signed-off-by: Stefano Garzarella
---
hw/block/virtio-blk.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff
In order to avoid migration issues, we enable DISCARD and
WRITE ZEROES features only for machine type >= 4.0
Suggested-by: Dr. David Alan Gilbert
Signed-off-by: Stefano Garzarella
---
hw/block/virtio-blk.c | 2 ++
hw/core/machine.c | 1 +
include/hw/virtio/virtio-blk.h |
PINGing
Please help!
On 23/01/2019 14:54, Andrey Shinkevich wrote:
> The copy-on-read filter driver is applied to block-stream operations.
> The 'test_stream_parallel' in the file tests/qemu-iotests/030 runs
> jobs that use nodes for streaming in parallel through the backing chain.
> We've got
bdrv_co_invalidate_cache() clears the BDRV_O_INACTIVE flag before
actually activating a node so that the correct permissions etc. are
taken. In case of errors, the flag must be restored so that the next
call to bdrv_co_invalidate_cache() retries activation.
Restoring the flag was missing in the
In the 'Format specific information' section of the 'qemu-img info'
command output, the supplemental information about existing QCOW2
bitmaps will be shown, such as a bitmap name, flags and granularity:
image: /vz/vmprivate/VM1/harddisk.hdd
file format: qcow2
virtual size: 64G (68719476736 bytes)
This series adds the support of DISCARD and WRITE ZEROES commands
and extends the virtio-blk-test to test WRITE_ZEROES command when
the feature is enabled.
v2:
- added patch 1 to use virtio_blk_handle_rw_error() with discard operation
- added patch 2 to make those new features machine-type
On Thu, Jan 31, 2019 at 04:50:46PM +0100, Stefano Garzarella wrote:
> On Thu, Jan 31, 2019 at 03:40:38PM +, Dr. David Alan Gilbert wrote:
> > * Stefano Garzarella (sgarz...@redhat.com) wrote:
> > > In order to avoid migration issues, we enable DISCARD and
> > > WRITE ZEROES features only for
On Thu, Jan 31, 2019 at 11:04:10AM -0500, Michael S. Tsirkin wrote:
> On Thu, Jan 31, 2019 at 04:19:12PM +0100, Stefano Garzarella wrote:
> > This patch adds the support of DISCARD and WRITE ZEROES commands,
> > that have been introduced in the virtio-blk protocol to have
> > better performance
On Thu, Jan 31, 2019 at 04:19:09PM +0100, Stefano Garzarella wrote:
> This series adds the support of DISCARD and WRITE ZEROES commands
> and extends the virtio-blk-test to test WRITE_ZEROES command when
> the feature is enabled.
>
> v2:
> - added patch 1 to use virtio_blk_handle_rw_error() with
On Thu, Jan 31, 2019 at 06:01:34PM +0100, Stefano Garzarella wrote:
> On Thu, Jan 31, 2019 at 11:04:10AM -0500, Michael S. Tsirkin wrote:
> > On Thu, Jan 31, 2019 at 04:19:12PM +0100, Stefano Garzarella wrote:
> > > This patch adds the support of DISCARD and WRITE ZEROES commands,
> > > that have
If the WRITE_ZEROES feature is enabled, we check this command
in the test_basic().
Signed-off-by: Stefano Garzarella
---
tests/virtio-blk-test.c | 60 +
1 file changed, 60 insertions(+)
diff --git a/tests/virtio-blk-test.c b/tests/virtio-blk-test.c
index
The size of data in the virtio_blk_request must be a multiple
of 512 bytes for IN and OUT requests, or a multiple of the size
of struct virtio_blk_discard_write_zeroes for DISCARD and
WRITE_ZEROES requests.
Signed-off-by: Stefano Garzarella
---
tests/virtio-blk-test.c | 15 ++-
1
Some frontend drivers will handle dynamic resizing of PV disks, so set up
the BlockDevOps resize_cb() method during xen_block_realize() to allow
this to be done.
Signed-off-by: Paul Durrant
---
Cc: Stefan Hajnoczi
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Kevin Wolf
Cc: Max Reitz
v3:
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 31 January 2019 15:25
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-block@nongnu.org; xen-
> de...@lists.xenproject.org; Stefan Hajnoczi ; Stefano
> Stabellini ; Kevin Wolf ; Max
> Reitz
>
* Stefano Garzarella (sgarz...@redhat.com) wrote:
> In order to avoid migration issues, we enable DISCARD and
> WRITE ZEROES features only for machine type >= 4.0
>
> Suggested-by: Dr. David Alan Gilbert
> Signed-off-by: Stefano Garzarella
> ---
> hw/block/virtio-blk.c | 2 ++
>
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 31 January 2019 15:21
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-block@nongnu.org; xen-
> de...@lists.xenproject.org; Stefan Hajnoczi ; Stefano
> Stabellini ; Kevin Wolf ; Max
> Reitz
>
* Stefano Garzarella (sgarz...@redhat.com) wrote:
> On Thu, Jan 31, 2019 at 03:40:38PM +, Dr. David Alan Gilbert wrote:
> > * Stefano Garzarella (sgarz...@redhat.com) wrote:
> > > In order to avoid migration issues, we enable DISCARD and
> > > WRITE ZEROES features only for machine type >= 4.0
On Thu, Jan 31, 2019 at 04:19:12PM +0100, Stefano Garzarella wrote:
> This patch adds the support of DISCARD and WRITE ZEROES commands,
> that have been introduced in the virtio-blk protocol to have
> better performance when using SSD backend.
>
> We support only one segment per request since
On Thu, Jan 31, 2019 at 03:22:18PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > Sent: 31 January 2019 15:21
> > To: Paul Durrant
> > Cc: qemu-de...@nongnu.org; qemu-block@nongnu.org; xen-
> > de...@lists.xenproject.org;
On Thu, Jan 31, 2019 at 03:40:38PM +, Dr. David Alan Gilbert wrote:
> * Stefano Garzarella (sgarz...@redhat.com) wrote:
> > In order to avoid migration issues, we enable DISCARD and
> > WRITE ZEROES features only for machine type >= 4.0
> >
> > Suggested-by: Dr. David Alan Gilbert
> >
On Thu, Jan 31, 2019 at 03:33:16PM +, Paul Durrant wrote:
> Some frontend drivers will handle dynamic resizing of PV disks, so set up
> the BlockDevOps resize_cb() method during xen_block_realize() to allow
> this to be done.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Anthony PERARD
On Thu, Jan 31, 2019 at 11:43:07AM -0500, Michael S. Tsirkin wrote:
> On Thu, Jan 31, 2019 at 04:50:46PM +0100, Stefano Garzarella wrote:
> > On Thu, Jan 31, 2019 at 03:40:38PM +, Dr. David Alan Gilbert wrote:
> > > * Stefano Garzarella (sgarz...@redhat.com) wrote:
> > > > In order to avoid
On Thu, Jan 31, 2019 at 12:15:17PM -0500, Michael S. Tsirkin wrote:
> On Thu, Jan 31, 2019 at 04:19:09PM +0100, Stefano Garzarella wrote:
> > This series adds the support of DISCARD and WRITE ZEROES commands
> > and extends the virtio-blk-test to test WRITE_ZEROES command when
> > the feature is
Signed-off-by: Kevin Wolf
---
block/qcow2.h | 3 ++-
block/qcow2-cluster.c | 37 +++--
block/qcow2-refcount.c | 10 +-
3 files changed, 26 insertions(+), 24 deletions(-)
diff --git a/block/qcow2.h b/block/qcow2.h
index a242a43fe7..2cb763bf11
This adds basic constants, struct fields and helper function for
external data file support to the implementation.
QCOW2_INCOMPAT_MASK is not updated yet so that opening images with an
external data file still fails (we don't handle them correctly yet).
Signed-off-by: Kevin Wolf
---
There are use cases where raw images are given (e.g. existing physical
disks), but advanced features like dirty bitmaps or backing files are
wanted that require use of a proper image format like qcow2.
This series adds an incompatible feature bit to qcow2 which allows to
use an external data
This adds a .bdrv_open option to specify the external data file node.
Signed-off-by: Kevin Wolf
---
qapi/block-core.json | 3 ++-
block/qcow2.h| 4 +++-
block/qcow2.c| 25 +++--
3 files changed, 28 insertions(+), 4 deletions(-)
diff --git
Offset 0 can be valid for normal (allocated) clusters now, so use
qcow2_get_cluster_type() instead.
Signed-off-by: Kevin Wolf
---
block/qcow2-cluster.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index
This adds a .bdrv_create option to use an external data file.
Signed-off-by: Kevin Wolf
---
qapi/block-core.json | 1 +
include/block/block_int.h | 1 +
block/qcow2.c | 26 ++
3 files changed, 28 insertions(+)
diff --git a/qapi/block-core.json
84 matches
Mail list logo
