04.02.2020 20:42, Max Reitz wrote:
On 04.02.20 16:35, Vladimir Sementsov-Ogievskiy wrote:
31.01.2020 20:44, Eric Blake wrote:
Having two slightly-different function names for related purposes is
unwieldy, especially since I envision adding yet another notion of
zero support in an upcoming patch
On 2/4/20 11:53 AM, Max Reitz wrote:
On 31.01.20 18:44, Eric Blake wrote:
Having two slightly-different function names for related purposes is
unwieldy, especially since I envision adding yet another notion of
zero support in an upcoming patch. It doesn't help that
bdrv_has_zero_init() is a mis
On 2/4/20 11:32 AM, Max Reitz wrote:
On 31.01.20 18:44, Eric Blake wrote:
Based-on: <20200124103458.1525982-2-david.edmond...@oracle.com>
([PATCH v2 1/2] qemu-img: Add --target-is-zero to convert)
I'm working on adding an NBD extension that reports whether an image
is already all zero when the
On 31.01.20 18:44, Eric Blake wrote:
> Having two slightly-different function names for related purposes is
> unwieldy, especially since I envision adding yet another notion of
> zero support in an upcoming patch. It doesn't help that
> bdrv_has_zero_init() is a misleading name (I originally thoug
On 2/4/20 11:34 AM, Max Reitz wrote:
+++ b/include/block/block.h
@@ -105,6 +105,16 @@ typedef enum {
* for drivers that set .bdrv_co_truncate.
*/
BDRV_ZERO_TRUNCATE = 0x2,
+
+/*
+ * bdrv_known_zeroes() should include this bit if an image is
+ * known to read
On 2/4/20 11:42 AM, Max Reitz wrote:
I understand that this is preexisting logic, but could I ask: why?
What's wrong
if driver can guarantee that created file is all-zero, but is not sure
about
file resizing? I agree that it's normal for these flags to have the same
value,
but what is the reaso
On 04.02.20 16:35, Vladimir Sementsov-Ogievskiy wrote:
> 31.01.2020 20:44, Eric Blake wrote:
>> Having two slightly-different function names for related purposes is
>> unwieldy, especially since I envision adding yet another notion of
>> zero support in an upcoming patch. It doesn't help that
>> b
On 31.01.20 18:44, Eric Blake wrote:
> Knowing that a file reads as all zeroes when created is useful, but
> limited in scope to drivers that can create images. However, there
> are also situations where pre-existing images can quickly be
> determined to read as all zeroes, even when the image was
On 31.01.20 18:44, Eric Blake wrote:
> Based-on: <20200124103458.1525982-2-david.edmond...@oracle.com>
> ([PATCH v2 1/2] qemu-img: Add --target-is-zero to convert)
>
> I'm working on adding an NBD extension that reports whether an image
> is already all zero when the client first connects. I init
On 1/30/20 5:32 PM, Philippe Mathieu-Daudé wrote:
Hello,
These are mechanical sed patches used to convert the
code base to Python 3, as suggested on this thread:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg675024.html
Since v1:
- new checkpatch.pl patch
- addressed Kevin and Vladimir
Make bdrv_child_cb_attach() call bdrv_backing_attach() for children with
a COW role (and drop the reverse call from bdrv_backing_attach()), so it
can be used for any child (with a proper role set).
Because so far no child has a proper role set, we need a temporary new
callback for child_backing.at
bdrv_default_perms() can decide which permission profile to use based on
the BdrvChildRole, so block drivers do not need to select it explicitly.
The blkverify driver now no longer shares the WRITE permission for the
image to verify. We thus have to adjust two places in
test-block-iothread not to
Signed-off-by: Max Reitz
---
block.c | 30 +-
include/block/block_int.h | 1 -
tests/test-bdrv-drain.c | 8 +++-
3 files changed, 4 insertions(+), 35 deletions(-)
diff --git a/block.c b/block.c
index b6e35ed552..e3390e8d41 100644
--- a/block.
These calls have no real use for the child role yet, but it will not
harm to give one.
Notably, the bdrv_root_attach_child() call in blockjob.c is left
unmodified because there is not much the generic BlockJob object wants
from its children.
Signed-off-by: Max Reitz
---
block/block-backend.c |
Signed-off-by: Max Reitz
---
block.c | 12 ++--
include/block/block_int.h | 10 --
2 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/block.c b/block.c
index 747a2973f5..091e9cc16a 100644
--- a/block.c
+++ b/block.c
@@ -2194,12 +2194,12 @@ int bdrv_c
Implementations should decide the necessary permissions based on @role.
Signed-off-by: Max Reitz
---
block.c | 45 -
block/backup-top.c | 3 +--
block/blkdebug.c| 3 +--
block/blklogwrites.c| 3 +--
block/com
Commonly, they need to pass the BDRV_CHILD_IMAGE set as the
BdrvChildRole; but there are exceptions for drivers with external data
files (qcow2 and vmdk).
Signed-off-by: Max Reitz
---
block/bochs.c | 4 ++--
block/cloop.c | 4 ++--
block/crypto.c| 4 ++--
block/dmg.c | 4 ++
Replace child_file by child_of_bds in all remaining places (excluding
tests).
Signed-off-by: Max Reitz
---
block.c | 3 ++-
block/backup-top.c | 4 ++--
block/blklogwrites.c | 4 ++--
block/blkreplay.c| 5 +++--
block/raw-format.c | 15 +--
5 files changed, 2
Signed-off-by: Max Reitz
---
block.c | 19 ---
include/block/block_int.h | 11 ---
2 files changed, 30 deletions(-)
diff --git a/block.c b/block.c
index 091e9cc16a..b6e35ed552 100644
--- a/block.c
+++ b/block.c
@@ -2317,25 +2317,6 @@ static void bdrv_def
Signed-off-by: Max Reitz
---
block.c | 62 +++
include/block/block_int.h | 1 -
2 files changed, 4 insertions(+), 59 deletions(-)
diff --git a/block.c b/block.c
index 6b705ee23a..e245b5d8d9 100644
--- a/block.c
+++ b/block.c
@@ -1169,15 +116
Split raw_read_options() into one function that actually just reads the
options, and another that applies them. This will allow us to detect
whether the user has specified any options before attaching the file
child (so we can decide on its role based on the options).
Signed-off-by: Max Reitz
--
Signed-off-by: Max Reitz
---
tests/test-bdrv-drain.c | 29 +
tests/test-bdrv-graph-mod.c | 6 --
2 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/tests/test-bdrv-drain.c b/tests/test-bdrv-drain.c
index 15393a0140..91567ca97d 100644
--- a/tests/
Signed-off-by: Max Reitz
---
block.c | 71 +
1 file changed, 46 insertions(+), 25 deletions(-)
diff --git a/block.c b/block.c
index b26ec10cce..b7999696d4 100644
--- a/block.c
+++ b/block.c
@@ -2318,6 +2318,50 @@ static void
bdrv_default_p
This callback can be used by BDSs that use child_of_bds with the
appropriate BdrvChildRole for their children.
Also, make bdrv_format_default_perms() use it for child_of_bds children
(just a temporary solution until we can drop bdrv_format_default_perms()
altogether).
Signed-off-by: Max Reitz
--
Note that some filters have secondary children, namely blkverify (the
image to be verified) and blklogwrites (the log). This patch does not
touch those children.
Note that for blkverify, the filtered child should not be format-probed.
While there is nothing enforcing this here, in practice, it wi
Both users (quorum and blkverify) use child_format for
not-really-filtered children, so the appropriate BdrvChildRole in both
cases is DATA. (Note that this will cause bdrv_inherited_options() to
force-allow format probing.)
Signed-off-by: Max Reitz
---
block/blkverify.c | 4 ++--
block/quorum.
Signed-off-by: Max Reitz
---
block.c | 26 --
block/backup-top.c | 2 +-
block/vvfat.c | 3 ++-
tests/test-bdrv-drain.c | 13 +++--
4 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/block.c b/block.c
index 77755f0c6c.
Make bdrv_child_cb_detach() call bdrv_backing_detach() for children with
a COW role (and drop the reverse call from bdrv_backing_detach()), so it
can be used for any child (with a proper role set).
Because so far no child has a proper role set, we need a temporary new
callback for child_backing.de
The other two .inherit_options implementations specify exactly for what
case they are used in their name, so do it for this one as well.
(The actual intention behind this patch is to follow it up with a
generic bdrv_inherited_options() that works for all three cases.)
Signed-off-by: Max Reitz
--
Signed-off-by: Max Reitz
---
block.c | 62 +
1 file changed, 40 insertions(+), 22 deletions(-)
diff --git a/block.c b/block.c
index 39ba6aad0a..b26ec10cce 100644
--- a/block.c
+++ b/block.c
@@ -2280,6 +2280,44 @@ void bdrv_filter_default_pe
We plan to unify the generic .inherit_options() functions. The
resulting common function will need to decide whether to force-enable
format probing, force-disable it, or leave it as-is. To make this
decision, it will need to know whether the parent node is a format node
or not (because we never w
Signed-off-by: Max Reitz
---
block.c | 29 -
include/block/block_int.h | 1 -
2 files changed, 30 deletions(-)
diff --git a/block.c b/block.c
index 994a037730..77755f0c6c 100644
--- a/block.c
+++ b/block.c
@@ -1126,35 +1126,6 @@ const BdrvChildClass
After the series this patch belongs to, we want to have a common
BdrvChildClass that encompasses all of child_file, child_format, and
child_backing. Such a single class needs a single .inherit_options()
implementation, and this patch introduces it.
The next patch will show how the existing implem
For now, it is always set to 0. Later patches in this series will
ensure that all callers pass an appropriate combination of flags.
Signed-off-by: Max Reitz
---
block.c | 11 ---
block/backup-top.c | 3 ++-
block/blkdebug.c| 2 +-
block/blklogw
Signed-off-by: Max Reitz
---
block.c | 22 --
block/backup-top.c | 3 ++-
block/blkdebug.c| 5 +++--
block/blklogwrites.c| 9 +
block/commit.c | 1 +
block/copy-on-read.c| 1 +
block/mirror.c
Let child_file's, child_format's, and child_backing's .inherit_options()
implementations fall back to bdrv_inherited_options() to show that it
would really work for all of these cases, if only the parents passed the
appropriate BdrvChildRole and parent_is_format values.
(Also, make bdrv_open_inher
We can be less restrictive about pure data children than those with
metadata on them.
For bdrv_format_default_perms(), we keep the safe option of
bdrv_default_perms_for_metadata() (until we drop
bdrv_format_default_perms() altogether).
That means that bdrv_default_perms_for_data() is unused at th
bdrv_format_default_perms() has one code path for backing files, and one
for storage files. We want to pull them out into own functions, so
make sure they are completely distinct before so the next patches will
be a bit cleaner.
Signed-off-by: Max Reitz
---
block.c | 19 +--
1 f
This structure nearly only contains parent callbacks for child state
changes. It cannot really reflect a child's role, because different
roles may overlap (as we will see when real roles are introduced), and
because parents can have custom callbacks even when the child fulfills a
standard role.
S
Any current user of child_file, child_format, and child_backing can and
should use this generic BdrvChildClass instead, as it can handle all of
these cases. However, to be able to do so, the users must pass the
appropriate BdrvChildRole when the child is created/attached. (The
following commits w
Based-on: <20200130214431.333510-1-mre...@redhat.com>
(“block: Fix check_to_replace_node()”)
Branch: https://github.com/XanClic/qemu.git child-role-v2
Branch: https://git.xanclic.moe/XanClic/qemu.git child-role-v2
v1: https://lists.nongnu.org/archive/html/qemu-block/2019-11/msg00908.html
Hi,
F
Signed-off-by: Max Reitz
---
block.c | 40 +++
block/block-backend.c | 3 ++-
block/vvfat.c | 3 ++-
include/block/block_int.h | 3 ++-
4 files changed, 30 insertions(+), 19 deletions(-)
diff --git a/block.c b/block.c
index
This enum will supplement BdrvChildClass when it comes to what role (or
combination of roles) a child takes for its parent.
Because empty enums are not allowed, let us just start with it filled.
Signed-off-by: Max Reitz
---
include/block/block.h | 27 +++
1 file changed,
We want to unify child_format and child_file at some point. One of the
important things that set format drivers apart from other drivers is
that they do not expect other format nodes under them (except in the
backing chain). That means we need something on which to distinguish
format drivers from
On Tue, Feb 04, 2020 at 10:51:42AM +0100, Klaus Jensen wrote:
> Hi,
>
>
> Changes since v4
> - Changed vendor and device id to use a Red Hat allocated one. For
>backwards compatibility add the 'x-use-intel-id' nvme device
>parameter. This is off by default but is added as a machine compa
On Tue, Feb 04, 2020 at 10:52:08AM +0100, Klaus Jensen wrote:
> Signed-off-by: Klaus Jensen
> ---
> hw/block/nvme-ns.c | 2 +-
> hw/block/nvme-ns.h | 4 +++-
> hw/block/nvme.c| 1 +
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/hw/block/nvme-ns.c b/hw/block/nvme-ns.c
>
On Tue, Feb 04, 2020 at 10:52:06AM +0100, Klaus Jensen wrote:
> There are two reasons for changing this:
>
> 1. The nvme device currently uses an internal Intel device id.
>
> 2. Since commits "nvme: fix write zeroes offset and count" and "nvme:
> support multiple namespaces" the control
On Tue, Feb 04, 2020 at 10:52:04AM +0100, Klaus Jensen wrote:
> This adds support for multiple namespaces by introducing a new 'nvme-ns'
> device model. The nvme device creates a bus named from the device name
> ('id'). The nvme-ns devices then connect to this and registers
> themselves with the nv
04.02.2020 18:49, Eric Blake wrote:
On 2/4/20 9:35 AM, Vladimir Sementsov-Ogievskiy wrote:
31.01.2020 20:44, Eric Blake wrote:
Having two slightly-different function names for related purposes is
unwieldy, especially since I envision adding yet another notion of
zero support in an upcoming patc
On 30/01/20 17:32, Philippe Mathieu-Daudé wrote:
> Hello,
>
> These are mechanical sed patches used to convert the
> code base to Python 3, as suggested on this thread:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg675024.html
>
> Since v1:
> - new checkpatch.pl patch
> - addressed Kevi
On 2/4/20 9:35 AM, Vladimir Sementsov-Ogievskiy wrote:
31.01.2020 20:44, Eric Blake wrote:
Having two slightly-different function names for related purposes is
unwieldy, especially since I envision adding yet another notion of
zero support in an upcoming patch. It doesn't help that
bdrv_has_zer
31.01.2020 20:44, Eric Blake wrote:
Having two slightly-different function names for related purposes is
unwieldy, especially since I envision adding yet another notion of
zero support in an upcoming patch. It doesn't help that
bdrv_has_zero_init() is a misleading name (I originally thought that
On 2/4/20 9:03 AM, Vladimir Sementsov-Ogievskiy wrote:
31.01.2020 20:44, Eric Blake wrote:
Several drivers supply .bdrv_has_zero_init that returns 1, but lack
the .bdrv_has_zero_init_truncate callback (parallels and qed outright,
vdi in some scenarios). A literal reading of the existing
documen
31.01.2020 20:44, Eric Blake wrote:
block_int.h claims that .bdrv_has_zero_init must return 0 if
.bdrv_has_zero_init_truncate does likewise; but this is violated if
Hmm, you changed this in patch 04..
only the former callback is provided if .bdrv_co_truncate also exists.
When adding the latte
31.01.2020 20:44, Eric Blake wrote:
block.c already defaults to 0 if we don't provide a callback; there's
no need to write a callback that always fails.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
31.01.2020 20:44, Eric Blake wrote:
Several drivers supply .bdrv_has_zero_init that returns 1, but lack
the .bdrv_has_zero_init_truncate callback (parallels and qed outright,
vdi in some scenarios). A literal reading of the existing
documentation says such drivers are broken, because
bdrv_has_ze
31.01.2020 20:44, Eric Blake wrote:
As the feature name table can be quite large (over 9k if all 64 bits
of all three feature fields have names; a mere 8 features leaves only
8 bytes for a backing file name in a 512-byte cluster), it is unwise
to emit this optional header in images with small clu
On 2/4/20 12:53 AM, Cédric Le Goater wrote:
On 2/3/20 7:09 PM, Guenter Roeck wrote:
Always report 6 bytes of JEDEC data. Fill remaining data with 0.
For unsupported commands, keep sending a value of 0 until the chip
is deselected.
Both changes avoid attempts to decode random commands. Up to no
31.01.2020 20:44, Eric Blake wrote:
The feature table is supposed to advertise the name of all feature
bits that we support; however, we forgot to update the table for
autoclear bits. While at it, move the table to read-only memory in
code, and tweak the qcow2 spec to name the second autoclear b
On 2/4/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
I understand that it is safer to have restrictions now and lift them
later, than to allow use of the option at any time and leave room for
the user to shoot themselves in the foot with no way to add safety
later. The argument against no b
On Tuesday, 2020-02-04 at 16:59:39 +03, Vladimir Sementsov-Ogievskiy wrote:
> 04.02.2020 12:52, David Edmondson wrote:
>> In many cases the target of a convert operation is a newly provisioned
>> target that the user knows is blank (filled with zeroes). In this
>> situation there is no requirement
On Tuesday, 2020-02-04 at 07:31:52 -06, Eric Blake wrote:
> On 2/4/20 3:52 AM, David Edmondson wrote:
>> In many cases the target of a convert operation is a newly provisioned
>> target that the user knows is blank (filled with zeroes). In this
>
> 'filled with zeroes' is accurate for a preallocat
On 2/3/20 11:45 PM, Cédric Le Goater wrote:
On 2/3/20 7:09 PM, Guenter Roeck wrote:
The Linux kernel recently started using FAST_READ_4 commands.
This results in flash read failures. At the same time, the m25p80
emulation is seen to read 8 more bytes than expected. Adjusting the
expected number
On 2/3/20 11:16 PM, Cédric Le Goater wrote:
On 2/3/20 7:09 PM, Guenter Roeck wrote:
While at it, add some trace messages to help debug problems
seen when running the latest Linux kernel.
Signed-off-by: Guenter Roeck
Reviewed-by: Cédric Le Goater
We have been chasing a bug for years on the
31.01.2020 20:44, Eric Blake wrote:
Various trivial typos noticed while working on this file.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
31.01.2020 0:44, Max Reitz wrote:
Signed-off-by: Max Reitz
---
tests/qemu-iotests/iotests.py | 56 +++
1 file changed, 56 insertions(+)
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 01b58dcb50..69861cf05e 100644
--- a/tests/q
04.02.2020 16:31, Eric Blake wrote:
On 2/4/20 3:52 AM, David Edmondson wrote:
In many cases the target of a convert operation is a newly provisioned
target that the user knows is blank (filled with zeroes). In this
'filled with zeroes' is accurate for a preallocated image, but reads awkwardly
04.02.2020 12:52, David Edmondson wrote:
In many cases the target of a convert operation is a newly provisioned
target that the user knows is blank (filled with zeroes). In this
situation there is no requirement for qemu-img to wastefully zero out
the entire device.
Add a new option, --target-is
On 2/4/20 7:01 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
There are some ideas, which needs extra arguments in NBD request:
1. Selecting metacontext for NBD_BLOCK_STATUS [Nir], possibly through new
command, instead of extending the original [Wouter]
2. 64bit block-status/write-zeroes [I k
On 2/4/20 3:52 AM, David Edmondson wrote:
In many cases the target of a convert operation is a newly provisioned
target that the user knows is blank (filled with zeroes). In this
'filled with zeroes' is accurate for a preallocated image, but reads
awkwardly for a sparse image; it might be bett
04.02.2020 16:12, Eric Blake wrote:
On 2/3/20 11:45 AM, Vladimir Sementsov-Ogievskiy wrote:
31.01.2020 20:44, Eric Blake wrote:
With the recent introduction of BDRV_ZERO_OPEN, we can optimize
various qemu-img operations if we know the destination starts life
with all zero content. For an image
On 2/3/20 11:45 AM, Vladimir Sementsov-Ogievskiy wrote:
31.01.2020 20:44, Eric Blake wrote:
With the recent introduction of BDRV_ZERO_OPEN, we can optimize
various qemu-img operations if we know the destination starts life
with all zero content. For an image with no cluster allocations and
no b
Hi all!
There are some ideas, which needs extra arguments in NBD request:
1. Selecting metacontext for NBD_BLOCK_STATUS [Nir], possibly through new
command, instead of extending the original [Wouter]
2. 64bit block-status/write-zeroes [I know about Eric's work on all-zero check,
but I think, th
On 2/4/20 9:53 AM, Cédric Le Goater wrote:
On 2/3/20 7:09 PM, Guenter Roeck wrote:
Always report 6 bytes of JEDEC data. Fill remaining data with 0.
For unsupported commands, keep sending a value of 0 until the chip
is deselected.
Both changes avoid attempts to decode random commands. Up to now
Hi Guenter,
On 2/3/20 7:09 PM, Guenter Roeck wrote:
Always report 6 bytes of JEDEC data. Fill remaining data with 0.
For unsupported commands, keep sending a value of 0 until the chip
is deselected.
Two changes, I'd rather see 2 patches. If you happen to respin they are
welcome. As the split
On 2/3/20 7:09 PM, Guenter Roeck wrote:
While at it, add some trace messages to help debug problems
seen when running the latest Linux kernel.
Signed-off-by: Guenter Roeck
---
hw/block/m25p80.c | 48 ---
hw/block/trace-events | 16 +++
31.01.2020 0:44, Max Reitz wrote:
All tearDowns in 041 shutdown the VM. Thus, test cases do not need to
do it themselves (unless they need the VM to be down for some
post-operation check).
Signed-off-by: Max Reitz
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
Patchew URL:
https://patchew.org/QEMU/20200204095208.269131-1-k.jen...@samsung.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH v5 00/26] nvme: support NVMe v1.3d, SGLs and multiple namespaces
Message-id: 20200204095208.2691
31.01.2020 0:44, Max Reitz wrote:
Signed-off-by: Max Reitz
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
31.01.2020 0:44, Max Reitz wrote:
Signed-off-by: Max Reitz
You forget my r-b:
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
31.01.2020 0:44, Max Reitz wrote:
Signed-off-by: Max Reitz
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
On Monday, 2020-02-03 at 21:20:16 +03, Vladimir Sementsov-Ogievskiy wrote:
> 24.01.2020 13:34, David Edmondson wrote:
>> In many cases the target of a convert operation is a newly provisioned
>> target that the user knows is blank (filled with zeroes). In this
>> situation there is no requirement
Signed-off-by: Klaus Jensen
---
hw/block/nvme-ns.c | 2 +-
hw/block/nvme-ns.h | 4 +++-
hw/block/nvme.c| 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/block/nvme-ns.c b/hw/block/nvme-ns.c
index 0e5be44486f4..981d7101b8f2 100644
--- a/hw/block/nvme-ns.c
+++ b/hw/block/
Since clean up of the request qsg/iov has been moved to the common
nvme_enqueue_req_completion function, there is no need to use a
stack allocated qsg/iov in nvme_dma_prp.
Signed-off-by: Klaus Jensen
---
hw/block/nvme.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
d
The command struct is available in the NvmeRequest that we generally
pass around anyway.
Signed-off-by: Klaus Jensen
---
hw/block/nvme.c | 198
1 file changed, 98 insertions(+), 100 deletions(-)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
inde
Required for compliance with NVMe revision 1.2.1 or later. See NVM
Express 1.2.1, Section 5.11 ("Identify command"), Figure 90 and Section
7.9 ("NVMe Qualified Names").
This also bumps the supported version to 1.2.1.
Signed-off-by: Klaus Jensen
---
hw/block/nvme.c | 13 ++---
1 file cha
This refactors how the device issues asynchronous block backend
requests. The NvmeRequest now holds a queue of NvmeAIOs that are
associated with the command. This allows multiple aios to be issued for
a command. Only when all requests have been completed will the device
post a completion queue entr
There are two reasons for changing this:
1. The nvme device currently uses an internal Intel device id.
2. Since commits "nvme: fix write zeroes offset and count" and "nvme:
support multiple namespaces" the controller device no longer has
the quirks that the Linux kernel think it ha
On 30.01.2020 17:58, Stefan Hajnoczi wrote:
On Wed, Jan 29, 2020 at 05:07:00PM +0300, Denis Plotnikov wrote:
The goal is to reduce the amount of requests issued by a guest on
1M reads/writes. This rises the performance up to 4% on that kind of
disk access pattern.
The maximum chunk size to b
0x is not an allowed value for NCQR and NSQR in Set Features on
Number of Queues.
Signed-off-by: Klaus Jensen
---
hw/block/nvme.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 30c5b3e7a67d..900732bb2f38 100644
--- a/hw/block/nvme.c
+++ b/hw/b
In many cases the target of a convert operation is a newly provisioned
target that the user knows is blank (filled with zeroes). In this
situation there is no requirement for qemu-img to wastefully zero out
the entire device.
Add a new option, --target-is-zero, allowing the user to indicate that
a
This adds support for multiple namespaces by introducing a new 'nvme-ns'
device model. The nvme device creates a bus named from the device name
('id'). The nvme-ns devices then connect to this and registers
themselves with the nvme device.
This changes how an nvme device is created. Example with t
qemu-img: Add --target-is-zero to indicate that a target is blank
v3:
- Merge with the rST docs.
- No more need to fix @var -> @code.
v2:
- Remove target_is_zero, preferring to set has_zero_init
directly (Mark Kanda).
- Disallow --target-is-zero in the presence of a backing file (Max
Reitz)
For now, support the Data Block, Segment and Last Segment descriptor
types.
See NVM Express 1.3d, Section 4.4 ("Scatter Gather List (SGL)").
Signed-off-by: Klaus Jensen
Acked-by: Fam Zheng
---
block/nvme.c | 18 +-
hw/block/nvme.c | 375 +++--
The nvme device needs to know the return value of dma_memory_rw to pass
block/011 from blktests. So pass it along instead of ignoring it.
There are no existing users of the return value, so this patch should be
safe.
Signed-off-by: Klaus Jensen
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: M
The emulated nvme device (hw/block/nvme.c) is currently using an
internal Intel device id.
Prepare to change that by allocating a device id under the 1b36 (Red
Hat, Inc.) vendor id.
Signed-off-by: Klaus Jensen
---
MAINTAINERS| 1 +
docs/specs/nvme.txt| 10 ++
docs/specs
Handling DMA errors gracefully is required for the device to pass the
block/011 test ("disable PCI device while doing I/O") in the blktests
suite.
With this patch the device passes the test by retrying "critical"
transfers (posting of completion entries and processing of submission
queue entries).
Required for compliance with NVMe revision 1.2.1. See NVM Express 1.2.1,
Section 5.2 ("Asynchronous Event Request command").
Mostly imported from Keith's qemu-nvme tree. Modified with a max number
of queued events (controllable with the aer_max_queued device
parameter). The spec states that the co
Refactor nvme_map_prp and allow PRPs to be located in the CMB. The logic
ensures that if some of the PRP is in the CMB, all of it must be located
there, as per the specification.
Also combine nvme_dma_{read,write}_prp into a single nvme_dma_prp that
takes an additional DMADirection parameter.
Sig
This patch splits up nvme_realize into multiple individual functions,
each initializing a different subset of the device.
Signed-off-by: Klaus Jensen
---
hw/block/nvme.c | 175 +++-
hw/block/nvme.h | 21 ++
2 files changed, 133 insertions(+), 63 d
1 - 100 of 117 matches
Mail list logo