From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bOpyB-0006ij-Sm for qemu-devel@nongnu.org; Sun, 17 Jul 2016 13:35:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bOpy8-0004yi-Oq for qemu-devel@nongnu.org; Sun, 17 Jul 2016 13:35:11 -0400 Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]:35316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bOpy8-0004xc-Hw for qemu-devel@nongnu.org; Sun, 17 Jul 2016 13:35:08 -0400 Received: by mail-wm0-x242.google.com with SMTP id i5so9419206wmg.2 for ; Sun, 17 Jul 2016 10:35:08 -0700 (PDT) Reply-To: marcel@redhat.com References: <20160715172951.4750.12047.stgit@gimli.home> From: Marcel Apfelbaum Message-ID: <578BC1C9.3000208@gmail.com> Date: Sun, 17 Jul 2016 20:35:05 +0300 MIME-Version: 1.0 In-Reply-To: <20160715172951.4750.12047.stgit@gimli.home> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] vfio/pci: Hide ARI capability List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: qemu-devel@nongnu.org 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 Thanks, Marcel > Signed-off-by: Alex Williamson > --- > 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: > >