On Wed, Jan 8, 2020 at 7:52 PM Alberto Garcia wrote:
>
> The qcow2 header specifies the virtual size of the image in bytes, but
> BlockDriverState stores it as a number of 512-byte sectors.
>
> If the user tries to create an image with a size that is not a
> multiple of the sector size then this
On Wed, Jan 8, 2020 at 7:50 PM Alberto Garcia wrote:
>
> This replaces all remaining instances in the qcow2 code.
>
> Signed-off-by: Alberto Garcia
> ---
> block/qcow2-cluster.c | 2 +-
> block/qcow2.c | 16 +---
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff
The L1 table is read from disk using the byte-based bdrv_pread() and
is never accessed beyond its last element, so there's no need to
allocate more memory than that.
Signed-off-by: Alberto Garcia
---
block/qcow2-cluster.c | 5 ++---
block/qcow2-refcount.c | 2 +-
block/qcow2-snapshot.c | 3 +--
The qcow2 header specifies the virtual size of the image in bytes, but
BlockDriverState stores it as a number of 512-byte sectors.
If the user tries to create an image with a size that is not a
multiple of the sector size then this is fixed on creation by
silently rounding the image size up (see
This small series gets rid of all the remaining instances of hardcoded
sector sizes in the qcow2 code and adds a check for images whose
virtual size is not a multiple of the sector size.
See the individual patches for details.
Berto
Alberto Garcia (3):
qcow2: Require that the virtual size is
This replaces all remaining instances in the qcow2 code.
Signed-off-by: Alberto Garcia
---
block/qcow2-cluster.c | 2 +-
block/qcow2.c | 16 +---
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index
From: Chen Qun
The accel_list forgot to free, the asan output:
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x919331cb in __interceptor_malloc (/lib64/libasan.so.4+0xd31cb)
#1 0x913f7163 in g_malloc (/lib64/libglib-2.0.so.0+0x57163)
#2 0x91413d9b in
From: Pan Nengyuan
spotted by ASAN
Fixes: 81d8ccb1bea4fb9eaaf4c8e30bd4021180a9a39f
Reported-by: Euler Robot
Signed-off-by: Pan Nengyuan
Reviewed-by: Markus Armbruster
Message-Id: <1576805650-16380-1-git-send-email-pannengy...@huawei.com>
Signed-off-by: Laurent Vivier
---
util/module.c | 1
From: Pan Nengyuan
Fixes:
target/arm/translate-a64.c: In function 'disas_crypto_three_reg_sha512':
target/arm/translate-a64.c:13625:9: error: 'genfn' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
genfn(tcg_rd_ptr, tcg_rn_ptr, tcg_rm_ptr);
From: Yuval Shaia
Use gmail account for maintainer tasks.
Signed-off-by: Yuval Shaia
Acked-by: Marcel Apfelbaum
Message-Id: <20191126102637.2038-1-yuval.sh...@oracle.com>
Signed-off-by: Laurent Vivier
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Pan Nengyuan
Fixes:
/mnt/sdb/qemu/nbd/server.c: In function 'nbd_handle_request':
/mnt/sdb/qemu/nbd/server.c:2313:9: error: 'ret' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
int ret;
Reported-by: Euler Robot
Signed-off-by: Pan Nengyuan
Reviewed-by:
The following changes since commit 035eed4c0d257c905a556fa0f4865a0c077b4e7f:
Merge remote-tracking branch 'remotes/vivier/tags/q800-for-5.0-pull-request'
into staging (2020-01-07 17:08:21 +)
are available in the Git repository at:
git://github.com/vivier/qemu.git
Le 08/01/2020 à 03:51, pannengy...@huawei.com a écrit :
> From: Pan Nengyuan
>
> Fixes:
> /mnt/sdb/qemu/nbd/server.c: In function 'nbd_handle_request':
> /mnt/sdb/qemu/nbd/server.c:2313:9: error: 'ret' may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> int ret;
>
Marking without waiting would not result in actual serialising behavior.
Thus, make a call bdrv_mark_request_serialising sufficient for
serialisation to happen.
Signed-off-by: Paolo Bonzini
---
block/file-posix.c| 1 -
block/io.c| 40
It is unused since commit 00e30f0 ("block/backup: use backup-top instead
of write notifiers", 2019-10-01), drop it to simplify the code.
While at it, drop redundant assertions on flags.
Signed-off-by: Paolo Bonzini
---
block/io.c| 18 --
include/block/block.h | 12
bdrv_mark_request_serialising is writing the overlap_offset and
overlap_bytes fields of BdrvTrackedRequest. Take bs->reqs_lock
for the whole duration of it, and not just when waiting for
serialising requests, so that tracked_request_overlaps does not
look at a half-updated request.
The new code
Peter Lieven noticed that reqs->overlap_offset and reqs->overlap_bytes
are written outside bs->reqs_lock. Patch 3 fixes it, while patches 1
and 2 are preparatory cleanups.
v1->v2: fix comment in patch 2, commit message in patch 3 [Kevin]
Paolo Bonzini (3):
block: eliminate
All paths that lead to bdrv_backup_top_drop(), except for the call
from backup_clean(), imply that the BDS AioContext has already been
acquired, so doing it there too can potentially lead to QEMU hanging
on AIO_WAIT_WHILE().
An easy way to trigger this situation is by issuing a two actions
Includes the following tests:
- Adding a dirty bitmap.
* RHBZ: 1782175
- Starting a drive-mirror to an NBD-backed target.
* RHBZ: 1746217, 1773517
- Aborting an external snapshot transaction.
* RHBZ: 1779036
- Aborting a blockdev backup transaction.
* RHBZ: 1782111
For each
external_snapshot_abort() calls to bdrv_set_backing_hd(), which
returns state->old_bs to the main AioContext, as it's intended to be
used then the BDS is going to be released. As that's not the case when
aborting an external snapshot, return it to the AioContext it was
before the call.
This issue
Fix a couple of minor coding style issues in drive_backup_prepare.
Signed-off-by: Sergio Lopez
Reviewed-by: Max Reitz
Reviewed-by: Kevin Wolf
---
blockdev.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 8e029e9c01..553e315972 100644
This patch series includes fixes for various issues related to
AioContext mismanagement for various blockdev-initiated actions.
It also adds tests for those actions when executed on drives running
on an IOThread AioContext.
---
Changelog:
v6:
- Rename the patch series.
- Add
Dirty map addition and removal functions are not acquiring to BDS
AioContext, while they may call to code that expects it to be
acquired.
This may trigger a crash with a stack trace like this one:
#0 0x7f0ef146370f in __GI_raise (sig=sig@entry=6)
at
bdrv_try_set_aio_context() requires that the old context is held, and
the new context is not held. Fix all the occurrences where it's not
done this way.
Suggested-by: Max Reitz
Signed-off-by: Sergio Lopez
---
blockdev.c | 68 +++---
1 file
Issuing a blockdev-backup from qmp_blockdev_backup takes a slightly
different path than when it's issued from a transaction. In the code,
this is manifested as some redundancy between do_blockdev_backup() and
blockdev_backup_prepare().
This change unifies both paths, merging do_blockdev_backup()
Issuing a drive-backup from qmp_drive_backup takes a slightly
different path than when it's issued from a transaction. In the code,
this is manifested as some redundancy between do_drive_backup() and
drive_backup_prepare().
This change unifies both paths, merging do_drive_backup() and
On 08/01/2020 14.24, Paolo Bonzini wrote:
> On 08/01/20 14:10, Daniel P. Berrangé wrote:
>> On Wed, Jan 08, 2020 at 01:41:59PM +0100, Paolo Bonzini wrote:
>>> On 08/01/20 11:58, Thomas Huth wrote:
> "-accel default" could be considered to have vibes of Do The Right
> Thing (tm) and could
On 08/01/20 14:10, Daniel P. Berrangé wrote:
> On Wed, Jan 08, 2020 at 01:41:59PM +0100, Paolo Bonzini wrote:
>> On 08/01/20 11:58, Thomas Huth wrote:
"-accel default" could be considered to have vibes of Do The Right
Thing (tm) and could in time actually become so!
>>>
>>> "-accel
On Wed, Jan 08, 2020 at 01:41:59PM +0100, Paolo Bonzini wrote:
> On 08/01/20 11:58, Thomas Huth wrote:
> >> "-accel default" could be considered to have vibes of Do The Right
> >> Thing (tm) and could in time actually become so!
> >
> > "-accel default" sounds like the default behavior that you'd
On 08/01/20 11:58, Thomas Huth wrote:
>> "-accel default" could be considered to have vibes of Do The Right
>> Thing (tm) and could in time actually become so!
>
> "-accel default" sounds like the default behavior that you'd also get if
> you don't use this option at all ... what about "-accel
Patchew URL:
https://patchew.org/QEMU/20200108112220.499180-1-stefa...@redhat.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN
Add qemu-img measure support in the "luks" block driver.
Signed-off-by: Stefan Hajnoczi
---
block/crypto.c | 82 ++
1 file changed, 82 insertions(+)
diff --git a/block/crypto.c b/block/crypto.c
index ed32202fa2..94a24210ab 100644
---
The qcow2 .bdrv_measure() code calculates the crypto payload offset.
This logic really belongs in block/crypto.c where it can be reused by
other image formats.
The "luks" block driver will need this same logic in order to implement
.bdrv_measure(), so extract the
In most qemu-img sub-commands the --object option only makes sense when
there is a filename. qemu-img measure is an exception because objects
may be referenced from the image creation options instead of an existing
image file. Allow --object without a filename.
Signed-off-by: Stefan Hajnoczi
This test exercises the block/crypto.c "luks" block driver
.bdrv_measure() code.
Signed-off-by: Stefan Hajnoczi
---
tests/qemu-iotests/282 | 93 ++
tests/qemu-iotests/282.out | 30
tests/qemu-iotests/group | 1 +
3 files changed, 124
This patch series adds qemu-img measure support to the "luks" block driver. We
just need to take into account the LUKS header when sizing the image.
Stefan Hajnoczi (4):
luks: extract block_crypto_calculate_payload_offset()
luks: implement .bdrv_measure()
qemu-img: allow qemu-img measure
On Wed, 8 Jan 2020 at 10:40, Alex Bennée wrote:
> Thomas Huth writes:
> > What about "-accel any" or "-accel fastest" or something similar?
>
> "any" is just ambiguous, "fastest" is just begging for me to find a
> micro-benchmark that TCG outperforms on ;-)
>
> "-accel default" could be
On 08/01/2020 11.39, Alex Bennée wrote:
>
> Thomas Huth writes:
>
>> On 07/01/2020 13.54, Daniel P. Berrangé wrote:
>>> On Tue, Jan 07, 2020 at 01:23:18PM +0100, Paolo Bonzini wrote:
On 07/01/20 13:18, Thomas Huth wrote:
> I don't think we need a separate priority parameter here. But
Thomas Huth writes:
> On 07/01/2020 13.54, Daniel P. Berrangé wrote:
>> On Tue, Jan 07, 2020 at 01:23:18PM +0100, Paolo Bonzini wrote:
>>> On 07/01/20 13:18, Thomas Huth wrote:
I don't think we need a separate priority parameter here. But IMHO it's
really rather common practice to
Am 07.01.2020 um 18:43 hat Christophe de Dinechin geschrieben:
> > It would break backwards compatibility for "-machine accel=tcg:kvm",
> > which so far meant "use TCG if compiled in, otherwise use KVM". This is
> > not something I would have a problem with... except that "tcg:kvm" is
> > the
Am 07.01.2020 um 23:39 hat Alexander Popov geschrieben:
> > Did you have a look why this happens? I suppose we might be running out
> > of some resources in the qtest framework becasue each send_dma_request()
> > calls get_pci_device() again?
>
> I've spent some time on investigating, but didn't
41 matches
Mail list logo
