qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Levon <john.levon@nutanix.com>
To: "Cédric Le Goater" <clg@redhat.com>
Cc: qemu-devel@nongnu.org,
	"Thanos Makatos" <thanos.makatos@nutanix.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"John Johnson" <john.g.johnson@oracle.com>,
	"Elena Ufimtseva" <elena.ufimtseva@oracle.com>,
	"Jagannathan Raman" <jag.raman@oracle.com>
Subject: Re: [PATCH v4 03/19] vfio-user: implement message receive infrastructure
Date: Wed, 25 Jun 2025 10:16:11 +0100	[thread overview]
Message-ID: <aFu-W1mpmGaZByjZ@lent> (raw)
In-Reply-To: <4b2bd5c8-0353-4603-8b66-b0c4b7517c96@redhat.com>

On Wed, Jun 25, 2025 at 10:02:50AM +0200, Cédric Le Goater wrote:

> > +/*
> > + * Process a received message.
> > + */
> > +static void vfio_user_process(VFIOUserProxy *proxy, VFIOUserMsg *msg,
> > +                              bool isreply)
> 
> This routine could have an 'Error **errp' parameter and avoid the
> error_printf() below. Can you fix that please ?

I could, but I think the current code makes more sense actually.

vfio_user_process() handles a single message. If it's a reply with an error, we
want to report it, but we don't want to tear down the device altogether. So it
wouldn't make much sense for this particular routine to pass the error back to
its caller?
>
> > + * For replies, find matching outgoing request and wake any waiters.
> > + * For requests, queue in incoming list and run request BH.
> > + */
> > +static int vfio_user_recv_one(VFIOUserProxy *proxy)
> 
> I would add an 'Error **' parameter too ...

This one I can do though

regards
john


  reply	other threads:[~2025-06-25  9:17 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-19 13:31 [PATCH v4 00/19] vfio-user client John Levon
2025-06-19 13:31 ` [PATCH v4 01/19] vfio-user: add vfio-user class and container John Levon
2025-06-19 13:31 ` [PATCH v4 02/19] vfio-user: connect vfio proxy to remote server John Levon
2025-06-19 13:31 ` [PATCH v4 03/19] vfio-user: implement message receive infrastructure John Levon
2025-06-25  8:02   ` Cédric Le Goater
2025-06-25  9:16     ` John Levon [this message]
2025-06-19 13:31 ` [PATCH v4 04/19] vfio-user: implement message send infrastructure John Levon
2025-06-25  8:05   ` Cédric Le Goater
2025-06-19 13:31 ` [PATCH v4 05/19] vfio-user: implement VFIO_USER_DEVICE_GET_INFO John Levon
2025-06-25  8:06   ` Cédric Le Goater
2025-06-19 13:31 ` [PATCH v4 06/19] vfio-user: implement VFIO_USER_DEVICE_GET_REGION_INFO John Levon
2025-06-19 13:31 ` [PATCH v4 07/19] vfio-user: implement VFIO_USER_REGION_READ/WRITE John Levon
2025-06-19 13:31 ` [PATCH v4 08/19] vfio-user: set up PCI in vfio_user_pci_realize() John Levon
2025-06-19 13:31 ` [PATCH v4 09/19] vfio-user: implement VFIO_USER_DEVICE_GET/SET_IRQ* John Levon
2025-06-19 13:31 ` [PATCH v4 10/19] vfio-user: forward MSI-X PBA BAR accesses to server John Levon
2025-06-19 13:31 ` [PATCH v4 11/19] vfio-user: set up container access to the proxy John Levon
2025-06-19 13:31 ` [PATCH v4 12/19] vfio-user: implement VFIO_USER_DEVICE_RESET John Levon
2025-06-19 13:31 ` [PATCH v4 13/19] vfio-user: implement VFIO_USER_DMA_MAP/UNMAP John Levon
2025-06-19 13:31 ` [PATCH v4 14/19] vfio-user: implement VFIO_USER_DMA_READ/WRITE John Levon
2025-06-19 13:31 ` [PATCH v4 15/19] vfio-user: add 'x-msg-timeout' option John Levon
2025-06-19 13:31 ` [PATCH v4 16/19] vfio-user: support posted writes John Levon
2025-06-19 13:31 ` [PATCH v4 17/19] vfio-user: add coalesced " John Levon
2025-06-19 13:31 ` [PATCH v4 18/19] docs: add vfio-user documentation John Levon
2025-06-19 13:31 ` [PATCH v4 19/19] vfio-user: introduce vfio-user protocol specification John Levon
2025-06-20  9:11 ` [PATCH v4 00/19] vfio-user client Cédric Le Goater
2025-06-21 11:45   ` John Levon
2025-06-21 14:25     ` Cédric Le Goater
2025-06-21 14:50       ` John Levon
2025-06-25  8:56         ` Cédric Le Goater
2025-06-25  9:03           ` John Levon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aFu-W1mpmGaZByjZ@lent \
    --to=john.levon@nutanix.com \
    --cc=alex.williamson@redhat.com \
    --cc=berrange@redhat.com \
    --cc=clg@redhat.com \
    --cc=elena.ufimtseva@oracle.com \
    --cc=jag.raman@oracle.com \
    --cc=john.g.johnson@oracle.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thanos.makatos@nutanix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).