Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752732AbaFLU3G (ORCPT ); Thu, 12 Jun 2014 16:29:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47379 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752268AbaFLU3D (ORCPT ); Thu, 12 Jun 2014 16:29:03 -0400 Message-ID: <1402604942.3707.17.camel@ul30vt.home> Subject: Re: [PATCH] vfio/pci: Add extra test for extended capabilities From: Alex Williamson To: Bandan Das Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Date: Thu, 12 Jun 2014 14:29:02 -0600 In-Reply-To: References: <20140612164349.9739.53824.stgit@bling.home> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2014-06-12 at 16:12 -0400, Bandan Das wrote: > Alex Williamson writes: > > > If the PCI core set cfg_size isn't large enough for extended > > capabilities, then they're not there. Extended config space may be > > inaccessible due to a PCI bridge, in which case cfg_size may be cut > > short. > > Just curious, is this part of the spec or just a convention ? I mean > could there be devices with quirks ? The PCIe bridge spec indicates that PCIe-to-PCI bridges should handle extended config accesses as an unsupported request. But as in 78916b00, we've seen that's not always the case. This just makes us trust PCI-core before the capabilities we find on the device. The current quirk in the referenced commit is for a relatively uncommon topology, but never rule out that we couldn't have a device quirked to avoid touching extended config space too. Thanks, Alex > > Signed-off-by: Alex Williamson > > --- > > drivers/vfio/pci/vfio_pci_config.c | 13 +++++++++---- > > 1 file changed, 9 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c > > index 83cd157..4a62a37 100644 > > --- a/drivers/vfio/pci/vfio_pci_config.c > > +++ b/drivers/vfio/pci/vfio_pci_config.c > > @@ -1027,8 +1027,11 @@ static int vfio_cap_len(struct vfio_pci_device *vdev, u8 cap, u8 pos) > > > > if (PCI_X_CMD_VERSION(word)) { > > /* Test for extended capabilities */ > > - pci_read_config_dword(pdev, PCI_CFG_SPACE_SIZE, &dword); > > - vdev->extended_caps = (dword != 0); > > + if (pdev->cfg_size > PCI_CFG_SPACE_SIZE) { > > + pci_read_config_dword(pdev, PCI_CFG_SPACE_SIZE, > > + &dword); > > + vdev->extended_caps = (dword != 0); > > + } > > return PCI_CAP_PCIX_SIZEOF_V2; > > } else > > return PCI_CAP_PCIX_SIZEOF_V0; > > @@ -1041,8 +1044,10 @@ static int vfio_cap_len(struct vfio_pci_device *vdev, u8 cap, u8 pos) > > return byte; > > case PCI_CAP_ID_EXP: > > /* Test for extended capabilities */ > > - pci_read_config_dword(pdev, PCI_CFG_SPACE_SIZE, &dword); > > - vdev->extended_caps = (dword != 0); > > + if (pdev->cfg_size > PCI_CFG_SPACE_SIZE) { > > + pci_read_config_dword(pdev, PCI_CFG_SPACE_SIZE, &dword); > > + vdev->extended_caps = (dword != 0); > > + } > > > > /* length based on version */ > > if ((pcie_caps_reg(pdev) & PCI_EXP_FLAGS_VERS) == 1) > > > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/