From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com [209.85.192.182]) by dpdk.org (Postfix) with ESMTP id 313EA28F2 for ; Fri, 26 Feb 2016 10:04:49 +0100 (CET) Received: by mail-pf0-f182.google.com with SMTP id e127so49082941pfe.3 for ; Fri, 26 Feb 2016 01:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mvista-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=+qRaSYY0/ub6cwvTGehKFSoiMMcwOTskJPq/9wKiaKI=; b=XabYJFAttJ3/t5PeUQocEnGNQzmluvK8k9wWsTCAswd6x6SXE0pAqVD5qNBrGpOss7 9IRi8yNGKoTacvzRPVnfvaI++YpPjlPm3jASwOzC3PqZyrdNz9NZnchiMYLRwKC2pGig tIGbhVl/HQZJFmPzeHpfLDTDlxO5BVsV7wrhunO0RJyRd33pDWQ9GEhA7BHivHFKvdGQ 8e47LbdJnbI5mj32QUemT1K7jF98ZqP2kSsjdDMXzjYSNbGxsSuL3iPYjd7l4/1O2AvP j3KhghZnnJ5aZ7KoWqs9/KUeCllvfC7wIYR22zf8sYaWqX8EEmgL4lKrnQn3v8Pole8R 8ORg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+qRaSYY0/ub6cwvTGehKFSoiMMcwOTskJPq/9wKiaKI=; b=l4HI9FW2U3/ZFEV2H/GPl6kJ0pFHsEJrJoZ1so5gg5wmsCHPm+IYtEkEfCFkvHylmq U3Qtti042EAIhSJ8Is8d0D1PiPgI4RihwHuHcvdHLz3ymXuvVmK60yIKbS41ngenCFJU fg4CDEzeuX0S+M4T3cDsLsnxHBuHnuYg+RJ8QcjsBjBZQR1bvXCQ0YtFJRZJTDLB2qWm 0apMya80i3X3Qwc80Yty5wMTjtF3ssa1oBCSDGE7AfGVSaNQbQrviAP7eyyB/7j0niN7 N0rNPU1JJo7euuxTMKv0i9VonNzIZhoJQJWw4jXiS0iEE4/HAN5uFUHHXmtOmCILD0EJ p+Fw== X-Gm-Message-State: AD7BkJLgvjUaQ541/PcR7uV3Kfr4TrUpX/wIsoskBP/6EnfyapjScfhrJpn6j10VmbRTcGF+xhZ54C4q3BN9/mgp MIME-Version: 1.0 X-Received: by 10.98.34.198 with SMTP id p67mr519853pfj.93.1456477488604; Fri, 26 Feb 2016 01:04:48 -0800 (PST) Received: by 10.66.12.132 with HTTP; Fri, 26 Feb 2016 01:04:48 -0800 (PST) In-Reply-To: References: <20160226022358.GG14300@yliu-dev.sh.intel.com> Date: Fri, 26 Feb 2016 14:34:48 +0530 Message-ID: From: Santosh Shukla To: "Xie, Huawei" Content-Type: text/plain; charset=UTF-8 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] virtio PMD is not working with master version X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 09:04:49 -0000 On Fri, Feb 26, 2016 at 2:14 PM, Xie, Huawei wrote: > On 2/26/2016 4:29 PM, David Marchand wrote: >> On Fri, Feb 26, 2016 at 3:23 AM, Yuanhan Liu >> wrote: >>> Mauricio, thanks for the testing and report. >>> >>> On Thu, Feb 25, 2016 at 02:30:18PM +0100, David Marchand wrote: >>>> >From the logs, I would say I broke uio_pci_generic since we are in >>>> "uio" case, but uio portio sysfs does not exist. >>>> virtio pmd fell back to ioports discovery before my change. >>> Maybe we can do same? > We shouldn't, :). I am now rebasing the patch to fix the issue that > virtio driver takes the virtio device blindly. > With the patch: > if driver is VFIO/UIO, and errors happens, returns without falling back > to IO port. Nice, This will be useful for non-x86 arch case, IO port is NA for non-x86 arch so falling back to IO port would always fail. so defaulting to IO port case is incorrect. IMO, not arch agnostic. > if no any kernel driver is managing the device, try IO port; otherwise > returns 1 to tell the layer we don't take over this device. > >> I suppose, but see below. >> >>> --- >>> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c b/lib/librte_eal/linuxapp/eal/eal_pci.c >>> index 4346973..579731c 100644 >>> --- a/lib/librte_eal/linuxapp/eal/eal_pci.c >>> +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c >>> @@ -685,12 +685,11 @@ int >>> rte_eal_pci_ioport_map(struct rte_pci_device *dev, int bar, >>> struct rte_pci_ioport *p) >>> { >>> - int ret; >>> + int ret = -1; >>> >>> switch (dev->kdrv) { >>> #ifdef VFIO_PRESENT >>> case RTE_KDRV_VFIO: >>> - ret = -1; >>> if (pci_vfio_is_enabled()) >>> ret = pci_vfio_ioport_map(dev, bar, p); >>> break; >>> @@ -700,14 +699,14 @@ rte_eal_pci_ioport_map(struct rte_pci_device *dev, int bar, >>> ret = pci_uio_ioport_map(dev, bar, p); >>> break; >>> default: >>> + break; >>> + } >>> + >>> #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686) >>> - /* special case for x86 ... */ >>> + /* special case for x86 ... */ >>> + if (ret) >>> ret = pci_ioport_map(dev, bar, p); >>> -#else >>> - ret = -1; >>> #endif >>> - break; >>> - } >> What if we are supposed to do vfio here, but for some reason init failed ? >> Next thing, we will call ioport_read in vfio context, but init went >> through the ioports parsing => boom ? >> >> Another issue is that when device is bound to a kernel driver (let's >> say virtio-pci here), then init will succeed and pmd will kick in the >> device registers. >> >> This special case should really be narrowed down to "uio" and "none" >> driver cases. >> >> >