qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Levon <john.levon@nutanix.com>
To: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Cc: qemu-devel@nongnu.org, "Daniel P. Berrangé" <berrange@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Thanos Makatos" <thanos.makatos@nutanix.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Cédric Le Goater" <clg@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"John Johnson" <john.g.johnson@oracle.com>,
	"Elena Ufimtseva" <elena.ufimtseva@oracle.com>,
	"Jagannathan Raman" <jag.raman@oracle.com>
Subject: Re: [PATCH v3 06/23] vfio-user: add vfio-user class and container
Date: Tue, 10 Jun 2025 04:56:33 -0700	[thread overview]
Message-ID: <aEgdcfh-OBklhGFg@lent> (raw)
In-Reply-To: <f1a03beb-3667-485e-aca3-5a8f4990f67a@nutanix.com>

On Tue, Jun 10, 2025 at 12:42:35PM +0100, Mark Cave-Ayland wrote:

> Question: how do you see the division between hw/vfio and hw/vfio-user? My
> initial feeling is that there is substantial sharing between the two, in
> which case I'd expect the files to be in hw/vfio as e.g.
> hw/vfio/container-user.c etc. instead of its own directory.

That was also in the earlier patchsets! Cédric asked for hw/vfio-user - and I
think I actually prefer it myself. The amount we export from hw/vfio is actually
fairly minimal (now).

> > +#include "hw/vfio/vfio-container-base.h"
> > +
> > +/* MMU container sub-class for vfio-user. */
> > +typedef struct VFIOUserContainer {
> > +    VFIOContainerBase bcontainer;
> > +} VFIOUserContainer;
> > +
> > +OBJECT_DECLARE_SIMPLE_TYPE(VFIOUserContainer, VFIO_IOMMU_USER);
> 
> As per the documentation at https://qemu-project.gitlab.io/qemu/devel/style.html#qemu-object-model-declarations
> the parent object should always be named parent_obj and struct shouldn't
> have a typedef i.e.
> 
> /* MMU container sub-class for vfio-user. */
> struct VFIOUserContainer {
>     VFIOContainerBase parent_obj;
> };
> 
> OBJECT_DECLARE_SIMPLE_TYPE(VFIOUserContainer, VFIO_IOMMU_USER);

I don't think I want to diverge from VFIOContainer here, though, right?

> > +static VFIOUserContainer *
> > +vfio_user_container_connect(AddressSpace *as, Error **errp)
> > +{
> > +    VFIOContainerBase *bcontainer;
> > +    VFIOUserContainer *container;
> > +    VFIOAddressSpace *space;
> > +    VFIOIOMMUClass *vioc;
> > +
> > +    space = vfio_address_space_get(as);
> > +
> > +    container = vfio_user_create_container(errp);
> > +    if (!container) {
> > +        goto put_space_exit;
> > +    }
> > +
> > +    bcontainer = &container->bcontainer;
> 
> References to the object hierarchy should always be done with the
> automatically generated QOM cast macros since they are easier to read, and
> also ensure type safety e.g.:
> 
>        bcontainer = VFIO_IOMMU(container);

Ditto. Sounds like a fine future cleanup that should be applied to all the code,
but for now, and for review reasons, I'd prefer to be "the same" as hw/vfio/

> > +struct VFIOUserPCIDevice {
> > +    VFIOPCIDevice device;
> > +    char *sock_name;
> > +};
> 
> Again as per the documentation link above, device should be called
> parent_obj plus there should be a empty line between parent_obj and the
> other members i.e.
> 
> struct VFIOUserPCIDevice {
>     VFIOPCIDevice parent_obj;
> 
>     char *sock_name;
> }
> 
> Note that by using QOM casts the name of the parent object member is not
> exposed to the remainder of the code.

I can make this change, though, as there's no vfio equivalent, if Cédric thinks
I should too.

> > +static void register_vfio_user_dev_type(void)
> > +{
> > +    type_register_static(&vfio_user_pci_dev_info);
> > +}
> > +
> > + type_init(register_vfio_user_dev_type)
> 
> Use DEFINE_TYPES as you've already done above instead of type_init() here.

Again, same as hw/vfio/pci.c

regards
john


  reply	other threads:[~2025-06-10 11:58 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-07  0:10 [PATCH v3 00/23] vfio-user client John Levon
2025-06-07  0:10 ` [PATCH v3 01/23] vfio: export PCI helpers needed for vfio-user John Levon
2025-06-10  7:00   ` Cédric Le Goater
2025-06-10 10:47   ` Mark Cave-Ayland
2025-06-10 17:38   ` Cédric Le Goater
2025-06-07  0:10 ` [PATCH v3 02/23] vfio: enable per-IRQ MSI-X masking John Levon
2025-06-10  7:27   ` Cédric Le Goater
2025-06-10 21:52   ` John Levon
2025-06-11  7:13     ` Cédric Le Goater
2025-06-07  0:10 ` [PATCH v3 03/23] vfio: add per-region fd support John Levon
2025-06-10  7:42   ` Cédric Le Goater
2025-06-10 12:34     ` John Levon
2025-06-11  7:12       ` Cédric Le Goater
2025-06-10 16:59     ` John Levon
2025-06-10 18:15     ` John Levon
2025-06-10 10:58   ` Mark Cave-Ayland
2025-06-10 11:27     ` John Levon
2025-06-10 11:57       ` Cédric Le Goater
2025-06-10 12:13         ` John Levon
2025-06-11  7:24   ` Cédric Le Goater
2025-06-07  0:10 ` [PATCH v3 04/23] vfio: mark posted writes in region write callbacks John Levon
2025-06-11  7:24   ` Cédric Le Goater
2025-06-07  0:10 ` [PATCH v3 05/23] vfio-user: introduce vfio-user protocol specification John Levon
2025-06-10  9:38   ` Cédric Le Goater
2025-06-10  9:55     ` John Levon
2025-06-10 10:12       ` Cédric Le Goater
2025-06-10 10:22         ` Mark Cave-Ayland
2025-06-10 13:06           ` Cédric Le Goater
2025-06-10 16:55     ` John Levon
2025-06-11 11:49   ` Cédric Le Goater
2025-06-07  0:10 ` [PATCH v3 06/23] vfio-user: add vfio-user class and container John Levon
2025-06-10  9:57   ` Cédric Le Goater
2025-06-10 16:52     ` John Levon
2025-06-11  7:46       ` Cédric Le Goater
2025-06-11  8:58         ` John Levon
2025-06-10 11:42   ` Mark Cave-Ayland
2025-06-10 11:56     ` John Levon [this message]
2025-06-10 12:15       ` Cédric Le Goater
2025-06-10 12:13     ` Cédric Le Goater
2025-06-12  6:39   ` Cédric Le Goater
2025-06-12 14:02     ` John Levon
2025-06-07  0:10 ` [PATCH v3 07/23] vfio-user: connect vfio proxy to remote server John Levon
2025-06-07  0:10 ` [PATCH v3 08/23] vfio-user: implement message receive infrastructure John Levon
2025-06-07  0:10 ` [PATCH v3 09/23] vfio-user: implement message send infrastructure John Levon
2025-06-07  0:10 ` [PATCH v3 10/23] vfio-user: implement VFIO_USER_DEVICE_GET_INFO John Levon
2025-06-07  0:10 ` [PATCH v3 11/23] vfio-user: implement VFIO_USER_DEVICE_GET_REGION_INFO John Levon
2025-06-07  0:10 ` [PATCH v3 12/23] vfio-user: implement VFIO_USER_REGION_READ/WRITE John Levon
2025-06-07  0:10 ` [PATCH v3 13/23] vfio-user: set up PCI in vfio_user_pci_realize() John Levon
2025-06-07  0:10 ` [PATCH v3 14/23] vfio-user: implement VFIO_USER_DEVICE_GET/SET_IRQ* John Levon
2025-06-07  0:10 ` [PATCH v3 15/23] vfio-user: forward MSI-X PBA BAR accesses to server John Levon
2025-06-07  0:10 ` [PATCH v3 16/23] vfio-user: set up container access to the proxy John Levon
2025-06-07  0:10 ` [PATCH v3 17/23] vfio-user: implement VFIO_USER_DEVICE_RESET John Levon
2025-06-07  0:10 ` [PATCH v3 18/23] vfio-user: implement VFIO_USER_DMA_MAP/UNMAP John Levon
2025-06-07  0:10 ` [PATCH v3 19/23] vfio-user: implement VFIO_USER_DMA_READ/WRITE John Levon
2025-06-07  0:10 ` [PATCH v3 20/23] vfio-user: add 'x-msg-timeout' option John Levon
2025-06-07  0:10 ` [PATCH v3 21/23] vfio-user: support posted writes John Levon
2025-06-07  0:10 ` [PATCH v3 22/23] vfio-user: add coalesced " John Levon
2025-06-07  0:10 ` [PATCH v3 23/23] docs: add vfio-user documentation John Levon
2025-06-12  6:57 ` [PATCH v3 00/23] vfio-user client Cédric Le Goater
2025-06-12 14:19   ` John Levon
2025-06-19 11:56     ` Cédric Le Goater
2025-06-20  8:20       ` Mark Cave-Ayland
2025-06-20  8:32         ` Cédric Le Goater
2025-06-21 12:22           ` John Levon
2025-06-22 12:57             ` Cédric Le Goater
2025-06-23  8:36               ` John Levon
2025-06-23 16:14                 ` Mark Cave-Ayland
2025-06-23 16:09               ` Mark Cave-Ayland
2025-06-23 17:06                 ` Cédric Le Goater

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=aEgdcfh-OBklhGFg@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=mark.caveayland@nutanix.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).