* [PATCH v3 01/23] vfio: export PCI helpers needed for vfio-user
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-10 7:00 ` Cédric Le Goater
` (2 more replies)
2025-06-07 0:10 ` [PATCH v3 02/23] vfio: enable per-IRQ MSI-X masking John Levon
` (22 subsequent siblings)
23 siblings, 3 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon
The vfio-user code will need to re-use various parts of the vfio PCI
code. Export them in hw/vfio/pci.h, and rename them to the vfio_pci_*
namespace.
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio/pci.h | 11 ++++++++++
hw/vfio/pci.c | 48 ++++++++++++++++++++++----------------------
hw/vfio/trace-events | 6 +++---
3 files changed, 38 insertions(+), 27 deletions(-)
diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
index 5ce0fb916f..d4c6b2e7b7 100644
--- a/hw/vfio/pci.h
+++ b/hw/vfio/pci.h
@@ -248,4 +248,15 @@ void vfio_display_finalize(VFIOPCIDevice *vdev);
extern const VMStateDescription vfio_display_vmstate;
+void vfio_pci_bars_exit(VFIOPCIDevice *vdev);
+bool vfio_pci_add_capabilities(VFIOPCIDevice *vdev, Error **errp);
+bool vfio_pci_config_setup(VFIOPCIDevice *vdev, Error **errp);
+bool vfio_pci_interrupt_setup(VFIOPCIDevice *vdev, Error **errp);
+void vfio_pci_intx_eoi(VFIODevice *vbasedev);
+void vfio_pci_put_device(VFIOPCIDevice *vdev);
+bool vfio_pci_populate_device(VFIOPCIDevice *vdev, Error **errp);
+void vfio_pci_register_err_notifier(VFIOPCIDevice *vdev);
+void vfio_pci_register_req_notifier(VFIOPCIDevice *vdev);
+void vfio_pci_teardown_msi(VFIOPCIDevice *vdev);
+
#endif /* HW_VFIO_VFIO_PCI_H */
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index b1250d85bf..a49405660a 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -103,7 +103,7 @@ static void vfio_intx_interrupt(void *opaque)
}
}
-static void vfio_intx_eoi(VFIODevice *vbasedev)
+void vfio_pci_intx_eoi(VFIODevice *vbasedev)
{
VFIOPCIDevice *vdev = container_of(vbasedev, VFIOPCIDevice, vbasedev);
@@ -111,7 +111,7 @@ static void vfio_intx_eoi(VFIODevice *vbasedev)
return;
}
- trace_vfio_intx_eoi(vbasedev->name);
+ trace_vfio_pci_intx_eoi(vbasedev->name);
vdev->intx.pending = false;
pci_irq_deassert(&vdev->pdev);
@@ -236,7 +236,7 @@ static void vfio_intx_update(VFIOPCIDevice *vdev, PCIINTxRoute *route)
}
/* Re-enable the interrupt in cased we missed an EOI */
- vfio_intx_eoi(&vdev->vbasedev);
+ vfio_pci_intx_eoi(&vdev->vbasedev);
}
static void vfio_intx_routing_notifier(PCIDevice *pdev)
@@ -1743,7 +1743,7 @@ static bool vfio_msix_setup(VFIOPCIDevice *vdev, int pos, Error **errp)
return true;
}
-static void vfio_teardown_msi(VFIOPCIDevice *vdev)
+void vfio_pci_teardown_msi(VFIOPCIDevice *vdev)
{
msi_uninit(&vdev->pdev);
@@ -1839,7 +1839,7 @@ static void vfio_bars_register(VFIOPCIDevice *vdev)
}
}
-static void vfio_bars_exit(VFIOPCIDevice *vdev)
+void vfio_pci_bars_exit(VFIOPCIDevice *vdev)
{
int i;
@@ -2430,7 +2430,7 @@ static void vfio_add_ext_cap(VFIOPCIDevice *vdev)
g_free(config);
}
-static bool vfio_add_capabilities(VFIOPCIDevice *vdev, Error **errp)
+bool vfio_pci_add_capabilities(VFIOPCIDevice *vdev, Error **errp)
{
PCIDevice *pdev = &vdev->pdev;
@@ -2706,7 +2706,7 @@ static int vfio_pci_load_config(VFIODevice *vbasedev, QEMUFile *f)
static VFIODeviceOps vfio_pci_ops = {
.vfio_compute_needs_reset = vfio_pci_compute_needs_reset,
.vfio_hot_reset_multi = vfio_pci_hot_reset_multi,
- .vfio_eoi = vfio_intx_eoi,
+ .vfio_eoi = vfio_pci_intx_eoi,
.vfio_get_object = vfio_pci_get_object,
.vfio_save_config = vfio_pci_save_config,
.vfio_load_config = vfio_pci_load_config,
@@ -2777,7 +2777,7 @@ bool vfio_populate_vga(VFIOPCIDevice *vdev, Error **errp)
return true;
}
-static bool vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
+bool vfio_pci_populate_device(VFIOPCIDevice *vdev, Error **errp)
{
VFIODevice *vbasedev = &vdev->vbasedev;
struct vfio_region_info *reg_info = NULL;
@@ -2823,7 +2823,7 @@ static bool vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
return false;
}
- trace_vfio_populate_device_config(vdev->vbasedev.name,
+ trace_vfio_pci_populate_device_config(vdev->vbasedev.name,
(unsigned long)reg_info->size,
(unsigned long)reg_info->offset,
(unsigned long)reg_info->flags);
@@ -2845,7 +2845,7 @@ static bool vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
ret = vfio_device_get_irq_info(vbasedev, VFIO_PCI_ERR_IRQ_INDEX, &irq_info);
if (ret) {
/* This can fail for an old kernel or legacy PCI dev */
- trace_vfio_populate_device_get_irq_info_failure(strerror(-ret));
+ trace_vfio_pci_populate_device_get_irq_info_failure(strerror(-ret));
} else if (irq_info.count == 1) {
vdev->pci_aer = true;
} else {
@@ -2857,7 +2857,7 @@ static bool vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
return true;
}
-static void vfio_pci_put_device(VFIOPCIDevice *vdev)
+void vfio_pci_put_device(VFIOPCIDevice *vdev)
{
vfio_display_finalize(vdev);
vfio_bars_finalize(vdev);
@@ -2905,7 +2905,7 @@ static void vfio_err_notifier_handler(void *opaque)
* and continue after disabling error recovery support for the
* device.
*/
-static void vfio_register_err_notifier(VFIOPCIDevice *vdev)
+void vfio_pci_register_err_notifier(VFIOPCIDevice *vdev)
{
Error *err = NULL;
int32_t fd;
@@ -2964,7 +2964,7 @@ static void vfio_req_notifier_handler(void *opaque)
}
}
-static void vfio_register_req_notifier(VFIOPCIDevice *vdev)
+void vfio_pci_register_req_notifier(VFIOPCIDevice *vdev)
{
struct vfio_irq_info irq_info;
Error *err = NULL;
@@ -3018,7 +3018,7 @@ static void vfio_unregister_req_notifier(VFIOPCIDevice *vdev)
vdev->req_enabled = false;
}
-static bool vfio_pci_config_setup(VFIOPCIDevice *vdev, Error **errp)
+bool vfio_pci_config_setup(VFIOPCIDevice *vdev, Error **errp)
{
PCIDevice *pdev = &vdev->pdev;
VFIODevice *vbasedev = &vdev->vbasedev;
@@ -3124,7 +3124,7 @@ static bool vfio_pci_config_setup(VFIOPCIDevice *vdev, Error **errp)
return true;
}
-static bool vfio_interrupt_setup(VFIOPCIDevice *vdev, Error **errp)
+bool vfio_pci_interrupt_setup(VFIOPCIDevice *vdev, Error **errp)
{
PCIDevice *pdev = &vdev->pdev;
@@ -3214,7 +3214,7 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
goto error;
}
- if (!vfio_populate_device(vdev, errp)) {
+ if (!vfio_pci_populate_device(vdev, errp)) {
goto error;
}
@@ -3228,7 +3228,7 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
goto out_teardown;
}
- if (!vfio_add_capabilities(vdev, errp)) {
+ if (!vfio_pci_add_capabilities(vdev, errp)) {
goto out_unset_idev;
}
@@ -3244,7 +3244,7 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
vfio_bar_quirk_setup(vdev, i);
}
- if (!vfio_interrupt_setup(vdev, errp)) {
+ if (!vfio_pci_interrupt_setup(vdev, errp)) {
goto out_unset_idev;
}
@@ -3288,8 +3288,8 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
}
}
- vfio_register_err_notifier(vdev);
- vfio_register_req_notifier(vdev);
+ vfio_pci_register_err_notifier(vdev);
+ vfio_pci_register_req_notifier(vdev);
vfio_setup_resetfn_quirk(vdev);
return;
@@ -3310,8 +3310,8 @@ out_unset_idev:
pci_device_unset_iommu_device(pdev);
}
out_teardown:
- vfio_teardown_msi(vdev);
- vfio_bars_exit(vdev);
+ vfio_pci_teardown_msi(vdev);
+ vfio_pci_bars_exit(vdev);
error:
error_prepend(errp, VFIO_MSG_PREFIX, vbasedev->name);
}
@@ -3338,9 +3338,9 @@ static void vfio_exitfn(PCIDevice *pdev)
if (vdev->intx.mmap_timer) {
timer_free(vdev->intx.mmap_timer);
}
- vfio_teardown_msi(vdev);
+ vfio_pci_teardown_msi(vdev);
vfio_pci_disable_rp_atomics(vdev);
- vfio_bars_exit(vdev);
+ vfio_pci_bars_exit(vdev);
vfio_migration_exit(vbasedev);
if (!vbasedev->mdev) {
pci_device_unset_iommu_device(pdev);
diff --git a/hw/vfio/trace-events b/hw/vfio/trace-events
index e90ec9bff8..f06236f37b 100644
--- a/hw/vfio/trace-events
+++ b/hw/vfio/trace-events
@@ -2,7 +2,7 @@
# pci.c
vfio_intx_interrupt(const char *name, char line) " (%s) Pin %c"
-vfio_intx_eoi(const char *name) " (%s) EOI"
+vfio_pci_intx_eoi(const char *name) " (%s) EOI"
vfio_intx_enable_kvm(const char *name) " (%s) KVM INTx accel enabled"
vfio_intx_disable_kvm(const char *name) " (%s) KVM INTx accel disabled"
vfio_intx_update(const char *name, int new_irq, int target_irq) " (%s) IRQ moved %d -> %d"
@@ -35,8 +35,8 @@ vfio_pci_hot_reset(const char *name, const char *type) " (%s) %s"
vfio_pci_hot_reset_has_dep_devices(const char *name) "%s: hot reset dependent devices:"
vfio_pci_hot_reset_dep_devices(int domain, int bus, int slot, int function, int group_id) "\t%04x:%02x:%02x.%x group %d"
vfio_pci_hot_reset_result(const char *name, const char *result) "%s hot reset: %s"
-vfio_populate_device_config(const char *name, unsigned long size, unsigned long offset, unsigned long flags) "Device '%s' config: size: 0x%lx, offset: 0x%lx, flags: 0x%lx"
-vfio_populate_device_get_irq_info_failure(const char *errstr) "VFIO_DEVICE_GET_IRQ_INFO failure: %s"
+vfio_pci_populate_device_config(const char *name, unsigned long size, unsigned long offset, unsigned long flags) "Device '%s' config: size: 0x%lx, offset: 0x%lx, flags: 0x%lx"
+vfio_pci_populate_device_get_irq_info_failure(const char *errstr) "VFIO_DEVICE_GET_IRQ_INFO failure: %s"
vfio_mdev(const char *name, bool is_mdev) " (%s) is_mdev %d"
vfio_add_ext_cap_dropped(const char *name, uint16_t cap, uint16_t offset) "%s 0x%x@0x%x"
vfio_pci_reset(const char *name) " (%s)"
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH v3 01/23] vfio: export PCI helpers needed for vfio-user
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
2 siblings, 0 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-10 7:00 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 6/7/25 02:10, John Levon wrote:
> The vfio-user code will need to re-use various parts of the vfio PCI
> code. Export them in hw/vfio/pci.h, and rename them to the vfio_pci_*
> namespace.
>
> Signed-off-by: John Levon <john.levon@nutanix.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Thanks,
C.
> ---
> hw/vfio/pci.h | 11 ++++++++++
> hw/vfio/pci.c | 48 ++++++++++++++++++++++----------------------
> hw/vfio/trace-events | 6 +++---
> 3 files changed, 38 insertions(+), 27 deletions(-)
>
> diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
> index 5ce0fb916f..d4c6b2e7b7 100644
> --- a/hw/vfio/pci.h
> +++ b/hw/vfio/pci.h
> @@ -248,4 +248,15 @@ void vfio_display_finalize(VFIOPCIDevice *vdev);
>
> extern const VMStateDescription vfio_display_vmstate;
>
> +void vfio_pci_bars_exit(VFIOPCIDevice *vdev);
> +bool vfio_pci_add_capabilities(VFIOPCIDevice *vdev, Error **errp);
> +bool vfio_pci_config_setup(VFIOPCIDevice *vdev, Error **errp);
> +bool vfio_pci_interrupt_setup(VFIOPCIDevice *vdev, Error **errp);
> +void vfio_pci_intx_eoi(VFIODevice *vbasedev);
> +void vfio_pci_put_device(VFIOPCIDevice *vdev);
> +bool vfio_pci_populate_device(VFIOPCIDevice *vdev, Error **errp);
> +void vfio_pci_register_err_notifier(VFIOPCIDevice *vdev);
> +void vfio_pci_register_req_notifier(VFIOPCIDevice *vdev);
> +void vfio_pci_teardown_msi(VFIOPCIDevice *vdev);
> +
> #endif /* HW_VFIO_VFIO_PCI_H */
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index b1250d85bf..a49405660a 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -103,7 +103,7 @@ static void vfio_intx_interrupt(void *opaque)
> }
> }
>
> -static void vfio_intx_eoi(VFIODevice *vbasedev)
> +void vfio_pci_intx_eoi(VFIODevice *vbasedev)
> {
> VFIOPCIDevice *vdev = container_of(vbasedev, VFIOPCIDevice, vbasedev);
>
> @@ -111,7 +111,7 @@ static void vfio_intx_eoi(VFIODevice *vbasedev)
> return;
> }
>
> - trace_vfio_intx_eoi(vbasedev->name);
> + trace_vfio_pci_intx_eoi(vbasedev->name);
>
> vdev->intx.pending = false;
> pci_irq_deassert(&vdev->pdev);
> @@ -236,7 +236,7 @@ static void vfio_intx_update(VFIOPCIDevice *vdev, PCIINTxRoute *route)
> }
>
> /* Re-enable the interrupt in cased we missed an EOI */
> - vfio_intx_eoi(&vdev->vbasedev);
> + vfio_pci_intx_eoi(&vdev->vbasedev);
> }
>
> static void vfio_intx_routing_notifier(PCIDevice *pdev)
> @@ -1743,7 +1743,7 @@ static bool vfio_msix_setup(VFIOPCIDevice *vdev, int pos, Error **errp)
> return true;
> }
>
> -static void vfio_teardown_msi(VFIOPCIDevice *vdev)
> +void vfio_pci_teardown_msi(VFIOPCIDevice *vdev)
> {
> msi_uninit(&vdev->pdev);
>
> @@ -1839,7 +1839,7 @@ static void vfio_bars_register(VFIOPCIDevice *vdev)
> }
> }
>
> -static void vfio_bars_exit(VFIOPCIDevice *vdev)
> +void vfio_pci_bars_exit(VFIOPCIDevice *vdev)
> {
> int i;
>
> @@ -2430,7 +2430,7 @@ static void vfio_add_ext_cap(VFIOPCIDevice *vdev)
> g_free(config);
> }
>
> -static bool vfio_add_capabilities(VFIOPCIDevice *vdev, Error **errp)
> +bool vfio_pci_add_capabilities(VFIOPCIDevice *vdev, Error **errp)
> {
> PCIDevice *pdev = &vdev->pdev;
>
> @@ -2706,7 +2706,7 @@ static int vfio_pci_load_config(VFIODevice *vbasedev, QEMUFile *f)
> static VFIODeviceOps vfio_pci_ops = {
> .vfio_compute_needs_reset = vfio_pci_compute_needs_reset,
> .vfio_hot_reset_multi = vfio_pci_hot_reset_multi,
> - .vfio_eoi = vfio_intx_eoi,
> + .vfio_eoi = vfio_pci_intx_eoi,
> .vfio_get_object = vfio_pci_get_object,
> .vfio_save_config = vfio_pci_save_config,
> .vfio_load_config = vfio_pci_load_config,
> @@ -2777,7 +2777,7 @@ bool vfio_populate_vga(VFIOPCIDevice *vdev, Error **errp)
> return true;
> }
>
> -static bool vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
> +bool vfio_pci_populate_device(VFIOPCIDevice *vdev, Error **errp)
> {
> VFIODevice *vbasedev = &vdev->vbasedev;
> struct vfio_region_info *reg_info = NULL;
> @@ -2823,7 +2823,7 @@ static bool vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
> return false;
> }
>
> - trace_vfio_populate_device_config(vdev->vbasedev.name,
> + trace_vfio_pci_populate_device_config(vdev->vbasedev.name,
> (unsigned long)reg_info->size,
> (unsigned long)reg_info->offset,
> (unsigned long)reg_info->flags);
> @@ -2845,7 +2845,7 @@ static bool vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
> ret = vfio_device_get_irq_info(vbasedev, VFIO_PCI_ERR_IRQ_INDEX, &irq_info);
> if (ret) {
> /* This can fail for an old kernel or legacy PCI dev */
> - trace_vfio_populate_device_get_irq_info_failure(strerror(-ret));
> + trace_vfio_pci_populate_device_get_irq_info_failure(strerror(-ret));
> } else if (irq_info.count == 1) {
> vdev->pci_aer = true;
> } else {
> @@ -2857,7 +2857,7 @@ static bool vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
> return true;
> }
>
> -static void vfio_pci_put_device(VFIOPCIDevice *vdev)
> +void vfio_pci_put_device(VFIOPCIDevice *vdev)
> {
> vfio_display_finalize(vdev);
> vfio_bars_finalize(vdev);
> @@ -2905,7 +2905,7 @@ static void vfio_err_notifier_handler(void *opaque)
> * and continue after disabling error recovery support for the
> * device.
> */
> -static void vfio_register_err_notifier(VFIOPCIDevice *vdev)
> +void vfio_pci_register_err_notifier(VFIOPCIDevice *vdev)
> {
> Error *err = NULL;
> int32_t fd;
> @@ -2964,7 +2964,7 @@ static void vfio_req_notifier_handler(void *opaque)
> }
> }
>
> -static void vfio_register_req_notifier(VFIOPCIDevice *vdev)
> +void vfio_pci_register_req_notifier(VFIOPCIDevice *vdev)
> {
> struct vfio_irq_info irq_info;
> Error *err = NULL;
> @@ -3018,7 +3018,7 @@ static void vfio_unregister_req_notifier(VFIOPCIDevice *vdev)
> vdev->req_enabled = false;
> }
>
> -static bool vfio_pci_config_setup(VFIOPCIDevice *vdev, Error **errp)
> +bool vfio_pci_config_setup(VFIOPCIDevice *vdev, Error **errp)
> {
> PCIDevice *pdev = &vdev->pdev;
> VFIODevice *vbasedev = &vdev->vbasedev;
> @@ -3124,7 +3124,7 @@ static bool vfio_pci_config_setup(VFIOPCIDevice *vdev, Error **errp)
> return true;
> }
>
> -static bool vfio_interrupt_setup(VFIOPCIDevice *vdev, Error **errp)
> +bool vfio_pci_interrupt_setup(VFIOPCIDevice *vdev, Error **errp)
> {
> PCIDevice *pdev = &vdev->pdev;
>
> @@ -3214,7 +3214,7 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
> goto error;
> }
>
> - if (!vfio_populate_device(vdev, errp)) {
> + if (!vfio_pci_populate_device(vdev, errp)) {
> goto error;
> }
>
> @@ -3228,7 +3228,7 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
> goto out_teardown;
> }
>
> - if (!vfio_add_capabilities(vdev, errp)) {
> + if (!vfio_pci_add_capabilities(vdev, errp)) {
> goto out_unset_idev;
> }
>
> @@ -3244,7 +3244,7 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
> vfio_bar_quirk_setup(vdev, i);
> }
>
> - if (!vfio_interrupt_setup(vdev, errp)) {
> + if (!vfio_pci_interrupt_setup(vdev, errp)) {
> goto out_unset_idev;
> }
>
> @@ -3288,8 +3288,8 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
> }
> }
>
> - vfio_register_err_notifier(vdev);
> - vfio_register_req_notifier(vdev);
> + vfio_pci_register_err_notifier(vdev);
> + vfio_pci_register_req_notifier(vdev);
> vfio_setup_resetfn_quirk(vdev);
>
> return;
> @@ -3310,8 +3310,8 @@ out_unset_idev:
> pci_device_unset_iommu_device(pdev);
> }
> out_teardown:
> - vfio_teardown_msi(vdev);
> - vfio_bars_exit(vdev);
> + vfio_pci_teardown_msi(vdev);
> + vfio_pci_bars_exit(vdev);
> error:
> error_prepend(errp, VFIO_MSG_PREFIX, vbasedev->name);
> }
> @@ -3338,9 +3338,9 @@ static void vfio_exitfn(PCIDevice *pdev)
> if (vdev->intx.mmap_timer) {
> timer_free(vdev->intx.mmap_timer);
> }
> - vfio_teardown_msi(vdev);
> + vfio_pci_teardown_msi(vdev);
> vfio_pci_disable_rp_atomics(vdev);
> - vfio_bars_exit(vdev);
> + vfio_pci_bars_exit(vdev);
> vfio_migration_exit(vbasedev);
> if (!vbasedev->mdev) {
> pci_device_unset_iommu_device(pdev);
> diff --git a/hw/vfio/trace-events b/hw/vfio/trace-events
> index e90ec9bff8..f06236f37b 100644
> --- a/hw/vfio/trace-events
> +++ b/hw/vfio/trace-events
> @@ -2,7 +2,7 @@
>
> # pci.c
> vfio_intx_interrupt(const char *name, char line) " (%s) Pin %c"
> -vfio_intx_eoi(const char *name) " (%s) EOI"
> +vfio_pci_intx_eoi(const char *name) " (%s) EOI"
> vfio_intx_enable_kvm(const char *name) " (%s) KVM INTx accel enabled"
> vfio_intx_disable_kvm(const char *name) " (%s) KVM INTx accel disabled"
> vfio_intx_update(const char *name, int new_irq, int target_irq) " (%s) IRQ moved %d -> %d"
> @@ -35,8 +35,8 @@ vfio_pci_hot_reset(const char *name, const char *type) " (%s) %s"
> vfio_pci_hot_reset_has_dep_devices(const char *name) "%s: hot reset dependent devices:"
> vfio_pci_hot_reset_dep_devices(int domain, int bus, int slot, int function, int group_id) "\t%04x:%02x:%02x.%x group %d"
> vfio_pci_hot_reset_result(const char *name, const char *result) "%s hot reset: %s"
> -vfio_populate_device_config(const char *name, unsigned long size, unsigned long offset, unsigned long flags) "Device '%s' config: size: 0x%lx, offset: 0x%lx, flags: 0x%lx"
> -vfio_populate_device_get_irq_info_failure(const char *errstr) "VFIO_DEVICE_GET_IRQ_INFO failure: %s"
> +vfio_pci_populate_device_config(const char *name, unsigned long size, unsigned long offset, unsigned long flags) "Device '%s' config: size: 0x%lx, offset: 0x%lx, flags: 0x%lx"
> +vfio_pci_populate_device_get_irq_info_failure(const char *errstr) "VFIO_DEVICE_GET_IRQ_INFO failure: %s"
> vfio_mdev(const char *name, bool is_mdev) " (%s) is_mdev %d"
> vfio_add_ext_cap_dropped(const char *name, uint16_t cap, uint16_t offset) "%s 0x%x@0x%x"
> vfio_pci_reset(const char *name) " (%s)"
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 01/23] vfio: export PCI helpers needed for vfio-user
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
2 siblings, 0 replies; 69+ messages in thread
From: Mark Cave-Ayland @ 2025-06-10 10:47 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé
On 07/06/2025 01:10, John Levon wrote:
> The vfio-user code will need to re-use various parts of the vfio PCI
> code. Export them in hw/vfio/pci.h, and rename them to the vfio_pci_*
> namespace.
>
> Signed-off-by: John Levon <john.levon@nutanix.com>
> ---
> hw/vfio/pci.h | 11 ++++++++++
> hw/vfio/pci.c | 48 ++++++++++++++++++++++----------------------
> hw/vfio/trace-events | 6 +++---
> 3 files changed, 38 insertions(+), 27 deletions(-)
>
> diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
> index 5ce0fb916f..d4c6b2e7b7 100644
> --- a/hw/vfio/pci.h
> +++ b/hw/vfio/pci.h
> @@ -248,4 +248,15 @@ void vfio_display_finalize(VFIOPCIDevice *vdev);
>
> extern const VMStateDescription vfio_display_vmstate;
>
> +void vfio_pci_bars_exit(VFIOPCIDevice *vdev);
> +bool vfio_pci_add_capabilities(VFIOPCIDevice *vdev, Error **errp);
> +bool vfio_pci_config_setup(VFIOPCIDevice *vdev, Error **errp);
> +bool vfio_pci_interrupt_setup(VFIOPCIDevice *vdev, Error **errp);
> +void vfio_pci_intx_eoi(VFIODevice *vbasedev);
> +void vfio_pci_put_device(VFIOPCIDevice *vdev);
> +bool vfio_pci_populate_device(VFIOPCIDevice *vdev, Error **errp);
> +void vfio_pci_register_err_notifier(VFIOPCIDevice *vdev);
> +void vfio_pci_register_req_notifier(VFIOPCIDevice *vdev);
> +void vfio_pci_teardown_msi(VFIOPCIDevice *vdev);
> +
> #endif /* HW_VFIO_VFIO_PCI_H */
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index b1250d85bf..a49405660a 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -103,7 +103,7 @@ static void vfio_intx_interrupt(void *opaque)
> }
> }
>
> -static void vfio_intx_eoi(VFIODevice *vbasedev)
> +void vfio_pci_intx_eoi(VFIODevice *vbasedev)
> {
> VFIOPCIDevice *vdev = container_of(vbasedev, VFIOPCIDevice, vbasedev);
>
> @@ -111,7 +111,7 @@ static void vfio_intx_eoi(VFIODevice *vbasedev)
> return;
> }
>
> - trace_vfio_intx_eoi(vbasedev->name);
> + trace_vfio_pci_intx_eoi(vbasedev->name);
>
> vdev->intx.pending = false;
> pci_irq_deassert(&vdev->pdev);
> @@ -236,7 +236,7 @@ static void vfio_intx_update(VFIOPCIDevice *vdev, PCIINTxRoute *route)
> }
>
> /* Re-enable the interrupt in cased we missed an EOI */
> - vfio_intx_eoi(&vdev->vbasedev);
> + vfio_pci_intx_eoi(&vdev->vbasedev);
> }
>
> static void vfio_intx_routing_notifier(PCIDevice *pdev)
> @@ -1743,7 +1743,7 @@ static bool vfio_msix_setup(VFIOPCIDevice *vdev, int pos, Error **errp)
> return true;
> }
>
> -static void vfio_teardown_msi(VFIOPCIDevice *vdev)
> +void vfio_pci_teardown_msi(VFIOPCIDevice *vdev)
> {
> msi_uninit(&vdev->pdev);
>
> @@ -1839,7 +1839,7 @@ static void vfio_bars_register(VFIOPCIDevice *vdev)
> }
> }
>
> -static void vfio_bars_exit(VFIOPCIDevice *vdev)
> +void vfio_pci_bars_exit(VFIOPCIDevice *vdev)
> {
> int i;
>
> @@ -2430,7 +2430,7 @@ static void vfio_add_ext_cap(VFIOPCIDevice *vdev)
> g_free(config);
> }
>
> -static bool vfio_add_capabilities(VFIOPCIDevice *vdev, Error **errp)
> +bool vfio_pci_add_capabilities(VFIOPCIDevice *vdev, Error **errp)
> {
> PCIDevice *pdev = &vdev->pdev;
>
> @@ -2706,7 +2706,7 @@ static int vfio_pci_load_config(VFIODevice *vbasedev, QEMUFile *f)
> static VFIODeviceOps vfio_pci_ops = {
> .vfio_compute_needs_reset = vfio_pci_compute_needs_reset,
> .vfio_hot_reset_multi = vfio_pci_hot_reset_multi,
> - .vfio_eoi = vfio_intx_eoi,
> + .vfio_eoi = vfio_pci_intx_eoi,
> .vfio_get_object = vfio_pci_get_object,
> .vfio_save_config = vfio_pci_save_config,
> .vfio_load_config = vfio_pci_load_config,
> @@ -2777,7 +2777,7 @@ bool vfio_populate_vga(VFIOPCIDevice *vdev, Error **errp)
> return true;
> }
>
> -static bool vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
> +bool vfio_pci_populate_device(VFIOPCIDevice *vdev, Error **errp)
> {
> VFIODevice *vbasedev = &vdev->vbasedev;
> struct vfio_region_info *reg_info = NULL;
> @@ -2823,7 +2823,7 @@ static bool vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
> return false;
> }
>
> - trace_vfio_populate_device_config(vdev->vbasedev.name,
> + trace_vfio_pci_populate_device_config(vdev->vbasedev.name,
> (unsigned long)reg_info->size,
> (unsigned long)reg_info->offset,
> (unsigned long)reg_info->flags);
> @@ -2845,7 +2845,7 @@ static bool vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
> ret = vfio_device_get_irq_info(vbasedev, VFIO_PCI_ERR_IRQ_INDEX, &irq_info);
> if (ret) {
> /* This can fail for an old kernel or legacy PCI dev */
> - trace_vfio_populate_device_get_irq_info_failure(strerror(-ret));
> + trace_vfio_pci_populate_device_get_irq_info_failure(strerror(-ret));
> } else if (irq_info.count == 1) {
> vdev->pci_aer = true;
> } else {
> @@ -2857,7 +2857,7 @@ static bool vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
> return true;
> }
>
> -static void vfio_pci_put_device(VFIOPCIDevice *vdev)
> +void vfio_pci_put_device(VFIOPCIDevice *vdev)
> {
> vfio_display_finalize(vdev);
> vfio_bars_finalize(vdev);
> @@ -2905,7 +2905,7 @@ static void vfio_err_notifier_handler(void *opaque)
> * and continue after disabling error recovery support for the
> * device.
> */
> -static void vfio_register_err_notifier(VFIOPCIDevice *vdev)
> +void vfio_pci_register_err_notifier(VFIOPCIDevice *vdev)
> {
> Error *err = NULL;
> int32_t fd;
> @@ -2964,7 +2964,7 @@ static void vfio_req_notifier_handler(void *opaque)
> }
> }
>
> -static void vfio_register_req_notifier(VFIOPCIDevice *vdev)
> +void vfio_pci_register_req_notifier(VFIOPCIDevice *vdev)
> {
> struct vfio_irq_info irq_info;
> Error *err = NULL;
> @@ -3018,7 +3018,7 @@ static void vfio_unregister_req_notifier(VFIOPCIDevice *vdev)
> vdev->req_enabled = false;
> }
>
> -static bool vfio_pci_config_setup(VFIOPCIDevice *vdev, Error **errp)
> +bool vfio_pci_config_setup(VFIOPCIDevice *vdev, Error **errp)
> {
> PCIDevice *pdev = &vdev->pdev;
> VFIODevice *vbasedev = &vdev->vbasedev;
> @@ -3124,7 +3124,7 @@ static bool vfio_pci_config_setup(VFIOPCIDevice *vdev, Error **errp)
> return true;
> }
>
> -static bool vfio_interrupt_setup(VFIOPCIDevice *vdev, Error **errp)
> +bool vfio_pci_interrupt_setup(VFIOPCIDevice *vdev, Error **errp)
> {
> PCIDevice *pdev = &vdev->pdev;
>
> @@ -3214,7 +3214,7 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
> goto error;
> }
>
> - if (!vfio_populate_device(vdev, errp)) {
> + if (!vfio_pci_populate_device(vdev, errp)) {
> goto error;
> }
>
> @@ -3228,7 +3228,7 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
> goto out_teardown;
> }
>
> - if (!vfio_add_capabilities(vdev, errp)) {
> + if (!vfio_pci_add_capabilities(vdev, errp)) {
> goto out_unset_idev;
> }
>
> @@ -3244,7 +3244,7 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
> vfio_bar_quirk_setup(vdev, i);
> }
>
> - if (!vfio_interrupt_setup(vdev, errp)) {
> + if (!vfio_pci_interrupt_setup(vdev, errp)) {
> goto out_unset_idev;
> }
>
> @@ -3288,8 +3288,8 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
> }
> }
>
> - vfio_register_err_notifier(vdev);
> - vfio_register_req_notifier(vdev);
> + vfio_pci_register_err_notifier(vdev);
> + vfio_pci_register_req_notifier(vdev);
> vfio_setup_resetfn_quirk(vdev);
>
> return;
> @@ -3310,8 +3310,8 @@ out_unset_idev:
> pci_device_unset_iommu_device(pdev);
> }
> out_teardown:
> - vfio_teardown_msi(vdev);
> - vfio_bars_exit(vdev);
> + vfio_pci_teardown_msi(vdev);
> + vfio_pci_bars_exit(vdev);
> error:
> error_prepend(errp, VFIO_MSG_PREFIX, vbasedev->name);
> }
> @@ -3338,9 +3338,9 @@ static void vfio_exitfn(PCIDevice *pdev)
> if (vdev->intx.mmap_timer) {
> timer_free(vdev->intx.mmap_timer);
> }
> - vfio_teardown_msi(vdev);
> + vfio_pci_teardown_msi(vdev);
> vfio_pci_disable_rp_atomics(vdev);
> - vfio_bars_exit(vdev);
> + vfio_pci_bars_exit(vdev);
> vfio_migration_exit(vbasedev);
> if (!vbasedev->mdev) {
> pci_device_unset_iommu_device(pdev);
> diff --git a/hw/vfio/trace-events b/hw/vfio/trace-events
> index e90ec9bff8..f06236f37b 100644
> --- a/hw/vfio/trace-events
> +++ b/hw/vfio/trace-events
> @@ -2,7 +2,7 @@
>
> # pci.c
> vfio_intx_interrupt(const char *name, char line) " (%s) Pin %c"
> -vfio_intx_eoi(const char *name) " (%s) EOI"
> +vfio_pci_intx_eoi(const char *name) " (%s) EOI"
> vfio_intx_enable_kvm(const char *name) " (%s) KVM INTx accel enabled"
> vfio_intx_disable_kvm(const char *name) " (%s) KVM INTx accel disabled"
> vfio_intx_update(const char *name, int new_irq, int target_irq) " (%s) IRQ moved %d -> %d"
> @@ -35,8 +35,8 @@ vfio_pci_hot_reset(const char *name, const char *type) " (%s) %s"
> vfio_pci_hot_reset_has_dep_devices(const char *name) "%s: hot reset dependent devices:"
> vfio_pci_hot_reset_dep_devices(int domain, int bus, int slot, int function, int group_id) "\t%04x:%02x:%02x.%x group %d"
> vfio_pci_hot_reset_result(const char *name, const char *result) "%s hot reset: %s"
> -vfio_populate_device_config(const char *name, unsigned long size, unsigned long offset, unsigned long flags) "Device '%s' config: size: 0x%lx, offset: 0x%lx, flags: 0x%lx"
> -vfio_populate_device_get_irq_info_failure(const char *errstr) "VFIO_DEVICE_GET_IRQ_INFO failure: %s"
> +vfio_pci_populate_device_config(const char *name, unsigned long size, unsigned long offset, unsigned long flags) "Device '%s' config: size: 0x%lx, offset: 0x%lx, flags: 0x%lx"
> +vfio_pci_populate_device_get_irq_info_failure(const char *errstr) "VFIO_DEVICE_GET_IRQ_INFO failure: %s"
> vfio_mdev(const char *name, bool is_mdev) " (%s) is_mdev %d"
> vfio_add_ext_cap_dropped(const char *name, uint16_t cap, uint16_t offset) "%s 0x%x@0x%x"
> vfio_pci_reset(const char *name) " (%s)"
Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
ATB,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 01/23] vfio: export PCI helpers needed for vfio-user
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
2 siblings, 0 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-10 17:38 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 6/7/25 02:10, John Levon wrote:
> The vfio-user code will need to re-use various parts of the vfio PCI
> code. Export them in hw/vfio/pci.h, and rename them to the vfio_pci_*
> namespace.
>
> Signed-off-by: John Levon <john.levon@nutanix.com>
> ---
> hw/vfio/pci.h | 11 ++++++++++
> hw/vfio/pci.c | 48 ++++++++++++++++++++++----------------------
> hw/vfio/trace-events | 6 +++---
> 3 files changed, 38 insertions(+), 27 deletions(-)
Applied to vfio-next.
Thanks,
C.
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH v3 02/23] vfio: enable per-IRQ MSI-X masking
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-07 0:10 ` John Levon
2025-06-10 7:27 ` Cédric Le Goater
2025-06-10 21:52 ` John Levon
2025-06-07 0:10 ` [PATCH v3 03/23] vfio: add per-region fd support John Levon
` (21 subsequent siblings)
23 siblings, 2 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
If VFIO_IRQ_INFO_MASKABLE is set for VFIO_PCI_MSIX_IRQ_INDEX, record
this in ->can_mask_msix, and use it to individually mask MSI-X
interrupts as needed.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio/pci.h | 1 +
include/hw/vfio/vfio-device.h | 2 ++
hw/vfio/device.c | 26 ++++++++++++++++++++
hw/vfio/pci.c | 46 ++++++++++++++++++++++++++++++-----
4 files changed, 69 insertions(+), 6 deletions(-)
diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
index d4c6b2e7b7..e3a7d7bdca 100644
--- a/hw/vfio/pci.h
+++ b/hw/vfio/pci.h
@@ -191,6 +191,7 @@ struct VFIOPCIDevice {
bool defer_kvm_irq_routing;
bool clear_parent_atomics_on_exit;
bool skip_vsc_check;
+ bool can_mask_msix;
VFIODisplay *dpy;
Notifier irqchip_change_notifier;
};
diff --git a/include/hw/vfio/vfio-device.h b/include/hw/vfio/vfio-device.h
index 8bcb3c19f6..923f9cd116 100644
--- a/include/hw/vfio/vfio-device.h
+++ b/include/hw/vfio/vfio-device.h
@@ -133,7 +133,9 @@ struct VFIODeviceOps {
(ret < 0 ? strerror(-ret) : "short write")
void vfio_device_irq_disable(VFIODevice *vbasedev, int index);
+void vfio_device_irq_unmask_single(VFIODevice *vbasedev, int index, int irq);
void vfio_device_irq_unmask(VFIODevice *vbasedev, int index);
+void vfio_device_irq_mask_single(VFIODevice *vbasedev, int index, int irq);
void vfio_device_irq_mask(VFIODevice *vbasedev, int index);
bool vfio_device_irq_set_signaling(VFIODevice *vbasedev, int index, int subindex,
int action, int fd, Error **errp);
diff --git a/hw/vfio/device.c b/hw/vfio/device.c
index 9fba2c7272..d0068086ae 100644
--- a/hw/vfio/device.c
+++ b/hw/vfio/device.c
@@ -85,6 +85,19 @@ void vfio_device_irq_disable(VFIODevice *vbasedev, int index)
vbasedev->io_ops->set_irqs(vbasedev, &irq_set);
}
+void vfio_device_irq_unmask_single(VFIODevice *vbasedev, int index, int irq)
+{
+ struct vfio_irq_set irq_set = {
+ .argsz = sizeof(irq_set),
+ .flags = VFIO_IRQ_SET_DATA_NONE | VFIO_IRQ_SET_ACTION_UNMASK,
+ .index = index,
+ .start = irq,
+ .count = 1,
+ };
+
+ vbasedev->io_ops->set_irqs(vbasedev, &irq_set);
+}
+
void vfio_device_irq_unmask(VFIODevice *vbasedev, int index)
{
struct vfio_irq_set irq_set = {
@@ -98,6 +111,19 @@ void vfio_device_irq_unmask(VFIODevice *vbasedev, int index)
vbasedev->io_ops->set_irqs(vbasedev, &irq_set);
}
+void vfio_device_irq_mask_single(VFIODevice *vbasedev, int index, int irq)
+{
+ struct vfio_irq_set irq_set = {
+ .argsz = sizeof(irq_set),
+ .flags = VFIO_IRQ_SET_DATA_NONE | VFIO_IRQ_SET_ACTION_MASK,
+ .index = index,
+ .start = irq,
+ .count = 1,
+ };
+
+ vbasedev->io_ops->set_irqs(vbasedev, &irq_set);
+}
+
void vfio_device_irq_mask(VFIODevice *vbasedev, int index)
{
struct vfio_irq_set irq_set = {
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index a49405660a..714d37e227 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -535,6 +535,7 @@ static int vfio_msix_vector_do_use(PCIDevice *pdev, unsigned int nr,
{
VFIOPCIDevice *vdev = VFIO_PCI_BASE(pdev);
VFIOMSIVector *vector;
+ bool new_vec = false;
int ret;
bool resizing = !!(vdev->nr_vectors < nr + 1);
@@ -575,6 +576,7 @@ static int vfio_msix_vector_do_use(PCIDevice *pdev, unsigned int nr,
kvm_irqchip_commit_route_changes(&vfio_route_change);
vfio_connect_kvm_msi_virq(vector);
}
+ new_vec = true;
}
}
@@ -584,6 +586,9 @@ static int vfio_msix_vector_do_use(PCIDevice *pdev, unsigned int nr,
* in use, so we shutdown and incrementally increase them as needed.
* nr_vectors represents the total number of vectors allocated.
*
+ * Otherwise, unmask the vector if the vector is already setup (and we can
+ * do so) or send the fd if not.
+ *
* When dynamic allocation is supported, let the host only allocate
* and enable a vector when it is in use in guest. nr_vectors represents
* the upper bound of vectors being enabled (but not all of the ranges
@@ -594,13 +599,20 @@ static int vfio_msix_vector_do_use(PCIDevice *pdev, unsigned int nr,
}
if (!vdev->defer_kvm_irq_routing) {
- if (vdev->msix->noresize && resizing) {
- vfio_device_irq_disable(&vdev->vbasedev, VFIO_PCI_MSIX_IRQ_INDEX);
- ret = vfio_enable_vectors(vdev, true);
- if (ret) {
- error_report("vfio: failed to enable vectors, %s",
- strerror(-ret));
+ if (resizing) {
+ if (vdev->msix->noresize) {
+ vfio_device_irq_disable(&vdev->vbasedev,
+ VFIO_PCI_MSIX_IRQ_INDEX);
+ ret = vfio_enable_vectors(vdev, true);
+ if (ret) {
+ error_report("vfio: failed to enable vectors, %d", ret);
+ }
+ } else {
+ set_irq_signalling(&vdev->vbasedev, vector, nr);
}
+ } else if (vdev->can_mask_msix && !new_vec) {
+ vfio_device_irq_unmask_single(&vdev->vbasedev,
+ VFIO_PCI_MSIX_IRQ_INDEX, nr);
} else {
set_irq_signalling(&vdev->vbasedev, vector, nr);
}
@@ -630,6 +642,13 @@ static void vfio_msix_vector_release(PCIDevice *pdev, unsigned int nr)
trace_vfio_msix_vector_release(vdev->vbasedev.name, nr);
+ /* just mask vector if peer supports it */
+ if (vdev->can_mask_msix) {
+ vfio_device_irq_mask_single(&vdev->vbasedev, VFIO_PCI_MSIX_IRQ_INDEX,
+ nr);
+ return;
+ }
+
/*
* There are still old guests that mask and unmask vectors on every
* interrupt. If we're using QEMU bypass with a KVM irqfd, leave all of
@@ -702,6 +721,13 @@ static void vfio_msix_enable(VFIOPCIDevice *vdev)
error_report("vfio: failed to enable vectors, %s",
strerror(-ret));
}
+ } else if (vdev->can_mask_msix) {
+ /*
+ * If we can use single irq masking, send an invalid fd on vector 0
+ * to enable MSI-X without any vectors enabled.
+ */
+ vfio_device_irq_set_signaling(&vdev->vbasedev, VFIO_PCI_MSIX_IRQ_INDEX,
+ 0, VFIO_IRQ_SET_ACTION_TRIGGER, -1, NULL);
} else {
/*
* Some communication channels between VF & PF or PF & fw rely on the
@@ -2842,6 +2868,14 @@ bool vfio_pci_populate_device(VFIOPCIDevice *vdev, Error **errp)
}
}
+ ret = vfio_device_get_irq_info(vbasedev, VFIO_PCI_MSIX_IRQ_INDEX,
+ &irq_info);
+ if (ret == 0 && (irq_info.flags & VFIO_IRQ_INFO_MASKABLE)) {
+ vdev->can_mask_msix = true;
+ } else {
+ vdev->can_mask_msix = false;
+ }
+
ret = vfio_device_get_irq_info(vbasedev, VFIO_PCI_ERR_IRQ_INDEX, &irq_info);
if (ret) {
/* This can fail for an old kernel or legacy PCI dev */
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH v3 02/23] vfio: enable per-IRQ MSI-X masking
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
1 sibling, 0 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-10 7:27 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, John Johnson, Elena Ufimtseva,
Jagannathan Raman
On 6/7/25 02:10, John Levon wrote:
> If VFIO_IRQ_INFO_MASKABLE is set for VFIO_PCI_MSIX_IRQ_INDEX, record
> this in ->can_mask_msix, and use it to individually mask MSI-X
> interrupts as needed.
>
> Originally-by: John Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: John Levon <john.levon@nutanix.com>
> ---
> hw/vfio/pci.h | 1 +
> include/hw/vfio/vfio-device.h | 2 ++
> hw/vfio/device.c | 26 ++++++++++++++++++++
> hw/vfio/pci.c | 46 ++++++++++++++++++++++++++++++-----
> 4 files changed, 69 insertions(+), 6 deletions(-)
I find these changes difficult to understand. Can you split them
a bit more ?
Thanks,
C.
>
> diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
> index d4c6b2e7b7..e3a7d7bdca 100644
> --- a/hw/vfio/pci.h
> +++ b/hw/vfio/pci.h
> @@ -191,6 +191,7 @@ struct VFIOPCIDevice {
> bool defer_kvm_irq_routing;
> bool clear_parent_atomics_on_exit;
> bool skip_vsc_check;
> + bool can_mask_msix;
> VFIODisplay *dpy;
> Notifier irqchip_change_notifier;
> };
> diff --git a/include/hw/vfio/vfio-device.h b/include/hw/vfio/vfio-device.h
> index 8bcb3c19f6..923f9cd116 100644
> --- a/include/hw/vfio/vfio-device.h
> +++ b/include/hw/vfio/vfio-device.h
> @@ -133,7 +133,9 @@ struct VFIODeviceOps {
> (ret < 0 ? strerror(-ret) : "short write")
>
> void vfio_device_irq_disable(VFIODevice *vbasedev, int index);
> +void vfio_device_irq_unmask_single(VFIODevice *vbasedev, int index, int irq);
> void vfio_device_irq_unmask(VFIODevice *vbasedev, int index);
> +void vfio_device_irq_mask_single(VFIODevice *vbasedev, int index, int irq);
> void vfio_device_irq_mask(VFIODevice *vbasedev, int index);
> bool vfio_device_irq_set_signaling(VFIODevice *vbasedev, int index, int subindex,
> int action, int fd, Error **errp);
> diff --git a/hw/vfio/device.c b/hw/vfio/device.c
> index 9fba2c7272..d0068086ae 100644
> --- a/hw/vfio/device.c
> +++ b/hw/vfio/device.c
> @@ -85,6 +85,19 @@ void vfio_device_irq_disable(VFIODevice *vbasedev, int index)
> vbasedev->io_ops->set_irqs(vbasedev, &irq_set);
> }
>
> +void vfio_device_irq_unmask_single(VFIODevice *vbasedev, int index, int irq)
> +{
> + struct vfio_irq_set irq_set = {
> + .argsz = sizeof(irq_set),
> + .flags = VFIO_IRQ_SET_DATA_NONE | VFIO_IRQ_SET_ACTION_UNMASK,
> + .index = index,
> + .start = irq,
> + .count = 1,
> + };
> +
> + vbasedev->io_ops->set_irqs(vbasedev, &irq_set);
> +}
> +
> void vfio_device_irq_unmask(VFIODevice *vbasedev, int index)
> {
> struct vfio_irq_set irq_set = {
> @@ -98,6 +111,19 @@ void vfio_device_irq_unmask(VFIODevice *vbasedev, int index)
> vbasedev->io_ops->set_irqs(vbasedev, &irq_set);
> }
>
> +void vfio_device_irq_mask_single(VFIODevice *vbasedev, int index, int irq)
> +{
> + struct vfio_irq_set irq_set = {
> + .argsz = sizeof(irq_set),
> + .flags = VFIO_IRQ_SET_DATA_NONE | VFIO_IRQ_SET_ACTION_MASK,
> + .index = index,
> + .start = irq,
> + .count = 1,
> + };
> +
> + vbasedev->io_ops->set_irqs(vbasedev, &irq_set);
> +}
> +
> void vfio_device_irq_mask(VFIODevice *vbasedev, int index)
> {
> struct vfio_irq_set irq_set = {
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index a49405660a..714d37e227 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -535,6 +535,7 @@ static int vfio_msix_vector_do_use(PCIDevice *pdev, unsigned int nr,
> {
> VFIOPCIDevice *vdev = VFIO_PCI_BASE(pdev);
> VFIOMSIVector *vector;
> + bool new_vec = false;
> int ret;
> bool resizing = !!(vdev->nr_vectors < nr + 1);
>
> @@ -575,6 +576,7 @@ static int vfio_msix_vector_do_use(PCIDevice *pdev, unsigned int nr,
> kvm_irqchip_commit_route_changes(&vfio_route_change);
> vfio_connect_kvm_msi_virq(vector);
> }
> + new_vec = true;
> }
> }
>
> @@ -584,6 +586,9 @@ static int vfio_msix_vector_do_use(PCIDevice *pdev, unsigned int nr,
> * in use, so we shutdown and incrementally increase them as needed.
> * nr_vectors represents the total number of vectors allocated.
> *
> + * Otherwise, unmask the vector if the vector is already setup (and we can
> + * do so) or send the fd if not.
> + *
> * When dynamic allocation is supported, let the host only allocate
> * and enable a vector when it is in use in guest. nr_vectors represents
> * the upper bound of vectors being enabled (but not all of the ranges
> @@ -594,13 +599,20 @@ static int vfio_msix_vector_do_use(PCIDevice *pdev, unsigned int nr,
> }
>
> if (!vdev->defer_kvm_irq_routing) {
> - if (vdev->msix->noresize && resizing) {
> - vfio_device_irq_disable(&vdev->vbasedev, VFIO_PCI_MSIX_IRQ_INDEX);
> - ret = vfio_enable_vectors(vdev, true);
> - if (ret) {
> - error_report("vfio: failed to enable vectors, %s",
> - strerror(-ret));
> + if (resizing) {
> + if (vdev->msix->noresize) {
> + vfio_device_irq_disable(&vdev->vbasedev,
> + VFIO_PCI_MSIX_IRQ_INDEX);
> + ret = vfio_enable_vectors(vdev, true);
> + if (ret) {
> + error_report("vfio: failed to enable vectors, %d", ret);
> + }
> + } else {
> + set_irq_signalling(&vdev->vbasedev, vector, nr);
> }
> + } else if (vdev->can_mask_msix && !new_vec) {
> + vfio_device_irq_unmask_single(&vdev->vbasedev,
> + VFIO_PCI_MSIX_IRQ_INDEX, nr);
> } else {
> set_irq_signalling(&vdev->vbasedev, vector, nr);
> }
> @@ -630,6 +642,13 @@ static void vfio_msix_vector_release(PCIDevice *pdev, unsigned int nr)
>
> trace_vfio_msix_vector_release(vdev->vbasedev.name, nr);
>
> + /* just mask vector if peer supports it */
> + if (vdev->can_mask_msix) {
> + vfio_device_irq_mask_single(&vdev->vbasedev, VFIO_PCI_MSIX_IRQ_INDEX,
> + nr);
> + return;
> + }
> +
> /*
> * There are still old guests that mask and unmask vectors on every
> * interrupt. If we're using QEMU bypass with a KVM irqfd, leave all of
> @@ -702,6 +721,13 @@ static void vfio_msix_enable(VFIOPCIDevice *vdev)
> error_report("vfio: failed to enable vectors, %s",
> strerror(-ret));
> }
> + } else if (vdev->can_mask_msix) {
> + /*
> + * If we can use single irq masking, send an invalid fd on vector 0
> + * to enable MSI-X without any vectors enabled.
> + */
> + vfio_device_irq_set_signaling(&vdev->vbasedev, VFIO_PCI_MSIX_IRQ_INDEX,
> + 0, VFIO_IRQ_SET_ACTION_TRIGGER, -1, NULL);
> } else {
> /*
> * Some communication channels between VF & PF or PF & fw rely on the
> @@ -2842,6 +2868,14 @@ bool vfio_pci_populate_device(VFIOPCIDevice *vdev, Error **errp)
> }
> }
>
> + ret = vfio_device_get_irq_info(vbasedev, VFIO_PCI_MSIX_IRQ_INDEX,
> + &irq_info);
> + if (ret == 0 && (irq_info.flags & VFIO_IRQ_INFO_MASKABLE)) {
> + vdev->can_mask_msix = true;
> + } else {
> + vdev->can_mask_msix = false;
> + }
> +
> ret = vfio_device_get_irq_info(vbasedev, VFIO_PCI_ERR_IRQ_INDEX, &irq_info);
> if (ret) {
> /* This can fail for an old kernel or legacy PCI dev */
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 02/23] vfio: enable per-IRQ MSI-X masking
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
1 sibling, 1 reply; 69+ messages in thread
From: John Levon @ 2025-06-10 21:52 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Johnson, Elena Ufimtseva,
Jagannathan Raman
On Fri, Jun 06, 2025 at 05:10:34PM -0700, John Levon wrote:
> If VFIO_IRQ_INFO_MASKABLE is set for VFIO_PCI_MSIX_IRQ_INDEX, record
> this in ->can_mask_msix, and use it to individually mask MSI-X
> interrupts as needed.
I'm just going to drop this patch. Neither vfio nor libvfio-user (including
qemu-as-server) report MASKABLE for MSI-X anyway, so it doesn't seem relevant.
I'm not sure if Oracle had some other use case in mind or had previously tested
it somehow.
Furthermore, this:
> @@ -702,6 +721,13 @@ static void vfio_msix_enable(VFIOPCIDevice *vdev)
> error_report("vfio: failed to enable vectors, %s",
> strerror(-ret));
> }
> + } else if (vdev->can_mask_msix) {
> + /*
> + * If we can use single irq masking, send an invalid fd on vector 0
> + * to enable MSI-X without any vectors enabled.
> + */
> + vfio_device_irq_set_signaling(&vdev->vbasedev, VFIO_PCI_MSIX_IRQ_INDEX,
> + 0, VFIO_IRQ_SET_ACTION_TRIGGER, -1, NULL);
> } else {
> /*
> * Some communication channels between VF & PF or PF & fw rely on the
Seems odd as it doesn't pass DATA_EVENTFD, unlike the vfio_enable_msix_no_vec()
below it; I have no idea why the difference or if it makes sense, but it doesn't
seem so.
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 02/23] vfio: enable per-IRQ MSI-X masking
2025-06-10 21:52 ` John Levon
@ 2025-06-11 7:13 ` Cédric Le Goater
0 siblings, 0 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-11 7:13 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, John Johnson, Elena Ufimtseva,
Jagannathan Raman
On 6/10/25 23:52, John Levon wrote:
> On Fri, Jun 06, 2025 at 05:10:34PM -0700, John Levon wrote:
>
>> If VFIO_IRQ_INFO_MASKABLE is set for VFIO_PCI_MSIX_IRQ_INDEX, record
>> this in ->can_mask_msix, and use it to individually mask MSI-X
>> interrupts as needed.
>
> I'm just going to drop this patch. Neither vfio nor libvfio-user (including
> qemu-as-server) report MASKABLE for MSI-X anyway, so it doesn't seem relevant.
ok. Dropped.
Thanks,
C.
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH v3 03/23] vfio: add per-region fd support
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-07 0:10 ` [PATCH v3 02/23] vfio: enable per-IRQ MSI-X masking John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-10 7:42 ` Cédric Le Goater
` (2 more replies)
2025-06-07 0:10 ` [PATCH v3 04/23] vfio: mark posted writes in region write callbacks John Levon
` (20 subsequent siblings)
23 siblings, 3 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon
For vfio-user, each region has its own fd rather than sharing
vbasedev's. Add the necessary plumbing to support this, and use the
correct fd in vfio_region_mmap().
Signed-off-by: John Levon <john.levon@nutanix.com>
---
include/hw/vfio/vfio-device.h | 7 +++++--
hw/vfio/device.c | 29 +++++++++++++++++++++++++----
hw/vfio/region.c | 9 +++++++--
3 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/include/hw/vfio/vfio-device.h b/include/hw/vfio/vfio-device.h
index 923f9cd116..5cb817fd6a 100644
--- a/include/hw/vfio/vfio-device.h
+++ b/include/hw/vfio/vfio-device.h
@@ -66,6 +66,7 @@ typedef struct VFIODevice {
OnOffAuto enable_migration;
OnOffAuto migration_multifd_transfer;
bool migration_events;
+ bool use_region_fds;
VFIODeviceOps *ops;
VFIODeviceIOOps *io_ops;
unsigned int num_irqs;
@@ -84,6 +85,7 @@ typedef struct VFIODevice {
VFIOIOASHwpt *hwpt;
QLIST_ENTRY(VFIODevice) hwpt_next;
struct vfio_region_info **reginfo;
+ int *region_fds;
} VFIODevice;
struct VFIODeviceOps {
@@ -172,10 +174,11 @@ struct VFIODeviceIOOps {
/**
* @get_region_info
*
- * Fill in @info with information on the region given by @info->index.
+ * Fill in @info (and optionally @fd) with information on the region given
+ * by @info->index.
*/
int (*get_region_info)(VFIODevice *vdev,
- struct vfio_region_info *info);
+ struct vfio_region_info *info, int *fd);
/**
* @get_irq_info
diff --git a/hw/vfio/device.c b/hw/vfio/device.c
index d0068086ae..29a8d72deb 100644
--- a/hw/vfio/device.c
+++ b/hw/vfio/device.c
@@ -226,6 +226,7 @@ int vfio_device_get_region_info(VFIODevice *vbasedev, int index,
struct vfio_region_info **info)
{
size_t argsz = sizeof(struct vfio_region_info);
+ int fd = -1;
int ret;
/* check cache */
@@ -240,7 +241,7 @@ int vfio_device_get_region_info(VFIODevice *vbasedev, int index,
retry:
(*info)->argsz = argsz;
- ret = vbasedev->io_ops->get_region_info(vbasedev, *info);
+ ret = vbasedev->io_ops->get_region_info(vbasedev, *info, &fd);
if (ret != 0) {
g_free(*info);
*info = NULL;
@@ -251,11 +252,19 @@ retry:
argsz = (*info)->argsz;
*info = g_realloc(*info, argsz);
+ if (fd != -1) {
+ close(fd);
+ fd = -1;
+ }
+
goto retry;
}
/* fill cache */
vbasedev->reginfo[index] = *info;
+ if (vbasedev->region_fds != NULL) {
+ vbasedev->region_fds[index] = fd;
+ }
return 0;
}
@@ -360,6 +369,7 @@ void vfio_device_init(VFIODevice *vbasedev, int type, VFIODeviceOps *ops,
vbasedev->io_ops = &vfio_device_io_ops_ioctl;
vbasedev->dev = dev;
vbasedev->fd = -1;
+ vbasedev->use_region_fds = false;
vbasedev->ram_block_discard_allowed = ram_discard;
}
@@ -470,6 +480,9 @@ void vfio_device_prepare(VFIODevice *vbasedev, VFIOContainerBase *bcontainer,
vbasedev->reginfo = g_new0(struct vfio_region_info *,
vbasedev->num_regions);
+ if (vbasedev->use_region_fds) {
+ vbasedev->region_fds = g_new0(int, vbasedev->num_regions);
+ }
}
void vfio_device_unprepare(VFIODevice *vbasedev)
@@ -478,9 +491,14 @@ void vfio_device_unprepare(VFIODevice *vbasedev)
for (i = 0; i < vbasedev->num_regions; i++) {
g_free(vbasedev->reginfo[i]);
+ if (vbasedev->region_fds != NULL && vbasedev->region_fds[i] != -1) {
+ close(vbasedev->region_fds[i]);
+ }
+
}
- g_free(vbasedev->reginfo);
- vbasedev->reginfo = NULL;
+
+ g_clear_pointer(&vbasedev->reginfo, g_free);
+ g_clear_pointer(&vbasedev->region_fds, g_free);
QLIST_REMOVE(vbasedev, container_next);
QLIST_REMOVE(vbasedev, global_next);
@@ -502,10 +520,13 @@ static int vfio_device_io_device_feature(VFIODevice *vbasedev,
}
static int vfio_device_io_get_region_info(VFIODevice *vbasedev,
- struct vfio_region_info *info)
+ struct vfio_region_info *info,
+ int *fd)
{
int ret;
+ *fd = -1;
+
ret = ioctl(vbasedev->fd, VFIO_DEVICE_GET_REGION_INFO, info);
return ret < 0 ? -errno : ret;
diff --git a/hw/vfio/region.c b/hw/vfio/region.c
index 34752c3f65..cb172f2136 100644
--- a/hw/vfio/region.c
+++ b/hw/vfio/region.c
@@ -241,6 +241,7 @@ int vfio_region_mmap(VFIORegion *region)
{
int i, ret, prot = 0;
char *name;
+ int fd;
if (!region->mem) {
return 0;
@@ -271,14 +272,18 @@ int vfio_region_mmap(VFIORegion *region)
goto no_mmap;
}
+ /* Use the per-region fd if set, or the shared fd. */
+ fd = region->vbasedev->region_fds ?
+ region->vbasedev->region_fds[region->nr] :
+ region->vbasedev->fd,
+
map_align = (void *)ROUND_UP((uintptr_t)map_base, (uintptr_t)align);
munmap(map_base, map_align - map_base);
munmap(map_align + region->mmaps[i].size,
align - (map_align - map_base));
region->mmaps[i].mmap = mmap(map_align, region->mmaps[i].size, prot,
- MAP_SHARED | MAP_FIXED,
- region->vbasedev->fd,
+ MAP_SHARED | MAP_FIXED, fd,
region->fd_offset +
region->mmaps[i].offset);
if (region->mmaps[i].mmap == MAP_FAILED) {
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH v3 03/23] vfio: add per-region fd support
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
` (2 more replies)
2025-06-10 10:58 ` Mark Cave-Ayland
2025-06-11 7:24 ` Cédric Le Goater
2 siblings, 3 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-10 7:42 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 6/7/25 02:10, John Levon wrote:
> For vfio-user, each region has its own fd rather than sharing
> vbasedev's. Add the necessary plumbing to support this, and use the
> correct fd in vfio_region_mmap().
>
> Signed-off-by: John Levon <john.levon@nutanix.com>
> ---
> include/hw/vfio/vfio-device.h | 7 +++++--
> hw/vfio/device.c | 29 +++++++++++++++++++++++++----
> hw/vfio/region.c | 9 +++++++--
> 3 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/include/hw/vfio/vfio-device.h b/include/hw/vfio/vfio-device.h
> index 923f9cd116..5cb817fd6a 100644
> --- a/include/hw/vfio/vfio-device.h
> +++ b/include/hw/vfio/vfio-device.h
> @@ -66,6 +66,7 @@ typedef struct VFIODevice {
> OnOffAuto enable_migration;
> OnOffAuto migration_multifd_transfer;
> bool migration_events;
> + bool use_region_fds;
> VFIODeviceOps *ops;
> VFIODeviceIOOps *io_ops;
> unsigned int num_irqs;
> @@ -84,6 +85,7 @@ typedef struct VFIODevice {
> VFIOIOASHwpt *hwpt;
> QLIST_ENTRY(VFIODevice) hwpt_next;
> struct vfio_region_info **reginfo;
> + int *region_fds;
> } VFIODevice;
>
> struct VFIODeviceOps {
> @@ -172,10 +174,11 @@ struct VFIODeviceIOOps {
> /**
> * @get_region_info
> *
> - * Fill in @info with information on the region given by @info->index.
> + * Fill in @info (and optionally @fd) with information on the region given
> + * by @info->index.
> */
Could you please update the whole documentation of the VFIODeviceIOOps
struct and document each parameter ?
> int (*get_region_info)(VFIODevice *vdev,
> - struct vfio_region_info *info);
> + struct vfio_region_info *info, int *fd);
>
> /**
> * @get_irq_info
> diff --git a/hw/vfio/device.c b/hw/vfio/device.c
> index d0068086ae..29a8d72deb 100644
> --- a/hw/vfio/device.c
> +++ b/hw/vfio/device.c
> @@ -226,6 +226,7 @@ int vfio_device_get_region_info(VFIODevice *vbasedev, int index,
> struct vfio_region_info **info)
> {
> size_t argsz = sizeof(struct vfio_region_info);
> + int fd = -1;
> int ret;
>
> /* check cache */
> @@ -240,7 +241,7 @@ int vfio_device_get_region_info(VFIODevice *vbasedev, int index,
> retry:
> (*info)->argsz = argsz;
>
> - ret = vbasedev->io_ops->get_region_info(vbasedev, *info);
> + ret = vbasedev->io_ops->get_region_info(vbasedev, *info, &fd);
> if (ret != 0) {
> g_free(*info);
> *info = NULL;
> @@ -251,11 +252,19 @@ retry:
> argsz = (*info)->argsz;
> *info = g_realloc(*info, argsz);
>
> + if (fd != -1) {
> + close(fd);
> + fd = -1;
> + }
> +
> goto retry;
> }
>
> /* fill cache */
> vbasedev->reginfo[index] = *info;
> + if (vbasedev->region_fds != NULL) {
> + vbasedev->region_fds[index] = fd;
> + }
>
> return 0;
> }
> @@ -360,6 +369,7 @@ void vfio_device_init(VFIODevice *vbasedev, int type, VFIODeviceOps *ops,
> vbasedev->io_ops = &vfio_device_io_ops_ioctl;
> vbasedev->dev = dev;
> vbasedev->fd = -1;
> + vbasedev->use_region_fds = false;
why not extend vfio_device_init() with a 'region_fd_cache' bool
parameter instead ? and avoid the extra VFIODevice attribute.
>
> vbasedev->ram_block_discard_allowed = ram_discard;
> }
> @@ -470,6 +480,9 @@ void vfio_device_prepare(VFIODevice *vbasedev, VFIOContainerBase *bcontainer,
>
> vbasedev->reginfo = g_new0(struct vfio_region_info *,
> vbasedev->num_regions);
> + if (vbasedev->use_region_fds) {
> + vbasedev->region_fds = g_new0(int, vbasedev->num_regions);
> + }
> }
>
> void vfio_device_unprepare(VFIODevice *vbasedev)
> @@ -478,9 +491,14 @@ void vfio_device_unprepare(VFIODevice *vbasedev)
>
> for (i = 0; i < vbasedev->num_regions; i++) {
> g_free(vbasedev->reginfo[i]);
> + if (vbasedev->region_fds != NULL && vbasedev->region_fds[i] != -1) {
> + close(vbasedev->region_fds[i]);
> + }
> +
Adding a small helper to retrieve the region fd from the cache,
would hide some of the implementation details here and below in
vfio_region_mmap()
> }
> - g_free(vbasedev->reginfo);
> - vbasedev->reginfo = NULL;
> +
> + g_clear_pointer(&vbasedev->reginfo, g_free);
unrelated change.
Thanks,
C.
> + g_clear_pointer(&vbasedev->region_fds, g_free);
>
> QLIST_REMOVE(vbasedev, container_next);
> QLIST_REMOVE(vbasedev, global_next);
> @@ -502,10 +520,13 @@ static int vfio_device_io_device_feature(VFIODevice *vbasedev,
> }
>
> static int vfio_device_io_get_region_info(VFIODevice *vbasedev,
> - struct vfio_region_info *info)
> + struct vfio_region_info *info,
> + int *fd)
> {
> int ret;
>
> + *fd = -1;
> +
> ret = ioctl(vbasedev->fd, VFIO_DEVICE_GET_REGION_INFO, info);
>
> return ret < 0 ? -errno : ret;
> diff --git a/hw/vfio/region.c b/hw/vfio/region.c
> index 34752c3f65..cb172f2136 100644
> --- a/hw/vfio/region.c
> +++ b/hw/vfio/region.c
> @@ -241,6 +241,7 @@ int vfio_region_mmap(VFIORegion *region)
> {
> int i, ret, prot = 0;
> char *name;
> + int fd;
>
> if (!region->mem) {
> return 0;
> @@ -271,14 +272,18 @@ int vfio_region_mmap(VFIORegion *region)
> goto no_mmap;
> }
>
> + /* Use the per-region fd if set, or the shared fd. */
> + fd = region->vbasedev->region_fds ?
> + region->vbasedev->region_fds[region->nr] :
> + region->vbasedev->fd,
> +
> map_align = (void *)ROUND_UP((uintptr_t)map_base, (uintptr_t)align);
> munmap(map_base, map_align - map_base);
> munmap(map_align + region->mmaps[i].size,
> align - (map_align - map_base));
>
> region->mmaps[i].mmap = mmap(map_align, region->mmaps[i].size, prot,
> - MAP_SHARED | MAP_FIXED,
> - region->vbasedev->fd,
> + MAP_SHARED | MAP_FIXED, fd,
> region->fd_offset +
> region->mmaps[i].offset);
> if (region->mmaps[i].mmap == MAP_FAILED) {
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 03/23] vfio: add per-region fd support
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
2 siblings, 1 reply; 69+ messages in thread
From: John Levon @ 2025-06-10 12:34 UTC (permalink / raw)
To: Cédric Le Goater
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On Tue, Jun 10, 2025 at 09:42:41AM +0200, Cédric Le Goater wrote:
> On 6/7/25 02:10, John Levon wrote:
> > For vfio-user, each region has its own fd rather than sharing
> > vbasedev's. Add the necessary plumbing to support this, and use the
> > correct fd in vfio_region_mmap().
> >
> > @@ -172,10 +174,11 @@ struct VFIODeviceIOOps {
> > /**
> > * @get_region_info
> > *
> > - * Fill in @info with information on the region given by @info->index.
> > + * Fill in @info (and optionally @fd) with information on the region given
> > + * by @info->index.
> > */
>
> Could you please update the whole documentation of the VFIODeviceIOOps
> struct and document each parameter ?
Sorry, not sure what you're asking for. This struct was fully documented in
38bf025d ("vfio: add device IO ops vector")
and its subsequent patches.
> > @@ -360,6 +369,7 @@ void vfio_device_init(VFIODevice *vbasedev, int type, VFIODeviceOps *ops,
> > vbasedev->io_ops = &vfio_device_io_ops_ioctl;
> > vbasedev->dev = dev;
> > vbasedev->fd = -1;
> > + vbasedev->use_region_fds = false;
>
> why not extend vfio_device_init() with a 'region_fd_cache' bool
> parameter instead ?
I could do, but you previously asked me not to add an "io_ops" parameter to this
function and instead directly change it here - why is this parameter different?
> and avoid the extra VFIODevice attribute.
I don't get this - we still need to record the boolean in the vbasedev.
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 03/23] vfio: add per-region fd support
2025-06-10 12:34 ` John Levon
@ 2025-06-11 7:12 ` Cédric Le Goater
0 siblings, 0 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-11 7:12 UTC (permalink / raw)
To: John Levon
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 6/10/25 14:34, John Levon wrote:
> On Tue, Jun 10, 2025 at 09:42:41AM +0200, Cédric Le Goater wrote:
>
>> On 6/7/25 02:10, John Levon wrote:
>>> For vfio-user, each region has its own fd rather than sharing
>>> vbasedev's. Add the necessary plumbing to support this, and use the
>>> correct fd in vfio_region_mmap().
>>>
>>> @@ -172,10 +174,11 @@ struct VFIODeviceIOOps {
>>> /**
>>> * @get_region_info
>>> *
>>> - * Fill in @info with information on the region given by @info->index.
>>> + * Fill in @info (and optionally @fd) with information on the region given
>>> + * by @info->index.
>>> */
>>
>> Could you please update the whole documentation of the VFIODeviceIOOps
>> struct and document each parameter ?
>
> Sorry, not sure what you're asking for. This struct was fully documented in
> 38bf025d ("vfio: add device IO ops vector")
> and its subsequent patches.
yes. See the formatting of VFIODeviceOps :
/**
* @vfio_save_config
*
* Save device config state
*
* @vdev: #VFIODevice for which to save the config
* @f: #QEMUFile where to send the data
* @errp: pointer to Error*, to store an error if it happens.
*
* Returns zero to indicate success and negative for error
*/
int (*vfio_save_config)(VFIODevice *vdev, QEMUFile *f, Error **errp);
No big deal. It can come later.
>>> @@ -360,6 +369,7 @@ void vfio_device_init(VFIODevice *vbasedev, int type, VFIODeviceOps *ops,
>>> vbasedev->io_ops = &vfio_device_io_ops_ioctl;
>>> vbasedev->dev = dev;
>>> vbasedev->fd = -1;
>>> + vbasedev->use_region_fds = false;
>>
>> why not extend vfio_device_init() with a 'region_fd_cache' bool
>> parameter instead ?
>
> I could do, but you previously asked me not to add an "io_ops" parameter to this
> function and instead directly change it here - why is this parameter different?
Because I thought we could allocate vbasedev->region_fds[] directly under
vfio_device_init().
>> and avoid the extra VFIODevice attribute.
>
> I don't get this - we still need to record the boolean in the vbasedev.
but we can't because we don't have the vbasedev->num_regions value yet.
So forget this proposal.
That said, there are a few contortions around the instance_init()
handler, vfio_device_init() and the realize() handler that I find
confusing. I will see if it can be improved when the code is stable
again.
Thanks,
C.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 03/23] vfio: add per-region fd support
2025-06-10 7:42 ` Cédric Le Goater
2025-06-10 12:34 ` John Levon
@ 2025-06-10 16:59 ` John Levon
2025-06-10 18:15 ` John Levon
2 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-10 16:59 UTC (permalink / raw)
To: Cédric Le Goater
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On Tue, Jun 10, 2025 at 09:42:41AM +0200, Cédric Le Goater wrote:
> > @@ -478,9 +491,14 @@ void vfio_device_unprepare(VFIODevice *vbasedev)
> > for (i = 0; i < vbasedev->num_regions; i++) {
> > g_free(vbasedev->reginfo[i]);
> > + if (vbasedev->region_fds != NULL && vbasedev->region_fds[i] != -1) {
> > + close(vbasedev->region_fds[i]);
> > + }
> > +
>
> Adding a small helper to retrieve the region fd from the cache,
> would hide some of the implementation details here and below in
> vfio_region_mmap()
I can add a region_get_fd() helper, but I can't use it here - we should only
close the fd if it's a per-region fd. I'll make this call a region_cleanup() or
similar.
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 03/23] vfio: add per-region fd support
2025-06-10 7:42 ` Cédric Le Goater
2025-06-10 12:34 ` John Levon
2025-06-10 16:59 ` John Levon
@ 2025-06-10 18:15 ` John Levon
2 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-10 18:15 UTC (permalink / raw)
To: Cédric Le Goater
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On Tue, Jun 10, 2025 at 09:42:41AM +0200, Cédric Le Goater wrote:
> > @@ -478,9 +491,14 @@ void vfio_device_unprepare(VFIODevice *vbasedev)
> > for (i = 0; i < vbasedev->num_regions; i++) {
> > g_free(vbasedev->reginfo[i]);
> > + if (vbasedev->region_fds != NULL && vbasedev->region_fds[i] != -1) {
> > + close(vbasedev->region_fds[i]);
> > + }
>
> Adding a small helper to retrieve the region fd from the cache,
> would hide some of the implementation details here and below in
> vfio_region_mmap()
I've added vfio_device_get_region_fd() - used by vfio_region_mmap(); now the
existence of ->region_fds is private to device.c, so I think that's better.
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 03/23] vfio: add per-region fd support
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 10:58 ` Mark Cave-Ayland
2025-06-10 11:27 ` John Levon
2025-06-11 7:24 ` Cédric Le Goater
2 siblings, 1 reply; 69+ messages in thread
From: Mark Cave-Ayland @ 2025-06-10 10:58 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé
On 07/06/2025 01:10, John Levon wrote:
> For vfio-user, each region has its own fd rather than sharing
> vbasedev's. Add the necessary plumbing to support this, and use the
> correct fd in vfio_region_mmap().
>
> Signed-off-by: John Levon <john.levon@nutanix.com>
> ---
> include/hw/vfio/vfio-device.h | 7 +++++--
> hw/vfio/device.c | 29 +++++++++++++++++++++++++----
> hw/vfio/region.c | 9 +++++++--
> 3 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/include/hw/vfio/vfio-device.h b/include/hw/vfio/vfio-device.h
> index 923f9cd116..5cb817fd6a 100644
> --- a/include/hw/vfio/vfio-device.h
> +++ b/include/hw/vfio/vfio-device.h
> @@ -66,6 +66,7 @@ typedef struct VFIODevice {
> OnOffAuto enable_migration;
> OnOffAuto migration_multifd_transfer;
> bool migration_events;
> + bool use_region_fds;
> VFIODeviceOps *ops;
> VFIODeviceIOOps *io_ops;
> unsigned int num_irqs;
> @@ -84,6 +85,7 @@ typedef struct VFIODevice {
> VFIOIOASHwpt *hwpt;
> QLIST_ENTRY(VFIODevice) hwpt_next;
> struct vfio_region_info **reginfo;
> + int *region_fds;
> } VFIODevice;
>
> struct VFIODeviceOps {
> @@ -172,10 +174,11 @@ struct VFIODeviceIOOps {
> /**
> * @get_region_info
> *
> - * Fill in @info with information on the region given by @info->index.
> + * Fill in @info (and optionally @fd) with information on the region given
> + * by @info->index.
> */
> int (*get_region_info)(VFIODevice *vdev,
> - struct vfio_region_info *info);
> + struct vfio_region_info *info, int *fd);
>
> /**
> * @get_irq_info
> diff --git a/hw/vfio/device.c b/hw/vfio/device.c
> index d0068086ae..29a8d72deb 100644
> --- a/hw/vfio/device.c
> +++ b/hw/vfio/device.c
> @@ -226,6 +226,7 @@ int vfio_device_get_region_info(VFIODevice *vbasedev, int index,
> struct vfio_region_info **info)
> {
> size_t argsz = sizeof(struct vfio_region_info);
> + int fd = -1;
> int ret;
>
> /* check cache */
> @@ -240,7 +241,7 @@ int vfio_device_get_region_info(VFIODevice *vbasedev, int index,
> retry:
> (*info)->argsz = argsz;
>
> - ret = vbasedev->io_ops->get_region_info(vbasedev, *info);
> + ret = vbasedev->io_ops->get_region_info(vbasedev, *info, &fd);
> if (ret != 0) {
> g_free(*info);
> *info = NULL;
> @@ -251,11 +252,19 @@ retry:
> argsz = (*info)->argsz;
> *info = g_realloc(*info, argsz);
>
> + if (fd != -1) {
> + close(fd);
> + fd = -1;
> + }
> +
> goto retry;
> }
>
> /* fill cache */
> vbasedev->reginfo[index] = *info;
> + if (vbasedev->region_fds != NULL) {
> + vbasedev->region_fds[index] = fd;
> + }
>
> return 0;
> }
> @@ -360,6 +369,7 @@ void vfio_device_init(VFIODevice *vbasedev, int type, VFIODeviceOps *ops,
> vbasedev->io_ops = &vfio_device_io_ops_ioctl;
> vbasedev->dev = dev;
> vbasedev->fd = -1;
> + vbasedev->use_region_fds = false;
>
> vbasedev->ram_block_discard_allowed = ram_discard;
> }
> @@ -470,6 +480,9 @@ void vfio_device_prepare(VFIODevice *vbasedev, VFIOContainerBase *bcontainer,
>
> vbasedev->reginfo = g_new0(struct vfio_region_info *,
> vbasedev->num_regions);
> + if (vbasedev->use_region_fds) {
> + vbasedev->region_fds = g_new0(int, vbasedev->num_regions);
> + }
> }
>
> void vfio_device_unprepare(VFIODevice *vbasedev)
> @@ -478,9 +491,14 @@ void vfio_device_unprepare(VFIODevice *vbasedev)
>
> for (i = 0; i < vbasedev->num_regions; i++) {
> g_free(vbasedev->reginfo[i]);
> + if (vbasedev->region_fds != NULL && vbasedev->region_fds[i] != -1) {
> + close(vbasedev->region_fds[i]);
> + }
> +
> }
> - g_free(vbasedev->reginfo);
> - vbasedev->reginfo = NULL;
> +
> + g_clear_pointer(&vbasedev->reginfo, g_free);
> + g_clear_pointer(&vbasedev->region_fds, g_free);
>
> QLIST_REMOVE(vbasedev, container_next);
> QLIST_REMOVE(vbasedev, global_next);
> @@ -502,10 +520,13 @@ static int vfio_device_io_device_feature(VFIODevice *vbasedev,
> }
>
> static int vfio_device_io_get_region_info(VFIODevice *vbasedev,
> - struct vfio_region_info *info)
> + struct vfio_region_info *info,
> + int *fd)
> {
> int ret;
>
> + *fd = -1;
> +
> ret = ioctl(vbasedev->fd, VFIO_DEVICE_GET_REGION_INFO, info);
>
> return ret < 0 ? -errno : ret;
> diff --git a/hw/vfio/region.c b/hw/vfio/region.c
> index 34752c3f65..cb172f2136 100644
> --- a/hw/vfio/region.c
> +++ b/hw/vfio/region.c
> @@ -241,6 +241,7 @@ int vfio_region_mmap(VFIORegion *region)
> {
> int i, ret, prot = 0;
> char *name;
> + int fd;
>
> if (!region->mem) {
> return 0;
> @@ -271,14 +272,18 @@ int vfio_region_mmap(VFIORegion *region)
> goto no_mmap;
> }
>
> + /* Use the per-region fd if set, or the shared fd. */
> + fd = region->vbasedev->region_fds ?
> + region->vbasedev->region_fds[region->nr] :
> + region->vbasedev->fd,
> +
This feels a bit odd: if you're asking to map a VFIORegion then
shouldn't that contain all the information required for the mapping,
including the fd?
(goes and looks)
It appears that there is already a fd field in VFIORegion so is there a
reason why we can't use this instead of adding region_fds to vbasedev?
> map_align = (void *)ROUND_UP((uintptr_t)map_base, (uintptr_t)align);
> munmap(map_base, map_align - map_base);
> munmap(map_align + region->mmaps[i].size,
> align - (map_align - map_base));
>
> region->mmaps[i].mmap = mmap(map_align, region->mmaps[i].size, prot,
> - MAP_SHARED | MAP_FIXED,
> - region->vbasedev->fd,
> + MAP_SHARED | MAP_FIXED, fd,
> region->fd_offset +
> region->mmaps[i].offset);
> if (region->mmaps[i].mmap == MAP_FAILED) {
ATB,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 03/23] vfio: add per-region fd support
2025-06-10 10:58 ` Mark Cave-Ayland
@ 2025-06-10 11:27 ` John Levon
2025-06-10 11:57 ` Cédric Le Goater
0 siblings, 1 reply; 69+ messages in thread
From: John Levon @ 2025-06-10 11:27 UTC (permalink / raw)
To: Mark Cave-Ayland
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Cédric Le Goater, Philippe Mathieu-Daudé
On Tue, Jun 10, 2025 at 11:58:18AM +0100, Mark Cave-Ayland wrote:
> > + /* Use the per-region fd if set, or the shared fd. */
> > + fd = region->vbasedev->region_fds ?
> > + region->vbasedev->region_fds[region->nr] :
> > + region->vbasedev->fd,
> > +
>
> This feels a bit odd: if you're asking to map a VFIORegion then shouldn't
> that contain all the information required for the mapping, including the fd?
>
> (goes and looks)
>
> It appears that there is already a fd field in VFIORegion so is there a
> reason why we can't use this instead of adding region_fds to vbasedev?
region->fd was in earlier patchsets, but dropped as requested by Cédric. So we
must look it up here.
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 03/23] vfio: add per-region fd support
2025-06-10 11:27 ` John Levon
@ 2025-06-10 11:57 ` Cédric Le Goater
2025-06-10 12:13 ` John Levon
0 siblings, 1 reply; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-10 11:57 UTC (permalink / raw)
To: John Levon, Mark Cave-Ayland
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 6/10/25 13:27, John Levon wrote:
> On Tue, Jun 10, 2025 at 11:58:18AM +0100, Mark Cave-Ayland wrote:
>
>>> + /* Use the per-region fd if set, or the shared fd. */
>>> + fd = region->vbasedev->region_fds ?
>>> + region->vbasedev->region_fds[region->nr] :
>>> + region->vbasedev->fd,
>>> +
>>
>> This feels a bit odd: if you're asking to map a VFIORegion then shouldn't
>> that contain all the information required for the mapping, including the fd?
>>
>> (goes and looks)
>>
>> It appears that there is already a fd field in VFIORegion so is there a
>> reason why we can't use this instead of adding region_fds to vbasedev?
>
> region->fd was in earlier patchsets, but dropped as requested by Cédric. So we
> must look it up here.
yes. It didn't seem necessary to store the same information under
multiple structs.
C.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 03/23] vfio: add per-region fd support
2025-06-10 11:57 ` Cédric Le Goater
@ 2025-06-10 12:13 ` John Levon
0 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-10 12:13 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Mark Cave-Ayland, qemu-devel, Daniel P. Berrangé,
Paolo Bonzini, Thanos Makatos, Marc-André Lureau,
Alex Williamson, Philippe Mathieu-Daudé
On Tue, Jun 10, 2025 at 01:57:23PM +0200, Cédric Le Goater wrote:
> On 6/10/25 13:27, John Levon wrote:
> > On Tue, Jun 10, 2025 at 11:58:18AM +0100, Mark Cave-Ayland wrote:
> >
> > > > + /* Use the per-region fd if set, or the shared fd. */
> > > > + fd = region->vbasedev->region_fds ?
> > > > + region->vbasedev->region_fds[region->nr] :
> > > > + region->vbasedev->fd,
> > > > +
> > >
> > > This feels a bit odd: if you're asking to map a VFIORegion then shouldn't
> > > that contain all the information required for the mapping, including the fd?
> > >
> > > (goes and looks)
> > >
> > > It appears that there is already a fd field in VFIORegion so is there a
> > > reason why we can't use this instead of adding region_fds to vbasedev?
> >
> > region->fd was in earlier patchsets, but dropped as requested by Cédric. So we
> > must look it up here.
>
> yes. It didn't seem necessary to store the same information under
> multiple structs.
And the reason we have ->region_fds at all rather than just storing directly in
region->fd is that vfio_device_get_region_info() doesn't take a VFIORegion
argument, as it's used in other contexts too.
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 03/23] vfio: add per-region fd support
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 10:58 ` Mark Cave-Ayland
@ 2025-06-11 7:24 ` Cédric Le Goater
2 siblings, 0 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-11 7:24 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 6/7/25 02:10, John Levon wrote:
> For vfio-user, each region has its own fd rather than sharing
> vbasedev's. Add the necessary plumbing to support this, and use the
> correct fd in vfio_region_mmap().
>
> Signed-off-by: John Levon <john.levon@nutanix.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Applied to vfio-next.
Thanks,
C.
> ---
> include/hw/vfio/vfio-device.h | 7 +++++--
> hw/vfio/device.c | 29 +++++++++++++++++++++++++----
> hw/vfio/region.c | 9 +++++++--
> 3 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/include/hw/vfio/vfio-device.h b/include/hw/vfio/vfio-device.h
> index 923f9cd116..5cb817fd6a 100644
> --- a/include/hw/vfio/vfio-device.h
> +++ b/include/hw/vfio/vfio-device.h
> @@ -66,6 +66,7 @@ typedef struct VFIODevice {
> OnOffAuto enable_migration;
> OnOffAuto migration_multifd_transfer;
> bool migration_events;
> + bool use_region_fds;
> VFIODeviceOps *ops;
> VFIODeviceIOOps *io_ops;
> unsigned int num_irqs;
> @@ -84,6 +85,7 @@ typedef struct VFIODevice {
> VFIOIOASHwpt *hwpt;
> QLIST_ENTRY(VFIODevice) hwpt_next;
> struct vfio_region_info **reginfo;
> + int *region_fds;
> } VFIODevice;
>
> struct VFIODeviceOps {
> @@ -172,10 +174,11 @@ struct VFIODeviceIOOps {
> /**
> * @get_region_info
> *
> - * Fill in @info with information on the region given by @info->index.
> + * Fill in @info (and optionally @fd) with information on the region given
> + * by @info->index.
> */
> int (*get_region_info)(VFIODevice *vdev,
> - struct vfio_region_info *info);
> + struct vfio_region_info *info, int *fd);
>
> /**
> * @get_irq_info
> diff --git a/hw/vfio/device.c b/hw/vfio/device.c
> index d0068086ae..29a8d72deb 100644
> --- a/hw/vfio/device.c
> +++ b/hw/vfio/device.c
> @@ -226,6 +226,7 @@ int vfio_device_get_region_info(VFIODevice *vbasedev, int index,
> struct vfio_region_info **info)
> {
> size_t argsz = sizeof(struct vfio_region_info);
> + int fd = -1;
> int ret;
>
> /* check cache */
> @@ -240,7 +241,7 @@ int vfio_device_get_region_info(VFIODevice *vbasedev, int index,
> retry:
> (*info)->argsz = argsz;
>
> - ret = vbasedev->io_ops->get_region_info(vbasedev, *info);
> + ret = vbasedev->io_ops->get_region_info(vbasedev, *info, &fd);
> if (ret != 0) {
> g_free(*info);
> *info = NULL;
> @@ -251,11 +252,19 @@ retry:
> argsz = (*info)->argsz;
> *info = g_realloc(*info, argsz);
>
> + if (fd != -1) {
> + close(fd);
> + fd = -1;
> + }
> +
> goto retry;
> }
>
> /* fill cache */
> vbasedev->reginfo[index] = *info;
> + if (vbasedev->region_fds != NULL) {
> + vbasedev->region_fds[index] = fd;
> + }
>
> return 0;
> }
> @@ -360,6 +369,7 @@ void vfio_device_init(VFIODevice *vbasedev, int type, VFIODeviceOps *ops,
> vbasedev->io_ops = &vfio_device_io_ops_ioctl;
> vbasedev->dev = dev;
> vbasedev->fd = -1;
> + vbasedev->use_region_fds = false;
>
> vbasedev->ram_block_discard_allowed = ram_discard;
> }
> @@ -470,6 +480,9 @@ void vfio_device_prepare(VFIODevice *vbasedev, VFIOContainerBase *bcontainer,
>
> vbasedev->reginfo = g_new0(struct vfio_region_info *,
> vbasedev->num_regions);
> + if (vbasedev->use_region_fds) {
> + vbasedev->region_fds = g_new0(int, vbasedev->num_regions);
> + }
> }
>
> void vfio_device_unprepare(VFIODevice *vbasedev)
> @@ -478,9 +491,14 @@ void vfio_device_unprepare(VFIODevice *vbasedev)
>
> for (i = 0; i < vbasedev->num_regions; i++) {
> g_free(vbasedev->reginfo[i]);
> + if (vbasedev->region_fds != NULL && vbasedev->region_fds[i] != -1) {
> + close(vbasedev->region_fds[i]);
> + }
> +
> }
> - g_free(vbasedev->reginfo);
> - vbasedev->reginfo = NULL;
> +
> + g_clear_pointer(&vbasedev->reginfo, g_free);
> + g_clear_pointer(&vbasedev->region_fds, g_free);
>
> QLIST_REMOVE(vbasedev, container_next);
> QLIST_REMOVE(vbasedev, global_next);
> @@ -502,10 +520,13 @@ static int vfio_device_io_device_feature(VFIODevice *vbasedev,
> }
>
> static int vfio_device_io_get_region_info(VFIODevice *vbasedev,
> - struct vfio_region_info *info)
> + struct vfio_region_info *info,
> + int *fd)
> {
> int ret;
>
> + *fd = -1;
> +
> ret = ioctl(vbasedev->fd, VFIO_DEVICE_GET_REGION_INFO, info);
>
> return ret < 0 ? -errno : ret;
> diff --git a/hw/vfio/region.c b/hw/vfio/region.c
> index 34752c3f65..cb172f2136 100644
> --- a/hw/vfio/region.c
> +++ b/hw/vfio/region.c
> @@ -241,6 +241,7 @@ int vfio_region_mmap(VFIORegion *region)
> {
> int i, ret, prot = 0;
> char *name;
> + int fd;
>
> if (!region->mem) {
> return 0;
> @@ -271,14 +272,18 @@ int vfio_region_mmap(VFIORegion *region)
> goto no_mmap;
> }
>
> + /* Use the per-region fd if set, or the shared fd. */
> + fd = region->vbasedev->region_fds ?
> + region->vbasedev->region_fds[region->nr] :
> + region->vbasedev->fd,
> +
> map_align = (void *)ROUND_UP((uintptr_t)map_base, (uintptr_t)align);
> munmap(map_base, map_align - map_base);
> munmap(map_align + region->mmaps[i].size,
> align - (map_align - map_base));
>
> region->mmaps[i].mmap = mmap(map_align, region->mmaps[i].size, prot,
> - MAP_SHARED | MAP_FIXED,
> - region->vbasedev->fd,
> + MAP_SHARED | MAP_FIXED, fd,
> region->fd_offset +
> region->mmaps[i].offset);
> if (region->mmaps[i].mmap == MAP_FAILED) {
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH v3 04/23] vfio: mark posted writes in region write callbacks
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (2 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 03/23] vfio: add per-region fd support John Levon
@ 2025-06-07 0:10 ` 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
` (19 subsequent siblings)
23 siblings, 1 reply; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon
For vfio-user, the region write implementation needs to know if the
write is posted; add the necessary plumbing to support this.
Signed-off-by: John Levon <john.levon@nutanix.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
---
include/hw/vfio/vfio-device.h | 4 ++--
include/hw/vfio/vfio-region.h | 1 +
hw/vfio/device.c | 3 ++-
hw/vfio/pci.c | 5 ++++-
hw/vfio/region.c | 3 ++-
5 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/hw/vfio/vfio-device.h b/include/hw/vfio/vfio-device.h
index 5cb817fd6a..a23ef4ea13 100644
--- a/include/hw/vfio/vfio-device.h
+++ b/include/hw/vfio/vfio-device.h
@@ -207,10 +207,10 @@ struct VFIODeviceIOOps {
* @region_write
*
* Write @size bytes to the region @nr at offset @off from the buffer
- * @data.
+ * @data; if @post, the write is posted.
*/
int (*region_write)(VFIODevice *vdev, uint8_t nr, off_t off, uint32_t size,
- void *data);
+ void *data, bool post);
};
void vfio_device_prepare(VFIODevice *vbasedev, VFIOContainerBase *bcontainer,
diff --git a/include/hw/vfio/vfio-region.h b/include/hw/vfio/vfio-region.h
index cbffb26962..ede6e0c8f9 100644
--- a/include/hw/vfio/vfio-region.h
+++ b/include/hw/vfio/vfio-region.h
@@ -29,6 +29,7 @@ typedef struct VFIORegion {
uint32_t nr_mmaps;
VFIOMmap *mmaps;
uint8_t nr; /* cache the region number for debug */
+ bool post_wr; /* writes can be posted */
} VFIORegion;
diff --git a/hw/vfio/device.c b/hw/vfio/device.c
index 29a8d72deb..ad0bac9765 100644
--- a/hw/vfio/device.c
+++ b/hw/vfio/device.c
@@ -569,7 +569,8 @@ static int vfio_device_io_region_read(VFIODevice *vbasedev, uint8_t index,
}
static int vfio_device_io_region_write(VFIODevice *vbasedev, uint8_t index,
- off_t off, uint32_t size, void *data)
+ off_t off, uint32_t size, void *data,
+ bool post)
{
struct vfio_region_info *info;
int ret;
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 714d37e227..d68c1412d2 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1015,7 +1015,7 @@ static int vfio_pci_config_space_write(VFIOPCIDevice *vdev, off_t offset,
{
return vdev->vbasedev.io_ops->region_write(&vdev->vbasedev,
VFIO_PCI_CONFIG_REGION_INDEX,
- offset, size, data);
+ offset, size, data, false);
}
static uint64_t vfio_rom_read(void *opaque, hwaddr addr, unsigned size)
@@ -1819,6 +1819,9 @@ static void vfio_bar_prepare(VFIOPCIDevice *vdev, int nr)
bar->type = pci_bar & (bar->ioport ? ~PCI_BASE_ADDRESS_IO_MASK :
~PCI_BASE_ADDRESS_MEM_MASK);
bar->size = bar->region.size;
+
+ /* IO regions are sync, memory can be async */
+ bar->region.post_wr = (bar->ioport == 0);
}
static void vfio_bars_prepare(VFIOPCIDevice *vdev)
diff --git a/hw/vfio/region.c b/hw/vfio/region.c
index cb172f2136..f5b8e3cbf1 100644
--- a/hw/vfio/region.c
+++ b/hw/vfio/region.c
@@ -66,7 +66,7 @@ void vfio_region_write(void *opaque, hwaddr addr,
}
ret = vbasedev->io_ops->region_write(vbasedev, region->nr,
- addr, size, &buf);
+ addr, size, &buf, region->post_wr);
if (ret != size) {
error_report("%s(%s:region%d+0x%"HWADDR_PRIx", 0x%"PRIx64
",%d) failed: %s",
@@ -200,6 +200,7 @@ int vfio_region_setup(Object *obj, VFIODevice *vbasedev, VFIORegion *region,
region->size = info->size;
region->fd_offset = info->offset;
region->nr = index;
+ region->post_wr = false;
if (region->size) {
region->mem = g_new0(MemoryRegion, 1);
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH v3 04/23] vfio: mark posted writes in region write callbacks
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
0 siblings, 0 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-11 7:24 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 6/7/25 02:10, John Levon wrote:
> For vfio-user, the region write implementation needs to know if the
> write is posted; add the necessary plumbing to support this.
>
> Signed-off-by: John Levon <john.levon@nutanix.com>
> Reviewed-by: Cédric Le Goater <clg@redhat.com>
Applied to vfio-next.
Thanks,
C.
> ---
> include/hw/vfio/vfio-device.h | 4 ++--
> include/hw/vfio/vfio-region.h | 1 +
> hw/vfio/device.c | 3 ++-
> hw/vfio/pci.c | 5 ++++-
> hw/vfio/region.c | 3 ++-
> 5 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/include/hw/vfio/vfio-device.h b/include/hw/vfio/vfio-device.h
> index 5cb817fd6a..a23ef4ea13 100644
> --- a/include/hw/vfio/vfio-device.h
> +++ b/include/hw/vfio/vfio-device.h
> @@ -207,10 +207,10 @@ struct VFIODeviceIOOps {
> * @region_write
> *
> * Write @size bytes to the region @nr at offset @off from the buffer
> - * @data.
> + * @data; if @post, the write is posted.
> */
> int (*region_write)(VFIODevice *vdev, uint8_t nr, off_t off, uint32_t size,
> - void *data);
> + void *data, bool post);
> };
>
> void vfio_device_prepare(VFIODevice *vbasedev, VFIOContainerBase *bcontainer,
> diff --git a/include/hw/vfio/vfio-region.h b/include/hw/vfio/vfio-region.h
> index cbffb26962..ede6e0c8f9 100644
> --- a/include/hw/vfio/vfio-region.h
> +++ b/include/hw/vfio/vfio-region.h
> @@ -29,6 +29,7 @@ typedef struct VFIORegion {
> uint32_t nr_mmaps;
> VFIOMmap *mmaps;
> uint8_t nr; /* cache the region number for debug */
> + bool post_wr; /* writes can be posted */
> } VFIORegion;
>
>
> diff --git a/hw/vfio/device.c b/hw/vfio/device.c
> index 29a8d72deb..ad0bac9765 100644
> --- a/hw/vfio/device.c
> +++ b/hw/vfio/device.c
> @@ -569,7 +569,8 @@ static int vfio_device_io_region_read(VFIODevice *vbasedev, uint8_t index,
> }
>
> static int vfio_device_io_region_write(VFIODevice *vbasedev, uint8_t index,
> - off_t off, uint32_t size, void *data)
> + off_t off, uint32_t size, void *data,
> + bool post)
> {
> struct vfio_region_info *info;
> int ret;
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 714d37e227..d68c1412d2 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -1015,7 +1015,7 @@ static int vfio_pci_config_space_write(VFIOPCIDevice *vdev, off_t offset,
> {
> return vdev->vbasedev.io_ops->region_write(&vdev->vbasedev,
> VFIO_PCI_CONFIG_REGION_INDEX,
> - offset, size, data);
> + offset, size, data, false);
> }
>
> static uint64_t vfio_rom_read(void *opaque, hwaddr addr, unsigned size)
> @@ -1819,6 +1819,9 @@ static void vfio_bar_prepare(VFIOPCIDevice *vdev, int nr)
> bar->type = pci_bar & (bar->ioport ? ~PCI_BASE_ADDRESS_IO_MASK :
> ~PCI_BASE_ADDRESS_MEM_MASK);
> bar->size = bar->region.size;
> +
> + /* IO regions are sync, memory can be async */
> + bar->region.post_wr = (bar->ioport == 0);
> }
>
> static void vfio_bars_prepare(VFIOPCIDevice *vdev)
> diff --git a/hw/vfio/region.c b/hw/vfio/region.c
> index cb172f2136..f5b8e3cbf1 100644
> --- a/hw/vfio/region.c
> +++ b/hw/vfio/region.c
> @@ -66,7 +66,7 @@ void vfio_region_write(void *opaque, hwaddr addr,
> }
>
> ret = vbasedev->io_ops->region_write(vbasedev, region->nr,
> - addr, size, &buf);
> + addr, size, &buf, region->post_wr);
> if (ret != size) {
> error_report("%s(%s:region%d+0x%"HWADDR_PRIx", 0x%"PRIx64
> ",%d) failed: %s",
> @@ -200,6 +200,7 @@ int vfio_region_setup(Object *obj, VFIODevice *vbasedev, VFIORegion *region,
> region->size = info->size;
> region->fd_offset = info->offset;
> region->nr = index;
> + region->post_wr = false;
>
> if (region->size) {
> region->mem = g_new0(MemoryRegion, 1);
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH v3 05/23] vfio-user: introduce vfio-user protocol specification
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (3 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 04/23] vfio: mark posted writes in region write callbacks John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-10 9:38 ` Cédric Le Goater
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
` (18 subsequent siblings)
23 siblings, 2 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon
From: Thanos Makatos <thanos.makatos@nutanix.com>
This patch introduces the vfio-user protocol specification (formerly
known as VFIO-over-socket), which is designed to allow devices to be
emulated outside QEMU, in a separate process. vfio-user reuses the
existing VFIO defines, structs and concepts.
It has been earlier discussed as an RFC in:
"RFC: use VFIO over a UNIX domain socket to implement device offloading"
Signed-off-by: Thanos Makatos <thanos.makatos@nutanix.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
MAINTAINERS | 8 +-
docs/devel/index-internals.rst | 1 +
docs/devel/vfio-user.rst | 1522 ++++++++++++++++++++++++++++++++
3 files changed, 1530 insertions(+), 1 deletion(-)
create mode 100644 docs/devel/vfio-user.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index aa6763077e..dbc393989a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4241,13 +4241,19 @@ F: hw/remote/proxy-memory-listener.c
F: include/hw/remote/proxy-memory-listener.h
F: hw/remote/iohub.c
F: include/hw/remote/iohub.h
-F: subprojects/libvfio-user
F: hw/remote/vfio-user-obj.c
F: include/hw/remote/vfio-user-obj.h
F: hw/remote/iommu.c
F: include/hw/remote/iommu.h
F: tests/functional/test_multiprocess.py
+VFIO-USER:
+M: John Levon <john.levon@nutanix.com>
+M: Thanos Makatos <thanos.makatos@nutanix.com>
+S: Supported
+F: docs/devel/vfio-user.rst
+F: subprojects/libvfio-user
+
EBPF:
M: Jason Wang <jasowang@redhat.com>
R: Andrew Melnychenko <andrew@daynix.com>
diff --git a/docs/devel/index-internals.rst b/docs/devel/index-internals.rst
index 7a0678cbdd..1b04311f06 100644
--- a/docs/devel/index-internals.rst
+++ b/docs/devel/index-internals.rst
@@ -22,6 +22,7 @@ Details about QEMU's various subsystems including how to add features to them.
tracing
uefi-vars
vfio-iommufd
+ vfio-user
writing-monitor-commands
virtio-backends
crypto
diff --git a/docs/devel/vfio-user.rst b/docs/devel/vfio-user.rst
new file mode 100644
index 0000000000..0d96477a68
--- /dev/null
+++ b/docs/devel/vfio-user.rst
@@ -0,0 +1,1522 @@
+.. include:: <isonum.txt>
+********************************
+vfio-user Protocol Specification
+********************************
+
+--------------
+Version_ 0.9.1
+--------------
+
+.. contents:: Table of Contents
+
+Introduction
+============
+vfio-user is a protocol that allows a device to be emulated in a separate
+process outside of a Virtual Machine Monitor (VMM). vfio-user devices consist
+of a generic VFIO device type, living inside the VMM, which we call the client,
+and the core device implementation, living outside the VMM, which we call the
+server.
+
+The vfio-user specification is partly based on the
+`Linux VFIO ioctl interface <https://www.kernel.org/doc/html/latest/driver-api/vfio.html>`_.
+
+VFIO is a mature and stable API, backed by an extensively used framework. The
+existing VFIO client implementation in QEMU (``qemu/hw/vfio/``) can be largely
+re-used, though there is nothing in this specification that requires that
+particular implementation. None of the VFIO kernel modules are required for
+supporting the protocol, on either the client or server side. Some source
+definitions in VFIO are re-used for vfio-user.
+
+The main idea is to allow a virtual device to function in a separate process in
+the same host over a UNIX domain socket. A UNIX domain socket (``AF_UNIX``) is
+chosen because file descriptors can be trivially sent over it, which in turn
+allows:
+
+* Sharing of client memory for DMA with the server.
+* Sharing of server memory with the client for fast MMIO.
+* Efficient sharing of eventfd's for triggering interrupts.
+
+Other socket types could be used which allow the server to run in a separate
+guest in the same host (``AF_VSOCK``) or remotely (``AF_INET``). Theoretically
+the underlying transport does not necessarily have to be a socket, however we do
+not examine such alternatives. In this protocol version we focus on using a UNIX
+domain socket and introduce basic support for the other two types of sockets
+without considering performance implications.
+
+While passing of file descriptors is desirable for performance reasons, support
+is not necessary for either the client or the server in order to implement the
+protocol. There is always an in-band, message-passing fall back mechanism.
+
+Overview
+========
+
+VFIO is a framework that allows a physical device to be securely passed through
+to a user space process; the device-specific kernel driver does not drive the
+device at all. Typically, the user space process is a VMM and the device is
+passed through to it in order to achieve high performance. VFIO provides an API
+and the required functionality in the kernel. QEMU has adopted VFIO to allow a
+guest to directly access physical devices, instead of emulating them in
+software.
+
+vfio-user reuses the core VFIO concepts defined in its API, but implements them
+as messages to be sent over a socket. It does not change the kernel-based VFIO
+in any way, in fact none of the VFIO kernel modules need to be loaded to use
+vfio-user. It is also possible for the client to concurrently use the current
+kernel-based VFIO for one device, and vfio-user for another device.
+
+VFIO Device Model
+-----------------
+
+A device under VFIO presents a standard interface to the user process. Many of
+the VFIO operations in the existing interface use the ``ioctl()`` system call, and
+references to the existing interface are called the ``ioctl()`` implementation in
+this document.
+
+The following sections describe the set of messages that implement the vfio-user
+interface over a socket. In many cases, the messages are analogous to data
+structures used in the ``ioctl()`` implementation. Messages derived from the
+``ioctl()`` will have a name derived from the ``ioctl()`` command name. E.g., the
+``VFIO_DEVICE_GET_INFO`` ``ioctl()`` command becomes a
+``VFIO_USER_DEVICE_GET_INFO`` message. The purpose of this reuse is to share as
+much code as feasible with the ``ioctl()`` implementation``.
+
+Connection Initiation
+^^^^^^^^^^^^^^^^^^^^^
+
+After the client connects to the server, the initial client message is
+``VFIO_USER_VERSION`` to propose a protocol version and set of capabilities to
+apply to the session. The server replies with a compatible version and set of
+capabilities it supports, or closes the connection if it cannot support the
+advertised version.
+
+Device Information
+^^^^^^^^^^^^^^^^^^
+
+The client uses a ``VFIO_USER_DEVICE_GET_INFO`` message to query the server for
+information about the device. This information includes:
+
+* The device type and whether it supports reset (``VFIO_DEVICE_FLAGS_``),
+* the number of device regions, and
+* the device presents to the client the number of interrupt types the device
+ supports.
+
+Region Information
+^^^^^^^^^^^^^^^^^^
+
+The client uses ``VFIO_USER_DEVICE_GET_REGION_INFO`` messages to query the
+server for information about the device's regions. This information describes:
+
+* Read and write permissions, whether it can be memory mapped, and whether it
+ supports additional capabilities (``VFIO_REGION_INFO_CAP_``).
+* Region index, size, and offset.
+
+When a device region can be mapped by the client, the server provides a file
+descriptor which the client can ``mmap()``. The server is responsible for
+polling for client updates to memory mapped regions.
+
+Region Capabilities
+"""""""""""""""""""
+
+Some regions have additional capabilities that cannot be described adequately
+by the region info data structure. These capabilities are returned in the
+region info reply in a list similar to PCI capabilities in a PCI device's
+configuration space.
+
+Sparse Regions
+""""""""""""""
+A region can be memory-mappable in whole or in part. When only a subset of a
+region can be mapped by the client, a ``VFIO_REGION_INFO_CAP_SPARSE_MMAP``
+capability is included in the region info reply. This capability describes
+which portions can be mapped by the client.
+
+.. Note::
+ For example, in a virtual NVMe controller, sparse regions can be used so
+ that accesses to the NVMe registers (found in the beginning of BAR0) are
+ trapped (an infrequent event), while allowing direct access to the doorbells
+ (an extremely frequent event as every I/O submission requires a write to
+ BAR0), found in the next page after the NVMe registers in BAR0.
+
+Device-Specific Regions
+"""""""""""""""""""""""
+
+A device can define regions additional to the standard ones (e.g. PCI indexes
+0-8). This is achieved by including a ``VFIO_REGION_INFO_CAP_TYPE`` capability
+in the region info reply of a device-specific region. Such regions are reflected
+in ``struct vfio_user_device_info.num_regions``. Thus, for PCI devices this
+value can be equal to, or higher than, ``VFIO_PCI_NUM_REGIONS``.
+
+Region I/O via file descriptors
+-------------------------------
+
+For unmapped regions, region I/O from the client is done via
+``VFIO_USER_REGION_READ/WRITE``. As an optimization, ioeventfds or ioregionfds
+may be configured for sub-regions of some regions. A client may request
+information on these sub-regions via ``VFIO_USER_DEVICE_GET_REGION_IO_FDS``; by
+configuring the returned file descriptors as ioeventfds or ioregionfds, the
+server can be directly notified of I/O (for example, by KVM) without taking a
+trip through the client.
+
+Interrupts
+^^^^^^^^^^
+
+The client uses ``VFIO_USER_DEVICE_GET_IRQ_INFO`` messages to query the server
+for the device's interrupt types. The interrupt types are specific to the bus
+the device is attached to, and the client is expected to know the capabilities
+of each interrupt type. The server can signal an interrupt by directly injecting
+interrupts into the guest via an event file descriptor. The client configures
+how the server signals an interrupt with ``VFIO_USER_SET_IRQS`` messages.
+
+Device Read and Write
+^^^^^^^^^^^^^^^^^^^^^
+
+When the guest executes load or store operations to an unmapped device region,
+the client forwards these operations to the server with
+``VFIO_USER_REGION_READ`` or ``VFIO_USER_REGION_WRITE`` messages. The server
+will reply with data from the device on read operations or an acknowledgement on
+write operations. See `Read and Write Operations`_.
+
+Client memory access
+--------------------
+
+The client uses ``VFIO_USER_DMA_MAP`` and ``VFIO_USER_DMA_UNMAP`` messages to
+inform the server of the valid DMA ranges that the server can access on behalf
+of a device (typically, VM guest memory). DMA memory may be accessed by the
+server via ``VFIO_USER_DMA_READ`` and ``VFIO_USER_DMA_WRITE`` messages over the
+socket. In this case, the "DMA" part of the naming is a misnomer.
+
+Actual direct memory access of client memory from the server is possible if the
+client provides file descriptors the server can ``mmap()``. Note that ``mmap()``
+privileges cannot be revoked by the client, therefore file descriptors should
+only be exported in environments where the client trusts the server not to
+corrupt guest memory.
+
+See `Read and Write Operations`_.
+
+Client/server interactions
+==========================
+
+Socket
+------
+
+A server can serve:
+
+1) one or more clients, and/or
+2) one or more virtual devices, belonging to one or more clients.
+
+The current protocol specification requires a dedicated socket per
+client/server connection. It is a server-side implementation detail whether a
+single server handles multiple virtual devices from the same or multiple
+clients. The location of the socket is implementation-specific. Multiplexing
+clients, devices, and servers over the same socket is not supported in this
+version of the protocol.
+
+Authentication
+--------------
+
+For ``AF_UNIX``, we rely on OS mandatory access controls on the socket files,
+therefore it is up to the management layer to set up the socket as required.
+Socket types that span guests or hosts will require a proper authentication
+mechanism. Defining that mechanism is deferred to a future version of the
+protocol.
+
+Command Concurrency
+-------------------
+
+A client may pipeline multiple commands without waiting for previous command
+replies. The server will process commands in the order they are received. A
+consequence of this is if a client issues a command with the *No_reply* bit,
+then subsequently issues a command without *No_reply*, the older command will
+have been processed before the reply to the younger command is sent by the
+server. The client must be aware of the device's capability to process
+concurrent commands if pipelining is used. For example, pipelining allows
+multiple client threads to concurrently access device regions; the client must
+ensure these accesses obey device semantics.
+
+An example is a frame buffer device, where the device may allow concurrent
+access to different areas of video memory, but may have indeterminate behavior
+if concurrent accesses are performed to command or status registers.
+
+Note that unrelated messages sent from the server to the client can appear in
+between a client to server request/reply and vice versa.
+
+Implementers should be prepared for certain commands to exhibit potentially
+unbounded latencies. For example, ``VFIO_USER_DEVICE_RESET`` may take an
+arbitrarily long time to complete; clients should take care not to block
+unnecessarily.
+
+Socket Disconnection Behavior
+-----------------------------
+The server and the client can disconnect from each other, either intentionally
+or unexpectedly. Both the client and the server need to know how to handle such
+events.
+
+Server Disconnection
+^^^^^^^^^^^^^^^^^^^^
+A server disconnecting from the client may indicate that:
+
+1) A virtual device has been restarted, either intentionally (e.g. because of a
+ device update) or unintentionally (e.g. because of a crash).
+2) A virtual device has been shut down with no intention to be restarted.
+
+It is impossible for the client to know whether or not a failure is
+intermittent or innocuous and should be retried, therefore the client should
+reset the VFIO device when it detects the socket has been disconnected.
+Error recovery will be driven by the guest's device error handling
+behavior.
+
+Client Disconnection
+^^^^^^^^^^^^^^^^^^^^
+The client disconnecting from the server primarily means that the client
+has exited. Currently, this means that the guest is shut down so the device is
+no longer needed therefore the server can automatically exit. However, there
+can be cases where a client disconnection should not result in a server exit:
+
+1) A single server serving multiple clients.
+2) A multi-process QEMU upgrading itself step by step, which is not yet
+ implemented.
+
+Therefore in order for the protocol to be forward compatible, the server should
+respond to a client disconnection as follows:
+
+ - all client memory regions are unmapped and cleaned up (including closing any
+ passed file descriptors)
+ - all IRQ file descriptors passed from the old client are closed
+ - the device state should otherwise be retained
+
+The expectation is that when a client reconnects, it will re-establish IRQ and
+client memory mappings.
+
+If anything happens to the client (such as qemu really did exit), the control
+stack will know about it and can clean up resources accordingly.
+
+Security Considerations
+-----------------------
+
+Speaking generally, vfio-user clients should not trust servers, and vice versa.
+Standard tools and mechanisms should be used on both sides to validate input and
+prevent against denial of service scenarios, buffer overflow, etc.
+
+Request Retry and Response Timeout
+----------------------------------
+A failed command is a command that has been successfully sent and has been
+responded to with an error code. Failure to send the command in the first place
+(e.g. because the socket is disconnected) is a different type of error examined
+earlier in the disconnect section.
+
+.. Note::
+ QEMU's VFIO retries certain operations if they fail. While this makes sense
+ for real HW, we don't know for sure whether it makes sense for virtual
+ devices.
+
+Defining a retry and timeout scheme is deferred to a future version of the
+protocol.
+
+Message sizes
+-------------
+
+Some requests have an ``argsz`` field. In a request, it defines the maximum
+expected reply payload size, which should be at least the size of the fixed
+reply payload headers defined here. The *request* payload size is defined by the
+usual ``msg_size`` field in the header, not the ``argsz`` field.
+
+In a reply, the server sets ``argsz`` field to the size needed for a full
+payload size. This may be less than the requested maximum size. This may be
+larger than the requested maximum size: in that case, the full payload is not
+included in the reply, but the ``argsz`` field in the reply indicates the needed
+size, allowing a client to allocate a larger buffer for holding the reply before
+trying again.
+
+In addition, during negotiation (see `Version`_), the client and server may
+each specify a ``max_data_xfer_size`` value; this defines the maximum data that
+may be read or written via one of the ``VFIO_USER_DMA/REGION_READ/WRITE``
+messages; see `Read and Write Operations`_.
+
+Protocol Specification
+======================
+
+To distinguish from the base VFIO symbols, all vfio-user symbols are prefixed
+with ``vfio_user`` or ``VFIO_USER``. In this revision, all data is in the
+endianness of the host system, although this may be relaxed in future
+revisions in cases where the client and server run on different hosts
+with different endianness.
+
+Unless otherwise specified, all sizes should be presumed to be in bytes.
+
+.. _Commands:
+
+Commands
+--------
+The following table lists the VFIO message command IDs, and whether the
+message command is sent from the client or the server.
+
+====================================== ========= =================
+Name Command Request Direction
+====================================== ========= =================
+``VFIO_USER_VERSION`` 1 client -> server
+``VFIO_USER_DMA_MAP`` 2 client -> server
+``VFIO_USER_DMA_UNMAP`` 3 client -> server
+``VFIO_USER_DEVICE_GET_INFO`` 4 client -> server
+``VFIO_USER_DEVICE_GET_REGION_INFO`` 5 client -> server
+``VFIO_USER_DEVICE_GET_REGION_IO_FDS`` 6 client -> server
+``VFIO_USER_DEVICE_GET_IRQ_INFO`` 7 client -> server
+``VFIO_USER_DEVICE_SET_IRQS`` 8 client -> server
+``VFIO_USER_REGION_READ`` 9 client -> server
+``VFIO_USER_REGION_WRITE`` 10 client -> server
+``VFIO_USER_DMA_READ`` 11 server -> client
+``VFIO_USER_DMA_WRITE`` 12 server -> client
+``VFIO_USER_DEVICE_RESET`` 13 client -> server
+``VFIO_USER_REGION_WRITE_MULTI`` 15 client -> server
+====================================== ========= =================
+
+Header
+------
+
+All messages, both command messages and reply messages, are preceded by a
+16-byte header that contains basic information about the message. The header is
+followed by message-specific data described in the sections below.
+
++----------------+--------+-------------+
+| Name | Offset | Size |
++================+========+=============+
+| Message ID | 0 | 2 |
++----------------+--------+-------------+
+| Command | 2 | 2 |
++----------------+--------+-------------+
+| Message size | 4 | 4 |
++----------------+--------+-------------+
+| Flags | 8 | 4 |
++----------------+--------+-------------+
+| | +-----+------------+ |
+| | | Bit | Definition | |
+| | +=====+============+ |
+| | | 0-3 | Type | |
+| | +-----+------------+ |
+| | | 4 | No_reply | |
+| | +-----+------------+ |
+| | | 5 | Error | |
+| | +-----+------------+ |
++----------------+--------+-------------+
+| Error | 12 | 4 |
++----------------+--------+-------------+
+| <message data> | 16 | variable |
++----------------+--------+-------------+
+
+* *Message ID* identifies the message, and is echoed in the command's reply
+ message. Message IDs belong entirely to the sender, can be re-used (even
+ concurrently) and the receiver must not make any assumptions about their
+ uniqueness.
+* *Command* specifies the command to be executed, listed in Commands_. It is
+ also set in the reply header.
+* *Message size* contains the size of the entire message, including the header.
+* *Flags* contains attributes of the message:
+
+ * The *Type* bits indicate the message type.
+
+ * *Command* (value 0x0) indicates a command message.
+ * *Reply* (value 0x1) indicates a reply message acknowledging a previous
+ command with the same message ID.
+ * *No_reply* in a command message indicates that no reply is needed for this
+ command. This is commonly used when multiple commands are sent, and only
+ the last needs acknowledgement.
+ * *Error* in a reply message indicates the command being acknowledged had
+ an error. In this case, the *Error* field will be valid.
+
+* *Error* in a reply message is an optional UNIX errno value. It may be zero
+ even if the Error bit is set in Flags. It is reserved in a command message.
+
+Each command message in Commands_ must be replied to with a reply message,
+unless the message sets the *No_Reply* bit. The reply consists of the header
+with the *Reply* bit set, plus any additional data.
+
+If an error occurs, the reply message must only include the reply header.
+
+As the header is standard in both requests and replies, it is not included in
+the command-specific specifications below; each message definition should be
+appended to the standard header, and the offsets are given from the end of the
+standard header.
+
+``VFIO_USER_VERSION``
+---------------------
+
+.. _Version:
+
+This is the initial message sent by the client after the socket connection is
+established; the same format is used for the server's reply.
+
+Upon establishing a connection, the client must send a ``VFIO_USER_VERSION``
+message proposing a protocol version and a set of capabilities. The server
+compares these with the versions and capabilities it supports and sends a
+``VFIO_USER_VERSION`` reply according to the following rules.
+
+* The major version in the reply must be the same as proposed. If the client
+ does not support the proposed major, it closes the connection.
+* The minor version in the reply must be equal to or less than the minor
+ version proposed.
+* The capability list must be a subset of those proposed. If the server
+ requires a capability the client did not include, it closes the connection.
+
+The protocol major version will only change when incompatible protocol changes
+are made, such as changing the message format. The minor version may change
+when compatible changes are made, such as adding new messages or capabilities,
+Both the client and server must support all minor versions less than the
+maximum minor version it supports. E.g., an implementation that supports
+version 1.3 must also support 1.0 through 1.2.
+
+When making a change to this specification, the protocol version number must
+be included in the form "added in version X.Y"
+
+Request
+^^^^^^^
+
+============== ====== ====
+Name Offset Size
+============== ====== ====
+version major 0 2
+version minor 2 2
+version data 4 variable (including terminating NUL). Optional.
+============== ====== ====
+
+The version data is an optional UTF-8 encoded JSON byte array with the following
+format:
+
++--------------+--------+-----------------------------------+
+| Name | Type | Description |
++==============+========+===================================+
+| capabilities | object | Contains common capabilities that |
+| | | the sender supports. Optional. |
++--------------+--------+-----------------------------------+
+
+Capabilities:
+
++--------------------+---------+------------------------------------------------+
+| Name | Type | Description |
++====================+=========+================================================+
+| max_msg_fds | number | Maximum number of file descriptors that can be |
+| | | received by the sender in one message. |
+| | | Optional. If not specified then the receiver |
+| | | must assume a value of ``1``. |
++--------------------+---------+------------------------------------------------+
+| max_data_xfer_size | number | Maximum ``count`` for data transfer messages; |
+| | | see `Read and Write Operations`_. Optional, |
+| | | with a default value of 1048576 bytes. |
++--------------------+---------+------------------------------------------------+
+| pgsizes | number | Page sizes supported in DMA map operations |
+| | | or'ed together. Optional, with a default value |
+| | | of supporting only 4k pages. |
++--------------------+---------+------------------------------------------------+
+| max_dma_maps | number | Maximum number DMA map windows that can be |
+| | | valid simultaneously. Optional, with a |
+| | | value of 65535 (64k-1). |
++--------------------+---------+------------------------------------------------+
+| migration | object | Migration capability parameters. If missing |
+| | | then migration is not supported by the sender. |
++--------------------+---------+------------------------------------------------+
+| write_multiple | boolean | ``VFIO_USER_REGION_WRITE_MULTI`` messages |
+| | | are supported if the value is ``true``. |
++--------------------+---------+------------------------------------------------+
+
+The migration capability contains the following name/value pairs:
+
++-----------------+--------+--------------------------------------------------+
+| Name | Type | Description |
++=================+========+==================================================+
+| pgsize | number | Page size of dirty pages bitmap. The smallest |
+| | | between the client and the server is used. |
++-----------------+--------+--------------------------------------------------+
+| max_bitmap_size | number | Maximum bitmap size in ``VFIO_USER_DIRTY_PAGES`` |
+| | | and ``VFIO_DMA_UNMAP`` messages. Optional, |
+| | | with a default value of 256MB. |
++-----------------+--------+--------------------------------------------------+
+
+Reply
+^^^^^
+
+The same message format is used in the server's reply with the semantics
+described above.
+
+``VFIO_USER_DMA_MAP``
+---------------------
+
+This command message is sent by the client to the server to inform it of the
+memory regions the server can access. It must be sent before the server can
+perform any DMA to the client. It is normally sent directly after the version
+handshake is completed, but may also occur when memory is added to the client,
+or if the client uses a vIOMMU.
+
+Request
+^^^^^^^
+
+The request payload for this message is a structure of the following format:
+
++-------------+--------+-------------+
+| Name | Offset | Size |
++=============+========+=============+
+| argsz | 0 | 4 |
++-------------+--------+-------------+
+| flags | 4 | 4 |
++-------------+--------+-------------+
+| | +-----+------------+ |
+| | | Bit | Definition | |
+| | +=====+============+ |
+| | | 0 | readable | |
+| | +-----+------------+ |
+| | | 1 | writeable | |
+| | +-----+------------+ |
++-------------+--------+-------------+
+| offset | 8 | 8 |
++-------------+--------+-------------+
+| address | 16 | 8 |
++-------------+--------+-------------+
+| size | 24 | 8 |
++-------------+--------+-------------+
+
+* *argsz* is the size of the above structure. Note there is no reply payload,
+ so this field differs from other message types.
+* *flags* contains the following region attributes:
+
+ * *readable* indicates that the region can be read from.
+
+ * *writeable* indicates that the region can be written to.
+
+* *offset* is the file offset of the region with respect to the associated file
+ descriptor, or zero if the region is not mappable
+* *address* is the base DMA address of the region.
+* *size* is the size of the region.
+
+This structure is 32 bytes in size, so the message size is 16 + 32 bytes.
+
+If the DMA region being added can be directly mapped by the server, a file
+descriptor must be sent as part of the message meta-data. The region can be
+mapped via the mmap() system call. On ``AF_UNIX`` sockets, the file descriptor
+must be passed as ``SCM_RIGHTS`` type ancillary data. Otherwise, if the DMA
+region cannot be directly mapped by the server, no file descriptor must be sent
+as part of the message meta-data and the DMA region can be accessed by the
+server using ``VFIO_USER_DMA_READ`` and ``VFIO_USER_DMA_WRITE`` messages,
+explained in `Read and Write Operations`_. A command to map over an existing
+region must be failed by the server with ``EEXIST`` set in error field in the
+reply.
+
+Reply
+^^^^^
+
+There is no payload in the reply message.
+
+``VFIO_USER_DMA_UNMAP``
+-----------------------
+
+This command message is sent by the client to the server to inform it that a
+DMA region, previously made available via a ``VFIO_USER_DMA_MAP`` command
+message, is no longer available for DMA. It typically occurs when memory is
+subtracted from the client or if the client uses a vIOMMU. The DMA region is
+described by the following structure:
+
+Request
+^^^^^^^
+
+The request payload for this message is a structure of the following format:
+
++--------------+--------+------------------------+
+| Name | Offset | Size |
++==============+========+========================+
+| argsz | 0 | 4 |
++--------------+--------+------------------------+
+| flags | 4 | 4 |
++--------------+--------+------------------------+
+| address | 8 | 8 |
++--------------+--------+------------------------+
+| size | 16 | 8 |
++--------------+--------+------------------------+
+
+* *argsz* is the maximum size of the reply payload.
+* *flags* is unused in this version.
+* *address* is the base DMA address of the DMA region.
+* *size* is the size of the DMA region.
+
+The address and size of the DMA region being unmapped must match exactly a
+previous mapping.
+
+Reply
+^^^^^
+
+Upon receiving a ``VFIO_USER_DMA_UNMAP`` command, if the file descriptor is
+mapped then the server must release all references to that DMA region before
+replying, which potentially includes in-flight DMA transactions.
+
+The server responds with the original DMA entry in the request.
+
+
+``VFIO_USER_DEVICE_GET_INFO``
+-----------------------------
+
+This command message is sent by the client to the server to query for basic
+information about the device.
+
+Request
+^^^^^^^
+
++-------------+--------+--------------------------+
+| Name | Offset | Size |
++=============+========+==========================+
+| argsz | 0 | 4 |
++-------------+--------+--------------------------+
+| flags | 4 | 4 |
++-------------+--------+--------------------------+
+| | +-----+-------------------------+ |
+| | | Bit | Definition | |
+| | +=====+=========================+ |
+| | | 0 | VFIO_DEVICE_FLAGS_RESET | |
+| | +-----+-------------------------+ |
+| | | 1 | VFIO_DEVICE_FLAGS_PCI | |
+| | +-----+-------------------------+ |
++-------------+--------+--------------------------+
+| num_regions | 8 | 4 |
++-------------+--------+--------------------------+
+| num_irqs | 12 | 4 |
++-------------+--------+--------------------------+
+
+* *argsz* is the maximum size of the reply payload
+* all other fields must be zero.
+
+Reply
+^^^^^
+
++-------------+--------+--------------------------+
+| Name | Offset | Size |
++=============+========+==========================+
+| argsz | 0 | 4 |
++-------------+--------+--------------------------+
+| flags | 4 | 4 |
++-------------+--------+--------------------------+
+| | +-----+-------------------------+ |
+| | | Bit | Definition | |
+| | +=====+=========================+ |
+| | | 0 | VFIO_DEVICE_FLAGS_RESET | |
+| | +-----+-------------------------+ |
+| | | 1 | VFIO_DEVICE_FLAGS_PCI | |
+| | +-----+-------------------------+ |
++-------------+--------+--------------------------+
+| num_regions | 8 | 4 |
++-------------+--------+--------------------------+
+| num_irqs | 12 | 4 |
++-------------+--------+--------------------------+
+
+* *argsz* is the size required for the full reply payload (16 bytes today)
+* *flags* contains the following device attributes.
+
+ * ``VFIO_DEVICE_FLAGS_RESET`` indicates that the device supports the
+ ``VFIO_USER_DEVICE_RESET`` message.
+ * ``VFIO_DEVICE_FLAGS_PCI`` indicates that the device is a PCI device.
+
+* *num_regions* is the number of memory regions that the device exposes.
+* *num_irqs* is the number of distinct interrupt types that the device supports.
+
+This version of the protocol only supports PCI devices. Additional devices may
+be supported in future versions.
+
+``VFIO_USER_DEVICE_GET_REGION_INFO``
+------------------------------------
+
+This command message is sent by the client to the server to query for
+information about device regions. The VFIO region info structure is defined in
+``<linux/vfio.h>`` (``struct vfio_region_info``).
+
+Request
+^^^^^^^
+
++------------+--------+------------------------------+
+| Name | Offset | Size |
++============+========+==============================+
+| argsz | 0 | 4 |
++------------+--------+------------------------------+
+| flags | 4 | 4 |
++------------+--------+------------------------------+
+| index | 8 | 4 |
++------------+--------+------------------------------+
+| cap_offset | 12 | 4 |
++------------+--------+------------------------------+
+| size | 16 | 8 |
++------------+--------+------------------------------+
+| offset | 24 | 8 |
++------------+--------+------------------------------+
+
+* *argsz* the maximum size of the reply payload
+* *index* is the index of memory region being queried, it is the only field
+ that is required to be set in the command message.
+* all other fields must be zero.
+
+Reply
+^^^^^
+
++------------+--------+------------------------------+
+| Name | Offset | Size |
++============+========+==============================+
+| argsz | 0 | 4 |
++------------+--------+------------------------------+
+| flags | 4 | 4 |
++------------+--------+------------------------------+
+| | +-----+-----------------------------+ |
+| | | Bit | Definition | |
+| | +=====+=============================+ |
+| | | 0 | VFIO_REGION_INFO_FLAG_READ | |
+| | +-----+-----------------------------+ |
+| | | 1 | VFIO_REGION_INFO_FLAG_WRITE | |
+| | +-----+-----------------------------+ |
+| | | 2 | VFIO_REGION_INFO_FLAG_MMAP | |
+| | +-----+-----------------------------+ |
+| | | 3 | VFIO_REGION_INFO_FLAG_CAPS | |
+| | +-----+-----------------------------+ |
++------------+--------+------------------------------+
++------------+--------+------------------------------+
+| index | 8 | 4 |
++------------+--------+------------------------------+
+| cap_offset | 12 | 4 |
++------------+--------+------------------------------+
+| size | 16 | 8 |
++------------+--------+------------------------------+
+| offset | 24 | 8 |
++------------+--------+------------------------------+
+
+* *argsz* is the size required for the full reply payload (region info structure
+ plus the size of any region capabilities)
+* *flags* are attributes of the region:
+
+ * ``VFIO_REGION_INFO_FLAG_READ`` allows client read access to the region.
+ * ``VFIO_REGION_INFO_FLAG_WRITE`` allows client write access to the region.
+ * ``VFIO_REGION_INFO_FLAG_MMAP`` specifies the client can mmap() the region.
+ When this flag is set, the reply will include a file descriptor in its
+ meta-data. On ``AF_UNIX`` sockets, the file descriptors will be passed as
+ ``SCM_RIGHTS`` type ancillary data.
+ * ``VFIO_REGION_INFO_FLAG_CAPS`` indicates additional capabilities found in the
+ reply.
+
+* *index* is the index of memory region being queried, it is the only field
+ that is required to be set in the command message.
+* *cap_offset* describes where additional region capabilities can be found.
+ cap_offset is relative to the beginning of the VFIO region info structure.
+ The data structure it points is a VFIO cap header defined in
+ ``<linux/vfio.h>``.
+* *size* is the size of the region.
+* *offset* is the offset that should be given to the mmap() system call for
+ regions with the MMAP attribute. It is also used as the base offset when
+ mapping a VFIO sparse mmap area, described below.
+
+VFIO region capabilities
+""""""""""""""""""""""""
+
+The VFIO region information can also include a capabilities list. This list is
+similar to a PCI capability list - each entry has a common header that
+identifies a capability and where the next capability in the list can be found.
+The VFIO capability header format is defined in ``<linux/vfio.h>`` (``struct
+vfio_info_cap_header``).
+
+VFIO cap header format
+""""""""""""""""""""""
+
++---------+--------+------+
+| Name | Offset | Size |
++=========+========+======+
+| id | 0 | 2 |
++---------+--------+------+
+| version | 2 | 2 |
++---------+--------+------+
+| next | 4 | 4 |
++---------+--------+------+
+
+* *id* is the capability identity.
+* *version* is a capability-specific version number.
+* *next* specifies the offset of the next capability in the capability list. It
+ is relative to the beginning of the VFIO region info structure.
+
+VFIO sparse mmap cap header
+"""""""""""""""""""""""""""
+
++------------------+----------------------------------+
+| Name | Value |
++==================+==================================+
+| id | VFIO_REGION_INFO_CAP_SPARSE_MMAP |
++------------------+----------------------------------+
+| version | 0x1 |
++------------------+----------------------------------+
+| next | <next> |
++------------------+----------------------------------+
+| sparse mmap info | VFIO region info sparse mmap |
++------------------+----------------------------------+
+
+This capability is defined when only a subrange of the region supports
+direct access by the client via mmap(). The VFIO sparse mmap area is defined in
+``<linux/vfio.h>`` (``struct vfio_region_sparse_mmap_area`` and ``struct
+vfio_region_info_cap_sparse_mmap``).
+
+VFIO region info cap sparse mmap
+""""""""""""""""""""""""""""""""
+
++----------+--------+------+
+| Name | Offset | Size |
++==========+========+======+
+| nr_areas | 0 | 4 |
++----------+--------+------+
+| reserved | 4 | 4 |
++----------+--------+------+
+| offset | 8 | 8 |
++----------+--------+------+
+| size | 16 | 8 |
++----------+--------+------+
+| ... | | |
++----------+--------+------+
+
+* *nr_areas* is the number of sparse mmap areas in the region.
+* *offset* and size describe a single area that can be mapped by the client.
+ There will be *nr_areas* pairs of offset and size. The offset will be added to
+ the base offset given in the ``VFIO_USER_DEVICE_GET_REGION_INFO`` to form the
+ offset argument of the subsequent mmap() call.
+
+The VFIO sparse mmap area is defined in ``<linux/vfio.h>`` (``struct
+vfio_region_info_cap_sparse_mmap``).
+
+
+``VFIO_USER_DEVICE_GET_REGION_IO_FDS``
+--------------------------------------
+
+Clients can access regions via ``VFIO_USER_REGION_READ/WRITE`` or, if provided, by
+``mmap()`` of a file descriptor provided by the server.
+
+``VFIO_USER_DEVICE_GET_REGION_IO_FDS`` provides an alternative access mechanism via
+file descriptors. This is an optional feature intended for performance
+improvements where an underlying sub-system (such as KVM) supports communication
+across such file descriptors to the vfio-user server, without needing to
+round-trip through the client.
+
+The server returns an array of sub-regions for the requested region. Each
+sub-region describes a span (offset and size) of a region, along with the
+requested file descriptor notification mechanism to use. Each sub-region in the
+response message may choose to use a different method, as defined below. The
+two mechanisms supported in this specification are ioeventfds and ioregionfds.
+
+The server in addition returns a file descriptor in the ancillary data; clients
+are expected to configure each sub-region's file descriptor with the requested
+notification method. For example, a client could configure KVM with the
+requested ioeventfd via a ``KVM_IOEVENTFD`` ``ioctl()``.
+
+Request
+^^^^^^^
+
++-------------+--------+------+
+| Name | Offset | Size |
++=============+========+======+
+| argsz | 0 | 4 |
++-------------+--------+------+
+| flags | 4 | 4 |
++-------------+--------+------+
+| index | 8 | 4 |
++-------------+--------+------+
+| count | 12 | 4 |
++-------------+--------+------+
+
+* *argsz* the maximum size of the reply payload
+* *index* is the index of memory region being queried
+* all other fields must be zero
+
+The client must set ``flags`` to zero and specify the region being queried in
+the ``index``.
+
+Reply
+^^^^^
+
++-------------+--------+------+
+| Name | Offset | Size |
++=============+========+======+
+| argsz | 0 | 4 |
++-------------+--------+------+
+| flags | 4 | 4 |
++-------------+--------+------+
+| index | 8 | 4 |
++-------------+--------+------+
+| count | 12 | 4 |
++-------------+--------+------+
+| sub-regions | 16 | ... |
++-------------+--------+------+
+
+* *argsz* is the size of the region IO FD info structure plus the
+ total size of the sub-region array. Thus, each array entry "i" is at offset
+ i * ((argsz - 32) / count). Note that currently this is 40 bytes for both IO
+ FD types, but this is not to be relied on. As elsewhere, this indicates the
+ full reply payload size needed.
+* *flags* must be zero
+* *index* is the index of memory region being queried
+* *count* is the number of sub-regions in the array
+* *sub-regions* is the array of Sub-Region IO FD info structures
+
+The reply message will additionally include at least one file descriptor in the
+ancillary data. Note that more than one sub-region may share the same file
+descriptor.
+
+Note that it is the client's responsibility to verify the requested values (for
+example, that the requested offset does not exceed the region's bounds).
+
+Each sub-region given in the response has one of two possible structures,
+depending whether *type* is ``VFIO_USER_IO_FD_TYPE_IOEVENTFD`` or
+``VFIO_USER_IO_FD_TYPE_IOREGIONFD``:
+
+Sub-Region IO FD info format (ioeventfd)
+""""""""""""""""""""""""""""""""""""""""
+
++-----------+--------+------+
+| Name | Offset | Size |
++===========+========+======+
+| offset | 0 | 8 |
++-----------+--------+------+
+| size | 8 | 8 |
++-----------+--------+------+
+| fd_index | 16 | 4 |
++-----------+--------+------+
+| type | 20 | 4 |
++-----------+--------+------+
+| flags | 24 | 4 |
++-----------+--------+------+
+| padding | 28 | 4 |
++-----------+--------+------+
+| datamatch | 32 | 8 |
++-----------+--------+------+
+
+* *offset* is the offset of the start of the sub-region within the region
+ requested ("physical address offset" for the region)
+* *size* is the length of the sub-region. This may be zero if the access size is
+ not relevant, which may allow for optimizations
+* *fd_index* is the index in the ancillary data of the FD to use for ioeventfd
+ notification; it may be shared.
+* *type* is ``VFIO_USER_IO_FD_TYPE_IOEVENTFD``
+* *flags* is any of:
+
+ * ``KVM_IOEVENTFD_FLAG_DATAMATCH``
+ * ``KVM_IOEVENTFD_FLAG_PIO``
+ * ``KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY`` (FIXME: makes sense?)
+
+* *datamatch* is the datamatch value if needed
+
+See https://www.kernel.org/doc/Documentation/virtual/kvm/api.txt, *4.59
+KVM_IOEVENTFD* for further context on the ioeventfd-specific fields.
+
+Sub-Region IO FD info format (ioregionfd)
+"""""""""""""""""""""""""""""""""""""""""
+
++-----------+--------+------+
+| Name | Offset | Size |
++===========+========+======+
+| offset | 0 | 8 |
++-----------+--------+------+
+| size | 8 | 8 |
++-----------+--------+------+
+| fd_index | 16 | 4 |
++-----------+--------+------+
+| type | 20 | 4 |
++-----------+--------+------+
+| flags | 24 | 4 |
++-----------+--------+------+
+| padding | 28 | 4 |
++-----------+--------+------+
+| user_data | 32 | 8 |
++-----------+--------+------+
+
+* *offset* is the offset of the start of the sub-region within the region
+ requested ("physical address offset" for the region)
+* *size* is the length of the sub-region. This may be zero if the access size is
+ not relevant, which may allow for optimizations; ``KVM_IOREGION_POSTED_WRITES``
+ must be set in *flags* in this case
+* *fd_index* is the index in the ancillary data of the FD to use for ioregionfd
+ messages; it may be shared
+* *type* is ``VFIO_USER_IO_FD_TYPE_IOREGIONFD``
+* *flags* is any of:
+
+ * ``KVM_IOREGION_PIO``
+ * ``KVM_IOREGION_POSTED_WRITES``
+
+* *user_data* is an opaque value passed back to the server via a message on the
+ file descriptor
+
+For further information on the ioregionfd-specific fields, see:
+https://lore.kernel.org/kvm/cover.1613828726.git.eafanasova@gmail.com/
+
+(FIXME: update with final API docs.)
+
+``VFIO_USER_DEVICE_GET_IRQ_INFO``
+---------------------------------
+
+This command message is sent by the client to the server to query for
+information about device interrupt types. The VFIO IRQ info structure is
+defined in ``<linux/vfio.h>`` (``struct vfio_irq_info``).
+
+Request
+^^^^^^^
+
++-------+--------+---------------------------+
+| Name | Offset | Size |
++=======+========+===========================+
+| argsz | 0 | 4 |
++-------+--------+---------------------------+
+| flags | 4 | 4 |
++-------+--------+---------------------------+
+| | +-----+--------------------------+ |
+| | | Bit | Definition | |
+| | +=====+==========================+ |
+| | | 0 | VFIO_IRQ_INFO_EVENTFD | |
+| | +-----+--------------------------+ |
+| | | 1 | VFIO_IRQ_INFO_MASKABLE | |
+| | +-----+--------------------------+ |
+| | | 2 | VFIO_IRQ_INFO_AUTOMASKED | |
+| | +-----+--------------------------+ |
+| | | 3 | VFIO_IRQ_INFO_NORESIZE | |
+| | +-----+--------------------------+ |
++-------+--------+---------------------------+
+| index | 8 | 4 |
++-------+--------+---------------------------+
+| count | 12 | 4 |
++-------+--------+---------------------------+
+
+* *argsz* is the maximum size of the reply payload (16 bytes today)
+* index is the index of IRQ type being queried (e.g. ``VFIO_PCI_MSIX_IRQ_INDEX``)
+* all other fields must be zero
+
+Reply
+^^^^^
+
++-------+--------+---------------------------+
+| Name | Offset | Size |
++=======+========+===========================+
+| argsz | 0 | 4 |
++-------+--------+---------------------------+
+| flags | 4 | 4 |
++-------+--------+---------------------------+
+| | +-----+--------------------------+ |
+| | | Bit | Definition | |
+| | +=====+==========================+ |
+| | | 0 | VFIO_IRQ_INFO_EVENTFD | |
+| | +-----+--------------------------+ |
+| | | 1 | VFIO_IRQ_INFO_MASKABLE | |
+| | +-----+--------------------------+ |
+| | | 2 | VFIO_IRQ_INFO_AUTOMASKED | |
+| | +-----+--------------------------+ |
+| | | 3 | VFIO_IRQ_INFO_NORESIZE | |
+| | +-----+--------------------------+ |
++-------+--------+---------------------------+
+| index | 8 | 4 |
++-------+--------+---------------------------+
+| count | 12 | 4 |
++-------+--------+---------------------------+
+
+* *argsz* is the size required for the full reply payload (16 bytes today)
+* *flags* defines IRQ attributes:
+
+ * ``VFIO_IRQ_INFO_EVENTFD`` indicates the IRQ type can support server eventfd
+ signalling.
+ * ``VFIO_IRQ_INFO_MASKABLE`` indicates that the IRQ type supports the ``MASK``
+ and ``UNMASK`` actions in a ``VFIO_USER_DEVICE_SET_IRQS`` message.
+ * ``VFIO_IRQ_INFO_AUTOMASKED`` indicates the IRQ type masks itself after being
+ triggered, and the client must send an ``UNMASK`` action to receive new
+ interrupts.
+ * ``VFIO_IRQ_INFO_NORESIZE`` indicates ``VFIO_USER_SET_IRQS`` operations setup
+ interrupts as a set, and new sub-indexes cannot be enabled without disabling
+ the entire type.
+* index is the index of IRQ type being queried
+* count describes the number of interrupts of the queried type.
+
+``VFIO_USER_DEVICE_SET_IRQS``
+-----------------------------
+
+This command message is sent by the client to the server to set actions for
+device interrupt types. The VFIO IRQ set structure is defined in
+``<linux/vfio.h>`` (``struct vfio_irq_set``).
+
+Request
+^^^^^^^
+
++-------+--------+------------------------------+
+| Name | Offset | Size |
++=======+========+==============================+
+| argsz | 0 | 4 |
++-------+--------+------------------------------+
+| flags | 4 | 4 |
++-------+--------+------------------------------+
+| | +-----+-----------------------------+ |
+| | | Bit | Definition | |
+| | +=====+=============================+ |
+| | | 0 | VFIO_IRQ_SET_DATA_NONE | |
+| | +-----+-----------------------------+ |
+| | | 1 | VFIO_IRQ_SET_DATA_BOOL | |
+| | +-----+-----------------------------+ |
+| | | 2 | VFIO_IRQ_SET_DATA_EVENTFD | |
+| | +-----+-----------------------------+ |
+| | | 3 | VFIO_IRQ_SET_ACTION_MASK | |
+| | +-----+-----------------------------+ |
+| | | 4 | VFIO_IRQ_SET_ACTION_UNMASK | |
+| | +-----+-----------------------------+ |
+| | | 5 | VFIO_IRQ_SET_ACTION_TRIGGER | |
+| | +-----+-----------------------------+ |
++-------+--------+------------------------------+
+| index | 8 | 4 |
++-------+--------+------------------------------+
+| start | 12 | 4 |
++-------+--------+------------------------------+
+| count | 16 | 4 |
++-------+--------+------------------------------+
+| data | 20 | variable |
++-------+--------+------------------------------+
+
+* *argsz* is the size of the VFIO IRQ set request payload, including any *data*
+ field. Note there is no reply payload, so this field differs from other
+ message types.
+* *flags* defines the action performed on the interrupt range. The ``DATA``
+ flags describe the data field sent in the message; the ``ACTION`` flags
+ describe the action to be performed. The flags are mutually exclusive for
+ both sets.
+
+ * ``VFIO_IRQ_SET_DATA_NONE`` indicates there is no data field in the command.
+ The action is performed unconditionally.
+ * ``VFIO_IRQ_SET_DATA_BOOL`` indicates the data field is an array of boolean
+ bytes. The action is performed if the corresponding boolean is true.
+ * ``VFIO_IRQ_SET_DATA_EVENTFD`` indicates an array of event file descriptors
+ was sent in the message meta-data. These descriptors will be signalled when
+ the action defined by the action flags occurs. In ``AF_UNIX`` sockets, the
+ descriptors are sent as ``SCM_RIGHTS`` type ancillary data.
+ If no file descriptors are provided, this de-assigns the specified
+ previously configured interrupts.
+ * ``VFIO_IRQ_SET_ACTION_MASK`` indicates a masking event. It can be used with
+ ``VFIO_IRQ_SET_DATA_BOOL`` or ``VFIO_IRQ_SET_DATA_NONE`` to mask an interrupt,
+ or with ``VFIO_IRQ_SET_DATA_EVENTFD`` to generate an event when the guest masks
+ the interrupt.
+ * ``VFIO_IRQ_SET_ACTION_UNMASK`` indicates an unmasking event. It can be used
+ with ``VFIO_IRQ_SET_DATA_BOOL`` or ``VFIO_IRQ_SET_DATA_NONE`` to unmask an
+ interrupt, or with ``VFIO_IRQ_SET_DATA_EVENTFD`` to generate an event when the
+ guest unmasks the interrupt.
+ * ``VFIO_IRQ_SET_ACTION_TRIGGER`` indicates a triggering event. It can be used
+ with ``VFIO_IRQ_SET_DATA_BOOL`` or ``VFIO_IRQ_SET_DATA_NONE`` to trigger an
+ interrupt, or with ``VFIO_IRQ_SET_DATA_EVENTFD`` to generate an event when the
+ server triggers the interrupt.
+
+* *index* is the index of IRQ type being setup.
+* *start* is the start of the sub-index being set.
+* *count* describes the number of sub-indexes being set. As a special case, a
+ count (and start) of 0, with data flags of ``VFIO_IRQ_SET_DATA_NONE`` disables
+ all interrupts of the index.
+* *data* is an optional field included when the
+ ``VFIO_IRQ_SET_DATA_BOOL`` flag is present. It contains an array of booleans
+ that specify whether the action is to be performed on the corresponding
+ index. It's used when the action is only performed on a subset of the range
+ specified.
+
+Not all interrupt types support every combination of data and action flags.
+The client must know the capabilities of the device and IRQ index before it
+sends a ``VFIO_USER_DEVICE_SET_IRQ`` message.
+
+In typical operation, a specific IRQ may operate as follows:
+
+1. The client sends a ``VFIO_USER_DEVICE_SET_IRQ`` message with
+ ``flags=(VFIO_IRQ_SET_DATA_EVENTFD|VFIO_IRQ_SET_ACTION_TRIGGER)`` along
+ with an eventfd. This associates the IRQ with a particular eventfd on the
+ server side.
+
+#. The client may send a ``VFIO_USER_DEVICE_SET_IRQ`` message with
+ ``flags=(VFIO_IRQ_SET_DATA_EVENTFD|VFIO_IRQ_SET_ACTION_MASK/UNMASK)`` along
+ with another eventfd. This associates the given eventfd with the
+ mask/unmask state on the server side.
+
+#. The server may trigger the IRQ by writing 1 to the eventfd.
+
+#. The server may mask/unmask an IRQ which will write 1 to the corresponding
+ mask/unmask eventfd, if there is one.
+
+5. A client may trigger a device IRQ itself, by sending a
+ ``VFIO_USER_DEVICE_SET_IRQ`` message with
+ ``flags=(VFIO_IRQ_SET_DATA_NONE/BOOL|VFIO_IRQ_SET_ACTION_TRIGGER)``.
+
+6. A client may mask or unmask the IRQ, by sending a
+ ``VFIO_USER_DEVICE_SET_IRQ`` message with
+ ``flags=(VFIO_IRQ_SET_DATA_NONE/BOOL|VFIO_IRQ_SET_ACTION_MASK/UNMASK)``.
+
+Reply
+^^^^^
+
+There is no payload in the reply.
+
+.. _Read and Write Operations:
+
+Note that all of these operations must be supported by the client and/or server,
+even if the corresponding memory or device region has been shared as mappable.
+
+The ``count`` field must not exceed the value of ``max_data_xfer_size`` of the
+peer, for both reads and writes.
+
+``VFIO_USER_REGION_READ``
+-------------------------
+
+If a device region is not mappable, it's not directly accessible by the client
+via ``mmap()`` of the underlying file descriptor. In this case, a client can
+read from a device region with this message.
+
+Request
+^^^^^^^
+
++--------+--------+----------+
+| Name | Offset | Size |
++========+========+==========+
+| offset | 0 | 8 |
++--------+--------+----------+
+| region | 8 | 4 |
++--------+--------+----------+
+| count | 12 | 4 |
++--------+--------+----------+
+
+* *offset* into the region being accessed.
+* *region* is the index of the region being accessed.
+* *count* is the size of the data to be transferred.
+
+Reply
+^^^^^
+
++--------+--------+----------+
+| Name | Offset | Size |
++========+========+==========+
+| offset | 0 | 8 |
++--------+--------+----------+
+| region | 8 | 4 |
++--------+--------+----------+
+| count | 12 | 4 |
++--------+--------+----------+
+| data | 16 | variable |
++--------+--------+----------+
+
+* *offset* into the region accessed.
+* *region* is the index of the region accessed.
+* *count* is the size of the data transferred.
+* *data* is the data that was read from the device region.
+
+``VFIO_USER_REGION_WRITE``
+--------------------------
+
+If a device region is not mappable, it's not directly accessible by the client
+via mmap() of the underlying fd. In this case, a client can write to a device
+region with this message.
+
+Request
+^^^^^^^
+
++--------+--------+----------+
+| Name | Offset | Size |
++========+========+==========+
+| offset | 0 | 8 |
++--------+--------+----------+
+| region | 8 | 4 |
++--------+--------+----------+
+| count | 12 | 4 |
++--------+--------+----------+
+| data | 16 | variable |
++--------+--------+----------+
+
+* *offset* into the region being accessed.
+* *region* is the index of the region being accessed.
+* *count* is the size of the data to be transferred.
+* *data* is the data to write
+
+Reply
+^^^^^
+
++--------+--------+----------+
+| Name | Offset | Size |
++========+========+==========+
+| offset | 0 | 8 |
++--------+--------+----------+
+| region | 8 | 4 |
++--------+--------+----------+
+| count | 12 | 4 |
++--------+--------+----------+
+
+* *offset* into the region accessed.
+* *region* is the index of the region accessed.
+* *count* is the size of the data transferred.
+
+``VFIO_USER_DMA_READ``
+-----------------------
+
+If the client has not shared mappable memory, the server can use this message to
+read from guest memory.
+
+Request
+^^^^^^^
+
++---------+--------+----------+
+| Name | Offset | Size |
++=========+========+==========+
+| address | 0 | 8 |
++---------+--------+----------+
+| count | 8 | 8 |
++---------+--------+----------+
+
+* *address* is the client DMA memory address being accessed. This address must have
+ been previously exported to the server with a ``VFIO_USER_DMA_MAP`` message.
+* *count* is the size of the data to be transferred.
+
+Reply
+^^^^^
+
++---------+--------+----------+
+| Name | Offset | Size |
++=========+========+==========+
+| address | 0 | 8 |
++---------+--------+----------+
+| count | 8 | 8 |
++---------+--------+----------+
+| data | 16 | variable |
++---------+--------+----------+
+
+* *address* is the client DMA memory address being accessed.
+* *count* is the size of the data transferred.
+* *data* is the data read.
+
+``VFIO_USER_DMA_WRITE``
+-----------------------
+
+If the client has not shared mappable memory, the server can use this message to
+write to guest memory.
+
+Request
+^^^^^^^
+
++---------+--------+----------+
+| Name | Offset | Size |
++=========+========+==========+
+| address | 0 | 8 |
++---------+--------+----------+
+| count | 8 | 8 |
++---------+--------+----------+
+| data | 16 | variable |
++---------+--------+----------+
+
+* *address* is the client DMA memory address being accessed. This address must have
+ been previously exported to the server with a ``VFIO_USER_DMA_MAP`` message.
+* *count* is the size of the data to be transferred.
+* *data* is the data to write
+
+Reply
+^^^^^
+
++---------+--------+----------+
+| Name | Offset | Size |
++=========+========+==========+
+| address | 0 | 8 |
++---------+--------+----------+
+| count | 8 | 4 |
++---------+--------+----------+
+
+* *address* is the client DMA memory address being accessed.
+* *count* is the size of the data transferred.
+
+``VFIO_USER_DEVICE_RESET``
+--------------------------
+
+This command message is sent from the client to the server to reset the device.
+Neither the request or reply have a payload.
+
+``VFIO_USER_REGION_WRITE_MULTI``
+--------------------------------
+
+This message can be used to coalesce multiple device write operations
+into a single messgage. It is only used as an optimization when the
+outgoing message queue is relatively full.
+
+Request
+^^^^^^^
+
++---------+--------+----------+
+| Name | Offset | Size |
++=========+========+==========+
+| wr_cnt | 0 | 8 |
++---------+--------+----------+
+| wrs | 8 | variable |
++---------+--------+----------+
+
+* *wr_cnt* is the number of device writes coalesced in the message
+* *wrs* is an array of device writes defined below
+
+Single Device Write Format
+""""""""""""""""""""""""""
+
++--------+--------+----------+
+| Name | Offset | Size |
++========+========+==========+
+| offset | 0 | 8 |
++--------+--------+----------+
+| region | 8 | 4 |
++--------+--------+----------+
+| count | 12 | 4 |
++--------+--------+----------+
+| data | 16 | 8 |
++--------+--------+----------+
+
+* *offset* into the region being accessed.
+* *region* is the index of the region being accessed.
+* *count* is the size of the data to be transferred. This format can
+ only describe writes of 8 bytes or less.
+* *data* is the data to write.
+
+Reply
+^^^^^
+
++---------+--------+----------+
+| Name | Offset | Size |
++=========+========+==========+
+| wr_cnt | 0 | 8 |
++---------+--------+----------+
+
+* *wr_cnt* is the number of device writes completed.
+
+
+Appendices
+==========
+
+Unused VFIO ``ioctl()`` commands
+--------------------------------
+
+The following VFIO commands do not have an equivalent vfio-user command:
+
+* ``VFIO_GET_API_VERSION``
+* ``VFIO_CHECK_EXTENSION``
+* ``VFIO_SET_IOMMU``
+* ``VFIO_GROUP_GET_STATUS``
+* ``VFIO_GROUP_SET_CONTAINER``
+* ``VFIO_GROUP_UNSET_CONTAINER``
+* ``VFIO_GROUP_GET_DEVICE_FD``
+* ``VFIO_IOMMU_GET_INFO``
+
+However, once support for live migration for VFIO devices is finalized some
+of the above commands may have to be handled by the client in their
+corresponding vfio-user form. This will be addressed in a future protocol
+version.
+
+VFIO groups and containers
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The current VFIO implementation includes group and container idioms that
+describe how a device relates to the host IOMMU. In the vfio-user
+implementation, the IOMMU is implemented in SW by the client, and is not
+visible to the server. The simplest idea would be that the client put each
+device into its own group and container.
+
+Backend Program Conventions
+---------------------------
+
+vfio-user backend program conventions are based on the vhost-user ones.
+
+* The backend program must not daemonize itself.
+* No assumptions must be made as to what access the backend program has on the
+ system.
+* File descriptors 0, 1 and 2 must exist, must have regular
+ stdin/stdout/stderr semantics, and can be redirected.
+* The backend program must honor the SIGTERM signal.
+* The backend program must accept the following commands line options:
+
+ * ``--socket-path=PATH``: path to UNIX domain socket,
+ * ``--fd=FDNUM``: file descriptor for UNIX domain socket, incompatible with
+ ``--socket-path``
+* The backend program must be accompanied with a JSON file stored under
+ ``/usr/share/vfio-user``.
+
+TODO add schema similar to docs/interop/vhost-user.json.
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH v3 05/23] vfio-user: introduce vfio-user protocol specification
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 16:55 ` John Levon
2025-06-11 11:49 ` Cédric Le Goater
1 sibling, 2 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-10 9:38 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 6/7/25 02:10, John Levon wrote:
> From: Thanos Makatos <thanos.makatos@nutanix.com>
>
> This patch introduces the vfio-user protocol specification (formerly
> known as VFIO-over-socket), which is designed to allow devices to be
> emulated outside QEMU, in a separate process. vfio-user reuses the
> existing VFIO defines, structs and concepts.
>
> It has been earlier discussed as an RFC in:
> "RFC: use VFIO over a UNIX domain socket to implement device offloading"
>
> Signed-off-by: Thanos Makatos <thanos.makatos@nutanix.com>
> Signed-off-by: John Levon <john.levon@nutanix.com>
> ---
> MAINTAINERS | 8 +-
> docs/devel/index-internals.rst | 1 +
> docs/devel/vfio-user.rst | 1522 ++++++++++++++++++++++++++++++++
I think this file should be split in several smaller files. The
protocol specification part belongs to "System Emulation Management
and Interoperability" section.
We already have a docs/system/devices/vfio-user.rst which needs some
care. Tbh, this is a bit confusing.
We lack a device example (and functional tests)
> 3 files changed, 1530 insertions(+), 1 deletion(-)
> create mode 100644 docs/devel/vfio-user.rst> diff --git a/MAINTAINERS b/MAINTAINERS
> index aa6763077e..dbc393989a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4241,13 +4241,19 @@ F: hw/remote/proxy-memory-listener.c
> F: include/hw/remote/proxy-memory-listener.h
> F: hw/remote/iohub.c
> F: include/hw/remote/iohub.h
> -F: subprojects/libvfio-user
> F: hw/remote/vfio-user-obj.c
> F: include/hw/remote/vfio-user-obj.h
> F: hw/remote/iommu.c
> F: include/hw/remote/iommu.h
> F: tests/functional/test_multiprocess.py
>
> +VFIO-USER:
> +M: John Levon <john.levon@nutanix.com>
> +M: Thanos Makatos <thanos.makatos@nutanix.com>
> +S: Supported
> +F: docs/devel/vfio-user.rst
> +F: subprojects/libvfio-user
> +
> EBPF:
> M: Jason Wang <jasowang@redhat.com>
> R: Andrew Melnychenko <andrew@daynix.com>
> diff --git a/docs/devel/index-internals.rst b/docs/devel/index-internals.rst
> index 7a0678cbdd..1b04311f06 100644
> --- a/docs/devel/index-internals.rst
> +++ b/docs/devel/index-internals.rst
> @@ -22,6 +22,7 @@ Details about QEMU's various subsystems including how to add features to them.
> tracing
> uefi-vars
> vfio-iommufd
> + vfio-user
> writing-monitor-commands
> virtio-backends
> crypto
> diff --git a/docs/devel/vfio-user.rst b/docs/devel/vfio-user.rst
> new file mode 100644
> index 0000000000..0d96477a68
> --- /dev/null
> +++ b/docs/devel/vfio-user.rst
> @@ -0,0 +1,1522 @@
> +.. include:: <isonum.txt>
> +********************************
> +vfio-user Protocol Specification
> +********************************
An '*' line defines a chapter. I think we want a section instead.
Please use an '=' line.
> +
> +--------------
> +Version_ 0.9.1
> +--------------
Are you planning to have a subsection per version ?
Also, the version is not consistent with the code :
hw/vfio-user/protocol.h:#define VFIO_USER_MAJOR_VER 0
hw/vfio-user/protocol.h:#define VFIO_USER_MINOR_VER 0
Should this version information move to the "Protocol specification" subsection
below ?
> +
> +.. contents:: Table of Contents
> +
> +Introduction
> +============
> +vfio-user is a protocol that allows a device to be emulated in a separate
> +process outside of a Virtual Machine Monitor (VMM). vfio-user devices consist
> +of a generic VFIO device type, living inside the VMM, which we call the client,
> +and the core device implementation, living outside the VMM, which we call the
> +server.
> +
> +The vfio-user specification is partly based on the
> +`Linux VFIO ioctl interface <https://www.kernel.org/doc/html/latest/driver-api/vfio.html>`_.
> +
> +VFIO is a mature and stable API, backed by an extensively used framework. The
> +existing VFIO client implementation in QEMU (``qemu/hw/vfio/``) can be largely
> +re-used, though there is nothing in this specification that requires that
> +particular implementation. None of the VFIO kernel modules are required for
> +supporting the protocol, on either the client or server side. Some source
> +definitions in VFIO are re-used for vfio-user.
> +
> +The main idea is to allow a virtual device to function in a separate process in
> +the same host over a UNIX domain socket. A UNIX domain socket (``AF_UNIX``) is
> +chosen because file descriptors can be trivially sent over it, which in turn
> +allows:
> +
> +* Sharing of client memory for DMA with the server.
> +* Sharing of server memory with the client for fast MMIO.
> +* Efficient sharing of eventfd's for triggering interrupts.
> +
> +Other socket types could be used which allow the server to run in a separate
> +guest in the same host (``AF_VSOCK``) or remotely (``AF_INET``). Theoretically
> +the underlying transport does not necessarily have to be a socket, however we do
> +not examine such alternatives. In this protocol version we focus on using a UNIX
> +domain socket and introduce basic support for the other two types of sockets
> +without considering performance implications.
> +
> +While passing of file descriptors is desirable for performance reasons, support
> +is not necessary for either the client or the server in order to implement the
> +protocol. There is always an in-band, message-passing fall back mechanism.
> +
> +Overview
> +========
> +
> +VFIO is a framework that allows a physical device to be securely passed through
> +to a user space process; the device-specific kernel driver does not drive the
> +device at all. Typically, the user space process is a VMM and the device is
> +passed through to it in order to achieve high performance. VFIO provides an API
> +and the required functionality in the kernel. QEMU has adopted VFIO to allow a
> +guest to directly access physical devices, instead of emulating them in
> +software.
> +
> +vfio-user reuses the core VFIO concepts defined in its API, but implements them
> +as messages to be sent over a socket. It does not change the kernel-based VFIO
> +in any way, in fact none of the VFIO kernel modules need to be loaded to use
> +vfio-user. It is also possible for the client to concurrently use the current
> +kernel-based VFIO for one device, and vfio-user for another device.
> +
> +VFIO Device Model
> +-----------------
> +
> +A device under VFIO presents a standard interface to the user process. Many of
> +the VFIO operations in the existing interface use the ``ioctl()`` system call, and
> +references to the existing interface are called the ``ioctl()`` implementation in
> +this document.
> +
> +The following sections describe the set of messages that implement the vfio-user
> +interface over a socket. In many cases, the messages are analogous to data
> +structures used in the ``ioctl()`` implementation. Messages derived from the
> +``ioctl()`` will have a name derived from the ``ioctl()`` command name. E.g., the
> +``VFIO_DEVICE_GET_INFO`` ``ioctl()`` command becomes a
> +``VFIO_USER_DEVICE_GET_INFO`` message. The purpose of this reuse is to share as
> +much code as feasible with the ``ioctl()`` implementation``.
> +
> +Connection Initiation
> +^^^^^^^^^^^^^^^^^^^^^
> +
> +After the client connects to the server, the initial client message is
> +``VFIO_USER_VERSION`` to propose a protocol version and set of capabilities to
> +apply to the session. The server replies with a compatible version and set of
> +capabilities it supports, or closes the connection if it cannot support the
> +advertised version.
> +
> +Device Information
> +^^^^^^^^^^^^^^^^^^
> +
> +The client uses a ``VFIO_USER_DEVICE_GET_INFO`` message to query the server for
> +information about the device. This information includes:
> +
> +* The device type and whether it supports reset (``VFIO_DEVICE_FLAGS_``),
> +* the number of device regions, and
> +* the device presents to the client the number of interrupt types the device
> + supports.
> +
> +Region Information
> +^^^^^^^^^^^^^^^^^^
> +
> +The client uses ``VFIO_USER_DEVICE_GET_REGION_INFO`` messages to query the
> +server for information about the device's regions. This information describes:
> +
> +* Read and write permissions, whether it can be memory mapped, and whether it
> + supports additional capabilities (``VFIO_REGION_INFO_CAP_``).
> +* Region index, size, and offset.
> +
> +When a device region can be mapped by the client, the server provides a file
> +descriptor which the client can ``mmap()``. The server is responsible for
> +polling for client updates to memory mapped regions.
> +
> +Region Capabilities
> +"""""""""""""""""""
> +
> +Some regions have additional capabilities that cannot be described adequately
> +by the region info data structure. These capabilities are returned in the
> +region info reply in a list similar to PCI capabilities in a PCI device's
> +configuration space.
> +
> +Sparse Regions
> +""""""""""""""
> +A region can be memory-mappable in whole or in part. When only a subset of a
> +region can be mapped by the client, a ``VFIO_REGION_INFO_CAP_SPARSE_MMAP``
> +capability is included in the region info reply. This capability describes
> +which portions can be mapped by the client.
> +
> +.. Note::
> + For example, in a virtual NVMe controller, sparse regions can be used so
> + that accesses to the NVMe registers (found in the beginning of BAR0) are
> + trapped (an infrequent event), while allowing direct access to the doorbells
> + (an extremely frequent event as every I/O submission requires a write to
> + BAR0), found in the next page after the NVMe registers in BAR0.
> +
> +Device-Specific Regions
> +"""""""""""""""""""""""
> +
> +A device can define regions additional to the standard ones (e.g. PCI indexes
> +0-8). This is achieved by including a ``VFIO_REGION_INFO_CAP_TYPE`` capability
> +in the region info reply of a device-specific region. Such regions are reflected
> +in ``struct vfio_user_device_info.num_regions``. Thus, for PCI devices this
> +value can be equal to, or higher than, ``VFIO_PCI_NUM_REGIONS``.
> +
> +Region I/O via file descriptors
> +-------------------------------
> +
> +For unmapped regions, region I/O from the client is done via
> +``VFIO_USER_REGION_READ/WRITE``. As an optimization, ioeventfds or ioregionfds
> +may be configured for sub-regions of some regions. A client may request
> +information on these sub-regions via ``VFIO_USER_DEVICE_GET_REGION_IO_FDS``; by
> +configuring the returned file descriptors as ioeventfds or ioregionfds, the
> +server can be directly notified of I/O (for example, by KVM) without taking a
> +trip through the client.
> +
> +Interrupts
> +^^^^^^^^^^
> +
> +The client uses ``VFIO_USER_DEVICE_GET_IRQ_INFO`` messages to query the server
> +for the device's interrupt types. The interrupt types are specific to the bus
> +the device is attached to, and the client is expected to know the capabilities
> +of each interrupt type. The server can signal an interrupt by directly injecting
> +interrupts into the guest via an event file descriptor. The client configures
> +how the server signals an interrupt with ``VFIO_USER_SET_IRQS`` messages.
> +
> +Device Read and Write
> +^^^^^^^^^^^^^^^^^^^^^
> +
> +When the guest executes load or store operations to an unmapped device region,
> +the client forwards these operations to the server with
> +``VFIO_USER_REGION_READ`` or ``VFIO_USER_REGION_WRITE`` messages. The server
> +will reply with data from the device on read operations or an acknowledgement on
> +write operations. See `Read and Write Operations`_.
> +
> +Client memory access
> +--------------------
> +
> +The client uses ``VFIO_USER_DMA_MAP`` and ``VFIO_USER_DMA_UNMAP`` messages to
> +inform the server of the valid DMA ranges that the server can access on behalf
> +of a device (typically, VM guest memory). DMA memory may be accessed by the
> +server via ``VFIO_USER_DMA_READ`` and ``VFIO_USER_DMA_WRITE`` messages over the
> +socket. In this case, the "DMA" part of the naming is a misnomer.
> +
> +Actual direct memory access of client memory from the server is possible if the
> +client provides file descriptors the server can ``mmap()``. Note that ``mmap()``
> +privileges cannot be revoked by the client, therefore file descriptors should
> +only be exported in environments where the client trusts the server not to
> +corrupt guest memory.
> +
> +See `Read and Write Operations`_.
> +
> +Client/server interactions
> +==========================
> +
> +Socket
> +------
> +
> +A server can serve:
> +
> +1) one or more clients, and/or
> +2) one or more virtual devices, belonging to one or more clients.
> +
> +The current protocol specification requires a dedicated socket per
> +client/server connection. It is a server-side implementation detail whether a
> +single server handles multiple virtual devices from the same or multiple
> +clients. The location of the socket is implementation-specific. Multiplexing
> +clients, devices, and servers over the same socket is not supported in this
> +version of the protocol.
> +
> +Authentication
> +--------------
> +
> +For ``AF_UNIX``, we rely on OS mandatory access controls on the socket files,
> +therefore it is up to the management layer to set up the socket as required.
> +Socket types that span guests or hosts will require a proper authentication
> +mechanism. Defining that mechanism is deferred to a future version of the
> +protocol.
> +
> +Command Concurrency
> +-------------------
> +
> +A client may pipeline multiple commands without waiting for previous command
> +replies. The server will process commands in the order they are received. A
> +consequence of this is if a client issues a command with the *No_reply* bit,
> +then subsequently issues a command without *No_reply*, the older command will
> +have been processed before the reply to the younger command is sent by the
> +server. The client must be aware of the device's capability to process
> +concurrent commands if pipelining is used. For example, pipelining allows
> +multiple client threads to concurrently access device regions; the client must
> +ensure these accesses obey device semantics.
> +
> +An example is a frame buffer device, where the device may allow concurrent
> +access to different areas of video memory, but may have indeterminate behavior
> +if concurrent accesses are performed to command or status registers.
> +
> +Note that unrelated messages sent from the server to the client can appear in
> +between a client to server request/reply and vice versa.
> +
> +Implementers should be prepared for certain commands to exhibit potentially
> +unbounded latencies. For example, ``VFIO_USER_DEVICE_RESET`` may take an
> +arbitrarily long time to complete; clients should take care not to block
> +unnecessarily.
> +
> +Socket Disconnection Behavior
> +-----------------------------
> +The server and the client can disconnect from each other, either intentionally
> +or unexpectedly. Both the client and the server need to know how to handle such
> +events.
> +
> +Server Disconnection
> +^^^^^^^^^^^^^^^^^^^^
> +A server disconnecting from the client may indicate that:
> +
> +1) A virtual device has been restarted, either intentionally (e.g. because of a
> + device update) or unintentionally (e.g. because of a crash).
> +2) A virtual device has been shut down with no intention to be restarted.
> +
> +It is impossible for the client to know whether or not a failure is
> +intermittent or innocuous and should be retried, therefore the client should
> +reset the VFIO device when it detects the socket has been disconnected.
> +Error recovery will be driven by the guest's device error handling
> +behavior.
> +
> +Client Disconnection
> +^^^^^^^^^^^^^^^^^^^^
> +The client disconnecting from the server primarily means that the client
> +has exited. Currently, this means that the guest is shut down so the device is
> +no longer needed therefore the server can automatically exit. However, there
> +can be cases where a client disconnection should not result in a server exit:
> +
> +1) A single server serving multiple clients.
> +2) A multi-process QEMU upgrading itself step by step, which is not yet
> + implemented.
> +
> +Therefore in order for the protocol to be forward compatible, the server should
> +respond to a client disconnection as follows:
> +
> + - all client memory regions are unmapped and cleaned up (including closing any
> + passed file descriptors)
> + - all IRQ file descriptors passed from the old client are closed
> + - the device state should otherwise be retained
> +
> +The expectation is that when a client reconnects, it will re-establish IRQ and
> +client memory mappings.
> +
> +If anything happens to the client (such as qemu really did exit), the control
> +stack will know about it and can clean up resources accordingly.
> +
> +Security Considerations
> +-----------------------
> +
> +Speaking generally, vfio-user clients should not trust servers, and vice versa.
> +Standard tools and mechanisms should be used on both sides to validate input and
> +prevent against denial of service scenarios, buffer overflow, etc.
> +
> +Request Retry and Response Timeout
> +----------------------------------
> +A failed command is a command that has been successfully sent and has been
> +responded to with an error code. Failure to send the command in the first place
> +(e.g. because the socket is disconnected) is a different type of error examined
> +earlier in the disconnect section.
> +
> +.. Note::
> + QEMU's VFIO retries certain operations if they fail. While this makes sense
> + for real HW, we don't know for sure whether it makes sense for virtual
> + devices.
> +
> +Defining a retry and timeout scheme is deferred to a future version of the
> +protocol.
> +
> +Message sizes
> +-------------
> +
> +Some requests have an ``argsz`` field. In a request, it defines the maximum
> +expected reply payload size, which should be at least the size of the fixed
> +reply payload headers defined here. The *request* payload size is defined by the
> +usual ``msg_size`` field in the header, not the ``argsz`` field.
> +
> +In a reply, the server sets ``argsz`` field to the size needed for a full
> +payload size. This may be less than the requested maximum size. This may be
> +larger than the requested maximum size: in that case, the full payload is not
> +included in the reply, but the ``argsz`` field in the reply indicates the needed
> +size, allowing a client to allocate a larger buffer for holding the reply before
> +trying again.
> +
> +In addition, during negotiation (see `Version`_), the client and server may
> +each specify a ``max_data_xfer_size`` value; this defines the maximum data that
> +may be read or written via one of the ``VFIO_USER_DMA/REGION_READ/WRITE``
> +messages; see `Read and Write Operations`_.
> +
> +Protocol Specification
> +======================
> +
> +To distinguish from the base VFIO symbols, all vfio-user symbols are prefixed
> +with ``vfio_user`` or ``VFIO_USER``. In this revision, all data is in the
> +endianness of the host system, although this may be relaxed in future
> +revisions in cases where the client and server run on different hosts
> +with different endianness.
> +
> +Unless otherwise specified, all sizes should be presumed to be in bytes.
> +
> +.. _Commands:
> +
> +Commands
> +--------
> +The following table lists the VFIO message command IDs, and whether the
> +message command is sent from the client or the server.
> +
> +====================================== ========= =================
> +Name Command Request Direction
> +====================================== ========= =================
> +``VFIO_USER_VERSION`` 1 client -> server
> +``VFIO_USER_DMA_MAP`` 2 client -> server
> +``VFIO_USER_DMA_UNMAP`` 3 client -> server
> +``VFIO_USER_DEVICE_GET_INFO`` 4 client -> server
> +``VFIO_USER_DEVICE_GET_REGION_INFO`` 5 client -> server
> +``VFIO_USER_DEVICE_GET_REGION_IO_FDS`` 6 client -> server
> +``VFIO_USER_DEVICE_GET_IRQ_INFO`` 7 client -> server
> +``VFIO_USER_DEVICE_SET_IRQS`` 8 client -> server
> +``VFIO_USER_REGION_READ`` 9 client -> server
> +``VFIO_USER_REGION_WRITE`` 10 client -> server
> +``VFIO_USER_DMA_READ`` 11 server -> client
> +``VFIO_USER_DMA_WRITE`` 12 server -> client
> +``VFIO_USER_DEVICE_RESET`` 13 client -> server
> +``VFIO_USER_REGION_WRITE_MULTI`` 15 client -> server
> +====================================== ========= =================
> +
> +Header
> +------
> +
> +All messages, both command messages and reply messages, are preceded by a
> +16-byte header that contains basic information about the message. The header is
> +followed by message-specific data described in the sections below.
> +
> ++----------------+--------+-------------+
> +| Name | Offset | Size |
> ++================+========+=============+
> +| Message ID | 0 | 2 |
> ++----------------+--------+-------------+
> +| Command | 2 | 2 |
> ++----------------+--------+-------------+
> +| Message size | 4 | 4 |
> ++----------------+--------+-------------+
> +| Flags | 8 | 4 |
> ++----------------+--------+-------------+
> +| | +-----+------------+ |
> +| | | Bit | Definition | |
> +| | +=====+============+ |
> +| | | 0-3 | Type | |
> +| | +-----+------------+ |
> +| | | 4 | No_reply | |
> +| | +-----+------------+ |
> +| | | 5 | Error | |
> +| | +-----+------------+ |
> ++----------------+--------+-------------+
> +| Error | 12 | 4 |
> ++----------------+--------+-------------+
> +| <message data> | 16 | variable |
> ++----------------+--------+-------------+
> +
> +* *Message ID* identifies the message, and is echoed in the command's reply
> + message. Message IDs belong entirely to the sender, can be re-used (even
> + concurrently) and the receiver must not make any assumptions about their
> + uniqueness.
> +* *Command* specifies the command to be executed, listed in Commands_. It is
> + also set in the reply header.
> +* *Message size* contains the size of the entire message, including the header.
> +* *Flags* contains attributes of the message:
> +
> + * The *Type* bits indicate the message type.
> +
> + * *Command* (value 0x0) indicates a command message.
> + * *Reply* (value 0x1) indicates a reply message acknowledging a previous
> + command with the same message ID.
> + * *No_reply* in a command message indicates that no reply is needed for this
> + command. This is commonly used when multiple commands are sent, and only
> + the last needs acknowledgement.
> + * *Error* in a reply message indicates the command being acknowledged had
> + an error. In this case, the *Error* field will be valid.
> +
> +* *Error* in a reply message is an optional UNIX errno value. It may be zero
> + even if the Error bit is set in Flags. It is reserved in a command message.
> +
> +Each command message in Commands_ must be replied to with a reply message,
> +unless the message sets the *No_Reply* bit. The reply consists of the header
> +with the *Reply* bit set, plus any additional data.
> +
> +If an error occurs, the reply message must only include the reply header.
> +
> +As the header is standard in both requests and replies, it is not included in
> +the command-specific specifications below; each message definition should be
> +appended to the standard header, and the offsets are given from the end of the
> +standard header.
> +
> +``VFIO_USER_VERSION``
> +---------------------
> +
> +.. _Version:
> +
> +This is the initial message sent by the client after the socket connection is
> +established; the same format is used for the server's reply.
> +
> +Upon establishing a connection, the client must send a ``VFIO_USER_VERSION``
> +message proposing a protocol version and a set of capabilities. The server
> +compares these with the versions and capabilities it supports and sends a
> +``VFIO_USER_VERSION`` reply according to the following rules.
> +
> +* The major version in the reply must be the same as proposed. If the client
> + does not support the proposed major, it closes the connection.
> +* The minor version in the reply must be equal to or less than the minor
> + version proposed.
> +* The capability list must be a subset of those proposed. If the server
> + requires a capability the client did not include, it closes the connection.
> +
> +The protocol major version will only change when incompatible protocol changes
> +are made, such as changing the message format. The minor version may change
> +when compatible changes are made, such as adding new messages or capabilities,
> +Both the client and server must support all minor versions less than the
> +maximum minor version it supports. E.g., an implementation that supports
> +version 1.3 must also support 1.0 through 1.2.
> +
> +When making a change to this specification, the protocol version number must
> +be included in the form "added in version X.Y"
> +
> +Request
> +^^^^^^^
> +
> +============== ====== ====
> +Name Offset Size
> +============== ====== ====
> +version major 0 2
> +version minor 2 2
> +version data 4 variable (including terminating NUL). Optional.
> +============== ====== ====
> +
> +The version data is an optional UTF-8 encoded JSON byte array with the following
> +format:
> +
> ++--------------+--------+-----------------------------------+
> +| Name | Type | Description |
> ++==============+========+===================================+
> +| capabilities | object | Contains common capabilities that |
> +| | | the sender supports. Optional. |
> ++--------------+--------+-----------------------------------+
> +
> +Capabilities:
> +
> ++--------------------+---------+------------------------------------------------+
> +| Name | Type | Description |
> ++====================+=========+================================================+
> +| max_msg_fds | number | Maximum number of file descriptors that can be |
> +| | | received by the sender in one message. |
> +| | | Optional. If not specified then the receiver |
> +| | | must assume a value of ``1``. |
> ++--------------------+---------+------------------------------------------------+
> +| max_data_xfer_size | number | Maximum ``count`` for data transfer messages; |
> +| | | see `Read and Write Operations`_. Optional, |
> +| | | with a default value of 1048576 bytes. |
> ++--------------------+---------+------------------------------------------------+
> +| pgsizes | number | Page sizes supported in DMA map operations |
> +| | | or'ed together. Optional, with a default value |
> +| | | of supporting only 4k pages. |
> ++--------------------+---------+------------------------------------------------+
> +| max_dma_maps | number | Maximum number DMA map windows that can be |
> +| | | valid simultaneously. Optional, with a |
> +| | | value of 65535 (64k-1). |
> ++--------------------+---------+------------------------------------------------+
> +| migration | object | Migration capability parameters. If missing |
> +| | | then migration is not supported by the sender. |
> ++--------------------+---------+------------------------------------------------+
> +| write_multiple | boolean | ``VFIO_USER_REGION_WRITE_MULTI`` messages |
> +| | | are supported if the value is ``true``. |
> ++--------------------+---------+------------------------------------------------+
> +
> +The migration capability contains the following name/value pairs:
> +
> ++-----------------+--------+--------------------------------------------------+
> +| Name | Type | Description |
> ++=================+========+==================================================+
> +| pgsize | number | Page size of dirty pages bitmap. The smallest |
> +| | | between the client and the server is used. |
> ++-----------------+--------+--------------------------------------------------+
> +| max_bitmap_size | number | Maximum bitmap size in ``VFIO_USER_DIRTY_PAGES`` |
> +| | | and ``VFIO_DMA_UNMAP`` messages. Optional, |
> +| | | with a default value of 256MB. |
> ++-----------------+--------+--------------------------------------------------+
> +
> +Reply
> +^^^^^
> +
> +The same message format is used in the server's reply with the semantics
> +described above.
> +
> +``VFIO_USER_DMA_MAP``
> +---------------------
> +
> +This command message is sent by the client to the server to inform it of the
> +memory regions the server can access. It must be sent before the server can
> +perform any DMA to the client. It is normally sent directly after the version
> +handshake is completed, but may also occur when memory is added to the client,
> +or if the client uses a vIOMMU.
> +
> +Request
> +^^^^^^^
> +
> +The request payload for this message is a structure of the following format:
> +
> ++-------------+--------+-------------+
> +| Name | Offset | Size |
> ++=============+========+=============+
> +| argsz | 0 | 4 |
> ++-------------+--------+-------------+
> +| flags | 4 | 4 |
> ++-------------+--------+-------------+
> +| | +-----+------------+ |
> +| | | Bit | Definition | |
> +| | +=====+============+ |
> +| | | 0 | readable | |
> +| | +-----+------------+ |
> +| | | 1 | writeable | |
> +| | +-----+------------+ |
> ++-------------+--------+-------------+
> +| offset | 8 | 8 |
> ++-------------+--------+-------------+
> +| address | 16 | 8 |
> ++-------------+--------+-------------+
> +| size | 24 | 8 |
> ++-------------+--------+-------------+
> +
> +* *argsz* is the size of the above structure. Note there is no reply payload,
> + so this field differs from other message types.
> +* *flags* contains the following region attributes:
> +
> + * *readable* indicates that the region can be read from.
> +
> + * *writeable* indicates that the region can be written to.
> +
> +* *offset* is the file offset of the region with respect to the associated file
> + descriptor, or zero if the region is not mappable
> +* *address* is the base DMA address of the region.
> +* *size* is the size of the region.
> +
> +This structure is 32 bytes in size, so the message size is 16 + 32 bytes.
> +
> +If the DMA region being added can be directly mapped by the server, a file
> +descriptor must be sent as part of the message meta-data. The region can be
> +mapped via the mmap() system call. On ``AF_UNIX`` sockets, the file descriptor
> +must be passed as ``SCM_RIGHTS`` type ancillary data. Otherwise, if the DMA
> +region cannot be directly mapped by the server, no file descriptor must be sent
> +as part of the message meta-data and the DMA region can be accessed by the
> +server using ``VFIO_USER_DMA_READ`` and ``VFIO_USER_DMA_WRITE`` messages,
> +explained in `Read and Write Operations`_. A command to map over an existing
> +region must be failed by the server with ``EEXIST`` set in error field in the
> +reply.
> +
> +Reply
> +^^^^^
> +
> +There is no payload in the reply message.
> +
> +``VFIO_USER_DMA_UNMAP``
> +-----------------------
> +
> +This command message is sent by the client to the server to inform it that a
> +DMA region, previously made available via a ``VFIO_USER_DMA_MAP`` command
> +message, is no longer available for DMA. It typically occurs when memory is
> +subtracted from the client or if the client uses a vIOMMU. The DMA region is
> +described by the following structure:
> +
> +Request
> +^^^^^^^
> +
> +The request payload for this message is a structure of the following format:
> +
> ++--------------+--------+------------------------+
> +| Name | Offset | Size |
> ++==============+========+========================+
> +| argsz | 0 | 4 |
> ++--------------+--------+------------------------+
> +| flags | 4 | 4 |
> ++--------------+--------+------------------------+
> +| address | 8 | 8 |
> ++--------------+--------+------------------------+
> +| size | 16 | 8 |
> ++--------------+--------+------------------------+
> +
> +* *argsz* is the maximum size of the reply payload.
> +* *flags* is unused in this version.
> +* *address* is the base DMA address of the DMA region.
> +* *size* is the size of the DMA region.
> +
> +The address and size of the DMA region being unmapped must match exactly a
> +previous mapping.
> +
> +Reply
> +^^^^^
> +
> +Upon receiving a ``VFIO_USER_DMA_UNMAP`` command, if the file descriptor is
> +mapped then the server must release all references to that DMA region before
> +replying, which potentially includes in-flight DMA transactions.
> +
> +The server responds with the original DMA entry in the request.
> +
> +
> +``VFIO_USER_DEVICE_GET_INFO``
> +-----------------------------
> +
> +This command message is sent by the client to the server to query for basic
> +information about the device.
> +
> +Request
> +^^^^^^^
> +
> ++-------------+--------+--------------------------+
> +| Name | Offset | Size |
> ++=============+========+==========================+
> +| argsz | 0 | 4 |
> ++-------------+--------+--------------------------+
> +| flags | 4 | 4 |
> ++-------------+--------+--------------------------+
> +| | +-----+-------------------------+ |
> +| | | Bit | Definition | |
> +| | +=====+=========================+ |
> +| | | 0 | VFIO_DEVICE_FLAGS_RESET | |
> +| | +-----+-------------------------+ |
> +| | | 1 | VFIO_DEVICE_FLAGS_PCI | |
> +| | +-----+-------------------------+ |
> ++-------------+--------+--------------------------+
> +| num_regions | 8 | 4 |
> ++-------------+--------+--------------------------+
> +| num_irqs | 12 | 4 |
> ++-------------+--------+--------------------------+
> +
> +* *argsz* is the maximum size of the reply payload
> +* all other fields must be zero.
> +
> +Reply
> +^^^^^
> +
> ++-------------+--------+--------------------------+
> +| Name | Offset | Size |
> ++=============+========+==========================+
> +| argsz | 0 | 4 |
> ++-------------+--------+--------------------------+
> +| flags | 4 | 4 |
> ++-------------+--------+--------------------------+
> +| | +-----+-------------------------+ |
> +| | | Bit | Definition | |
> +| | +=====+=========================+ |
> +| | | 0 | VFIO_DEVICE_FLAGS_RESET | |
> +| | +-----+-------------------------+ |
> +| | | 1 | VFIO_DEVICE_FLAGS_PCI | |
> +| | +-----+-------------------------+ |
> ++-------------+--------+--------------------------+
> +| num_regions | 8 | 4 |
> ++-------------+--------+--------------------------+
> +| num_irqs | 12 | 4 |
> ++-------------+--------+--------------------------+
> +
> +* *argsz* is the size required for the full reply payload (16 bytes today)
> +* *flags* contains the following device attributes.
> +
> + * ``VFIO_DEVICE_FLAGS_RESET`` indicates that the device supports the
> + ``VFIO_USER_DEVICE_RESET`` message.
> + * ``VFIO_DEVICE_FLAGS_PCI`` indicates that the device is a PCI device.
> +
> +* *num_regions* is the number of memory regions that the device exposes.
> +* *num_irqs* is the number of distinct interrupt types that the device supports.
> +
> +This version of the protocol only supports PCI devices. Additional devices may
> +be supported in future versions.
> +
> +``VFIO_USER_DEVICE_GET_REGION_INFO``
> +------------------------------------
> +
> +This command message is sent by the client to the server to query for
> +information about device regions. The VFIO region info structure is defined in
> +``<linux/vfio.h>`` (``struct vfio_region_info``).
> +
> +Request
> +^^^^^^^
> +
> ++------------+--------+------------------------------+
> +| Name | Offset | Size |
> ++============+========+==============================+
> +| argsz | 0 | 4 |
> ++------------+--------+------------------------------+
> +| flags | 4 | 4 |
> ++------------+--------+------------------------------+
> +| index | 8 | 4 |
> ++------------+--------+------------------------------+
> +| cap_offset | 12 | 4 |
> ++------------+--------+------------------------------+
> +| size | 16 | 8 |
> ++------------+--------+------------------------------+
> +| offset | 24 | 8 |
> ++------------+--------+------------------------------+
> +
> +* *argsz* the maximum size of the reply payload
> +* *index* is the index of memory region being queried, it is the only field
> + that is required to be set in the command message.
> +* all other fields must be zero.
> +
> +Reply
> +^^^^^
> +
> ++------------+--------+------------------------------+
> +| Name | Offset | Size |
> ++============+========+==============================+
> +| argsz | 0 | 4 |
> ++------------+--------+------------------------------+
> +| flags | 4 | 4 |
> ++------------+--------+------------------------------+
> +| | +-----+-----------------------------+ |
> +| | | Bit | Definition | |
> +| | +=====+=============================+ |
> +| | | 0 | VFIO_REGION_INFO_FLAG_READ | |
> +| | +-----+-----------------------------+ |
> +| | | 1 | VFIO_REGION_INFO_FLAG_WRITE | |
> +| | +-----+-----------------------------+ |
> +| | | 2 | VFIO_REGION_INFO_FLAG_MMAP | |
> +| | +-----+-----------------------------+ |
> +| | | 3 | VFIO_REGION_INFO_FLAG_CAPS | |
> +| | +-----+-----------------------------+ |
> ++------------+--------+------------------------------+
> ++------------+--------+------------------------------+
> +| index | 8 | 4 |
> ++------------+--------+------------------------------+
> +| cap_offset | 12 | 4 |
> ++------------+--------+------------------------------+
> +| size | 16 | 8 |
> ++------------+--------+------------------------------+
> +| offset | 24 | 8 |
> ++------------+--------+------------------------------+
> +
> +* *argsz* is the size required for the full reply payload (region info structure
> + plus the size of any region capabilities)
> +* *flags* are attributes of the region:
> +
> + * ``VFIO_REGION_INFO_FLAG_READ`` allows client read access to the region.
> + * ``VFIO_REGION_INFO_FLAG_WRITE`` allows client write access to the region.
> + * ``VFIO_REGION_INFO_FLAG_MMAP`` specifies the client can mmap() the region.
> + When this flag is set, the reply will include a file descriptor in its
> + meta-data. On ``AF_UNIX`` sockets, the file descriptors will be passed as
> + ``SCM_RIGHTS`` type ancillary data.
> + * ``VFIO_REGION_INFO_FLAG_CAPS`` indicates additional capabilities found in the
> + reply.
> +
> +* *index* is the index of memory region being queried, it is the only field
> + that is required to be set in the command message.
> +* *cap_offset* describes where additional region capabilities can be found.
> + cap_offset is relative to the beginning of the VFIO region info structure.
> + The data structure it points is a VFIO cap header defined in
> + ``<linux/vfio.h>``.
> +* *size* is the size of the region.
> +* *offset* is the offset that should be given to the mmap() system call for
> + regions with the MMAP attribute. It is also used as the base offset when
> + mapping a VFIO sparse mmap area, described below.
> +
> +VFIO region capabilities
> +""""""""""""""""""""""""
> +
> +The VFIO region information can also include a capabilities list. This list is
> +similar to a PCI capability list - each entry has a common header that
> +identifies a capability and where the next capability in the list can be found.
> +The VFIO capability header format is defined in ``<linux/vfio.h>`` (``struct
> +vfio_info_cap_header``).
> +
> +VFIO cap header format
> +""""""""""""""""""""""
> +
> ++---------+--------+------+
> +| Name | Offset | Size |
> ++=========+========+======+
> +| id | 0 | 2 |
> ++---------+--------+------+
> +| version | 2 | 2 |
> ++---------+--------+------+
> +| next | 4 | 4 |
> ++---------+--------+------+
> +
> +* *id* is the capability identity.
> +* *version* is a capability-specific version number.
> +* *next* specifies the offset of the next capability in the capability list. It
> + is relative to the beginning of the VFIO region info structure.
> +
> +VFIO sparse mmap cap header
> +"""""""""""""""""""""""""""
> +
> ++------------------+----------------------------------+
> +| Name | Value |
> ++==================+==================================+
> +| id | VFIO_REGION_INFO_CAP_SPARSE_MMAP |
> ++------------------+----------------------------------+
> +| version | 0x1 |
> ++------------------+----------------------------------+
> +| next | <next> |
> ++------------------+----------------------------------+
> +| sparse mmap info | VFIO region info sparse mmap |
> ++------------------+----------------------------------+
> +
> +This capability is defined when only a subrange of the region supports
> +direct access by the client via mmap(). The VFIO sparse mmap area is defined in
> +``<linux/vfio.h>`` (``struct vfio_region_sparse_mmap_area`` and ``struct
> +vfio_region_info_cap_sparse_mmap``).
> +
> +VFIO region info cap sparse mmap
> +""""""""""""""""""""""""""""""""
> +
> ++----------+--------+------+
> +| Name | Offset | Size |
> ++==========+========+======+
> +| nr_areas | 0 | 4 |
> ++----------+--------+------+
> +| reserved | 4 | 4 |
> ++----------+--------+------+
> +| offset | 8 | 8 |
> ++----------+--------+------+
> +| size | 16 | 8 |
> ++----------+--------+------+
> +| ... | | |
> ++----------+--------+------+
> +
> +* *nr_areas* is the number of sparse mmap areas in the region.
> +* *offset* and size describe a single area that can be mapped by the client.
> + There will be *nr_areas* pairs of offset and size. The offset will be added to
> + the base offset given in the ``VFIO_USER_DEVICE_GET_REGION_INFO`` to form the
> + offset argument of the subsequent mmap() call.
> +
> +The VFIO sparse mmap area is defined in ``<linux/vfio.h>`` (``struct
> +vfio_region_info_cap_sparse_mmap``).
> +
> +
> +``VFIO_USER_DEVICE_GET_REGION_IO_FDS``
> +--------------------------------------
> +
> +Clients can access regions via ``VFIO_USER_REGION_READ/WRITE`` or, if provided, by
> +``mmap()`` of a file descriptor provided by the server.
> +
> +``VFIO_USER_DEVICE_GET_REGION_IO_FDS`` provides an alternative access mechanism via
> +file descriptors. This is an optional feature intended for performance
> +improvements where an underlying sub-system (such as KVM) supports communication
> +across such file descriptors to the vfio-user server, without needing to
> +round-trip through the client.
> +
> +The server returns an array of sub-regions for the requested region. Each
> +sub-region describes a span (offset and size) of a region, along with the
> +requested file descriptor notification mechanism to use. Each sub-region in the
> +response message may choose to use a different method, as defined below. The
> +two mechanisms supported in this specification are ioeventfds and ioregionfds.
> +
> +The server in addition returns a file descriptor in the ancillary data; clients
> +are expected to configure each sub-region's file descriptor with the requested
> +notification method. For example, a client could configure KVM with the
> +requested ioeventfd via a ``KVM_IOEVENTFD`` ``ioctl()``.
> +
> +Request
> +^^^^^^^
> +
> ++-------------+--------+------+
> +| Name | Offset | Size |
> ++=============+========+======+
> +| argsz | 0 | 4 |
> ++-------------+--------+------+
> +| flags | 4 | 4 |
> ++-------------+--------+------+
> +| index | 8 | 4 |
> ++-------------+--------+------+
> +| count | 12 | 4 |
> ++-------------+--------+------+
> +
> +* *argsz* the maximum size of the reply payload
> +* *index* is the index of memory region being queried
> +* all other fields must be zero
> +
> +The client must set ``flags`` to zero and specify the region being queried in
> +the ``index``.
> +
> +Reply
> +^^^^^
> +
> ++-------------+--------+------+
> +| Name | Offset | Size |
> ++=============+========+======+
> +| argsz | 0 | 4 |
> ++-------------+--------+------+
> +| flags | 4 | 4 |
> ++-------------+--------+------+
> +| index | 8 | 4 |
> ++-------------+--------+------+
> +| count | 12 | 4 |
> ++-------------+--------+------+
> +| sub-regions | 16 | ... |
> ++-------------+--------+------+
> +
> +* *argsz* is the size of the region IO FD info structure plus the
> + total size of the sub-region array. Thus, each array entry "i" is at offset
> + i * ((argsz - 32) / count). Note that currently this is 40 bytes for both IO
> + FD types, but this is not to be relied on. As elsewhere, this indicates the
> + full reply payload size needed.
> +* *flags* must be zero
> +* *index* is the index of memory region being queried
> +* *count* is the number of sub-regions in the array
> +* *sub-regions* is the array of Sub-Region IO FD info structures
> +
> +The reply message will additionally include at least one file descriptor in the
> +ancillary data. Note that more than one sub-region may share the same file
> +descriptor.
> +
> +Note that it is the client's responsibility to verify the requested values (for
> +example, that the requested offset does not exceed the region's bounds).
> +
> +Each sub-region given in the response has one of two possible structures,
> +depending whether *type* is ``VFIO_USER_IO_FD_TYPE_IOEVENTFD`` or
> +``VFIO_USER_IO_FD_TYPE_IOREGIONFD``:
> +
> +Sub-Region IO FD info format (ioeventfd)
> +""""""""""""""""""""""""""""""""""""""""
> +
> ++-----------+--------+------+
> +| Name | Offset | Size |
> ++===========+========+======+
> +| offset | 0 | 8 |
> ++-----------+--------+------+
> +| size | 8 | 8 |
> ++-----------+--------+------+
> +| fd_index | 16 | 4 |
> ++-----------+--------+------+
> +| type | 20 | 4 |
> ++-----------+--------+------+
> +| flags | 24 | 4 |
> ++-----------+--------+------+
> +| padding | 28 | 4 |
> ++-----------+--------+------+
> +| datamatch | 32 | 8 |
> ++-----------+--------+------+
> +
> +* *offset* is the offset of the start of the sub-region within the region
> + requested ("physical address offset" for the region)
> +* *size* is the length of the sub-region. This may be zero if the access size is
> + not relevant, which may allow for optimizations
> +* *fd_index* is the index in the ancillary data of the FD to use for ioeventfd
> + notification; it may be shared.
> +* *type* is ``VFIO_USER_IO_FD_TYPE_IOEVENTFD``
> +* *flags* is any of:
> +
> + * ``KVM_IOEVENTFD_FLAG_DATAMATCH``
> + * ``KVM_IOEVENTFD_FLAG_PIO``
> + * ``KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY`` (FIXME: makes sense?)
> +
> +* *datamatch* is the datamatch value if needed
> +
> +See https://www.kernel.org/doc/Documentation/virtual/kvm/api.txt, *4.59
> +KVM_IOEVENTFD* for further context on the ioeventfd-specific fields.
> +
> +Sub-Region IO FD info format (ioregionfd)
> +"""""""""""""""""""""""""""""""""""""""""
> +
> ++-----------+--------+------+
> +| Name | Offset | Size |
> ++===========+========+======+
> +| offset | 0 | 8 |
> ++-----------+--------+------+
> +| size | 8 | 8 |
> ++-----------+--------+------+
> +| fd_index | 16 | 4 |
> ++-----------+--------+------+
> +| type | 20 | 4 |
> ++-----------+--------+------+
> +| flags | 24 | 4 |
> ++-----------+--------+------+
> +| padding | 28 | 4 |
> ++-----------+--------+------+
> +| user_data | 32 | 8 |
> ++-----------+--------+------+
> +
> +* *offset* is the offset of the start of the sub-region within the region
> + requested ("physical address offset" for the region)
> +* *size* is the length of the sub-region. This may be zero if the access size is
> + not relevant, which may allow for optimizations; ``KVM_IOREGION_POSTED_WRITES``
> + must be set in *flags* in this case
> +* *fd_index* is the index in the ancillary data of the FD to use for ioregionfd
> + messages; it may be shared
> +* *type* is ``VFIO_USER_IO_FD_TYPE_IOREGIONFD``
> +* *flags* is any of:
> +
> + * ``KVM_IOREGION_PIO``
> + * ``KVM_IOREGION_POSTED_WRITES``
> +
> +* *user_data* is an opaque value passed back to the server via a message on the
> + file descriptor
> +
> +For further information on the ioregionfd-specific fields, see:
> +https://lore.kernel.org/kvm/cover.1613828726.git.eafanasova@gmail.com/
> +
> +(FIXME: update with final API docs.)
> +
> +``VFIO_USER_DEVICE_GET_IRQ_INFO``
> +---------------------------------
> +
> +This command message is sent by the client to the server to query for
> +information about device interrupt types. The VFIO IRQ info structure is
> +defined in ``<linux/vfio.h>`` (``struct vfio_irq_info``).
> +
> +Request
> +^^^^^^^
> +
> ++-------+--------+---------------------------+
> +| Name | Offset | Size |
> ++=======+========+===========================+
> +| argsz | 0 | 4 |
> ++-------+--------+---------------------------+
> +| flags | 4 | 4 |
> ++-------+--------+---------------------------+
> +| | +-----+--------------------------+ |
> +| | | Bit | Definition | |
> +| | +=====+==========================+ |
> +| | | 0 | VFIO_IRQ_INFO_EVENTFD | |
> +| | +-----+--------------------------+ |
> +| | | 1 | VFIO_IRQ_INFO_MASKABLE | |
> +| | +-----+--------------------------+ |
> +| | | 2 | VFIO_IRQ_INFO_AUTOMASKED | |
> +| | +-----+--------------------------+ |
> +| | | 3 | VFIO_IRQ_INFO_NORESIZE | |
> +| | +-----+--------------------------+ |
> ++-------+--------+---------------------------+
> +| index | 8 | 4 |
> ++-------+--------+---------------------------+
> +| count | 12 | 4 |
> ++-------+--------+---------------------------+
> +
> +* *argsz* is the maximum size of the reply payload (16 bytes today)
> +* index is the index of IRQ type being queried (e.g. ``VFIO_PCI_MSIX_IRQ_INDEX``)
> +* all other fields must be zero
> +
> +Reply
> +^^^^^
> +
> ++-------+--------+---------------------------+
> +| Name | Offset | Size |
> ++=======+========+===========================+
> +| argsz | 0 | 4 |
> ++-------+--------+---------------------------+
> +| flags | 4 | 4 |
> ++-------+--------+---------------------------+
> +| | +-----+--------------------------+ |
> +| | | Bit | Definition | |
> +| | +=====+==========================+ |
> +| | | 0 | VFIO_IRQ_INFO_EVENTFD | |
> +| | +-----+--------------------------+ |
> +| | | 1 | VFIO_IRQ_INFO_MASKABLE | |
> +| | +-----+--------------------------+ |
> +| | | 2 | VFIO_IRQ_INFO_AUTOMASKED | |
> +| | +-----+--------------------------+ |
> +| | | 3 | VFIO_IRQ_INFO_NORESIZE | |
> +| | +-----+--------------------------+ |
> ++-------+--------+---------------------------+
> +| index | 8 | 4 |
> ++-------+--------+---------------------------+
> +| count | 12 | 4 |
> ++-------+--------+---------------------------+
> +
> +* *argsz* is the size required for the full reply payload (16 bytes today)
> +* *flags* defines IRQ attributes:
> +
> + * ``VFIO_IRQ_INFO_EVENTFD`` indicates the IRQ type can support server eventfd
> + signalling.
> + * ``VFIO_IRQ_INFO_MASKABLE`` indicates that the IRQ type supports the ``MASK``
> + and ``UNMASK`` actions in a ``VFIO_USER_DEVICE_SET_IRQS`` message.
> + * ``VFIO_IRQ_INFO_AUTOMASKED`` indicates the IRQ type masks itself after being
> + triggered, and the client must send an ``UNMASK`` action to receive new
> + interrupts.
> + * ``VFIO_IRQ_INFO_NORESIZE`` indicates ``VFIO_USER_SET_IRQS`` operations setup
> + interrupts as a set, and new sub-indexes cannot be enabled without disabling
> + the entire type.
> +* index is the index of IRQ type being queried
> +* count describes the number of interrupts of the queried type.
> +
> +``VFIO_USER_DEVICE_SET_IRQS``
> +-----------------------------
> +
> +This command message is sent by the client to the server to set actions for
> +device interrupt types. The VFIO IRQ set structure is defined in
> +``<linux/vfio.h>`` (``struct vfio_irq_set``).
> +
> +Request
> +^^^^^^^
> +
> ++-------+--------+------------------------------+
> +| Name | Offset | Size |
> ++=======+========+==============================+
> +| argsz | 0 | 4 |
> ++-------+--------+------------------------------+
> +| flags | 4 | 4 |
> ++-------+--------+------------------------------+
> +| | +-----+-----------------------------+ |
> +| | | Bit | Definition | |
> +| | +=====+=============================+ |
> +| | | 0 | VFIO_IRQ_SET_DATA_NONE | |
> +| | +-----+-----------------------------+ |
> +| | | 1 | VFIO_IRQ_SET_DATA_BOOL | |
> +| | +-----+-----------------------------+ |
> +| | | 2 | VFIO_IRQ_SET_DATA_EVENTFD | |
> +| | +-----+-----------------------------+ |
> +| | | 3 | VFIO_IRQ_SET_ACTION_MASK | |
> +| | +-----+-----------------------------+ |
> +| | | 4 | VFIO_IRQ_SET_ACTION_UNMASK | |
> +| | +-----+-----------------------------+ |
> +| | | 5 | VFIO_IRQ_SET_ACTION_TRIGGER | |
> +| | +-----+-----------------------------+ |
> ++-------+--------+------------------------------+
> +| index | 8 | 4 |
> ++-------+--------+------------------------------+
> +| start | 12 | 4 |
> ++-------+--------+------------------------------+
> +| count | 16 | 4 |
> ++-------+--------+------------------------------+
> +| data | 20 | variable |
> ++-------+--------+------------------------------+
> +
> +* *argsz* is the size of the VFIO IRQ set request payload, including any *data*
> + field. Note there is no reply payload, so this field differs from other
> + message types.
> +* *flags* defines the action performed on the interrupt range. The ``DATA``
> + flags describe the data field sent in the message; the ``ACTION`` flags
> + describe the action to be performed. The flags are mutually exclusive for
> + both sets.
> +
> + * ``VFIO_IRQ_SET_DATA_NONE`` indicates there is no data field in the command.
> + The action is performed unconditionally.
> + * ``VFIO_IRQ_SET_DATA_BOOL`` indicates the data field is an array of boolean
> + bytes. The action is performed if the corresponding boolean is true.
> + * ``VFIO_IRQ_SET_DATA_EVENTFD`` indicates an array of event file descriptors
> + was sent in the message meta-data. These descriptors will be signalled when
> + the action defined by the action flags occurs. In ``AF_UNIX`` sockets, the
> + descriptors are sent as ``SCM_RIGHTS`` type ancillary data.
> + If no file descriptors are provided, this de-assigns the specified
> + previously configured interrupts.
> + * ``VFIO_IRQ_SET_ACTION_MASK`` indicates a masking event. It can be used with
> + ``VFIO_IRQ_SET_DATA_BOOL`` or ``VFIO_IRQ_SET_DATA_NONE`` to mask an interrupt,
> + or with ``VFIO_IRQ_SET_DATA_EVENTFD`` to generate an event when the guest masks
> + the interrupt.
> + * ``VFIO_IRQ_SET_ACTION_UNMASK`` indicates an unmasking event. It can be used
> + with ``VFIO_IRQ_SET_DATA_BOOL`` or ``VFIO_IRQ_SET_DATA_NONE`` to unmask an
> + interrupt, or with ``VFIO_IRQ_SET_DATA_EVENTFD`` to generate an event when the
> + guest unmasks the interrupt.
> + * ``VFIO_IRQ_SET_ACTION_TRIGGER`` indicates a triggering event. It can be used
> + with ``VFIO_IRQ_SET_DATA_BOOL`` or ``VFIO_IRQ_SET_DATA_NONE`` to trigger an
> + interrupt, or with ``VFIO_IRQ_SET_DATA_EVENTFD`` to generate an event when the
> + server triggers the interrupt.
> +
> +* *index* is the index of IRQ type being setup.
> +* *start* is the start of the sub-index being set.
> +* *count* describes the number of sub-indexes being set. As a special case, a
> + count (and start) of 0, with data flags of ``VFIO_IRQ_SET_DATA_NONE`` disables
> + all interrupts of the index.
> +* *data* is an optional field included when the
> + ``VFIO_IRQ_SET_DATA_BOOL`` flag is present. It contains an array of booleans
> + that specify whether the action is to be performed on the corresponding
> + index. It's used when the action is only performed on a subset of the range
> + specified.
> +
> +Not all interrupt types support every combination of data and action flags.
> +The client must know the capabilities of the device and IRQ index before it
> +sends a ``VFIO_USER_DEVICE_SET_IRQ`` message.
> +
> +In typical operation, a specific IRQ may operate as follows:
> +
> +1. The client sends a ``VFIO_USER_DEVICE_SET_IRQ`` message with
> + ``flags=(VFIO_IRQ_SET_DATA_EVENTFD|VFIO_IRQ_SET_ACTION_TRIGGER)`` along
> + with an eventfd. This associates the IRQ with a particular eventfd on the
> + server side.
> +
> +#. The client may send a ``VFIO_USER_DEVICE_SET_IRQ`` message with
> + ``flags=(VFIO_IRQ_SET_DATA_EVENTFD|VFIO_IRQ_SET_ACTION_MASK/UNMASK)`` along
> + with another eventfd. This associates the given eventfd with the
> + mask/unmask state on the server side.
> +
> +#. The server may trigger the IRQ by writing 1 to the eventfd.
> +
> +#. The server may mask/unmask an IRQ which will write 1 to the corresponding
> + mask/unmask eventfd, if there is one.
> +
> +5. A client may trigger a device IRQ itself, by sending a
> + ``VFIO_USER_DEVICE_SET_IRQ`` message with
> + ``flags=(VFIO_IRQ_SET_DATA_NONE/BOOL|VFIO_IRQ_SET_ACTION_TRIGGER)``.
> +
> +6. A client may mask or unmask the IRQ, by sending a
> + ``VFIO_USER_DEVICE_SET_IRQ`` message with
> + ``flags=(VFIO_IRQ_SET_DATA_NONE/BOOL|VFIO_IRQ_SET_ACTION_MASK/UNMASK)``.
> +
> +Reply
> +^^^^^
> +
> +There is no payload in the reply.
> +
> +.. _Read and Write Operations:
> +
> +Note that all of these operations must be supported by the client and/or server,
> +even if the corresponding memory or device region has been shared as mappable.
> +
> +The ``count`` field must not exceed the value of ``max_data_xfer_size`` of the
> +peer, for both reads and writes.
> +
> +``VFIO_USER_REGION_READ``
> +-------------------------
> +
> +If a device region is not mappable, it's not directly accessible by the client
> +via ``mmap()`` of the underlying file descriptor. In this case, a client can
> +read from a device region with this message.
> +
> +Request
> +^^^^^^^
> +
> ++--------+--------+----------+
> +| Name | Offset | Size |
> ++========+========+==========+
> +| offset | 0 | 8 |
> ++--------+--------+----------+
> +| region | 8 | 4 |
> ++--------+--------+----------+
> +| count | 12 | 4 |
> ++--------+--------+----------+
> +
> +* *offset* into the region being accessed.
> +* *region* is the index of the region being accessed.
> +* *count* is the size of the data to be transferred.
> +
> +Reply
> +^^^^^
> +
> ++--------+--------+----------+
> +| Name | Offset | Size |
> ++========+========+==========+
> +| offset | 0 | 8 |
> ++--------+--------+----------+
> +| region | 8 | 4 |
> ++--------+--------+----------+
> +| count | 12 | 4 |
> ++--------+--------+----------+
> +| data | 16 | variable |
> ++--------+--------+----------+
> +
> +* *offset* into the region accessed.
> +* *region* is the index of the region accessed.
> +* *count* is the size of the data transferred.
> +* *data* is the data that was read from the device region.
> +
> +``VFIO_USER_REGION_WRITE``
> +--------------------------
> +
> +If a device region is not mappable, it's not directly accessible by the client
> +via mmap() of the underlying fd. In this case, a client can write to a device
> +region with this message.
> +
> +Request
> +^^^^^^^
> +
> ++--------+--------+----------+
> +| Name | Offset | Size |
> ++========+========+==========+
> +| offset | 0 | 8 |
> ++--------+--------+----------+
> +| region | 8 | 4 |
> ++--------+--------+----------+
> +| count | 12 | 4 |
> ++--------+--------+----------+
> +| data | 16 | variable |
> ++--------+--------+----------+
> +
> +* *offset* into the region being accessed.
> +* *region* is the index of the region being accessed.
> +* *count* is the size of the data to be transferred.
> +* *data* is the data to write
> +
> +Reply
> +^^^^^
> +
> ++--------+--------+----------+
> +| Name | Offset | Size |
> ++========+========+==========+
> +| offset | 0 | 8 |
> ++--------+--------+----------+
> +| region | 8 | 4 |
> ++--------+--------+----------+
> +| count | 12 | 4 |
> ++--------+--------+----------+
> +
> +* *offset* into the region accessed.
> +* *region* is the index of the region accessed.
> +* *count* is the size of the data transferred.
> +
> +``VFIO_USER_DMA_READ``
> +-----------------------
> +
> +If the client has not shared mappable memory, the server can use this message to
> +read from guest memory.
> +
> +Request
> +^^^^^^^
> +
> ++---------+--------+----------+
> +| Name | Offset | Size |
> ++=========+========+==========+
> +| address | 0 | 8 |
> ++---------+--------+----------+
> +| count | 8 | 8 |
> ++---------+--------+----------+
> +
> +* *address* is the client DMA memory address being accessed. This address must have
> + been previously exported to the server with a ``VFIO_USER_DMA_MAP`` message.
> +* *count* is the size of the data to be transferred.
> +
> +Reply
> +^^^^^
> +
> ++---------+--------+----------+
> +| Name | Offset | Size |
> ++=========+========+==========+
> +| address | 0 | 8 |
> ++---------+--------+----------+
> +| count | 8 | 8 |
> ++---------+--------+----------+
> +| data | 16 | variable |
> ++---------+--------+----------+
> +
> +* *address* is the client DMA memory address being accessed.
> +* *count* is the size of the data transferred.
> +* *data* is the data read.
> +
> +``VFIO_USER_DMA_WRITE``
> +-----------------------
> +
> +If the client has not shared mappable memory, the server can use this message to
> +write to guest memory.
> +
> +Request
> +^^^^^^^
> +
> ++---------+--------+----------+
> +| Name | Offset | Size |
> ++=========+========+==========+
> +| address | 0 | 8 |
> ++---------+--------+----------+
> +| count | 8 | 8 |
> ++---------+--------+----------+
> +| data | 16 | variable |
> ++---------+--------+----------+
> +
> +* *address* is the client DMA memory address being accessed. This address must have
> + been previously exported to the server with a ``VFIO_USER_DMA_MAP`` message.
> +* *count* is the size of the data to be transferred.
> +* *data* is the data to write
> +
> +Reply
> +^^^^^
> +
> ++---------+--------+----------+
> +| Name | Offset | Size |
> ++=========+========+==========+
> +| address | 0 | 8 |
> ++---------+--------+----------+
> +| count | 8 | 4 |
> ++---------+--------+----------+
> +
> +* *address* is the client DMA memory address being accessed.
> +* *count* is the size of the data transferred.
> +
> +``VFIO_USER_DEVICE_RESET``
> +--------------------------
> +
> +This command message is sent from the client to the server to reset the device.
> +Neither the request or reply have a payload.
> +
> +``VFIO_USER_REGION_WRITE_MULTI``
> +--------------------------------
> +
> +This message can be used to coalesce multiple device write operations
> +into a single messgage. It is only used as an optimization when the
> +outgoing message queue is relatively full.
> +
> +Request
> +^^^^^^^
> +
> ++---------+--------+----------+
> +| Name | Offset | Size |
> ++=========+========+==========+
> +| wr_cnt | 0 | 8 |
> ++---------+--------+----------+
> +| wrs | 8 | variable |
> ++---------+--------+----------+
> +
> +* *wr_cnt* is the number of device writes coalesced in the message
> +* *wrs* is an array of device writes defined below
> +
> +Single Device Write Format
> +""""""""""""""""""""""""""
> +
> ++--------+--------+----------+
> +| Name | Offset | Size |
> ++========+========+==========+
> +| offset | 0 | 8 |
> ++--------+--------+----------+
> +| region | 8 | 4 |
> ++--------+--------+----------+
> +| count | 12 | 4 |
> ++--------+--------+----------+
> +| data | 16 | 8 |
> ++--------+--------+----------+
> +
> +* *offset* into the region being accessed.
> +* *region* is the index of the region being accessed.
> +* *count* is the size of the data to be transferred. This format can
> + only describe writes of 8 bytes or less.
> +* *data* is the data to write.
> +
> +Reply
> +^^^^^
> +
> ++---------+--------+----------+
> +| Name | Offset | Size |
> ++=========+========+==========+
> +| wr_cnt | 0 | 8 |
> ++---------+--------+----------+
> +
> +* *wr_cnt* is the number of device writes completed.
> +
> +
> +Appendices
> +==========
> +
> +Unused VFIO ``ioctl()`` commands
> +--------------------------------
> +
> +The following VFIO commands do not have an equivalent vfio-user command:
> +
> +* ``VFIO_GET_API_VERSION``
> +* ``VFIO_CHECK_EXTENSION``
> +* ``VFIO_SET_IOMMU``
> +* ``VFIO_GROUP_GET_STATUS``
> +* ``VFIO_GROUP_SET_CONTAINER``
> +* ``VFIO_GROUP_UNSET_CONTAINER``
> +* ``VFIO_GROUP_GET_DEVICE_FD``
> +* ``VFIO_IOMMU_GET_INFO``
> +
> +However, once support for live migration for VFIO devices is finalized some
> +of the above commands may have to be handled by the client in their
> +corresponding vfio-user form. This will be addressed in a future protocol
> +version.
> +
> +VFIO groups and containers
> +^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The current VFIO implementation includes group and container idioms that
> +describe how a device relates to the host IOMMU. In the vfio-user
> +implementation, the IOMMU is implemented in SW by the client, and is not
> +visible to the server. The simplest idea would be that the client put each
> +device into its own group and container.
> +
> +Backend Program Conventions
> +---------------------------
> +
> +vfio-user backend program conventions are based on the vhost-user ones.
> +
> +* The backend program must not daemonize itself.
> +* No assumptions must be made as to what access the backend program has on the
> + system.
> +* File descriptors 0, 1 and 2 must exist, must have regular
> + stdin/stdout/stderr semantics, and can be redirected.
> +* The backend program must honor the SIGTERM signal.
> +* The backend program must accept the following commands line options:
> +
> + * ``--socket-path=PATH``: path to UNIX domain socket,
> + * ``--fd=FDNUM``: file descriptor for UNIX domain socket, incompatible with
> + ``--socket-path``
> +* The backend program must be accompanied with a JSON file stored under
> + ``/usr/share/vfio-user``.
> +
> +TODO add schema similar to docs/interop/vhost-user.json.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 05/23] vfio-user: introduce vfio-user protocol specification
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 16:55 ` John Levon
1 sibling, 1 reply; 69+ messages in thread
From: John Levon @ 2025-06-10 9:55 UTC (permalink / raw)
To: Cédric Le Goater
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On Tue, Jun 10, 2025 at 11:38:29AM +0200, Cédric Le Goater wrote:
> > docs/devel/vfio-user.rst | 1522 ++++++++++++++++++++++++++++++++
>
> I think this file should be split in several smaller files. The
> protocol specification part belongs to "System Emulation Management
> and Interoperability" section.
I can move it to interop/ sure. Why must it be split up ? It's nearest analogue,
vhost-user.rst, is one file, and I think that's better for a protocol
specification.
> We already have a docs/system/devices/vfio-user.rst which needs some
> care.
My series adds this file. This is the user docs, including a device
example, so independent of the protocol specification.
Please let me know what care it needs!
> (and functional tests)
Mark is working on them, there are some difficulties...
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 05/23] vfio-user: introduce vfio-user protocol specification
2025-06-10 9:55 ` John Levon
@ 2025-06-10 10:12 ` Cédric Le Goater
2025-06-10 10:22 ` Mark Cave-Ayland
0 siblings, 1 reply; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-10 10:12 UTC (permalink / raw)
To: John Levon
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 6/10/25 11:55, John Levon wrote:
> On Tue, Jun 10, 2025 at 11:38:29AM +0200, Cédric Le Goater wrote:
>
>>> docs/devel/vfio-user.rst | 1522 ++++++++++++++++++++++++++++++++
>>
>> I think this file should be split in several smaller files. The
>> protocol specification part belongs to "System Emulation Management
>> and Interoperability" section.
>
> I can move it to interop/ sure. Why must it be split up ? It's nearest analogue,
> vhost-user.rst, is one file, and I think that's better for a protocol
> specification.
>
>> We already have a docs/system/devices/vfio-user.rst which needs some
>> care.
>
> My series adds this file. This is the user docs, including a device
> example, so independent of the protocol specification.
ah yes. The QEMU documentation is a bit messy. Not your fault.
> Please let me know what care it needs!
sure.
>> (and functional tests)
>
> Mark is working on them, there are some difficulties...
Which kind ? This is important to have and I will be reluctant to merge
any support without tests. It is OK to merge a dummy device implementation
for the tests since they provide a good example.
C.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 05/23] vfio-user: introduce vfio-user protocol specification
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
0 siblings, 1 reply; 69+ messages in thread
From: Mark Cave-Ayland @ 2025-06-10 10:22 UTC (permalink / raw)
To: Cédric Le Goater, John Levon
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 10/06/2025 11:12, Cédric Le Goater wrote:
> On 6/10/25 11:55, John Levon wrote:
>> On Tue, Jun 10, 2025 at 11:38:29AM +0200, Cédric Le Goater wrote:
>>
>>>> docs/devel/vfio-user.rst | 1522 +++++++++++++++++++++++++++
>>>> +++++
>>>
>>> I think this file should be split in several smaller files. The
>>> protocol specification part belongs to "System Emulation Management
>>> and Interoperability" section.
>>
>> I can move it to interop/ sure. Why must it be split up ? It's nearest
>> analogue,
>> vhost-user.rst, is one file, and I think that's better for a protocol
>> specification.
>>
>>> We already have a docs/system/devices/vfio-user.rst which needs some
>>> care.
>>
>> My series adds this file. This is the user docs, including a device
>> example, so independent of the protocol specification.
>
> ah yes. The QEMU documentation is a bit messy. Not your fault.
>
>> Please let me know what care it needs!
>
> sure.
>
>>> (and functional tests)
>>
>> Mark is working on them, there are some difficulties...
>
> Which kind ? This is important to have and I will be reluctant to merge
> any support without tests. It is OK to merge a dummy device implementation
> for the tests since they provide a good example.
>
> C.
I have a bootable test image available for testing basic functionality,
however there are a few issues with the functional test framework: in
particular the test framework doesn't currently allow logging of
multiple VM consoles correctly.
I am continuing to work on this in the background, and hope to be able
to provide an integrated functional test soon.
ATB,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 05/23] vfio-user: introduce vfio-user protocol specification
2025-06-10 10:22 ` Mark Cave-Ayland
@ 2025-06-10 13:06 ` Cédric Le Goater
0 siblings, 0 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-10 13:06 UTC (permalink / raw)
To: Mark Cave-Ayland, John Levon
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 6/10/25 12:22, Mark Cave-Ayland wrote:
> On 10/06/2025 11:12, Cédric Le Goater wrote:
>
>> On 6/10/25 11:55, John Levon wrote:
>>> On Tue, Jun 10, 2025 at 11:38:29AM +0200, Cédric Le Goater wrote:
>>>
>>>>> docs/devel/vfio-user.rst | 1522 +++++++++++++++++++++++++++ +++++
>>>>
>>>> I think this file should be split in several smaller files. The
>>>> protocol specification part belongs to "System Emulation Management
>>>> and Interoperability" section.
>>>
>>> I can move it to interop/ sure. Why must it be split up ? It's nearest analogue,
>>> vhost-user.rst, is one file, and I think that's better for a protocol
>>> specification.
>>>
>>>> We already have a docs/system/devices/vfio-user.rst which needs some
>>>> care.
>>>
>>> My series adds this file. This is the user docs, including a device
>>> example, so independent of the protocol specification.
>>
>> ah yes. The QEMU documentation is a bit messy. Not your fault.
>>
>>> Please let me know what care it needs!
>>
>> sure.
>>
>>>> (and functional tests)
>>>
>>> Mark is working on them, there are some difficulties...
>>
>> Which kind ? This is important to have and I will be reluctant to merge
>> any support without tests. It is OK to merge a dummy device implementation
>> for the tests since they provide a good example.
>>
>> C.
>
> I have a bootable test image available for testing basic functionality, however there are a few issues with the functional test framework: in particular the test framework doesn't currently allow logging of multiple VM consoles correctly.
What about test_aarch64_aspeed_ast2700fc.py which boots multiple SoCs ?
> I am continuing to work on this in the background, and hope to be able to provide an integrated functional test soon.
Nice ! That would be great.
Thanks Mark,
C.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 05/23] vfio-user: introduce vfio-user protocol specification
2025-06-10 9:38 ` Cédric Le Goater
2025-06-10 9:55 ` John Levon
@ 2025-06-10 16:55 ` John Levon
1 sibling, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-10 16:55 UTC (permalink / raw)
To: Cédric Le Goater
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On Tue, Jun 10, 2025 at 11:38:29AM +0200, Cédric Le Goater wrote:
> > +
> > +--------------
> > +Version_ 0.9.1
> > +--------------
>
> Are you planning to have a subsection per version ?
>
I've removed this, as it's not useful/meaningful at this point in time.
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 05/23] vfio-user: introduce vfio-user protocol specification
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-11 11:49 ` Cédric Le Goater
1 sibling, 0 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-11 11:49 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 6/7/25 02:10, John Levon wrote:
> From: Thanos Makatos <thanos.makatos@nutanix.com>
>
> This patch introduces the vfio-user protocol specification (formerly
> known as VFIO-over-socket), which is designed to allow devices to be
> emulated outside QEMU, in a separate process. vfio-user reuses the
> existing VFIO defines, structs and concepts.
>
> It has been earlier discussed as an RFC in:
> "RFC: use VFIO over a UNIX domain socket to implement device offloading"
>
> Signed-off-by: Thanos Makatos <thanos.makatos@nutanix.com>
> Signed-off-by: John Levon <john.levon@nutanix.com>
please put this documentation change at the end in v4.
Thanks,
C.
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH v3 06/23] vfio-user: add vfio-user class and container
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (4 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 05/23] vfio-user: introduce vfio-user protocol specification John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-10 9:57 ` Cédric Le Goater
` (2 more replies)
2025-06-07 0:10 ` [PATCH v3 07/23] vfio-user: connect vfio proxy to remote server John Levon
` (17 subsequent siblings)
23 siblings, 3 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
Introduce basic plumbing for vfio-user behind a new
--enable-vfio-user-client option.
We introduce VFIOUserContainer in hw/vfio-user/container.c, which is a
container type for the "IOMMU" type "vfio-iommu-user", and share some
common container code from hw/vfio/container.c.
Add hw/vfio-user/pci.c for instantiating VFIOUserPCIDevice objects,
sharing some common code from hw/vfio/pci.c.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
MAINTAINERS | 2 +
hw/vfio-user/container.h | 25 +++
include/hw/vfio/vfio-container-base.h | 1 +
hw/vfio-user/container.c | 212 ++++++++++++++++++++++++++
hw/vfio-user/pci.c | 155 +++++++++++++++++++
hw/meson.build | 1 +
hw/vfio-user/meson.build | 9 ++
meson_options.txt | 2 +
scripts/meson-buildoptions.sh | 4 +
9 files changed, 411 insertions(+)
create mode 100644 hw/vfio-user/container.h
create mode 100644 hw/vfio-user/container.c
create mode 100644 hw/vfio-user/pci.c
create mode 100644 hw/vfio-user/meson.build
diff --git a/MAINTAINERS b/MAINTAINERS
index dbc393989a..328bab8d19 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4252,6 +4252,8 @@ M: John Levon <john.levon@nutanix.com>
M: Thanos Makatos <thanos.makatos@nutanix.com>
S: Supported
F: docs/devel/vfio-user.rst
+F: hw/vfio-user/*
+F: include/hw/vfio-user/*
F: subprojects/libvfio-user
EBPF:
diff --git a/hw/vfio-user/container.h b/hw/vfio-user/container.h
new file mode 100644
index 0000000000..3cd3303e68
--- /dev/null
+++ b/hw/vfio-user/container.h
@@ -0,0 +1,25 @@
+/*
+ * vfio-user specific definitions.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#ifndef HW_VFIO_USER_CONTAINER_H
+#define HW_VFIO_USER_CONTAINER_H
+
+#include <inttypes.h>
+#include <stdbool.h>
+
+#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);
+
+#endif /* HW_VFIO_USER_CONTAINER_H */
diff --git a/include/hw/vfio/vfio-container-base.h b/include/hw/vfio/vfio-container-base.h
index 9d37f86115..28899ca0a6 100644
--- a/include/hw/vfio/vfio-container-base.h
+++ b/include/hw/vfio/vfio-container-base.h
@@ -109,6 +109,7 @@ vfio_container_get_page_size_mask(const VFIOContainerBase *bcontainer)
#define TYPE_VFIO_IOMMU_LEGACY TYPE_VFIO_IOMMU "-legacy"
#define TYPE_VFIO_IOMMU_SPAPR TYPE_VFIO_IOMMU "-spapr"
#define TYPE_VFIO_IOMMU_IOMMUFD TYPE_VFIO_IOMMU "-iommufd"
+#define TYPE_VFIO_IOMMU_USER TYPE_VFIO_IOMMU "-user"
OBJECT_DECLARE_TYPE(VFIOContainerBase, VFIOIOMMUClass, VFIO_IOMMU)
diff --git a/hw/vfio-user/container.c b/hw/vfio-user/container.c
new file mode 100644
index 0000000000..2892845b4f
--- /dev/null
+++ b/hw/vfio-user/container.c
@@ -0,0 +1,212 @@
+/*
+ * Container for vfio-user IOMMU type: rather than communicating with the kernel
+ * vfio driver, we communicate over a socket to a server using the vfio-user
+ * protocol.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include <sys/ioctl.h>
+#include <linux/vfio.h>
+#include "qemu/osdep.h"
+
+#include "hw/vfio-user/container.h"
+#include "hw/vfio/vfio-cpr.h"
+#include "hw/vfio/vfio-device.h"
+#include "hw/vfio/vfio-listener.h"
+#include "qapi/error.h"
+#include "trace.h"
+
+static int vfio_user_dma_unmap(const VFIOContainerBase *bcontainer,
+ hwaddr iova, ram_addr_t size,
+ IOMMUTLBEntry *iotlb, bool unmap_all)
+{
+ return -ENOTSUP;
+}
+
+static int vfio_user_dma_map(const VFIOContainerBase *bcontainer, hwaddr iova,
+ ram_addr_t size, void *vaddr, bool readonly,
+ MemoryRegion *mrp)
+{
+ return -ENOTSUP;
+}
+
+static int
+vfio_user_set_dirty_page_tracking(const VFIOContainerBase *bcontainer,
+ bool start, Error **errp)
+{
+ error_setg_errno(errp, ENOTSUP, "Not supported");
+ return -ENOTSUP;
+}
+
+static int vfio_user_query_dirty_bitmap(const VFIOContainerBase *bcontainer,
+ VFIOBitmap *vbmap, hwaddr iova,
+ hwaddr size, Error **errp)
+{
+ error_setg_errno(errp, ENOTSUP, "Not supported");
+ return -ENOTSUP;
+}
+
+static bool vfio_user_setup(VFIOContainerBase *bcontainer, Error **errp)
+{
+ error_setg_errno(errp, ENOTSUP, "Not supported");
+ return -ENOTSUP;
+}
+
+static VFIOUserContainer *vfio_user_create_container(Error **errp)
+{
+ VFIOUserContainer *container;
+
+ container = VFIO_IOMMU_USER(object_new(TYPE_VFIO_IOMMU_USER));
+ return container;
+}
+
+/*
+ * Try to mirror vfio_container_connect() as much as possible.
+ */
+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;
+
+ if (!vfio_cpr_register_container(bcontainer, errp)) {
+ goto free_container_exit;
+ }
+
+ vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
+ assert(vioc->setup);
+
+ if (!vioc->setup(bcontainer, errp)) {
+ goto unregister_container_exit;
+ }
+
+ vfio_address_space_insert(space, bcontainer);
+
+ if (!vfio_listener_register(bcontainer, errp)) {
+ goto listener_release_exit;
+ }
+
+ bcontainer->initialized = true;
+
+ return container;
+
+listener_release_exit:
+ vfio_listener_unregister(bcontainer);
+ if (vioc->release) {
+ vioc->release(bcontainer);
+ }
+
+unregister_container_exit:
+ vfio_cpr_unregister_container(bcontainer);
+
+free_container_exit:
+ object_unref(container);
+
+put_space_exit:
+ vfio_address_space_put(space);
+
+ return NULL;
+}
+
+static void vfio_user_container_disconnect(VFIOUserContainer *container)
+{
+ VFIOContainerBase *bcontainer = &container->bcontainer;
+ VFIOIOMMUClass *vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
+
+ vfio_listener_unregister(bcontainer);
+ if (vioc->release) {
+ vioc->release(bcontainer);
+ }
+
+ VFIOAddressSpace *space = bcontainer->space;
+
+ vfio_cpr_unregister_container(bcontainer);
+ object_unref(container);
+
+ vfio_address_space_put(space);
+}
+
+static bool vfio_user_device_get(VFIOUserContainer *container,
+ VFIODevice *vbasedev, Error **errp)
+{
+ struct vfio_device_info info = { 0 };
+
+ vbasedev->fd = -1;
+
+ vfio_device_prepare(vbasedev, &container->bcontainer, &info);
+
+ return true;
+}
+
+/*
+ * vfio_user_device_attach: attach a device to a new container.
+ */
+static bool vfio_user_device_attach(const char *name, VFIODevice *vbasedev,
+ AddressSpace *as, Error **errp)
+{
+ VFIOUserContainer *container;
+
+ container = vfio_user_container_connect(as, errp);
+ if (container == NULL) {
+ error_prepend(errp, "failed to connect proxy");
+ return false;
+ }
+
+ return vfio_user_device_get(container, vbasedev, errp);
+}
+
+static void vfio_user_device_detach(VFIODevice *vbasedev)
+{
+ VFIOUserContainer *container = container_of(vbasedev->bcontainer,
+ VFIOUserContainer, bcontainer);
+
+ vfio_device_unprepare(vbasedev);
+
+ vfio_user_container_disconnect(container);
+}
+
+static int vfio_user_pci_hot_reset(VFIODevice *vbasedev, bool single)
+{
+ /* ->needs_reset is always false for vfio-user. */
+ return 0;
+}
+
+static void vfio_iommu_user_class_init(ObjectClass *klass, const void *data)
+{
+ VFIOIOMMUClass *vioc = VFIO_IOMMU_CLASS(klass);
+
+ vioc->setup = vfio_user_setup;
+ vioc->dma_map = vfio_user_dma_map;
+ vioc->dma_unmap = vfio_user_dma_unmap;
+ vioc->attach_device = vfio_user_device_attach;
+ vioc->detach_device = vfio_user_device_detach;
+ vioc->set_dirty_page_tracking = vfio_user_set_dirty_page_tracking;
+ vioc->query_dirty_bitmap = vfio_user_query_dirty_bitmap;
+ vioc->pci_hot_reset = vfio_user_pci_hot_reset;
+};
+
+static const TypeInfo types[] = {
+ {
+ .name = TYPE_VFIO_IOMMU_USER,
+ .parent = TYPE_VFIO_IOMMU,
+ .instance_size = sizeof(VFIOUserContainer),
+ .class_init = vfio_iommu_user_class_init,
+ },
+};
+
+DEFINE_TYPES(types)
diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
new file mode 100644
index 0000000000..74b0c61f9b
--- /dev/null
+++ b/hw/vfio-user/pci.c
@@ -0,0 +1,155 @@
+/*
+ * vfio PCI device over a UNIX socket.
+ *
+ * Copyright © 2018, 2021 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include <sys/ioctl.h>
+#include "qemu/osdep.h"
+
+#include "hw/qdev-properties.h"
+#include "hw/vfio/pci.h"
+
+#define TYPE_VFIO_USER_PCI "vfio-user-pci"
+OBJECT_DECLARE_SIMPLE_TYPE(VFIOUserPCIDevice, VFIO_USER_PCI)
+
+struct VFIOUserPCIDevice {
+ VFIOPCIDevice device;
+ char *sock_name;
+};
+
+/*
+ * Emulated devices don't use host hot reset
+ */
+static void vfio_user_compute_needs_reset(VFIODevice *vbasedev)
+{
+ vbasedev->needs_reset = false;
+}
+
+static Object *vfio_user_pci_get_object(VFIODevice *vbasedev)
+{
+ VFIOUserPCIDevice *vdev = container_of(vbasedev, VFIOUserPCIDevice,
+ device.vbasedev);
+
+ return OBJECT(vdev);
+}
+
+static VFIODeviceOps vfio_user_pci_ops = {
+ .vfio_compute_needs_reset = vfio_user_compute_needs_reset,
+ .vfio_eoi = vfio_pci_intx_eoi,
+ .vfio_get_object = vfio_user_pci_get_object,
+ /* No live migration support yet. */
+ .vfio_save_config = NULL,
+ .vfio_load_config = NULL,
+};
+
+static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
+{
+ ERRP_GUARD();
+ VFIOUserPCIDevice *udev = VFIO_USER_PCI(pdev);
+ VFIOPCIDevice *vdev = VFIO_PCI_BASE(pdev);
+ VFIODevice *vbasedev = &vdev->vbasedev;
+ AddressSpace *as;
+
+ /*
+ * TODO: make option parser understand SocketAddress
+ * and use that instead of having scalar options
+ * for each socket type.
+ */
+ if (!udev->sock_name) {
+ error_setg(errp, "No socket specified");
+ error_append_hint(errp, "Use -device vfio-user-pci,socket=<name>\n");
+ return;
+ }
+
+ vbasedev->name = g_strdup_printf("VFIO user <%s>", udev->sock_name);
+
+ /*
+ * vfio-user devices are effectively mdevs (don't use a host iommu).
+ */
+ vbasedev->mdev = true;
+
+ as = pci_device_iommu_address_space(pdev);
+ if (!vfio_device_attach_by_iommu_type(TYPE_VFIO_IOMMU_USER,
+ vbasedev->name, vbasedev,
+ as, errp)) {
+ error_prepend(errp, VFIO_MSG_PREFIX, vbasedev->name);
+ return;
+ }
+}
+
+static void vfio_user_instance_init(Object *obj)
+{
+ PCIDevice *pci_dev = PCI_DEVICE(obj);
+ VFIOPCIDevice *vdev = VFIO_PCI_BASE(obj);
+ VFIODevice *vbasedev = &vdev->vbasedev;
+
+ device_add_bootindex_property(obj, &vdev->bootindex,
+ "bootindex", NULL,
+ &pci_dev->qdev);
+ vdev->host.domain = ~0U;
+ vdev->host.bus = ~0U;
+ vdev->host.slot = ~0U;
+ vdev->host.function = ~0U;
+
+ vfio_device_init(vbasedev, VFIO_DEVICE_TYPE_PCI, &vfio_user_pci_ops,
+ DEVICE(vdev), false);
+
+ vdev->nv_gpudirect_clique = 0xFF;
+
+ /*
+ * QEMU_PCI_CAP_EXPRESS initialization does not depend on QEMU command
+ * line, therefore, no need to wait to realize like other devices.
+ */
+ pci_dev->cap_present |= QEMU_PCI_CAP_EXPRESS;
+}
+
+static void vfio_user_instance_finalize(Object *obj)
+{
+ VFIOPCIDevice *vdev = VFIO_PCI_BASE(obj);
+
+ vfio_pci_put_device(vdev);
+}
+
+static const Property vfio_user_pci_dev_properties[] = {
+ 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_STRING("socket", VFIOUserPCIDevice, sock_name),
+};
+
+static void vfio_user_pci_dev_class_init(ObjectClass *klass, const void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ PCIDeviceClass *pdc = PCI_DEVICE_CLASS(klass);
+
+ device_class_set_props(dc, vfio_user_pci_dev_properties);
+ dc->desc = "VFIO over socket PCI device assignment";
+ pdc->realize = vfio_user_pci_realize;
+}
+
+static const TypeInfo vfio_user_pci_dev_info = {
+ .name = TYPE_VFIO_USER_PCI,
+ .parent = TYPE_VFIO_PCI_BASE,
+ .instance_size = sizeof(VFIOUserPCIDevice),
+ .class_init = vfio_user_pci_dev_class_init,
+ .instance_init = vfio_user_instance_init,
+ .instance_finalize = vfio_user_instance_finalize,
+};
+
+static void register_vfio_user_dev_type(void)
+{
+ type_register_static(&vfio_user_pci_dev_info);
+}
+
+ type_init(register_vfio_user_dev_type)
diff --git a/hw/meson.build b/hw/meson.build
index b91f761fe0..791ce21ab4 100644
--- a/hw/meson.build
+++ b/hw/meson.build
@@ -39,6 +39,7 @@ subdir('uefi')
subdir('ufs')
subdir('usb')
subdir('vfio')
+subdir('vfio-user')
subdir('virtio')
subdir('vmapple')
subdir('watchdog')
diff --git a/hw/vfio-user/meson.build b/hw/vfio-user/meson.build
new file mode 100644
index 0000000000..f1fee70c85
--- /dev/null
+++ b/hw/vfio-user/meson.build
@@ -0,0 +1,9 @@
+vfio_user_ss = ss.source_set()
+vfio_user_ss.add(files(
+ 'container.c',
+ 'pci.c',
+))
+
+if get_option('vfio_user_client').enabled()
+ specific_ss.add_all(vfio_user_ss)
+endif
diff --git a/meson_options.txt b/meson_options.txt
index a442be2995..97d3db44cd 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -109,6 +109,8 @@ option('multiprocess', type: 'feature', value: 'auto',
description: 'Out of process device emulation support')
option('relocatable', type : 'boolean', value : true,
description: 'toggle relocatable install')
+option('vfio_user_client', type: 'feature', value: 'disabled',
+ description: 'vfio-user client support')
option('vfio_user_server', type: 'feature', value: 'disabled',
description: 'vfio-user server support')
option('dbus_display', type: 'feature', value: 'auto',
diff --git a/scripts/meson-buildoptions.sh b/scripts/meson-buildoptions.sh
index f09ef9604f..2c5673769a 100644
--- a/scripts/meson-buildoptions.sh
+++ b/scripts/meson-buildoptions.sh
@@ -201,6 +201,8 @@ meson_options_help() {
printf "%s\n" ' vdi vdi image format support'
printf "%s\n" ' vduse-blk-export'
printf "%s\n" ' VDUSE block export support'
+ printf "%s\n" ' vfio-user-client'
+ printf "%s\n" ' vfio-user client support'
printf "%s\n" ' vfio-user-server'
printf "%s\n" ' vfio-user server support'
printf "%s\n" ' vhdx vhdx image format support'
@@ -529,6 +531,8 @@ _meson_option_parse() {
--disable-vdi) printf "%s" -Dvdi=disabled ;;
--enable-vduse-blk-export) printf "%s" -Dvduse_blk_export=enabled ;;
--disable-vduse-blk-export) printf "%s" -Dvduse_blk_export=disabled ;;
+ --enable-vfio-user-client) printf "%s" -Dvfio_user_client=enabled ;;
+ --disable-vfio-user-client) printf "%s" -Dvfio_user_client=disabled ;;
--enable-vfio-user-server) printf "%s" -Dvfio_user_server=enabled ;;
--disable-vfio-user-server) printf "%s" -Dvfio_user_server=disabled ;;
--enable-vhdx) printf "%s" -Dvhdx=enabled ;;
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH v3 06/23] vfio-user: add vfio-user class and container
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-10 11:42 ` Mark Cave-Ayland
2025-06-12 6:39 ` Cédric Le Goater
2 siblings, 1 reply; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-10 9:57 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, John Johnson, Elena Ufimtseva,
Jagannathan Raman
On 6/7/25 02:10, John Levon wrote:
> Introduce basic plumbing for vfio-user behind a new
> --enable-vfio-user-client option.
>
> We introduce VFIOUserContainer in hw/vfio-user/container.c, which is a
> container type for the "IOMMU" type "vfio-iommu-user", and share some
> common container code from hw/vfio/container.c.
>
> Add hw/vfio-user/pci.c for instantiating VFIOUserPCIDevice objects,
> sharing some common code from hw/vfio/pci.c.
>
> Originally-by: John Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: John Levon <john.levon@nutanix.com>
> ---
> MAINTAINERS | 2 +
> hw/vfio-user/container.h | 25 +++
> include/hw/vfio/vfio-container-base.h | 1 +
> hw/vfio-user/container.c | 212 ++++++++++++++++++++++++++
> hw/vfio-user/pci.c | 155 +++++++++++++++++++
> hw/meson.build | 1 +
> hw/vfio-user/meson.build | 9 ++
> meson_options.txt | 2 +
> scripts/meson-buildoptions.sh | 4 +
> 9 files changed, 411 insertions(+)
> create mode 100644 hw/vfio-user/container.h
> create mode 100644 hw/vfio-user/container.c
> create mode 100644 hw/vfio-user/pci.c
> create mode 100644 hw/vfio-user/meson.build
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index dbc393989a..328bab8d19 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4252,6 +4252,8 @@ M: John Levon <john.levon@nutanix.com>
> M: Thanos Makatos <thanos.makatos@nutanix.com>
> S: Supported
> F: docs/devel/vfio-user.rst
> +F: hw/vfio-user/*
> +F: include/hw/vfio-user/*
> F: subprojects/libvfio-user
>
> EBPF:
> diff --git a/hw/vfio-user/container.h b/hw/vfio-user/container.h
> new file mode 100644
> index 0000000000..3cd3303e68
> --- /dev/null
> +++ b/hw/vfio-user/container.h
> @@ -0,0 +1,25 @@
> +/*
> + * vfio-user specific definitions.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2. See
> + * the COPYING file in the top-level directory.
Please drop the license boiler plate. This is redundant with SPDX.
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */> +
> +#ifndef HW_VFIO_USER_CONTAINER_H
> +#define HW_VFIO_USER_CONTAINER_H
> +
> +#include <inttypes.h>
> +#include <stdbool.h>
> +
> +#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);
> +
> +#endif /* HW_VFIO_USER_CONTAINER_H */
> diff --git a/include/hw/vfio/vfio-container-base.h b/include/hw/vfio/vfio-container-base.h
> index 9d37f86115..28899ca0a6 100644
> --- a/include/hw/vfio/vfio-container-base.h
> +++ b/include/hw/vfio/vfio-container-base.h
> @@ -109,6 +109,7 @@ vfio_container_get_page_size_mask(const VFIOContainerBase *bcontainer)
> #define TYPE_VFIO_IOMMU_LEGACY TYPE_VFIO_IOMMU "-legacy"
> #define TYPE_VFIO_IOMMU_SPAPR TYPE_VFIO_IOMMU "-spapr"
> #define TYPE_VFIO_IOMMU_IOMMUFD TYPE_VFIO_IOMMU "-iommufd"
> +#define TYPE_VFIO_IOMMU_USER TYPE_VFIO_IOMMU "-user"
>
> OBJECT_DECLARE_TYPE(VFIOContainerBase, VFIOIOMMUClass, VFIO_IOMMU)
>
> diff --git a/hw/vfio-user/container.c b/hw/vfio-user/container.c
> new file mode 100644
> index 0000000000..2892845b4f
> --- /dev/null
> +++ b/hw/vfio-user/container.c
> @@ -0,0 +1,212 @@
> +/*
> + * Container for vfio-user IOMMU type: rather than communicating with the kernel
> + * vfio driver, we communicate over a socket to a server using the vfio-user
> + * protocol.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2. See
> + * the COPYING file in the top-level directory.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#include <sys/ioctl.h>
> +#include <linux/vfio.h>
> +#include "qemu/osdep.h"
> +
> +#include "hw/vfio-user/container.h"
> +#include "hw/vfio/vfio-cpr.h"
> +#include "hw/vfio/vfio-device.h"
> +#include "hw/vfio/vfio-listener.h"
> +#include "qapi/error.h"
> +#include "trace.h"
> +
> +static int vfio_user_dma_unmap(const VFIOContainerBase *bcontainer,
> + hwaddr iova, ram_addr_t size,
> + IOMMUTLBEntry *iotlb, bool unmap_all)
> +{
> + return -ENOTSUP;
> +}
> +
> +static int vfio_user_dma_map(const VFIOContainerBase *bcontainer, hwaddr iova,
> + ram_addr_t size, void *vaddr, bool readonly,
> + MemoryRegion *mrp)
> +{
> + return -ENOTSUP;
> +}
> +
> +static int
> +vfio_user_set_dirty_page_tracking(const VFIOContainerBase *bcontainer,
> + bool start, Error **errp)
> +{
> + error_setg_errno(errp, ENOTSUP, "Not supported");
> + return -ENOTSUP;
> +}
> +
> +static int vfio_user_query_dirty_bitmap(const VFIOContainerBase *bcontainer,
> + VFIOBitmap *vbmap, hwaddr iova,
> + hwaddr size, Error **errp)
> +{
> + error_setg_errno(errp, ENOTSUP, "Not supported");
> + return -ENOTSUP;
> +}
> +
> +static bool vfio_user_setup(VFIOContainerBase *bcontainer, Error **errp)
> +{
> + error_setg_errno(errp, ENOTSUP, "Not supported");
> + return -ENOTSUP;
> +}
> +
> +static VFIOUserContainer *vfio_user_create_container(Error **errp)
> +{
> + VFIOUserContainer *container;
> +
> + container = VFIO_IOMMU_USER(object_new(TYPE_VFIO_IOMMU_USER));
> + return container;
> +}
> +
> +/*
> + * Try to mirror vfio_container_connect() as much as possible.
> + */
> +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;
> +
> + if (!vfio_cpr_register_container(bcontainer, errp)) {
> + goto free_container_exit;
> + }
> +
> + vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
> + assert(vioc->setup);
> +
> + if (!vioc->setup(bcontainer, errp)) {
> + goto unregister_container_exit;
> + }
> +
> + vfio_address_space_insert(space, bcontainer);
> +
> + if (!vfio_listener_register(bcontainer, errp)) {
> + goto listener_release_exit;
> + }
> +
> + bcontainer->initialized = true;
> +
> + return container;
> +
> +listener_release_exit:
> + vfio_listener_unregister(bcontainer);
> + if (vioc->release) {
> + vioc->release(bcontainer);
> + }
> +
> +unregister_container_exit:
> + vfio_cpr_unregister_container(bcontainer);
> +
> +free_container_exit:
> + object_unref(container);
> +
> +put_space_exit:
> + vfio_address_space_put(space);
> +
> + return NULL;
> +}
> +
> +static void vfio_user_container_disconnect(VFIOUserContainer *container)
> +{
> + VFIOContainerBase *bcontainer = &container->bcontainer;
> + VFIOIOMMUClass *vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
> +
> + vfio_listener_unregister(bcontainer);
> + if (vioc->release) {
> + vioc->release(bcontainer);
> + }
> +
> + VFIOAddressSpace *space = bcontainer->space;
> +
> + vfio_cpr_unregister_container(bcontainer);
> + object_unref(container);
> +
> + vfio_address_space_put(space);
> +}
> +
> +static bool vfio_user_device_get(VFIOUserContainer *container,
> + VFIODevice *vbasedev, Error **errp)
> +{
> + struct vfio_device_info info = { 0 };
> +
> + vbasedev->fd = -1;
> +
> + vfio_device_prepare(vbasedev, &container->bcontainer, &info);
> +
> + return true;
> +}
> +
> +/*
> + * vfio_user_device_attach: attach a device to a new container.
> + */
> +static bool vfio_user_device_attach(const char *name, VFIODevice *vbasedev,
> + AddressSpace *as, Error **errp)
> +{
> + VFIOUserContainer *container;
> +
> + container = vfio_user_container_connect(as, errp);
> + if (container == NULL) {
> + error_prepend(errp, "failed to connect proxy");
> + return false;
> + }
> +
> + return vfio_user_device_get(container, vbasedev, errp);
> +}
> +
> +static void vfio_user_device_detach(VFIODevice *vbasedev)
> +{
> + VFIOUserContainer *container = container_of(vbasedev->bcontainer,
> + VFIOUserContainer, bcontainer);
> +
> + vfio_device_unprepare(vbasedev);
> +
> + vfio_user_container_disconnect(container);
> +}
> +
> +static int vfio_user_pci_hot_reset(VFIODevice *vbasedev, bool single)
> +{
> + /* ->needs_reset is always false for vfio-user. */
> + return 0;
> +}
> +
> +static void vfio_iommu_user_class_init(ObjectClass *klass, const void *data)
> +{
> + VFIOIOMMUClass *vioc = VFIO_IOMMU_CLASS(klass);
> +
> + vioc->setup = vfio_user_setup;
> + vioc->dma_map = vfio_user_dma_map;
> + vioc->dma_unmap = vfio_user_dma_unmap;
> + vioc->attach_device = vfio_user_device_attach;
> + vioc->detach_device = vfio_user_device_detach;
> + vioc->set_dirty_page_tracking = vfio_user_set_dirty_page_tracking;
> + vioc->query_dirty_bitmap = vfio_user_query_dirty_bitmap;
> + vioc->pci_hot_reset = vfio_user_pci_hot_reset;
> +};
> +
> +static const TypeInfo types[] = {
> + {
> + .name = TYPE_VFIO_IOMMU_USER,
> + .parent = TYPE_VFIO_IOMMU,
> + .instance_size = sizeof(VFIOUserContainer),
> + .class_init = vfio_iommu_user_class_init,
> + },
> +};
> +
> +DEFINE_TYPES(types)
> diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
> new file mode 100644
> index 0000000000..74b0c61f9b
> --- /dev/null
> +++ b/hw/vfio-user/pci.c
> @@ -0,0 +1,155 @@
> +/*
> + * vfio PCI device over a UNIX socket.
> + *
> + * Copyright © 2018, 2021 Oracle and/or its affiliates.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#include <sys/ioctl.h>
> +#include "qemu/osdep.h"
> +
> +#include "hw/qdev-properties.h"
> +#include "hw/vfio/pci.h"
> +
> +#define TYPE_VFIO_USER_PCI "vfio-user-pci"
> +OBJECT_DECLARE_SIMPLE_TYPE(VFIOUserPCIDevice, VFIO_USER_PCI)
> +
> +struct VFIOUserPCIDevice {
> + VFIOPCIDevice device;
> + char *sock_name;
> +};
> +
> +/*
> + * Emulated devices don't use host hot reset
> + */
> +static void vfio_user_compute_needs_reset(VFIODevice *vbasedev)
> +{
> + vbasedev->needs_reset = false;
> +}
> +
> +static Object *vfio_user_pci_get_object(VFIODevice *vbasedev)
> +{
> + VFIOUserPCIDevice *vdev = container_of(vbasedev, VFIOUserPCIDevice,
> + device.vbasedev);
> +
> + return OBJECT(vdev);
> +}
> +
> +static VFIODeviceOps vfio_user_pci_ops = {
> + .vfio_compute_needs_reset = vfio_user_compute_needs_reset,
> + .vfio_eoi = vfio_pci_intx_eoi,
> + .vfio_get_object = vfio_user_pci_get_object,
> + /* No live migration support yet. */
> + .vfio_save_config = NULL,
> + .vfio_load_config = NULL,
> +};
> +
> +static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
> +{
> + ERRP_GUARD();
> + VFIOUserPCIDevice *udev = VFIO_USER_PCI(pdev);
> + VFIOPCIDevice *vdev = VFIO_PCI_BASE(pdev);
> + VFIODevice *vbasedev = &vdev->vbasedev;
> + AddressSpace *as;
> +
> + /*
> + * TODO: make option parser understand SocketAddress
> + * and use that instead of having scalar options
> + * for each socket type.
> + */
> + if (!udev->sock_name) {
> + error_setg(errp, "No socket specified");
> + error_append_hint(errp, "Use -device vfio-user-pci,socket=<name>\n");
> + return;
> + }
> +
> + vbasedev->name = g_strdup_printf("VFIO user <%s>", udev->sock_name);
> +
> + /*
> + * vfio-user devices are effectively mdevs (don't use a host iommu).
> + */
> + vbasedev->mdev = true;
> +
> + as = pci_device_iommu_address_space(pdev);
> + if (!vfio_device_attach_by_iommu_type(TYPE_VFIO_IOMMU_USER,
> + vbasedev->name, vbasedev,
> + as, errp)) {
> + error_prepend(errp, VFIO_MSG_PREFIX, vbasedev->name);
> + return;
> + }
> +}
> +
> +static void vfio_user_instance_init(Object *obj)
> +{
> + PCIDevice *pci_dev = PCI_DEVICE(obj);
> + VFIOPCIDevice *vdev = VFIO_PCI_BASE(obj);
> + VFIODevice *vbasedev = &vdev->vbasedev;
> +
> + device_add_bootindex_property(obj, &vdev->bootindex,
> + "bootindex", NULL,
> + &pci_dev->qdev);
> + vdev->host.domain = ~0U;
> + vdev->host.bus = ~0U;
> + vdev->host.slot = ~0U;
> + vdev->host.function = ~0U;
> +
> + vfio_device_init(vbasedev, VFIO_DEVICE_TYPE_PCI, &vfio_user_pci_ops,
> + DEVICE(vdev), false);
> +
> + vdev->nv_gpudirect_clique = 0xFF;
> +
> + /*
> + * QEMU_PCI_CAP_EXPRESS initialization does not depend on QEMU command
> + * line, therefore, no need to wait to realize like other devices.
> + */
> + pci_dev->cap_present |= QEMU_PCI_CAP_EXPRESS;
> +}
> +
> +static void vfio_user_instance_finalize(Object *obj)
> +{
> + VFIOPCIDevice *vdev = VFIO_PCI_BASE(obj);
> +
> + vfio_pci_put_device(vdev);
> +}
> +
> +static const Property vfio_user_pci_dev_properties[] = {
> + 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_STRING("socket", VFIOUserPCIDevice, sock_name),
> +};
> +
> +static void vfio_user_pci_dev_class_init(ObjectClass *klass, const void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> + PCIDeviceClass *pdc = PCI_DEVICE_CLASS(klass);
> +
> + device_class_set_props(dc, vfio_user_pci_dev_properties);
> + dc->desc = "VFIO over socket PCI device assignment";
> + pdc->realize = vfio_user_pci_realize;
> +}
> +
> +static const TypeInfo vfio_user_pci_dev_info = {
> + .name = TYPE_VFIO_USER_PCI,
> + .parent = TYPE_VFIO_PCI_BASE,
> + .instance_size = sizeof(VFIOUserPCIDevice),
> + .class_init = vfio_user_pci_dev_class_init,
> + .instance_init = vfio_user_instance_init,
> + .instance_finalize = vfio_user_instance_finalize,
> +};
> +
> +static void register_vfio_user_dev_type(void)
> +{
> + type_register_static(&vfio_user_pci_dev_info);
> +}
> +
> + type_init(register_vfio_user_dev_type)
> diff --git a/hw/meson.build b/hw/meson.build
> index b91f761fe0..791ce21ab4 100644
> --- a/hw/meson.build
> +++ b/hw/meson.build
> @@ -39,6 +39,7 @@ subdir('uefi')
> subdir('ufs')
> subdir('usb')
> subdir('vfio')
> +subdir('vfio-user')
> subdir('virtio')
> subdir('vmapple')
> subdir('watchdog')
> diff --git a/hw/vfio-user/meson.build b/hw/vfio-user/meson.build
> new file mode 100644
> index 0000000000..f1fee70c85
> --- /dev/null
> +++ b/hw/vfio-user/meson.build
> @@ -0,0 +1,9 @@
> +vfio_user_ss = ss.source_set()
> +vfio_user_ss.add(files(
> + 'container.c',
> + 'pci.c',
> +))
> +
> +if get_option('vfio_user_client').enabled()
> + specific_ss.add_all(vfio_user_ss)
> +endif
> diff --git a/meson_options.txt b/meson_options.txt
> index a442be2995..97d3db44cd 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -109,6 +109,8 @@ option('multiprocess', type: 'feature', value: 'auto',
> description: 'Out of process device emulation support')
> option('relocatable', type : 'boolean', value : true,
> description: 'toggle relocatable install')
> +option('vfio_user_client', type: 'feature', value: 'disabled',
> + description: 'vfio-user client support')
> option('vfio_user_server', type: 'feature', value: 'disabled',
> description: 'vfio-user server support')
> option('dbus_display', type: 'feature', value: 'auto',
> diff --git a/scripts/meson-buildoptions.sh b/scripts/meson-buildoptions.sh
> index f09ef9604f..2c5673769a 100644
> --- a/scripts/meson-buildoptions.sh
> +++ b/scripts/meson-buildoptions.sh
> @@ -201,6 +201,8 @@ meson_options_help() {
> printf "%s\n" ' vdi vdi image format support'
> printf "%s\n" ' vduse-blk-export'
> printf "%s\n" ' VDUSE block export support'
> + printf "%s\n" ' vfio-user-client'
> + printf "%s\n" ' vfio-user client support'
> printf "%s\n" ' vfio-user-server'
> printf "%s\n" ' vfio-user server support'
> printf "%s\n" ' vhdx vhdx image format support'
> @@ -529,6 +531,8 @@ _meson_option_parse() {
> --disable-vdi) printf "%s" -Dvdi=disabled ;;
> --enable-vduse-blk-export) printf "%s" -Dvduse_blk_export=enabled ;;
> --disable-vduse-blk-export) printf "%s" -Dvduse_blk_export=disabled ;;
> + --enable-vfio-user-client) printf "%s" -Dvfio_user_client=enabled ;;
> + --disable-vfio-user-client) printf "%s" -Dvfio_user_client=disabled ;;
> --enable-vfio-user-server) printf "%s" -Dvfio_user_server=enabled ;;
> --disable-vfio-user-server) printf "%s" -Dvfio_user_server=disabled ;;
> --enable-vhdx) printf "%s" -Dvhdx=enabled ;;
can't we simply have a CONFIG option and select the device on platforms
supporting it ?
Thanks,
C.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 06/23] vfio-user: add vfio-user class and container
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
0 siblings, 1 reply; 69+ messages in thread
From: John Levon @ 2025-06-10 16:52 UTC (permalink / raw)
To: Cédric Le Goater
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, John Johnson, Elena Ufimtseva,
Jagannathan Raman
On Tue, Jun 10, 2025 at 11:57:00AM +0200, Cédric Le Goater wrote:
> > @@ -529,6 +531,8 @@ _meson_option_parse() {
> > --disable-vdi) printf "%s" -Dvdi=disabled ;;
> > --enable-vduse-blk-export) printf "%s" -Dvduse_blk_export=enabled ;;
> > --disable-vduse-blk-export) printf "%s" -Dvduse_blk_export=disabled ;;
> > + --enable-vfio-user-client) printf "%s" -Dvfio_user_client=enabled ;;
> > + --disable-vfio-user-client) printf "%s" -Dvfio_user_client=disabled ;;
> > --enable-vfio-user-server) printf "%s" -Dvfio_user_server=enabled ;;
> > --disable-vfio-user-server) printf "%s" -Dvfio_user_server=disabled ;;
> > --enable-vhdx) printf "%s" -Dvhdx=enabled ;;
>
> can't we simply have a CONFIG option and select the device on platforms
> supporting it ?
You mean always build vfio-user client rather than optionally? Why would it be
different from other optional components?
AFAIK all platforms (at least in theory) would support it.
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 06/23] vfio-user: add vfio-user class and container
2025-06-10 16:52 ` John Levon
@ 2025-06-11 7:46 ` Cédric Le Goater
2025-06-11 8:58 ` John Levon
0 siblings, 1 reply; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-11 7:46 UTC (permalink / raw)
To: John Levon
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, John Johnson, Elena Ufimtseva,
Jagannathan Raman
On 6/10/25 18:52, John Levon wrote:
> On Tue, Jun 10, 2025 at 11:57:00AM +0200, Cédric Le Goater wrote:
>
>>> @@ -529,6 +531,8 @@ _meson_option_parse() {
>>> --disable-vdi) printf "%s" -Dvdi=disabled ;;
>>> --enable-vduse-blk-export) printf "%s" -Dvduse_blk_export=enabled ;;
>>> --disable-vduse-blk-export) printf "%s" -Dvduse_blk_export=disabled ;;
>>> + --enable-vfio-user-client) printf "%s" -Dvfio_user_client=enabled ;;
>>> + --disable-vfio-user-client) printf "%s" -Dvfio_user_client=disabled ;;
>>> --enable-vfio-user-server) printf "%s" -Dvfio_user_server=enabled ;;
>>> --disable-vfio-user-server) printf "%s" -Dvfio_user_server=disabled ;;
>>> --enable-vhdx) printf "%s" -Dvhdx=enabled ;;
>>
>> can't we simply have a CONFIG option and select the device on platforms
>> supporting it ?
>
> You mean always build vfio-user client rather than optionally? Why would it be
> different from other optional components?
why would it be optional ? I don't see any dependency for vfio-user-client.
vfio-user-server depends on libvfio-user [1]. Not vfio-user-client.
Should it ?
Does this mean we are abandoning libvfio-user ? Sorry I am not familiar with
this framework.
> AFAIK all platforms (at least in theory) would support it.
So what would be the reason for not compiling it ? It is not different
from VFIO AFAICT.
Thanks,
C.
[1] https://gitlab.com/qemu-project/libvfio-user
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 06/23] vfio-user: add vfio-user class and container
2025-06-11 7:46 ` Cédric Le Goater
@ 2025-06-11 8:58 ` John Levon
0 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-11 8:58 UTC (permalink / raw)
To: Cédric Le Goater
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, John Johnson, Elena Ufimtseva,
Jagannathan Raman
On Wed, Jun 11, 2025 at 09:46:15AM +0200, Cédric Le Goater wrote:
> > > can't we simply have a CONFIG option and select the device on platforms
> > > supporting it ?
> >
> > You mean always build vfio-user client rather than optionally? Why would it be
> > different from other optional components?
>
> why would it be optional ? I don't see any dependency for vfio-user-client.
> vfio-user-server depends on libvfio-user [1]. Not vfio-user-client.
> Should it ?
libvfio-user is for the server side, you are correct that the client does not
depend on it at all. (It's still actively in use.)
> > AFAIK all platforms (at least in theory) would support it.
>
> So what would be the reason for not compiling it ? It is not different
> from VFIO AFAICT.
OK, thanks. I simply didn't know qemu policy on building things in by default.
Of course I would be very happy to see it built into every qemu :)
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 06/23] vfio-user: add vfio-user class and container
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 11:42 ` Mark Cave-Ayland
2025-06-10 11:56 ` John Levon
2025-06-10 12:13 ` Cédric Le Goater
2025-06-12 6:39 ` Cédric Le Goater
2 siblings, 2 replies; 69+ messages in thread
From: Mark Cave-Ayland @ 2025-06-10 11:42 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Johnson, Elena Ufimtseva,
Jagannathan Raman
On 07/06/2025 01:10, John Levon wrote:
> Introduce basic plumbing for vfio-user behind a new
> --enable-vfio-user-client option.
>
> We introduce VFIOUserContainer in hw/vfio-user/container.c, which is a
> container type for the "IOMMU" type "vfio-iommu-user", and share some
> common container code from hw/vfio/container.c.
>
> Add hw/vfio-user/pci.c for instantiating VFIOUserPCIDevice objects,
> sharing some common code from hw/vfio/pci.c.
>
> Originally-by: John Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: John Levon <john.levon@nutanix.com>
> ---
> MAINTAINERS | 2 +
> hw/vfio-user/container.h | 25 +++
> include/hw/vfio/vfio-container-base.h | 1 +
> hw/vfio-user/container.c | 212 ++++++++++++++++++++++++++
> hw/vfio-user/pci.c | 155 +++++++++++++++++++
> hw/meson.build | 1 +
> hw/vfio-user/meson.build | 9 ++
> meson_options.txt | 2 +
> scripts/meson-buildoptions.sh | 4 +
> 9 files changed, 411 insertions(+)
> create mode 100644 hw/vfio-user/container.h
> create mode 100644 hw/vfio-user/container.c
> create mode 100644 hw/vfio-user/pci.c
> create mode 100644 hw/vfio-user/meson.build
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index dbc393989a..328bab8d19 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4252,6 +4252,8 @@ M: John Levon <john.levon@nutanix.com>
> M: Thanos Makatos <thanos.makatos@nutanix.com>
> S: Supported
> F: docs/devel/vfio-user.rst
> +F: hw/vfio-user/*
> +F: include/hw/vfio-user/*
> F: subprojects/libvfio-user
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.
Cédric, what are your thoughts here?
> EBPF:
> diff --git a/hw/vfio-user/container.h b/hw/vfio-user/container.h
> new file mode 100644
> index 0000000000..3cd3303e68
> --- /dev/null
> +++ b/hw/vfio-user/container.h
> @@ -0,0 +1,25 @@
> +/*
> + * vfio-user specific definitions.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2. See
> + * the COPYING file in the top-level directory.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#ifndef HW_VFIO_USER_CONTAINER_H
> +#define HW_VFIO_USER_CONTAINER_H
> +
> +#include <inttypes.h>
> +#include <stdbool.h>
These shouldn't be included directly: you probably just want:
#include "qemu/osdep.h"
instead.
> +#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);
> +#endif /* HW_VFIO_USER_CONTAINER_H */
> diff --git a/include/hw/vfio/vfio-container-base.h b/include/hw/vfio/vfio-container-base.h
> index 9d37f86115..28899ca0a6 100644
> --- a/include/hw/vfio/vfio-container-base.h
> +++ b/include/hw/vfio/vfio-container-base.h
> @@ -109,6 +109,7 @@ vfio_container_get_page_size_mask(const VFIOContainerBase *bcontainer)
> #define TYPE_VFIO_IOMMU_LEGACY TYPE_VFIO_IOMMU "-legacy"
> #define TYPE_VFIO_IOMMU_SPAPR TYPE_VFIO_IOMMU "-spapr"
> #define TYPE_VFIO_IOMMU_IOMMUFD TYPE_VFIO_IOMMU "-iommufd"
> +#define TYPE_VFIO_IOMMU_USER TYPE_VFIO_IOMMU "-user"
>
> OBJECT_DECLARE_TYPE(VFIOContainerBase, VFIOIOMMUClass, VFIO_IOMMU)
>
> diff --git a/hw/vfio-user/container.c b/hw/vfio-user/container.c
> new file mode 100644
> index 0000000000..2892845b4f
> --- /dev/null
> +++ b/hw/vfio-user/container.c
> @@ -0,0 +1,212 @@
> +/*
> + * Container for vfio-user IOMMU type: rather than communicating with the kernel
> + * vfio driver, we communicate over a socket to a server using the vfio-user
> + * protocol.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2. See
> + * the COPYING file in the top-level directory.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#include <sys/ioctl.h>
> +#include <linux/vfio.h>
> +#include "qemu/osdep.h"
> +
> +#include "hw/vfio-user/container.h"
> +#include "hw/vfio/vfio-cpr.h"
> +#include "hw/vfio/vfio-device.h"
> +#include "hw/vfio/vfio-listener.h"
> +#include "qapi/error.h"
> +#include "trace.h"
> +
> +static int vfio_user_dma_unmap(const VFIOContainerBase *bcontainer,
> + hwaddr iova, ram_addr_t size,
> + IOMMUTLBEntry *iotlb, bool unmap_all)
> +{
> + return -ENOTSUP;
> +}
> +
> +static int vfio_user_dma_map(const VFIOContainerBase *bcontainer, hwaddr iova,
> + ram_addr_t size, void *vaddr, bool readonly,
> + MemoryRegion *mrp)
> +{
> + return -ENOTSUP;
> +}
> +
> +static int
> +vfio_user_set_dirty_page_tracking(const VFIOContainerBase *bcontainer,
> + bool start, Error **errp)
> +{
> + error_setg_errno(errp, ENOTSUP, "Not supported");
> + return -ENOTSUP;
> +}
> +
> +static int vfio_user_query_dirty_bitmap(const VFIOContainerBase *bcontainer,
> + VFIOBitmap *vbmap, hwaddr iova,
> + hwaddr size, Error **errp)
> +{
> + error_setg_errno(errp, ENOTSUP, "Not supported");
> + return -ENOTSUP;
> +}
> +
> +static bool vfio_user_setup(VFIOContainerBase *bcontainer, Error **errp)
> +{
> + error_setg_errno(errp, ENOTSUP, "Not supported");
> + return -ENOTSUP;
> +}
> +
> +static VFIOUserContainer *vfio_user_create_container(Error **errp)
> +{
> + VFIOUserContainer *container;
> +
> + container = VFIO_IOMMU_USER(object_new(TYPE_VFIO_IOMMU_USER));
> + return container;
> +}
> +
> +/*
> + * Try to mirror vfio_container_connect() as much as possible.
> + */
> +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);
> + if (!vfio_cpr_register_container(bcontainer, errp)) {
> + goto free_container_exit;
> + }
> +
> + vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
> + assert(vioc->setup);
> +
> + if (!vioc->setup(bcontainer, errp)) {
> + goto unregister_container_exit;
> + }
> +
> + vfio_address_space_insert(space, bcontainer);
> +
> + if (!vfio_listener_register(bcontainer, errp)) {
> + goto listener_release_exit;
> + }
> +
> + bcontainer->initialized = true;
> +
> + return container;
> +
> +listener_release_exit:
> + vfio_listener_unregister(bcontainer);
> + if (vioc->release) {
> + vioc->release(bcontainer);
> + }
> +
> +unregister_container_exit:
> + vfio_cpr_unregister_container(bcontainer);
> +
> +free_container_exit:
> + object_unref(container);
> +
> +put_space_exit:
> + vfio_address_space_put(space);
> +
> + return NULL;
> +}
> +
> +static void vfio_user_container_disconnect(VFIOUserContainer *container)
> +{
> + VFIOContainerBase *bcontainer = &container->bcontainer;
Use a QOM cast here.
> + VFIOIOMMUClass *vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
> +
> + vfio_listener_unregister(bcontainer);
> + if (vioc->release) {
> + vioc->release(bcontainer);
> + }
> +
> + VFIOAddressSpace *space = bcontainer->space;
> +
> + vfio_cpr_unregister_container(bcontainer);
> + object_unref(container);
> +
> + vfio_address_space_put(space);
> +}
> +
> +static bool vfio_user_device_get(VFIOUserContainer *container,
> + VFIODevice *vbasedev, Error **errp)
> +{
> + struct vfio_device_info info = { 0 };
> +
> + vbasedev->fd = -1;
> +
> + vfio_device_prepare(vbasedev, &container->bcontainer, &info);
Use a QOM cast here.
> + return true;
> +}
> +
> +/*
> + * vfio_user_device_attach: attach a device to a new container.
> + */
> +static bool vfio_user_device_attach(const char *name, VFIODevice *vbasedev,
> + AddressSpace *as, Error **errp)
> +{
> + VFIOUserContainer *container;
> +
> + container = vfio_user_container_connect(as, errp);
> + if (container == NULL) {
> + error_prepend(errp, "failed to connect proxy");
> + return false;
> + }
> +
> + return vfio_user_device_get(container, vbasedev, errp);
> +}
> +
> +static void vfio_user_device_detach(VFIODevice *vbasedev)
> +{
> + VFIOUserContainer *container = container_of(vbasedev->bcontainer,
> + VFIOUserContainer, bcontainer);
> +
> + vfio_device_unprepare(vbasedev);
> +
> + vfio_user_container_disconnect(container);
> +}
> +
> +static int vfio_user_pci_hot_reset(VFIODevice *vbasedev, bool single)
> +{
> + /* ->needs_reset is always false for vfio-user. */
> + return 0;
> +}
> +
> +static void vfio_iommu_user_class_init(ObjectClass *klass, const void *data)
> +{
> + VFIOIOMMUClass *vioc = VFIO_IOMMU_CLASS(klass);
> +
> + vioc->setup = vfio_user_setup;
> + vioc->dma_map = vfio_user_dma_map;
> + vioc->dma_unmap = vfio_user_dma_unmap;
> + vioc->attach_device = vfio_user_device_attach;
> + vioc->detach_device = vfio_user_device_detach;
> + vioc->set_dirty_page_tracking = vfio_user_set_dirty_page_tracking;
> + vioc->query_dirty_bitmap = vfio_user_query_dirty_bitmap;
> + vioc->pci_hot_reset = vfio_user_pci_hot_reset;
> +};
> +
> +static const TypeInfo types[] = {
> + {
> + .name = TYPE_VFIO_IOMMU_USER,
> + .parent = TYPE_VFIO_IOMMU,
> + .instance_size = sizeof(VFIOUserContainer),
> + .class_init = vfio_iommu_user_class_init,
> + },
> +};
> +
> +DEFINE_TYPES(types)
> diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
> new file mode 100644
> index 0000000000..74b0c61f9b
> --- /dev/null
> +++ b/hw/vfio-user/pci.c
> @@ -0,0 +1,155 @@
> +/*
> + * vfio PCI device over a UNIX socket.
> + *
> + * Copyright © 2018, 2021 Oracle and/or its affiliates.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#include <sys/ioctl.h>
> +#include "qemu/osdep.h"
> +
> +#include "hw/qdev-properties.h"
> +#include "hw/vfio/pci.h"
> +
> +#define TYPE_VFIO_USER_PCI "vfio-user-pci"
> +OBJECT_DECLARE_SIMPLE_TYPE(VFIOUserPCIDevice, VFIO_USER_PCI)
> +
> +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.
> +/*
> + * Emulated devices don't use host hot reset
> + */
> +static void vfio_user_compute_needs_reset(VFIODevice *vbasedev)
> +{
> + vbasedev->needs_reset = false;
> +}
> +
> +static Object *vfio_user_pci_get_object(VFIODevice *vbasedev)
> +{
> + VFIOUserPCIDevice *vdev = container_of(vbasedev, VFIOUserPCIDevice,
> + device.vbasedev);
Hmmm. Not for this series but this may suggest VFIODevice should be
QOMified.
> + return OBJECT(vdev);
> +}
> > +static VFIODeviceOps vfio_user_pci_ops = {
> + .vfio_compute_needs_reset = vfio_user_compute_needs_reset,
> + .vfio_eoi = vfio_pci_intx_eoi,
> + .vfio_get_object = vfio_user_pci_get_object,
> + /* No live migration support yet. */
> + .vfio_save_config = NULL,
> + .vfio_load_config = NULL,
> +};
> +
> +static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
> +{
> + ERRP_GUARD();
> + VFIOUserPCIDevice *udev = VFIO_USER_PCI(pdev);
> + VFIOPCIDevice *vdev = VFIO_PCI_BASE(pdev);
> + VFIODevice *vbasedev = &vdev->vbasedev;
> + AddressSpace *as;
> +
> + /*
> + * TODO: make option parser understand SocketAddress
> + * and use that instead of having scalar options
> + * for each socket type.
> + */
> + if (!udev->sock_name) {
> + error_setg(errp, "No socket specified");
> + error_append_hint(errp, "Use -device vfio-user-pci,socket=<name>\n");
> + return;
> + }
> +
> + vbasedev->name = g_strdup_printf("VFIO user <%s>", udev->sock_name);
> +
> + /*
> + * vfio-user devices are effectively mdevs (don't use a host iommu).
> + */
> + vbasedev->mdev = true;
> +
> + as = pci_device_iommu_address_space(pdev);
> + if (!vfio_device_attach_by_iommu_type(TYPE_VFIO_IOMMU_USER,
> + vbasedev->name, vbasedev,
> + as, errp)) {
> + error_prepend(errp, VFIO_MSG_PREFIX, vbasedev->name);
> + return;
> + }
> +}
> +
> +static void vfio_user_instance_init(Object *obj)
> +{
> + PCIDevice *pci_dev = PCI_DEVICE(obj);
> + VFIOPCIDevice *vdev = VFIO_PCI_BASE(obj);
> + VFIODevice *vbasedev = &vdev->vbasedev;
> +
> + device_add_bootindex_property(obj, &vdev->bootindex,
> + "bootindex", NULL,
> + &pci_dev->qdev);
> + vdev->host.domain = ~0U;
> + vdev->host.bus = ~0U;
> + vdev->host.slot = ~0U;
> + vdev->host.function = ~0U;
> +
> + vfio_device_init(vbasedev, VFIO_DEVICE_TYPE_PCI, &vfio_user_pci_ops,
> + DEVICE(vdev), false);
> +
> + vdev->nv_gpudirect_clique = 0xFF;
> +
> + /*
> + * QEMU_PCI_CAP_EXPRESS initialization does not depend on QEMU command
> + * line, therefore, no need to wait to realize like other devices.
> + */
> + pci_dev->cap_present |= QEMU_PCI_CAP_EXPRESS;
> +}
> +
> +static void vfio_user_instance_finalize(Object *obj)
> +{
> + VFIOPCIDevice *vdev = VFIO_PCI_BASE(obj);
> +
> + vfio_pci_put_device(vdev);
> +}
> +
> +static const Property vfio_user_pci_dev_properties[] = {
> + 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_STRING("socket", VFIOUserPCIDevice, sock_name),
> +};
> +
> +static void vfio_user_pci_dev_class_init(ObjectClass *klass, const void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> + PCIDeviceClass *pdc = PCI_DEVICE_CLASS(klass);
> +
> + device_class_set_props(dc, vfio_user_pci_dev_properties);
> + dc->desc = "VFIO over socket PCI device assignment";
> + pdc->realize = vfio_user_pci_realize;
> +}
> +
> +static const TypeInfo vfio_user_pci_dev_info = {
> + .name = TYPE_VFIO_USER_PCI,
> + .parent = TYPE_VFIO_PCI_BASE,
> + .instance_size = sizeof(VFIOUserPCIDevice),
> + .class_init = vfio_user_pci_dev_class_init,
> + .instance_init = vfio_user_instance_init,
> + .instance_finalize = vfio_user_instance_finalize,
> +};
> +
> +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.
> diff --git a/hw/meson.build b/hw/meson.build
> index b91f761fe0..791ce21ab4 100644
> --- a/hw/meson.build
> +++ b/hw/meson.build
> @@ -39,6 +39,7 @@ subdir('uefi')
> subdir('ufs')
> subdir('usb')
> subdir('vfio')
> +subdir('vfio-user')
> subdir('virtio')
> subdir('vmapple')
> subdir('watchdog')
> diff --git a/hw/vfio-user/meson.build b/hw/vfio-user/meson.build
> new file mode 100644
> index 0000000000..f1fee70c85
> --- /dev/null
> +++ b/hw/vfio-user/meson.build
> @@ -0,0 +1,9 @@
> +vfio_user_ss = ss.source_set()
> +vfio_user_ss.add(files(
> + 'container.c',
> + 'pci.c',
> +))
> +
> +if get_option('vfio_user_client').enabled()
> + specific_ss.add_all(vfio_user_ss)
> +endif
> diff --git a/meson_options.txt b/meson_options.txt
> index a442be2995..97d3db44cd 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -109,6 +109,8 @@ option('multiprocess', type: 'feature', value: 'auto',
> description: 'Out of process device emulation support')
> option('relocatable', type : 'boolean', value : true,
> description: 'toggle relocatable install')
> +option('vfio_user_client', type: 'feature', value: 'disabled',
> + description: 'vfio-user client support')
> option('vfio_user_server', type: 'feature', value: 'disabled',
> description: 'vfio-user server support')
> option('dbus_display', type: 'feature', value: 'auto',
> diff --git a/scripts/meson-buildoptions.sh b/scripts/meson-buildoptions.sh
> index f09ef9604f..2c5673769a 100644
> --- a/scripts/meson-buildoptions.sh
> +++ b/scripts/meson-buildoptions.sh
> @@ -201,6 +201,8 @@ meson_options_help() {
> printf "%s\n" ' vdi vdi image format support'
> printf "%s\n" ' vduse-blk-export'
> printf "%s\n" ' VDUSE block export support'
> + printf "%s\n" ' vfio-user-client'
> + printf "%s\n" ' vfio-user client support'
> printf "%s\n" ' vfio-user-server'
> printf "%s\n" ' vfio-user server support'
> printf "%s\n" ' vhdx vhdx image format support'
> @@ -529,6 +531,8 @@ _meson_option_parse() {
> --disable-vdi) printf "%s" -Dvdi=disabled ;;
> --enable-vduse-blk-export) printf "%s" -Dvduse_blk_export=enabled ;;
> --disable-vduse-blk-export) printf "%s" -Dvduse_blk_export=disabled ;;
> + --enable-vfio-user-client) printf "%s" -Dvfio_user_client=enabled ;;
> + --disable-vfio-user-client) printf "%s" -Dvfio_user_client=disabled ;;
> --enable-vfio-user-server) printf "%s" -Dvfio_user_server=enabled ;;
> --disable-vfio-user-server) printf "%s" -Dvfio_user_server=disabled ;;
> --enable-vhdx) printf "%s" -Dvhdx=enabled ;;
ATB,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 06/23] vfio-user: add vfio-user class and container
2025-06-10 11:42 ` Mark Cave-Ayland
@ 2025-06-10 11:56 ` John Levon
2025-06-10 12:15 ` Cédric Le Goater
2025-06-10 12:13 ` Cédric Le Goater
1 sibling, 1 reply; 69+ messages in thread
From: John Levon @ 2025-06-10 11:56 UTC (permalink / raw)
To: Mark Cave-Ayland
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Cédric Le Goater, Philippe Mathieu-Daudé, John Johnson,
Elena Ufimtseva, Jagannathan Raman
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
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 06/23] vfio-user: add vfio-user class and container
2025-06-10 11:56 ` John Levon
@ 2025-06-10 12:15 ` Cédric Le Goater
0 siblings, 0 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-10 12:15 UTC (permalink / raw)
To: John Levon, Mark Cave-Ayland
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, John Johnson, Elena Ufimtseva,
Jagannathan Raman
On 6/10/25 13:56, John Levon wrote:
> 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).
yes. It looks much better. The interfaces between the core VFIO framework
and the new vfio-user-pci device are clear. This is easier for maintenance
too.
Thanks,
C.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 06/23] vfio-user: add vfio-user class and container
2025-06-10 11:42 ` Mark Cave-Ayland
2025-06-10 11:56 ` John Levon
@ 2025-06-10 12:13 ` Cédric Le Goater
1 sibling, 0 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-10 12:13 UTC (permalink / raw)
To: Mark Cave-Ayland, John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, John Johnson, Elena Ufimtseva,
Jagannathan Raman
On 6/10/25 13:42, Mark Cave-Ayland wrote:
> On 07/06/2025 01:10, John Levon wrote:
>
>> Introduce basic plumbing for vfio-user behind a new
>> --enable-vfio-user-client option.
>>
>> We introduce VFIOUserContainer in hw/vfio-user/container.c, which is a
>> container type for the "IOMMU" type "vfio-iommu-user", and share some
>> common container code from hw/vfio/container.c.
>>
>> Add hw/vfio-user/pci.c for instantiating VFIOUserPCIDevice objects,
>> sharing some common code from hw/vfio/pci.c.
>>
>> Originally-by: John Johnson <john.g.johnson@oracle.com>
>> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
>> Signed-off-by: John Levon <john.levon@nutanix.com>
>> ---
>> MAINTAINERS | 2 +
>> hw/vfio-user/container.h | 25 +++
>> include/hw/vfio/vfio-container-base.h | 1 +
>> hw/vfio-user/container.c | 212 ++++++++++++++++++++++++++
>> hw/vfio-user/pci.c | 155 +++++++++++++++++++
>> hw/meson.build | 1 +
>> hw/vfio-user/meson.build | 9 ++
>> meson_options.txt | 2 +
>> scripts/meson-buildoptions.sh | 4 +
>> 9 files changed, 411 insertions(+)
>> create mode 100644 hw/vfio-user/container.h
>> create mode 100644 hw/vfio-user/container.c
>> create mode 100644 hw/vfio-user/pci.c
>> create mode 100644 hw/vfio-user/meson.build
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index dbc393989a..328bab8d19 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -4252,6 +4252,8 @@ M: John Levon <john.levon@nutanix.com>
>> M: Thanos Makatos <thanos.makatos@nutanix.com>
>> S: Supported
>> F: docs/devel/vfio-user.rst
>> +F: hw/vfio-user/*
>> +F: include/hw/vfio-user/*
>> F: subprojects/libvfio-user
>
> 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.
>
> Cédric, what are your thoughts here?
The vfio devices are very dependent on the bus they depend on.
My idea is to keep under hw/vfio the initial implementation of
the vfio-pci device and the common services for other "complex"
vfio devices like vfio-user-pci. Which give us :
hw/vfio/* 17323 lines
hw/vfio-user/* 2955 lines
vfio-ap and vfio-ccw are small but I might still move them under
s390x. vfio-platform will be removed in the next QEMU cycle.
Also, util/vfio-helpers.c, on which is built the nvme BlockDriver,
should be merged under the common services, so under hw/vfio.
Thanks,
C.
>
>> EBPF:
>> diff --git a/hw/vfio-user/container.h b/hw/vfio-user/container.h
>> new file mode 100644
>> index 0000000000..3cd3303e68
>> --- /dev/null
>> +++ b/hw/vfio-user/container.h
>> @@ -0,0 +1,25 @@
>> +/*
>> + * vfio-user specific definitions.
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2. See
>> + * the COPYING file in the top-level directory.
>> + *
>> + * SPDX-License-Identifier: GPL-2.0-or-later
>> + */
>> +
>> +#ifndef HW_VFIO_USER_CONTAINER_H
>> +#define HW_VFIO_USER_CONTAINER_H
>> +
>> +#include <inttypes.h>
>> +#include <stdbool.h>
>
> These shouldn't be included directly: you probably just want:
>
> #include "qemu/osdep.h"
>
> instead.
>
>> +#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);
>
>> +#endif /* HW_VFIO_USER_CONTAINER_H */
>> diff --git a/include/hw/vfio/vfio-container-base.h b/include/hw/vfio/vfio-container-base.h
>> index 9d37f86115..28899ca0a6 100644
>> --- a/include/hw/vfio/vfio-container-base.h
>> +++ b/include/hw/vfio/vfio-container-base.h
>> @@ -109,6 +109,7 @@ vfio_container_get_page_size_mask(const VFIOContainerBase *bcontainer)
>> #define TYPE_VFIO_IOMMU_LEGACY TYPE_VFIO_IOMMU "-legacy"
>> #define TYPE_VFIO_IOMMU_SPAPR TYPE_VFIO_IOMMU "-spapr"
>> #define TYPE_VFIO_IOMMU_IOMMUFD TYPE_VFIO_IOMMU "-iommufd"
>> +#define TYPE_VFIO_IOMMU_USER TYPE_VFIO_IOMMU "-user"
>> OBJECT_DECLARE_TYPE(VFIOContainerBase, VFIOIOMMUClass, VFIO_IOMMU)
>> diff --git a/hw/vfio-user/container.c b/hw/vfio-user/container.c
>> new file mode 100644
>> index 0000000000..2892845b4f
>> --- /dev/null
>> +++ b/hw/vfio-user/container.c
>> @@ -0,0 +1,212 @@
>> +/*
>> + * Container for vfio-user IOMMU type: rather than communicating with the kernel
>> + * vfio driver, we communicate over a socket to a server using the vfio-user
>> + * protocol.
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2. See
>> + * the COPYING file in the top-level directory.
>> + *
>> + * SPDX-License-Identifier: GPL-2.0-or-later
>> + */
>> +
>> +#include <sys/ioctl.h>
>> +#include <linux/vfio.h>
>> +#include "qemu/osdep.h"
>> +
>> +#include "hw/vfio-user/container.h"
>> +#include "hw/vfio/vfio-cpr.h"
>> +#include "hw/vfio/vfio-device.h"
>> +#include "hw/vfio/vfio-listener.h"
>> +#include "qapi/error.h"
>> +#include "trace.h"
>> +
>> +static int vfio_user_dma_unmap(const VFIOContainerBase *bcontainer,
>> + hwaddr iova, ram_addr_t size,
>> + IOMMUTLBEntry *iotlb, bool unmap_all)
>> +{
>> + return -ENOTSUP;
>> +}
>> +
>> +static int vfio_user_dma_map(const VFIOContainerBase *bcontainer, hwaddr iova,
>> + ram_addr_t size, void *vaddr, bool readonly,
>> + MemoryRegion *mrp)
>> +{
>> + return -ENOTSUP;
>> +}
>> +
>> +static int
>> +vfio_user_set_dirty_page_tracking(const VFIOContainerBase *bcontainer,
>> + bool start, Error **errp)
>> +{
>> + error_setg_errno(errp, ENOTSUP, "Not supported");
>> + return -ENOTSUP;
>> +}
>> +
>> +static int vfio_user_query_dirty_bitmap(const VFIOContainerBase *bcontainer,
>> + VFIOBitmap *vbmap, hwaddr iova,
>> + hwaddr size, Error **errp)
>> +{
>> + error_setg_errno(errp, ENOTSUP, "Not supported");
>> + return -ENOTSUP;
>> +}
>> +
>> +static bool vfio_user_setup(VFIOContainerBase *bcontainer, Error **errp)
>> +{
>> + error_setg_errno(errp, ENOTSUP, "Not supported");
>> + return -ENOTSUP;
>> +}
>> +
>> +static VFIOUserContainer *vfio_user_create_container(Error **errp)
>> +{
>> + VFIOUserContainer *container;
>> +
>> + container = VFIO_IOMMU_USER(object_new(TYPE_VFIO_IOMMU_USER));
>> + return container;
>> +}
>> +
>> +/*
>> + * Try to mirror vfio_container_connect() as much as possible.
>> + */
>> +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);
>
>> + if (!vfio_cpr_register_container(bcontainer, errp)) {
>> + goto free_container_exit;
>> + }
>> +
>> + vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
>> + assert(vioc->setup);
>> +
>> + if (!vioc->setup(bcontainer, errp)) {
>> + goto unregister_container_exit;
>> + }
>> +
>> + vfio_address_space_insert(space, bcontainer);
>> +
>> + if (!vfio_listener_register(bcontainer, errp)) {
>> + goto listener_release_exit;
>> + }
>> +
>> + bcontainer->initialized = true;
>> +
>> + return container;
>> +
>> +listener_release_exit:
>> + vfio_listener_unregister(bcontainer);
>> + if (vioc->release) {
>> + vioc->release(bcontainer);
>> + }
>> +
>> +unregister_container_exit:
>> + vfio_cpr_unregister_container(bcontainer);
>> +
>> +free_container_exit:
>> + object_unref(container);
>> +
>> +put_space_exit:
>> + vfio_address_space_put(space);
>> +
>> + return NULL;
>> +}
>> +
>> +static void vfio_user_container_disconnect(VFIOUserContainer *container)
>> +{
>> + VFIOContainerBase *bcontainer = &container->bcontainer;
>
> Use a QOM cast here.
>
>> + VFIOIOMMUClass *vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
>> +
>> + vfio_listener_unregister(bcontainer);
>> + if (vioc->release) {
>> + vioc->release(bcontainer);
>> + }
>> +
>> + VFIOAddressSpace *space = bcontainer->space;
>> +
>> + vfio_cpr_unregister_container(bcontainer);
>> + object_unref(container);
>> +
>> + vfio_address_space_put(space);
>> +}
>> +
>> +static bool vfio_user_device_get(VFIOUserContainer *container,
>> + VFIODevice *vbasedev, Error **errp)
>> +{
>> + struct vfio_device_info info = { 0 };
>> +
>> + vbasedev->fd = -1;
>> +
>> + vfio_device_prepare(vbasedev, &container->bcontainer, &info);
>
> Use a QOM cast here.
>
>> + return true;
>> +}
>> +
>> +/*
>> + * vfio_user_device_attach: attach a device to a new container.
>> + */
>> +static bool vfio_user_device_attach(const char *name, VFIODevice *vbasedev,
>> + AddressSpace *as, Error **errp)
>> +{
>> + VFIOUserContainer *container;
>> +
>> + container = vfio_user_container_connect(as, errp);
>> + if (container == NULL) {
>> + error_prepend(errp, "failed to connect proxy");
>> + return false;
>> + }
>> +
>> + return vfio_user_device_get(container, vbasedev, errp);
>> +}
>> +
>> +static void vfio_user_device_detach(VFIODevice *vbasedev)
>> +{
>> + VFIOUserContainer *container = container_of(vbasedev->bcontainer,
>> + VFIOUserContainer, bcontainer);
>> +
>> + vfio_device_unprepare(vbasedev);
>> +
>> + vfio_user_container_disconnect(container);
>> +}
>> +
>> +static int vfio_user_pci_hot_reset(VFIODevice *vbasedev, bool single)
>> +{
>> + /* ->needs_reset is always false for vfio-user. */
>> + return 0;
>> +}
>> +
>> +static void vfio_iommu_user_class_init(ObjectClass *klass, const void *data)
>> +{
>> + VFIOIOMMUClass *vioc = VFIO_IOMMU_CLASS(klass);
>> +
>> + vioc->setup = vfio_user_setup;
>> + vioc->dma_map = vfio_user_dma_map;
>> + vioc->dma_unmap = vfio_user_dma_unmap;
>> + vioc->attach_device = vfio_user_device_attach;
>> + vioc->detach_device = vfio_user_device_detach;
>> + vioc->set_dirty_page_tracking = vfio_user_set_dirty_page_tracking;
>> + vioc->query_dirty_bitmap = vfio_user_query_dirty_bitmap;
>> + vioc->pci_hot_reset = vfio_user_pci_hot_reset;
>> +};
>> +
>> +static const TypeInfo types[] = {
>> + {
>> + .name = TYPE_VFIO_IOMMU_USER,
>> + .parent = TYPE_VFIO_IOMMU,
>> + .instance_size = sizeof(VFIOUserContainer),
>> + .class_init = vfio_iommu_user_class_init,
>> + },
>> +};
>> +
>> +DEFINE_TYPES(types)
>> diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
>> new file mode 100644
>> index 0000000000..74b0c61f9b
>> --- /dev/null
>> +++ b/hw/vfio-user/pci.c
>> @@ -0,0 +1,155 @@
>> +/*
>> + * vfio PCI device over a UNIX socket.
>> + *
>> + * Copyright © 2018, 2021 Oracle and/or its affiliates.
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
>> + * See the COPYING file in the top-level directory.
>> + *
>> + * SPDX-License-Identifier: GPL-2.0-or-later
>> + */
>> +
>> +#include <sys/ioctl.h>
>> +#include "qemu/osdep.h"
>> +
>> +#include "hw/qdev-properties.h"
>> +#include "hw/vfio/pci.h"
>> +
>> +#define TYPE_VFIO_USER_PCI "vfio-user-pci"
>> +OBJECT_DECLARE_SIMPLE_TYPE(VFIOUserPCIDevice, VFIO_USER_PCI)
>> +
>> +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.
>
>> +/*
>> + * Emulated devices don't use host hot reset
>> + */
>> +static void vfio_user_compute_needs_reset(VFIODevice *vbasedev)
>> +{
>> + vbasedev->needs_reset = false;
>> +}
>> +
>> +static Object *vfio_user_pci_get_object(VFIODevice *vbasedev)
>> +{
>> + VFIOUserPCIDevice *vdev = container_of(vbasedev, VFIOUserPCIDevice,
>> + device.vbasedev);
>
> Hmmm. Not for this series but this may suggest VFIODevice should be QOMified.
>
>> + return OBJECT(vdev);
>> +}
> > > +static VFIODeviceOps vfio_user_pci_ops = {
>> + .vfio_compute_needs_reset = vfio_user_compute_needs_reset,
>> + .vfio_eoi = vfio_pci_intx_eoi,
>> + .vfio_get_object = vfio_user_pci_get_object,
>> + /* No live migration support yet. */
>> + .vfio_save_config = NULL,
>> + .vfio_load_config = NULL,
>> +};
>> +
>> +static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
>> +{
>> + ERRP_GUARD();
>> + VFIOUserPCIDevice *udev = VFIO_USER_PCI(pdev);
>> + VFIOPCIDevice *vdev = VFIO_PCI_BASE(pdev);
>> + VFIODevice *vbasedev = &vdev->vbasedev;
>> + AddressSpace *as;
>> +
>> + /*
>> + * TODO: make option parser understand SocketAddress
>> + * and use that instead of having scalar options
>> + * for each socket type.
>> + */
>> + if (!udev->sock_name) {
>> + error_setg(errp, "No socket specified");
>> + error_append_hint(errp, "Use -device vfio-user-pci,socket=<name>\n");
>> + return;
>> + }
>> +
>> + vbasedev->name = g_strdup_printf("VFIO user <%s>", udev->sock_name);
>> +
>> + /*
>> + * vfio-user devices are effectively mdevs (don't use a host iommu).
>> + */
>> + vbasedev->mdev = true;
>> +
>> + as = pci_device_iommu_address_space(pdev);
>> + if (!vfio_device_attach_by_iommu_type(TYPE_VFIO_IOMMU_USER,
>> + vbasedev->name, vbasedev,
>> + as, errp)) {
>> + error_prepend(errp, VFIO_MSG_PREFIX, vbasedev->name);
>> + return;
>> + }
>> +}
>> +
>> +static void vfio_user_instance_init(Object *obj)
>> +{
>> + PCIDevice *pci_dev = PCI_DEVICE(obj);
>> + VFIOPCIDevice *vdev = VFIO_PCI_BASE(obj);
>> + VFIODevice *vbasedev = &vdev->vbasedev;
>> +
>> + device_add_bootindex_property(obj, &vdev->bootindex,
>> + "bootindex", NULL,
>> + &pci_dev->qdev);
>> + vdev->host.domain = ~0U;
>> + vdev->host.bus = ~0U;
>> + vdev->host.slot = ~0U;
>> + vdev->host.function = ~0U;
>> +
>> + vfio_device_init(vbasedev, VFIO_DEVICE_TYPE_PCI, &vfio_user_pci_ops,
>> + DEVICE(vdev), false);
>> +
>> + vdev->nv_gpudirect_clique = 0xFF;
>> +
>> + /*
>> + * QEMU_PCI_CAP_EXPRESS initialization does not depend on QEMU command
>> + * line, therefore, no need to wait to realize like other devices.
>> + */
>> + pci_dev->cap_present |= QEMU_PCI_CAP_EXPRESS;
>> +}
>> +
>> +static void vfio_user_instance_finalize(Object *obj)
>> +{
>> + VFIOPCIDevice *vdev = VFIO_PCI_BASE(obj);
>> +
>> + vfio_pci_put_device(vdev);
>> +}
>> +
>> +static const Property vfio_user_pci_dev_properties[] = {
>> + 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_STRING("socket", VFIOUserPCIDevice, sock_name),
>> +};
>> +
>> +static void vfio_user_pci_dev_class_init(ObjectClass *klass, const void *data)
>> +{
>> + DeviceClass *dc = DEVICE_CLASS(klass);
>> + PCIDeviceClass *pdc = PCI_DEVICE_CLASS(klass);
>> +
>> + device_class_set_props(dc, vfio_user_pci_dev_properties);
>> + dc->desc = "VFIO over socket PCI device assignment";
>> + pdc->realize = vfio_user_pci_realize;
>> +}
>> +
>> +static const TypeInfo vfio_user_pci_dev_info = {
>> + .name = TYPE_VFIO_USER_PCI,
>> + .parent = TYPE_VFIO_PCI_BASE,
>> + .instance_size = sizeof(VFIOUserPCIDevice),
>> + .class_init = vfio_user_pci_dev_class_init,
>> + .instance_init = vfio_user_instance_init,
>> + .instance_finalize = vfio_user_instance_finalize,
>> +};
>> +
>> +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.
>
>> diff --git a/hw/meson.build b/hw/meson.build
>> index b91f761fe0..791ce21ab4 100644
>> --- a/hw/meson.build
>> +++ b/hw/meson.build
>> @@ -39,6 +39,7 @@ subdir('uefi')
>> subdir('ufs')
>> subdir('usb')
>> subdir('vfio')
>> +subdir('vfio-user')
>> subdir('virtio')
>> subdir('vmapple')
>> subdir('watchdog')
>> diff --git a/hw/vfio-user/meson.build b/hw/vfio-user/meson.build
>> new file mode 100644
>> index 0000000000..f1fee70c85
>> --- /dev/null
>> +++ b/hw/vfio-user/meson.build
>> @@ -0,0 +1,9 @@
>> +vfio_user_ss = ss.source_set()
>> +vfio_user_ss.add(files(
>> + 'container.c',
>> + 'pci.c',
>> +))
>> +
>> +if get_option('vfio_user_client').enabled()
>> + specific_ss.add_all(vfio_user_ss)
>> +endif
>> diff --git a/meson_options.txt b/meson_options.txt
>> index a442be2995..97d3db44cd 100644
>> --- a/meson_options.txt
>> +++ b/meson_options.txt
>> @@ -109,6 +109,8 @@ option('multiprocess', type: 'feature', value: 'auto',
>> description: 'Out of process device emulation support')
>> option('relocatable', type : 'boolean', value : true,
>> description: 'toggle relocatable install')
>> +option('vfio_user_client', type: 'feature', value: 'disabled',
>> + description: 'vfio-user client support')
>> option('vfio_user_server', type: 'feature', value: 'disabled',
>> description: 'vfio-user server support')
>> option('dbus_display', type: 'feature', value: 'auto',
>> diff --git a/scripts/meson-buildoptions.sh b/scripts/meson-buildoptions.sh
>> index f09ef9604f..2c5673769a 100644
>> --- a/scripts/meson-buildoptions.sh
>> +++ b/scripts/meson-buildoptions.sh
>> @@ -201,6 +201,8 @@ meson_options_help() {
>> printf "%s\n" ' vdi vdi image format support'
>> printf "%s\n" ' vduse-blk-export'
>> printf "%s\n" ' VDUSE block export support'
>> + printf "%s\n" ' vfio-user-client'
>> + printf "%s\n" ' vfio-user client support'
>> printf "%s\n" ' vfio-user-server'
>> printf "%s\n" ' vfio-user server support'
>> printf "%s\n" ' vhdx vhdx image format support'
>> @@ -529,6 +531,8 @@ _meson_option_parse() {
>> --disable-vdi) printf "%s" -Dvdi=disabled ;;
>> --enable-vduse-blk-export) printf "%s" -Dvduse_blk_export=enabled ;;
>> --disable-vduse-blk-export) printf "%s" -Dvduse_blk_export=disabled ;;
>> + --enable-vfio-user-client) printf "%s" -Dvfio_user_client=enabled ;;
>> + --disable-vfio-user-client) printf "%s" -Dvfio_user_client=disabled ;;
>> --enable-vfio-user-server) printf "%s" -Dvfio_user_server=enabled ;;
>> --disable-vfio-user-server) printf "%s" -Dvfio_user_server=disabled ;;
>> --enable-vhdx) printf "%s" -Dvhdx=enabled ;;
>
>
> ATB,
>
> Mark.
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 06/23] vfio-user: add vfio-user class and container
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 11:42 ` Mark Cave-Ayland
@ 2025-06-12 6:39 ` Cédric Le Goater
2025-06-12 14:02 ` John Levon
2 siblings, 1 reply; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-12 6:39 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, John Johnson, Elena Ufimtseva,
Jagannathan Raman
On 6/7/25 02:10, John Levon wrote:
> Introduce basic plumbing for vfio-user behind a new
> --enable-vfio-user-client option.
>
> We introduce VFIOUserContainer in hw/vfio-user/container.c, which is a
> container type for the "IOMMU" type "vfio-iommu-user", and share some
> common container code from hw/vfio/container.c.
>
> Add hw/vfio-user/pci.c for instantiating VFIOUserPCIDevice objects,
> sharing some common code from hw/vfio/pci.c.
>
> Originally-by: John Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: John Levon <john.levon@nutanix.com>
> ---
> MAINTAINERS | 2 +
> hw/vfio-user/container.h | 25 +++
> include/hw/vfio/vfio-container-base.h | 1 +
> hw/vfio-user/container.c | 212 ++++++++++++++++++++++++++
> hw/vfio-user/pci.c | 155 +++++++++++++++++++
> hw/meson.build | 1 +
> hw/vfio-user/meson.build | 9 ++
> meson_options.txt | 2 +
> scripts/meson-buildoptions.sh | 4 +
> 9 files changed, 411 insertions(+)
> create mode 100644 hw/vfio-user/container.h
> create mode 100644 hw/vfio-user/container.c
> create mode 100644 hw/vfio-user/pci.c
> create mode 100644 hw/vfio-user/meson.build
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index dbc393989a..328bab8d19 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4252,6 +4252,8 @@ M: John Levon <john.levon@nutanix.com>
> M: Thanos Makatos <thanos.makatos@nutanix.com>
> S: Supported
> F: docs/devel/vfio-user.rst
> +F: hw/vfio-user/*
> +F: include/hw/vfio-user/*
> F: subprojects/libvfio-user
>
> EBPF:
> diff --git a/hw/vfio-user/container.h b/hw/vfio-user/container.h
> new file mode 100644
> index 0000000000..3cd3303e68
> --- /dev/null
> +++ b/hw/vfio-user/container.h
> @@ -0,0 +1,25 @@
> +/*
> + * vfio-user specific definitions.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2. See
> + * the COPYING file in the top-level directory.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#ifndef HW_VFIO_USER_CONTAINER_H
> +#define HW_VFIO_USER_CONTAINER_H
> +
> +#include <inttypes.h>
> +#include <stdbool.h>
> +
> +#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);
> +
> +#endif /* HW_VFIO_USER_CONTAINER_H */
> diff --git a/include/hw/vfio/vfio-container-base.h b/include/hw/vfio/vfio-container-base.h
> index 9d37f86115..28899ca0a6 100644
> --- a/include/hw/vfio/vfio-container-base.h
> +++ b/include/hw/vfio/vfio-container-base.h
> @@ -109,6 +109,7 @@ vfio_container_get_page_size_mask(const VFIOContainerBase *bcontainer)
> #define TYPE_VFIO_IOMMU_LEGACY TYPE_VFIO_IOMMU "-legacy"
> #define TYPE_VFIO_IOMMU_SPAPR TYPE_VFIO_IOMMU "-spapr"
> #define TYPE_VFIO_IOMMU_IOMMUFD TYPE_VFIO_IOMMU "-iommufd"
> +#define TYPE_VFIO_IOMMU_USER TYPE_VFIO_IOMMU "-user"
>
> OBJECT_DECLARE_TYPE(VFIOContainerBase, VFIOIOMMUClass, VFIO_IOMMU)
>
> diff --git a/hw/vfio-user/container.c b/hw/vfio-user/container.c
> new file mode 100644
> index 0000000000..2892845b4f
> --- /dev/null
> +++ b/hw/vfio-user/container.c
> @@ -0,0 +1,212 @@
> +/*
> + * Container for vfio-user IOMMU type: rather than communicating with the kernel
> + * vfio driver, we communicate over a socket to a server using the vfio-user
> + * protocol.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2. See
> + * the COPYING file in the top-level directory.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#include <sys/ioctl.h>
> +#include <linux/vfio.h>
> +#include "qemu/osdep.h"
> +
> +#include "hw/vfio-user/container.h"
> +#include "hw/vfio/vfio-cpr.h"
> +#include "hw/vfio/vfio-device.h"
> +#include "hw/vfio/vfio-listener.h"
> +#include "qapi/error.h"
> +#include "trace.h"
> +
> +static int vfio_user_dma_unmap(const VFIOContainerBase *bcontainer,
> + hwaddr iova, ram_addr_t size,
> + IOMMUTLBEntry *iotlb, bool unmap_all)
> +{
> + return -ENOTSUP;
> +}
> +
> +static int vfio_user_dma_map(const VFIOContainerBase *bcontainer, hwaddr iova,
> + ram_addr_t size, void *vaddr, bool readonly,
> + MemoryRegion *mrp)
> +{
> + return -ENOTSUP;
> +}
> +
> +static int
> +vfio_user_set_dirty_page_tracking(const VFIOContainerBase *bcontainer,
> + bool start, Error **errp)
> +{
> + error_setg_errno(errp, ENOTSUP, "Not supported");
> + return -ENOTSUP;
> +}
> +
> +static int vfio_user_query_dirty_bitmap(const VFIOContainerBase *bcontainer,
> + VFIOBitmap *vbmap, hwaddr iova,
> + hwaddr size, Error **errp)
> +{
> + error_setg_errno(errp, ENOTSUP, "Not supported");
> + return -ENOTSUP;
> +}
> +
> +static bool vfio_user_setup(VFIOContainerBase *bcontainer, Error **errp)
> +{
> + error_setg_errno(errp, ENOTSUP, "Not supported");
> + return -ENOTSUP;
> +}
> +
> +static VFIOUserContainer *vfio_user_create_container(Error **errp)
> +{
> + VFIOUserContainer *container;
> +
> + container = VFIO_IOMMU_USER(object_new(TYPE_VFIO_IOMMU_USER));
> + return container;
> +}
> +
> +/*
> + * Try to mirror vfio_container_connect() as much as possible.
> + */
> +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;
> +
> + if (!vfio_cpr_register_container(bcontainer, errp)) {
> + goto free_container_exit;
> + }
> +
> + vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
> + assert(vioc->setup);
> +
> + if (!vioc->setup(bcontainer, errp)) {
> + goto unregister_container_exit;
> + }
> +
> + vfio_address_space_insert(space, bcontainer);
> +
> + if (!vfio_listener_register(bcontainer, errp)) {
> + goto listener_release_exit;
> + }
> +
> + bcontainer->initialized = true;
> +
> + return container;
> +
> +listener_release_exit:
> + vfio_listener_unregister(bcontainer);
> + if (vioc->release) {
> + vioc->release(bcontainer);
> + }
> +
> +unregister_container_exit:
> + vfio_cpr_unregister_container(bcontainer);
> +
> +free_container_exit:
> + object_unref(container);
> +
> +put_space_exit:
> + vfio_address_space_put(space);
> +
> + return NULL;
> +}
> +
> +static void vfio_user_container_disconnect(VFIOUserContainer *container)
> +{
> + VFIOContainerBase *bcontainer = &container->bcontainer;
> + VFIOIOMMUClass *vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
> +
> + vfio_listener_unregister(bcontainer);
> + if (vioc->release) {
> + vioc->release(bcontainer);
> + }
> +
> + VFIOAddressSpace *space = bcontainer->space;
> +
> + vfio_cpr_unregister_container(bcontainer);
> + object_unref(container);
> +
> + vfio_address_space_put(space);
> +}
> +
> +static bool vfio_user_device_get(VFIOUserContainer *container,
> + VFIODevice *vbasedev, Error **errp)
> +{
> + struct vfio_device_info info = { 0 };
> +
> + vbasedev->fd = -1;
> +
> + vfio_device_prepare(vbasedev, &container->bcontainer, &info);
> +
> + return true;
> +}
> +
> +/*
> + * vfio_user_device_attach: attach a device to a new container.
> + */
> +static bool vfio_user_device_attach(const char *name, VFIODevice *vbasedev,
> + AddressSpace *as, Error **errp)
> +{
> + VFIOUserContainer *container;
> +
> + container = vfio_user_container_connect(as, errp);
> + if (container == NULL) {
> + error_prepend(errp, "failed to connect proxy");
> + return false;
> + }
> +
> + return vfio_user_device_get(container, vbasedev, errp);
> +}
> +
> +static void vfio_user_device_detach(VFIODevice *vbasedev)
> +{
> + VFIOUserContainer *container = container_of(vbasedev->bcontainer,
> + VFIOUserContainer, bcontainer);
> +
> + vfio_device_unprepare(vbasedev);
> +
> + vfio_user_container_disconnect(container);
> +}
> +
> +static int vfio_user_pci_hot_reset(VFIODevice *vbasedev, bool single)
> +{
> + /* ->needs_reset is always false for vfio-user. */
> + return 0;
> +}
> +
> +static void vfio_iommu_user_class_init(ObjectClass *klass, const void *data)
> +{
> + VFIOIOMMUClass *vioc = VFIO_IOMMU_CLASS(klass);
> +
> + vioc->setup = vfio_user_setup;
> + vioc->dma_map = vfio_user_dma_map;
> + vioc->dma_unmap = vfio_user_dma_unmap;
> + vioc->attach_device = vfio_user_device_attach;
> + vioc->detach_device = vfio_user_device_detach;
> + vioc->set_dirty_page_tracking = vfio_user_set_dirty_page_tracking;
> + vioc->query_dirty_bitmap = vfio_user_query_dirty_bitmap;
> + vioc->pci_hot_reset = vfio_user_pci_hot_reset;
> +};
> +
> +static const TypeInfo types[] = {
> + {
> + .name = TYPE_VFIO_IOMMU_USER,
> + .parent = TYPE_VFIO_IOMMU,
> + .instance_size = sizeof(VFIOUserContainer),
> + .class_init = vfio_iommu_user_class_init,
> + },
> +};
> +
> +DEFINE_TYPES(types)
> diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
> new file mode 100644
> index 0000000000..74b0c61f9b
> --- /dev/null
> +++ b/hw/vfio-user/pci.c
> @@ -0,0 +1,155 @@
> +/*
> + * vfio PCI device over a UNIX socket.
> + *
> + * Copyright © 2018, 2021 Oracle and/or its affiliates.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#include <sys/ioctl.h>
> +#include "qemu/osdep.h"
> +
> +#include "hw/qdev-properties.h"
> +#include "hw/vfio/pci.h"
> +
> +#define TYPE_VFIO_USER_PCI "vfio-user-pci"
> +OBJECT_DECLARE_SIMPLE_TYPE(VFIOUserPCIDevice, VFIO_USER_PCI)
> +
> +struct VFIOUserPCIDevice {
> + VFIOPCIDevice device;
> + char *sock_name;
> +};
> +
> +/*
> + * Emulated devices don't use host hot reset
> + */
> +static void vfio_user_compute_needs_reset(VFIODevice *vbasedev)
> +{
> + vbasedev->needs_reset = false;
> +}
> +
> +static Object *vfio_user_pci_get_object(VFIODevice *vbasedev)
> +{
> + VFIOUserPCIDevice *vdev = container_of(vbasedev, VFIOUserPCIDevice,
> + device.vbasedev);
> +
> + return OBJECT(vdev);
> +}
> +
> +static VFIODeviceOps vfio_user_pci_ops = {
> + .vfio_compute_needs_reset = vfio_user_compute_needs_reset,
> + .vfio_eoi = vfio_pci_intx_eoi,
> + .vfio_get_object = vfio_user_pci_get_object,
> + /* No live migration support yet. */
> + .vfio_save_config = NULL,
> + .vfio_load_config = NULL,
> +};
> +
> +static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
> +{
> + ERRP_GUARD();
> + VFIOUserPCIDevice *udev = VFIO_USER_PCI(pdev);
> + VFIOPCIDevice *vdev = VFIO_PCI_BASE(pdev);
> + VFIODevice *vbasedev = &vdev->vbasedev;
> + AddressSpace *as;
> +
> + /*
> + * TODO: make option parser understand SocketAddress
> + * and use that instead of having scalar options
> + * for each socket type.
Please take a look at vfu_object_class_init() to handle the
"socket" property.
C.
> + */
> + if (!udev->sock_name) {
> + error_setg(errp, "No socket specified");
> + error_append_hint(errp, "Use -device vfio-user-pci,socket=<name>\n");
> + return;
> + }
> +
> + vbasedev->name = g_strdup_printf("VFIO user <%s>", udev->sock_name);
> +
> + /*
> + * vfio-user devices are effectively mdevs (don't use a host iommu).
> + */
> + vbasedev->mdev = true;
> +
> + as = pci_device_iommu_address_space(pdev);
> + if (!vfio_device_attach_by_iommu_type(TYPE_VFIO_IOMMU_USER,
> + vbasedev->name, vbasedev,
> + as, errp)) {
> + error_prepend(errp, VFIO_MSG_PREFIX, vbasedev->name);
> + return;
> + }
> +}
> +
> +static void vfio_user_instance_init(Object *obj)
> +{
> + PCIDevice *pci_dev = PCI_DEVICE(obj);
> + VFIOPCIDevice *vdev = VFIO_PCI_BASE(obj);
> + VFIODevice *vbasedev = &vdev->vbasedev;
> +
> + device_add_bootindex_property(obj, &vdev->bootindex,
> + "bootindex", NULL,
> + &pci_dev->qdev);
> + vdev->host.domain = ~0U;
> + vdev->host.bus = ~0U;
> + vdev->host.slot = ~0U;
> + vdev->host.function = ~0U;
> +
> + vfio_device_init(vbasedev, VFIO_DEVICE_TYPE_PCI, &vfio_user_pci_ops,
> + DEVICE(vdev), false);
> +
> + vdev->nv_gpudirect_clique = 0xFF;
> +
> + /*
> + * QEMU_PCI_CAP_EXPRESS initialization does not depend on QEMU command
> + * line, therefore, no need to wait to realize like other devices.
> + */
> + pci_dev->cap_present |= QEMU_PCI_CAP_EXPRESS;
> +}
> +
> +static void vfio_user_instance_finalize(Object *obj)
> +{
> + VFIOPCIDevice *vdev = VFIO_PCI_BASE(obj);
> +
> + vfio_pci_put_device(vdev);
> +}
> +
> +static const Property vfio_user_pci_dev_properties[] = {
> + 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_STRING("socket", VFIOUserPCIDevice, sock_name),
> +};
> +
> +static void vfio_user_pci_dev_class_init(ObjectClass *klass, const void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> + PCIDeviceClass *pdc = PCI_DEVICE_CLASS(klass);
> +
> + device_class_set_props(dc, vfio_user_pci_dev_properties);
> + dc->desc = "VFIO over socket PCI device assignment";
> + pdc->realize = vfio_user_pci_realize;
> +}
> +
> +static const TypeInfo vfio_user_pci_dev_info = {
> + .name = TYPE_VFIO_USER_PCI,
> + .parent = TYPE_VFIO_PCI_BASE,
> + .instance_size = sizeof(VFIOUserPCIDevice),
> + .class_init = vfio_user_pci_dev_class_init,
> + .instance_init = vfio_user_instance_init,
> + .instance_finalize = vfio_user_instance_finalize,
> +};
> +
> +static void register_vfio_user_dev_type(void)
> +{
> + type_register_static(&vfio_user_pci_dev_info);
> +}
> +
> + type_init(register_vfio_user_dev_type)
> diff --git a/hw/meson.build b/hw/meson.build
> index b91f761fe0..791ce21ab4 100644
> --- a/hw/meson.build
> +++ b/hw/meson.build
> @@ -39,6 +39,7 @@ subdir('uefi')
> subdir('ufs')
> subdir('usb')
> subdir('vfio')
> +subdir('vfio-user')
> subdir('virtio')
> subdir('vmapple')
> subdir('watchdog')
> diff --git a/hw/vfio-user/meson.build b/hw/vfio-user/meson.build
> new file mode 100644
> index 0000000000..f1fee70c85
> --- /dev/null
> +++ b/hw/vfio-user/meson.build
> @@ -0,0 +1,9 @@
> +vfio_user_ss = ss.source_set()
> +vfio_user_ss.add(files(
> + 'container.c',
> + 'pci.c',
> +))
> +
> +if get_option('vfio_user_client').enabled()
> + specific_ss.add_all(vfio_user_ss)
> +endif
> diff --git a/meson_options.txt b/meson_options.txt
> index a442be2995..97d3db44cd 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -109,6 +109,8 @@ option('multiprocess', type: 'feature', value: 'auto',
> description: 'Out of process device emulation support')
> option('relocatable', type : 'boolean', value : true,
> description: 'toggle relocatable install')
> +option('vfio_user_client', type: 'feature', value: 'disabled',
> + description: 'vfio-user client support')
> option('vfio_user_server', type: 'feature', value: 'disabled',
> description: 'vfio-user server support')
> option('dbus_display', type: 'feature', value: 'auto',
> diff --git a/scripts/meson-buildoptions.sh b/scripts/meson-buildoptions.sh
> index f09ef9604f..2c5673769a 100644
> --- a/scripts/meson-buildoptions.sh
> +++ b/scripts/meson-buildoptions.sh
> @@ -201,6 +201,8 @@ meson_options_help() {
> printf "%s\n" ' vdi vdi image format support'
> printf "%s\n" ' vduse-blk-export'
> printf "%s\n" ' VDUSE block export support'
> + printf "%s\n" ' vfio-user-client'
> + printf "%s\n" ' vfio-user client support'
> printf "%s\n" ' vfio-user-server'
> printf "%s\n" ' vfio-user server support'
> printf "%s\n" ' vhdx vhdx image format support'
> @@ -529,6 +531,8 @@ _meson_option_parse() {
> --disable-vdi) printf "%s" -Dvdi=disabled ;;
> --enable-vduse-blk-export) printf "%s" -Dvduse_blk_export=enabled ;;
> --disable-vduse-blk-export) printf "%s" -Dvduse_blk_export=disabled ;;
> + --enable-vfio-user-client) printf "%s" -Dvfio_user_client=enabled ;;
> + --disable-vfio-user-client) printf "%s" -Dvfio_user_client=disabled ;;
> --enable-vfio-user-server) printf "%s" -Dvfio_user_server=enabled ;;
> --disable-vfio-user-server) printf "%s" -Dvfio_user_server=disabled ;;
> --enable-vhdx) printf "%s" -Dvhdx=enabled ;;
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 06/23] vfio-user: add vfio-user class and container
2025-06-12 6:39 ` Cédric Le Goater
@ 2025-06-12 14:02 ` John Levon
0 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-12 14:02 UTC (permalink / raw)
To: Cédric Le Goater
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, John Johnson, Elena Ufimtseva,
Jagannathan Raman
On Thu, Jun 12, 2025 at 08:39:17AM +0200, Cédric Le Goater wrote:
> > +static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
> > +{
> > + ERRP_GUARD();
> > + VFIOUserPCIDevice *udev = VFIO_USER_PCI(pdev);
> > + VFIOPCIDevice *vdev = VFIO_PCI_BASE(pdev);
> > + VFIODevice *vbasedev = &vdev->vbasedev;
> > + AddressSpace *as;
> > +
> > + /*
> > + * TODO: make option parser understand SocketAddress
> > + * and use that instead of having scalar options
> > + * for each socket type.
>
> Please take a look at vfu_object_class_init() to handle the
> "socket" property.
Thanks for the pointer: done. I had to switch to using JSON-style device
specification for this though, so updated docs too.
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH v3 07/23] vfio-user: connect vfio proxy to remote server
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (5 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 06/23] vfio-user: add vfio-user class and container John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-07 0:10 ` [PATCH v3 08/23] vfio-user: implement message receive infrastructure John Levon
` (16 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
Introduce the vfio-user "proxy": this is the client code responsible for
sending and receiving vfio-user messages across the control socket.
The new files hw/vfio-user/proxy.[ch] contain some basic plumbing for
managing the proxy; initialize the proxy during realization of the
VFIOUserPCIDevice instance.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/proxy.h | 82 +++++++++++++++++
include/hw/vfio/vfio-device.h | 2 +
hw/vfio-user/pci.c | 17 ++++
hw/vfio-user/proxy.c | 165 ++++++++++++++++++++++++++++++++++
hw/vfio-user/meson.build | 1 +
5 files changed, 267 insertions(+)
create mode 100644 hw/vfio-user/proxy.h
create mode 100644 hw/vfio-user/proxy.c
diff --git a/hw/vfio-user/proxy.h b/hw/vfio-user/proxy.h
new file mode 100644
index 0000000000..60fe3e0b6d
--- /dev/null
+++ b/hw/vfio-user/proxy.h
@@ -0,0 +1,82 @@
+#ifndef VFIO_USER_PROXY_H
+#define VFIO_USER_PROXY_H
+
+/*
+ * vfio protocol over a UNIX socket.
+ *
+ * Copyright © 2018, 2021 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "io/channel.h"
+#include "io/channel-socket.h"
+
+typedef struct {
+ int send_fds;
+ int recv_fds;
+ int *fds;
+} VFIOUserFDs;
+
+enum msg_type {
+ VFIO_MSG_NONE,
+ VFIO_MSG_ASYNC,
+ VFIO_MSG_WAIT,
+ VFIO_MSG_NOWAIT,
+ VFIO_MSG_REQ,
+};
+
+typedef struct VFIOUserMsg {
+ QTAILQ_ENTRY(VFIOUserMsg) next;
+ VFIOUserFDs *fds;
+ uint32_t rsize;
+ uint32_t id;
+ QemuCond cv;
+ bool complete;
+ enum msg_type type;
+} VFIOUserMsg;
+
+
+enum proxy_state {
+ VFIO_PROXY_CONNECTED = 1,
+ VFIO_PROXY_ERROR = 2,
+ VFIO_PROXY_CLOSING = 3,
+ VFIO_PROXY_CLOSED = 4,
+};
+
+typedef QTAILQ_HEAD(VFIOUserMsgQ, VFIOUserMsg) VFIOUserMsgQ;
+
+typedef struct VFIOUserProxy {
+ QLIST_ENTRY(VFIOUserProxy) next;
+ char *sockname;
+ struct QIOChannel *ioc;
+ void (*request)(void *opaque, VFIOUserMsg *msg);
+ void *req_arg;
+ int flags;
+ QemuCond close_cv;
+ AioContext *ctx;
+ QEMUBH *req_bh;
+
+ /*
+ * above only changed when BQL is held
+ * below are protected by per-proxy lock
+ */
+ QemuMutex lock;
+ VFIOUserMsgQ free;
+ VFIOUserMsgQ pending;
+ VFIOUserMsgQ incoming;
+ VFIOUserMsgQ outgoing;
+ VFIOUserMsg *last_nowait;
+ enum proxy_state state;
+} VFIOUserProxy;
+
+/* VFIOProxy flags */
+#define VFIO_PROXY_CLIENT 0x1
+
+VFIOUserProxy *vfio_user_connect_dev(SocketAddress *addr, Error **errp);
+void vfio_user_disconnect(VFIOUserProxy *proxy);
+
+#endif /* VFIO_USER_PROXY_H */
diff --git a/include/hw/vfio/vfio-device.h b/include/hw/vfio/vfio-device.h
index a23ef4ea13..09f1a21bf8 100644
--- a/include/hw/vfio/vfio-device.h
+++ b/include/hw/vfio/vfio-device.h
@@ -46,6 +46,7 @@ typedef struct VFIOMigration VFIOMigration;
typedef struct IOMMUFDBackend IOMMUFDBackend;
typedef struct VFIOIOASHwpt VFIOIOASHwpt;
+typedef struct VFIOUserProxy VFIOUserProxy;
typedef struct VFIODevice {
QLIST_ENTRY(VFIODevice) next;
@@ -86,6 +87,7 @@ typedef struct VFIODevice {
QLIST_ENTRY(VFIODevice) hwpt_next;
struct vfio_region_info **reginfo;
int *region_fds;
+ VFIOUserProxy *proxy;
} VFIODevice;
struct VFIODeviceOps {
diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
index 74b0c61f9b..f1a2d4374d 100644
--- a/hw/vfio-user/pci.c
+++ b/hw/vfio-user/pci.c
@@ -14,6 +14,7 @@
#include "hw/qdev-properties.h"
#include "hw/vfio/pci.h"
+#include "hw/vfio-user/proxy.h"
#define TYPE_VFIO_USER_PCI "vfio-user-pci"
OBJECT_DECLARE_SIMPLE_TYPE(VFIOUserPCIDevice, VFIO_USER_PCI)
@@ -55,6 +56,8 @@ static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
VFIOPCIDevice *vdev = VFIO_PCI_BASE(pdev);
VFIODevice *vbasedev = &vdev->vbasedev;
AddressSpace *as;
+ SocketAddress addr;
+ VFIOUserProxy *proxy;
/*
* TODO: make option parser understand SocketAddress
@@ -67,6 +70,15 @@ static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
return;
}
+ memset(&addr, 0, sizeof(addr));
+ addr.type = SOCKET_ADDRESS_TYPE_UNIX;
+ addr.u.q_unix.path = udev->sock_name;
+ proxy = vfio_user_connect_dev(&addr, errp);
+ if (!proxy) {
+ return;
+ }
+ vbasedev->proxy = proxy;
+
vbasedev->name = g_strdup_printf("VFIO user <%s>", udev->sock_name);
/*
@@ -112,8 +124,13 @@ static void vfio_user_instance_init(Object *obj)
static void vfio_user_instance_finalize(Object *obj)
{
VFIOPCIDevice *vdev = VFIO_PCI_BASE(obj);
+ VFIODevice *vbasedev = &vdev->vbasedev;
vfio_pci_put_device(vdev);
+
+ if (vbasedev->proxy != NULL) {
+ vfio_user_disconnect(vbasedev->proxy);
+ }
}
static const Property vfio_user_pci_dev_properties[] = {
diff --git a/hw/vfio-user/proxy.c b/hw/vfio-user/proxy.c
new file mode 100644
index 0000000000..ac481553ba
--- /dev/null
+++ b/hw/vfio-user/proxy.c
@@ -0,0 +1,165 @@
+/*
+ * vfio protocol over a UNIX socket.
+ *
+ * Copyright © 2018, 2021 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include <sys/ioctl.h>
+
+#include "hw/vfio/vfio-device.h"
+#include "hw/vfio-user/proxy.h"
+#include "qapi/error.h"
+#include "qemu/error-report.h"
+#include "qemu/lockable.h"
+#include "system/iothread.h"
+
+static IOThread *vfio_user_iothread;
+
+static void vfio_user_shutdown(VFIOUserProxy *proxy);
+
+
+/*
+ * Functions called by main, CPU, or iothread threads
+ */
+
+static void vfio_user_shutdown(VFIOUserProxy *proxy)
+{
+ qio_channel_shutdown(proxy->ioc, QIO_CHANNEL_SHUTDOWN_READ, NULL);
+ qio_channel_set_aio_fd_handler(proxy->ioc, proxy->ctx, NULL,
+ proxy->ctx, NULL, NULL);
+}
+
+/*
+ * Functions only called by iothread
+ */
+
+static void vfio_user_cb(void *opaque)
+{
+ VFIOUserProxy *proxy = opaque;
+
+ QEMU_LOCK_GUARD(&proxy->lock);
+
+ proxy->state = VFIO_PROXY_CLOSED;
+ qemu_cond_signal(&proxy->close_cv);
+}
+
+
+/*
+ * Functions called by main or CPU threads
+ */
+
+static QLIST_HEAD(, VFIOUserProxy) vfio_user_sockets =
+ QLIST_HEAD_INITIALIZER(vfio_user_sockets);
+
+VFIOUserProxy *vfio_user_connect_dev(SocketAddress *addr, Error **errp)
+{
+ VFIOUserProxy *proxy;
+ QIOChannelSocket *sioc;
+ QIOChannel *ioc;
+ char *sockname;
+
+ if (addr->type != SOCKET_ADDRESS_TYPE_UNIX) {
+ error_setg(errp, "vfio_user_connect - bad address family");
+ return NULL;
+ }
+ sockname = addr->u.q_unix.path;
+
+ sioc = qio_channel_socket_new();
+ ioc = QIO_CHANNEL(sioc);
+ if (qio_channel_socket_connect_sync(sioc, addr, errp)) {
+ object_unref(OBJECT(ioc));
+ return NULL;
+ }
+ qio_channel_set_blocking(ioc, false, NULL);
+
+ proxy = g_malloc0(sizeof(VFIOUserProxy));
+ proxy->sockname = g_strdup_printf("unix:%s", sockname);
+ proxy->ioc = ioc;
+ proxy->flags = VFIO_PROXY_CLIENT;
+ proxy->state = VFIO_PROXY_CONNECTED;
+
+ qemu_mutex_init(&proxy->lock);
+ qemu_cond_init(&proxy->close_cv);
+
+ if (vfio_user_iothread == NULL) {
+ vfio_user_iothread = iothread_create("VFIO user", errp);
+ }
+
+ proxy->ctx = iothread_get_aio_context(vfio_user_iothread);
+
+ QTAILQ_INIT(&proxy->outgoing);
+ QTAILQ_INIT(&proxy->incoming);
+ QTAILQ_INIT(&proxy->free);
+ QTAILQ_INIT(&proxy->pending);
+ QLIST_INSERT_HEAD(&vfio_user_sockets, proxy, next);
+
+ return proxy;
+}
+
+void vfio_user_disconnect(VFIOUserProxy *proxy)
+{
+ VFIOUserMsg *r1, *r2;
+
+ qemu_mutex_lock(&proxy->lock);
+
+ /* our side is quitting */
+ if (proxy->state == VFIO_PROXY_CONNECTED) {
+ vfio_user_shutdown(proxy);
+ if (!QTAILQ_EMPTY(&proxy->pending)) {
+ error_printf("vfio_user_disconnect: outstanding requests\n");
+ }
+ }
+ object_unref(OBJECT(proxy->ioc));
+ proxy->ioc = NULL;
+
+ proxy->state = VFIO_PROXY_CLOSING;
+ QTAILQ_FOREACH_SAFE(r1, &proxy->outgoing, next, r2) {
+ qemu_cond_destroy(&r1->cv);
+ QTAILQ_REMOVE(&proxy->outgoing, r1, next);
+ g_free(r1);
+ }
+ QTAILQ_FOREACH_SAFE(r1, &proxy->incoming, next, r2) {
+ qemu_cond_destroy(&r1->cv);
+ QTAILQ_REMOVE(&proxy->incoming, r1, next);
+ g_free(r1);
+ }
+ QTAILQ_FOREACH_SAFE(r1, &proxy->pending, next, r2) {
+ qemu_cond_destroy(&r1->cv);
+ QTAILQ_REMOVE(&proxy->pending, r1, next);
+ g_free(r1);
+ }
+ QTAILQ_FOREACH_SAFE(r1, &proxy->free, next, r2) {
+ qemu_cond_destroy(&r1->cv);
+ QTAILQ_REMOVE(&proxy->free, r1, next);
+ g_free(r1);
+ }
+
+ /*
+ * Make sure the iothread isn't blocking anywhere
+ * with a ref to this proxy by waiting for a BH
+ * handler to run after the proxy fd handlers were
+ * deleted above.
+ */
+ aio_bh_schedule_oneshot(proxy->ctx, vfio_user_cb, proxy);
+ qemu_cond_wait(&proxy->close_cv, &proxy->lock);
+
+ /* we now hold the only ref to proxy */
+ qemu_mutex_unlock(&proxy->lock);
+ qemu_cond_destroy(&proxy->close_cv);
+ qemu_mutex_destroy(&proxy->lock);
+
+ QLIST_REMOVE(proxy, next);
+ if (QLIST_EMPTY(&vfio_user_sockets)) {
+ iothread_destroy(vfio_user_iothread);
+ vfio_user_iothread = NULL;
+ }
+
+ g_free(proxy->sockname);
+ g_free(proxy);
+}
diff --git a/hw/vfio-user/meson.build b/hw/vfio-user/meson.build
index f1fee70c85..695b341547 100644
--- a/hw/vfio-user/meson.build
+++ b/hw/vfio-user/meson.build
@@ -2,6 +2,7 @@ vfio_user_ss = ss.source_set()
vfio_user_ss.add(files(
'container.c',
'pci.c',
+ 'proxy.c',
))
if get_option('vfio_user_client').enabled()
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 08/23] vfio-user: implement message receive infrastructure
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (6 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 07/23] vfio-user: connect vfio proxy to remote server John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-07 0:10 ` [PATCH v3 09/23] vfio-user: implement message send infrastructure John Levon
` (15 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
Add the basic implementation for receiving vfio-user messages from the
control socket.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
meson.build | 1 +
hw/vfio-user/protocol.h | 56 ++++++
hw/vfio-user/proxy.h | 11 +
hw/vfio-user/trace.h | 1 +
hw/vfio-user/pci.c | 11 +
hw/vfio-user/proxy.c | 409 ++++++++++++++++++++++++++++++++++++++
hw/vfio-user/trace-events | 6 +
7 files changed, 495 insertions(+)
create mode 100644 hw/vfio-user/protocol.h
create mode 100644 hw/vfio-user/trace.h
create mode 100644 hw/vfio-user/trace-events
diff --git a/meson.build b/meson.build
index 967a10e80b..45aec2a4ad 100644
--- a/meson.build
+++ b/meson.build
@@ -3679,6 +3679,7 @@ if have_system
'hw/ufs',
'hw/usb',
'hw/vfio',
+ 'hw/vfio-user',
'hw/virtio',
'hw/vmapple',
'hw/watchdog',
diff --git a/hw/vfio-user/protocol.h b/hw/vfio-user/protocol.h
new file mode 100644
index 0000000000..6300c681e7
--- /dev/null
+++ b/hw/vfio-user/protocol.h
@@ -0,0 +1,56 @@
+#ifndef VFIO_USER_PROTOCOL_H
+#define VFIO_USER_PROTOCOL_H
+
+/*
+ * vfio protocol over a UNIX socket.
+ *
+ * Copyright © 2018, 2021 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ * Each message has a standard header that describes the command
+ * being sent, which is almost always a VFIO ioctl().
+ *
+ * The header may be followed by command-specific data, such as the
+ * region and offset info for read and write commands.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+typedef struct {
+ uint16_t id;
+ uint16_t command;
+ uint32_t size;
+ uint32_t flags;
+ uint32_t error_reply;
+} VFIOUserHdr;
+
+/* VFIOUserHdr commands */
+enum vfio_user_command {
+ VFIO_USER_VERSION = 1,
+ VFIO_USER_DMA_MAP = 2,
+ VFIO_USER_DMA_UNMAP = 3,
+ VFIO_USER_DEVICE_GET_INFO = 4,
+ VFIO_USER_DEVICE_GET_REGION_INFO = 5,
+ VFIO_USER_DEVICE_GET_REGION_IO_FDS = 6,
+ VFIO_USER_DEVICE_GET_IRQ_INFO = 7,
+ VFIO_USER_DEVICE_SET_IRQS = 8,
+ VFIO_USER_REGION_READ = 9,
+ VFIO_USER_REGION_WRITE = 10,
+ VFIO_USER_DMA_READ = 11,
+ VFIO_USER_DMA_WRITE = 12,
+ VFIO_USER_DEVICE_RESET = 13,
+ VFIO_USER_DIRTY_PAGES = 14,
+ VFIO_USER_MAX,
+};
+
+/* VFIOUserHdr flags */
+#define VFIO_USER_REQUEST 0x0
+#define VFIO_USER_REPLY 0x1
+#define VFIO_USER_TYPE 0xF
+
+#define VFIO_USER_NO_REPLY 0x10
+#define VFIO_USER_ERROR 0x20
+
+#endif /* VFIO_USER_PROTOCOL_H */
diff --git a/hw/vfio-user/proxy.h b/hw/vfio-user/proxy.h
index 60fe3e0b6d..0105479d02 100644
--- a/hw/vfio-user/proxy.h
+++ b/hw/vfio-user/proxy.h
@@ -15,6 +15,9 @@
#include "io/channel.h"
#include "io/channel-socket.h"
+#include "qemu/sockets.h"
+#include "hw/vfio-user/protocol.h"
+
typedef struct {
int send_fds;
int recv_fds;
@@ -31,6 +34,7 @@ enum msg_type {
typedef struct VFIOUserMsg {
QTAILQ_ENTRY(VFIOUserMsg) next;
+ VFIOUserHdr *hdr;
VFIOUserFDs *fds;
uint32_t rsize;
uint32_t id;
@@ -70,13 +74,20 @@ typedef struct VFIOUserProxy {
VFIOUserMsgQ incoming;
VFIOUserMsgQ outgoing;
VFIOUserMsg *last_nowait;
+ VFIOUserMsg *part_recv;
+ size_t recv_left;
enum proxy_state state;
} VFIOUserProxy;
/* VFIOProxy flags */
#define VFIO_PROXY_CLIENT 0x1
+typedef struct VFIODevice VFIODevice;
+
VFIOUserProxy *vfio_user_connect_dev(SocketAddress *addr, Error **errp);
void vfio_user_disconnect(VFIOUserProxy *proxy);
+void vfio_user_set_handler(VFIODevice *vbasedev,
+ void (*handler)(void *opaque, VFIOUserMsg *msg),
+ void *reqarg);
#endif /* VFIO_USER_PROXY_H */
diff --git a/hw/vfio-user/trace.h b/hw/vfio-user/trace.h
new file mode 100644
index 0000000000..574b59aa89
--- /dev/null
+++ b/hw/vfio-user/trace.h
@@ -0,0 +1 @@
+#include "trace/trace-hw_vfio_user.h"
diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
index f1a2d4374d..93bd0e1361 100644
--- a/hw/vfio-user/pci.c
+++ b/hw/vfio-user/pci.c
@@ -24,6 +24,16 @@ struct VFIOUserPCIDevice {
char *sock_name;
};
+/*
+ * Incoming request message callback.
+ *
+ * Runs off main loop, so BQL held.
+ */
+static void vfio_user_pci_process_req(void *opaque, VFIOUserMsg *msg)
+{
+
+}
+
/*
* Emulated devices don't use host hot reset
*/
@@ -78,6 +88,7 @@ static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
return;
}
vbasedev->proxy = proxy;
+ vfio_user_set_handler(vbasedev, vfio_user_pci_process_req, vdev);
vbasedev->name = g_strdup_printf("VFIO user <%s>", udev->sock_name);
diff --git a/hw/vfio-user/proxy.c b/hw/vfio-user/proxy.c
index ac481553ba..4a654d7597 100644
--- a/hw/vfio-user/proxy.c
+++ b/hw/vfio-user/proxy.c
@@ -14,15 +14,32 @@
#include "hw/vfio/vfio-device.h"
#include "hw/vfio-user/proxy.h"
+#include "hw/vfio-user/trace.h"
#include "qapi/error.h"
#include "qemu/error-report.h"
#include "qemu/lockable.h"
+#include "qemu/main-loop.h"
#include "system/iothread.h"
static IOThread *vfio_user_iothread;
static void vfio_user_shutdown(VFIOUserProxy *proxy);
+static VFIOUserMsg *vfio_user_getmsg(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
+ VFIOUserFDs *fds);
+static VFIOUserFDs *vfio_user_getfds(int numfds);
+static void vfio_user_recycle(VFIOUserProxy *proxy, VFIOUserMsg *msg);
+static void vfio_user_recv(void *opaque);
+static int vfio_user_recv_one(VFIOUserProxy *proxy);
+static void vfio_user_cb(void *opaque);
+
+static void vfio_user_request(void *opaque);
+
+static inline void vfio_user_set_error(VFIOUserHdr *hdr, uint32_t err)
+{
+ hdr->flags |= VFIO_USER_ERROR;
+ hdr->error_reply = err;
+}
/*
* Functions called by main, CPU, or iothread threads
@@ -35,10 +52,340 @@ static void vfio_user_shutdown(VFIOUserProxy *proxy)
proxy->ctx, NULL, NULL);
}
+static VFIOUserMsg *vfio_user_getmsg(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
+ VFIOUserFDs *fds)
+{
+ VFIOUserMsg *msg;
+
+ msg = QTAILQ_FIRST(&proxy->free);
+ if (msg != NULL) {
+ QTAILQ_REMOVE(&proxy->free, msg, next);
+ } else {
+ msg = g_malloc0(sizeof(*msg));
+ qemu_cond_init(&msg->cv);
+ }
+
+ msg->hdr = hdr;
+ msg->fds = fds;
+ return msg;
+}
+
+/*
+ * Recycle a message list entry to the free list.
+ */
+static void vfio_user_recycle(VFIOUserProxy *proxy, VFIOUserMsg *msg)
+{
+ if (msg->type == VFIO_MSG_NONE) {
+ error_printf("vfio_user_recycle - freeing free msg\n");
+ return;
+ }
+
+ /* free msg buffer if no one is waiting to consume the reply */
+ if (msg->type == VFIO_MSG_NOWAIT || msg->type == VFIO_MSG_ASYNC) {
+ g_free(msg->hdr);
+ if (msg->fds != NULL) {
+ g_free(msg->fds);
+ }
+ }
+
+ msg->type = VFIO_MSG_NONE;
+ msg->hdr = NULL;
+ msg->fds = NULL;
+ msg->complete = false;
+ QTAILQ_INSERT_HEAD(&proxy->free, msg, next);
+}
+
+static VFIOUserFDs *vfio_user_getfds(int numfds)
+{
+ VFIOUserFDs *fds = g_malloc0(sizeof(*fds) + (numfds * sizeof(int)));
+
+ fds->fds = (int *)((char *)fds + sizeof(*fds));
+
+ return fds;
+}
+
/*
* Functions only called by iothread
*/
+/*
+ * Process a received message.
+ */
+static void vfio_user_process(VFIOUserProxy *proxy, VFIOUserMsg *msg,
+ bool isreply)
+{
+
+ /*
+ * Replies signal a waiter, if none just check for errors
+ * and free the message buffer.
+ *
+ * Requests get queued for the BH.
+ */
+ if (isreply) {
+ msg->complete = true;
+ if (msg->type == VFIO_MSG_WAIT) {
+ qemu_cond_signal(&msg->cv);
+ } else {
+ if (msg->hdr->flags & VFIO_USER_ERROR) {
+ error_printf("vfio_user_process: error reply on async ");
+ error_printf("request command %x error %s\n",
+ msg->hdr->command,
+ strerror(msg->hdr->error_reply));
+ }
+ /* youngest nowait msg has been ack'd */
+ if (proxy->last_nowait == msg) {
+ proxy->last_nowait = NULL;
+ }
+ vfio_user_recycle(proxy, msg);
+ }
+ } else {
+ QTAILQ_INSERT_TAIL(&proxy->incoming, msg, next);
+ qemu_bh_schedule(proxy->req_bh);
+ }
+}
+
+/*
+ * Complete a partial message read
+ */
+static int vfio_user_complete(VFIOUserProxy *proxy, Error **errp)
+{
+ VFIOUserMsg *msg = proxy->part_recv;
+ size_t msgleft = proxy->recv_left;
+ bool isreply;
+ char *data;
+ int ret;
+
+ data = (char *)msg->hdr + (msg->hdr->size - msgleft);
+ while (msgleft > 0) {
+ ret = qio_channel_read(proxy->ioc, data, msgleft, errp);
+
+ /* error or would block */
+ if (ret <= 0) {
+ /* try for rest on next iternation */
+ if (ret == QIO_CHANNEL_ERR_BLOCK) {
+ proxy->recv_left = msgleft;
+ }
+ return ret;
+ }
+ trace_vfio_user_recv_read(msg->hdr->id, ret);
+
+ msgleft -= ret;
+ data += ret;
+ }
+
+ /*
+ * Read complete message, process it.
+ */
+ proxy->part_recv = NULL;
+ proxy->recv_left = 0;
+ isreply = (msg->hdr->flags & VFIO_USER_TYPE) == VFIO_USER_REPLY;
+ vfio_user_process(proxy, msg, isreply);
+
+ /* return positive value */
+ return 1;
+}
+
+static void vfio_user_recv(void *opaque)
+{
+ VFIOUserProxy *proxy = opaque;
+
+ QEMU_LOCK_GUARD(&proxy->lock);
+
+ if (proxy->state == VFIO_PROXY_CONNECTED) {
+ while (vfio_user_recv_one(proxy) == 0) {
+ ;
+ }
+ }
+}
+
+/*
+ * Receive and process one incoming message.
+ *
+ * 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)
+{
+ VFIOUserMsg *msg = NULL;
+ g_autofree int *fdp = NULL;
+ VFIOUserFDs *reqfds;
+ VFIOUserHdr hdr;
+ struct iovec iov = {
+ .iov_base = &hdr,
+ .iov_len = sizeof(hdr),
+ };
+ bool isreply = false;
+ int i, ret;
+ size_t msgleft, numfds = 0;
+ char *data = NULL;
+ char *buf = NULL;
+ Error *local_err = NULL;
+
+ /*
+ * Complete any partial reads
+ */
+ if (proxy->part_recv != NULL) {
+ ret = vfio_user_complete(proxy, &local_err);
+
+ /* still not complete, try later */
+ if (ret == QIO_CHANNEL_ERR_BLOCK) {
+ return ret;
+ }
+
+ if (ret <= 0) {
+ goto fatal;
+ }
+ /* else fall into reading another msg */
+ }
+
+ /*
+ * Read header
+ */
+ ret = qio_channel_readv_full(proxy->ioc, &iov, 1, &fdp, &numfds, 0,
+ &local_err);
+ if (ret == QIO_CHANNEL_ERR_BLOCK) {
+ return ret;
+ }
+
+ /* read error or other side closed connection */
+ if (ret <= 0) {
+ goto fatal;
+ }
+
+ if (ret < sizeof(hdr)) {
+ error_setg(&local_err, "short read of header");
+ goto fatal;
+ }
+
+ /*
+ * Validate header
+ */
+ if (hdr.size < sizeof(VFIOUserHdr)) {
+ error_setg(&local_err, "bad header size");
+ goto fatal;
+ }
+ switch (hdr.flags & VFIO_USER_TYPE) {
+ case VFIO_USER_REQUEST:
+ isreply = false;
+ break;
+ case VFIO_USER_REPLY:
+ isreply = true;
+ break;
+ default:
+ error_setg(&local_err, "unknown message type");
+ goto fatal;
+ }
+ trace_vfio_user_recv_hdr(proxy->sockname, hdr.id, hdr.command, hdr.size,
+ hdr.flags);
+
+ /*
+ * For replies, find the matching pending request.
+ * For requests, reap incoming FDs.
+ */
+ if (isreply) {
+ QTAILQ_FOREACH(msg, &proxy->pending, next) {
+ if (hdr.id == msg->id) {
+ break;
+ }
+ }
+ if (msg == NULL) {
+ error_setg(&local_err, "unexpected reply");
+ goto err;
+ }
+ QTAILQ_REMOVE(&proxy->pending, msg, next);
+
+ /*
+ * Process any received FDs
+ */
+ if (numfds != 0) {
+ if (msg->fds == NULL || msg->fds->recv_fds < numfds) {
+ error_setg(&local_err, "unexpected FDs");
+ goto err;
+ }
+ msg->fds->recv_fds = numfds;
+ memcpy(msg->fds->fds, fdp, numfds * sizeof(int));
+ }
+ } else {
+ if (numfds != 0) {
+ reqfds = vfio_user_getfds(numfds);
+ memcpy(reqfds->fds, fdp, numfds * sizeof(int));
+ } else {
+ reqfds = NULL;
+ }
+ }
+
+ /*
+ * Put the whole message into a single buffer.
+ */
+ if (isreply) {
+ if (hdr.size > msg->rsize) {
+ error_setg(&local_err, "reply larger than recv buffer");
+ goto err;
+ }
+ *msg->hdr = hdr;
+ data = (char *)msg->hdr + sizeof(hdr);
+ } else {
+ buf = g_malloc0(hdr.size);
+ memcpy(buf, &hdr, sizeof(hdr));
+ data = buf + sizeof(hdr);
+ msg = vfio_user_getmsg(proxy, (VFIOUserHdr *)buf, reqfds);
+ msg->type = VFIO_MSG_REQ;
+ }
+
+ /*
+ * Read rest of message.
+ */
+ msgleft = hdr.size - sizeof(hdr);
+ while (msgleft > 0) {
+ ret = qio_channel_read(proxy->ioc, data, msgleft, &local_err);
+
+ /* prepare to complete read on next iternation */
+ if (ret == QIO_CHANNEL_ERR_BLOCK) {
+ proxy->part_recv = msg;
+ proxy->recv_left = msgleft;
+ return ret;
+ }
+
+ if (ret <= 0) {
+ goto fatal;
+ }
+ trace_vfio_user_recv_read(hdr.id, ret);
+
+ msgleft -= ret;
+ data += ret;
+ }
+
+ vfio_user_process(proxy, msg, isreply);
+ return 0;
+
+ /*
+ * fatal means the other side closed or we don't trust the stream
+ * err means this message is corrupt
+ */
+fatal:
+ vfio_user_shutdown(proxy);
+ proxy->state = VFIO_PROXY_ERROR;
+
+ /* set error if server side closed */
+ if (ret == 0) {
+ error_setg(&local_err, "server closed socket");
+ }
+
+err:
+ for (i = 0; i < numfds; i++) {
+ close(fdp[i]);
+ }
+ if (isreply && msg != NULL) {
+ /* force an error to keep sending thread from hanging */
+ vfio_user_set_error(msg->hdr, EINVAL);
+ msg->complete = true;
+ qemu_cond_signal(&msg->cv);
+ }
+ error_prepend(&local_err, "vfio_user_recv_one: ");
+ error_report_err(local_err);
+ return -1;
+}
+
static void vfio_user_cb(void *opaque)
{
VFIOUserProxy *proxy = opaque;
@@ -54,6 +401,53 @@ static void vfio_user_cb(void *opaque)
* Functions called by main or CPU threads
*/
+/*
+ * Process incoming requests.
+ *
+ * The bus-specific callback has the form:
+ * request(opaque, msg)
+ * where 'opaque' was specified in vfio_user_set_handler
+ * and 'msg' is the inbound message.
+ *
+ * The callback is responsible for disposing of the message buffer,
+ * usually by re-using it when calling vfio_send_reply or vfio_send_error,
+ * both of which free their message buffer when the reply is sent.
+ *
+ * If the callback uses a new buffer, it needs to free the old one.
+ */
+static void vfio_user_request(void *opaque)
+{
+ VFIOUserProxy *proxy = opaque;
+ VFIOUserMsgQ new, free;
+ VFIOUserMsg *msg, *m1;
+
+ /* reap all incoming */
+ QTAILQ_INIT(&new);
+ WITH_QEMU_LOCK_GUARD(&proxy->lock) {
+ QTAILQ_FOREACH_SAFE(msg, &proxy->incoming, next, m1) {
+ QTAILQ_REMOVE(&proxy->incoming, msg, next);
+ QTAILQ_INSERT_TAIL(&new, msg, next);
+ }
+ }
+
+ /* process list */
+ QTAILQ_INIT(&free);
+ QTAILQ_FOREACH_SAFE(msg, &new, next, m1) {
+ QTAILQ_REMOVE(&new, msg, next);
+ trace_vfio_user_recv_request(msg->hdr->command);
+ proxy->request(proxy->req_arg, msg);
+ QTAILQ_INSERT_HEAD(&free, msg, next);
+ }
+
+ /* free list */
+ WITH_QEMU_LOCK_GUARD(&proxy->lock) {
+ QTAILQ_FOREACH_SAFE(msg, &free, next, m1) {
+ vfio_user_recycle(proxy, msg);
+ }
+ }
+}
+
+
static QLIST_HEAD(, VFIOUserProxy) vfio_user_sockets =
QLIST_HEAD_INITIALIZER(vfio_user_sockets);
@@ -92,6 +486,7 @@ VFIOUserProxy *vfio_user_connect_dev(SocketAddress *addr, Error **errp)
}
proxy->ctx = iothread_get_aio_context(vfio_user_iothread);
+ proxy->req_bh = qemu_bh_new(vfio_user_request, proxy);
QTAILQ_INIT(&proxy->outgoing);
QTAILQ_INIT(&proxy->incoming);
@@ -102,6 +497,18 @@ VFIOUserProxy *vfio_user_connect_dev(SocketAddress *addr, Error **errp)
return proxy;
}
+void vfio_user_set_handler(VFIODevice *vbasedev,
+ void (*handler)(void *opaque, VFIOUserMsg *msg),
+ void *req_arg)
+{
+ VFIOUserProxy *proxy = vbasedev->proxy;
+
+ proxy->request = handler;
+ proxy->req_arg = req_arg;
+ qio_channel_set_aio_fd_handler(proxy->ioc, proxy->ctx,
+ vfio_user_recv, NULL, NULL, proxy);
+}
+
void vfio_user_disconnect(VFIOUserProxy *proxy)
{
VFIOUserMsg *r1, *r2;
@@ -117,6 +524,8 @@ void vfio_user_disconnect(VFIOUserProxy *proxy)
}
object_unref(OBJECT(proxy->ioc));
proxy->ioc = NULL;
+ qemu_bh_delete(proxy->req_bh);
+ proxy->req_bh = NULL;
proxy->state = VFIO_PROXY_CLOSING;
QTAILQ_FOREACH_SAFE(r1, &proxy->outgoing, next, r2) {
diff --git a/hw/vfio-user/trace-events b/hw/vfio-user/trace-events
new file mode 100644
index 0000000000..89d6c11c4c
--- /dev/null
+++ b/hw/vfio-user/trace-events
@@ -0,0 +1,6 @@
+# See docs/devel/tracing.rst for syntax documentation.
+
+# common.c
+vfio_user_recv_hdr(const char *name, uint16_t id, uint16_t cmd, uint32_t size, uint32_t flags) " (%s) id 0x%x cmd 0x%x size 0x%x flags 0x%x"
+vfio_user_recv_read(uint16_t id, int read) " id 0x%x read 0x%x"
+vfio_user_recv_request(uint16_t cmd) " command 0x%x"
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 09/23] vfio-user: implement message send infrastructure
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (7 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 08/23] vfio-user: implement message receive infrastructure John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-07 0:10 ` [PATCH v3 10/23] vfio-user: implement VFIO_USER_DEVICE_GET_INFO John Levon
` (14 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Jagannathan Raman, Elena Ufimtseva
Add plumbing for sending vfio-user messages on the control socket.
Add initial version negotation on connection.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/protocol.h | 62 +++++
hw/vfio-user/proxy.h | 9 +
hw/vfio-user/pci.c | 18 +-
hw/vfio-user/proxy.c | 494 ++++++++++++++++++++++++++++++++++++++
hw/vfio-user/trace-events | 2 +
5 files changed, 583 insertions(+), 2 deletions(-)
diff --git a/hw/vfio-user/protocol.h b/hw/vfio-user/protocol.h
index 6300c681e7..74ea2a94e6 100644
--- a/hw/vfio-user/protocol.h
+++ b/hw/vfio-user/protocol.h
@@ -53,4 +53,66 @@ enum vfio_user_command {
#define VFIO_USER_NO_REPLY 0x10
#define VFIO_USER_ERROR 0x20
+
+/*
+ * VFIO_USER_VERSION
+ */
+typedef struct {
+ VFIOUserHdr hdr;
+ uint16_t major;
+ uint16_t minor;
+ char capabilities[];
+} VFIOUserVersion;
+
+#define VFIO_USER_MAJOR_VER 0
+#define VFIO_USER_MINOR_VER 0
+
+#define VFIO_USER_CAP "capabilities"
+
+/* "capabilities" members */
+#define VFIO_USER_CAP_MAX_FDS "max_msg_fds"
+#define VFIO_USER_CAP_MAX_XFER "max_data_xfer_size"
+#define VFIO_USER_CAP_PGSIZES "pgsizes"
+#define VFIO_USER_CAP_MAP_MAX "max_dma_maps"
+#define VFIO_USER_CAP_MIGR "migration"
+
+/* "migration" members */
+#define VFIO_USER_CAP_PGSIZE "pgsize"
+#define VFIO_USER_CAP_MAX_BITMAP "max_bitmap_size"
+
+/*
+ * Max FDs mainly comes into play when a device supports multiple interrupts
+ * where each ones uses an eventfd to inject it into the guest.
+ * It is clamped by the the number of FDs the qio channel supports in a
+ * single message.
+ */
+#define VFIO_USER_DEF_MAX_FDS 8
+#define VFIO_USER_MAX_MAX_FDS 16
+
+/*
+ * Max transfer limits the amount of data in region and DMA messages.
+ * Region R/W will be very small (limited by how much a single instruction
+ * can process) so just use a reasonable limit here.
+ */
+#define VFIO_USER_DEF_MAX_XFER (1024 * 1024)
+#define VFIO_USER_MAX_MAX_XFER (64 * 1024 * 1024)
+
+/*
+ * Default pagesizes supported is 4k.
+ */
+#define VFIO_USER_DEF_PGSIZE 4096
+
+/*
+ * Default max number of DMA mappings is stolen from the
+ * linux kernel "dma_entry_limit"
+ */
+#define VFIO_USER_DEF_MAP_MAX 65535
+
+/*
+ * Default max bitmap size is also take from the linux kernel,
+ * where usage of signed ints limits the VA range to 2^31 bytes.
+ * Dividing that by the number of bits per byte yields 256MB
+ */
+#define VFIO_USER_DEF_MAX_BITMAP (256 * 1024 * 1024)
+
#endif /* VFIO_USER_PROTOCOL_H */
diff --git a/hw/vfio-user/proxy.h b/hw/vfio-user/proxy.h
index 0105479d02..33e8a4d83b 100644
--- a/hw/vfio-user/proxy.h
+++ b/hw/vfio-user/proxy.h
@@ -40,6 +40,7 @@ typedef struct VFIOUserMsg {
uint32_t id;
QemuCond cv;
bool complete;
+ bool pending;
enum msg_type type;
} VFIOUserMsg;
@@ -59,6 +60,12 @@ typedef struct VFIOUserProxy {
struct QIOChannel *ioc;
void (*request)(void *opaque, VFIOUserMsg *msg);
void *req_arg;
+ uint64_t max_xfer_size;
+ uint64_t max_send_fds;
+ uint64_t max_dma;
+ uint64_t dma_pgsizes;
+ uint64_t max_bitmap;
+ uint64_t migr_pgsize;
int flags;
QemuCond close_cv;
AioContext *ctx;
@@ -81,6 +88,7 @@ typedef struct VFIOUserProxy {
/* VFIOProxy flags */
#define VFIO_PROXY_CLIENT 0x1
+#define VFIO_PROXY_FORCE_QUEUED 0x4
typedef struct VFIODevice VFIODevice;
@@ -89,5 +97,6 @@ void vfio_user_disconnect(VFIOUserProxy *proxy);
void vfio_user_set_handler(VFIODevice *vbasedev,
void (*handler)(void *opaque, VFIOUserMsg *msg),
void *reqarg);
+bool vfio_user_validate_version(VFIOUserProxy *proxy, Error **errp);
#endif /* VFIO_USER_PROXY_H */
diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
index 93bd0e1361..bcef0ea341 100644
--- a/hw/vfio-user/pci.c
+++ b/hw/vfio-user/pci.c
@@ -22,6 +22,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(VFIOUserPCIDevice, VFIO_USER_PCI)
struct VFIOUserPCIDevice {
VFIOPCIDevice device;
char *sock_name;
+ bool send_queued; /* all sends are queued */
};
/*
@@ -90,6 +91,14 @@ static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
vbasedev->proxy = proxy;
vfio_user_set_handler(vbasedev, vfio_user_pci_process_req, vdev);
+ if (udev->send_queued) {
+ proxy->flags |= VFIO_PROXY_FORCE_QUEUED;
+ }
+
+ if (!vfio_user_validate_version(proxy, errp)) {
+ goto error;
+ }
+
vbasedev->name = g_strdup_printf("VFIO user <%s>", udev->sock_name);
/*
@@ -101,9 +110,13 @@ static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
if (!vfio_device_attach_by_iommu_type(TYPE_VFIO_IOMMU_USER,
vbasedev->name, vbasedev,
as, errp)) {
- error_prepend(errp, VFIO_MSG_PREFIX, vbasedev->name);
- return;
+ goto error;
}
+
+ return;
+
+error:
+ error_prepend(errp, VFIO_MSG_PREFIX, vdev->vbasedev.name);
}
static void vfio_user_instance_init(Object *obj)
@@ -154,6 +167,7 @@ static const Property vfio_user_pci_dev_properties[] = {
DEFINE_PROP_UINT32("x-pci-sub-device-id", VFIOPCIDevice,
sub_device_id, PCI_ANY_ID),
DEFINE_PROP_STRING("socket", VFIOUserPCIDevice, sock_name),
+ DEFINE_PROP_BOOL("x-send-queued", VFIOUserPCIDevice, send_queued, false),
};
static void vfio_user_pci_dev_class_init(ObjectClass *klass, const void *data)
diff --git a/hw/vfio-user/proxy.c b/hw/vfio-user/proxy.c
index 4a654d7597..0bc12da865 100644
--- a/hw/vfio-user/proxy.c
+++ b/hw/vfio-user/proxy.c
@@ -16,14 +16,19 @@
#include "hw/vfio-user/proxy.h"
#include "hw/vfio-user/trace.h"
#include "qapi/error.h"
+#include "qobject/qdict.h"
+#include "qobject/qjson.h"
+#include "qobject/qnum.h"
#include "qemu/error-report.h"
#include "qemu/lockable.h"
#include "qemu/main-loop.h"
#include "system/iothread.h"
+static int wait_time = 5000; /* wait up to 5 sec for busy servers */
static IOThread *vfio_user_iothread;
static void vfio_user_shutdown(VFIOUserProxy *proxy);
+static int vfio_user_send_qio(VFIOUserProxy *proxy, VFIOUserMsg *msg);
static VFIOUserMsg *vfio_user_getmsg(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
VFIOUserFDs *fds);
static VFIOUserFDs *vfio_user_getfds(int numfds);
@@ -31,9 +36,16 @@ static void vfio_user_recycle(VFIOUserProxy *proxy, VFIOUserMsg *msg);
static void vfio_user_recv(void *opaque);
static int vfio_user_recv_one(VFIOUserProxy *proxy);
+static void vfio_user_send(void *opaque);
+static int vfio_user_send_one(VFIOUserProxy *proxy);
static void vfio_user_cb(void *opaque);
static void vfio_user_request(void *opaque);
+static int vfio_user_send_queued(VFIOUserProxy *proxy, VFIOUserMsg *msg);
+static void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
+ VFIOUserFDs *fds, int rsize);
+static void vfio_user_request_msg(VFIOUserHdr *hdr, uint16_t cmd,
+ uint32_t size, uint32_t flags);
static inline void vfio_user_set_error(VFIOUserHdr *hdr, uint32_t err)
{
@@ -52,6 +64,35 @@ static void vfio_user_shutdown(VFIOUserProxy *proxy)
proxy->ctx, NULL, NULL);
}
+static int vfio_user_send_qio(VFIOUserProxy *proxy, VFIOUserMsg *msg)
+{
+ VFIOUserFDs *fds = msg->fds;
+ struct iovec iov = {
+ .iov_base = msg->hdr,
+ .iov_len = msg->hdr->size,
+ };
+ size_t numfds = 0;
+ int ret, *fdp = NULL;
+ Error *local_err = NULL;
+
+ if (fds != NULL && fds->send_fds != 0) {
+ numfds = fds->send_fds;
+ fdp = fds->fds;
+ }
+
+ ret = qio_channel_writev_full(proxy->ioc, &iov, 1, fdp, numfds, 0,
+ &local_err);
+
+ if (ret == -1) {
+ vfio_user_set_error(msg->hdr, EIO);
+ vfio_user_shutdown(proxy);
+ error_report_err(local_err);
+ }
+ trace_vfio_user_send_write(msg->hdr->id, ret);
+
+ return ret;
+}
+
static VFIOUserMsg *vfio_user_getmsg(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
VFIOUserFDs *fds)
{
@@ -92,6 +133,7 @@ static void vfio_user_recycle(VFIOUserProxy *proxy, VFIOUserMsg *msg)
msg->hdr = NULL;
msg->fds = NULL;
msg->complete = false;
+ msg->pending = false;
QTAILQ_INSERT_HEAD(&proxy->free, msg, next);
}
@@ -386,6 +428,54 @@ err:
return -1;
}
+/*
+ * Send messages from outgoing queue when the socket buffer has space.
+ * If we deplete 'outgoing', remove ourselves from the poll list.
+ */
+static void vfio_user_send(void *opaque)
+{
+ VFIOUserProxy *proxy = opaque;
+
+ QEMU_LOCK_GUARD(&proxy->lock);
+
+ if (proxy->state == VFIO_PROXY_CONNECTED) {
+ while (!QTAILQ_EMPTY(&proxy->outgoing)) {
+ if (vfio_user_send_one(proxy) < 0) {
+ return;
+ }
+ }
+ qio_channel_set_aio_fd_handler(proxy->ioc, proxy->ctx,
+ vfio_user_recv, NULL, NULL, proxy);
+ }
+}
+
+/*
+ * Send a single message.
+ *
+ * Sent async messages are freed, others are moved to pending queue.
+ */
+static int vfio_user_send_one(VFIOUserProxy *proxy)
+{
+ VFIOUserMsg *msg;
+ int ret;
+
+ msg = QTAILQ_FIRST(&proxy->outgoing);
+ ret = vfio_user_send_qio(proxy, msg);
+ if (ret < 0) {
+ return ret;
+ }
+
+ QTAILQ_REMOVE(&proxy->outgoing, msg, next);
+ if (msg->type == VFIO_MSG_ASYNC) {
+ vfio_user_recycle(proxy, msg);
+ } else {
+ QTAILQ_INSERT_TAIL(&proxy->pending, msg, next);
+ msg->pending = true;
+ }
+
+ return 0;
+}
+
static void vfio_user_cb(void *opaque)
{
VFIOUserProxy *proxy = opaque;
@@ -447,6 +537,119 @@ static void vfio_user_request(void *opaque)
}
}
+/*
+ * Messages are queued onto the proxy's outgoing list.
+ *
+ * It handles 3 types of messages:
+ *
+ * async messages - replies and posted writes
+ *
+ * There will be no reply from the server, so message
+ * buffers are freed after they're sent.
+ *
+ * nowait messages - map/unmap during address space transactions
+ *
+ * These are also sent async, but a reply is expected so that
+ * vfio_wait_reqs() can wait for the youngest nowait request.
+ * They transition from the outgoing list to the pending list
+ * when sent, and are freed when the reply is received.
+ *
+ * wait messages - all other requests
+ *
+ * The reply to these messages is waited for by their caller.
+ * They also transition from outgoing to pending when sent, but
+ * the message buffer is returned to the caller with the reply
+ * contents. The caller is responsible for freeing these messages.
+ *
+ * As an optimization, if the outgoing list and the socket send
+ * buffer are empty, the message is sent inline instead of being
+ * added to the outgoing list. The rest of the transitions are
+ * unchanged.
+ *
+ * returns 0 if the message was sent or queued
+ * returns -1 on send error
+ */
+static int vfio_user_send_queued(VFIOUserProxy *proxy, VFIOUserMsg *msg)
+{
+ int ret;
+
+ /*
+ * Unsent outgoing msgs - add to tail
+ */
+ if (!QTAILQ_EMPTY(&proxy->outgoing)) {
+ QTAILQ_INSERT_TAIL(&proxy->outgoing, msg, next);
+ return 0;
+ }
+
+ /*
+ * Try inline - if blocked, queue it and kick send poller
+ */
+ if (proxy->flags & VFIO_PROXY_FORCE_QUEUED) {
+ ret = QIO_CHANNEL_ERR_BLOCK;
+ } else {
+ ret = vfio_user_send_qio(proxy, msg);
+ }
+ if (ret == QIO_CHANNEL_ERR_BLOCK) {
+ QTAILQ_INSERT_HEAD(&proxy->outgoing, msg, next);
+ qio_channel_set_aio_fd_handler(proxy->ioc, proxy->ctx,
+ vfio_user_recv, proxy->ctx,
+ vfio_user_send, proxy);
+ return 0;
+ }
+ if (ret == -1) {
+ return ret;
+ }
+
+ /*
+ * Sent - free async, add others to pending
+ */
+ if (msg->type == VFIO_MSG_ASYNC) {
+ vfio_user_recycle(proxy, msg);
+ } else {
+ QTAILQ_INSERT_TAIL(&proxy->pending, msg, next);
+ msg->pending = true;
+ }
+
+ return 0;
+}
+
+static void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
+ VFIOUserFDs *fds, int rsize)
+{
+ VFIOUserMsg *msg;
+ int ret;
+
+ if (hdr->flags & VFIO_USER_NO_REPLY) {
+ error_printf("vfio_user_send_wait on async message\n");
+ vfio_user_set_error(hdr, EINVAL);
+ return;
+ }
+
+ qemu_mutex_lock(&proxy->lock);
+
+ msg = vfio_user_getmsg(proxy, hdr, fds);
+ msg->id = hdr->id;
+ msg->rsize = rsize ? rsize : hdr->size;
+ msg->type = VFIO_MSG_WAIT;
+
+ ret = vfio_user_send_queued(proxy, msg);
+
+ if (ret == 0) {
+ while (!msg->complete) {
+ if (!qemu_cond_timedwait(&msg->cv, &proxy->lock, wait_time)) {
+ VFIOUserMsgQ *list;
+
+ list = msg->pending ? &proxy->pending : &proxy->outgoing;
+ QTAILQ_REMOVE(list, msg, next);
+ vfio_user_set_error(hdr, ETIMEDOUT);
+ break;
+ }
+ }
+ }
+ vfio_user_recycle(proxy, msg);
+
+ qemu_mutex_unlock(&proxy->lock);
+}
static QLIST_HEAD(, VFIOUserProxy) vfio_user_sockets =
QLIST_HEAD_INITIALIZER(vfio_user_sockets);
@@ -475,6 +678,15 @@ VFIOUserProxy *vfio_user_connect_dev(SocketAddress *addr, Error **errp)
proxy = g_malloc0(sizeof(VFIOUserProxy));
proxy->sockname = g_strdup_printf("unix:%s", sockname);
proxy->ioc = ioc;
+
+ /* init defaults */
+ proxy->max_xfer_size = VFIO_USER_DEF_MAX_XFER;
+ proxy->max_send_fds = VFIO_USER_DEF_MAX_FDS;
+ proxy->max_dma = VFIO_USER_DEF_MAP_MAX;
+ proxy->dma_pgsizes = VFIO_USER_DEF_PGSIZE;
+ proxy->max_bitmap = VFIO_USER_DEF_MAX_BITMAP;
+ proxy->migr_pgsize = VFIO_USER_DEF_PGSIZE;
+
proxy->flags = VFIO_PROXY_CLIENT;
proxy->state = VFIO_PROXY_CONNECTED;
@@ -572,3 +784,285 @@ void vfio_user_disconnect(VFIOUserProxy *proxy)
g_free(proxy->sockname);
g_free(proxy);
}
+
+static void vfio_user_request_msg(VFIOUserHdr *hdr, uint16_t cmd,
+ uint32_t size, uint32_t flags)
+{
+ static uint16_t next_id;
+
+ hdr->id = qatomic_fetch_inc(&next_id);
+ hdr->command = cmd;
+ hdr->size = size;
+ hdr->flags = (flags & ~VFIO_USER_TYPE) | VFIO_USER_REQUEST;
+ hdr->error_reply = 0;
+}
+
+struct cap_entry {
+ const char *name;
+ bool (*check)(VFIOUserProxy *proxy, QObject *qobj, Error **errp);
+};
+
+static bool caps_parse(VFIOUserProxy *proxy, QDict *qdict,
+ struct cap_entry caps[], Error **errp)
+{
+ QObject *qobj;
+ struct cap_entry *p;
+
+ for (p = caps; p->name != NULL; p++) {
+ qobj = qdict_get(qdict, p->name);
+ if (qobj != NULL) {
+ if (!p->check(proxy, qobj, errp)) {
+ return false;
+ }
+ qdict_del(qdict, p->name);
+ }
+ }
+
+ /* warning, for now */
+ if (qdict_size(qdict) != 0) {
+ warn_report("spurious capabilities");
+ }
+ return true;
+}
+
+static bool check_migr_pgsize(VFIOUserProxy *proxy, QObject *qobj, Error **errp)
+{
+ QNum *qn = qobject_to(QNum, qobj);
+ uint64_t pgsize;
+
+ if (qn == NULL || !qnum_get_try_uint(qn, &pgsize)) {
+ error_setg(errp, "malformed %s", VFIO_USER_CAP_PGSIZE);
+ return false;
+ }
+
+ /* must be larger than default */
+ if (pgsize & (VFIO_USER_DEF_PGSIZE - 1)) {
+ error_setg(errp, "pgsize 0x%"PRIx64" too small", pgsize);
+ return false;
+ }
+
+ proxy->migr_pgsize = pgsize;
+ return true;
+}
+
+static bool check_bitmap(VFIOUserProxy *proxy, QObject *qobj, Error **errp)
+{
+ QNum *qn = qobject_to(QNum, qobj);
+ uint64_t bitmap_size;
+
+ if (qn == NULL || !qnum_get_try_uint(qn, &bitmap_size)) {
+ error_setg(errp, "malformed %s", VFIO_USER_CAP_MAX_BITMAP);
+ return false;
+ }
+
+ /* can only lower it */
+ if (bitmap_size > VFIO_USER_DEF_MAX_BITMAP) {
+ error_setg(errp, "%s too large", VFIO_USER_CAP_MAX_BITMAP);
+ return false;
+ }
+
+ proxy->max_bitmap = bitmap_size;
+ return true;
+}
+
+static struct cap_entry caps_migr[] = {
+ { VFIO_USER_CAP_PGSIZE, check_migr_pgsize },
+ { VFIO_USER_CAP_MAX_BITMAP, check_bitmap },
+ { NULL }
+};
+
+static bool check_max_fds(VFIOUserProxy *proxy, QObject *qobj, Error **errp)
+{
+ QNum *qn = qobject_to(QNum, qobj);
+ uint64_t max_send_fds;
+
+ if (qn == NULL || !qnum_get_try_uint(qn, &max_send_fds) ||
+ max_send_fds > VFIO_USER_MAX_MAX_FDS) {
+ error_setg(errp, "malformed %s", VFIO_USER_CAP_MAX_FDS);
+ return false;
+ }
+ proxy->max_send_fds = max_send_fds;
+ return true;
+}
+
+static bool check_max_xfer(VFIOUserProxy *proxy, QObject *qobj, Error **errp)
+{
+ QNum *qn = qobject_to(QNum, qobj);
+ uint64_t max_xfer_size;
+
+ if (qn == NULL || !qnum_get_try_uint(qn, &max_xfer_size) ||
+ max_xfer_size > VFIO_USER_MAX_MAX_XFER) {
+ error_setg(errp, "malformed %s", VFIO_USER_CAP_MAX_XFER);
+ return false;
+ }
+ proxy->max_xfer_size = max_xfer_size;
+ return true;
+}
+
+static bool check_pgsizes(VFIOUserProxy *proxy, QObject *qobj, Error **errp)
+{
+ QNum *qn = qobject_to(QNum, qobj);
+ uint64_t pgsizes;
+
+ if (qn == NULL || !qnum_get_try_uint(qn, &pgsizes)) {
+ error_setg(errp, "malformed %s", VFIO_USER_CAP_PGSIZES);
+ return false;
+ }
+
+ /* must be larger than default */
+ if (pgsizes & (VFIO_USER_DEF_PGSIZE - 1)) {
+ error_setg(errp, "pgsize 0x%"PRIx64" too small", pgsizes);
+ return false;
+ }
+
+ proxy->dma_pgsizes = pgsizes;
+ return true;
+}
+
+static bool check_max_dma(VFIOUserProxy *proxy, QObject *qobj, Error **errp)
+{
+ QNum *qn = qobject_to(QNum, qobj);
+ uint64_t max_dma;
+
+ if (qn == NULL || !qnum_get_try_uint(qn, &max_dma)) {
+ error_setg(errp, "malformed %s", VFIO_USER_CAP_MAP_MAX);
+ return false;
+ }
+
+ /* can only lower it */
+ if (max_dma > VFIO_USER_DEF_MAP_MAX) {
+ error_setg(errp, "%s too large", VFIO_USER_CAP_MAP_MAX);
+ return false;
+ }
+
+ proxy->max_dma = max_dma;
+ return true;
+}
+
+static bool check_migr(VFIOUserProxy *proxy, QObject *qobj, Error **errp)
+{
+ QDict *qdict = qobject_to(QDict, qobj);
+
+ if (qdict == NULL) {
+ error_setg(errp, "malformed %s", VFIO_USER_CAP_MAX_FDS);
+ return true;
+ }
+ return caps_parse(proxy, qdict, caps_migr, errp);
+}
+
+static struct cap_entry caps_cap[] = {
+ { VFIO_USER_CAP_MAX_FDS, check_max_fds },
+ { VFIO_USER_CAP_MAX_XFER, check_max_xfer },
+ { VFIO_USER_CAP_PGSIZES, check_pgsizes },
+ { VFIO_USER_CAP_MAP_MAX, check_max_dma },
+ { VFIO_USER_CAP_MIGR, check_migr },
+ { NULL }
+};
+
+static bool check_cap(VFIOUserProxy *proxy, QObject *qobj, Error **errp)
+{
+ QDict *qdict = qobject_to(QDict, qobj);
+
+ if (qdict == NULL) {
+ error_setg(errp, "malformed %s", VFIO_USER_CAP);
+ return false;
+ }
+ return caps_parse(proxy, qdict, caps_cap, errp);
+}
+
+static struct cap_entry ver_0_0[] = {
+ { VFIO_USER_CAP, check_cap },
+ { NULL }
+};
+
+static bool caps_check(VFIOUserProxy *proxy, int minor, const char *caps,
+ Error **errp)
+{
+ QObject *qobj;
+ QDict *qdict;
+ bool ret;
+
+ qobj = qobject_from_json(caps, NULL);
+ if (qobj == NULL) {
+ error_setg(errp, "malformed capabilities %s", caps);
+ return false;
+ }
+ qdict = qobject_to(QDict, qobj);
+ if (qdict == NULL) {
+ error_setg(errp, "capabilities %s not an object", caps);
+ qobject_unref(qobj);
+ return false;
+ }
+ ret = caps_parse(proxy, qdict, ver_0_0, errp);
+
+ qobject_unref(qobj);
+ return ret;
+}
+
+static GString *caps_json(void)
+{
+ QDict *dict = qdict_new();
+ QDict *capdict = qdict_new();
+ QDict *migdict = qdict_new();
+ GString *str;
+
+ qdict_put_int(migdict, VFIO_USER_CAP_PGSIZE, VFIO_USER_DEF_PGSIZE);
+ qdict_put_int(migdict, VFIO_USER_CAP_MAX_BITMAP, VFIO_USER_DEF_MAX_BITMAP);
+ qdict_put_obj(capdict, VFIO_USER_CAP_MIGR, QOBJECT(migdict));
+
+ qdict_put_int(capdict, VFIO_USER_CAP_MAX_FDS, VFIO_USER_MAX_MAX_FDS);
+ qdict_put_int(capdict, VFIO_USER_CAP_MAX_XFER, VFIO_USER_DEF_MAX_XFER);
+ qdict_put_int(capdict, VFIO_USER_CAP_PGSIZES, VFIO_USER_DEF_PGSIZE);
+ qdict_put_int(capdict, VFIO_USER_CAP_MAP_MAX, VFIO_USER_DEF_MAP_MAX);
+
+ qdict_put_obj(dict, VFIO_USER_CAP, QOBJECT(capdict));
+
+ str = qobject_to_json(QOBJECT(dict));
+ qobject_unref(dict);
+ return str;
+}
+
+bool vfio_user_validate_version(VFIOUserProxy *proxy, Error **errp)
+{
+ g_autofree VFIOUserVersion *msgp = NULL;
+ GString *caps;
+ char *reply;
+ int size, caplen;
+
+ caps = caps_json();
+ caplen = caps->len + 1;
+ size = sizeof(*msgp) + caplen;
+ msgp = g_malloc0(size);
+
+ vfio_user_request_msg(&msgp->hdr, VFIO_USER_VERSION, size, 0);
+ msgp->major = VFIO_USER_MAJOR_VER;
+ msgp->minor = VFIO_USER_MINOR_VER;
+ memcpy(&msgp->capabilities, caps->str, caplen);
+ g_string_free(caps, true);
+ trace_vfio_user_version(msgp->major, msgp->minor, msgp->capabilities);
+
+ vfio_user_send_wait(proxy, &msgp->hdr, NULL, 0);
+ if (msgp->hdr.flags & VFIO_USER_ERROR) {
+ error_setg_errno(errp, msgp->hdr.error_reply, "version reply");
+ return false;
+ }
+
+ if (msgp->major != VFIO_USER_MAJOR_VER ||
+ msgp->minor > VFIO_USER_MINOR_VER) {
+ error_setg(errp, "incompatible server version");
+ return false;
+ }
+
+ reply = msgp->capabilities;
+ if (reply[msgp->hdr.size - sizeof(*msgp) - 1] != '\0') {
+ error_setg(errp, "corrupt version reply");
+ return false;
+ }
+
+ if (!caps_check(proxy, msgp->minor, reply, errp)) {
+ return false;
+ }
+
+ trace_vfio_user_version(msgp->major, msgp->minor, msgp->capabilities);
+ return true;
+}
diff --git a/hw/vfio-user/trace-events b/hw/vfio-user/trace-events
index 89d6c11c4c..7a3645024f 100644
--- a/hw/vfio-user/trace-events
+++ b/hw/vfio-user/trace-events
@@ -4,3 +4,5 @@
vfio_user_recv_hdr(const char *name, uint16_t id, uint16_t cmd, uint32_t size, uint32_t flags) " (%s) id 0x%x cmd 0x%x size 0x%x flags 0x%x"
vfio_user_recv_read(uint16_t id, int read) " id 0x%x read 0x%x"
vfio_user_recv_request(uint16_t cmd) " command 0x%x"
+vfio_user_send_write(uint16_t id, int wrote) " id 0x%x wrote 0x%x"
+vfio_user_version(uint16_t major, uint16_t minor, const char *caps) " major %d minor %d caps: %s"
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 10/23] vfio-user: implement VFIO_USER_DEVICE_GET_INFO
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (8 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 09/23] vfio-user: implement message send infrastructure John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-07 0:10 ` [PATCH v3 11/23] vfio-user: implement VFIO_USER_DEVICE_GET_REGION_INFO John Levon
` (13 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
Add support for getting basic device information.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/device.h | 23 ++++++++++++++++++
hw/vfio-user/protocol.h | 12 ++++++++++
hw/vfio-user/proxy.h | 7 ++++++
hw/vfio-user/container.c | 10 +++++++-
hw/vfio-user/device.c | 50 +++++++++++++++++++++++++++++++++++++++
hw/vfio-user/proxy.c | 12 ++++------
hw/vfio-user/meson.build | 1 +
hw/vfio-user/trace-events | 1 +
8 files changed, 107 insertions(+), 9 deletions(-)
create mode 100644 hw/vfio-user/device.h
create mode 100644 hw/vfio-user/device.c
diff --git a/hw/vfio-user/device.h b/hw/vfio-user/device.h
new file mode 100644
index 0000000000..f27f26b479
--- /dev/null
+++ b/hw/vfio-user/device.h
@@ -0,0 +1,23 @@
+#ifndef VFIO_USER_DEVICE_H
+#define VFIO_USER_DEVICE_H
+
+/*
+ * vfio protocol over a UNIX socket device handling.
+ *
+ * Copyright © 2018, 2021 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "linux/vfio.h"
+
+#include "hw/vfio-user/proxy.h"
+
+int vfio_user_get_device_info(VFIOUserProxy *proxy,
+ struct vfio_device_info *info);
+
+#endif /* VFIO_USER_DEVICE_H */
diff --git a/hw/vfio-user/protocol.h b/hw/vfio-user/protocol.h
index 74ea2a94e6..648badff46 100644
--- a/hw/vfio-user/protocol.h
+++ b/hw/vfio-user/protocol.h
@@ -115,4 +115,16 @@ typedef struct {
*/
#define VFIO_USER_DEF_MAX_BITMAP (256 * 1024 * 1024)
+/*
+ * VFIO_USER_DEVICE_GET_INFO
+ * imported from struct vfio_device_info
+ */
+typedef struct {
+ VFIOUserHdr hdr;
+ uint32_t argsz;
+ uint32_t flags;
+ uint32_t num_regions;
+ uint32_t num_irqs;
+} VFIOUserDeviceInfo;
+
#endif /* VFIO_USER_PROTOCOL_H */
diff --git a/hw/vfio-user/proxy.h b/hw/vfio-user/proxy.h
index 33e8a4d83b..9c6b2cdf35 100644
--- a/hw/vfio-user/proxy.h
+++ b/hw/vfio-user/proxy.h
@@ -15,7 +15,9 @@
#include "io/channel.h"
#include "io/channel-socket.h"
+#include "qemu/queue.h"
#include "qemu/sockets.h"
+#include "qemu/thread.h"
#include "hw/vfio-user/protocol.h"
typedef struct {
@@ -99,4 +101,9 @@ void vfio_user_set_handler(VFIODevice *vbasedev,
void *reqarg);
bool vfio_user_validate_version(VFIOUserProxy *proxy, Error **errp);
+void vfio_user_request_msg(VFIOUserHdr *hdr, uint16_t cmd,
+ uint32_t size, uint32_t flags);
+void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
+ VFIOUserFDs *fds, int rsize);
+
#endif /* VFIO_USER_PROXY_H */
diff --git a/hw/vfio-user/container.c b/hw/vfio-user/container.c
index 2892845b4f..6f0eb86a75 100644
--- a/hw/vfio-user/container.c
+++ b/hw/vfio-user/container.c
@@ -14,6 +14,7 @@
#include "qemu/osdep.h"
#include "hw/vfio-user/container.h"
+#include "hw/vfio-user/device.h"
#include "hw/vfio/vfio-cpr.h"
#include "hw/vfio/vfio-device.h"
#include "hw/vfio/vfio-listener.h"
@@ -144,7 +145,14 @@ static void vfio_user_container_disconnect(VFIOUserContainer *container)
static bool vfio_user_device_get(VFIOUserContainer *container,
VFIODevice *vbasedev, Error **errp)
{
- struct vfio_device_info info = { 0 };
+ struct vfio_device_info info = { .argsz = sizeof(info) };
+ int ret;
+
+ ret = vfio_user_get_device_info(vbasedev->proxy, &info);
+ if (ret) {
+ error_setg_errno(errp, -ret, "get info failure");
+ return ret;
+ }
vbasedev->fd = -1;
diff --git a/hw/vfio-user/device.c b/hw/vfio-user/device.c
new file mode 100644
index 0000000000..e081033ff1
--- /dev/null
+++ b/hw/vfio-user/device.c
@@ -0,0 +1,50 @@
+/*
+ * vfio protocol over a UNIX socket device handling.
+ *
+ * Copyright © 2018, 2021 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+
+#include "hw/vfio-user/device.h"
+#include "hw/vfio-user/trace.h"
+
+/*
+ * These are to defend against a malign server trying
+ * to force us to run out of memory.
+ */
+#define VFIO_USER_MAX_REGIONS 100
+#define VFIO_USER_MAX_IRQS 50
+
+int vfio_user_get_device_info(VFIOUserProxy *proxy,
+ struct vfio_device_info *info)
+{
+ VFIOUserDeviceInfo msg;
+ uint32_t argsz = sizeof(msg) - sizeof(msg.hdr);
+
+ memset(&msg, 0, sizeof(msg));
+ vfio_user_request_msg(&msg.hdr, VFIO_USER_DEVICE_GET_INFO, sizeof(msg), 0);
+ msg.argsz = argsz;
+
+ vfio_user_send_wait(proxy, &msg.hdr, NULL, 0);
+ if (msg.hdr.flags & VFIO_USER_ERROR) {
+ return -msg.hdr.error_reply;
+ }
+ trace_vfio_user_get_info(msg.num_regions, msg.num_irqs);
+
+ memcpy(info, &msg.argsz, argsz);
+
+ /* defend against a malicious server */
+ if (info->num_regions > VFIO_USER_MAX_REGIONS ||
+ info->num_irqs > VFIO_USER_MAX_IRQS) {
+ error_printf("%s: invalid reply\n", __func__);
+ return -EINVAL;
+ }
+
+ return 0;
+}
diff --git a/hw/vfio-user/proxy.c b/hw/vfio-user/proxy.c
index 0bc12da865..34df9bba7b 100644
--- a/hw/vfio-user/proxy.c
+++ b/hw/vfio-user/proxy.c
@@ -42,10 +42,6 @@ static void vfio_user_cb(void *opaque);
static void vfio_user_request(void *opaque);
static int vfio_user_send_queued(VFIOUserProxy *proxy, VFIOUserMsg *msg);
-static void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
- VFIOUserFDs *fds, int rsize);
-static void vfio_user_request_msg(VFIOUserHdr *hdr, uint16_t cmd,
- uint32_t size, uint32_t flags);
static inline void vfio_user_set_error(VFIOUserHdr *hdr, uint32_t err)
{
@@ -613,8 +609,8 @@ static int vfio_user_send_queued(VFIOUserProxy *proxy, VFIOUserMsg *msg)
return 0;
}
-static void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
- VFIOUserFDs *fds, int rsize)
+void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
+ VFIOUserFDs *fds, int rsize)
{
VFIOUserMsg *msg;
int ret;
@@ -785,8 +781,8 @@ void vfio_user_disconnect(VFIOUserProxy *proxy)
g_free(proxy);
}
-static void vfio_user_request_msg(VFIOUserHdr *hdr, uint16_t cmd,
- uint32_t size, uint32_t flags)
+void vfio_user_request_msg(VFIOUserHdr *hdr, uint16_t cmd,
+ uint32_t size, uint32_t flags)
{
static uint16_t next_id;
diff --git a/hw/vfio-user/meson.build b/hw/vfio-user/meson.build
index 695b341547..19bdee688c 100644
--- a/hw/vfio-user/meson.build
+++ b/hw/vfio-user/meson.build
@@ -1,6 +1,7 @@
vfio_user_ss = ss.source_set()
vfio_user_ss.add(files(
'container.c',
+ 'device.c',
'pci.c',
'proxy.c',
))
diff --git a/hw/vfio-user/trace-events b/hw/vfio-user/trace-events
index 7a3645024f..6b06a3ed82 100644
--- a/hw/vfio-user/trace-events
+++ b/hw/vfio-user/trace-events
@@ -6,3 +6,4 @@ vfio_user_recv_read(uint16_t id, int read) " id 0x%x read 0x%x"
vfio_user_recv_request(uint16_t cmd) " command 0x%x"
vfio_user_send_write(uint16_t id, int wrote) " id 0x%x wrote 0x%x"
vfio_user_version(uint16_t major, uint16_t minor, const char *caps) " major %d minor %d caps: %s"
+vfio_user_get_info(uint32_t nregions, uint32_t nirqs) " #regions %d #irqs %d"
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 11/23] vfio-user: implement VFIO_USER_DEVICE_GET_REGION_INFO
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (9 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 10/23] vfio-user: implement VFIO_USER_DEVICE_GET_INFO John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-07 0:10 ` [PATCH v3 12/23] vfio-user: implement VFIO_USER_REGION_READ/WRITE John Levon
` (12 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
Add support for getting region info for vfio-user. As vfio-user has one
fd per region, enable ->use_region_fds.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/device.h | 2 ++
hw/vfio-user/protocol.h | 14 ++++++++
hw/vfio-user/proxy.h | 1 +
hw/vfio-user/device.c | 68 +++++++++++++++++++++++++++++++++++++++
hw/vfio-user/pci.c | 11 +++++++
hw/vfio-user/trace-events | 1 +
6 files changed, 97 insertions(+)
diff --git a/hw/vfio-user/device.h b/hw/vfio-user/device.h
index f27f26b479..a5a2aa9ba6 100644
--- a/hw/vfio-user/device.h
+++ b/hw/vfio-user/device.h
@@ -20,4 +20,6 @@
int vfio_user_get_device_info(VFIOUserProxy *proxy,
struct vfio_device_info *info);
+extern VFIODeviceIOOps vfio_user_device_io_ops_sock;
+
#endif /* VFIO_USER_DEVICE_H */
diff --git a/hw/vfio-user/protocol.h b/hw/vfio-user/protocol.h
index 648badff46..1878d44c51 100644
--- a/hw/vfio-user/protocol.h
+++ b/hw/vfio-user/protocol.h
@@ -127,4 +127,18 @@ typedef struct {
uint32_t num_irqs;
} VFIOUserDeviceInfo;
+/*
+ * VFIO_USER_DEVICE_GET_REGION_INFO
+ * imported from struct vfio_region_info
+ */
+typedef struct {
+ VFIOUserHdr hdr;
+ uint32_t argsz;
+ uint32_t flags;
+ uint32_t index;
+ uint32_t cap_offset;
+ uint64_t size;
+ uint64_t offset;
+} VFIOUserRegionInfo;
+
#endif /* VFIO_USER_PROTOCOL_H */
diff --git a/hw/vfio-user/proxy.h b/hw/vfio-user/proxy.h
index 9c6b2cdf35..e2cfaeead8 100644
--- a/hw/vfio-user/proxy.h
+++ b/hw/vfio-user/proxy.h
@@ -18,6 +18,7 @@
#include "qemu/queue.h"
#include "qemu/sockets.h"
#include "qemu/thread.h"
+#include "hw/vfio/vfio-device.h"
#include "hw/vfio-user/protocol.h"
typedef struct {
diff --git a/hw/vfio-user/device.c b/hw/vfio-user/device.c
index e081033ff1..57793e6b2b 100644
--- a/hw/vfio-user/device.c
+++ b/hw/vfio-user/device.c
@@ -48,3 +48,71 @@ int vfio_user_get_device_info(VFIOUserProxy *proxy,
return 0;
}
+
+static int vfio_user_get_region_info(VFIOUserProxy *proxy,
+ struct vfio_region_info *info,
+ VFIOUserFDs *fds)
+{
+ g_autofree VFIOUserRegionInfo *msgp = NULL;
+ uint32_t size;
+
+ /* data returned can be larger than vfio_region_info */
+ if (info->argsz < sizeof(*info)) {
+ error_printf("vfio_user_get_region_info argsz too small\n");
+ return -E2BIG;
+ }
+ if (fds != NULL && fds->send_fds != 0) {
+ error_printf("vfio_user_get_region_info can't send FDs\n");
+ return -EINVAL;
+ }
+
+ size = info->argsz + sizeof(VFIOUserHdr);
+ msgp = g_malloc0(size);
+
+ vfio_user_request_msg(&msgp->hdr, VFIO_USER_DEVICE_GET_REGION_INFO,
+ sizeof(*msgp), 0);
+ msgp->argsz = info->argsz;
+ msgp->index = info->index;
+
+ vfio_user_send_wait(proxy, &msgp->hdr, fds, size);
+ if (msgp->hdr.flags & VFIO_USER_ERROR) {
+ return -msgp->hdr.error_reply;
+ }
+ trace_vfio_user_get_region_info(msgp->index, msgp->flags, msgp->size);
+
+ memcpy(info, &msgp->argsz, info->argsz);
+ return 0;
+}
+
+
+static int vfio_user_device_io_get_region_info(VFIODevice *vbasedev,
+ struct vfio_region_info *info,
+ int *fd)
+{
+ VFIOUserFDs fds = { 0, 1, fd};
+ int ret;
+
+ if (info->index > vbasedev->num_regions) {
+ return -EINVAL;
+ }
+
+ ret = vfio_user_get_region_info(vbasedev->proxy, info, &fds);
+ if (ret) {
+ return ret;
+ }
+
+ /* cap_offset in valid area */
+ if ((info->flags & VFIO_REGION_INFO_FLAG_CAPS) &&
+ (info->cap_offset < sizeof(*info) || info->cap_offset > info->argsz)) {
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/*
+ * Socket-based io_ops
+ */
+VFIODeviceIOOps vfio_user_device_io_ops_sock = {
+ .get_region_info = vfio_user_device_io_get_region_info,
+};
diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
index bcef0ea341..c2e7283489 100644
--- a/hw/vfio-user/pci.c
+++ b/hw/vfio-user/pci.c
@@ -14,6 +14,7 @@
#include "hw/qdev-properties.h"
#include "hw/vfio/pci.h"
+#include "hw/vfio-user/device.h"
#include "hw/vfio-user/proxy.h"
#define TYPE_VFIO_USER_PCI "vfio-user-pci"
@@ -101,11 +102,21 @@ static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
vbasedev->name = g_strdup_printf("VFIO user <%s>", udev->sock_name);
+ /*
+ * Use socket-based device I/O instead of vfio kernel driver.
+ */
+ vbasedev->io_ops = &vfio_user_device_io_ops_sock;
+
/*
* vfio-user devices are effectively mdevs (don't use a host iommu).
*/
vbasedev->mdev = true;
+ /*
+ * Enable per-region fds.
+ */
+ vbasedev->use_region_fds = true;
+
as = pci_device_iommu_address_space(pdev);
if (!vfio_device_attach_by_iommu_type(TYPE_VFIO_IOMMU_USER,
vbasedev->name, vbasedev,
diff --git a/hw/vfio-user/trace-events b/hw/vfio-user/trace-events
index 6b06a3ed82..1860430301 100644
--- a/hw/vfio-user/trace-events
+++ b/hw/vfio-user/trace-events
@@ -7,3 +7,4 @@ vfio_user_recv_request(uint16_t cmd) " command 0x%x"
vfio_user_send_write(uint16_t id, int wrote) " id 0x%x wrote 0x%x"
vfio_user_version(uint16_t major, uint16_t minor, const char *caps) " major %d minor %d caps: %s"
vfio_user_get_info(uint32_t nregions, uint32_t nirqs) " #regions %d #irqs %d"
+vfio_user_get_region_info(uint32_t index, uint32_t flags, uint64_t size) " index %d flags 0x%x size 0x%"PRIx64
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 12/23] vfio-user: implement VFIO_USER_REGION_READ/WRITE
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (10 preceding siblings ...)
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 ` John Levon
2025-06-07 0:10 ` [PATCH v3 13/23] vfio-user: set up PCI in vfio_user_pci_realize() John Levon
` (11 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/protocol.h | 12 +++++++
hw/vfio-user/device.c | 67 +++++++++++++++++++++++++++++++++++++++
hw/vfio-user/trace-events | 1 +
3 files changed, 80 insertions(+)
diff --git a/hw/vfio-user/protocol.h b/hw/vfio-user/protocol.h
index 1878d44c51..8e6ccbe9e8 100644
--- a/hw/vfio-user/protocol.h
+++ b/hw/vfio-user/protocol.h
@@ -141,4 +141,16 @@ typedef struct {
uint64_t offset;
} VFIOUserRegionInfo;
+/*
+ * VFIO_USER_REGION_READ
+ * VFIO_USER_REGION_WRITE
+ */
+typedef struct {
+ VFIOUserHdr hdr;
+ uint64_t offset;
+ uint32_t region;
+ uint32_t count;
+ char data[];
+} VFIOUserRegionRW;
+
#endif /* VFIO_USER_PROTOCOL_H */
diff --git a/hw/vfio-user/device.c b/hw/vfio-user/device.c
index 57793e6b2b..a767e4fb01 100644
--- a/hw/vfio-user/device.c
+++ b/hw/vfio-user/device.c
@@ -110,9 +110,76 @@ static int vfio_user_device_io_get_region_info(VFIODevice *vbasedev,
return 0;
}
+static int vfio_user_device_io_region_read(VFIODevice *vbasedev, uint8_t index,
+ off_t off, uint32_t count,
+ void *data)
+{
+ g_autofree VFIOUserRegionRW *msgp = NULL;
+ VFIOUserProxy *proxy = vbasedev->proxy;
+ int size = sizeof(*msgp) + count;
+
+ if (count > proxy->max_xfer_size) {
+ return -EINVAL;
+ }
+
+ msgp = g_malloc0(size);
+ vfio_user_request_msg(&msgp->hdr, VFIO_USER_REGION_READ, sizeof(*msgp), 0);
+ msgp->offset = off;
+ msgp->region = index;
+ msgp->count = count;
+ trace_vfio_user_region_rw(msgp->region, msgp->offset, msgp->count);
+
+ vfio_user_send_wait(proxy, &msgp->hdr, NULL, size);
+ if (msgp->hdr.flags & VFIO_USER_ERROR) {
+ return -msgp->hdr.error_reply;
+ } else if (msgp->count > count) {
+ return -E2BIG;
+ } else {
+ memcpy(data, &msgp->data, msgp->count);
+ }
+
+ return msgp->count;
+}
+
+static int vfio_user_device_io_region_write(VFIODevice *vbasedev, uint8_t index,
+ off_t off, unsigned count,
+ void *data, bool post)
+{
+ VFIOUserRegionRW *msgp = NULL;
+ VFIOUserProxy *proxy = vbasedev->proxy;
+ int size = sizeof(*msgp) + count;
+ int ret;
+
+ if (count > proxy->max_xfer_size) {
+ return -EINVAL;
+ }
+
+ msgp = g_malloc0(size);
+ vfio_user_request_msg(&msgp->hdr, VFIO_USER_REGION_WRITE, size, 0);
+ msgp->offset = off;
+ msgp->region = index;
+ msgp->count = count;
+ memcpy(&msgp->data, data, count);
+ trace_vfio_user_region_rw(msgp->region, msgp->offset, msgp->count);
+
+ /* Ignore post: all writes are synchronous/non-posted. */
+ vfio_user_send_wait(proxy, &msgp->hdr, NULL, 0);
+ if (msgp->hdr.flags & VFIO_USER_ERROR) {
+ ret = -msgp->hdr.error_reply;
+ } else {
+ ret = count;
+ }
+
+ g_free(msgp);
+ return ret;
+}
+
/*
* Socket-based io_ops
*/
VFIODeviceIOOps vfio_user_device_io_ops_sock = {
.get_region_info = vfio_user_device_io_get_region_info,
+ .region_read = vfio_user_device_io_region_read,
+ .region_write = vfio_user_device_io_region_write,
+
};
diff --git a/hw/vfio-user/trace-events b/hw/vfio-user/trace-events
index 1860430301..3f5aebe7ac 100644
--- a/hw/vfio-user/trace-events
+++ b/hw/vfio-user/trace-events
@@ -8,3 +8,4 @@ vfio_user_send_write(uint16_t id, int wrote) " id 0x%x wrote 0x%x"
vfio_user_version(uint16_t major, uint16_t minor, const char *caps) " major %d minor %d caps: %s"
vfio_user_get_info(uint32_t nregions, uint32_t nirqs) " #regions %d #irqs %d"
vfio_user_get_region_info(uint32_t index, uint32_t flags, uint64_t size) " index %d flags 0x%x size 0x%"PRIx64
+vfio_user_region_rw(uint32_t region, uint64_t off, uint32_t count) " region %d offset 0x%"PRIx64" count %d"
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 13/23] vfio-user: set up PCI in vfio_user_pci_realize()
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (11 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 12/23] vfio-user: implement VFIO_USER_REGION_READ/WRITE John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-07 0:10 ` [PATCH v3 14/23] vfio-user: implement VFIO_USER_DEVICE_GET/SET_IRQ* John Levon
` (10 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
Re-use PCI setup functions from hw/vfio/pci.c to realize the vfio-user
PCI device.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/pci.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
index c2e7283489..5ac3fb087f 100644
--- a/hw/vfio-user/pci.c
+++ b/hw/vfio-user/pci.c
@@ -124,10 +124,39 @@ static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
goto error;
}
+ if (!vfio_pci_populate_device(vdev, errp)) {
+ goto error;
+ }
+
+ if (!vfio_pci_config_setup(vdev, errp)) {
+ goto error;
+ }
+
+ /*
+ * vfio_pci_config_setup will have registered the device's BARs
+ * and setup any MSIX BARs, so errors after it succeeds must
+ * use out_teardown
+ */
+
+ if (!vfio_pci_add_capabilities(vdev, errp)) {
+ goto out_teardown;
+ }
+
+ if (!vfio_pci_interrupt_setup(vdev, errp)) {
+ goto out_teardown;
+ }
+
+ vfio_pci_register_err_notifier(vdev);
+ vfio_pci_register_req_notifier(vdev);
+
return;
+out_teardown:
+ vfio_pci_teardown_msi(vdev);
+ vfio_pci_bars_exit(vdev);
error:
error_prepend(errp, VFIO_MSG_PREFIX, vdev->vbasedev.name);
+ vfio_pci_put_device(vdev);
}
static void vfio_user_instance_init(Object *obj)
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 14/23] vfio-user: implement VFIO_USER_DEVICE_GET/SET_IRQ*
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (12 preceding siblings ...)
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 ` John Levon
2025-06-07 0:10 ` [PATCH v3 15/23] vfio-user: forward MSI-X PBA BAR accesses to server John Levon
` (9 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
IRQ setup uses the same semantics as the traditional vfio path, but we
need to share the corresponding file descriptors with the server as
necessary.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/protocol.h | 25 ++++++++
hw/vfio-user/device.c | 121 ++++++++++++++++++++++++++++++++++++++
hw/vfio-user/trace-events | 2 +
3 files changed, 148 insertions(+)
diff --git a/hw/vfio-user/protocol.h b/hw/vfio-user/protocol.h
index 8e6ccbe9e8..920b9c44ec 100644
--- a/hw/vfio-user/protocol.h
+++ b/hw/vfio-user/protocol.h
@@ -141,6 +141,31 @@ typedef struct {
uint64_t offset;
} VFIOUserRegionInfo;
+/*
+ * VFIO_USER_DEVICE_GET_IRQ_INFO
+ * imported from struct vfio_irq_info
+ */
+typedef struct {
+ VFIOUserHdr hdr;
+ uint32_t argsz;
+ uint32_t flags;
+ uint32_t index;
+ uint32_t count;
+} VFIOUserIRQInfo;
+
+/*
+ * VFIO_USER_DEVICE_SET_IRQS
+ * imported from struct vfio_irq_set
+ */
+typedef struct {
+ VFIOUserHdr hdr;
+ uint32_t argsz;
+ uint32_t flags;
+ uint32_t index;
+ uint32_t start;
+ uint32_t count;
+} VFIOUserIRQSet;
+
/*
* VFIO_USER_REGION_READ
* VFIO_USER_REGION_WRITE
diff --git a/hw/vfio-user/device.c b/hw/vfio-user/device.c
index a767e4fb01..45b91d22f0 100644
--- a/hw/vfio-user/device.c
+++ b/hw/vfio-user/device.c
@@ -110,6 +110,125 @@ static int vfio_user_device_io_get_region_info(VFIODevice *vbasedev,
return 0;
}
+static int vfio_user_device_io_get_irq_info(VFIODevice *vbasedev,
+ struct vfio_irq_info *info)
+{
+ VFIOUserProxy *proxy = vbasedev->proxy;
+ VFIOUserIRQInfo msg;
+
+ memset(&msg, 0, sizeof(msg));
+ vfio_user_request_msg(&msg.hdr, VFIO_USER_DEVICE_GET_IRQ_INFO,
+ sizeof(msg), 0);
+ msg.argsz = info->argsz;
+ msg.index = info->index;
+
+ vfio_user_send_wait(proxy, &msg.hdr, NULL, 0);
+ if (msg.hdr.flags & VFIO_USER_ERROR) {
+ return -msg.hdr.error_reply;
+ }
+ trace_vfio_user_get_irq_info(msg.index, msg.flags, msg.count);
+
+ memcpy(info, &msg.argsz, sizeof(*info));
+ return 0;
+}
+
+static int irq_howmany(int *fdp, uint32_t cur, uint32_t max)
+{
+ int n = 0;
+
+ if (fdp[cur] != -1) {
+ do {
+ n++;
+ } while (n < max && fdp[cur + n] != -1);
+ } else {
+ do {
+ n++;
+ } while (n < max && fdp[cur + n] == -1);
+ }
+
+ return n;
+}
+
+static int vfio_user_device_io_set_irqs(VFIODevice *vbasedev,
+ struct vfio_irq_set *irq)
+{
+ VFIOUserProxy *proxy = vbasedev->proxy;
+ g_autofree VFIOUserIRQSet *msgp = NULL;
+ uint32_t size, nfds, send_fds, sent_fds, max;
+
+ if (irq->argsz < sizeof(*irq)) {
+ error_printf("vfio_user_set_irqs argsz too small\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Handle simple case
+ */
+ if ((irq->flags & VFIO_IRQ_SET_DATA_EVENTFD) == 0) {
+ size = sizeof(VFIOUserHdr) + irq->argsz;
+ msgp = g_malloc0(size);
+
+ vfio_user_request_msg(&msgp->hdr, VFIO_USER_DEVICE_SET_IRQS, size, 0);
+ msgp->argsz = irq->argsz;
+ msgp->flags = irq->flags;
+ msgp->index = irq->index;
+ msgp->start = irq->start;
+ msgp->count = irq->count;
+ trace_vfio_user_set_irqs(msgp->index, msgp->start, msgp->count,
+ msgp->flags);
+
+ vfio_user_send_wait(proxy, &msgp->hdr, NULL, 0);
+ if (msgp->hdr.flags & VFIO_USER_ERROR) {
+ return -msgp->hdr.error_reply;
+ }
+
+ return 0;
+ }
+
+ /*
+ * Calculate the number of FDs to send
+ * and adjust argsz
+ */
+ nfds = (irq->argsz - sizeof(*irq)) / sizeof(int);
+ irq->argsz = sizeof(*irq);
+ msgp = g_malloc0(sizeof(*msgp));
+ /*
+ * Send in chunks if over max_send_fds
+ */
+ for (sent_fds = 0; nfds > sent_fds; sent_fds += send_fds) {
+ VFIOUserFDs *arg_fds, loop_fds;
+
+ /* must send all valid FDs or all invalid FDs in single msg */
+ max = nfds - sent_fds;
+ if (max > proxy->max_send_fds) {
+ max = proxy->max_send_fds;
+ }
+ send_fds = irq_howmany((int *)irq->data, sent_fds, max);
+
+ vfio_user_request_msg(&msgp->hdr, VFIO_USER_DEVICE_SET_IRQS,
+ sizeof(*msgp), 0);
+ msgp->argsz = irq->argsz;
+ msgp->flags = irq->flags;
+ msgp->index = irq->index;
+ msgp->start = irq->start + sent_fds;
+ msgp->count = send_fds;
+ trace_vfio_user_set_irqs(msgp->index, msgp->start, msgp->count,
+ msgp->flags);
+
+ loop_fds.send_fds = send_fds;
+ loop_fds.recv_fds = 0;
+ loop_fds.fds = (int *)irq->data + sent_fds;
+ arg_fds = loop_fds.fds[0] != -1 ? &loop_fds : NULL;
+
+ vfio_user_send_wait(proxy, &msgp->hdr, arg_fds, 0);
+ if (msgp->hdr.flags & VFIO_USER_ERROR) {
+ return -msgp->hdr.error_reply;
+ }
+ }
+
+ return 0;
+}
+
static int vfio_user_device_io_region_read(VFIODevice *vbasedev, uint8_t index,
off_t off, uint32_t count,
void *data)
@@ -179,6 +298,8 @@ static int vfio_user_device_io_region_write(VFIODevice *vbasedev, uint8_t index,
*/
VFIODeviceIOOps vfio_user_device_io_ops_sock = {
.get_region_info = vfio_user_device_io_get_region_info,
+ .get_irq_info = vfio_user_device_io_get_irq_info,
+ .set_irqs = vfio_user_device_io_set_irqs,
.region_read = vfio_user_device_io_region_read,
.region_write = vfio_user_device_io_region_write,
diff --git a/hw/vfio-user/trace-events b/hw/vfio-user/trace-events
index 3f5aebe7ac..053f5932eb 100644
--- a/hw/vfio-user/trace-events
+++ b/hw/vfio-user/trace-events
@@ -9,3 +9,5 @@ vfio_user_version(uint16_t major, uint16_t minor, const char *caps) " major %d m
vfio_user_get_info(uint32_t nregions, uint32_t nirqs) " #regions %d #irqs %d"
vfio_user_get_region_info(uint32_t index, uint32_t flags, uint64_t size) " index %d flags 0x%x size 0x%"PRIx64
vfio_user_region_rw(uint32_t region, uint64_t off, uint32_t count) " region %d offset 0x%"PRIx64" count %d"
+vfio_user_get_irq_info(uint32_t index, uint32_t flags, uint32_t count) " index %d flags 0x%x count %d"
+vfio_user_set_irqs(uint32_t index, uint32_t start, uint32_t count, uint32_t flags) " index %d start %d count %d flags 0x%x"
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 15/23] vfio-user: forward MSI-X PBA BAR accesses to server
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (13 preceding siblings ...)
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 ` John Levon
2025-06-07 0:10 ` [PATCH v3 16/23] vfio-user: set up container access to the proxy John Levon
` (8 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
For vfio-user, the server holds the pending IRQ state; set up an I/O
region for the MSI-X PBA so we can ask the server for this state on a
PBA read.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio/pci.h | 1 +
hw/vfio-user/pci.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 65 insertions(+)
diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
index e3a7d7bdca..47cf50a4bc 100644
--- a/hw/vfio/pci.h
+++ b/hw/vfio/pci.h
@@ -116,6 +116,7 @@ typedef struct VFIOMSIXInfo {
uint32_t pba_offset;
unsigned long *pending;
bool noresize;
+ MemoryRegion *pba_region;
} VFIOMSIXInfo;
/*
diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
index 5ac3fb087f..e055d5ffec 100644
--- a/hw/vfio-user/pci.c
+++ b/hw/vfio-user/pci.c
@@ -26,6 +26,62 @@ struct VFIOUserPCIDevice {
bool send_queued; /* all sends are queued */
};
+/*
+ * The server maintains the device's pending interrupts,
+ * via its MSIX table and PBA, so we treat these accesses
+ * like PCI config space and forward them.
+ */
+static uint64_t vfio_user_pba_read(void *opaque, hwaddr addr,
+ unsigned size)
+{
+ VFIOPCIDevice *vdev = opaque;
+ VFIORegion *region = &vdev->bars[vdev->msix->pba_bar].region;
+ uint64_t data;
+
+ /* server copy is what matters */
+ data = vfio_region_read(region, addr + vdev->msix->pba_offset, size);
+ return data;
+}
+
+static void vfio_user_pba_write(void *opaque, hwaddr addr,
+ uint64_t data, unsigned size)
+{
+ /* dropped */
+}
+
+static const MemoryRegionOps vfio_user_pba_ops = {
+ .read = vfio_user_pba_read,
+ .write = vfio_user_pba_write,
+ .endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static void vfio_user_msix_setup(VFIOPCIDevice *vdev)
+{
+ MemoryRegion *vfio_reg, *msix_reg, *pba_reg;
+
+ pba_reg = g_new0(MemoryRegion, 1);
+ vdev->msix->pba_region = pba_reg;
+
+ vfio_reg = vdev->bars[vdev->msix->pba_bar].mr;
+ msix_reg = &vdev->pdev.msix_pba_mmio;
+ memory_region_init_io(pba_reg, OBJECT(vdev), &vfio_user_pba_ops, vdev,
+ "VFIO MSIX PBA", int128_get64(msix_reg->size));
+ memory_region_add_subregion_overlap(vfio_reg, vdev->msix->pba_offset,
+ pba_reg, 1);
+}
+
+static void vfio_user_msix_teardown(VFIOPCIDevice *vdev)
+{
+ MemoryRegion *mr, *sub;
+
+ mr = vdev->bars[vdev->msix->pba_bar].mr;
+ sub = vdev->msix->pba_region;
+ memory_region_del_subregion(mr, sub);
+
+ g_free(vdev->msix->pba_region);
+ vdev->msix->pba_region = NULL;
+}
+
/*
* Incoming request message callback.
*
@@ -142,6 +198,10 @@ static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
goto out_teardown;
}
+ if (vdev->msix != NULL) {
+ vfio_user_msix_setup(vdev);
+ }
+
if (!vfio_pci_interrupt_setup(vdev, errp)) {
goto out_teardown;
}
@@ -190,6 +250,10 @@ static void vfio_user_instance_finalize(Object *obj)
VFIOPCIDevice *vdev = VFIO_PCI_BASE(obj);
VFIODevice *vbasedev = &vdev->vbasedev;
+ if (vdev->msix != NULL) {
+ vfio_user_msix_teardown(vdev);
+ }
+
vfio_pci_put_device(vdev);
if (vbasedev->proxy != NULL) {
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 16/23] vfio-user: set up container access to the proxy
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (14 preceding siblings ...)
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 ` John Levon
2025-06-07 0:10 ` [PATCH v3 17/23] vfio-user: implement VFIO_USER_DEVICE_RESET John Levon
` (7 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
The user container will shortly need access to the underlying vfio-user
proxy; set this up.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/container.h | 2 ++
hw/vfio-user/container.c | 43 +++++++++++++++++++++++++++++++---------
2 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/hw/vfio-user/container.h b/hw/vfio-user/container.h
index 3cd3303e68..59e14cf5b3 100644
--- a/hw/vfio-user/container.h
+++ b/hw/vfio-user/container.h
@@ -14,10 +14,12 @@
#include <stdbool.h>
#include "hw/vfio/vfio-container-base.h"
+#include "hw/vfio-user/proxy.h"
/* MMU container sub-class for vfio-user. */
typedef struct VFIOUserContainer {
VFIOContainerBase bcontainer;
+ VFIOUserProxy *proxy;
} VFIOUserContainer;
OBJECT_DECLARE_SIMPLE_TYPE(VFIOUserContainer, VFIO_IOMMU_USER);
diff --git a/hw/vfio-user/container.c b/hw/vfio-user/container.c
index 6f0eb86a75..38e9cf8d8a 100644
--- a/hw/vfio-user/container.c
+++ b/hw/vfio-user/container.c
@@ -53,15 +53,28 @@ static int vfio_user_query_dirty_bitmap(const VFIOContainerBase *bcontainer,
static bool vfio_user_setup(VFIOContainerBase *bcontainer, Error **errp)
{
- error_setg_errno(errp, ENOTSUP, "Not supported");
- return -ENOTSUP;
+ VFIOUserContainer *container = container_of(bcontainer, VFIOUserContainer,
+ bcontainer);
+
+ assert(container->proxy->dma_pgsizes != 0);
+ bcontainer->pgsizes = container->proxy->dma_pgsizes;
+ bcontainer->dma_max_mappings = container->proxy->max_dma;
+
+ /* No live migration support yet. */
+ bcontainer->dirty_pages_supported = false;
+ bcontainer->max_dirty_bitmap_size = container->proxy->max_bitmap;
+ bcontainer->dirty_pgsizes = container->proxy->migr_pgsize;
+
+ return true;
}
-static VFIOUserContainer *vfio_user_create_container(Error **errp)
+static VFIOUserContainer *vfio_user_create_container(VFIODevice *vbasedev,
+ Error **errp)
{
VFIOUserContainer *container;
container = VFIO_IOMMU_USER(object_new(TYPE_VFIO_IOMMU_USER));
+ container->proxy = vbasedev->proxy;
return container;
}
@@ -69,16 +82,18 @@ static VFIOUserContainer *vfio_user_create_container(Error **errp)
* Try to mirror vfio_container_connect() as much as possible.
*/
static VFIOUserContainer *
-vfio_user_container_connect(AddressSpace *as, Error **errp)
+vfio_user_container_connect(AddressSpace *as, VFIODevice *vbasedev,
+ Error **errp)
{
VFIOContainerBase *bcontainer;
VFIOUserContainer *container;
VFIOAddressSpace *space;
VFIOIOMMUClass *vioc;
+ int ret;
space = vfio_address_space_get(as);
- container = vfio_user_create_container(errp);
+ container = vfio_user_create_container(vbasedev, errp);
if (!container) {
goto put_space_exit;
}
@@ -89,11 +104,17 @@ vfio_user_container_connect(AddressSpace *as, Error **errp)
goto free_container_exit;
}
+ ret = ram_block_uncoordinated_discard_disable(true);
+ if (ret) {
+ error_setg_errno(errp, -ret, "Cannot set discarding of RAM broken");
+ goto unregister_container_exit;
+ }
+
vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
assert(vioc->setup);
if (!vioc->setup(bcontainer, errp)) {
- goto unregister_container_exit;
+ goto enable_discards_exit;
}
vfio_address_space_insert(space, bcontainer);
@@ -112,6 +133,9 @@ listener_release_exit:
vioc->release(bcontainer);
}
+enable_discards_exit:
+ ram_block_uncoordinated_discard_disable(false);
+
unregister_container_exit:
vfio_cpr_unregister_container(bcontainer);
@@ -128,14 +152,15 @@ static void vfio_user_container_disconnect(VFIOUserContainer *container)
{
VFIOContainerBase *bcontainer = &container->bcontainer;
VFIOIOMMUClass *vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
+ VFIOAddressSpace *space = bcontainer->space;
+
+ ram_block_uncoordinated_discard_disable(false);
vfio_listener_unregister(bcontainer);
if (vioc->release) {
vioc->release(bcontainer);
}
- VFIOAddressSpace *space = bcontainer->space;
-
vfio_cpr_unregister_container(bcontainer);
object_unref(container);
@@ -169,7 +194,7 @@ static bool vfio_user_device_attach(const char *name, VFIODevice *vbasedev,
{
VFIOUserContainer *container;
- container = vfio_user_container_connect(as, errp);
+ container = vfio_user_container_connect(as, vbasedev, errp);
if (container == NULL) {
error_prepend(errp, "failed to connect proxy");
return false;
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 17/23] vfio-user: implement VFIO_USER_DEVICE_RESET
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (15 preceding siblings ...)
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 ` John Levon
2025-06-07 0:10 ` [PATCH v3 18/23] vfio-user: implement VFIO_USER_DMA_MAP/UNMAP John Levon
` (6 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
Hook this call up to the legacy reset handler for vfio-user-pci.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/device.h | 2 ++
hw/vfio-user/device.c | 12 ++++++++++++
hw/vfio-user/pci.c | 15 +++++++++++++++
3 files changed, 29 insertions(+)
diff --git a/hw/vfio-user/device.h b/hw/vfio-user/device.h
index a5a2aa9ba6..25cd4c8a00 100644
--- a/hw/vfio-user/device.h
+++ b/hw/vfio-user/device.h
@@ -20,6 +20,8 @@
int vfio_user_get_device_info(VFIOUserProxy *proxy,
struct vfio_device_info *info);
+void vfio_user_device_reset(VFIOUserProxy *proxy);
+
extern VFIODeviceIOOps vfio_user_device_io_ops_sock;
#endif /* VFIO_USER_DEVICE_H */
diff --git a/hw/vfio-user/device.c b/hw/vfio-user/device.c
index 45b91d22f0..b37f7329a1 100644
--- a/hw/vfio-user/device.c
+++ b/hw/vfio-user/device.c
@@ -49,6 +49,18 @@ int vfio_user_get_device_info(VFIOUserProxy *proxy,
return 0;
}
+void vfio_user_device_reset(VFIOUserProxy *proxy)
+{
+ VFIOUserHdr msg;
+
+ vfio_user_request_msg(&msg, VFIO_USER_DEVICE_RESET, sizeof(msg), 0);
+
+ vfio_user_send_wait(proxy, &msg, NULL, 0);
+ if (msg.flags & VFIO_USER_ERROR) {
+ error_printf("reset reply error %d\n", msg.error_reply);
+ }
+}
+
static int vfio_user_get_region_info(VFIOUserProxy *proxy,
struct vfio_region_info *info,
VFIOUserFDs *fds)
diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
index e055d5ffec..2bc71b9b54 100644
--- a/hw/vfio-user/pci.c
+++ b/hw/vfio-user/pci.c
@@ -261,6 +261,20 @@ static void vfio_user_instance_finalize(Object *obj)
}
}
+static void vfio_user_pci_reset(DeviceState *dev)
+{
+ VFIOPCIDevice *vdev = VFIO_PCI_BASE(dev);
+ VFIODevice *vbasedev = &vdev->vbasedev;
+
+ vfio_pci_pre_reset(vdev);
+
+ if (vbasedev->reset_works) {
+ vfio_user_device_reset(vbasedev->proxy);
+ }
+
+ vfio_pci_post_reset(vdev);
+}
+
static const Property vfio_user_pci_dev_properties[] = {
DEFINE_PROP_UINT32("x-pci-vendor-id", VFIOPCIDevice,
vendor_id, PCI_ANY_ID),
@@ -279,6 +293,7 @@ static void vfio_user_pci_dev_class_init(ObjectClass *klass, const void *data)
DeviceClass *dc = DEVICE_CLASS(klass);
PCIDeviceClass *pdc = PCI_DEVICE_CLASS(klass);
+ device_class_set_legacy_reset(dc, vfio_user_pci_reset);
device_class_set_props(dc, vfio_user_pci_dev_properties);
dc->desc = "VFIO over socket PCI device assignment";
pdc->realize = vfio_user_pci_realize;
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 18/23] vfio-user: implement VFIO_USER_DMA_MAP/UNMAP
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (16 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 17/23] vfio-user: implement VFIO_USER_DEVICE_RESET John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-07 0:10 ` [PATCH v3 19/23] vfio-user: implement VFIO_USER_DMA_READ/WRITE John Levon
` (5 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Levon, John Johnson,
Jagannathan Raman, Elena Ufimtseva
From: John Levon <levon@movementarian.org>
When the vfio-user container gets mapping updates, share them with the
vfio-user by sending a message; this can include the region fd, allowing
the server to directly mmap() the region as needed.
For performance, we only wait for the message responses when we're doing
with a series of updates via the listener_commit() callback.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/protocol.h | 32 ++++++++++++
hw/vfio-user/proxy.h | 6 +++
hw/vfio-user/container.c | 107 +++++++++++++++++++++++++++++++++++++-
hw/vfio-user/proxy.c | 77 ++++++++++++++++++++++++++-
hw/vfio-user/trace-events | 4 ++
5 files changed, 222 insertions(+), 4 deletions(-)
diff --git a/hw/vfio-user/protocol.h b/hw/vfio-user/protocol.h
index 920b9c44ec..4fa6d03b3f 100644
--- a/hw/vfio-user/protocol.h
+++ b/hw/vfio-user/protocol.h
@@ -115,6 +115,31 @@ typedef struct {
*/
#define VFIO_USER_DEF_MAX_BITMAP (256 * 1024 * 1024)
+/*
+ * VFIO_USER_DMA_MAP
+ * imported from struct vfio_iommu_type1_dma_map
+ */
+typedef struct {
+ VFIOUserHdr hdr;
+ uint32_t argsz;
+ uint32_t flags;
+ uint64_t offset; /* FD offset */
+ uint64_t iova;
+ uint64_t size;
+} VFIOUserDMAMap;
+
+/*
+ * VFIO_USER_DMA_UNMAP
+ * imported from struct vfio_iommu_type1_dma_unmap
+ */
+typedef struct {
+ VFIOUserHdr hdr;
+ uint32_t argsz;
+ uint32_t flags;
+ uint64_t iova;
+ uint64_t size;
+} VFIOUserDMAUnmap;
+
/*
* VFIO_USER_DEVICE_GET_INFO
* imported from struct vfio_device_info
@@ -178,4 +203,11 @@ typedef struct {
char data[];
} VFIOUserRegionRW;
+/*imported from struct vfio_bitmap */
+typedef struct {
+ uint64_t pgsize;
+ uint64_t size;
+ char data[];
+} VFIOUserBitmap;
+
#endif /* VFIO_USER_PROTOCOL_H */
diff --git a/hw/vfio-user/proxy.h b/hw/vfio-user/proxy.h
index e2cfaeead8..01fed3f17d 100644
--- a/hw/vfio-user/proxy.h
+++ b/hw/vfio-user/proxy.h
@@ -73,6 +73,7 @@ typedef struct VFIOUserProxy {
QemuCond close_cv;
AioContext *ctx;
QEMUBH *req_bh;
+ bool async_ops;
/*
* above only changed when BQL is held
@@ -102,9 +103,14 @@ void vfio_user_set_handler(VFIODevice *vbasedev,
void *reqarg);
bool vfio_user_validate_version(VFIOUserProxy *proxy, Error **errp);
+VFIOUserFDs *vfio_user_getfds(int numfds);
+
void vfio_user_request_msg(VFIOUserHdr *hdr, uint16_t cmd,
uint32_t size, uint32_t flags);
+void vfio_user_wait_reqs(VFIOUserProxy *proxy);
void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
VFIOUserFDs *fds, int rsize);
+void vfio_user_send_nowait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
+ VFIOUserFDs *fds, int rsize);
#endif /* VFIO_USER_PROXY_H */
diff --git a/hw/vfio-user/container.c b/hw/vfio-user/container.c
index 38e9cf8d8a..5a109c591e 100644
--- a/hw/vfio-user/container.c
+++ b/hw/vfio-user/container.c
@@ -21,18 +21,119 @@
#include "qapi/error.h"
#include "trace.h"
+/*
+ * When DMA space is the physical address space, the region add/del listeners
+ * will fire during memory update transactions. These depend on BQL being held,
+ * so do any resulting map/demap ops async while keeping BQL.
+ */
+static void vfio_user_listener_begin(VFIOContainerBase *bcontainer)
+{
+ VFIOUserContainer *container = container_of(bcontainer, VFIOUserContainer,
+ bcontainer);
+
+ container->proxy->async_ops = true;
+}
+
+static void vfio_user_listener_commit(VFIOContainerBase *bcontainer)
+{
+ VFIOUserContainer *container = container_of(bcontainer, VFIOUserContainer,
+ bcontainer);
+
+ /* wait here for any async requests sent during the transaction */
+ container->proxy->async_ops = false;
+ vfio_user_wait_reqs(container->proxy);
+}
+
static int vfio_user_dma_unmap(const VFIOContainerBase *bcontainer,
hwaddr iova, ram_addr_t size,
IOMMUTLBEntry *iotlb, bool unmap_all)
{
- return -ENOTSUP;
+ VFIOUserContainer *container = container_of(bcontainer, VFIOUserContainer,
+ bcontainer);
+
+ VFIOUserDMAUnmap *msgp = g_malloc(sizeof(*msgp));
+
+ vfio_user_request_msg(&msgp->hdr, VFIO_USER_DMA_UNMAP, sizeof(*msgp), 0);
+ msgp->argsz = sizeof(struct vfio_iommu_type1_dma_unmap);
+ msgp->flags = unmap_all ? VFIO_DMA_UNMAP_FLAG_ALL : 0;
+ msgp->iova = iova;
+ msgp->size = size;
+ trace_vfio_user_dma_unmap(msgp->iova, msgp->size, msgp->flags,
+ container->proxy->async_ops);
+
+ if (container->proxy->async_ops) {
+ vfio_user_send_nowait(container->proxy, &msgp->hdr, NULL, 0);
+ return 0;
+ }
+
+ vfio_user_send_wait(container->proxy, &msgp->hdr, NULL, 0);
+ if (msgp->hdr.flags & VFIO_USER_ERROR) {
+ return -msgp->hdr.error_reply;
+ }
+
+ g_free(msgp);
+ return 0;
}
static int vfio_user_dma_map(const VFIOContainerBase *bcontainer, hwaddr iova,
ram_addr_t size, void *vaddr, bool readonly,
MemoryRegion *mrp)
{
- return -ENOTSUP;
+ VFIOUserContainer *container = container_of(bcontainer, VFIOUserContainer,
+ bcontainer);
+
+ VFIOUserProxy *proxy = container->proxy;
+ int fd = memory_region_get_fd(mrp);
+ int ret;
+
+ VFIOUserFDs *fds = NULL;
+ VFIOUserDMAMap *msgp = g_malloc0(sizeof(*msgp));
+
+ vfio_user_request_msg(&msgp->hdr, VFIO_USER_DMA_MAP, sizeof(*msgp), 0);
+ msgp->argsz = sizeof(struct vfio_iommu_type1_dma_map);
+ msgp->flags = VFIO_DMA_MAP_FLAG_READ;
+ msgp->offset = 0;
+ msgp->iova = iova;
+ msgp->size = size;
+
+ /*
+ * vaddr enters as a QEMU process address; make it either a file offset
+ * for mapped areas or leave as 0.
+ */
+ if (fd != -1) {
+ msgp->offset = qemu_ram_block_host_offset(mrp->ram_block, vaddr);
+ }
+
+ if (!readonly) {
+ msgp->flags |= VFIO_DMA_MAP_FLAG_WRITE;
+ }
+
+ trace_vfio_user_dma_map(msgp->iova, msgp->size, msgp->offset, msgp->flags,
+ container->proxy->async_ops);
+
+ /*
+ * The async_ops case sends without blocking. They're later waited for in
+ * vfio_send_wait_reqs.
+ */
+ if (container->proxy->async_ops) {
+ /* can't use auto variable since we don't block */
+ if (fd != -1) {
+ fds = vfio_user_getfds(1);
+ fds->send_fds = 1;
+ fds->fds[0] = fd;
+ }
+ vfio_user_send_nowait(proxy, &msgp->hdr, fds, 0);
+ ret = 0;
+ } else {
+ VFIOUserFDs local_fds = { 1, 0, &fd };
+
+ fds = fd != -1 ? &local_fds : NULL;
+ vfio_user_send_wait(proxy, &msgp->hdr, fds, 0);
+ ret = (msgp->hdr.flags & VFIO_USER_ERROR) ? -msgp->hdr.error_reply : 0;
+ g_free(msgp);
+ }
+
+ return ret;
}
static int
@@ -224,6 +325,8 @@ static void vfio_iommu_user_class_init(ObjectClass *klass, const void *data)
VFIOIOMMUClass *vioc = VFIO_IOMMU_CLASS(klass);
vioc->setup = vfio_user_setup;
+ vioc->listener_begin = vfio_user_listener_begin,
+ vioc->listener_commit = vfio_user_listener_commit,
vioc->dma_map = vfio_user_dma_map;
vioc->dma_unmap = vfio_user_dma_unmap;
vioc->attach_device = vfio_user_device_attach;
diff --git a/hw/vfio-user/proxy.c b/hw/vfio-user/proxy.c
index 34df9bba7b..6d1446c38b 100644
--- a/hw/vfio-user/proxy.c
+++ b/hw/vfio-user/proxy.c
@@ -31,7 +31,6 @@ static void vfio_user_shutdown(VFIOUserProxy *proxy);
static int vfio_user_send_qio(VFIOUserProxy *proxy, VFIOUserMsg *msg);
static VFIOUserMsg *vfio_user_getmsg(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
VFIOUserFDs *fds);
-static VFIOUserFDs *vfio_user_getfds(int numfds);
static void vfio_user_recycle(VFIOUserProxy *proxy, VFIOUserMsg *msg);
static void vfio_user_recv(void *opaque);
@@ -133,7 +132,7 @@ static void vfio_user_recycle(VFIOUserProxy *proxy, VFIOUserMsg *msg)
QTAILQ_INSERT_HEAD(&proxy->free, msg, next);
}
-static VFIOUserFDs *vfio_user_getfds(int numfds)
+VFIOUserFDs *vfio_user_getfds(int numfds)
{
VFIOUserFDs *fds = g_malloc0(sizeof(*fds) + (numfds * sizeof(int)));
@@ -609,6 +608,36 @@ static int vfio_user_send_queued(VFIOUserProxy *proxy, VFIOUserMsg *msg)
return 0;
}
+/*
+ * nowait send - vfio_wait_reqs() can wait for it later
+ */
+void vfio_user_send_nowait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
+ VFIOUserFDs *fds, int rsize)
+{
+ VFIOUserMsg *msg;
+ int ret;
+
+ if (hdr->flags & VFIO_USER_NO_REPLY) {
+ error_printf("vfio_user_send_nowait on async message\n");
+ return;
+ }
+
+ QEMU_LOCK_GUARD(&proxy->lock);
+
+ msg = vfio_user_getmsg(proxy, hdr, fds);
+ msg->id = hdr->id;
+ msg->rsize = rsize ? rsize : hdr->size;
+ msg->type = VFIO_MSG_NOWAIT;
+
+ ret = vfio_user_send_queued(proxy, msg);
+ if (ret < 0) {
+ vfio_user_recycle(proxy, msg);
+ return;
+ }
+
+ proxy->last_nowait = msg;
+}
+
void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
VFIOUserFDs *fds, int rsize)
{
@@ -647,6 +676,50 @@ void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
qemu_mutex_unlock(&proxy->lock);
}
+void vfio_user_wait_reqs(VFIOUserProxy *proxy)
+{
+ VFIOUserMsg *msg;
+
+ /*
+ * Any DMA map/unmap requests sent in the middle
+ * of a memory region transaction were sent nowait.
+ * Wait for them here.
+ */
+ qemu_mutex_lock(&proxy->lock);
+ if (proxy->last_nowait != NULL) {
+ /*
+ * Change type to WAIT to wait for reply
+ */
+ msg = proxy->last_nowait;
+ msg->type = VFIO_MSG_WAIT;
+ proxy->last_nowait = NULL;
+ while (!msg->complete) {
+ if (!qemu_cond_timedwait(&msg->cv, &proxy->lock, wait_time)) {
+ VFIOUserMsgQ *list;
+
+ list = msg->pending ? &proxy->pending : &proxy->outgoing;
+ QTAILQ_REMOVE(list, msg, next);
+ error_printf("vfio_wait_reqs - timed out\n");
+ break;
+ }
+ }
+
+ if (msg->hdr->flags & VFIO_USER_ERROR) {
+ error_printf("vfio_user_wait_reqs - error reply on async ");
+ error_printf("request: command %x error %s\n", msg->hdr->command,
+ strerror(msg->hdr->error_reply));
+ }
+
+ /*
+ * Change type back to NOWAIT to free
+ */
+ msg->type = VFIO_MSG_NOWAIT;
+ vfio_user_recycle(proxy, msg);
+ }
+
+ qemu_mutex_unlock(&proxy->lock);
+}
+
static QLIST_HEAD(, VFIOUserProxy) vfio_user_sockets =
QLIST_HEAD_INITIALIZER(vfio_user_sockets);
diff --git a/hw/vfio-user/trace-events b/hw/vfio-user/trace-events
index 053f5932eb..7ef98813b3 100644
--- a/hw/vfio-user/trace-events
+++ b/hw/vfio-user/trace-events
@@ -11,3 +11,7 @@ vfio_user_get_region_info(uint32_t index, uint32_t flags, uint64_t size) " index
vfio_user_region_rw(uint32_t region, uint64_t off, uint32_t count) " region %d offset 0x%"PRIx64" count %d"
vfio_user_get_irq_info(uint32_t index, uint32_t flags, uint32_t count) " index %d flags 0x%x count %d"
vfio_user_set_irqs(uint32_t index, uint32_t start, uint32_t count, uint32_t flags) " index %d start %d count %d flags 0x%x"
+
+# container.c
+vfio_user_dma_map(uint64_t iova, uint64_t size, uint64_t off, uint32_t flags, bool async_ops) " iova 0x%"PRIx64" size 0x%"PRIx64" off 0x%"PRIx64" flags 0x%x async_ops %d"
+vfio_user_dma_unmap(uint64_t iova, uint64_t size, uint32_t flags, bool async_ops) " iova 0x%"PRIx64" size 0x%"PRIx64" flags 0x%x async_ops %d"
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 19/23] vfio-user: implement VFIO_USER_DMA_READ/WRITE
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (17 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 18/23] vfio-user: implement VFIO_USER_DMA_MAP/UNMAP John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-07 0:10 ` [PATCH v3 20/23] vfio-user: add 'x-msg-timeout' option John Levon
` (4 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
Unlike most other messages, this is a server->client message, for when a
server wants to do "DMA"; this is slow, so normally the server has
memory directly mapped instead.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/protocol.h | 13 ++++-
hw/vfio-user/proxy.h | 3 ++
hw/vfio-user/pci.c | 111 ++++++++++++++++++++++++++++++++++++++++
hw/vfio-user/proxy.c | 84 ++++++++++++++++++++++++++++++
4 files changed, 210 insertions(+), 1 deletion(-)
diff --git a/hw/vfio-user/protocol.h b/hw/vfio-user/protocol.h
index 4fa6d03b3f..8f589faef4 100644
--- a/hw/vfio-user/protocol.h
+++ b/hw/vfio-user/protocol.h
@@ -203,7 +203,18 @@ typedef struct {
char data[];
} VFIOUserRegionRW;
-/*imported from struct vfio_bitmap */
+/*
+ * VFIO_USER_DMA_READ
+ * VFIO_USER_DMA_WRITE
+ */
+typedef struct {
+ VFIOUserHdr hdr;
+ uint64_t offset;
+ uint32_t count;
+ char data[];
+} VFIOUserDMARW;
+
+/* imported from struct vfio_bitmap */
typedef struct {
uint64_t pgsize;
uint64_t size;
diff --git a/hw/vfio-user/proxy.h b/hw/vfio-user/proxy.h
index 01fed3f17d..8f2d529846 100644
--- a/hw/vfio-user/proxy.h
+++ b/hw/vfio-user/proxy.h
@@ -104,6 +104,7 @@ void vfio_user_set_handler(VFIODevice *vbasedev,
bool vfio_user_validate_version(VFIOUserProxy *proxy, Error **errp);
VFIOUserFDs *vfio_user_getfds(int numfds);
+void vfio_user_putfds(VFIOUserMsg *msg);
void vfio_user_request_msg(VFIOUserHdr *hdr, uint16_t cmd,
uint32_t size, uint32_t flags);
@@ -112,5 +113,7 @@ void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
VFIOUserFDs *fds, int rsize);
void vfio_user_send_nowait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
VFIOUserFDs *fds, int rsize);
+void vfio_user_send_reply(VFIOUserProxy *proxy, VFIOUserHdr *hdr, int size);
+void vfio_user_send_error(VFIOUserProxy *proxy, VFIOUserHdr *hdr, int error);
#endif /* VFIO_USER_PROXY_H */
diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
index 2bc71b9b54..095f32604d 100644
--- a/hw/vfio-user/pci.c
+++ b/hw/vfio-user/pci.c
@@ -11,6 +11,7 @@
#include <sys/ioctl.h>
#include "qemu/osdep.h"
+#include "qemu/error-report.h"
#include "hw/qdev-properties.h"
#include "hw/vfio/pci.h"
@@ -82,6 +83,95 @@ static void vfio_user_msix_teardown(VFIOPCIDevice *vdev)
vdev->msix->pba_region = NULL;
}
+static void vfio_user_dma_read(VFIOPCIDevice *vdev, VFIOUserDMARW *msg)
+{
+ PCIDevice *pdev = &vdev->pdev;
+ VFIOUserProxy *proxy = vdev->vbasedev.proxy;
+ VFIOUserDMARW *res;
+ MemTxResult r;
+ size_t size;
+
+ if (msg->hdr.size < sizeof(*msg)) {
+ vfio_user_send_error(proxy, &msg->hdr, EINVAL);
+ return;
+ }
+ if (msg->count > proxy->max_xfer_size) {
+ vfio_user_send_error(proxy, &msg->hdr, E2BIG);
+ return;
+ }
+
+ /* switch to our own message buffer */
+ size = msg->count + sizeof(VFIOUserDMARW);
+ res = g_malloc0(size);
+ memcpy(res, msg, sizeof(*res));
+ g_free(msg);
+
+ r = pci_dma_read(pdev, res->offset, &res->data, res->count);
+
+ switch (r) {
+ case MEMTX_OK:
+ if (res->hdr.flags & VFIO_USER_NO_REPLY) {
+ g_free(res);
+ return;
+ }
+ vfio_user_send_reply(proxy, &res->hdr, size);
+ break;
+ case MEMTX_ERROR:
+ vfio_user_send_error(proxy, &res->hdr, EFAULT);
+ break;
+ case MEMTX_DECODE_ERROR:
+ vfio_user_send_error(proxy, &res->hdr, ENODEV);
+ break;
+ case MEMTX_ACCESS_ERROR:
+ vfio_user_send_error(proxy, &res->hdr, EPERM);
+ break;
+ default:
+ error_printf("vfio_user_dma_read unknown error %d\n", r);
+ vfio_user_send_error(vdev->vbasedev.proxy, &res->hdr, EINVAL);
+ }
+}
+
+static void vfio_user_dma_write(VFIOPCIDevice *vdev, VFIOUserDMARW *msg)
+{
+ PCIDevice *pdev = &vdev->pdev;
+ VFIOUserProxy *proxy = vdev->vbasedev.proxy;
+ MemTxResult r;
+
+ if (msg->hdr.size < sizeof(*msg)) {
+ vfio_user_send_error(proxy, &msg->hdr, EINVAL);
+ return;
+ }
+ /* make sure transfer count isn't larger than the message data */
+ if (msg->count > msg->hdr.size - sizeof(*msg)) {
+ vfio_user_send_error(proxy, &msg->hdr, E2BIG);
+ return;
+ }
+
+ r = pci_dma_write(pdev, msg->offset, &msg->data, msg->count);
+
+ switch (r) {
+ case MEMTX_OK:
+ if ((msg->hdr.flags & VFIO_USER_NO_REPLY) == 0) {
+ vfio_user_send_reply(proxy, &msg->hdr, sizeof(msg->hdr));
+ } else {
+ g_free(msg);
+ }
+ break;
+ case MEMTX_ERROR:
+ vfio_user_send_error(proxy, &msg->hdr, EFAULT);
+ break;
+ case MEMTX_DECODE_ERROR:
+ vfio_user_send_error(proxy, &msg->hdr, ENODEV);
+ break;
+ case MEMTX_ACCESS_ERROR:
+ vfio_user_send_error(proxy, &msg->hdr, EPERM);
+ break;
+ default:
+ error_printf("vfio_user_dma_write unknown error %d\n", r);
+ vfio_user_send_error(vdev->vbasedev.proxy, &msg->hdr, EINVAL);
+ }
+}
+
/*
* Incoming request message callback.
*
@@ -89,7 +179,28 @@ static void vfio_user_msix_teardown(VFIOPCIDevice *vdev)
*/
static void vfio_user_pci_process_req(void *opaque, VFIOUserMsg *msg)
{
+ VFIOPCIDevice *vdev = opaque;
+ VFIOUserHdr *hdr = msg->hdr;
+
+ /* no incoming PCI requests pass FDs */
+ if (msg->fds != NULL) {
+ vfio_user_send_error(vdev->vbasedev.proxy, hdr, EINVAL);
+ vfio_user_putfds(msg);
+ return;
+ }
+ switch (hdr->command) {
+ case VFIO_USER_DMA_READ:
+ vfio_user_dma_read(vdev, (VFIOUserDMARW *)hdr);
+ break;
+ case VFIO_USER_DMA_WRITE:
+ vfio_user_dma_write(vdev, (VFIOUserDMARW *)hdr);
+ break;
+ default:
+ error_printf("vfio_user_pci_process_req unknown cmd %d\n",
+ hdr->command);
+ vfio_user_send_error(vdev->vbasedev.proxy, hdr, ENOSYS);
+ }
}
/*
diff --git a/hw/vfio-user/proxy.c b/hw/vfio-user/proxy.c
index 6d1446c38b..0935b72e9f 100644
--- a/hw/vfio-user/proxy.c
+++ b/hw/vfio-user/proxy.c
@@ -362,6 +362,10 @@ static int vfio_user_recv_one(VFIOUserProxy *proxy)
*msg->hdr = hdr;
data = (char *)msg->hdr + sizeof(hdr);
} else {
+ if (hdr.size > proxy->max_xfer_size + sizeof(VFIOUserDMARW)) {
+ error_setg(&local_err, "vfio_user_recv request larger than max");
+ goto err;
+ }
buf = g_malloc0(hdr.size);
memcpy(buf, &hdr, sizeof(hdr));
data = buf + sizeof(hdr);
@@ -676,6 +680,33 @@ void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
qemu_mutex_unlock(&proxy->lock);
}
+/*
+ * async send - msg can be queued, but will be freed when sent
+ */
+static void vfio_user_send_async(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
+ VFIOUserFDs *fds)
+{
+ VFIOUserMsg *msg;
+ int ret;
+
+ if (!(hdr->flags & (VFIO_USER_NO_REPLY | VFIO_USER_REPLY))) {
+ error_printf("vfio_user_send_async on sync message\n");
+ return;
+ }
+
+ QEMU_LOCK_GUARD(&proxy->lock);
+
+ msg = vfio_user_getmsg(proxy, hdr, fds);
+ msg->id = hdr->id;
+ msg->rsize = 0;
+ msg->type = VFIO_MSG_ASYNC;
+
+ ret = vfio_user_send_queued(proxy, msg);
+ if (ret < 0) {
+ vfio_user_recycle(proxy, msg);
+ }
+}
+
void vfio_user_wait_reqs(VFIOUserProxy *proxy)
{
VFIOUserMsg *msg;
@@ -720,6 +751,59 @@ void vfio_user_wait_reqs(VFIOUserProxy *proxy)
qemu_mutex_unlock(&proxy->lock);
}
+/*
+ * Reply to an incoming request.
+ */
+void vfio_user_send_reply(VFIOUserProxy *proxy, VFIOUserHdr *hdr, int size)
+{
+
+ if (size < sizeof(VFIOUserHdr)) {
+ error_printf("vfio_user_send_reply - size too small\n");
+ g_free(hdr);
+ return;
+ }
+
+ /*
+ * convert header to associated reply
+ */
+ hdr->flags = VFIO_USER_REPLY;
+ hdr->size = size;
+
+ vfio_user_send_async(proxy, hdr, NULL);
+}
+
+/*
+ * Send an error reply to an incoming request.
+ */
+void vfio_user_send_error(VFIOUserProxy *proxy, VFIOUserHdr *hdr, int error)
+{
+
+ /*
+ * convert header to associated reply
+ */
+ hdr->flags = VFIO_USER_REPLY;
+ hdr->flags |= VFIO_USER_ERROR;
+ hdr->error_reply = error;
+ hdr->size = sizeof(*hdr);
+
+ vfio_user_send_async(proxy, hdr, NULL);
+}
+
+/*
+ * Close FDs erroneously received in an incoming request.
+ */
+void vfio_user_putfds(VFIOUserMsg *msg)
+{
+ VFIOUserFDs *fds = msg->fds;
+ int i;
+
+ for (i = 0; i < fds->recv_fds; i++) {
+ close(fds->fds[i]);
+ }
+ g_free(fds);
+ msg->fds = NULL;
+}
+
static QLIST_HEAD(, VFIOUserProxy) vfio_user_sockets =
QLIST_HEAD_INITIALIZER(vfio_user_sockets);
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 20/23] vfio-user: add 'x-msg-timeout' option
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (18 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 19/23] vfio-user: implement VFIO_USER_DMA_READ/WRITE John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-07 0:10 ` [PATCH v3 21/23] vfio-user: support posted writes John Levon
` (3 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
By default, the vfio-user subsystem will wait 5 seconds for a message
reply from the server. Add an option to allow this to be configurable.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/proxy.h | 1 +
hw/vfio-user/pci.c | 5 +++++
hw/vfio-user/proxy.c | 7 ++++---
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/hw/vfio-user/proxy.h b/hw/vfio-user/proxy.h
index 8f2d529846..da29674fdc 100644
--- a/hw/vfio-user/proxy.h
+++ b/hw/vfio-user/proxy.h
@@ -70,6 +70,7 @@ typedef struct VFIOUserProxy {
uint64_t max_bitmap;
uint64_t migr_pgsize;
int flags;
+ uint32_t wait_time;
QemuCond close_cv;
AioContext *ctx;
QEMUBH *req_bh;
diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
index 095f32604d..769dd9b810 100644
--- a/hw/vfio-user/pci.c
+++ b/hw/vfio-user/pci.c
@@ -25,6 +25,7 @@ struct VFIOUserPCIDevice {
VFIOPCIDevice device;
char *sock_name;
bool send_queued; /* all sends are queued */
+ uint32_t wait_time; /* timeout for message replies */
};
/*
@@ -263,6 +264,9 @@ static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
proxy->flags |= VFIO_PROXY_FORCE_QUEUED;
}
+ /* user specified or 5 sec default */
+ proxy->wait_time = udev->wait_time;
+
if (!vfio_user_validate_version(proxy, errp)) {
goto error;
}
@@ -397,6 +401,7 @@ static const Property vfio_user_pci_dev_properties[] = {
sub_device_id, PCI_ANY_ID),
DEFINE_PROP_STRING("socket", VFIOUserPCIDevice, sock_name),
DEFINE_PROP_BOOL("x-send-queued", VFIOUserPCIDevice, send_queued, false),
+ DEFINE_PROP_UINT32("x-msg-timeout", VFIOUserPCIDevice, wait_time, 5000),
};
static void vfio_user_pci_dev_class_init(ObjectClass *klass, const void *data)
diff --git a/hw/vfio-user/proxy.c b/hw/vfio-user/proxy.c
index 0935b72e9f..74cfaff6fa 100644
--- a/hw/vfio-user/proxy.c
+++ b/hw/vfio-user/proxy.c
@@ -24,7 +24,6 @@
#include "qemu/main-loop.h"
#include "system/iothread.h"
-static int wait_time = 5000; /* wait up to 5 sec for busy servers */
static IOThread *vfio_user_iothread;
static void vfio_user_shutdown(VFIOUserProxy *proxy);
@@ -665,7 +664,8 @@ void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
if (ret == 0) {
while (!msg->complete) {
- if (!qemu_cond_timedwait(&msg->cv, &proxy->lock, wait_time)) {
+ if (!qemu_cond_timedwait(&msg->cv, &proxy->lock,
+ proxy->wait_time)) {
VFIOUserMsgQ *list;
list = msg->pending ? &proxy->pending : &proxy->outgoing;
@@ -725,7 +725,8 @@ void vfio_user_wait_reqs(VFIOUserProxy *proxy)
msg->type = VFIO_MSG_WAIT;
proxy->last_nowait = NULL;
while (!msg->complete) {
- if (!qemu_cond_timedwait(&msg->cv, &proxy->lock, wait_time)) {
+ if (!qemu_cond_timedwait(&msg->cv, &proxy->lock,
+ proxy->wait_time)) {
VFIOUserMsgQ *list;
list = msg->pending ? &proxy->pending : &proxy->outgoing;
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 21/23] vfio-user: support posted writes
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (19 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 20/23] vfio-user: add 'x-msg-timeout' option John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-07 0:10 ` [PATCH v3 22/23] vfio-user: add coalesced " John Levon
` (2 subsequent siblings)
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon
Support an asynchronous send of a vfio-user socket message (no wait for
a reply) when the write is posted. This is only safe when no regions are
mappable by the VM. Add an option to explicitly disable this as well.
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/proxy.h | 5 +++++
hw/vfio-user/device.c | 37 ++++++++++++++++++++++++++++++++++---
hw/vfio-user/pci.c | 6 ++++++
hw/vfio-user/proxy.c | 12 ++++++++++--
4 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/hw/vfio-user/proxy.h b/hw/vfio-user/proxy.h
index da29674fdc..22ed66c54f 100644
--- a/hw/vfio-user/proxy.h
+++ b/hw/vfio-user/proxy.h
@@ -94,6 +94,7 @@ typedef struct VFIOUserProxy {
/* VFIOProxy flags */
#define VFIO_PROXY_CLIENT 0x1
#define VFIO_PROXY_FORCE_QUEUED 0x4
+#define VFIO_PROXY_NO_POST 0x8
typedef struct VFIODevice VFIODevice;
@@ -107,6 +108,8 @@ bool vfio_user_validate_version(VFIOUserProxy *proxy, Error **errp);
VFIOUserFDs *vfio_user_getfds(int numfds);
void vfio_user_putfds(VFIOUserMsg *msg);
+void vfio_user_disable_posted_writes(VFIOUserProxy *proxy);
+
void vfio_user_request_msg(VFIOUserHdr *hdr, uint16_t cmd,
uint32_t size, uint32_t flags);
void vfio_user_wait_reqs(VFIOUserProxy *proxy);
@@ -114,6 +117,8 @@ void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
VFIOUserFDs *fds, int rsize);
void vfio_user_send_nowait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
VFIOUserFDs *fds, int rsize);
+void vfio_user_send_async(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
+ VFIOUserFDs *fds);
void vfio_user_send_reply(VFIOUserProxy *proxy, VFIOUserHdr *hdr, int size);
void vfio_user_send_error(VFIOUserProxy *proxy, VFIOUserHdr *hdr, int error);
diff --git a/hw/vfio-user/device.c b/hw/vfio-user/device.c
index b37f7329a1..eb2194c0eb 100644
--- a/hw/vfio-user/device.c
+++ b/hw/vfio-user/device.c
@@ -93,10 +93,21 @@ static int vfio_user_get_region_info(VFIOUserProxy *proxy,
trace_vfio_user_get_region_info(msgp->index, msgp->flags, msgp->size);
memcpy(info, &msgp->argsz, info->argsz);
+
+ /*
+ * If at least one region is directly mapped into the VM, then we can no
+ * longer rely on the sequential nature of vfio-user request handling to
+ * ensure that posted writes are completed before a subsequent read. In this
+ * case, disable posted write support. This is a per-device property, not
+ * per-region.
+ */
+ if (info->flags & VFIO_REGION_INFO_FLAG_MMAP) {
+ vfio_user_disable_posted_writes(proxy);
+ }
+
return 0;
}
-
static int vfio_user_device_io_get_region_info(VFIODevice *vbasedev,
struct vfio_region_info *info,
int *fd)
@@ -272,6 +283,12 @@ static int vfio_user_device_io_region_read(VFIODevice *vbasedev, uint8_t index,
return msgp->count;
}
+/*
+ * If this is a posted write, and VFIO_PROXY_NO_POST is not set, then we are OK
+ * to send the write to the socket without waiting for the server's reply:
+ * a subsequent read (of any region) will not pass the posted write, as all
+ * messages are handled sequentially.
+ */
static int vfio_user_device_io_region_write(VFIODevice *vbasedev, uint8_t index,
off_t off, unsigned count,
void *data, bool post)
@@ -279,21 +296,35 @@ static int vfio_user_device_io_region_write(VFIODevice *vbasedev, uint8_t index,
VFIOUserRegionRW *msgp = NULL;
VFIOUserProxy *proxy = vbasedev->proxy;
int size = sizeof(*msgp) + count;
+ int flags = 0;
int ret;
if (count > proxy->max_xfer_size) {
return -EINVAL;
}
+ if (proxy->flags & VFIO_PROXY_NO_POST) {
+ post = false;
+ }
+
+ if (post) {
+ flags |= VFIO_USER_NO_REPLY;
+ }
+
msgp = g_malloc0(size);
- vfio_user_request_msg(&msgp->hdr, VFIO_USER_REGION_WRITE, size, 0);
+ vfio_user_request_msg(&msgp->hdr, VFIO_USER_REGION_WRITE, size, flags);
msgp->offset = off;
msgp->region = index;
msgp->count = count;
memcpy(&msgp->data, data, count);
trace_vfio_user_region_rw(msgp->region, msgp->offset, msgp->count);
- /* Ignore post: all writes are synchronous/non-posted. */
+ /* async send will free msg after it's sent */
+ if (post) {
+ vfio_user_send_async(proxy, &msgp->hdr, NULL);
+ return count;
+ }
+
vfio_user_send_wait(proxy, &msgp->hdr, NULL, 0);
if (msgp->hdr.flags & VFIO_USER_ERROR) {
ret = -msgp->hdr.error_reply;
diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c
index 769dd9b810..e59fa27039 100644
--- a/hw/vfio-user/pci.c
+++ b/hw/vfio-user/pci.c
@@ -26,6 +26,7 @@ struct VFIOUserPCIDevice {
char *sock_name;
bool send_queued; /* all sends are queued */
uint32_t wait_time; /* timeout for message replies */
+ bool no_post; /* all region writes are sync */
};
/*
@@ -264,6 +265,10 @@ static void vfio_user_pci_realize(PCIDevice *pdev, Error **errp)
proxy->flags |= VFIO_PROXY_FORCE_QUEUED;
}
+ if (udev->no_post) {
+ proxy->flags |= VFIO_PROXY_NO_POST;
+ }
+
/* user specified or 5 sec default */
proxy->wait_time = udev->wait_time;
@@ -402,6 +407,7 @@ static const Property vfio_user_pci_dev_properties[] = {
DEFINE_PROP_STRING("socket", VFIOUserPCIDevice, sock_name),
DEFINE_PROP_BOOL("x-send-queued", VFIOUserPCIDevice, send_queued, false),
DEFINE_PROP_UINT32("x-msg-timeout", VFIOUserPCIDevice, wait_time, 5000),
+ DEFINE_PROP_BOOL("x-no-posted-writes", VFIOUserPCIDevice, no_post, false),
};
static void vfio_user_pci_dev_class_init(ObjectClass *klass, const void *data)
diff --git a/hw/vfio-user/proxy.c b/hw/vfio-user/proxy.c
index 74cfaff6fa..13f2407845 100644
--- a/hw/vfio-user/proxy.c
+++ b/hw/vfio-user/proxy.c
@@ -683,8 +683,8 @@ void vfio_user_send_wait(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
/*
* async send - msg can be queued, but will be freed when sent
*/
-static void vfio_user_send_async(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
- VFIOUserFDs *fds)
+void vfio_user_send_async(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
+ VFIOUserFDs *fds)
{
VFIOUserMsg *msg;
int ret;
@@ -805,6 +805,14 @@ void vfio_user_putfds(VFIOUserMsg *msg)
msg->fds = NULL;
}
+void
+vfio_user_disable_posted_writes(VFIOUserProxy *proxy)
+{
+ WITH_QEMU_LOCK_GUARD(&proxy->lock) {
+ proxy->flags |= VFIO_PROXY_NO_POST;
+ }
+}
+
static QLIST_HEAD(, VFIOUserProxy) vfio_user_sockets =
QLIST_HEAD_INITIALIZER(vfio_user_sockets);
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 22/23] vfio-user: add coalesced posted writes
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (20 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 21/23] vfio-user: support posted writes John Levon
@ 2025-06-07 0:10 ` 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
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon, John Johnson,
Elena Ufimtseva, Jagannathan Raman
Add new message to send multiple writes to server in a single message.
Prevents the outgoing queue from overflowing when a long latency
operation is followed by a series of posted writes.
Originally-by: John Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John Levon <john.levon@nutanix.com>
---
hw/vfio-user/protocol.h | 21 ++++++++++
hw/vfio-user/proxy.h | 12 ++++++
hw/vfio-user/device.c | 40 +++++++++++++++++++
hw/vfio-user/proxy.c | 84 +++++++++++++++++++++++++++++++++++++++
hw/vfio-user/trace-events | 1 +
5 files changed, 158 insertions(+)
diff --git a/hw/vfio-user/protocol.h b/hw/vfio-user/protocol.h
index 8f589faef4..f747e70e50 100644
--- a/hw/vfio-user/protocol.h
+++ b/hw/vfio-user/protocol.h
@@ -42,6 +42,7 @@ enum vfio_user_command {
VFIO_USER_DMA_WRITE = 12,
VFIO_USER_DEVICE_RESET = 13,
VFIO_USER_DIRTY_PAGES = 14,
+ VFIO_USER_REGION_WRITE_MULTI = 15,
VFIO_USER_MAX,
};
@@ -75,6 +76,7 @@ typedef struct {
#define VFIO_USER_CAP_PGSIZES "pgsizes"
#define VFIO_USER_CAP_MAP_MAX "max_dma_maps"
#define VFIO_USER_CAP_MIGR "migration"
+#define VFIO_USER_CAP_MULTI "write_multiple"
/* "migration" members */
#define VFIO_USER_CAP_PGSIZE "pgsize"
@@ -221,4 +223,23 @@ typedef struct {
char data[];
} VFIOUserBitmap;
+/*
+ * VFIO_USER_REGION_WRITE_MULTI
+ */
+#define VFIO_USER_MULTI_DATA 8
+#define VFIO_USER_MULTI_MAX 200
+
+typedef struct {
+ uint64_t offset;
+ uint32_t region;
+ uint32_t count;
+ char data[VFIO_USER_MULTI_DATA];
+} VFIOUserWROne;
+
+typedef struct {
+ VFIOUserHdr hdr;
+ uint64_t wr_cnt;
+ VFIOUserWROne wrs[VFIO_USER_MULTI_MAX];
+} VFIOUserWRMulti;
+
#endif /* VFIO_USER_PROTOCOL_H */
diff --git a/hw/vfio-user/proxy.h b/hw/vfio-user/proxy.h
index 22ed66c54f..ae09b9cc60 100644
--- a/hw/vfio-user/proxy.h
+++ b/hw/vfio-user/proxy.h
@@ -88,6 +88,8 @@ typedef struct VFIOUserProxy {
VFIOUserMsg *last_nowait;
VFIOUserMsg *part_recv;
size_t recv_left;
+ VFIOUserWRMulti *wr_multi;
+ int num_outgoing;
enum proxy_state state;
} VFIOUserProxy;
@@ -95,6 +97,11 @@ typedef struct VFIOUserProxy {
#define VFIO_PROXY_CLIENT 0x1
#define VFIO_PROXY_FORCE_QUEUED 0x4
#define VFIO_PROXY_NO_POST 0x8
+#define VFIO_PROXY_USE_MULTI 0x16
+
+/* coalescing high and low water marks for VFIOProxy num_outgoing */
+#define VFIO_USER_OUT_HIGH 1024
+#define VFIO_USER_OUT_LOW 128
typedef struct VFIODevice VFIODevice;
@@ -122,4 +129,9 @@ void vfio_user_send_async(VFIOUserProxy *proxy, VFIOUserHdr *hdr,
void vfio_user_send_reply(VFIOUserProxy *proxy, VFIOUserHdr *hdr, int size);
void vfio_user_send_error(VFIOUserProxy *proxy, VFIOUserHdr *hdr, int error);
+void vfio_user_flush_multi(VFIOUserProxy *proxy);
+void vfio_user_create_multi(VFIOUserProxy *proxy);
+void vfio_user_add_multi(VFIOUserProxy *proxy, uint8_t index,
+ off_t offset, uint32_t count, void *data);
+
#endif /* VFIO_USER_PROXY_H */
diff --git a/hw/vfio-user/device.c b/hw/vfio-user/device.c
index eb2194c0eb..79375ddc96 100644
--- a/hw/vfio-user/device.c
+++ b/hw/vfio-user/device.c
@@ -10,6 +10,8 @@
*/
#include "qemu/osdep.h"
+#include "qemu/lockable.h"
+#include "qemu/thread.h"
#include "hw/vfio-user/device.h"
#include "hw/vfio-user/trace.h"
@@ -296,6 +298,7 @@ static int vfio_user_device_io_region_write(VFIODevice *vbasedev, uint8_t index,
VFIOUserRegionRW *msgp = NULL;
VFIOUserProxy *proxy = vbasedev->proxy;
int size = sizeof(*msgp) + count;
+ bool can_multi;
int flags = 0;
int ret;
@@ -311,6 +314,43 @@ static int vfio_user_device_io_region_write(VFIODevice *vbasedev, uint8_t index,
flags |= VFIO_USER_NO_REPLY;
}
+ /* write eligible to be in a WRITE_MULTI msg ? */
+ can_multi = (proxy->flags & VFIO_PROXY_USE_MULTI) && post &&
+ count <= VFIO_USER_MULTI_DATA;
+
+ /*
+ * This should be a rare case, so first check without the lock,
+ * if we're wrong, vfio_send_queued() will flush any posted writes
+ * we missed here
+ */
+ if (proxy->wr_multi != NULL ||
+ (proxy->num_outgoing > VFIO_USER_OUT_HIGH && can_multi)) {
+
+ /*
+ * re-check with lock
+ *
+ * if already building a WRITE_MULTI msg,
+ * add this one if possible else flush pending before
+ * sending the current one
+ *
+ * else if outgoing queue is over the highwater,
+ * start a new WRITE_MULTI message
+ */
+ WITH_QEMU_LOCK_GUARD(&proxy->lock) {
+ if (proxy->wr_multi != NULL) {
+ if (can_multi) {
+ vfio_user_add_multi(proxy, index, off, count, data);
+ return count;
+ }
+ vfio_user_flush_multi(proxy);
+ } else if (proxy->num_outgoing > VFIO_USER_OUT_HIGH && can_multi) {
+ vfio_user_create_multi(proxy);
+ vfio_user_add_multi(proxy, index, off, count, data);
+ return count;
+ }
+ }
+ }
+
msgp = g_malloc0(size);
vfio_user_request_msg(&msgp->hdr, VFIO_USER_REGION_WRITE, size, flags);
msgp->offset = off;
diff --git a/hw/vfio-user/proxy.c b/hw/vfio-user/proxy.c
index 13f2407845..dbaa322952 100644
--- a/hw/vfio-user/proxy.c
+++ b/hw/vfio-user/proxy.c
@@ -16,12 +16,14 @@
#include "hw/vfio-user/proxy.h"
#include "hw/vfio-user/trace.h"
#include "qapi/error.h"
+#include "qobject/qbool.h"
#include "qobject/qdict.h"
#include "qobject/qjson.h"
#include "qobject/qnum.h"
#include "qemu/error-report.h"
#include "qemu/lockable.h"
#include "qemu/main-loop.h"
+#include "qemu/thread.h"
#include "system/iothread.h"
static IOThread *vfio_user_iothread;
@@ -444,6 +446,11 @@ static void vfio_user_send(void *opaque)
}
qio_channel_set_aio_fd_handler(proxy->ioc, proxy->ctx,
vfio_user_recv, NULL, NULL, proxy);
+
+ /* queue empty - send any pending multi write msgs */
+ if (proxy->wr_multi != NULL) {
+ vfio_user_flush_multi(proxy);
+ }
}
}
@@ -464,6 +471,7 @@ static int vfio_user_send_one(VFIOUserProxy *proxy)
}
QTAILQ_REMOVE(&proxy->outgoing, msg, next);
+ proxy->num_outgoing--;
if (msg->type == VFIO_MSG_ASYNC) {
vfio_user_recycle(proxy, msg);
} else {
@@ -571,11 +579,18 @@ static int vfio_user_send_queued(VFIOUserProxy *proxy, VFIOUserMsg *msg)
{
int ret;
+ /* older coalesced writes go first */
+ if (proxy->wr_multi != NULL &&
+ ((msg->hdr->flags & VFIO_USER_TYPE) == VFIO_USER_REQUEST)) {
+ vfio_user_flush_multi(proxy);
+ }
+
/*
* Unsent outgoing msgs - add to tail
*/
if (!QTAILQ_EMPTY(&proxy->outgoing)) {
QTAILQ_INSERT_TAIL(&proxy->outgoing, msg, next);
+ proxy->num_outgoing++;
return 0;
}
@@ -589,6 +604,7 @@ static int vfio_user_send_queued(VFIOUserProxy *proxy, VFIOUserMsg *msg)
}
if (ret == QIO_CHANNEL_ERR_BLOCK) {
QTAILQ_INSERT_HEAD(&proxy->outgoing, msg, next);
+ proxy->num_outgoing = 1;
qio_channel_set_aio_fd_handler(proxy->ioc, proxy->ctx,
vfio_user_recv, proxy->ctx,
vfio_user_send, proxy);
@@ -1112,12 +1128,27 @@ static bool check_migr(VFIOUserProxy *proxy, QObject *qobj, Error **errp)
return caps_parse(proxy, qdict, caps_migr, errp);
}
+static bool check_multi(VFIOUserProxy *proxy, QObject *qobj, Error **errp)
+{
+ QBool *qb = qobject_to(QBool, qobj);
+
+ if (qb == NULL) {
+ error_setg(errp, "malformed %s", VFIO_USER_CAP_MULTI);
+ return false;
+ }
+ if (qbool_get_bool(qb)) {
+ proxy->flags |= VFIO_PROXY_USE_MULTI;
+ }
+ return true;
+}
+
static struct cap_entry caps_cap[] = {
{ VFIO_USER_CAP_MAX_FDS, check_max_fds },
{ VFIO_USER_CAP_MAX_XFER, check_max_xfer },
{ VFIO_USER_CAP_PGSIZES, check_pgsizes },
{ VFIO_USER_CAP_MAP_MAX, check_max_dma },
{ VFIO_USER_CAP_MIGR, check_migr },
+ { VFIO_USER_CAP_MULTI, check_multi },
{ NULL }
};
@@ -1176,6 +1207,7 @@ static GString *caps_json(void)
qdict_put_int(capdict, VFIO_USER_CAP_MAX_XFER, VFIO_USER_DEF_MAX_XFER);
qdict_put_int(capdict, VFIO_USER_CAP_PGSIZES, VFIO_USER_DEF_PGSIZE);
qdict_put_int(capdict, VFIO_USER_CAP_MAP_MAX, VFIO_USER_DEF_MAP_MAX);
+ qdict_put_bool(capdict, VFIO_USER_CAP_MULTI, true);
qdict_put_obj(dict, VFIO_USER_CAP, QOBJECT(capdict));
@@ -1228,3 +1260,55 @@ bool vfio_user_validate_version(VFIOUserProxy *proxy, Error **errp)
trace_vfio_user_version(msgp->major, msgp->minor, msgp->capabilities);
return true;
}
+
+void vfio_user_flush_multi(VFIOUserProxy *proxy)
+{
+ VFIOUserMsg *msg;
+ VFIOUserWRMulti *wm = proxy->wr_multi;
+ int ret;
+
+ proxy->wr_multi = NULL;
+
+ /* adjust size for actual # of writes */
+ wm->hdr.size -= (VFIO_USER_MULTI_MAX - wm->wr_cnt) * sizeof(VFIOUserWROne);
+
+ msg = vfio_user_getmsg(proxy, &wm->hdr, NULL);
+ msg->id = wm->hdr.id;
+ msg->rsize = 0;
+ msg->type = VFIO_MSG_ASYNC;
+ trace_vfio_user_wrmulti("flush", wm->wr_cnt);
+
+ ret = vfio_user_send_queued(proxy, msg);
+ if (ret < 0) {
+ vfio_user_recycle(proxy, msg);
+ }
+}
+
+void vfio_user_create_multi(VFIOUserProxy *proxy)
+{
+ VFIOUserWRMulti *wm;
+
+ wm = g_malloc0(sizeof(*wm));
+ vfio_user_request_msg(&wm->hdr, VFIO_USER_REGION_WRITE_MULTI,
+ sizeof(*wm), VFIO_USER_NO_REPLY);
+ proxy->wr_multi = wm;
+}
+
+void vfio_user_add_multi(VFIOUserProxy *proxy, uint8_t index,
+ off_t offset, uint32_t count, void *data)
+{
+ VFIOUserWRMulti *wm = proxy->wr_multi;
+ VFIOUserWROne *w1 = &wm->wrs[wm->wr_cnt];
+
+ w1->offset = offset;
+ w1->region = index;
+ w1->count = count;
+ memcpy(&w1->data, data, count);
+
+ wm->wr_cnt++;
+ trace_vfio_user_wrmulti("add", wm->wr_cnt);
+ if (wm->wr_cnt == VFIO_USER_MULTI_MAX ||
+ proxy->num_outgoing < VFIO_USER_OUT_LOW) {
+ vfio_user_flush_multi(proxy);
+ }
+}
diff --git a/hw/vfio-user/trace-events b/hw/vfio-user/trace-events
index 7ef98813b3..64fac9137f 100644
--- a/hw/vfio-user/trace-events
+++ b/hw/vfio-user/trace-events
@@ -11,6 +11,7 @@ vfio_user_get_region_info(uint32_t index, uint32_t flags, uint64_t size) " index
vfio_user_region_rw(uint32_t region, uint64_t off, uint32_t count) " region %d offset 0x%"PRIx64" count %d"
vfio_user_get_irq_info(uint32_t index, uint32_t flags, uint32_t count) " index %d flags 0x%x count %d"
vfio_user_set_irqs(uint32_t index, uint32_t start, uint32_t count, uint32_t flags) " index %d start %d count %d flags 0x%x"
+vfio_user_wrmulti(const char *s, uint64_t wr_cnt) " %s count 0x%"PRIx64
# container.c
vfio_user_dma_map(uint64_t iova, uint64_t size, uint64_t off, uint32_t flags, bool async_ops) " iova 0x%"PRIx64" size 0x%"PRIx64" off 0x%"PRIx64" flags 0x%x async_ops %d"
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH v3 23/23] docs: add vfio-user documentation
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (21 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 22/23] vfio-user: add coalesced " John Levon
@ 2025-06-07 0:10 ` John Levon
2025-06-12 6:57 ` [PATCH v3 00/23] vfio-user client Cédric Le Goater
23 siblings, 0 replies; 69+ messages in thread
From: John Levon @ 2025-06-07 0:10 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson, Cédric Le Goater,
Philippe Mathieu-Daudé, John Levon
Add some basic documentation on vfio-user usage.
Signed-off-by: John Levon <john.levon@nutanix.com>
---
docs/system/device-emulation.rst | 1 +
docs/system/devices/vfio-user.rst | 24 ++++++++++++++++++++++++
2 files changed, 25 insertions(+)
create mode 100644 docs/system/devices/vfio-user.rst
diff --git a/docs/system/device-emulation.rst b/docs/system/device-emulation.rst
index a1b0d7997e..911381643f 100644
--- a/docs/system/device-emulation.rst
+++ b/docs/system/device-emulation.rst
@@ -85,6 +85,7 @@ Emulated Devices
devices/can.rst
devices/ccid.rst
devices/cxl.rst
+ devices/vfio-user.rst
devices/ivshmem.rst
devices/ivshmem-flat.rst
devices/keyboard.rst
diff --git a/docs/system/devices/vfio-user.rst b/docs/system/devices/vfio-user.rst
new file mode 100644
index 0000000000..e33e49d283
--- /dev/null
+++ b/docs/system/devices/vfio-user.rst
@@ -0,0 +1,24 @@
+=========
+vfio-user
+=========
+
+QEMU includes a ``vfio-user`` client. The ``vfio-user`` specification allows for
+implementing (PCI) devices in userspace outside of QEMU; it is similar to
+``vhost-user`` in this respect (see :doc:`vhost-user`), but can emulate arbitrary
+PCI devices, not just ``virtio``. Whereas ``vfio`` is handled by the host
+kernel, ``vfio-user``, while similar in implementation, is handled entirely in
+userspace.
+
+For example, SPDK includes a virtual PCI NVMe controller implementation; by
+setting up a ``vfio-user`` UNIX socket between QEMU and SPDK, a VM can send NVMe
+I/O to the SPDK process.
+
+Presuming a suitable ``vfio-user`` server has opened a socket at
+``/tmp/vfio-user.sock``, a device can be configured with for example:
+
+.. code-block:: console
+
+-device vfio-user-pci,socket=/tmp/vfio-user.sock,bus=pcie.0,addr=0x9
+
+See `libvfio-user <https://github.com/nutanix/libvfio-user/>`_ for further
+information.
--
2.43.0
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH v3 00/23] vfio-user client
2025-06-07 0:10 [PATCH v3 00/23] vfio-user client John Levon
` (22 preceding siblings ...)
2025-06-07 0:10 ` [PATCH v3 23/23] docs: add vfio-user documentation John Levon
@ 2025-06-12 6:57 ` Cédric Le Goater
2025-06-12 14:19 ` John Levon
23 siblings, 1 reply; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-12 6:57 UTC (permalink / raw)
To: John Levon, qemu-devel
Cc: Daniel P. Berrangé, Paolo Bonzini, Thanos Makatos,
Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, Mark Cave-Ayland
John,
On 6/7/25 02:10, John Levon wrote:
> The series contains an implement of a vfio-user client in QEMU, along with a few
> more preparatory patches.
>
> The vfio-user protocol allows for implementing (PCI) devices in another
> userspace process; SPDK is one example, which includes a virtual NVMe
> implementation.
>
> The vfio-user framework consists of 3 parts:
> 1) The VFIO user protocol specification.
> 2) A client - the VFIO device in QEMU that encapsulates VFIO messages
> and sends them to the server.
> 3) A server - a remote process that emulates a device.
>
> This patchset implements parts 1 and 2.
>
> It has been tested against libvfio-user test servers as well as SPDK.
Is libvfio-user a server-only library ? It seems a bit odd not to use it
on the client side. Anyhow,
We have now merged upstream all the prerequisite changes for vfio-user.
This gives us about 1 month to fix regressions and merge the model for
the vfio-user-pci device, its documentation and tests.
I *really* would prefer if we had functional tests although I don't how
complex it would be. At least an initial framework would be good to have.
More sophisticated scenarios, such as mappings and interrupts, can come
later.
Thanks,
C.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v3 00/23] vfio-user client
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
0 siblings, 1 reply; 69+ messages in thread
From: John Levon @ 2025-06-12 14:19 UTC (permalink / raw)
To: Cédric Le Goater
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, Mark Cave-Ayland
On Thu, Jun 12, 2025 at 08:57:54AM +0200, Cédric Le Goater wrote:
> On 6/7/25 02:10, John Levon wrote:
> > The series contains an implement of a vfio-user client in QEMU, along with a few
> > more preparatory patches.
> >
> > The vfio-user protocol allows for implementing (PCI) devices in another
> > userspace process; SPDK is one example, which includes a virtual NVMe
> > implementation.
> >
> > The vfio-user framework consists of 3 parts:
> > 1) The VFIO user protocol specification.
> > 2) A client - the VFIO device in QEMU that encapsulates VFIO messages
> > and sends them to the server.
> > 3) A server - a remote process that emulates a device.
> >
> > This patchset implements parts 1 and 2.
> >
> > It has been tested against libvfio-user test servers as well as SPDK.
>
> Is libvfio-user a server-only library ?
Yes.
>It seems a bit odd not to use it on the client side.
I wasn't around for any original discussion here, so don't have context, but
there are two clients I know of today: qemu and cloud-hypervisor. The latter is
in Rust, and the former is opinionated enough that I'm not sure the message
handling part (the only useful bit of the library here) would be a good match.
Also I rather like having more than one implementation of a protocol, anyway.
> I *really* would prefer if we had functional tests although I don't how
I agree it makes sense to have a working functional test before merging.
In the meantime, I would like to continue with review of the main chunk - as you
said, there's a lot of code. I've not made substantial changes since v3 (only
the comments so far), so I'm happy to continue with v3 review, or if you prefer,
I can send out v4 against master. Please let me know.
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 00/23] vfio-user client
2025-06-12 14:19 ` John Levon
@ 2025-06-19 11:56 ` Cédric Le Goater
2025-06-20 8:20 ` Mark Cave-Ayland
0 siblings, 1 reply; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-19 11:56 UTC (permalink / raw)
To: John Levon
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé, Mark Cave-Ayland
Hi John,
>> I *really* would prefer if we had functional tests although I don't how
>
> I agree it makes sense to have a working functional test before merging.
Any progress ?
> In the meantime, I would like to continue with review of the main chunk - as you
> said, there's a lot of code. I've not made substantial changes since v3 (only
> the comments so far), so I'm happy to continue with v3 review, or if you prefer,
> I can send out v4 against master. Please let me know.
I doubt we will have much more reviews on the vfio-user part. Can you
please send v4 ?
Thanks,
C.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 00/23] vfio-user client
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
0 siblings, 1 reply; 69+ messages in thread
From: Mark Cave-Ayland @ 2025-06-20 8:20 UTC (permalink / raw)
To: Cédric Le Goater, John Levon
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 19/06/2025 12:56, Cédric Le Goater wrote:
> Hi John,
>
>>> I *really* would prefer if we had functional tests although I don't how
>>
>> I agree it makes sense to have a working functional test before merging.
>
> Any progress ?
I've had to look at some other bits and pieces this week, but the basic
status is sadly still unchanged - I have a test with 2 VMs, a client and
server, that works fine when run by hand yet hangs when run within the
functional test framework.
I do now have a VM with lots of extra debugging installed, but figuring
out why I see these hangs is proving to be quite time intensive. If we
could point you towards a manual image and some scripts, would that be
sufficient for now?
>> In the meantime, I would like to continue with review of the main
>> chunk - as you
>> said, there's a lot of code. I've not made substantial changes since
>> v3 (only
>> the comments so far), so I'm happy to continue with v3 review, or if
>> you prefer,
>> I can send out v4 against master. Please let me know.
>
> I doubt we will have much more reviews on the vfio-user part. Can you
> please send v4 ?
ATB,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 00/23] vfio-user client
2025-06-20 8:20 ` Mark Cave-Ayland
@ 2025-06-20 8:32 ` Cédric Le Goater
2025-06-21 12:22 ` John Levon
0 siblings, 1 reply; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-20 8:32 UTC (permalink / raw)
To: Mark Cave-Ayland, John Levon
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
Hello Mark,
On 6/20/25 10:20, Mark Cave-Ayland wrote:
> On 19/06/2025 12:56, Cédric Le Goater wrote:
>
>> Hi John,
>>
>>>> I *really* would prefer if we had functional tests although I don't how
>>>
>>> I agree it makes sense to have a working functional test before merging.
>>
>> Any progress ?
>
> I've had to look at some other bits and pieces this week, but the basic status is sadly still unchanged - I have a test with 2 VMs, a client and server, that works fine when run by hand yet hangs when run within the functional test framework.
>
> I do now have a VM with lots of extra debugging installed, but figuring out why I see these hangs is proving to be quite time intensive. If we could point you towards a manual image and some scripts, would that be sufficient for now?
Before merging, I would like to be able to experiment a minimum.
Does a dummy device (server side) implementation exist ? and a
GH repo I could pull the code from.
John,
How do you test ?
Thanks,
C.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 00/23] vfio-user client
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
0 siblings, 1 reply; 69+ messages in thread
From: John Levon @ 2025-06-21 12:22 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Mark Cave-Ayland, qemu-devel, Daniel P. Berrangé,
Paolo Bonzini, Thanos Makatos, Marc-André Lureau,
Alex Williamson, Philippe Mathieu-Daudé
On Fri, Jun 20, 2025 at 10:32:10AM +0200, Cédric Le Goater wrote:
> Before merging, I would like to be able to experiment a minimum.
>
> Does a dummy device (server side) implementation exist ? and a
> GH repo I could pull the code from.
>
> John,
>
> How do you test ?
I use these scripts for smoke-testing:
https://github.com/jlevon/grot/blob/master/tests/vfio-user/run.sh
is easiest - you just need to compile libvfio-user and qemu
and you should be good if you have a suitable Linux image.
See https://github.com/nutanix/libvfio-user/blob/master/docs/qemu.md
if you need an image that has the relevant kernel module, and for some basic
testing instructions.
https://github.com/jlevon/grot/blob/master/tests/vfio-user/spdk-run.sh
is a more complete test - covers mmaps both ways etc. You can test this by
interacting with the vNVMe device inside your VM.
See https://github.com/nutanix/libvfio-user/blob/master/docs/spdk.md
The qemu and live migration sections there are obviously stale.
Please let me know if you hit problems.
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 00/23] vfio-user client
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:09 ` Mark Cave-Ayland
0 siblings, 2 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-22 12:57 UTC (permalink / raw)
To: John Levon
Cc: Mark Cave-Ayland, qemu-devel, Daniel P. Berrangé,
Paolo Bonzini, Thanos Makatos, Marc-André Lureau,
Alex Williamson, Philippe Mathieu-Daudé
Hello,
On 6/21/25 14:22, John Levon wrote:
> On Fri, Jun 20, 2025 at 10:32:10AM +0200, Cédric Le Goater wrote:
>
>> Before merging, I would like to be able to experiment a minimum.
>>
>> Does a dummy device (server side) implementation exist ? and a
>> GH repo I could pull the code from.
>>
>> John,
>>
>> How do you test ?
>
> I use these scripts for smoke-testing:
>
> https://github.com/jlevon/grot/blob/master/tests/vfio-user/run.sh
> is easiest - you just need to compile libvfio-user and qemu
> and you should be good if you have a suitable Linux image.
PCI enumeration work but the kernel module won't load on ubuntu 24.04
and 25.04 :
root@ubuntu:~# lspci -s 00:0d.0 -k -vv
00:0d.0 Non-VGA unclassified device: ACCES I/O Products, Inc. PCI-IDIO-16 Isolated Digital Input / FET Output Card
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 21
Region 2: I/O ports at 6000 [size=256]
Kernel modules: gpio_pci_idio_16
root@ubuntu:~# dmesg | grep 0000:00:0d.0
[ 0.381550] pci 0000:00:0d.0: [494f:0dc8] type 00 class 0x000000 conventional PCI endpoint
[ 0.382696] pci 0000:00:0d.0: BAR 2 [io 0x6000-0x60ff]
[ 4.017654] pci-idio-16 0000:00:0d.0: error -EINVAL: Unable to initialize register map
[ 4.027063] pci-idio-16 0000:00:0d.0: probe with driver pci-idio-16 failed with error -22
Any idea why ?
>
> See https://github.com/nutanix/libvfio-user/blob/master/docs/qemu.md
> if you need an image that has the relevant kernel module, and for some basic
> testing instructions.
>
> https://github.com/jlevon/grot/blob/master/tests/vfio-user/spdk-run.sh
> is a more complete test - covers mmaps both ways etc. You can test this by
> interacting with the vNVMe device inside your VM.
>
> See https://github.com/nutanix/libvfio-user/blob/master/docs/spdk.md
I didn't try SPDK yet.
Thanks,
C.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 00/23] vfio-user client
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
1 sibling, 1 reply; 69+ messages in thread
From: John Levon @ 2025-06-23 8:36 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Mark Cave-Ayland, qemu-devel, Daniel P. Berrangé,
Paolo Bonzini, Thanos Makatos, Marc-André Lureau,
Alex Williamson, Philippe Mathieu-Daudé
On Sun, Jun 22, 2025 at 02:57:57PM +0200, Cédric Le Goater wrote:
> PCI enumeration work but the kernel module won't load on ubuntu 24.04
Sorry, I forgot - there's a kernel bug in the Ubuntu LTS kernel for this driver.
Mark has a fix - Mark, can you share?
regards
john
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 00/23] vfio-user client
2025-06-23 8:36 ` John Levon
@ 2025-06-23 16:14 ` Mark Cave-Ayland
0 siblings, 0 replies; 69+ messages in thread
From: Mark Cave-Ayland @ 2025-06-23 16:14 UTC (permalink / raw)
To: John Levon, Cédric Le Goater
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 23/06/2025 09:36, John Levon wrote:
> On Sun, Jun 22, 2025 at 02:57:57PM +0200, Cédric Le Goater wrote:
>
>> PCI enumeration work but the kernel module won't load on ubuntu 24.04
>
> Sorry, I forgot - there's a kernel bug in the Ubuntu LTS kernel for this driver.
> Mark has a fix - Mark, can you share?
I did have a bit of a dig into this a few weeks ago, and I think there
are at least 2 bugs related to recent changes to the kernel regmap code.
I was able to persuade the module to load with a couple of hacks, but I
think there was still something else required to get the basic test up
and running...
ATB,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 00/23] vfio-user client
2025-06-22 12:57 ` Cédric Le Goater
2025-06-23 8:36 ` John Levon
@ 2025-06-23 16:09 ` Mark Cave-Ayland
2025-06-23 17:06 ` Cédric Le Goater
1 sibling, 1 reply; 69+ messages in thread
From: Mark Cave-Ayland @ 2025-06-23 16:09 UTC (permalink / raw)
To: Cédric Le Goater, John Levon
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 22/06/2025 13:57, Cédric Le Goater wrote:
> Hello,
>
> On 6/21/25 14:22, John Levon wrote:
>> On Fri, Jun 20, 2025 at 10:32:10AM +0200, Cédric Le Goater wrote:
>>
>>> Before merging, I would like to be able to experiment a minimum.
>>>
>>> Does a dummy device (server side) implementation exist ? and a
>>> GH repo I could pull the code from.
>>>
>>> John,
>>>
>>> How do you test ?
>>
>> I use these scripts for smoke-testing:
>>
>> https://urldefense.proofpoint.com/v2/url?
>> u=https-3A__github.com_jlevon_grot_blob_master_tests_vfio-2Duser_run.sh&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c23RpsaH4D2MKyD3EPJTDa0BAxz6tV8aUJqVSoytEiY&m=V-sTFYIBuNsRDS6PAkkLHCjd5V2lvtIYfbhCV4BsWHxVWzLB_Dj21kOCZ_00B8wZ&s=ZZtYgH13tGNzKPUfKumHJno3qZjfUTg5z6GMJ_9o5so&e= is easiest - you just need to compile libvfio-user and qemu
>> and you should be good if you have a suitable Linux image.
>
> PCI enumeration work but the kernel module won't load on ubuntu 24.04
> and 25.04 :
>
> root@ubuntu:~# lspci -s 00:0d.0 -k -vv
> 00:0d.0 Non-VGA unclassified device: ACCES I/O Products, Inc. PCI-
> IDIO-16 Isolated Digital Input / FET Output Card
> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Interrupt: pin A routed to IRQ 21
> Region 2: I/O ports at 6000 [size=256]
> Kernel modules: gpio_pci_idio_16
>
> root@ubuntu:~# dmesg | grep 0000:00:0d.0
> [ 0.381550] pci 0000:00:0d.0: [494f:0dc8] type 00 class 0x000000
> conventional PCI endpoint
> [ 0.382696] pci 0000:00:0d.0: BAR 2 [io 0x6000-0x60ff]
> [ 4.017654] pci-idio-16 0000:00:0d.0: error -EINVAL: Unable to
> initialize register map
> [ 4.027063] pci-idio-16 0000:00:0d.0: probe with driver pci-idio-16
> failed with error -22
>
> Any idea why ?
Annoyingly this is because the gpio_pci_idio_16 module is currently
broken upstream :( The last LTS I was able to able to successfully test
here was 6.1, and so that's what I've used to generate my functional
test images.
ATB,
Mark.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3 00/23] vfio-user client
2025-06-23 16:09 ` Mark Cave-Ayland
@ 2025-06-23 17:06 ` Cédric Le Goater
0 siblings, 0 replies; 69+ messages in thread
From: Cédric Le Goater @ 2025-06-23 17:06 UTC (permalink / raw)
To: Mark Cave-Ayland, John Levon
Cc: qemu-devel, Daniel P. Berrangé, Paolo Bonzini,
Thanos Makatos, Marc-André Lureau, Alex Williamson,
Philippe Mathieu-Daudé
On 6/23/25 18:09, Mark Cave-Ayland wrote:
> On 22/06/2025 13:57, Cédric Le Goater wrote:
>
>> Hello,
>>
>> On 6/21/25 14:22, John Levon wrote:
>>> On Fri, Jun 20, 2025 at 10:32:10AM +0200, Cédric Le Goater wrote:
>>>
>>>> Before merging, I would like to be able to experiment a minimum.
>>>>
>>>> Does a dummy device (server side) implementation exist ? and a
>>>> GH repo I could pull the code from.
>>>>
>>>> John,
>>>>
>>>> How do you test ?
>>>
>>> I use these scripts for smoke-testing:
>>>
>>> https://urldefense.proofpoint.com/v2/url? u=https-3A__github.com_jlevon_grot_blob_master_tests_vfio-2Duser_run.sh&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c23RpsaH4D2MKyD3EPJTDa0BAxz6tV8aUJqVSoytEiY&m=V-sTFYIBuNsRDS6PAkkLHCjd5V2lvtIYfbhCV4BsWHxVWzLB_Dj21kOCZ_00B8wZ&s=ZZtYgH13tGNzKPUfKumHJno3qZjfUTg5z6GMJ_9o5so&e= is easiest - you just need to compile libvfio-user and qemu
>>> and you should be good if you have a suitable Linux image.
>>
>> PCI enumeration work but the kernel module won't load on ubuntu 24.04
>> and 25.04 :
>>
>> root@ubuntu:~# lspci -s 00:0d.0 -k -vv
>> 00:0d.0 Non-VGA unclassified device: ACCES I/O Products, Inc. PCI- IDIO-16 Isolated Digital Input / FET Output Card
>> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Interrupt: pin A routed to IRQ 21
>> Region 2: I/O ports at 6000 [size=256]
>> Kernel modules: gpio_pci_idio_16
>>
>> root@ubuntu:~# dmesg | grep 0000:00:0d.0
>> [ 0.381550] pci 0000:00:0d.0: [494f:0dc8] type 00 class 0x000000 conventional PCI endpoint
>> [ 0.382696] pci 0000:00:0d.0: BAR 2 [io 0x6000-0x60ff]
>> [ 4.017654] pci-idio-16 0000:00:0d.0: error -EINVAL: Unable to initialize register map
>> [ 4.027063] pci-idio-16 0000:00:0d.0: probe with driver pci-idio-16 failed with error -22
>>
>> Any idea why ?
>
> Annoyingly this is because the gpio_pci_idio_16 module is currently
> broken upstream :(
Is is a known issue ? the gpio_pci_idio_16 module seems well maintained.
> The last LTS I was able to able to successfully test here was 6.1,
> and so that's what I've used to generate my functional test images.
All seems to work fine with the debian-12-nocloud-amd64.qcow2 imageand the gpio-pci-idio-16 kmod is even provided by default.
It would be nice to be able generate some interrupts
Thanks,
C.
^ permalink raw reply [flat|nested] 69+ messages in thread