From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <tiwei.bie@intel.com>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
by dpdk.org (Postfix) with ESMTP id 1AADA2E41
for <dev@dpdk.org>; Mon, 20 Aug 2018 10:19:06 +0200 (CEST)
X-Amp-Result: UNSCANNABLE
X-Amp-File-Uploaded: False
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
20 Aug 2018 01:19:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.53,264,1531810800"; d="scan'208";a="74148047"
Received: from debian.sh.intel.com (HELO debian) ([10.67.104.194])
by FMSMGA003.fm.intel.com with ESMTP; 20 Aug 2018 01:18:49 -0700
Date: Mon, 20 Aug 2018 16:18:04 +0800
From: Tiwei Bie <tiwei.bie@intel.com>
To: Luca Boccassi <bluca@debian.org>
Cc: dev@dpdk.org, maxime.coquelin@redhat.com, zhihong.wang@intel.com,
bruce.richardson@intel.com, brian.russell@intl.att.com
Message-ID: <20180820081804.GA29806@debian>
References: <20180814143035.19640-1-bluca@debian.org>
<20180816184750.30843-1-bluca@debian.org>
<20180816184750.30843-2-bluca@debian.org>
<1534445383.5764.56.camel@debian.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1534445383.5764.56.camel@debian.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Subject: Re: [dpdk-dev] [PATCH 2/2] virtio: fix PCI config err handling
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Aug 2018 08:19:07 -0000
On Thu, Aug 16, 2018 at 07:49:43PM +0100, Luca Boccassi wrote:
> On Thu, 2018-08-16 at 19:47 +0100, Luca Boccassi wrote:
> > From: Brian Russell <brussell@brocade.com>
> >
> > In virtio_read_caps and vtpci_msix_detect, rte_pci_read_config
> > returns
> > the number of bytes read from PCI config or < 0 on error.
> > If less than the expected number of bytes are read then log the
> > failure and return rather than carrying on with garbage.
> >
> > Fixes: 6ba1f63b5ab0 ("virtio: support specification 1.0")
> >
> > Signed-off-by: Brian Russell <brussell@brocade.com>
> > Signed-off-by: Luca Boccassi <bluca@debian.org>
> > ---
> > v2: handle additional rte_pci_read_config incomplete reads
> >
> > drivers/net/virtio/virtio_pci.c | 35 +++++++++++++++++++++--------
> > ----
> > 1 file changed, 22 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/net/virtio/virtio_pci.c
> > b/drivers/net/virtio/virtio_pci.c
> > index 6bd22e54a6..ff6f96f361 100644
> > --- a/drivers/net/virtio/virtio_pci.c
> > +++ b/drivers/net/virtio/virtio_pci.c
> ...
> > @@ -610,9 +613,13 @@ virtio_read_caps(struct rte_pci_device *dev,
> > struct virtio_hw *hw)
> > hw->common_cfg = get_cfg_addr(dev, &cap);
> > break;
> > case VIRTIO_PCI_CAP_NOTIFY_CFG:
> > - rte_pci_read_config(dev, &hw-
> > >notify_off_multiplier,
> > - 4, pos + sizeof(cap));
> > - hw->notify_base = get_cfg_addr(dev, &cap);
> > + /* Avoid half-reads into hw */
> > + ret = rte_pci_read_config(dev, &multiplier,
> > 4,
> > + pos + sizeof(cap));
> > + if (ret == 4) {
> > + hw->notify_off_multiplier =
> > multiplier;
> > + hw->notify_base = get_cfg_addr(dev,
> > &cap);
> > + }
> > break;
> > case VIRTIO_PCI_CAP_DEVICE_CFG:
> > hw->dev_cfg = get_cfg_addr(dev, &cap);
>
> Tiwei: not 100% sure what's the best way to handle a failure here, this
> will avoid writing to *hw in case of errors. Let me know if this is OK.
My concern is about reading the virtio capability directly.
With this patch, it will give up reading other capabilities
when failed to read a full virtio PCI capability structure
(the returned bytes are less than the expected bytes) even
though when the capability it's reading isn't a virtio vendor
specific capability. I'm not quite sure whether it will bring
any bad consequence. How about just reading the first two
bytes first? Something like this:
https://github.com/freebsd/freebsd/blob/72445a41b3ff/sys/dev/pci/pci.c#L1491-L1497
Thanks