> -Original Message-
> From: Keith Busch
> Sent: Wednesday, September 30, 2020 6:04 PM
> To: qemu-block@nongnu.org; qemu-de...@nongnu.org; Klaus Jensen
>
> Cc: Niklas Cassel ; Dmitry Fomichev
> ; Kevin Wolf ; Philippe
> Mathieu-Daudé ; Keith Busch
> Subject: [PATCH 3/9] hw/block/nvme:
> -Original Message-
> From: Keith Busch
> Sent: Wednesday, September 30, 2020 6:04 PM
> To: qemu-block@nongnu.org; qemu-de...@nongnu.org; Klaus Jensen
>
> Cc: Niklas Cassel ; Dmitry Fomichev
> ; Kevin Wolf ; Philippe
> Mathieu-Daudé ; Keith Busch
> Subject: [PATCH 1/9] hw/block/nvme:
> -Original Message-
> From: Niklas Cassel
> Sent: Monday, October 5, 2020 7:41 AM
> To: Dmitry Fomichev
> Cc: Alistair Francis ; qemu-de...@nongnu.org;
> Damien Le Moal ; f...@euphon.net; Matias
> Bjorling ; qemu-block@nongnu.org;
> kw...@redhat.com; mlevi...@redhat.com;
On 05.10.2020 17:58, Vladimir Sementsov-Ogievskiy wrote:
29.09.2020 15:38, Andrey Shinkevich wrote:
Limit the guest's COR operations by the base node in the backing chain
when the base node name is given. It will be useful for a block stream
job when the COR-filter is applied.
Signed-off-by:
On 05.10.2020 17:58, Vladimir Sementsov-Ogievskiy wrote:
29.09.2020 15:38, Andrey Shinkevich wrote:
Limit the guest's COR operations by the base node in the backing chain
when the base node name is given. It will be useful for a block stream
job when the COR-filter is applied.
On 10/5/20 10:58 AM, Kevin Wolf wrote:
> Most callers actually don't have to rely on cur_mon, but already know
> for which monitor they call monitor_get_cpu_index().
>
> Signed-off-by: Kevin Wolf
> ---
> include/monitor/monitor.h | 2 +-
> hw/core/machine-hmp-cmds.c | 2 +-
>
The current monitor is updated relatively early in the command handling
code even though only the command handler actually needs it.
The current monitor will become coroutine-local later, so we can only
update it when we know in which coroutine the command will be exectued.
Move it to
On 05.10.2020 16:34, Vladimir Sementsov-Ogievskiy wrote:
29.09.2020 15:38, Andrey Shinkevich wrote:
Provide API for the COR-filter insertion/removal.
Also, drop the filter child permissions for an inactive state when the
filter node is being removed.
Signed-off-by: Andrey Shinkevich
---
block_resize performs some I/O that could potentially take quite some
time, so use it as an example for the new 'coroutine': true annotation
in the QAPI schema.
bdrv_truncate() requires that we're already in the right AioContext for
the BlockDriverState if called in coroutine context. So instead
Add a pair of functions to temporarily move the current coroutine to the
AioContext of a given BlockDriverState.
Signed-off-by: Kevin Wolf
---
include/block/block.h | 17 +
block.c | 23 +++
2 files changed, 40 insertions(+)
diff --git
Inside of coroutine context, we can't directly use aio_context_acquire()
for the AioContext of a block node because we already own the lock of
the current AioContext and we need to avoid double locking to prevent
deadlocks.
This provides helper functions to lock the AioContext of a node only if
Often, QMP command handlers are not only called to handle QMP commands,
but also from a corresponding HMP command handler. In order to give them
a consistent environment, optionally run HMP command handlers in a
coroutine, too.
The implementation is a lot simpler than in QMP because for HMP, we
This patch adds a new 'coroutine' flag to QMP command definitions that
tells the QMP dispatcher that the command handler is safe to be run in a
coroutine.
The documentation of the new flag pretends that this flag is already
used as intended, which it isn't yet after this patch. We'll implement
Add a function that can be used to move the currently running coroutine
to a different AioContext (and therefore potentially a different
thread).
Signed-off-by: Kevin Wolf
Reviewed-by: Stefan Hajnoczi
---
include/block/aio.h | 10 ++
util/async.c| 30
This way, a monitor command handler will still be able to access the
current monitor, but when it yields, all other code code will correctly
get NULL from monitor_cur().
This uses a hash table to map the coroutine pointer to the current
monitor of that coroutine. Outside of coroutine context, we
The correct way to set the current monitor for a coroutine handler will
be different than for a blocking handler, so monitor_set_cur() needs to
be called in qmp_dispatch().
Signed-off-by: Kevin Wolf
---
include/qapi/qmp/dispatch.h | 3 ++-
monitor/qmp.c | 9 ++---
cur_mon really needs to be coroutine-local as soon as we move monitor
command handlers to coroutines and let them yield. As a first step, just
remove all direct accesses to cur_mon so that we can implement this in
the getter function later.
Signed-off-by: Kevin Wolf
---
Some QMP command handlers can block the main loop for a relatively long
time, for example because they perform some I/O. This is quite nasty.
Allowing such handlers to run in a coroutine where they can yield (and
therefore release the BQL) while waiting for an event such as I/O
completion solves
Most callers actually don't have to rely on cur_mon, but already know
for which monitor they call monitor_get_cpu_index().
Signed-off-by: Kevin Wolf
---
include/monitor/monitor.h | 2 +-
hw/core/machine-hmp-cmds.c | 2 +-
monitor/hmp-cmds.c | 2 +-
monitor/misc.c | 20
This moves the QMP dispatcher to a coroutine and runs all QMP command
handlers that declare 'coroutine': true in coroutine context so they
can avoid blocking the main loop while doing I/O or waiting for other
events.
For commands that are not declared safe to run in a coroutine, the
dispatcher
From: Vladimir Sementsov-Ogievskiy
Like for read/write in a previous commit, drop extra indirection layer,
generate directly bdrv_readv_vmstate() and bdrv_writev_vmstate().
Signed-off-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
Reviewed-by: Stefan
monitor_qmp_dispatch() is never supposed to be called in the context of
another monitor, so assert that monitor_cur() is NULL instead of saving
and restoring it.
Signed-off-by: Kevin Wolf
---
monitor/qmp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/monitor/qmp.c
Most callers actually don't have to rely on cur_mon, but already know
for which monitor they call monitor_set_cpu().
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
---
include/monitor/monitor.h | 2 +-
monitor/hmp-cmds.c| 2 +-
monitor/misc.c| 10 +-
3 files
From: Vladimir Sementsov-Ogievskiy
We have a very frequent pattern of creating a coroutine from a function
with several arguments:
- create a structure to pack parameters
- create _entry function to call original function taking parameters
from struct
- do different magic to handle
From: Eric Auger
Introduce the qemu_vfio_find_fixed/temp_iova helpers which
respectively allocate IOVAs from the bottom/top parts of the
usable IOVA range, without picking within host IOVA reserved
windows. The allocation remains basic: if the size is too big
for the remaining of the current
From: Vladimir Sementsov-Ogievskiy
This is the only non-ascii character in the file and it doesn't really
needed here. Let's use normal "'" symbol for consistency with the rest
11 occurrences of "'" in the file.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
From: Stefano Garzarella
When we added io_uring AIO engine, we forgot to update qemu-options.hx,
so qemu(1) man page and qemu help were outdated.
Signed-off-by: Stefano Garzarella
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Julia Suvorova
Reviewed-by: Pankaj Gupta
Message-Id:
From: Philippe Mathieu-Daudé
We only access the I/O register in nvme_init().
Remove the reference in BDRVNVMeState and reduce its scope.
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by: Stefan Hajnoczi
Message-Id: <20200922083821.578519-4-phi...@redhat.com>
---
block/nvme.c | 29
From: Vladimir Sementsov-Ogievskiy
Now that we are not maintaining boilerplate code for coroutine
wrappers, there is no more sense in keeping the extra indirection layer
of bdrv_prwv(). Let's drop it and instead generate pure bdrv_preadv()
and bdrv_pwritev().
Currently, bdrv_pwritev() and
From: Vladimir Sementsov-Ogievskiy
Use code generation implemented in previous commit to generated
coroutine wrappers in block.c and block/io.c
Signed-off-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
Message-Id:
From: Vladimir Sementsov-Ogievskiy
This is the only coroutine wrapper from block.c and block/io.c which
doesn't return a value, so let's convert it to the common behavior, to
simplify moving to generated coroutine wrappers in a further commit.
Also, bdrv_invalidate_cache is a void function,
From: Eric Auger
The IOVA allocator currently ignores host reserved regions.
As a result some chosen IOVAs may collide with some of them,
resulting in VFIO MAP_DMA errors later on. This happens on ARM
where the MSI reserved window quickly is encountered:
[0x800, 0x810]. since 5.4 kernel,
From: Vladimir Sementsov-Ogievskiy
We are going to keep coroutine-wrappers code (structure-packing
parameters, BDRV_POLL wrapper functions) in separate auto-generated
files. So, we'll need a header with declaration of original _co_
functions, for those which are static now. As well, we'll need
From: Vladimir Sementsov-Ogievskiy
Most of our coroutine wrappers already follow this convention:
We have 'coroutine_fn bdrv_co_()' as
the core function, and a wrapper 'bdrv_()' which does parameter packing and calls bdrv_run_co().
The only outsiders are the bdrv_prwv_co and
From: Philippe Mathieu-Daudé
Per the datasheet sections 3.1.13/3.1.14:
"The host should not read the doorbell registers."
As we don't need read access, map the doorbells with write-only
permission. We keep a reference to this mapped address in the
BDRVNVMeState structure.
Signed-off-by:
From: Philippe Mathieu-Daudé
Pages are currently mapped READ/WRITE. To be able to use different
protections, add a new argument to qemu_vfio_pci_map_bar().
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by: Stefan Hajnoczi
Message-Id: <20200922083821.578519-2-phi...@redhat.com>
---
From: Philippe Mathieu-Daudé
Use self-explicit SCALE_MS definition instead of magic value
(missed in similar commit e4f310fe7f5).
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by: Stefan Hajnoczi
Message-Id: <20200922083821.578519-7-phi...@redhat.com>
---
block/nvme.c | 2 +-
1 file
From: Philippe Mathieu-Daudé
NVMeRegs only contains NvmeBar. Simplify the code by using NvmeBar
directly.
This triggers a checkpatch.pl error:
ERROR: Use of volatile is usually wrong, please add a comment
#30: FILE: block/nvme.c:691:
+volatile NvmeBar *regs;
This is a false positive
The following changes since commit 469e72ab7dbbd7ff4ee601e5ea7c29545d46593b:
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
(2020-10-02 16:19:42 +0100)
are available in the Git repository at:
https://gitlab.com/stefanha/qemu.git tags/block-pull-request
for you
From: Philippe Mathieu-Daudé
Use the NVMe register definitions from "block/nvme.h" which
ease a bit reviewing the code while matching the datasheet.
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by: Stefan Hajnoczi
Message-Id: <20200922083821.578519-6-phi...@redhat.com>
---
block/nvme.c |
29.09.2020 15:38, Andrey Shinkevich wrote:
Limit the guest's COR operations by the base node in the backing chain
when the base node name is given. It will be useful for a block stream
job when the COR-filter is applied.
Signed-off-by: Andrey Shinkevich
---
block/copy-on-read.c | 38
29.09.2020 15:38, Andrey Shinkevich wrote:
To limit the guest's COR operations by the base node in the backing
Better to drop "guest's " word. We don't to limit the guest in any
chain during stream job, pass the base node name to the copy-on-read
driver. The rest of the functionality will be
On 10/5/20 2:55 PM, Paolo Bonzini wrote:
> Alex reported an uninitialized variable warning in ahci_populate_sglist.
> Even though the warning is bogus and happens only because of -Og, the
> code in the function leaves something to be desired; the condition that
> triggers the warning is easily
29.09.2020 15:38, Andrey Shinkevich wrote:
Provide API for the COR-filter insertion/removal.
Also, drop the filter child permissions for an inactive state when the
filter node is being removed.
Signed-off-by: Andrey Shinkevich
---
block/copy-on-read.c | 84
On Thu, Oct 01, 2020 at 04:12:12PM +0100, Peter Maydell wrote:
> On Thu, 1 Oct 2020 at 16:03, Stefan Hajnoczi wrote:
> >
> > On Thu, Oct 01, 2020 at 12:23:00PM +0100, Peter Maydell wrote:
> > > This produces this error message on ppc64be Linux:
> > >
> > > make: Entering directory
On Mon, Oct 05, 2020 at 12:54:40PM +0200, Philippe Mathieu-Daudé wrote:
> While the FW_CFG_DATA_GENERATOR_INTERFACE is only consumed
> by a device only available using system-mode (fw_cfg), it is
> implemented by a crypto component (tls-cipher-suites) which
> is always available when crypto is
On 05/10/20 12:54, Philippe Mathieu-Daudé wrote:
> This test fails on top of commit 69699f3055
> ("crypto/tls-cipher-suites: Produce fw_cfg consumable blob")
> because the TYPE_FW_CFG_DATA_GENERATOR_INTERFACE registered
> in hw/nvram/fw_cfg.c is not linked into qemu-storage-daemon:
>
> $ make
Alex reported an uninitialized variable warning in ahci_populate_sglist.
Even though the warning is bogus and happens only because of -Og, the
code in the function leaves something to be desired; the condition that
triggers the warning is easily shown to be entirely redundant.
In particular, the
Alex reported an uninitialized variable warning in dirty_bitmap_load_header,
where the compiler cannot understand that the !s->cancelled check must be
true for the following one to pass.
Even though the issue happened only because of -Og, the function is very
convoluted. Just rewrite it to first
Daniel P. Berrangé writes:
> On Mon, Oct 05, 2020 at 09:26:54AM +0200, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>> > On 10/2/20 11:27 AM, Daniel P. Berrangé wrote:
>> >
>> > Do we have a query- command handy to easily learn which snapshot names
>> > are even available to attempt
Markus Armbruster writes:
[...]
> Making help support opt-in complicates things. Is there a genuine use
> for not supporting help? Or is just to keep the users that don't
> support help yet (but should) working without change? Mind, I'm not
> asking you to make them work, I'm only asking
On Sun, Oct 04, 2020 at 11:57:07PM +, Dmitry Fomichev wrote:
> On Wed, 2020-09-30 at 14:50 +, Niklas Cassel wrote:
> > On Mon, Sep 28, 2020 at 11:35:23AM +0900, Dmitry Fomichev wrote:
> > > The emulation code has been changed to advertise NVM Command Set when
> > > "zoned" device property
On Fri, Oct 02, 2020 at 02:46:07PM -0500, Eric Blake wrote:
> On 10/2/20 11:27 AM, Daniel P. Berrangé wrote:
> > savevm, loadvm and delvm are some of the few HMP commands that have never
> > been converted to use QMP. The reasons for the lack of conversion are
> > that they blocked execution of
On Mon, Oct 05, 2020 at 09:26:54AM +0200, Markus Armbruster wrote:
> Eric Blake writes:
>
> > On 10/2/20 11:27 AM, Daniel P. Berrangé wrote:
> >
> > Do we have a query- command handy to easily learn which snapshot names
> > are even available to attempt deletion on? If not, that's worth a
> >
On Sun, Oct 04, 2020 at 11:54:13PM +, Dmitry Fomichev wrote:
> On Wed, 2020-09-30 at 13:50 +, Niklas Cassel wrote:
> > On Mon, Sep 28, 2020 at 11:35:20AM +0900, Dmitry Fomichev wrote:
> > > From: Niklas Cassel
> > >
> > > In NVMe, a namespace is active if it exists and is attached to the
Patchew URL:
https://patchew.org/QEMU/20201005105442.2093105-1-phi...@redhat.com/
Hi,
This series failed build test on FreeBSD host. Please find the details below.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit
Do not try to build socket_scm_helper if not softmmu target
is available. This fixes:
$ make check-block
Generating qemu-version.h with a meson_exe.py custom command
make: *** No rule to make target 'tests/qemu-iotests/socket_scm_helper',
needed by 'check-block'. Stop.
Signed-off-by:
Attempt to fix the issue reported by Kevin.
Introduce a trivial test, but there is currently no
framework in place to test qemu-storage-daemon.
There might be better fix to this QOM issue,
I went for the easiest one I could figure out.
Philippe Mathieu-Daudé (3):
qom: Always register
This test fails on top of commit 69699f3055
("crypto/tls-cipher-suites: Produce fw_cfg consumable blob")
because the TYPE_FW_CFG_DATA_GENERATOR_INTERFACE registered
in hw/nvram/fw_cfg.c is not linked into qemu-storage-daemon:
$ make check-block
Generating qemu-version.h with a meson_exe.py
While the FW_CFG_DATA_GENERATOR_INTERFACE is only consumed
by a device only available using system-mode (fw_cfg), it is
implemented by a crypto component (tls-cipher-suites) which
is always available when crypto is used.
Commit 69699f3055 introduced the following error in the
qemu-storage-daemon
Hi Laszlo,
On 10/1/20 9:18 AM, Laszlo Ersek wrote:
> On 09/29/20 17:46, Kevin Wolf wrote:
>> Am 04.07.2020 um 18:39 hat Philippe Mathieu-Daudé geschrieben:
>>> Since our format is consumable by the fw_cfg device,
>>> we can implement the FW_CFG_DATA_GENERATOR interface.
>>>
>>> Example of use to
Hi Sai,
On 9/16/20 7:51 PM, Sai Pavan Boddu wrote:
> Update 'SCR.CMD_SUPPORT' register with support of CMD23.
>
> Signed-off-by: Sai Pavan Boddu
> Reported-by: Rahul Thati
> ---
> Changes for V2:
> Fix commit message
>
> hw/sd/sd.c | 2 +-
> 1 file changed, 1 insertion(+), 1
Eric Blake writes:
> On 10/2/20 11:27 AM, Daniel P. Berrangé wrote:
>> savevm, loadvm and delvm are some of the few HMP commands that have never
>> been converted to use QMP. The reasons for the lack of conversion are
>> that they blocked execution of the event thread, and the semantics
>>
On 30.09.20 18:36, Fam Zheng wrote:
> On Wed, 2020-09-30 at 17:58 +0200, Christian Borntraeger wrote:
>> Fedora 32 gcc 10 seems to give false positives:
>>
>> Compiling C object libblock.fa.p/block_vmdk.c.o
>> ../block/vmdk.c: In function ‘vmdk_parse_extents’:
>> ../block/vmdk.c:587:5: error:
On 30.09.20 19:19, Eric Blake wrote:
> On 9/30/20 10:58 AM, Christian Borntraeger wrote:
>> gcc 10 from Fedora 32 gives me:
>>
>> Compiling C object libblock.fa.p/nbd_server.c.o
>> ../nbd/server.c: In function ‘nbd_co_client_start’:
>> ../nbd/server.c:625:14: error: ‘namelen’ may be used
On 30.09.20 18:27, Dr. David Alan Gilbert wrote:
> * Christian Borntraeger (borntrae...@de.ibm.com) wrote:
>> make: *** [Makefile:121: config-host.mak] Error 1
>> [cborntra@m83lp52 qemu]$ make -C build/
>> make: Entering directory '/home/cborntra/REPOS/qemu/build'
>> Generating qemu-version.h
66 matches
Mail list logo
