On 8/11/22 21:57, Stefan Hajnoczi wrote:
I've dropped the SDHCI CVE fix due to the CI failure.
The rest of the commits are still in the staging tree and I plan to
include them in v7.2.0-rc0.
Thank you Stefan, sorry for not catching that failure sooner.
at 10:11 PM, Klaus Jensen wrote:
> On Nov 8 12:39, John Levon wrote:
>> On Fri, Nov 04, 2022 at 07:32:12AM +0100, Klaus Jensen wrote:
>>
>>> On Nov 3 21:19, Jinhao Fan wrote:
On 11/3/2022 8:10 PM, Klaus Jensen wrote:
> I agree that the spec is a little unclear on this point. In any
blk_drain() needs the lock because it calls AIO_WAIT_WHILE().
The s->rq loop doesn't need the lock because dataplane has been stopped
when virtio_blk_reset() is called.
Signed-off-by: Stefan Hajnoczi
---
hw/block/virtio-blk.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
There is no need to acquire AioContext in virtio_blk_handle_vq() because
no APIs used in the function require it and nothing else in the
virtio-blk code requires mutual exclusion anymore.
Signed-off-by: Stefan Hajnoczi
---
hw/block/virtio-blk.c | 2 --
1 file changed, 2 deletions(-)
diff --git
From: Emanuele Giuseppe Esposito
virtio_queue_aio_attach_host_notifier() and
virtio_queue_aio_attach_host_notifier_nopoll() run always in the
main loop, so there is no need to protect them with AioContext
lock.
On the other side, virtio_queue_aio_detach_host_notifier() runs
in a bh in the
From: Emanuele Giuseppe Esposito
Just as done in the block API, mark functions in virtio-blk
that are called also from iothread(s).
We know such functions are IO because many are blk_* callbacks,
running always in the device iothread, and remaining are propagated
from the leaf IO functions (if
From: Emanuele Giuseppe Esposito
AioContext lock was introduced in b9e413dd375 and in this instance
it is used to protect these 3 functions:
- virtio_blk_handle_rw_error
- virtio_blk_req_complete
- block_acct_done
Now that all three of the above functions are protected with
their own locks, we
From: Emanuele Giuseppe Esposito
Just as done in the block API, mark functions in virtio-blk
that are always called in the main loop with BQL held.
We know such functions are GS because they all are callbacks
from virtio.c API that has already classified them as GS.
Signed-off-by: Emanuele
From: Emanuele Giuseppe Esposito
It is read from IO_CODE and written with BQL held,
so setting it as atomic should be enough.
Also remove the aiocontext lock that was sporadically
taken around the set.
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
Signed-off-by:
This is a continuation of Emanuele Esposito's work to remove the AioContext
lock in virtio-blk. In the past it was necessary to acquire the AioContext lock
in order to do I/O. Paolo Bonzini and Emanuele have removed the need for the
AioContext in the core block layer code, with a few exceptions
From: Emanuele Giuseppe Esposito
All the callbacks below are always running in the main loop.
The callbacks are the following:
- start/stop_ioeventfd: these are the callbacks where
blk_set_aio_context(iothread) is done, so they are called in the main
loop.
- save and load: called during
I've dropped the SDHCI CVE fix due to the CI failure.
The rest of the commits are still in the staging tree and I plan to
include them in v7.2.0-rc0.
Stefan
available in the Git repository at:
>
> https://github.com/philmd/qemu.git tags/memflash-20221108
>
> for you to fetch changes up to cf9b3efd816518f9f210f50a0fa3e46a00b33c27:
>
> Revert "hw/block/pflash_cfi: Error out if dev length isn
On 11/3/22 19:16, Avihai Horon wrote:
Add new function qemu_file_get_to_fd() that allows reading data from
QEMUFile and writing it straight into a given fd.
This will be used later in VFIO migration code.
Signed-off-by: Avihai Horon
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best
On 221108 1225, Alexander Bulekov wrote:
> On 221107 2312, Philippe Mathieu-Daudé wrote:
> > When sdhci_write_block_to_card() is called to transfer data from
> > the FIFO to the SD bus, the data is already present in the buffer
> > and we have to consume it directly.
> >
> > See the description
On 11/3/22 19:16, Avihai Horon wrote:
As part of its error flow, vfio_vmstate_change() accesses
MigrationState->to_dst_file without any checks. This can cause a NULL
pointer dereference if the error flow is taken and
MigrationState->to_dst_file is not set.
For example, this can happen if VM is
On 11/3/22 19:16, Avihai Horon wrote:
vfio_migration_init() initializes VFIOMigration->device_state using enum
of VFIO migration protocol v2. Current implemented protocol is v1 so v1
enum should be used. Fix it.
Fixes: 429c72800654 ("vfio/migration: Fix incorrect initialization value for
On 11/3/22 19:16, Avihai Horon wrote:
From: Juan Quintela
Signed-off-by: Juan Quintela
Signed-off-by: Avihai Horon
---
migration/migration.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index
On 11/8/22 21:36, Vladimir Sementsov-Ogievskiy wrote:
On 11/3/22 19:16, Avihai Horon wrote:
From: Juan Quintela
And it appears that what is wrong is the code. During bulk stage we
need to make sure that some block is dirty, but no games with
max_size at all.
:) That made me interested in,
On 11/3/22 19:16, Avihai Horon wrote:
From: Juan Quintela
And it appears that what is wrong is the code. During bulk stage we
need to make sure that some block is dirty, but no games with
max_size at all.
:) That made me interested in, why we need this one block, so I decided to
search
From: Daniel Henrique Barboza
Commit 334c388f25 ("pflash_cfi: Error out if device length
isn't a power of two") aimed to finish the effort started by
commit 06f1521795 ("pflash: Require backend size to match device,
improve errors"), but unfortunately we are not quite there since
various
When sdhci_write_block_to_card() is called to transfer data from
the FIFO to the SD bus, the data is already present in the buffer
and we have to consume it directly.
See the description of the 'Buffer Write Enable' bit from the
'Present State' register (prnsts::SDHC_SPACE_AVAILABLE) in Table
The following changes since commit ade760a2f63804b7ab1839fbc3e5ddbf30538718:
Merge tag 'pull-request-2022-11-08' of https://gitlab.com/thuth/qemu into
staging (2022-11-08 11:34:06 -0500)
are available in the Git repository at:
https://github.com/philmd/qemu.git tags/memflash-20221108
From: Zhenzhong Duan
The end address of memory region section isn't correctly calculated
which leads to overflowed mtree dump:
Dispatch
Physical sections
..
#70 @2000..00011fff io [ROOT]
#71 @5000..5fff (noname)
#72
Applied to the staging tree. Thanks!
Stefan
Applied to staging. Thanks!
Stefan
On 11/3/22 19:16, Avihai Horon wrote:
From: Juan Quintela
So remove it everywhere.
Signed-off-by: Juan Quintela
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
Commit 334c388f25 ("pflash_cfi: Error out if device length
isn't a power of two") aimed to finish the effort started by
commit 06f1521795 ("pflash: Require backend size to match device,
improve errors"), but unfortunately we are not quite there since
various machines are still ready to accept
On 11/3/22 19:16, Avihai Horon wrote:
From: Juan Quintela
It was only used for RAM, and in that case, it means that this amount
of data was sent for memory.
Not clear for me, what means "this amount of data was sent for memory"... That
amount of data was not yet sent, actually.
Just
Spansion nor-flash stores the dummy read count in bits in a config register.
This is currently read and used as the byte count which is wrong.
This patch fixes this bit to byte conversion without warning about
unsupported configurations (such as bits % 8 != 0)
Signed-off-by: Ramon Aerne
---
On 221107 2312, Philippe Mathieu-Daudé wrote:
> When sdhci_write_block_to_card() is called to transfer data from
> the FIFO to the SD bus, the data is already present in the buffer
> and we have to consume it directly.
>
> See the description of the 'Buffer Write Enable' bit from the
> 'Present
"Michael S. Tsirkin" writes:
> On Tue, Nov 08, 2022 at 11:21:26AM +, Alex Bennée wrote:
>>
>> "Michael S. Tsirkin" writes:
>>
>> > On Tue, Nov 08, 2022 at 10:23:15AM +, Alex Bennée wrote:
>> >>
>> >> "Michael S. Tsirkin" writes:
>> >>
>> >> > On Tue, Nov 08, 2022 at 09:23:04AM
On 11/8/22 19:19, Vladimir Sementsov-Ogievskiy wrote:
This is a lot better than our "coroutine_fn" sign, which actually do no check (and can't
do). Don't you plan to swap a "coroutine_fn" noop marker with more meaningful
IN_COROUTINE(); (or something like this, which just do
[add Stefan]
On 11/8/22 18:09, Emanuele Giuseppe Esposito wrote:
Am 08/11/2022 um 15:48 schrieb Vladimir Sementsov-Ogievskiy:
On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
These functions end up calling bdrv_common_block_status_above(), a
generated_co_wrapper function.
Am 08/11/2022 um 16:52 schrieb Vladimir Sementsov-Ogievskiy:
> On 11/8/22 18:13, Emanuele Giuseppe Esposito wrote:
>>
>>
>> Am 08/11/2022 um 15:33 schrieb Vladimir Sementsov-Ogievskiy:
>>> On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
It seems that bdrv_open_driver() forgot to create
On 11/8/22 18:13, Emanuele Giuseppe Esposito wrote:
Am 08/11/2022 um 15:33 schrieb Vladimir Sementsov-Ogievskiy:
On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
It seems that bdrv_open_driver() forgot to create a coroutine
where to call bs->drv->bdrv_co_drain_begin(), a callback
marked
On Tue, Nov 08, 2022 at 11:21:26AM +, Alex Bennée wrote:
>
> "Michael S. Tsirkin" writes:
>
> > On Tue, Nov 08, 2022 at 10:23:15AM +, Alex Bennée wrote:
> >>
> >> "Michael S. Tsirkin" writes:
> >>
> >> > On Tue, Nov 08, 2022 at 09:23:04AM +, Alex Bennée wrote:
> >> >> The
Am 04.11.2022 um 10:56 hat Emanuele Giuseppe Esposito geschrieben:
> Delete the if case and make sure it won't be called again
> in coroutines.
>
> Signed-off-by: Emanuele Giuseppe Esposito
> Reviewed-by: Paolo Bonzini
In the subject line, it should be "never called in coroutine context"
Am 08.11.2022 um 15:33 hat Vladimir Sementsov-Ogievskiy geschrieben:
> On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
> > It seems that bdrv_open_driver() forgot to create a coroutine
> > where to call bs->drv->bdrv_co_drain_begin(), a callback
> > marked as coroutine_fn.
> >
> > Because
Am 08/11/2022 um 15:33 schrieb Vladimir Sementsov-Ogievskiy:
> On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
>> It seems that bdrv_open_driver() forgot to create a coroutine
>> where to call bs->drv->bdrv_co_drain_begin(), a callback
>> marked as coroutine_fn.
>>
>> Because there is no
Am 08/11/2022 um 15:48 schrieb Vladimir Sementsov-Ogievskiy:
> On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
>> These functions end up calling bdrv_common_block_status_above(), a
>> generated_co_wrapper function.
>
> generated_co_wrapper is not a coroutine_fn. Сonversely it's a function
On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
Call two different functions depending on whether bdrv_create
is in coroutine or not, following the same pattern as
generated_co_wrapper functions.
This allows to also call the coroutine function directly,
without using CreateCo or relying in
On Fri, Nov 04, 2022 at 07:32:12AM +0100, Klaus Jensen wrote:
> On Nov 3 21:19, Jinhao Fan wrote:
> > On 11/3/2022 8:10 PM, Klaus Jensen wrote:
> > > I agree that the spec is a little unclear on this point. In any case, in
> > > Linux, when the driver has decided that the sq tail must be
On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
These functions end up calling bdrv_*() implemented as generated_co_wrapper
functions.
Same here. Sorry that I joined only on v3.
In past we had a lot of "coroutine wrappers", each IO function in block/io.c
and many in block.c had two
On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
These functions end up calling bdrv_common_block_status_above(), a
generated_co_wrapper function.
generated_co_wrapper is not a coroutine_fn. Сonversely it's a function that do
a class coroutine wrapping - start a coroutine and do POLL to
Setting it to true can cause the device size to be queried from libblkio
in otherwise fast paths, degrading performance. Set it to false and
require users to refresh the device size explicitly instead.
Fixes: 4c8f4fda0504 ("block/blkio: Tolerate device size changes")
Suggested-by: Kevin Wolf
On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
It seems that bdrv_open_driver() forgot to create a coroutine
where to call bs->drv->bdrv_co_drain_begin(), a callback
marked as coroutine_fn.
Because there is no active I/O at this point, the coroutine
should end right after entering, so the
The nvme-io_uring BlockDriver's path option must point at the character
device of an NVMe namespace, not at an image file.
Fixes: fd66dbd424f5 ("blkio: add libblkio block driver")
Suggested-by: Stefano Garzarella
Signed-off-by: Alberto Faria
---
qapi/block-core.json | 2 +-
1 file changed, 1
Am 08.11.2022 um 15:13 hat Kevin Wolf geschrieben:
> Am 07.11.2022 um 16:13 hat Hanna Reitz geschrieben:
> > Hi,
> >
> > v1 cover letter:
> > https://lists.nongnu.org/archive/html/qemu-block/2022-09/msg00389.html
> >
> > bdrv_replace_child_noperm() drains the child via
> >
On 11/4/22 19:06, Markus Armbruster wrote:
block-export-add argument @name defaults to the value of argument
@node-name.
nbd_export_create() implements this by copying @node_name to @name.
It leaves @has_node_name false, violating the "has_node_name ==
!!node_name" invariant. Unclean. Falls
Am 07.11.2022 um 16:13 hat Hanna Reitz geschrieben:
> Hi,
>
> v1 cover letter:
> https://lists.nongnu.org/archive/html/qemu-block/2022-09/msg00389.html
>
> bdrv_replace_child_noperm() drains the child via
> bdrv_parent_drained_{begin,end}_single(). When it removes a child, the
>
On Nov 8 12:39, John Levon wrote:
> On Fri, Nov 04, 2022 at 07:32:12AM +0100, Klaus Jensen wrote:
>
> > On Nov 3 21:19, Jinhao Fan wrote:
> > > On 11/3/2022 8:10 PM, Klaus Jensen wrote:
> > > > I agree that the spec is a little unclear on this point. In any case, in
> > > > Linux, when the
bdrv_drain_invoke() has now two entirely separate cases that share no
code any more and are selected depending on a bool parameter. Each case
has only one caller. Just inline the function.
Signed-off-by: Kevin Wolf
---
block/io.c | 23 ++-
1 file changed, 6 insertions(+), 17
In order to make sure that bdrv_replace_child_noperm() doesn't have to
poll any more, get rid of the bdrv_parent_drained_begin_single() call.
This is possible now because we can require that the child is already
drained when the function is called (it better be, having in-flight
requests while
Subtree drains are not used any more. Remove them.
After this, BdrvChildClass.attach/detach() don't poll any more.
Signed-off-by: Kevin Wolf
---
include/block/block-io.h | 18 +--
include/block/block_int-common.h | 1 -
include/block/block_int-io.h | 12 --
block.c
Instead of using a subtree drain from the top node (which also drains
child nodes of base that we're not even interested in), use a normal
drain for base, which automatically drains all of the parents, too.
Signed-off-by: Kevin Wolf
---
block.c | 4 ++--
1 file changed, 2 insertions(+), 2
We only need to call both the BlockDriver's callback and the parent
callbacks when going from undrained to drained or vice versa. A second
drain section doesn't make a difference for the driver or the parent,
they weren't supposed to send new requests before and after the second
drain.
One thing
ignore_bds_parents is now ignored, so we can just remove it.
Signed-off-by: Kevin Wolf
---
include/block/block-io.h | 10 ++
block.c | 4 +--
block/io.c | 78 +++-
3 files changed, 32 insertions(+), 60 deletions(-)
diff
We want to change .bdrv_co_drained_begin/end() back to be non-coroutine
callbacks, so in preparation, avoid yielding in their implementation.
This does almost the same as the existing logic in bdrv_drain_invoke(),
by creating and entering coroutines internally. However, since the test
case is by
All callers of bdrv_parent_drained_begin_single() pass poll=false now,
so we don't need the parameter any more.
Signed-off-by: Kevin Wolf
---
include/block/block-io.h | 5 ++---
block.c | 4 ++--
block/io.c | 7 ++-
3 files changed, 6 insertions(+), 10
The subtree drain was introduced in commit b1e1af394d9 as a way to avoid
graph changes between finding the base node and changing the block graph
as necessary on completion of the image streaming job.
The block graph could change between these two points because
bdrv_set_backing_hd() first drains
I'm aware that exactly nobody has been looking forward to a series with
this title, but it has to be. The way drain works means that we need to
poll in bdrv_replace_child_noperm() and that makes things rather messy
with Emanuele's multiqueue work because you must not poll while you hold
the graph
drained_end_counter is unused now, nobody changes its value any more. It
can be removed.
In cases where we had two almost identical functions that only differed
in whether the caller passes drained_end_counter, or whether they would
poll for a local drained_end_counter to reach 0, these become a
bdrv_reopen() and friends use subtree drains as a lazy way of covering
all the nodes they touch. Turns out that this lazy way is a lot more
complicated than just draining the nodes individually, even not
accounting for the additional complexity in the drain mechanism itself.
Simplify the code by
We want to change .bdrv_co_drained_begin() back to be a non-coroutine
callback, so in preparation, avoid yielding in its implementation.
Because we increase bs->in_flight and bdrv_drained_begin() polls, the
behaviour is unchanged.
Signed-off-by: Kevin Wolf
---
block/qed.c | 20
Polling during bdrv_drained_end() can be problematic (and in the future,
we may get cases for bdrv_drained_begin() where polling is forbidden,
and we don't care about already in-flight requests, but just want to
prevent new requests from arriving).
The .bdrv_drained_begin/end callbacks running in
"Michael S. Tsirkin" writes:
> On Tue, Nov 08, 2022 at 10:23:15AM +, Alex Bennée wrote:
>>
>> "Michael S. Tsirkin" writes:
>>
>> > On Tue, Nov 08, 2022 at 09:23:04AM +, Alex Bennée wrote:
>> >> The previous fix to virtio_device_started revealed a problem in its
>> >> use by both the
On Tue, Nov 08, 2022 at 10:23:15AM +, Alex Bennée wrote:
>
> "Michael S. Tsirkin" writes:
>
> > On Tue, Nov 08, 2022 at 09:23:04AM +, Alex Bennée wrote:
> >> The previous fix to virtio_device_started revealed a problem in its
> >> use by both the core and the device code. The core code
"Michael S. Tsirkin" writes:
> On Tue, Nov 08, 2022 at 09:23:04AM +, Alex Bennée wrote:
>> The previous fix to virtio_device_started revealed a problem in its
>> use by both the core and the device code. The core code should be able
>> to handle the device "starting" while the VM isn't
On Tue, Nov 08, 2022 at 09:23:04AM +, Alex Bennée wrote:
> The previous fix to virtio_device_started revealed a problem in its
> use by both the core and the device code. The core code should be able
> to handle the device "starting" while the VM isn't running to handle
> the restoration of
On Tue, Nov 08, 2022 at 09:23:04AM +, Alex Bennée wrote:
> The previous fix to virtio_device_started revealed a problem in its
> use by both the core and the device code. The core code should be able
> to handle the device "starting" while the VM isn't running to handle
> the restoration of
The previous fix to virtio_device_started revealed a problem in its
use by both the core and the device code. The core code should be able
to handle the device "starting" while the VM isn't running to handle
the restoration of migration state. To solve this dual use introduce a
new helper for use
On Mon, Nov 7, 2022 at 11:12 PM Philippe Mathieu-Daudé
wrote:
>
> When sdhci_write_block_to_card() is called to transfer data from
> the FIFO to the SD bus, the data is already present in the buffer
> and we have to consume it directly.
>
> See the description of the 'Buffer Write Enable' bit
73 matches
Mail list logo
