Am 19.02.2019 um 07:44 hat Thomas Huth geschrieben:
> On 18/02/2019 19.22, Cleber Rosa wrote:
> >
> >
> > On 2/13/19 6:54 AM, Thomas Huth wrote:
> >> This is very convenient for people like me who store their QEMU git trees
> >> on gitlab.com: Automatic CI pipelines are now run for each branch th
Problem reproduced with virtio-scsi as well on the same guest, this time it
took less than a day.
Information from the log file:
vdev 0x55823f119f90 ("virtio-scsi")
vq 0x55823f122e80 (idx 2)
inuse 128 vring.num 128
old_shadow_avail_idx 58367 last_avail_idx 58113 avail_idx 58367
avail 0x3de8a800 a
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? I
On 18/02/2019 19.22, Cleber Rosa wrote:
>
>
> On 2/13/19 6:54 AM, Thomas Huth wrote:
>> This is very convenient for people like me who store their QEMU git trees
>> on gitlab.com: Automatic CI pipelines are now run for each branch that is
>> pushed to the server - useful for some extra-testing be
Hi Eric, hi Daniel,
QEMU iotest 233 is failing for me on RHEL7:
233[07:29:30] [07:29:30] [failed, exit status 1] - output
mismatch (see 233.out.bad)
--- /home/thuth/devel/qemu/tests/qemu-iotests/233.out 2019-02-19
07:14:45.0 +0100
+++ /home/thuth/tmp/qemu-build/test
Laszlo Ersek writes:
> On 02/18/19 18:01, Laszlo Ersek wrote:
>> On 02/18/19 13:56, Markus Armbruster wrote:
>>> QOMification left parameter @size unused in pflash_cfi01_register()
>>> and pflash_cfi02_register(). register(). Obviously, @size should
>
> I meant to point out the typo above, but
Patchew URL: https://patchew.org/QEMU/20190218125615.18970-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190218125615.18970-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH 00/10] pflash: Fixes and cleanups
T
Patchew URL: https://patchew.org/QEMU/20190218125615.18970-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190218125615.18970-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH 00/10] pflash: Fixes and cleanups
T
Thank you for replying.
Well i am using latest PROXMOX in a cluster of 4 physical servers.
during the weekend i had to stop all hosts because electricians had to
work on the fuse box.
i shutted down all vm's then powered off all physical hosts. One of them
took very long.
this host had a raid5 of
On Mon, Feb 18, 2019 at 01:56:10PM +0100, Markus Armbruster wrote:
> Machine "ref405ep" maps its flash memory at address 2^32 - image size.
> Image size is rounded up to the next multiple of 64KiB. Useless,
> because pflash_cfi02_realize() fails with "failed to read the initial
> flash content" un
On 31.01.19 18:55, Kevin Wolf wrote:
> 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 q
On 31.01.19 18:55, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf
> ---
> qapi/block-core.json | 1 +
> block/qcow2.c| 6 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
[...]
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 4959bf16a4..e3427f9fcd 100644
> --- a/block/qcow2.
On 2/18/19 12:46 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:36, John Snow wrote:
>> Add an inconsistent bit to dirty-bitmaps that allows us to report a bitmap as
>> persistent but potentially inconsistent, i.e. if we find bitmaps on a qcow2
>> that have been marked as "in use".
>>
>>
On 31.01.19 18:55, 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.
>
> Signed-off-by:
On 31.01.19 18:55, 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 inserti
On 2/18/19 3:37 PM, Eric Blake wrote:
> On 2/18/19 12:13 PM, Vladimir Sementsov-Ogievskiy wrote:
>> 14.02.2019 2:36, John Snow wrote:
>>> Signed-off-by: John Snow
>>> ---
>>> block/dirty-bitmap.c | 15 +
>>> block/qcow2-bitmap.c | 42 ++
On 31.01.19 18:55, Kevin Wolf wrote:
> 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 d
When bitmaps are persistent, they may incur a disk read or write when bitmaps
are added or removed. For configurations like virtio-dataplane, failing to
acquire this lock will abort QEMU when disk IO occurs.
We used to acquire aio_context as part of the bitmap lookup, so re-introduce
the lock for
On 2/18/19 11:39 AM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> Currently, enabled means something like "the status of the bitmap
>> is ACTIVE." After this patch, it should mean exclusively: "This
>> bitmap is recording guest writes, and is allowed to do so."
>>
>
On 31.01.19 18:55, Kevin Wolf wrote:
> 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 al
On 2/18/19 12:27 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> These mean the same thing now. Unify them and rename the merged call
>> bdrv_dirty_bitmap_busy to indicate semantically what we are describing,
>> as well as help disambiguate from the various _locked
On 2/18/19 8:57 AM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> "Frozen" was a good description a long time ago, but it isn't adequate now.
>> Rename the frozen predicate to has_successor to make the semantics of the
>> predicate more clear to outside callers.
>>
>
On 2/18/19 4:55 PM, Eric Blake wrote:
> On 2/18/19 3:42 PM, John Snow wrote:
>> When bitmaps are persistent, they may incur a disk read or write when bitmaps
>> are added or removed. For configurations like virtio-dataplane, failing to
>> acquire this lock will abort QEMU when disk IO occurs.
>>
On 2/18/19 12:39 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> Simply move the big status enum comment block to above the status
>> function, and document it as being deprecated. The whole confusing
>> block can get deleted in three releases time.
>>
>> Signed-of
On 2/18/19 11:52 AM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> Instead of implying a locked status, make it explicit.
>
> locked interferes with bitmap mutex, so may be better "qmp_locked state", but
> not sure.
>
I agree that "locked" has too many meanings,
On 2/18/19 3:42 PM, John Snow wrote:
> When bitmaps are persistent, they may incur a disk read or write when bitmaps
> are added or removed. For configurations like virtio-dataplane, failing to
> acquire this lock will abort QEMU when disk IO occurs.
>
> We used to acquire aio_context as part of t
When bitmaps are persistent, they may incur a disk read or write when bitmaps
are added or removed. For configurations like virtio-dataplane, failing to
acquire this lock will abort QEMU when disk IO occurs.
We used to acquire aio_context as part of the bitmap lookup, so re-introduce
the lock for
See patch for details.
V4: Embarrassingly, fix a missing semicolon;
V3: Add signed-off-by. My script went a bit haywire,
so this one's for posterity.
John Snow (1):
blockdev: acquire aio_context for bitmap add/remove
blockdev.c | 26 --
1 file changed, 20 insertion
On 2/18/19 9:05 PM, Eric Blake wrote:
> [adding Eduardo for some python 2-vs-3 advice]
And Cleber.
>
> On 2/18/19 1:59 PM, Andrey Shinkevich wrote:
>> To write one byte to disk, Python2 may use 'chr' type.
>> In Python3, conversion to 'byte' type is required.
>>
>> Signed-off-by: Andrey Shinkevi
On 2/18/19 7:06 PM, Max Reitz wrote:
> VDI keeps the whole bitmap in memory, and the maximum size (which is
> tested here) is 2 GB. This may not be available on all machines, and it
> rarely is available when running a 32 bit build.
>
> Fix this by making VM.run_job() return the error string if a
On 2/18/19 12:06 PM, Max Reitz wrote:
> VDI keeps the whole bitmap in memory, and the maximum size (which is
> tested here) is 2 GB. This may not be available on all machines, and it
> rarely is available when running a 32 bit build.
>
> Fix this by making VM.run_job() return the error string if
On 2/16/19 10:54 PM, Alexander Marx wrote:
> Dear List!
>
> I have a big problem and hope you can help me.
> I built a new windows 2016 domain with virtual servers. 2 dc and 9 rds
> hosts.
> I was nearly finished with the setup and ready to migrate the users from
> old to new domain.
>
> Then
On 2/18/19 10:18 AM, Kevin Wolf wrote:
> aio_poll() has an existing assertion that the function is only called
> from the AioContext's home thread if blocking is allowed.
>
> This is not enough, some handlers make assumptions about the thread they
> run in. Extend the assertion to non-blocking cal
On 2/18/19 10:18 AM, Kevin Wolf wrote:
> Now that bdrv_set_aio_context() works inside drained sections, it can
> also use the real drain function instead of open coding something
> similar.
>
> Signed-off-by: Kevin Wolf
> ---
> block.c | 14 +-
> 1 file changed, 5 insertions(+), 9 de
On 2/18/19 10:18 AM, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf
> ---
> tests/test-bdrv-drain.c | 32
> 1 file changed, 32 insertions(+)
Reviewed-by: Eric Blake
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualizatio
On 2/18/19 10:18 AM, Kevin Wolf wrote:
> When a drained node changes its AioContext, we need to move its
> aio_disable_external() to the new context, too.
>
> Without this fix, drain_end will try to reenable the new context, which
> has never been disabled, so an assertion failure is triggered.
>
On 2/18/19 10:18 AM, Kevin Wolf wrote:
> The explicit aio_poll() call in bdrv_set_aio_context() was added in
> commit c2b6428d388 as a workaround for bdrv_drain() failing to achieve
> to actually quiesce everything (specifically the NBD client code to
> switch AioContext).
>
> Now that the NBD cli
On 2/18/19 10:18 AM, Kevin Wolf wrote:
> Instead of using the convenience wrapper qio_channel_read_all_eof(), use
> the lower level QIOChannel API. This means duplicating some code, but
> we'll need this because this coroutine yield is special: We want it to
> be interruptible so that nbd_client_at
On 2/18/19 10:18 AM, Kevin Wolf wrote:
> The only caller of nbd_read_eof() is nbd_receive_reply(), so it doesn't
> have to live in the header file, but can move next to its caller.
>
> Also add the missing coroutine_fn to the function and its caller.
>
> Signed-off-by: Kevin Wolf
> ---
> includ
On 2/18/19 12:13 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:36, John Snow wrote:
>> Signed-off-by: John Snow
>> ---
>> block/dirty-bitmap.c | 15 +
>> block/qcow2-bitmap.c | 42 ++-
>> blockdev.c | 43 +++
On 2/18/19 10:18 AM, Kevin Wolf wrote:
> Similar to how qemu_co_sleep_ns() allows to be preempted by an external
allows preemption from an external
> coroutine entry, allow reentering qio_channel_yield() early.
>
> Signed-off-by: Kevin Wolf
> ---
> include/io/channel.h | 9 ++---
> io/cha
On 2/18/19 10:18 AM, Kevin Wolf wrote:
> nbd_client_attach_aio_context() schedules connection_co in the new
> AioContext and this way reenters it in any arbitrary place that has
> yielded. We can restrict this a bit to the function call where the
> coroutine actually sits waiting when it's idle.
>
On 2/18/19 8:09 AM, Vladimir Sementsov-Ogievskiy wrote:
> Add a possibility of embedded iovec, for cases when we need only one
> local iov.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> include/qemu/iov.h | 64 --
> 1 file changed, 62 inserti
[adding Eduardo for some python 2-vs-3 advice]
On 2/18/19 1:59 PM, Andrey Shinkevich wrote:
> To write one byte to disk, Python2 may use 'chr' type.
> In Python3, conversion to 'byte' type is required.
>
> Signed-off-by: Andrey Shinkevich
> ---
> tests/qemu-iotests/242 | 9 +++--
> 1 file c
To write one byte to disk, Python2 may use 'chr' type.
In Python3, conversion to 'byte' type is required.
Signed-off-by: Andrey Shinkevich
---
tests/qemu-iotests/242 | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tests/qemu-iotests/242 b/tests/qemu-iotests/242
index
On 18/02/2019 19:12, Kevin Wolf wrote:
> Am 08.02.2019 um 16:06 hat Andrey Shinkevich geschrieben:
>> A new test file 242 added to the qemu-iotests set. It checks
>> the format of qcow2 specific information for the new added
>> section that lists details of bitmaps.
>>
>> Signed-off-by: Andrey Sh
On Wed, Feb 06, 2019 at 11:29:01AM -0500, Cleber Rosa wrote:
> This is a simple move of Python code that wraps common QEMU
> functionality, and are used by a number of different tests
> and scripts.
>
> By treating that code as a real Python module, we can more easily:
> * reuse code
> * have a
14.02.2019 2:36, John Snow wrote:
> Signed-off-by: John Snow
> ---
> block/dirty-bitmap.c | 15 +
> block/qcow2-bitmap.c | 42 ++-
> blockdev.c | 43
> include/block/dirty-bitmap
14.02.2019 2:36, John Snow wrote:
> Allow QEMU to read in bitmaps that have the in-use bit set, for the
> purposes of allowing users to clear or reset these bitmaps.
>
> This is chosen in preference to a hard error on load to minimize
> impact for a non-critical error, but to force the user or man
VDI keeps the whole bitmap in memory, and the maximum size (which is
tested here) is 2 GB. This may not be available on all machines, and it
rarely is available when running a 32 bit build.
Fix this by making VM.run_job() return the error string if an error
occurred, and checking whether that con
On 2/8/19 11:01 PM, Cleber Rosa wrote:
> Besides the obvious reasons of testing more, and somewhat for free,
> running the qemu-iotests along the other tests on Travis also makes
> sure that changes to shared code such as "scripts/qemu.py" and the
> like won't break other users of the same code.
On 02/18/19 18:01, Laszlo Ersek wrote:
> On 02/18/19 13:56, Markus Armbruster wrote:
>> QOMification left parameter @size unused in pflash_cfi01_register()
>> and pflash_cfi02_register(). register(). Obviously, @size should
I meant to point out the typo above, but I got distracted mid-review. So
14.02.2019 2:36, John Snow wrote:
> Add an inconsistent bit to dirty-bitmaps that allows us to report a bitmap as
> persistent but potentially inconsistent, i.e. if we find bitmaps on a qcow2
> that have been marked as "in use".
>
> Signed-off-by: John Snow
> ---
> block/dirty-bitmap.c
On 18.02.19 11:45, Stefan Hajnoczi wrote:
> v3:
> * Use encrypt.iter-time=10 to speed up qemu-iotests 178 [Max]
Thanks!
> v2:
> * Take into account all "encrypt." image creation options since the LUKS
>payload size varies depending on the cipher [Max]
>
> The LUKS payload has a significant
Patchew URL: https://patchew.org/QEMU/20190218125615.18970-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190218125615.18970-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH 00/10] pflash: Fixes and cleanups
T
14.02.2019 2:23, John Snow wrote:
> Simply move the big status enum comment block to above the status
> function, and document it as being deprecated. The whole confusing
> block can get deleted in three releases time.
>
> Signed-off-by: John Snow
Reviewed-by: Vladimir Sementsov-Ogievskiy
But
Laszlo Ersek writes:
> On 02/18/19 13:56, Markus Armbruster wrote:
>> PFLASH_BUG()'s lone use has a suspicious smell: it prints "Possible
>> BUG", which sounds like a warning, then calls exit(1), followed by
>> unreachable goto reset_flash. All this commit does is expanding the
>> macro, so the
14.02.2019 2:23, John Snow wrote:
> These mean the same thing now. Unify them and rename the merged call
> bdrv_dirty_bitmap_busy to indicate semantically what we are describing,
> as well as help disambiguate from the various _locked and _unlocked
> versions of bitmap helpers that refer to mutex l
On 18/02/19 17:18, Kevin Wolf wrote:
> +/* aio_ctx_switch is only supposed to be set if we're sitting in
> + * the qio_channel_yield() below. */
> +assert(!*aio_ctx_switch);
> bdrv_dec_in_flight(bs);
> qio_channel_yield(ioc, G_IO_IN);
>
Patchew URL: https://patchew.org/QEMU/20190218125615.18970-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190218125615.18970-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH 00/10] pflash: Fixes and cleanups
T
On 02/18/19 13:56, Markus Armbruster wrote:
> pflash_cfi01_register() creates a TYPE_CFI_PFLASH01 device, sets
> properties, realizes, and wires up.
>
> We have three modified copies of it, because their users need to set
> additional properties, or have the wiring done differently.
>
> Factor ou
On 18/02/19 17:18, Kevin Wolf wrote:
> Similar to how qemu_co_sleep_ns() allows to be preempted by an external
> coroutine entry, allow reentering qio_channel_yield() early.
>
> Signed-off-by: Kevin Wolf
> ---
> include/io/channel.h | 9 ++---
> io/channel.c | 10 ++
> 2 fil
18.02.2019 16:57, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> "Frozen" was a good description a long time ago, but it isn't adequate now.
>> Rename the frozen predicate to has_successor to make the semantics of the
>> predicate more clear to outside callers.
>>
>> In
On 02/18/19 13:56, Markus Armbruster wrote:
> QOMification left parameter @size unused in pflash_cfi01_register()
> and pflash_cfi02_register(). register(). Obviously, @size should
> match @sector_len and @nb_blocs, i.e. size == sector_len * nb_blocs.
> All callers satisfy this.
>
> Remove @nb_b
14.02.2019 2:23, John Snow wrote:
> Instead of implying a locked status, make it explicit.
locked interferes with bitmap mutex, so may be better "qmp_locked state", but
not sure.
> Now, bitmaps in use by migration, NBD or backup operations
> are all treated the same way with the same code paths.
On 02/18/19 13:56, Markus Armbruster wrote:
> QOMification left parameter @qdev unused in pflash_cfi01_register()
> and pflash_cfi02_register(). All callers pass NULL. Remove.
>
> Signed-off-by: Markus Armbruster
> ---
> hw/arm/collie.c | 4 ++--
> hw/arm/digic_boards.
On 02/18/19 13:56, Markus Armbruster wrote:
> We have two open-coded copies of macro CFI_PFLASH01(). Move the macro
> to the header, so we can ditch the copies. Move CFI_PFLASH02() to the
> header for symmetry.
>
> We define macros TYPE_CFI_PFLASH01 and TYPE_CFI_PFLASH02 for type name
> strings,
On 02/18/19 13:56, Markus Armbruster wrote:
> PFLASH_BUG()'s lone use has a suspicious smell: it prints "Possible
> BUG", which sounds like a warning, then calls exit(1), followed by
> unreachable goto reset_flash. All this commit does is expanding the
> macro, so the smell becomes more poignant,
On 02/18/19 13:56, Markus Armbruster wrote:
> flash.h's incomplete struct pflash_t is completed both in
> pflash_cfi01.c and in pflash_cfi02.c. The complete types are
> incompatible.
O_o
> This can hide type errors, such as passing a pflash_t
> created with pflash_cfi02_register() to pflash_cfi0
14.02.2019 2:23, John Snow wrote:
> Currently, enabled means something like "the status of the bitmap
> is ACTIVE." After this patch, it should mean exclusively: "This
> bitmap is recording guest writes, and is allowed to do so."
>
> In many places, this is how this predicate was already used.
> W
Now that bdrv_set_aio_context() works inside drained sections, it can
also use the real drain function instead of open coding something
similar.
Signed-off-by: Kevin Wolf
---
block.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/block.c b/block.c
index aefb57
Signed-off-by: Kevin Wolf
---
tests/test-bdrv-drain.c | 32
1 file changed, 32 insertions(+)
diff --git a/tests/test-bdrv-drain.c b/tests/test-bdrv-drain.c
index ee1740ff06..1b1f6c17a5 100644
--- a/tests/test-bdrv-drain.c
+++ b/tests/test-bdrv-drain.c
@@ -1522,6
bdrv_drain() must not leave connection_co scheduled, so bs->in_flight
needs to be increased while the coroutine is waiting to be scheduled
in the new AioContext after nbd_client_attach_aio_context().
Signed-off-by: Kevin Wolf
---
block/nbd-client.h | 1 +
include/block/nbd.h | 5 +++--
block/
aio_poll() has an existing assertion that the function is only called
from the AioContext's home thread if blocking is allowed.
This is not enough, some handlers make assumptions about the thread they
run in. Extend the assertion to non-blocking calls, too.
Signed-off-by: Kevin Wolf
---
util/ai
nbd_client_attach_aio_context() schedules connection_co in the new
AioContext and this way reenters it in any arbitrary place that has
yielded. We can restrict this a bit to the function call where the
coroutine actually sits waiting when it's idle.
This doesn't solve any bug yet, but it shows whe
Similar to how qemu_co_sleep_ns() allows to be preempted by an external
coroutine entry, allow reentering qio_channel_yield() early.
Signed-off-by: Kevin Wolf
---
include/io/channel.h | 9 ++---
io/channel.c | 10 ++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --
Background for this series is the following bug report, which is about a
crash with virtio-blk + iothread and request resubmission for werror/rerror:
https://bugzilla.redhat.com/show_bug.cgi?id=1671173
The reason is that bdrv_set_aio_context() didn't correctly quiesce
everything. Instead, it had
Instead of using the convenience wrapper qio_channel_read_all_eof(), use
the lower level QIOChannel API. This means duplicating some code, but
we'll need this because this coroutine yield is special: We want it to
be interruptible so that nbd_client_attach_aio_context() can correctly
reenter the co
The explicit aio_poll() call in bdrv_set_aio_context() was added in
commit c2b6428d388 as a workaround for bdrv_drain() failing to achieve
to actually quiesce everything (specifically the NBD client code to
switch AioContext).
Now that the NBD client has been fixed to complete this operation durin
The only caller of nbd_read_eof() is nbd_receive_reply(), so it doesn't
have to live in the header file, but can move next to its caller.
Also add the missing coroutine_fn to the function and its caller.
Signed-off-by: Kevin Wolf
---
include/block/nbd.h | 3 ++-
nbd/nbd-internal.h | 19 --
When a drained node changes its AioContext, we need to move its
aio_disable_external() to the new context, too.
Without this fix, drain_end will try to reenable the new context, which
has never been disabled, so an assertion failure is triggered.
Signed-off-by: Kevin Wolf
---
block.c | 7 ++
virtio_blk_dma_restart_bh() submits new requests, so in order to make
sure that these requests are not started inside a drained section of the
attached BlockBackend, we need to make sure that draining the
BlockBackend waits for the BH to be executed.
This BH is still questionable because its sched
For some users of BlockBackends, just increasing the in_flight counter
is easier than implementing separate handlers in BlockDevOps. Make the
helper functions for this public.
Signed-off-by: Kevin Wolf
---
include/sysemu/block-backend.h | 2 ++
block/block-backend.c | 4 ++--
2 files ch
Am 08.02.2019 um 16:06 hat Andrey Shinkevich geschrieben:
> A new test file 242 added to the qemu-iotests set. It checks
> the format of qcow2 specific information for the new added
> section that lists details of bitmaps.
>
> Signed-off-by: Andrey Shinkevich
This doesn't seem to be Python 3 com
On Fri, Feb 15, 2019 at 04:25:33PM +, Paul Durrant wrote:
> The function needs to make sure it is passed a valid disk name. This is
> easily done by making sure that the parsing loop results in a non-zero
> value.
>
> Spotted by Coverity: CID 1398640
>
> Reported-by: Peter Maydell
> Signed-o
12.02.2019 15:35, Andrey Shinkevich wrote:
> Clean QCOW2 image from bitmap obsolete directory when a new one
> is allocated and stored. It slows down the image growth a little bit.
> The flag QCOW2_DISCARD_ALWAYS allows a call to raw_co_pdiscard()
> that does the actual cleaning of the image on dis
Patchew URL:
https://patchew.org/QEMU/20190218140301.197408-1-sgarz...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190218140301.197408-1-sgarz...@redhat.com
Subject: [Qemu-devel] [PATCH v5 00/10] virtio-blk: add DI
On Fri, Feb 15, 2019 at 04:25:32PM +, Paul Durrant wrote:
> The assignment to 'p' is unnecessary as the code will either goto 'invalid'
> or p will get overwritten.
>
> Spotted by Coverity: CID 1398638
>
> Reported-by: Peter Maydell
> Signed-off-by: Paul Durrant
Acked-by: Anthony PERARD
Use new qemu_iovec_init_buf() instead of
qemu_iovec_init_external( ... , 1), which simplifies the code.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
block/vmdk.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/bl
Use new QEMU_IOVEC_INIT_BUF() instead of
qemu_iovec_init_external( ... , 1), which simplifies the code.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
tests/test-bdrv-drain.c | 29 -
1 file changed, 4 insertions(
Hi all!
Here is a new simple helper for a very often patter
around qemu_iovec_init_external, when we need simple qiov with only
one iov, initialized from external buffer.
v4:
01: tiny improvements by Eric
+ fix bug: s/niov/nalloc in assertion
+ rename s/qemu_iovec_get_buf/qemu_iovec_bu
Use new qemu_iovec_init_buf() instead of
qemu_iovec_init_external( ... , 1), which simplifies the code.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
block/qed-table.c | 16 +++-
block/qed.c | 31 +
Use new QEMU_IOVEC_INIT_BUF() instead of
qemu_iovec_init_external( ... , 1), which simplifies the code.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
block/commit.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/
On Fri, Feb 15, 2019 at 09:38:59PM +0100, Philippe Mathieu-Daudé wrote:
> On 2/15/19 5:25 PM, Paul Durrant wrote:
> > The if() statement is clearly bogus (dead code which should have been
> > cleaned up when grant mapping was removed).
>
> "... was removed in 06454c24ad)."
Actually, it looks like
Use new qemu_iovec_init_buf() instead of
qemu_iovec_init_external( ... , 1), which simplifies the code.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
block/backup.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/bl
Use new qemu_iovec_init_buf() instead of
qemu_iovec_init_external( ... , 1), which simplifies the code.
While being here, use qemu_try_blockalign0 as well.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
block/io.c | 89
Use new QEMU_IOVEC_INIT_BUF() instead of
qemu_iovec_init_external( ... , 1), which simplifies the code.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
block/parallels.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
di
Use new QEMU_IOVEC_INIT_BUF() instead of
qemu_iovec_init_external( ... , 1), which simplifies the code.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
block/stream.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/
Use new qemu_iovec_init_buf() instead of
qemu_iovec_init_external( ... , 1), which simplifies the code.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
migration/block.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff
@iov is used only to initialize @qiov. Let's use new
qemu_iovec_init_buf() instead, which simplifies the code.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
include/hw/ide/internal.h | 1 -
hw/ide/atapi.c| 5 ++---
2 files chan
1 - 100 of 141 matches
Mail list logo