Am 04.01.2019 um 17:40 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > Sent: 04 January 2019 16:31
> > To: Paul Durrant
> > Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> &g
Am 08.01.2019 um 15:20 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > Of Paul Durrant
> > Sent: 08 January 2019 14:11
> > To: Anthony Perard
> > Cc: 'Kevin
Am 22.01.2019 um 15:19 hat Thomas Huth geschrieben:
> On 2018-12-18 17:11, Thomas Huth wrote:
> > The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
> > It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
> > is derived from XenDevice which in turn is derived from Dev
Signed-off-by: Markus Armbruster
Reviewed-by: Kevin Wolf
Which tree should this go through? The Xen one?
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
:20
> >>> To: Paul Durrant ;
> >>> xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org;
> >>> qemu-de...@nongnu.org
> >>> Cc: Kevin Wolf ; Stefano Stabellini
> >>> ; Max Reitz
> >>> ; Stefan Hajnoczi ; Anthony
> >>
Am 01.04.2019 um 11:01 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Sent: 28 March 2019 11:56
> > To: Andrew Cooper
> > Cc: Anthony Perard ; Paul Durrant
> > ; xen-
> > de...@lists.xenp
Am 20.11.2019 um 13:59 hat Eric Blake geschrieben:
> On 11/20/19 3:50 AM, Vladimir Sementsov-Ogievskiy wrote:
> > Okay...
> >
> > I think that:
> >
> > 1. A lot of efforts (not only my, I think reviewing is already exceeded
> > generation efforts)
> > are made, it would be sad to lose them.
Am 21.11.2018 um 16:11 hat Paul Durrant geschrieben:
> This patch adds the basic boilerplate for a 'XenBus' object that will act
> as a parent to 'XenDevice' PV backends.
> A new 'XenBridge' object is also added to connect XenBus to the system bus.
>
> The XenBus object is instantiated by a new xe
'ring-ref' and
> 'event-channel' values specified in the frontend xenstore area are
> mapped/bound and used to set up the dataplane.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Stefano Stabellini
> Cc: Anthony Perard
> Cc: Kevin Wolf
Am 28.11.2018 um 17:29 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 28 November 2018 16:28
> > To: Paul Durrant
> > Cc: 'Kevin Wolf' ; qemu-bl...@nongnu.or
Am 28.11.2018 um 17:40 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Sent: 28 November 2018 16:35
> > To: Paul Durrant
> > Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> > de...@list
Am 28.11.2018 um 17:46 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Paul Durrant
> > Sent: 28 November 2018 16:46
> > To: 'Kevin Wolf'
> > Cc: 'Stefano Stabellini' ; qemu-bl...@nongnu.org;
> > qemu-de...@non
Am 29.11.2018 um 10:33 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Sent: 29 November 2018 09:01
> > To: Paul Durrant
> > Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> > de...@list
Am 12.12.2018 um 09:59 hat Olaf Hering geschrieben:
> On Fri, Nov 02, Kevin Wolf wrote:
>
> > A while ago, a downstream patch review found out that there are some QMP
> > commands that would immediately crash if a xen_disk device were present
> > because of the lacking qd
Am 11.12.2018 um 16:57 hat Paul Durrant geschrieben:
> This patch adds a creator function for XenBlockDevice-s so that they can
> be created automatically when the Xen toolstack instantiates a new
> PV backend. When the XenBlockDevice is created this way it is also
> necessary to create a drive whi
Am 13.12.2018 um 13:44 hat Paul Durrant geschrieben:
> > Essentially, what I'm wondering is whether we have anything that could
> > be treated more or less like another monitor besides QMP and HMP, which
> > would internally work similar to HMP, i.e. map (almost) everything to
> > QMP commands.
>
Am 21.03.2018 um 15:46 hat Michael S. Tsirkin geschrieben:
> Our current scheme is to use
> #include ""
> for internal headers, and
> #include <>
> for external ones.
>
> Unfortunately this is not based on compiler support: from C point of
> view, the "" form merely looks up headers in the curre
Am 21.03.2018 um 16:58 hat Michael S. Tsirkin geschrieben:
> On Wed, Mar 21, 2018 at 04:34:39PM +0100, Kevin Wolf wrote:
> > Am 21.03.2018 um 15:46 hat Michael S. Tsirkin geschrieben:
> > > Our current scheme is to use
> > > #include ""
> > > for inte
Am 23.03.2018 um 11:22 hat Daniel P. Berrangé geschrieben:
> On Thu, Mar 22, 2018 at 09:27:55PM +0200, Michael S. Tsirkin wrote:
> > Make sure all generated files go into qemu-build subdirectory.
> > We can then include them like this:
> > #include "qemu-build/trace.h"
> >
> > This serves two pur
Am 02.11.2018 um 11:00 hat Tim Smith geschrieben:
> A series of performance improvements for disks using the Xen PV ring.
>
> These have had fairly extensive testing.
>
> The batching and latency improvements together boost the throughput
> of small reads and writes by two to six percent (measure
Am 02.11.2018 um 12:13 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Sent: 02 November 2018 11:04
> > To: Tim Smith
> > Cc: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org; qemu-
> > bl.
Am 08.11.2018 um 15:00 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Markus Armbruster [mailto:arm...@redhat.com]
> > Sent: 05 November 2018 15:58
> > To: Paul Durrant
> > Cc: 'Kevin Wolf' ; Tim Smith ;
> > Stefano St
Am 09.11.2018 um 11:27 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Paul Durrant
> > Sent: 08 November 2018 16:44
> > To: Paul Durrant ; 'Kevin Wolf'
> >
> > Cc: Stefano Stabellini ; qemu-bl...@nongnu.org;
> > Tim S
Am 18.01.2021 um 16:49 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 18 January 2021 15:34
> > To: qemu-de...@nongnu.org
> > Cc: Roger Pau Monne ; Arthur Borsboom
> > ; Stefano
> > Stabellini ; Anthony P
Am 29.05.2020 um 12:56 hat Roman Kagan geschrieben:
> On Fri, May 29, 2020 at 11:53:26AM +0200, Markus Armbruster wrote:
> > Roman Kagan writes:
> >
> > > Several block device properties related to blocksize configuration must
> > > be in certain relationship WRT each other: physical block must b
Am 29.05.2020 um 00:55 hat Roman Kagan geschrieben:
> BlockConf includes several properties counted in bytes.
>
> Enhance their handling in some aspects, specifically
>
> - accept common size suffixes (k, m)
> - perform consistency checks on the values
> - lift the upper limit on physical_block_s
Am 31.05.2023 um 21:50 hat Stefan Hajnoczi geschrieben:
> Hi Kevin,
> Do you want to review the thread-local blk_io_plug() patch series or
> should I merge it?
I haven't reviewed it in detail, but on the high level it looks good to
me, and you already got reviews for the details.
A
Find an unoccupied device name */
> +while (disk < (1 << 20)) {
I like your optimism that we can handle a million disks. :-)
I haven't reviewed the Xen part in detail, but the patch looks fine on
the block layer side.
Acked-by: Kevin Wolf
Am 16.10.2023 um 17:19 hat David Woodhouse geschrieben:
> From: David Woodhouse
>
> There's no need to force the user to assign a vdev. We can automatically
> assign one, starting at xvda and searching until we find the first disk
> name that's unused.
>
> This means we can now allow '-drive if=
Am 18.10.2023 um 12:52 hat David Woodhouse geschrieben:
> > Actually, how does this play together with xen_config_dev_blk()? This
> > looks like it tried to implement a very similar thing (which is IF_XEN
> > even already existed).
>
> Ah yes, thanks for spotting that! I hadn't been looking at the
Am 23.10.2023 um 11:30 hat Igor Mammedov geschrieben:
> On Wed, 18 Oct 2023 09:32:47 +0100
> David Woodhouse wrote:
>
> > On Wed, 2023-10-18 at 09:32 +0200, Igor Mammedov wrote:
> > > On Mon, 16 Oct 2023 16:19:08 +0100
> > > David Woodhouse wrote:
> > >
> > > > From: David Woodhouse
> > > >
Am 25.10.2023 um 20:56 hat Andrew Cooper geschrieben:
> On 25/10/2023 7:26 pm, David Woodhouse wrote:
> > On Wed, 2023-10-25 at 13:20 -0500, Eric Blake wrote:
> >> On Wed, Oct 25, 2023 at 03:50:42PM +0100, David Woodhouse wrote:
> >>> +
> >>> +Booting Xen PV guests
> >>> +-
> >>
Am 13.09.2023 um 22:00 hat Stefan Hajnoczi geschrieben:
> v3:
> - Add comment pointing to API documentation in .c file [Philippe]
> - Add virtio_notify_irqfd_deferred_fn trace event [Ilya]
> - Remove outdated #include [Ilya]
> v2:
> - Rename blk_io_plug() to defer_call() and move it to util/ so the
Am 18.05.2022 um 15:09 hat Stefan Hajnoczi geschrieben:
> Commit 1b7fd729559c ("block: rename buffer_alignment to
> guest_block_size") noted:
>
> At this point, the field is set by the device emulation, but completely
> ignored by the block layer.
>
> The last time the value of buffer_alignme
Am 29.11.2023 um 20:55 hat Stefan Hajnoczi geschrieben:
> The AioContext lock no longer has any effect. Remove it.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> include/hw/virtio/virtio-scsi.h | 14 --
> hw/scsi/scsi-bus.c | 2 --
> hw/scsi/scsi-disk.c | 28 +++
otected by a lock.
>
> Run TMF request completion in the IOThread using aio_wait_bh_oneshot().
> This avoids more locking to protect the virtqueue and SCSI layer state.
>
> Signed-off-by: Stefan Hajnoczi
Reviewed-by: Kevin Wolf
Am 29.11.2023 um 20:55 hat Stefan Hajnoczi geschrieben:
> Protect the Task Management Function BH state with a lock. The TMF BH
> runs in the main loop thread. An IOThread might process a TMF at the
> same time as the TMF BH is running. Therefore tmf_bh_list and tmf_bh
> must be protected by a lock
Am 29.11.2023 um 20:55 hat Stefan Hajnoczi geschrieben:
> The aio_context_acquire() API is being removed. Drop the test case that
> calls the API.
>
> Signed-off-by: Stefan Hajnoczi
Reviewed-by: Kevin Wolf
iminating the lock.
>
> Signed-off-by: Stefan Hajnoczi
YOLO.
Acked-by: Kevin Wolf
es meaningless and they can be collapsed
> into one function.
>
> Signed-off-by: Stefan Hajnoczi
Reviewed-by: Kevin Wolf
t; }
It's still there at the end of the series.
> void coroutine_fn bdrv_co_unlock(BlockDriverState *bs)
> {
> -AioContext *ctx = bdrv_get_aio_context(bs);
> -
> -assert(qemu_in_coroutine());
> -if (ctx != qemu_get_aio_context()) {
> -aio_context_release(ctx);
> -}
> +/* TODO removed in next patch */
> }
This one, too.
Reviewed-by: Kevin Wolf
> AioContext.
>
> Signed-off-by: Stefan Hajnoczi
Reviewed-by: Kevin Wolf
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> The bdrv_co_lock() and bdrv_co_unlock() functions are already no-ops.
> Remove them.
>
> Signed-off-by: Stefan Hajnoczi
Reviewed-by: Kevin Wolf
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> The AioContext lock no longer has any effect. Remove it.
>
> Signed-off-by: Stefan Hajnoczi
> Reviewed-by: Eric Blake
Reviewed-by: Kevin Wolf
viewed-by: Eric Blake
Reviewed-by: Kevin Wolf
review that Emanuele eked out of
> Kevin and me over many months.
>
> Kevin Wolf tackled multitudes of graph locking conversions to protect
> in-flight I/O from run-time changes to the block graph as well as the
> clang Thread Safety Analysis annotations that allow the compiler to
> che
the deadlock the comment refers to is that AIO_WAIT_WHILE() sits
in a blocking aio_poll() and nobody wakes it up because aio_wait_kick()
only wakes up the main thread. This deadlock still exists after removing
the AioContext lock, so the comment after your change looks right to me.
Reviewed-by: Kevin Wolf
Am 05.12.2023 um 19:19 hat Stefan Hajnoczi geschrieben:
> v2:
> - Add Patch 2 "scsi: assert that callbacks run in the correct AioContext"
> [Kevin]
> - Add Patch 7 "block: remove bdrv_co_lock()" [Eric and Kevin]
> - Remove stray goto label in Patch 8 [Kevin]
> - Fix "eeked" -> "eked" typo in Patch
iminating the lock.
>
> Signed-off-by: Stefan Hajnoczi
> Reviewed-by: Eric Blake
> Acked-by: Kevin Wolf
I knew why I wasn't confident enough to give a R-b... This crashes
qemu-storage-daemon in the qemu-iotests case graph-changes-while-io.
qemu-storage-daemon: ../nbd/s
he same group of people, so I decided to do it in one patch.
>
> Signed-off-by: Stefan Hajnoczi
> Reviewed-by: Eric Blake
> Reviewed-by: Kevin Wolf
> Reviewed-by: Paul Durrant
> diff --git a/migration/block.c b/migration/block.c
> index a15f9bddcb..2bcfcbfdf6 100644
Am 19.12.2023 um 16:28 hat Kevin Wolf geschrieben:
> Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> > aio_context_acquire()/aio_context_release() has been replaced by
> > fine-grained locking to protect state shared by multiple threads. The
> > AioContext lock st
Am 19.12.2023 um 21:04 hat Stefan Hajnoczi geschrieben:
> On Tue, 19 Dec 2023 at 10:59, Kevin Wolf wrote:
> >
> > Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> > > This is the big patch that removes
> > > aio_context_acquire()/aio_context_r
Am 19.12.2023 um 22:23 hat Stefan Hajnoczi geschrieben:
> The following hack makes the test pass but there are larger safety
> issues that I'll need to look at on Wednesday:
I see, you're taking the same approach as in the SCSI layer: Don't make
things thread-safe, but just always access them from
s the
> * same as the current context of bs).
>
> As blk_set_aio_context() makes use of this function, this rule also
> applies to it.
>
> Fix all occurrences where this rule wasn't honored.
>
> Suggested-by: Kevin Wolf
> Signed-off-by: Sergio Lopez
Reviewed-by: Kevin Wolf
Am 14.12.2020 um 18:05 hat Sergio Lopez geschrieben:
> While processing the parents of a BDS, one of the parents may process
> the child that's doing the tail recursion, which leads to a BDS being
> processed twice. This is especially problematic for the aio_notifiers,
> as they might attempt to wo
Am 15.12.2020 um 14:15 hat Sergio Lopez geschrieben:
> On Tue, Dec 15, 2020 at 01:12:33PM +0100, Kevin Wolf wrote:
> > Am 14.12.2020 um 18:05 hat Sergio Lopez geschrieben:
> > > While processing the parents of a BDS, one of the parents may process
> > > the child that
Am 14.12.2020 um 18:05 hat Sergio Lopez geschrieben:
> There's a cross-dependency between closing the block exports and
> draining the block layer. The latter needs that we close all export's
> client connections to ensure they won't queue more requests, but the
> exports may have coroutines yieldi
Am 15.12.2020 um 18:23 hat Sergio Lopez geschrieben:
> On Tue, Dec 15, 2020 at 04:01:19PM +0100, Kevin Wolf wrote:
> > Am 15.12.2020 um 14:15 hat Sergio Lopez geschrieben:
> > > On Tue, Dec 15, 2020 at 01:12:33PM +0100, Kevin Wolf wrote:
> > > > Am 14.12.2020 um 18:0
Am 16.12.2020 um 15:55 hat Sergio Lopez geschrieben:
> On Wed, Dec 16, 2020 at 01:35:14PM +0100, Kevin Wolf wrote:
> > Am 15.12.2020 um 18:23 hat Sergio Lopez geschrieben:
> > > On Tue, Dec 15, 2020 at 04:01:19PM +0100, Kevin Wolf wrote:
> > > > Am 15.12.2020 um 14:1
Am 17.12.2020 um 10:37 hat Sergio Lopez geschrieben:
> On Wed, Dec 16, 2020 at 07:31:02PM +0100, Kevin Wolf wrote:
> > Am 16.12.2020 um 15:55 hat Sergio Lopez geschrieben:
> > > On Wed, Dec 16, 2020 at 01:35:14PM +0100, Kevin Wolf wrote:
> > > > Am 15.12.2020 um 18:2
Am 17.12.2020 um 13:50 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 17.12.2020 13:58, Kevin Wolf wrote:
> > Am 17.12.2020 um 10:37 hat Sergio Lopez geschrieben:
> > > On Wed, Dec 16, 2020 at 07:31:02PM +0100, Kevin Wolf wrote:
> > > > Am 16.12.2020 um 15:5
Am 31.08.2023 um 15:25 hat Markus Armbruster geschrieben:
> Local variables shadowing other local variables or parameters make the
> code needlessly hard to understand. Tracked down with -Wshadow=local.
> Clean up: delete inner declarations when they are actually redundant,
> else rename variables
onsistent(bitmap)) {
> @@ -1625,7 +1624,7 @@ bool
> qcow2_store_persistent_dirty_bitmaps(BlockDriverState *bs,
>
> /* allocate clusters and store bitmaps */
> QSIMPLEQ_FOREACH(bm, bm_list, entry) {
> -BdrvDirtyBitmap *bitmap = bm->dirty_bitmap;
> + bitmap = bm->dirty_bitmap;
>
> if (bitmap == NULL || bdrv_dirty_bitmap_readonly(bitmap)) {
> continue;
Reviewed-by: Kevin Wolf
Am 31.08.2023 um 15:25 hat Markus Armbruster geschrieben:
> Local variables shadowing other local variables or parameters make the
> code needlessly hard to understand. Tracked down with -Wshadow=local.
> Clean up: delete inner declarations when they are actually redundant,
> else rename variables
Am 19.09.2023 um 07:48 hat Markus Armbruster geschrieben:
> Kevin Wolf writes:
>
> > Am 31.08.2023 um 15:25 hat Markus Armbruster geschrieben:
> >> Local variables shadowing other local variables or parameters make the
> >> code needlessly hard to understand. Tr
else rename variables.
>
> Signed-off-by: Markus Armbruster
> Reviewed-by: Stefan Hajnoczi
Reviewed-by: Kevin Wolf
else rename variables.
>
> Signed-off-by: Markus Armbruster
> Reviewed-by: Stefan Hajnoczi
> Acked-by: Anthony PERARD
> Acked-by: Ilya Dryomov
Reviewed-by: Kevin Wolf
While there, move the local variables to function scope.
>
> Suggested-by: Kevin Wolf
> Signed-off-by: Markus Armbruster
Reviewed-by: Kevin Wolf
Am 20.09.2023 um 20:31 hat Markus Armbruster geschrieben:
> Variables declared in macros can shadow other variables. Much of the
> time, this is harmless, e.g.:
>
> #define _FDT(exp) \
> do {
Am 25.02.2021 um 18:32 hat Jim Fehlig geschrieben:
> Adding xen-devel and Ian to cc.
>
> On 2/24/21 6:11 AM, Daniel P. Berrangé wrote:
> > The following features have been deprecated for well over the 2
> > release cycle we promise
>
> This reminded me of a bug report we received late last year w
Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> This patch is part of an effort to remove the aio_disable_external()
> API because it does not fit in a multi-queue block layer world where
> many AioContexts may be submitting requests to the same disk.
>
> The SCSI emulation code is alrea
Am 01.05.2023 um 17:09 hat Stefan Hajnoczi geschrieben:
> On Fri, Apr 28, 2023 at 04:22:55PM +0200, Kevin Wolf wrote:
> > Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> > > This patch is part of an effort to remove the aio_disable_external()
> > > API because
Am 25.04.2023 um 19:26 hat Stefan Hajnoczi geschrieben:
> Only report a transport reset event to the guest after the SCSIDevice
> has been unrealized by qdev_simple_device_unplug_cb().
>
> qdev_simple_device_unplug_cb() sets the SCSIDevice's qdev.realized field
> to false so that scsi_device_find/
Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> Each vhost-user-blk request runs in a coroutine. When the BlockBackend
> enters a drained section we need to enter a quiescent state. Currently
> any in-flight requests race with bdrv_drained_begin() because it is
> unaware of vhost-user-blk
Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> vhost-user activity must be suspended during bdrv_drained_begin/end().
> This prevents new requests from interfering with whatever is happening
> in the drained section.
>
> Previously this was done using aio_set_fd_handler()'s is_external
Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> For simplicity, always run BlockDevOps .drained_begin/end/poll()
> callbacks in the main loop thread. This makes it easier to implement the
> callbacks and avoids extra locks.
>
> Move the function pointer declarations from the I/O Code sec
Am 02.05.2023 um 20:56 hat Stefan Hajnoczi geschrieben:
> On Tue, May 02, 2023 at 05:19:46PM +0200, Kevin Wolf wrote:
> > Am 25.04.2023 um 19:26 hat Stefan Hajnoczi geschrieben:
> > > Only report a transport reset event to the guest after the SCSIDevice
> >
Am 02.05.2023 um 22:06 hat Stefan Hajnoczi geschrieben:
> On Tue, May 02, 2023 at 06:04:24PM +0200, Kevin Wolf wrote:
> > Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> > > vhost-user activity must be suspended during bdrv_drained_begin/end().
> > > This
Am 02.05.2023 um 22:02 hat Stefan Hajnoczi geschrieben:
> On Tue, May 02, 2023 at 03:19:52PM +0200, Kevin Wolf wrote:
> > Am 01.05.2023 um 17:09 hat Stefan Hajnoczi geschrieben:
> > > On Fri, Apr 28, 2023 at 04:22:55PM +0200, Kevin Wolf wrote:
> > > > Am 25.04.202
Am 03.05.2023 um 15:11 hat Stefan Hajnoczi geschrieben:
> On Wed, May 03, 2023 at 10:08:46AM +0200, Kevin Wolf wrote:
> > Am 02.05.2023 um 22:06 hat Stefan Hajnoczi geschrieben:
> > > On Tue, May 02, 2023 at 06:04:24PM +0200, Kevin Wolf wrote:
> > > > Am 25.04.202
Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> virtio_queue_aio_detach_host_notifier() does two things:
> 1. It removes the fd handler from the event loop.
> 2. It processes the virtqueue one last time.
>
> The first step can be peformed by any thread and without taking the
> AioContext
Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> Detach ioeventfds during drained sections to stop I/O submission from
> the guest. virtio-blk is no longer reliant on aio_disable_external()
> after this patch. This will allow us to remove the
> aio_disable_external() API once all other cod
Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> The virtio-scsi Host Bus Adapter provides access to devices on a SCSI
> bus. Those SCSI devices typically have a BlockBackend. When the
> BlockBackend enters a drained section, the SCSI device must temporarily
> stop submitting new I/O reque
Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> All callers now pass is_external=false to aio_set_fd_handler() and
> aio_set_event_notifier(). The aio_disable_external() API that
> temporarily disables fd handlers that were registered is_external=true
> is therefore dead code.
>
> Remove
Am 04.05.2023 um 21:53 hat Stefan Hajnoczi geschrieben:
> v5:
> - Use atomic accesses for in_flight counter in vhost-user-server.c [Kevin]
> - Stash SCSIDevice id/lun values for VIRTIO_SCSI_T_TRANSPORT_RESET event
> before unrealizing the SCSIDevice [Kevin]
> - Keep vhost-user-blk export .detach(
Am 09.05.2023 um 19:51 hat Stefan Hajnoczi geschrieben:
> On Thu, May 04, 2023 at 11:44:42PM +0200, Kevin Wolf wrote:
> > Am 04.05.2023 um 21:53 hat Stefan Hajnoczi geschrieben:
> > > v5:
> > > - Use atomic accesses for in_flight counter in vhost-user-server.c [Kevin]
Am 04.05.2023 um 21:53 hat Stefan Hajnoczi geschrieben:
> This patch is part of an effort to remove the aio_disable_external()
> API because it does not fit in a multi-queue block layer world where
> many AioContexts may be submitting requests to the same disk.
>
> The SCSI emulation code is alrea
g drained.
> It's better to solve a block layer problem in the block layer than to have an
> odd event loop API solution.
>
> The approach in this patch series is to implement BlockDevOps
> .drained_begin/end() callbacks that temporarily stop file descriptor handlers.
> This ensures that new I/O requests are not submitted in drained sections.
Patches 2-16: Reviewed-by: Kevin Wolf
Am 16.05.2023 um 21:02 hat Stefan Hajnoczi geschrieben:
> The aio_disable_external() API temporarily suspends file descriptor monitoring
> in the event loop. The block layer uses this to prevent new I/O requests being
> submitted from the guest and elsewhere between bdrv_drained_begin() and
> bdrv_
89 matches
Mail list logo
