Hello,
On Mon, Jan 22, 2024 at 8:05 PM Peter Maydell wrote:
>
> On Thu, 18 Jan 2024 at 16:03, Manolo de Medici
> wrote:
> >
> > Compilation fails on systems where copy_file_range is already defined as a
> > stub.
>
> What do you mean by "stub" here ? If the system headers define
> a prototype
On Mon, Jan 22, 2024 at 9:23 PM Sergey Bugaev wrote:
> call such a function. For example on GNU/Linux, remove(2) is a stub,
(That was supposed to say revoke(2), of course.)
The NVMe ZNS devices follow NVMe ZNS spec but the state of namespace
zones does not persist accross restarts of QEMU. This patch makes the
metadata of ZNS emulation persistent by using new block layer APIs. The
ZNS device calls zone report and zone mgmt APIs from the block layer
which will handle
The zone information is contained in the BlockLimits fileds. Add blk_get_*()
functions
to access the block layer and update zone info accessing in the NVMe device
emulation.
Signed-off-by: Sam Li
---
block/block-backend.c | 72 +++
hw/nvme/ctrl.c
Zone descriptor extension data is host definied data that is
associated with each zone. Add zone descriptor extensions
to zonedmeta struct.
Signed-off-by: Sam Li
---
block/qcow2.c| 70 +---
block/qcow2.h| 2 +
Zone descriptor extension data (ZDED) is not persistent across QEMU
restarts. The zone descriptor extension valid bit (ZDEV) is part of
zone attributes, which sets to one when the ZDED is associated with
the zone.
With the qcow2 img as the backing file, the NVMe ZNS device stores
the zone
ZNS emulation follows NVMe ZNS spec but the state of namespace
zones does not persist accross restarts of QEMU. This patch makes the
metadata of ZNS emulation persistent by using new block layer APIs and
the qcow2 img as backing file. It is the second part after the patches
- adding full zoned
Signed-off-by: Sam Li
---
block/qcow2.c| 2 +-
hw/nvme/ctrl.c | 190 ---
include/sysemu/dma.h | 3 +
system/dma-helpers.c | 17
4 files changed, 162 insertions(+), 50 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index
The NVMe ZNS command set has the zone descriptor extension feature for
associating the data to a zone. Devices that supports ZAC/ZBC have zero
zone descriptor extension size.
Signed-off-by: Sam Li
---
docs/interop/qcow2.txt | 9 +
1 file changed, 9 insertions(+)
diff --git
Signed-off-by: Sam Li
---
block/block-backend.c | 16
hw/nvme/ctrl.c| 20 ++--
hw/nvme/ns.c | 24
hw/nvme/nvme.h| 7 ---
include/sysemu/block-backend-io.h | 2
To configure the zoned format feature on the qcow2 driver, it
requires settings as: the device size, zone model, zone size,
zone capacity, number of conventional zones, limits on zone
resources (max append bytes, max open zones, and max_active_zones).
To create a qcow2 image with zoned format
The zoned format feature can be tested by:
$ tests/qemu-iotests/check -qcow2 zoned-qcow2
Signed-off-by: Sam Li
Reviewed-by: Stefan Hajnoczi
---
tests/qemu-iotests/tests/zoned-qcow2 | 147 +++
tests/qemu-iotests/tests/zoned-qcow2.out | 172 +++
2 files
By adding zone operations and zoned metadata, the zoned emulation
capability enables full emulation support of zoned device using
a qcow2 file. The zoned device metadata includes zone type,
zoned device state and write pointer of each zone, which is stored
to an array of unsigned integers.
Each
Add the specs for the zoned format feature of the qcow2 driver.
The qcow2 file then can emulate real zoned devices, either passed
through by virtio-blk device or NVMe ZNS drive to the guest
given zoned information.
Signed-off-by: Sam Li
Reviewed-by: Stefan Hajnoczi
---
This patch series add a new extension - zoned format - to the
qcow2 driver thereby allowing full zoned storage emulation on
the qcow2 img file. Users can attach such a qcow2 file to the
guest as a zoned device.
Write pointer are preserved in the zoned metadata. It will be
recovered after power
Klaus Jensen 于2024年1月10日周三 07:52写道：
>
> Hi Sam,
>
> This is awesome. For the hw/nvme parts,
>
> Acked-by: Klaus Jensen
>
> I'll give it a proper R-b when you drop the RFC status.
Hi Klaus,
Sorry for the late response. I will submit a new RFC patch series very
soon.
Now the zone states should
On 22.01.24 18:41, Hanna Czenczek wrote:
On 05.01.24 15:30, Fiona Ebner wrote:
Am 05.01.24 um 14:43 schrieb Fiona Ebner:
Am 03.01.24 um 14:35 schrieb Paolo Bonzini:
On 1/3/24 12:40, Fiona Ebner wrote:
I'm happy to report that I cannot reproduce the CPU-usage-spike issue
with the patch, but I
On 05.01.24 15:30, Fiona Ebner wrote:
Am 05.01.24 um 14:43 schrieb Fiona Ebner:
Am 03.01.24 um 14:35 schrieb Paolo Bonzini:
On 1/3/24 12:40, Fiona Ebner wrote:
I'm happy to report that I cannot reproduce the CPU-usage-spike issue
with the patch, but I did run into an assertion failure when
Requests that complete in an IOThread use irqfd to notify the guest
while requests that complete in the main loop thread use the traditional
qdev irq code path. The reason for this conditional is that the irq code
path requires the BQL:
if (s->ioeventfd_started && !s->ioeventfd_disabled) {
(Cc'ing the block folks)
On Thu, 18 Jan 2024 at 16:03, Manolo de Medici wrote:
>
> Compilation fails on systems where copy_file_range is already defined as a
> stub.
What do you mean by "stub" here ? If the system headers define
a prototype for the function, I would have expected the
meson
From: Fiona Ebner
Using fleecing backup like in [0] on a qcow2 image (with metadata
preallocation) can lead to the following assertion failure:
> bdrv_co_do_block_status: Assertion `!(ret & BDRV_BLOCK_ZERO)' failed.
In the reproducer [0], it happens because the BDRV_BLOCK_RECURSE flag
will be
From: Akihiko Odaki
Coroutine may be pooled even after COROUTINE_TERMINATE if
CONFIG_COROUTINE_POOL is enabled and fake stack should be saved in
such a case to keep AddressSanitizerUseAfterReturn working. Even worse,
I'm seeing stack corruption without fake stack being saved.
Signed-off-by:
The following changes since commit 09be34717190c1620f0c6e5c8765b8da354aeb4b:
Merge tag 'pull-request-2024-01-19' of https://gitlab.com/thuth/qemu into
staging (2024-01-20 17:22:16 +)
are available in the Git repository at:
https://gitlab.com/stefanha/qemu.git tags/block-pull-request
On Mon, 22 Jan 2024 at 11:15, Kevin Wolf wrote:
>
> Am 20.01.2024 um 18:21 hat Peter Maydell geschrieben:
> > Got some compile failures on this one; looks like the compiler
> > on our s390 box didn't like this:
> >
> > https://gitlab.com/qemu-project/qemu/-/jobs/5973441293
> >
The following changes since commit 3f2a357b95845ea0bf7463eff6661e43b97d1afc:
Merge tag 'hw-cpus-20240119' of https://github.com/philmd/qemu into staging
(2024-01-19 11:39:38 +)
are available in the Git repository at:
https://repo.or.cz/qemu/kevin.git tags/for-upstream
for you to fetch
Am 20.01.2024 um 18:21 hat Peter Maydell geschrieben:
> On Fri, 19 Jan 2024 at 18:15, Kevin Wolf wrote:
> >
> > The following changes since commit 3f2a357b95845ea0bf7463eff6661e43b97d1afc:
> >
> > Merge tag 'hw-cpus-20240119' of https://github.com/philmd/qemu into
> > staging (2024-01-19
On Sat, Jan 20, 2024 at 01:18:14PM +0300, Michael Tokarev wrote:
> 08.01.2024 19:08, Gerd Hoffmann:
> > When running qemu with edk2 efi firmware on aarch64 the efi
> > variable store in pflash can get corrupted. qemu not doing
> > proper block writes -- flush all or nothing to storage -- is
> > a
27 matches
Mail list logo
