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
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
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?
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
+++
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
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
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 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
> ---
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.
>
>
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
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
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
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
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.
>>
>>
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
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
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
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/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
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
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
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
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
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
> ---
>
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:
> 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
[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
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
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
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
>
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
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
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.
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
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
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
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
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
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
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
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.
>
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
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 +++--
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
---
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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(-)
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
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
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
---
qemu-img.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git
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/qcow2.c | 12 ++--
1 file changed, 2 insertions(+), 10 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| 9 -
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/block-backend.c | 13 ++---
1 file changed, 2 insertions(+), 11
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 insertions(+), 2 deletions(-)
diff --git a/include/qemu/iov.h
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/qcow.c | 21 -
1 file changed, 4 insertions(+), 17
@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/core.c | 11 ++-
2
If the DISCARD feature is enabled, we try this command in the
test_basic(), checking only the status returned by the request.
Signed-off-by: Stefano Garzarella
---
tests/virtio-blk-test.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/tests/virtio-blk-test.c
If the WRITE_ZEROES feature is enabled, we check this command
in the test_basic().
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
Acked-by: Thomas Huth
Signed-off-by: Stefano Garzarella
---
tests/virtio-blk-test.c | 62 +
1 file changed,
In order to use VirtIOFeature also in other virtio devices, we move
its declaration and the endof() macro (renamed in virtio_endof())
in virtio.h.
We add virtio_feature_get_config_size() function to iterate the array
of VirtIOFeature and to return the config size depending on the
features enabled.
This function is useful to fix the endianness of struct
virtio_blk_discard_write_zeroes headers.
Signed-off-by: Stefano Garzarella
---
tests/virtio-blk-test.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/tests/virtio-blk-test.c
In order to avoid migration issues, we enable DISCARD and
WRITE_ZEROES features only for machine type >= 4.0
As discussed with Michael S. Tsirkin and Stefan Hajnoczi on the
list [1], DISCARD operation should not have security implications
(eg. page cache attacks), so we can enable it by default.
Since configurable features for virtio-blk are growing, this patch
adds host_features field in the struct VirtIOBlock. (as in virtio-net)
In this way, we can avoid to add new fields for new properties and
we can directly set VIRTIO_BLK_F* flags in the host_features.
We update "config-wce" and
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.
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Thomas Huth
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)
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Stefano Garzarella
---
hw/block/virtio-blk.c | 10
This series adds the support of DISCARD and WRITE_ZEROES commands
and extends the virtio-blk-test to test these new commands.
v5:
- rebased on master
- handled the config size for DISCARD and WRITE_ZEROES features as in
virtio-net (patches 4 and 5) [Michael, Stefan]
- fixed an endianness issues
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 the process, remove some calls to frozen() that no longer
14.02.2019 2:23, John Snow wrote:
> The current API allows us to report a single status, which we've defined as:
>
> Frozen: has a successor, treated as qmp_locked, may or may not be enabled.
> Locked: no successor, qmp_locked. may or may not be enabled.
> Disabled: Not frozen or locked,
1 - 100 of 116 matches
Mail list logo
