On Apr 1 11:42, Andrzej Jakowski wrote:
> This patch sets CMBS bit in controller capabilities register when user
> configures NVMe driver with CMB support, so capabilites are correctly reported
> to guest OS.
>
> Signed-off-by: Andrzej Jakowski
> ---
> hw/block/nvme.c | 2 ++
>
Hi all,
Hotplug of vhost-user-blk doesn't not work in qemu master branch and
all previous version.
The action I insert a vhost-user-blk disk is:
(qemu) chardev-add socket,id=spdk_vhost_blk2,path=/vhost-blk.0,reconnect=1
(qemu) device_add
On Tue, 7 Apr 2020 at 15:26, Kevin Wolf wrote:
>
> The following changes since commit 53ef8a92eb04ee19640f5aad3bff36cd4a36c250:
>
> Merge remote-tracking branch
> 'remotes/pmaydell/tags/pull-target-arm-20200406' into staging (2020-04-06
> 12:36:45 +0100)
>
> are available in the Git
On Tue, 7 Apr 2020 at 13:37, Max Reitz wrote:
>
> The following changes since commit 53ef8a92eb04ee19640f5aad3bff36cd4a36c250:
>
> Merge remote-tracking branch
> 'remotes/pmaydell/tags/pull-target-arm-20200406' into staging (2020-04-06
> 12:36:45 +0100)
>
> are available in the Git repository
07.04.2020 19:27, Kevin Wolf wrote:
Am 07.04.2020 um 16:56 hat Vladimir Sementsov-Ogievskiy geschrieben:
07.04.2020 17:42, Kevin Wolf wrote:
Am 07.04.2020 um 16:22 hat Vladimir Sementsov-Ogievskiy geschrieben:
07.04.2020 15:12, Kevin Wolf wrote:
External callers of blk_co_*() and of the
Am 07.04.2020 um 16:56 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 07.04.2020 17:42, Kevin Wolf wrote:
> > Am 07.04.2020 um 16:22 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > > 07.04.2020 15:12, Kevin Wolf wrote:
> > > > External callers of blk_co_*() and of the synchronous blk_*()
07.04.2020 17:42, Kevin Wolf wrote:
Am 07.04.2020 um 16:22 hat Vladimir Sementsov-Ogievskiy geschrieben:
07.04.2020 15:12, Kevin Wolf wrote:
External callers of blk_co_*() and of the synchronous blk_*() functions
don't currently increase the BlockBackend.in_flight counter, but calls
from
Am 07.04.2020 um 16:22 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 07.04.2020 15:12, Kevin Wolf wrote:
> > External callers of blk_co_*() and of the synchronous blk_*() functions
> > don't currently increase the BlockBackend.in_flight counter, but calls
> > from blk_aio_*() do, so there is an
From: Stefan Reiter
job_cancel_sync requires the job's lock to be held, all other callers
already do this (replication_stop, drive_backup_abort,
blockdev_backup_abort, job_cancel_sync_all, cancel_common).
In this case we're in a BlockDriver handler, so we already have a lock,
just assert that
As reported on Launchpad, Azure apparently doesn't accept images for
upload that are not both aligned to 1 MB blocks and have a BAT size that
matches the image size exactly.
As far as I can tell, there is no real reason why we create a BAT that
is one entry longer than necessary for aligned image
Move all variants of the flush/pdiscard functions to a single place and
put the blk_co_*() version first because it is called by all other
variants (and will become static in the next patch).
Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
Message-Id:
From: Stefan Reiter
All code-paths leading to backup_clean (via job_clean) have the job's
context already acquired. The job's context is guaranteed to be the same
as the one used by backup_top via backup_job_create.
Since the previous logic effectively acquired the lock twice, this
broke
From: Stefan Reiter
All callers of job_txn_apply hold a single job's lock, but different
jobs within a transaction can have different contexts, thus we need to
lock each one individually before applying the callback function.
Similar to job_completed_txn_abort this also requires releasing the
Waiting in blk_wait_while_drained() while blk->in_flight is increased
for the current request is wrong because it will cause the drain
operation to deadlock.
This patch makes sure that blk_wait_while_drained() is called with
blk->in_flight increased exactly once for the current request, and that
External callers of blk_co_*() and of the synchronous blk_*() functions
don't currently increase the BlockBackend.in_flight counter, but calls
from blk_aio_*() do, so there is an inconsistency whether the counter
has been increased or not.
This patch moves the actual operations to static
The following changes since commit 53ef8a92eb04ee19640f5aad3bff36cd4a36c250:
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200406'
into staging (2020-04-06 12:36:45 +0100)
are available in the Git repository at:
git://repo.or.cz/qemu/kevin.git tags/for-upstream
for
Am 07.04.2020 um 13:56 hat Stefan Reiter geschrieben:
> Contains three seperate but related patches cleaning up and fixing some
> issues regarding aio_context_acquire/aio_context_release for jobs. Mostly
> affects blockjobs running for devices that have IO threads enabled AFAICT.
>
>
> Changes
07.04.2020 15:12, Kevin Wolf wrote:
External callers of blk_co_*() and of the synchronous blk_*() functions
don't currently increase the BlockBackend.in_flight counter, but calls
from blk_aio_*() do, so there is an inconsistency whether the counter
has been increased or not.
This patch moves
On Mon, 6 Apr 2020 19:47:38 +0200
Philippe Mathieu-Daudé wrote:
> Patch created mechanically by running:
>
> $ spatch \
> --macro-file scripts/cocci-macro-file.h \
> --include-headers --keep-comments --in-place \
> --sp-file \
>
Am 07.04.2020 um 13:56 hat Stefan Reiter geschrieben:
> All callers of job_txn_apply hold a single job's lock, but different
> jobs within a transaction can have different contexts, thus we need to
> lock each one individually before applying the callback function.
>
> Similar to
On 07.04.20 14:12, Kevin Wolf wrote:
> External callers of blk_co_*() and of the synchronous blk_*() functions
> don't currently increase the BlockBackend.in_flight counter, but calls
> from blk_aio_*() do, so there is an inconsistency whether the counter
> has been increased or not.
>
> This
From: Anthony PERARD
Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on
remove") revealed that a request was removed twice from a list, once
in xen_block_finish_request() and a second time in
xen_block_release_request() when both function are called from
xen_block_complete_aio().
From: Alberto Garcia
A discard request deallocates the selected clusters so they read back
as zeroes. This is done by clearing the cluster offset field and
setting QCOW_OFLAG_ZERO in the L2 entry.
This flag is however only supported when qcow_version >= 3. In older
images the cluster is simply
>From time to time, my shell decides to repace the bracketed numbers here
by the numbers inside (i.e., "=== Clusters to be compressed [1]" is
printed as "=== Clusters to be compressed 1"). That makes tests that
use common.pattern fail. Prevent that from happening by quoting the
arguments to all
From: Alberto Garcia
When issuing a compressed write request the number of bytes must be a
multiple of the cluster size or reach the end of the last cluster.
With the current code such requests are allowed and we hit an
assertion:
$ qemu-img create -f qcow2 img.qcow2 1M
$ qemu-io -c
From: Eric Blake
Various qemu-img commands are inconsistent on whether they report
status/errors in terms of bytes or sector offsets. The latter is
confusing (especially as more places move to 4k block sizes), so let's
switch everything to just use bytes everywhere. One iotest is
impacted.
The following changes since commit 53ef8a92eb04ee19640f5aad3bff36cd4a36c250:
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200406'
into staging (2020-04-06 12:36:45 +0100)
are available in the Git repository at:
https://github.com/XanClic/qemu.git
External callers of blk_co_*() and of the synchronous blk_*() functions
don't currently increase the BlockBackend.in_flight counter, but calls
from blk_aio_*() do, so there is an inconsistency whether the counter
has been increased or not.
This patch moves the actual operations to static
Waiting in blk_wait_while_drained() while blk->in_flight is increased
for the current request is wrong because it will cause the drain
operation to deadlock.
This patch makes sure that blk_wait_while_drained() is called with
blk->in_flight increased exactly once for the current request, and that
Move all variants of the flush/pdiscard functions to a single place and
put the blk_co_*() version first because it is called by all other
variants (and will become static in the next patch).
Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
---
This fixes deadlocks when draining a BlockBackend in an iothread that
receives new requests at the same time.
v3:
- Call blk_inc/dec_in_flight() in blk_prw() rather than inside the
coroutines [Max]
v2:
- Rework the whole thing so that direct callers of blk_co_*() aren't
broken after the
All code-paths leading to backup_clean (via job_clean) have the job's
context already acquired. The job's context is guaranteed to be the same
as the one used by backup_top via backup_job_create.
Since the previous logic effectively acquired the lock twice, this
broke cleanup of backups for disks
Contains three seperate but related patches cleaning up and fixing some
issues regarding aio_context_acquire/aio_context_release for jobs. Mostly
affects blockjobs running for devices that have IO threads enabled AFAICT.
Changes from v4:
* Do job_ref/job_unref in job_txn_apply and job_exit since
All callers of job_txn_apply hold a single job's lock, but different
jobs within a transaction can have different contexts, thus we need to
lock each one individually before applying the callback function.
Similar to job_completed_txn_abort this also requires releasing the
caller's context before
job_cancel_sync requires the job's lock to be held, all other callers
already do this (replication_stop, drive_backup_abort,
blockdev_backup_abort, job_cancel_sync_all, cancel_common).
In this case we're in a BlockDriver handler, so we already have a lock,
just assert that it is the same as the
On 06.04.20 16:02, Anthony PERARD wrote:
> Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on
> remove") revealed that a request was removed twice from a list, once
> in xen_block_finish_request() and a second time in
> xen_block_release_request() when both function are called from
On 07.04.20 13:13, Kevin Wolf wrote:
> Am 07.04.2020 um 12:15 hat Max Reitz geschrieben:
>> On 07.04.20 12:04, Max Reitz wrote:
>>> On 06.04.20 19:14, Kevin Wolf wrote:
External callers of blk_co_*() don't currently increase the
BlockBackend.in_flight counter, but calls from blk_aio_*()
Am 07.04.2020 um 12:15 hat Max Reitz geschrieben:
> On 07.04.20 12:04, Max Reitz wrote:
> > On 06.04.20 19:14, Kevin Wolf wrote:
> >> External callers of blk_co_*() don't currently increase the
> >> BlockBackend.in_flight counter, but calls from blk_aio_*() do, so there
> >> is an inconsistency
On Mon, Apr 06, 2020 at 02:17:05PM +0200, Igor Mammedov wrote:
> On Mon, 6 Apr 2020 10:25:17 +0200
> Gerd Hoffmann wrote:
>
> > On Fri, Apr 03, 2020 at 12:09:21PM +0200, Igor Mammedov wrote:
> > > On Fri, 3 Apr 2020 10:04:57 +0200
> > > Gerd Hoffmann wrote:
> > >
> > > > Signed-off-by: Gerd
On Mon, Apr 06, 2020 at 12:22:31PM +0200, Igor Mammedov wrote:
> On Fri, 3 Apr 2020 10:04:56 +0200
> Gerd Hoffmann wrote:
>
> > Also add isa_aml_build() function which walks all isa devices.
> > This allows to move aml builder code to isa devices.
> >
> > Signed-off-by: Gerd Hoffmann
> > ---
On 07.04.20 12:04, Max Reitz wrote:
> On 06.04.20 19:14, Kevin Wolf wrote:
>> External callers of blk_co_*() don't currently increase the
>> BlockBackend.in_flight counter, but calls from blk_aio_*() do, so there
>> is an inconsistency whether the counter has been increased or not.
>>
>> This
On 06.04.20 19:14, Kevin Wolf wrote:
> Waiting in blk_wait_while_drained() while blk->in_flight is increased
> for the current request is wrong because it will cause the drain
> operation to deadlock.
>
> This patch makes sure that blk_wait_while_drained() is called with
> blk->in_flight
On 06.04.20 19:14, Kevin Wolf wrote:
> External callers of blk_co_*() don't currently increase the
> BlockBackend.in_flight counter, but calls from blk_aio_*() do, so there
> is an inconsistency whether the counter has been increased or not.
>
> This patch moves the actual operations to static
07.04.2020 12:48, Kevin Wolf wrote:
Am 07.04.2020 um 11:10 hat Vladimir Sementsov-Ogievskiy geschrieben:
07.04.2020 11:52, Kevin Wolf wrote:
Am 07.04.2020 um 08:41 hat Vladimir Sementsov-Ogievskiy geschrieben:
06.04.2020 20:14, Kevin Wolf wrote:
External callers of blk_co_*() don't currently
Am 07.04.2020 um 11:10 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 07.04.2020 11:52, Kevin Wolf wrote:
> > Am 07.04.2020 um 08:41 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > > 06.04.2020 20:14, Kevin Wolf wrote:
> > > > External callers of blk_co_*() don't currently increase the
> > > >
On 06.04.20 19:14, Kevin Wolf wrote:
> Move all variants of the flush/pdiscard functions to a single place and
> put the blk_co_*() version first because it is called by all other
> variants (and will become static in the next patch).
>
> Signed-off-by: Kevin Wolf
> ---
> block/block-backend.c
Am 07.04.2020 um 08:52 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 06.04.2020 20:14, Kevin Wolf wrote:
> > Waiting in blk_wait_while_drained() while blk->in_flight is increased
> > for the current request is wrong because it will cause the drain
> > operation to deadlock.
> >
> > This patch
07.04.2020 11:59, Kevin Wolf wrote:
Am 07.04.2020 um 08:52 hat Vladimir Sementsov-Ogievskiy geschrieben:
06.04.2020 20:14, Kevin Wolf wrote:
Waiting in blk_wait_while_drained() while blk->in_flight is increased
for the current request is wrong because it will cause the drain
operation to
07.04.2020 11:52, Kevin Wolf wrote:
Am 07.04.2020 um 08:41 hat Vladimir Sementsov-Ogievskiy geschrieben:
06.04.2020 20:14, Kevin Wolf wrote:
External callers of blk_co_*() don't currently increase the
BlockBackend.in_flight counter, but calls from blk_aio_*() do, so there
is an inconsistency
On 03.04.20 12:11, Max Reitz wrote:
> From time to time, my shell decides to repace the bracketed numbers here
> by the numbers inside (i.e., "=== Clusters to be compressed [1]" is
> printed as "=== Clusters to be compressed 1"). That makes tests that
> use common.pattern fail. Prevent that from
Am 07.04.2020 um 08:41 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 06.04.2020 20:14, Kevin Wolf wrote:
> > External callers of blk_co_*() don't currently increase the
> > BlockBackend.in_flight counter, but calls from blk_aio_*() do, so there
> > is an inconsistency whether the counter has
On 06.04.20 16:34, Alberto Garcia wrote:
> When issuing a compressed write request the number of bytes must be a
> multiple of the cluster size or reach the end of the last cluster.
>
> With the current code such requests are allowed and we hit an
> assertion:
>
>$ qemu-img create -f qcow2
06.04.2020 16:02, Max Reitz wrote:
On 25.03.20 11:21, Vladimir Sementsov-Ogievskiy wrote:
Add python script with new logic of searching for tests:
Old behavior:
- tests are named [0-9][0-9][0-9]
- tests must be registered in group file (even if test doesn't belong
to any group, like
06.04.2020 17:34, Alberto Garcia wrote:
When issuing a compressed write request the number of bytes must be a
multiple of the cluster size or reach the end of the last cluster.
With the current code such requests are allowed and we hit an
assertion:
$ qemu-img create -f qcow2 img.qcow2 1M
06.04.2020 20:14, Kevin Wolf wrote:
Waiting in blk_wait_while_drained() while blk->in_flight is increased
for the current request is wrong because it will cause the drain
operation to deadlock.
This patch makes sure that blk_wait_while_drained() is called with
blk->in_flight increased exactly
On 4/6/20 7:47 PM, Philippe Mathieu-Daudé wrote:
> Patch created mechanically by running:
>
> $ spatch \
> --macro-file scripts/cocci-macro-file.h \
> --include-headers --keep-comments --in-place \
> --sp-file \
> scripts/coccinelle/use-error_abort-in-instance_init.cocci
>
>
06.04.2020 20:14, Kevin Wolf wrote:
External callers of blk_co_*() don't currently increase the
BlockBackend.in_flight counter, but calls from blk_aio_*() do, so there
is an inconsistency whether the counter has been increased or not.
This patch moves the actual operations to static functions
I wouldn't mind either.
Andrey
From: Alberto Garcia
Sent: Monday, April 6, 2020 7:08 PM
To: qemu-de...@nongnu.org
Cc: qemu-block@nongnu.org ; Andrey Shinkevich
; Max Reitz ; Kevin Wolf
; Vladimir Sementsov-Ogievskiy ;
Pavel Butsykin
Subject: Re: [PATCH v2]
58 matches
Mail list logo
