From: John Levon <john.levon@nutanix.com>
To: "Cédric Le Goater" <clg@redhat.com>
Cc: qemu-devel@nongnu.org, "Tony Krowiak" <akrowiak@linux.ibm.com>,
"Stefano Garzarella" <sgarzare@redhat.com>,
"Peter Xu" <peterx@redhat.com>, "Thomas Huth" <thuth@redhat.com>,
"Matthew Rosato" <mjrosato@linux.ibm.com>,
"David Hildenbrand" <david@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
qemu-s390x@nongnu.org, "Tomita Moeko" <tomitamoeko@gmail.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Halil Pasic" <pasic@linux.ibm.com>,
"Jason Herne" <jjherne@linux.ibm.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Eric Farman" <farman@linux.ibm.com>,
"John Johnson" <john.g.johnson@oracle.com>,
"Elena Ufimtseva" <elena.ufimtseva@oracle.com>,
"Jagannathan Raman" <jag.raman@oracle.com>
Subject: Re: [PATCH 08/14] vfio: add vfio-pci-base class
Date: Fri, 25 Apr 2025 14:01:07 +0100 [thread overview]
Message-ID: <aAuHk0WEUbS_inCn@lent> (raw)
In-Reply-To: <08d7eb98-4d0c-419a-b143-88b7852a62a5@redhat.com>
On Fri, Apr 25, 2025 at 02:46:48PM +0200, Cédric Le Goater wrote:
> After this patch, here is what we have for the base class :
> static const Property vfio_pci_base_dev_properties[] = {
> DEFINE_PROP_ON_OFF_AUTO("x-pre-copy-dirty-page-tracking", VFIOPCIDevice,
> vbasedev.pre_copy_dirty_page_tracking,
> ON_OFF_AUTO_ON),
> DEFINE_PROP_ON_OFF_AUTO("x-device-dirty-page-tracking", VFIOPCIDevice,
> vbasedev.device_dirty_page_tracking,
> ON_OFF_AUTO_ON),
> DEFINE_PROP_UINT32("x-intx-mmap-timeout-ms", VFIOPCIDevice,
> intx.mmap_timeout, 1100),
> DEFINE_PROP_ON_OFF_AUTO("enable-migration", VFIOPCIDevice,
> vbasedev.enable_migration, ON_OFF_AUTO_AUTO),
> DEFINE_PROP("x-migration-multifd-transfer", VFIOPCIDevice,
> vbasedev.migration_multifd_transfer,
> vfio_pci_migration_multifd_transfer_prop, OnOffAuto,
> .set_default = true, .defval.i = ON_OFF_AUTO_AUTO),
> DEFINE_PROP_BOOL("migration-events", VFIOPCIDevice,
> vbasedev.migration_events, false),
> DEFINE_PROP_BOOL("x-no-mmap", VFIOPCIDevice, vbasedev.no_mmap, false),
> DEFINE_PROP_BOOL("x-balloon-allowed", VFIOPCIDevice,
> vbasedev.ram_block_discard_allowed, false),
> DEFINE_PROP_BOOL("x-no-kvm-intx", VFIOPCIDevice, no_kvm_intx, false),
> DEFINE_PROP_BOOL("x-no-kvm-msi", VFIOPCIDevice, no_kvm_msi, false),
> DEFINE_PROP_BOOL("x-no-kvm-msix", VFIOPCIDevice, no_kvm_msix, false),
> DEFINE_PROP_BOOL("x-no-kvm-ioeventfd", VFIOPCIDevice, no_kvm_ioeventfd,
> false),
> DEFINE_PROP_BOOL("x-no-vfio-ioeventfd", VFIOPCIDevice, no_vfio_ioeventfd,
> false),
> DEFINE_PROP_UINT32("x-pci-vendor-id", VFIOPCIDevice, vendor_id, PCI_ANY_ID),
> DEFINE_PROP_UINT32("x-pci-device-id", VFIOPCIDevice, device_id, PCI_ANY_ID),
> DEFINE_PROP_UINT32("x-pci-sub-vendor-id", VFIOPCIDevice,
> sub_vendor_id, PCI_ANY_ID),
> DEFINE_PROP_UINT32("x-pci-sub-device-id", VFIOPCIDevice,
> sub_device_id, PCI_ANY_ID),
> DEFINE_PROP_OFF_AUTO_PCIBAR("x-msix-relocation", VFIOPCIDevice, msix_relo,
> OFF_AUTO_PCIBAR_OFF),
> };
> and for vfio-pci :
> static const Property vfio_pci_dev_properties[] = {
> DEFINE_PROP_PCI_HOST_DEVADDR("host", VFIOPCIDevice, host),
> DEFINE_PROP_UUID_NODEFAULT("vf-token", VFIOPCIDevice, vf_token),
> DEFINE_PROP_STRING("sysfsdev", VFIOPCIDevice, vbasedev.sysfsdev),
> DEFINE_PROP_ON_OFF_AUTO("display", VFIOPCIDevice,
> display, ON_OFF_AUTO_OFF),
> DEFINE_PROP_UINT32("xres", VFIOPCIDevice, display_xres, 0),
> DEFINE_PROP_UINT32("yres", VFIOPCIDevice, display_yres, 0),
> DEFINE_PROP_BIT("x-vga", VFIOPCIDevice, features,
> VFIO_FEATURE_ENABLE_VGA_BIT, false),
> DEFINE_PROP_BIT("x-req", VFIOPCIDevice, features,
> VFIO_FEATURE_ENABLE_REQ_BIT, true),
> DEFINE_PROP_BIT("x-igd-opregion", VFIOPCIDevice, features,
> VFIO_FEATURE_ENABLE_IGD_OPREGION_BIT, false),
> DEFINE_PROP_UINT32("x-igd-gms", VFIOPCIDevice, igd_gms, 0),
> DEFINE_PROP_BIT("x-igd-lpc", VFIOPCIDevice, features,
> VFIO_FEATURE_ENABLE_IGD_LPC_BIT, false),
> DEFINE_PROP_ON_OFF_AUTO("x-igd-legacy-mode", VFIOPCIDevice,
> igd_legacy_mode, ON_OFF_AUTO_AUTO),
> DEFINE_PROP_BOOL("x-no-geforce-quirks", VFIOPCIDevice,
> no_geforce_quirks, false),
> DEFINE_PROP_UNSIGNED_NODEFAULT("x-nv-gpudirect-clique", VFIOPCIDevice,
> nv_gpudirect_clique,
> qdev_prop_nv_gpudirect_clique, uint8_t),
> #ifdef CONFIG_IOMMUFD
> DEFINE_PROP_LINK("iommufd", VFIOPCIDevice, vbasedev.iommufd,
> TYPE_IOMMUFD_BACKEND, IOMMUFDBackend *),
> #endif
> DEFINE_PROP_BOOL("skip-vsc-check", VFIOPCIDevice, skip_vsc_check, true),
> };
> Graphic property and host device definitions are excluded from the
> base class it seems. This might fit vfio-user needs but it looks
> like a quick hack from the vfio-pci side. It needs more work.
Can you suggest a preferred approach? I'm definitely not wedded to the current
way (after all, I didn't write it !), but I'm not sure how else we could do it.
Perhaps if there's some way to deregister properties when vfio-user
instantiates?
> > > Can you remind me why the vfio-pci class for vfio-user can not
> > > inherit directly from vfio-pci ?
> >
> > For the above reason: we'd inherit many properties that don't work for
> > vfio-user.
>
> What do you mean by "don't work" ? functionally irrelevant ?
I don't know the answer to that in general. Certainly some are just irrelevant
(like sysfsdev), but it's entirely possible the other stuff actively breaks.
Presumably you agree it's not good to introduce potential footguns for users
here?
regards
john
next prev parent reply other threads:[~2025-04-25 13:02 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 13:48 [PATCH 00/14] vfio: preparation for vfio-user John Levon
2025-04-09 13:48 ` [PATCH 01/14] vfio: refactor out vfio_interrupt_setup() John Levon
2025-04-23 12:20 ` Cédric Le Goater
2025-04-09 13:48 ` [PATCH 02/14] vfio: refactor out vfio_pci_config_setup() John Levon
2025-04-09 15:38 ` Tomita Moeko
2025-04-09 15:41 ` John Levon
2025-04-09 13:48 ` [PATCH 03/14] vfio: add vfio_prepare_device() John Levon
2025-04-23 12:45 ` Cédric Le Goater
2025-04-23 13:19 ` John Levon
2025-04-09 13:48 ` [PATCH 04/14] vfio: add vfio_attach_device_by_iommu_type() John Levon
2025-04-23 13:25 ` Cédric Le Goater
2025-04-09 13:48 ` [PATCH 05/14] vfio/container: pass listener_begin/commit callbacks John Levon
2025-04-23 13:45 ` Cédric Le Goater
2025-04-24 16:24 ` Cédric Le Goater
2025-04-24 16:28 ` John Levon
2025-04-24 16:35 ` Cédric Le Goater
2025-04-09 13:48 ` [PATCH 06/14] vfio: add flags parameter to DMA unmap callback John Levon
2025-04-09 13:48 ` [PATCH 07/14] vfio: specify VFIO_DMA_UNMAP_FLAG_ALL to callback John Levon
2025-04-23 17:01 ` Cédric Le Goater
2025-04-23 17:17 ` John Levon
2025-04-24 17:16 ` Cédric Le Goater
2025-04-24 19:35 ` John Levon
2025-04-28 11:41 ` Cédric Le Goater
2025-04-09 13:48 ` [PATCH 08/14] vfio: add vfio-pci-base class John Levon
2025-04-24 15:17 ` Cédric Le Goater
2025-04-24 21:52 ` John Levon
2025-04-25 12:46 ` Cédric Le Goater
2025-04-25 13:01 ` John Levon [this message]
2025-04-28 12:53 ` Cédric Le Goater
2025-04-09 13:48 ` [PATCH 09/14] vfio: add vfio_device_get_irq_info() helper John Levon
2025-04-23 17:16 ` Cédric Le Goater
2025-04-09 13:48 ` [PATCH 10/14] vfio: consistently handle return value for helpers John Levon
2025-04-24 15:19 ` Cédric Le Goater
2025-04-09 13:48 ` [PATCH 11/14] vfio: add vfio_pci_config_space_read/write() John Levon
2025-04-09 15:51 ` Tomita Moeko
2025-04-09 15:54 ` John Levon
2025-04-09 16:30 ` Tomita Moeko
2025-04-24 15:59 ` Cédric Le Goater
2025-04-24 16:06 ` Cédric Le Goater
2025-04-09 13:48 ` [PATCH 12/14] vfio: add region info cache John Levon
2025-04-24 16:08 ` Cédric Le Goater
2025-04-24 16:26 ` John Levon
2025-04-28 15:16 ` Cédric Le Goater
2025-04-28 15:26 ` John Levon
2025-04-28 15:39 ` Cédric Le Goater
2025-04-28 16:09 ` John Levon
2025-04-29 22:41 ` John Levon
2025-04-09 13:48 ` [PATCH 13/14] vfio: add device IO ops vector John Levon
2025-04-24 16:18 ` Cédric Le Goater
2025-04-09 13:48 ` [PATCH 14/14] vfio/container: pass MemoryRegion to DMA operations John Levon
2025-04-24 16:32 ` Cédric Le Goater
2025-04-24 17:49 ` John Levon
2025-04-25 7:59 ` [PATCH 00/14] vfio: preparation for vfio-user 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=aAuHk0WEUbS_inCn@lent \
--to=john.levon@nutanix.com \
--cc=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=clg@redhat.com \
--cc=david@redhat.com \
--cc=elena.ufimtseva@oracle.com \
--cc=farman@linux.ibm.com \
--cc=jag.raman@oracle.com \
--cc=jjherne@linux.ibm.com \
--cc=john.g.johnson@oracle.com \
--cc=mjrosato@linux.ibm.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=sgarzare@redhat.com \
--cc=thuth@redhat.com \
--cc=tomitamoeko@gmail.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).