Re: [PATCH 05/20] qapi/parser: adjust info location for doc body section

2024-05-15 Thread Markus Armbruster
John Snow writes: > Instead of using the info object for the doc block as a whole, update > the info pointer for each call to ensure_untagged_section when the > existing section is otherwise empty. This way, Sphinx error information > will match precisely to where the text actually starts. > >

Re: [PATCH v4 2/2] vhost-user: fix lost reconnect again

2024-05-15 Thread Raphael Norwitz
On Wed, May 15, 2024 at 10:58 PM Li Feng wrote: > > When the vhost-user is reconnecting to the backend, and if the vhost-user > fails > at the get_features in vhost_dev_init(), then the reconnect will fail > and it will not be retriggered forever. > > The reason is: > When the vhost-user fail at

Re: [PATCH v4 1/2] Revert "vhost-user: fix lost reconnect"

2024-05-15 Thread Raphael Norwitz
On Wed, May 15, 2024 at 10:58 PM Li Feng wrote: > > This reverts commit f02a4b8e6431598612466f76aac64ab492849abf. > > Since the current patch cannot completely fix the lost reconnect > problem, there is a scenario that is not considered: > - When the virtio-blk driver is removed from the guest

Re: [PATCH v3 2/2] vhost-user: fix lost reconnect again

2024-05-15 Thread Raphael Norwitz
OK - I'm happy with this approach then. On Wed, May 15, 2024 at 10:48 PM Li Feng wrote: > > > > 2024年5月15日 23:47,Raphael Norwitz 写道: > > The case your describing makes sense but now I have some concerns on > the vhost_dev_cleanup bit. > > On Wed, May 15, 2024 at 1:47 AM Li Feng wrote: > > > >

[PATCH v4 1/2] Revert "vhost-user: fix lost reconnect"

2024-05-15 Thread Li Feng
This reverts commit f02a4b8e6431598612466f76aac64ab492849abf. Since the current patch cannot completely fix the lost reconnect problem, there is a scenario that is not considered: - When the virtio-blk driver is removed from the guest os, s->connected has no chance to be set to false, resulting

[PATCH v4 2/2] vhost-user: fix lost reconnect again

2024-05-15 Thread Li Feng
When the vhost-user is reconnecting to the backend, and if the vhost-user fails at the get_features in vhost_dev_init(), then the reconnect will fail and it will not be retriggered forever. The reason is: When the vhost-user fail at get_features, the vhost_dev_cleanup will be called immediately.

Re: [PATCH v3 2/2] vhost-user: fix lost reconnect again

2024-05-15 Thread Li Feng
> 2024年5月15日 23:47,Raphael Norwitz 写道: > > The case your describing makes sense but now I have some concerns on > the vhost_dev_cleanup bit. > > On Wed, May 15, 2024 at 1:47 AM Li Feng > wrote: >> >> >> >>> 2024年5月14日 21:58,Raphael Norwitz 写道: >>> >>> Code

[PATCH] qio: Inherit follow_coroutine_ctx across TLS

2024-05-15 Thread Eric Blake
Since qemu 8.2, the combination of NBD + TLS + iothread crashes on an assertion failure: qemu-kvm: ../io/channel.c:534: void qio_channel_restart_read(void *): Assertion `qemu_get_current_aio_context() == qemu_coroutine_get_aio_context(co)' failed. It turns out that when we removed AioContext

Re: [PATCH RFC v4 0/7] virtio-net: add support for SR-IOV emulation

2024-05-15 Thread Yui Washizu
On 2024/04/28 18:05, Akihiko Odaki wrote: Based-on: <20240315-reuse-v9-0-67aa69af4...@daynix.com> ("[PATCH for 9.1 v9 00/11] hw/pci: SR-IOV related fixes and improvements") Introduction This series is based on the RFC series submitted by Yui Washizu[1]. See also [2] for the

Re: [PATCH v2 02/11] qcow2: simplify L2 entries accounting for discard-no-unref

2024-05-15 Thread Alberto Garcia
On Mon 13 May 2024 09:31:54 AM +03, Andrey Drobyshev wrote: > Commits 42a2890a and b2b10904 introduce handling of discard-no-unref > option in discard_in_l2_slice() and zero_in_l2_slice(). They add even > more if's when chosing the right l2 entry. What we really need for this > option is the new

Re: [PATCH v2 01/11] qcow2: make function update_refcount_discard() global

2024-05-15 Thread Alberto Garcia
On Mon 13 May 2024 09:31:53 AM +03, Andrey Drobyshev wrote: > We are going to need it for discarding separate subclusters. The > function itself doesn't do anything with the refcount tables, it simply > adds a discard request to the queue, so rename it to qcow2_queue_discard(). > > Signed-off-by:

Re: [PATCH 03/20] docs/qapidoc: delint a tiny portion of the module

2024-05-15 Thread John Snow
On Wed, May 15, 2024, 1:27 PM Markus Armbruster wrote: > John Snow writes: > > > On Wed, May 15, 2024 at 5:17 AM Markus Armbruster > wrote: > > > >> John Snow writes: > >> > >> > In the coming patches, it's helpful to have a linting baseline. > However, > >> > there's no need to shuffle

Re: [PATCH 03/20] docs/qapidoc: delint a tiny portion of the module

2024-05-15 Thread Markus Armbruster
John Snow writes: > On Wed, May 15, 2024 at 5:17 AM Markus Armbruster wrote: > >> John Snow writes: >> >> > In the coming patches, it's helpful to have a linting baseline. However, >> > there's no need to shuffle around the deck chairs too much, because most >> > of this code will be removed

Re: [PATCH 04/20] qapi/parser: preserve indentation in QAPIDoc sections

2024-05-15 Thread John Snow
On Wed, May 15, 2024 at 10:18 AM Markus Armbruster wrote: > John Snow writes: > > > On Wed, May 15, 2024, 7:50 AM Markus Armbruster > wrote: > > > >> John Snow writes: > >> > >> > Prior to this patch, a section like this: > >> > > >> > @name: lorem ipsum > >> >dolor sit amet > >> >

Re: [PATCH 03/20] docs/qapidoc: delint a tiny portion of the module

2024-05-15 Thread John Snow
On Wed, May 15, 2024 at 5:17 AM Markus Armbruster wrote: > John Snow writes: > > > In the coming patches, it's helpful to have a linting baseline. However, > > there's no need to shuffle around the deck chairs too much, because most > > of this code will be removed once the new qapidoc

Re: [PATCH v3 2/2] vhost-user: fix lost reconnect again

2024-05-15 Thread Raphael Norwitz
The case your describing makes sense but now I have some concerns on the vhost_dev_cleanup bit. On Wed, May 15, 2024 at 1:47 AM Li Feng wrote: > > > > > 2024年5月14日 21:58,Raphael Norwitz 写道: > > > > Code looks good. Just a question on the error case you're trying to fix. > > > > On Tue, May 14,

Re: [PATCH v3 1/2] Revert "vhost-user: fix lost reconnect"

2024-05-15 Thread Raphael Norwitz
On Wed, May 15, 2024 at 1:47 AM Li Feng wrote: > > > > > 2024年5月14日 21:58,Raphael Norwitz 写道: > > > > The code for these two patches looks fine. Just some questions on the > > failure case you're trying to fix. > > > > > > On Tue, May 14, 2024 at 2:12 AM Li Feng wrote: > >> > >> This reverts

Re: [PATCH 04/20] qapi/parser: preserve indentation in QAPIDoc sections

2024-05-15 Thread Markus Armbruster
John Snow writes: > On Wed, May 15, 2024, 7:50 AM Markus Armbruster wrote: > >> John Snow writes: >> >> > Prior to this patch, a section like this: >> > >> > @name: lorem ipsum >> >dolor sit amet >> > consectetur adipiscing elit >> > >> > would be parsed as: >> > >> > "lorem

Re: [PATCH 04/20] qapi/parser: preserve indentation in QAPIDoc sections

2024-05-15 Thread John Snow
On Wed, May 15, 2024, 7:50 AM Markus Armbruster wrote: > John Snow writes: > > > Prior to this patch, a section like this: > > > > @name: lorem ipsum > >dolor sit amet > > consectetur adipiscing elit > > > > would be parsed as: > > > > "lorem ipsum\ndolor sit amet\n consectetur

Re: [PATCH 03/20] docs/qapidoc: delint a tiny portion of the module

2024-05-15 Thread John Snow
On Wed, May 15, 2024, 5:17 AM Markus Armbruster wrote: > John Snow writes: > > > In the coming patches, it's helpful to have a linting baseline. However, > > there's no need to shuffle around the deck chairs too much, because most > > of this code will be removed once the new qapidoc generator

Re: [PATCH 04/20] qapi/parser: preserve indentation in QAPIDoc sections

2024-05-15 Thread Markus Armbruster
John Snow writes: > Prior to this patch, a section like this: > > @name: lorem ipsum >dolor sit amet > consectetur adipiscing elit > > would be parsed as: > > "lorem ipsum\ndolor sit amet\n consectetur adipiscing elit" > > We want to preserve the indentation for even the first body

Re: [PATCH v3] hw/pflash: fix block write start

2024-05-15 Thread Philippe Mathieu-Daudé
On 15/5/24 10:43, Gerd Hoffmann wrote: Move the pflash_blk_write_start() call. We need the offset of the first data write, not the offset for the setup (number-of-bytes) write. Without this fix u-boot can do block writes to the first flash block only. Wow, that is a fast fix :) Thanks!

Re: [PATCH 03/20] docs/qapidoc: delint a tiny portion of the module

2024-05-15 Thread Markus Armbruster
John Snow writes: > In the coming patches, it's helpful to have a linting baseline. However, > there's no need to shuffle around the deck chairs too much, because most > of this code will be removed once the new qapidoc generator (the > "transmogrifier") is in place. > > To ease my pain: just

Re: [PATCH 02/20] qapi: linter fixups

2024-05-15 Thread Markus Armbruster
John Snow writes: > Fix minor irritants to pylint/flake8 et al. > > (Yes, these need to be guarded by the Python tests. That's a work in > progress, a series that's quite likely to follow once I finish this > Sphinx project. Please pardon the temporary irritation.) No worries; one step at a

[PATCH v3] hw/pflash: fix block write start

2024-05-15 Thread Gerd Hoffmann
Move the pflash_blk_write_start() call. We need the offset of the first data write, not the offset for the setup (number-of-bytes) write. Without this fix u-boot can do block writes to the first flash block only. While being at it drop a leftover FIXME. Resolves: #2343 Fixes: fcc79f2e0955