Hi,

vhost_log_global_start() and vhost_log_global_stop() abort the whole
qemu process on error.  Not least because vhost devices are generally
outside of qemu (i.e. use a foreign code base), that is not great, as we
can basically be forced to abort because of bugs (or maybe even properly
behaving, just unexpectedly so) in other code bases.

In case of vhost_log_global_start(), the solution is simple: Ever since
commit 3688fec8923 ("memory: Add Error** argument to .log_global_start()
handler"), it can just return proper errors, so do that instead of
aborting.

In case of vhost_log_global_stop(), we cannot return errors; but we can
just ignore them.  In the worst case, some other process will keep
logging into shared memory we have already unmapped.  That's fine.


Hanna Czenczek (2):
  vhost: Do not abort on log-start error
  vhost: Do not abort on log-stop error

 hw/virtio/vhost.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

-- 
2.50.1

On 24.07.2025 15:59, Hanna Czenczek wrote:
> Hi,
> 
> vhost_log_global_start() and vhost_log_global_stop() abort the whole
> qemu process on error.  Not least because vhost devices are generally
> outside of qemu (i.e. use a foreign code base), that is not great, as we
> can basically be forced to abort because of bugs (or maybe even properly
> behaving, just unexpectedly so) in other code bases.
> 
> In case of vhost_log_global_start(), the solution is simple: Ever since
> commit 3688fec8923 ("memory: Add Error** argument to .log_global_start()
> handler"), it can just return proper errors, so do that instead of
> aborting.
> 
> In case of vhost_log_global_stop(), we cannot return errors; but we can
> just ignore them.  In the worst case, some other process will keep
> logging into shared memory we have already unmapped.  That's fine.
> 
> 
> Hanna Czenczek (2):
>    vhost: Do not abort on log-start error
>    vhost: Do not abort on log-stop error

I'm picking this up for qemu 10.0.x stable series, as simple
bugfixes.  Please let me know if I should not.

Thanks,

/mjt

Tested this series of patches with vhost-net regression tests,
everything works fine.

Tested-by: Lei Yang <leiyang@redhat.com>

On Thu, Jul 24, 2025 at 9:01 PM Hanna Czenczek <hreitz@redhat.com> wrote:
>
> Hi,
>
> vhost_log_global_start() and vhost_log_global_stop() abort the whole
> qemu process on error.  Not least because vhost devices are generally
> outside of qemu (i.e. use a foreign code base), that is not great, as we
> can basically be forced to abort because of bugs (or maybe even properly
> behaving, just unexpectedly so) in other code bases.
>
> In case of vhost_log_global_start(), the solution is simple: Ever since
> commit 3688fec8923 ("memory: Add Error** argument to .log_global_start()
> handler"), it can just return proper errors, so do that instead of
> aborting.
>
> In case of vhost_log_global_stop(), we cannot return errors; but we can
> just ignore them.  In the worst case, some other process will keep
> logging into shared memory we have already unmapped.  That's fine.
>
>
> Hanna Czenczek (2):
>   vhost: Do not abort on log-start error
>   vhost: Do not abort on log-stop error
>
>  hw/virtio/vhost.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> --
> 2.50.1
>
>