On 05.08.21 16:36, Max Reitz wrote:
gluster's block-status implementation is basically a copy of that in
block/file-posix.c, there is only one thing missing, and that is
aligning trailing data extents to the request alignment (as added by
commit 9c3db310ff0).
Note that 9c3db310ff0 mentions that
The following changes since commit 88afdc92b644120e0182c8567e1b1d236e471b12:
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
(2021-09-05 15:48:42 +0100)
are available in the Git repository at:
https://gitlab.com/stefanha/qemu.git tags/block-pull-request
for you to
From: Philippe Mathieu-Daudé
Both qemu_vfio_find_fixed_iova() and qemu_vfio_find_temp_iova()
return an errno which is unused (or overwritten). Have them propagate
eventual errors to callers, returning a boolean (which is what the
Error API recommends, see commit e3fe3988d78 "error: Document Error
From: Philippe Mathieu-Daudé
Instead of displaying the error on stderr, use error_report()
which also report to the monitor.
Reviewed-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Klaus Jensen
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20210902070025.197072-3-phi...@redhat.c
From: Philippe Mathieu-Daudé
Fix when building with -Wshorten-64-to-32:
warning: implicit conversion loses integer precision: 'unsigned long' to
'int' [-Wshorten-64-to-32]
Reviewed-by: Klaus Jensen
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20210902070025.197072-2-phi...@redhat.com
From: Philippe Mathieu-Daudé
nvme_create_queue_pair() does not return a boolean value (indicating
eventual error) but a pointer, and is inconsistent in how it fills the
error handler. To fulfill callers expectations, always set an error
message on failure.
Reported-by: Auger Eric
Reviewed-by: K
From: Philippe Mathieu-Daudé
Simplify qemu_vfio_dma_[un]map() handlers by replacing a pair of
qemu_mutex_lock/qemu_mutex_unlock calls by the WITH_QEMU_LOCK_GUARD
macro.
Reviewed-by: Klaus Jensen
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20210902070025.197072-4-phi...@redhat.com
Signed-
From: Philippe Mathieu-Daudé
Extract qemu_vfio_water_mark_reached() for readability,
and have it provide an error hint it its Error* handle.
Suggested-by: Klaus Jensen
Reviewed-by: Klaus Jensen
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20210902070025.197072-8-phi...@redhat.com
Signed-
From: Philippe Mathieu-Daudé
To simplify qemu_vfio_dma_map():
- reduce 'ret' (returned value) scope by returning errno directly,
- remove the goto 'out' label.
Reviewed-by: Klaus Jensen
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20210902070025.197072-10-phi...@redhat.com
Signed-off-by:
From: Philippe Mathieu-Daudé
qemu_vfio_add_mapping() returns a pointer to an indexed entry
in pre-allocated QEMUVFIOState::mappings[], thus can not be NULL.
Remove the pointless check.
Reviewed-by: Klaus Jensen
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20210902070025.197072-5-phi...@re
From: Philippe Mathieu-Daudé
Pass qemu_vfio_do_mapping() an Error* argument so it can propagate
any error to callers. Replace error_report() which only report
to the monitor by the more generic error_setg_errno().
Reviewed-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Klaus Jensen
S
From: Philippe Mathieu-Daudé
We expect the first qemu_vfio_dma_map() to fail (indicating
DMA mappings exhaustion, see commit 15a730e7a3a). Do not
report the first failure as error, since we are going to
flush the mappings and retry.
This removes spurious error message displayed on the monitor:
From: Philippe Mathieu-Daudé
Currently qemu_vfio_dma_map() displays errors on stderr.
When using management interface, this information is simply
lost. Pass qemu_vfio_dma_map() an Error** handle so it can
propagate the error to callers.
Reviewed-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
Revie
On 12.08.21 10:41, Hanna Reitz wrote:
Hi,
See the cover letter from v1 for the general idea:
https://lists.nongnu.org/archive/html/qemu-block/2021-06/msg00843.html
Cover letter from v2, introducing RCU locking:
https://lists.nongnu.org/archive/html/qemu-block/2021-06/msg01060.html
v3:
- Patch
On 24.08.21 17:35, Hanna Reitz wrote:
Hi,
I’ve updated my pylint to 2.10.2 and was greeted with some new warnings.
Some are fixed by John’s “Run iotest linters during Python CI” series
(https://lists.nongnu.org/archive/html/qemu-block/2021-07/msg00611.html),
but some are not (namely unspecified-
On 02.09.21 11:40, Hanna Reitz wrote:
v1: https://lists.nongnu.org/archive/html/qemu-block/2021-03/msg01471.html
v2: https://lists.nongnu.org/archive/html/qemu-block/2021-05/msg00492.html
v3: https://lists.nongnu.org/archive/html/qemu-block/2021-05/msg00569.html
Hi,
Sorry for the long delay, h
On 02.09.21 12:15, Philippe Mathieu-Daudé wrote:
On 9/2/21 11:58 AM, Vladimir Sementsov-Ogievskiy wrote:
02.09.2021 12:40, Hanna Reitz wrote:
The AbnormalShutdown exception class is not in qemu.machine, but in
qemu.machine.machine. (qemu.machine.AbnormalShutdown was enough for
Python to find i
Ping – any thoughts on this?
Hanna
On 19.08.21 12:12, Hanna Reitz wrote:
We cannot write to images opened with O_DIRECT unless we allow them to
be resized so they are aligned to the sector size: Since 9c60a5d1978,
bdrv_node_refresh_perm() ensures that for nodes whose length is not
aligned to th
On 9/7/21 11:57 AM, Hanna Reitz wrote:
> On 02.09.21 12:15, Philippe Mathieu-Daudé wrote:
>> On 9/2/21 11:58 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> 02.09.2021 12:40, Hanna Reitz wrote:
The AbnormalShutdown exception class is not in qemu.machine, but in
qemu.machine.machine. (qemu.ma
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Thu, Sep 02, 2021 at 07:19:58AM -0300, Leonardo Bras Soares Passos wrote:
> > On Thu, Sep 2, 2021 at 6:50 AM Daniel P. Berrangé
> > wrote:
> > >
> > > On Thu, Sep 02, 2021 at 06:34:01AM -0300, Leonardo Bras Soares Passos
> > > wrote:
> > > >
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Sep 01, 2021 at 11:35:33AM -0400, Peter Xu wrote:
> > On Wed, Sep 01, 2021 at 09:53:07AM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Aug 31, 2021 at 04:29:09PM -0400, Peter Xu wrote:
> > > > On Tue, Aug 31, 2021 at 02:16:42PM +0100, Dan
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Thu, Sep 02, 2021 at 05:52:15AM -0300, Leonardo Bras Soares Passos wrote:
> > On Thu, Sep 2, 2021 at 5:21 AM Daniel P. Berrangé
> > wrote:
> > >
> > > On Thu, Sep 02, 2021 at 04:22:55AM -0300, Leonardo Bras Soares Passos
> > > wrote:
> > > >
19.08.2021 13:12, Hanna Reitz wrote:
We cannot write to images opened with O_DIRECT unless we allow them to
be resized so they are aligned to the sector size: Since 9c60a5d1978,
bdrv_node_refresh_perm() ensures that for nodes whose length is not
aligned to the request alignment and where someone
Finalizing the job may cause its AioContext to change. This is noted by
job_exit(), which points at job_txn_apply() to take this fact into
account.
However, job_completed() does not necessarily invoke job_txn_apply()
(through job_completed_txn_success()), but potentially also
job_completed_txn_ab
When a transaction is aborted, no result matters, and so all jobs within
should be force-cancelled.
Signed-off-by: Hanna Reitz
Reviewed-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
job.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/job.c b/job.c
ind
As of HEAD^, there is no meaning to s->synced other than whether the job
is READY or not. job_is_ready() gives us that information, too.
Suggested-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Hanna Reitz
Reviewed-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Kevin W
Most callers of job_is_cancelled() actually want to know whether the job
is on its way to immediate termination. For example, we refuse to pause
jobs that are cancelled; but this only makes sense for jobs that are
really actually cancelled.
A mirror job that is cancelled during READY with force=f
An error does not take us out of the READY phase, which is what
s->synced signifies. It does of course mean that source and target are
no longer in sync, but that is what s->actively_sync is for -- s->synced
never meant that source and target are in sync, only that they were at
some point (and at
We largely have two cancel modes for jobs:
First, there is actual cancelling. The job is terminated as soon as
possible, without trying to reach a consistent result.
Second, we have mirror in the READY state. Technically, the job is not
really cancelled, but it just is a different completion mo
Callers should be able to specify whether they want job_cancel_sync() to
force-cancel the job or not.
In fact, almost all invocations do not care about consistency of the
result and just want the job to terminate as soon as possible, so they
should pass force=true. The replication block driver is
mirror_drained_poll() returns true whenever the job is cancelled,
because "we [can] be sure that it won't issue more requests". However,
this is only true for force-cancelled jobs, so use job_is_cancelled().
Signed-off-by: Hanna Reitz
Reviewed-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogie
We must check whether the job is force-cancelled early in our main loop,
most importantly before any `continue` statement. For example, we used
to have `continue`s before our current checking location that are
triggered by `mirror_flush()` failing. So, if `mirror_flush()` kept
failing, force-canc
Test what happens when there is an I/O error after a mirror job in the
READY phase has been cancelled.
Signed-off-by: Hanna Reitz
Reviewed-by: Vladimir Sementsov-Ogievskiy
Tested-by: Vladimir Sementsov-Ogievskiy
---
.../tests/mirror-ready-cancel-error | 143 ++
.../te
Clearing .cancelled before leaving the main loop when the job has been
soft-cancelled is no longer necessary since job_is_cancelled() only
returns true for jobs that have been force-cancelled.
Therefore, this only makes a differences in places that call
job_cancel_requested(). In block/mirror.c,
On 07.09.21 13:29, Vladimir Sementsov-Ogievskiy wrote:
19.08.2021 13:12, Hanna Reitz wrote:
We cannot write to images opened with O_DIRECT unless we allow them to
be resized so they are aligned to the sector size: Since 9c60a5d1978,
bdrv_node_refresh_perm() ensures that for nodes whose length is
Hi,
v1 cover letter:
https://lists.nongnu.org/archive/html/qemu-block/2021-07/msg00705.html
v2 cover letter:
https://lists.nongnu.org/archive/html/qemu-block/2021-07/msg00747.html
v3 cover letter:
https://lists.nongnu.org/archive/html/qemu-block/2021-08/msg00127.html
Changes in v4:
- Patch 1:
Once the mirror job is force-cancelled (job_is_cancelled() is true), we
should not generate new I/O requests. This applies to active mirroring,
too, so stop it once the job is cancelled.
(We must still forward all I/O requests to the source, though, of
course, but those are not really I/O request
07.09.2021 15:48, Hanna Reitz wrote:
On 07.09.21 13:29, Vladimir Sementsov-Ogievskiy wrote:
19.08.2021 13:12, Hanna Reitz wrote:
We cannot write to images opened with O_DIRECT unless we allow them to
be resized so they are aligned to the sector size: Since 9c60a5d1978,
bdrv_node_refresh_perm()
On 07.09.21 15:44, Vladimir Sementsov-Ogievskiy wrote:
07.09.2021 15:48, Hanna Reitz wrote:
On 07.09.21 13:29, Vladimir Sementsov-Ogievskiy wrote:
19.08.2021 13:12, Hanna Reitz wrote:
We cannot write to images opened with O_DIRECT unless we allow them to
be resized so they are aligned to the s
07.09.2021 17:00, Hanna Reitz wrote:
On 07.09.21 15:44, Vladimir Sementsov-Ogievskiy wrote:
07.09.2021 15:48, Hanna Reitz wrote:
On 07.09.21 13:29, Vladimir Sementsov-Ogievskiy wrote:
19.08.2021 13:12, Hanna Reitz wrote:
We cannot write to images opened with O_DIRECT unless we allow them to
b
On 3/15/21 1:08 PM, Peter Maydell wrote:
> On Mon, 15 Mar 2021 at 11:34, Paolo Bonzini wrote:
>> On 07/03/21 23:26, Philippe Mathieu-Daudé wrote:
>>> TYPE_PFLASH_CFI01 is a TYPE_SYS_BUS_DEVICE which registers its romd
>>> MemoryRegion with sysbus_init_mmio(), so we can use the generic
>>> sysbus_m
On Tue, 7 Sept 2021 at 15:45, Philippe Mathieu-Daudé wrote:
> The problems I see:
>
> - pflash_cfi01_get_memory() doesn't really document what it returns,
> simply an internal MemoryRegion* in pflash device. Neither we
> document this is a ROMD device providing a RAM buffer initialized
> by
On Tue, 7 Sept 2021 at 09:14, Stefan Hajnoczi wrote:
>
> The following changes since commit 88afdc92b644120e0182c8567e1b1d236e471b12:
>
> Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
> (2021-09-05 15:48:42 +0100)
>
> are available in the Git repository at:
>
> htt
On Thu, Sep 02, 2021 at 03:59:25AM -0300, Leonardo Bras Soares Passos wrote:
> I also suggested something like that, but I thought it could be good if we
> could
> fall back to io_writev() if we didn't have the zerocopy feature (or
> the async feature).
>
> What do you think?
That fallback looks
The NBD protocol just relaxed the requirements on
NBD_OPT_LIST_META_CONTEXT:
https://github.com/NetworkBlockDevice/nbd/commit/13a4e33a87
Since listing is not stateful (unlike SET_META_CONTEXT), we don't care
if a client asks for meta contexts without first requesting structured
replies. Well-beh
On Mon, Sep 06, 2021 at 10:06:46PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> When we don't have a connection and blocking is false, we return NULL
> but don't set errp. That's wrong.
Oops...
>
> We have two paths for calling nbd_co_establish_connection():
>
> 1. nbd_open() -> nbd_do_establis
On Tue, Sep 07, 2021 at 12:06:15PM +0100, Dr. David Alan Gilbert wrote:
> > > What if we do the 'flush()' before we start post-copy, instead of after
> > > each
> > > iteration? would that be enough?
> >
> > Possibly, yes. This really need David G's input since he understands
> > the code in way
On Thu, Sep 02, 2021 at 04:22:55AM -0300, Leonardo Bras Soares Passos wrote:
> > I don't think it is valid to unconditionally enable this feature due to the
> > resource usage implications
> >
> > https://www.kernel.org/doc/html/v5.4/networking/msg_zerocopy.html
> >
> > "A zerocopy failure will r
On Mon, Sep 06, 2021 at 10:06:48PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> It is useful when start of vm and start of nbd server are not
> simple to sync.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> qapi/block-core.json | 9 -
> block/nbd.c | 45 +++
On Mon, Sep 06, 2021 at 10:06:49PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> The only user of errp is call to nbd_do_establish_connection() in
> nbd_open(). The only way to cancel this call is through open_timer
The only caller of nbd_do_establish_connection() that uses errp is
nbd_open().
> t
On Mon, Sep 06, 2021 at 10:06:50PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> nbd/client-connection.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
Reviewed-by: Eric Blake
>
> diff --git a/nbd/client-connection.c b/nb
On Mon, Sep 06, 2021 at 10:06:54PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> .../qemu-iotests/tests/nbd-reconnect-on-open | 71 +++
> .../tests/nbd-reconnect-on-open.out | 11 +++
> 2 files changed, 82 insertions(+)
This patch set implements the Nuvoton MMC device
for NPCM7XX boards.
The MMC device is compatible with the SDHCI interface
in QEMU. It allows the user to attach an SD card image
to it.
Shengtan Mao (4):
tests/qtest/libqos: add SDHCI commands
hw/sd: add nuvoton MMC
hw/arm: Attach MMC to quan
From: Shengtan Mao
Signed-off-by: Shengtan Mao
Reviewed-by: Hao Wu
Reviewed-by: Chris Rauer
Reviewed-by: Tyrone Ting
---
tests/qtest/libqos/meson.build | 1 +
tests/qtest/libqos/sdhci-cmd.c | 116 +
tests/qtest/libqos/sdhci-cmd.h | 70
From: Shengtan Mao
Signed-off-by: Shengtan Mao
Reviewed-by: Hao Wu
Reviewed-by: Tyrone Ting
---
hw/arm/npcm7xx_boards.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/hw/arm/npcm7xx_boards.c b/hw/arm/npcm7xx_boards.c
index e5a3243995..7205483280 100644
--- a/hw/arm
From: Shengtan Mao
Signed-off-by: Shengtan Mao
Reviewed-by: Hao Wu
Reviewed-by: Chris Rauer
Reviewed-by: Tyrone Ting
---
hw/arm/npcm7xx.c | 12 +++-
hw/sd/meson.build | 1 +
hw/sd/npcm7xx_sdhci.c | 131 ++
include/hw/arm/npc
From: Shengtan Mao
Signed-off-by: Shengtan Mao
Reviewed-by: Hao Wu
Reviewed-by: Chris Rauer
Reviewed-by: Tyrone Ting
---
tests/qtest/meson.build | 1 +
tests/qtest/npcm7xx_sdhci-test.c | 201 +++
2 files changed, 202 insertions(+)
create mode 100644 te
On Wed, Sep 8, 2021 at 2:32 AM Peter Xu wrote:
>
> On Thu, Sep 02, 2021 at 04:22:55AM -0300, Leonardo Bras Soares Passos wrote:
> > > I don't think it is valid to unconditionally enable this feature due to
> > > the
> > > resource usage implications
> > >
> > > https://www.kernel.org/doc/html/v5.
On Wed, Sep 08, 2021 at 10:59:57AM +0800, Jason Wang wrote:
> On Wed, Sep 8, 2021 at 2:32 AM Peter Xu wrote:
> >
> > On Thu, Sep 02, 2021 at 04:22:55AM -0300, Leonardo Bras Soares Passos wrote:
> > > > I don't think it is valid to unconditionally enable this feature due to
> > > > the
> > > > res
On Wed, Sep 8, 2021 at 11:24 AM Peter Xu wrote:
>
> On Wed, Sep 08, 2021 at 10:59:57AM +0800, Jason Wang wrote:
> > On Wed, Sep 8, 2021 at 2:32 AM Peter Xu wrote:
> > >
> > > On Thu, Sep 02, 2021 at 04:22:55AM -0300, Leonardo Bras Soares Passos
> > > wrote:
> > > > > I don't think it is valid to
60 matches
Mail list logo
