[Qemu-devel] [PATCH] vfio/pci: Hide ARI capability

[Qemu-devel] [PATCH] vfio/pci: Hide ARI capability

[Alex Williamson]

QEMU supports ARI on downstream ports and assigned devices may support
ARI in their extended capabilities.  The endpoint ARI capability
specifies the next function, such that the OS doesn't need to walk
each possible function, however this next function is relative to the
host, not the guest.  This leads to device discovery issues when we
combine separate functions into virtual multi-function packages in a
guest.  For example, SR-IOV VFs are not enumerated by simply probing
the function address space, therefore the ARI next-function field is
zero.  When we combine multiple VFs together as a multi-function
device in the guest, the guest OS identifies ARI is enabled, relies on
this next-function field, and stops looking for additional function
after the first is found.

Long term we should expose the ARI capability to the guest to enable
configurations with more than 8 functions per slot, but this requires
additional QEMU PCI infrastructure to manage the next-function field
for multiple, otherwise independent devices.  In the short term,
hiding this capability allows equivalent functionality to what we
currently have on non-express chipsets.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
 hw/vfio/pci.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 44783c5..c8436a1 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1828,6 +1828,7 @@ static int vfio_add_ext_cap(VFIOPCIDevice *vdev)
 
         switch (cap_id) {
         case PCI_EXT_CAP_ID_SRIOV: /* Read-only VF BARs confuse OVMF */
+        case PCI_EXT_CAP_ID_ARI: /* XXX Needs next function virtualization */
             trace_vfio_add_ext_cap_dropped(vdev->vbasedev.name, cap_id, next);
             break;
         default:

Re: [Qemu-devel] [PATCH] vfio/pci: Hide ARI capability

[Marcel Apfelbaum]

On 07/15/2016 08:30 PM, Alex Williamson wrote:
> QEMU supports ARI on downstream ports and assigned devices may support
> ARI in their extended capabilities.  The endpoint ARI capability
> specifies the next function, such that the OS doesn't need to walk
> each possible function, however this next function is relative to the
> host, not the guest.  This leads to device discovery issues when we
> combine separate functions into virtual multi-function packages in a
> guest.  For example, SR-IOV VFs are not enumerated by simply probing
> the function address space, therefore the ARI next-function field is
> zero.  When we combine multiple VFs together as a multi-function
> device in the guest, the guest OS identifies ARI is enabled, relies on
> this next-function field, and stops looking for additional function
> after the first is found.
>

Hi Alex,

> Long term we should expose the ARI capability to the guest to enable
> configurations with more than 8 functions per slot, but this requires
> additional QEMU PCI infrastructure to manage the next-function field
> for multiple, otherwise independent devices.

The ARI implementation is on my "to-do" list.

   In the short term,
> hiding this capability allows equivalent functionality to what we
> currently have on non-express chipsets.
>

I agree.

Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>

Thanks,
Marcel


> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
>   hw/vfio/pci.c |    1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 44783c5..c8436a1 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -1828,6 +1828,7 @@ static int vfio_add_ext_cap(VFIOPCIDevice *vdev)
>
>           switch (cap_id) {
>           case PCI_EXT_CAP_ID_SRIOV: /* Read-only VF BARs confuse OVMF */
> +        case PCI_EXT_CAP_ID_ARI: /* XXX Needs next function virtualization */
>               trace_vfio_add_ext_cap_dropped(vdev->vbasedev.name, cap_id, next);
>               break;
>           default:
>
>