[fixing some of my editing errors]
On Fri, Jun 09, 2023 at 10:42:25AM -0500, Eric Blake wrote:
[...]
>
> The tl;dr summary of the above discourse:
> There are two orthogonal communications going on:
>
> libnbd <-> server choice of NBD_REPLY_TYPE_BLOCK_STATUS{,_EXT}
> app <-> libnbd choice
This is another caller of bdrv_get_allocated_file_size() that needs to
be converted to a coroutine because that function will be made
asynchronous when called (indirectly) from the QMP dispatcher.
This QMP command is a candidate because it calls bdrv_do_query_node_info(),
which in turn calls
We're converting callers of bdrv_get_allocated_file_size() to run in
coroutines because that function will be made asynchronous when called
(indirectly) from the QMP dispatcher.
This function is a candidate because it calls bdrv_do_query_node_info(),
which in turn calls
The last call site of this function has been removed by commit
c04d0ab026 ("qemu-img: Let info print block graph").
Reviewed-by: Claudio Fontana
Signed-off-by: Fabiano Rosas
---
block/qapi.c | 27 ---
include/block/qapi.h | 3 ---
2 files changed, 30
We're converting callers of bdrv_get_allocated_file_size() to run in
coroutines because that function will be made asynchronous when called
(indirectly) from the QMP dispatcher.
This function is a candidate because it calls bdrv_query_image_info()
-> bdrv_do_query_node_info() ->
From: Lin Ma
We're converting callers of bdrv_get_allocated_file_size() to run in
coroutines because that function will be made asynchronous when called
(indirectly) from the QMP dispatcher.
This QMP command is a candidate because it indirectly calls
bdrv_get_allocated_file_size() through
Hi,
The major change from the last version is that this time I'm moving
all of the callers of bdrv_get_allocated_file_size() into
coroutines. I had to make some temporary changes to avoid asserts
while not all the callers were converted.
I tried my best to explain why I think the changes are
Some callers of this function are about to be converted to run in
coroutines, so allow it to be executed both inside and outside a
coroutine while we convert all the callers.
This will be reverted once all callers of bdrv_do_query_node_info run
in a coroutine.
Signed-off-by: Fabiano Rosas
The following patches will add co_wrapper annotations to functions
declared in qapi.h. Add that header to the set of files used by
block-coroutine-wrapper.py.
Signed-off-by: Fabiano Rosas
---
block/meson.build | 1 +
scripts/block-coroutine-wrapper.py | 1 +
2 files changed, 2
We're currently doing a full query-block just to enumerate the devices
for qmp_nbd_server_add and then discarding the BlockInfoList
afterwards. Alter hmp_nbd_server_start to instead iterate explicitly
over the block_backends list.
This allows the removal of the dependency on qmp_query_block from
The commit 5d8813593f ("block/qapi: Let bdrv_query_image_info()
recurse") removed the loop where we set the 'bs0' variable, so now it
is just the same as 'bs'.
Signed-off-by: Fabiano Rosas
---
block/qapi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/block/qapi.c
From: João Silva
The fstat call can take a long time to finish when running over
NFS. Add a version of it that runs in the thread pool.
Adapt one of its users, raw_co_get_allocated_file size to use the new
version. That function is called via QMP under the qemu_global_mutex
so it has a large
This will enable CMD646-specific fields to be added to CMD6464IDEState in
future.
Signed-off-by: Mark Cave-Ayland
---
hw/ide/cmd646.c | 4 +++-
include/hw/ide/cmd646.h | 38 ++
2 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644
This is to allow us to use the cmd646_bmdma_ops name for the CMD646
device-specific registers in the next commit.
Signed-off-by: Mark Cave-Ayland
---
hw/ide/cmd646.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index
Signed-off-by: Mark Cave-Ayland
---
hw/ide/cmd646.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index a68357c1c5..20f1e41d57 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -96,7 +96,7 @@ static uint64_t
The aim here is to eliminate any device-specific registers from the main BMDMA
bar memory region so it can potentially be moved into the shared PCI IDE device.
For each BMDMA bus create a new cmd646-bmdma-specific memory region representing
the device-specific BMDMA registers and then map them
Signed-off-by: Mark Cave-Ayland
---
hw/alpha/dp264.c | 4 ++--
hw/sparc64/sun4u.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
index 03495e1e60..f2affecad9 100644
--- a/hw/alpha/dp264.c
+++ b/hw/alpha/dp264.c
@@ -13,7 +13,7 @@
This series follows on from a comment I made on Bernhard's PCI IDE tidy-up
series [1]
that it should be possible to further consolidate the BMDMA registers into the
PCI
IDE device with some minor rework to the CMD646 device.
It does this by moving the CMD646 device-specific BMDMA registers to a
On Fri, Jun 09, 2023 at 11:39:27AM +0200, Laszlo Ersek wrote:
> Fair warning: this patch has made me both very excited and very
> uncomfortable; that's the reason my style might come across as
> needlessly "combative". I don't mean to be combative. It's just how my
> thoughts have come out, and
From: Niklas Cassel
The AHCI spec states that:
For NCQ, PxCI is cleared on command queued successfully.
For non-NCQ, PxCI is cleared on command completed successfully.
(A non-NCQ command that completes with error does not clear PxCI.)
The current QEMU implementation either clears PxCI in
On 09.06.23 15:21, Alexander Ivanov wrote:
On 6/2/23 16:59, Hanna Czenczek wrote:
On 29.05.23 17:15, Alexander Ivanov wrote:
Repair an image at opening if the image is unclean or out-of-image
corruption was detected.
Signed-off-by: Alexander Ivanov
---
block/parallels.c | 65
From: Niklas Cassel
The way that BUSY + PxCI is cleared for NCQ (FPDMA QUEUED) commands is
described in SATA 3.5a Gold:
11.15 FPDMA QUEUED command protocol
DFPDMAQ2: ClearInterfaceBsy
"Transmit Register Device to Host FIS with the BSY bit cleared to zero
and the DRQ bit cleared to zero and
From: Niklas Cassel
When there is an error, we need to raise a TFES error irq, see AHCI 1.3.1,
5.3.13.1 SDB:Entry.
If ERR_STAT is set, we jump to state ERR:FatalTaskfile, which will raise
a TFES IRQ unconditionally, regardless if the I bit is set in the FIS or
not.
Thus, we should never raise
From: Niklas Cassel
Currently, the first time sending an unsupported command
(e.g. READ LOG DMA EXT) will not have ERR_STAT set in the completion.
Sending the unsupported command again, will correctly have ERR_STAT set.
When ide_cmd_permitted() returns false, it calls ide_abort_command().
From: Niklas Cassel
According to AHCI 1.3.1 definition of PxSACT:
This field is cleared when PxCMD.ST is written from a '1' to a '0' by
software. This field is not cleared by a COMRESET or a software reset.
According to AHCI 1.3.1 definition of PxCI:
This field is also cleared when PxCMD.ST is
On Wed, May 24, 2023 at 01:19:00PM +0200, Klaus Jensen wrote:
> From: Klaus Jensen
>
> A set of fixes and small quality-of-life improvements for the TP4146
> ("Flexible Data Placement") support.
>
> Klaus Jensen (4):
> hw/nvme: fix verification of number of ruhis
> hw/nvme: verify
From: Niklas Cassel
When encountering an NCQ error, you should not write the NCQ tag to the
SError register. This is completely wrong.
The SError register has a clear definition, where each bit represents a
different error, see PxSERR definition in AHCI 1.3.1.
If we write a random value (like
From: Niklas Cassel
Hello John,
Here comes some misc AHCI cleanups.
Most are related to error handling.
Please review.
Changes since v2:
-Squashed in the test commits that were sent out as a separate series into
the patch "hw/ide/ahci: PxCI should not get cleared when ERR_STAT is set",
and
On 6/2/23 16:59, Hanna Czenczek wrote:
On 29.05.23 17:15, Alexander Ivanov wrote:
Repair an image at opening if the image is unclean or out-of-image
corruption was detected.
Signed-off-by: Alexander Ivanov
---
block/parallels.c | 65 +--
1
From: Niklas Cassel
For NCQ, PxCI is cleared on command queued successfully.
For non-NCQ, PxCI is cleared on command completed successfully.
Successfully means ERR_STAT, BUSY and DRQ are all cleared.
A command that has ERR_STAT set, does not get to clear PxCI.
See AHCI 1.3.1, section 5.3.8,
From: Niklas Cassel
This backslash obviously does not belong here, so remove it.
Signed-off-by: Niklas Cassel
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: John Snow
---
hw/ide/ahci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index
On Mon, 29 May 2023 at 16:16, Alexander Ivanov
wrote:
>
> If the check is called during normal work, tracking of the check must be
> present in VM logs to have some clues if something going wrong with user's
> data.
>
> Signed-off-by: Alexander Ivanov
> Reviewed-by: Denis V. Lunev
> ---
>
On 6/2/23 16:48, Hanna Czenczek wrote:
On 29.05.23 17:15, Alexander Ivanov wrote:
If the check is called during normal work, tracking of the check must be
present in VM logs to have some clues if something going wrong with
user's
data.
I understand stderr counts as part of the VM log,
Fair warning: this patch has made me both very excited and very
uncomfortable; that's the reason my style might come across as
needlessly "combative". I don't mean to be combative. It's just how my
thoughts have come out, and (unfortunately) I need to go pick up my son
now, and don't have time for
09.06.2023 11:54, Denis V. Lunev wrote:
On 6/7/23 17:14, Hanna Czenczek wrote:
..>>> This, and a few other parallels changes in this series:
Should these be applied to -stable too, or is it not important?
Personally, I don’t think they need to be in stable; but I’ll leave the final
judgment
On 6/7/23 17:14, Hanna Czenczek wrote:
On 07.06.23 08:51, Michael Tokarev wrote:
05.06.2023 18:45, Hanna Czenczek wrote:
From: Alexander Ivanov
data_end field in BDRVParallelsState is set to the biggest offset
present
in BAT. If this offset is outside of the image, any further write will
bdrv_pad_request() relies on requests' lengths not to exceed SIZE_MAX,
which bdrv_check_qiov_request() does not guarantee.
bdrv_check_request32() however will guarantee this, and both of
bdrv_pad_request()'s callers (bdrv_co_preadv_part() and
bdrv_co_pwritev_part()) already run it before calling
On 08.06.23 11:52, Peter Maydell wrote:
On Mon, 5 Jun 2023 at 16:48, Hanna Czenczek wrote:
When processing vectored guest requests that are not aligned to the
storage request alignment, we pad them by adding head and/or tail
buffers for a read-modify-write cycle.
Hi; Coverity complains (CID
38 matches
Mail list logo
