From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 3DE4EDE3 for ; Tue, 22 Dec 2015 17:38:36 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP; 22 Dec 2015 08:38:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,465,1444719600"; d="scan'208";a="867470391" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga001.fm.intel.com with ESMTP; 22 Dec 2015 08:38:36 -0800 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 22 Dec 2015 08:38:33 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 22 Dec 2015 08:38:33 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.190]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.28]) with mapi id 14.03.0248.002; Wed, 23 Dec 2015 00:38:31 +0800 From: "Xie, Huawei" To: Peter Xu Thread-Topic: [dpdk-dev] [Question] How pmd virtio works without UIO? Thread-Index: AdE8piK6l8VXEhglRhmhlN1f6b8L3Q== Date: Tue, 22 Dec 2015 16:38:30 +0000 Message-ID: References: <20151222035041.GA7532@pxdev.xzpeter.org> <20151222070029.GO18863@yliu-dev.sh.intel.com> <20151222082338.GG7532@pxdev.xzpeter.org> <20151222083246.GT18863@yliu-dev.sh.intel.com> <20151222095641.GH7532@pxdev.xzpeter.org> <20151222113912.GA30780@pxdev.xzpeter.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DPDK Dev Subject: Re: [dpdk-dev] [Question] How pmd virtio works without UIO? 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: Tue, 22 Dec 2015 16:38:36 -0000 On 12/22/2015 7:39 PM, Peter Xu wrote:=0A= > On Tue, Dec 22, 2015 at 10:47:21AM +0000, Xie, Huawei wrote:=0A= >> On 12/22/2015 5:57 PM, Peter Xu wrote:=0A= >>> On Tue, Dec 22, 2015 at 04:32:46PM +0800, Yuanhan Liu wrote:=0A= >>>> Actually, you are right. I mentioned in the last email that this is=0A= >>>> for configuration part. To answer your question in this email, you=0A= >>>> will not be able to go that further (say initiating virtio pmd) if=0A= >>>> you don't unbind the origin virtio-net driver, and bind it to igb_uio= =0A= >>>> (or something similar).=0A= >>>>=0A= >>>> The start point is from rte_eal_pci_scan, where the sub-function=0A= >>>> pci_san_one just initates a DPDK bond driver.=0A= >>> I am not sure whether I do understand your meaning correctly=0A= >>> (regarding "you willl not be able to go that furture"): The problem=0A= >>> is that, we _can_ run testpmd without unbinding the ports and bind=0A= >>> to UIO or something. What we need to do is boot the guest, reserve=0A= >>> huge pages, and run testpmd (keeping its kernel driver as=0A= >>> "virtio-pci"). In pci_scan_one():=0A= >>>=0A= >>> if (!ret) {=0A= >>> if (!strcmp(driver, "vfio-pci"))=0A= >>> dev->kdrv =3D RTE_KDRV_VFIO;=0A= >>> else if (!strcmp(driver, "igb_uio"))=0A= >>> dev->kdrv =3D RTE_KDRV_IGB_UIO;=0A= >>> else if (!strcmp(driver, "uio_pci_generic"))=0A= >>> dev->kdrv =3D RTE_KDRV_UIO_GENERIC;=0A= >>> else=0A= >>> dev->kdrv =3D RTE_KDRV_UNKNOWN;=0A= >>> } else=0A= >>> dev->kdrv =3D RTE_KDRV_UNKNOWN;=0A= >>>=0A= >>> I think it should be going to RTE_KDRV_UNKNOWN=0A= >>> (driver=3D=3D"virtio-pci") here. I tried to run IO and it could work,= =0A= >>> but I am not sure whether it is safe, and how.=0A= >> Good catch, peter.=0A= >> Actually recently customers complain that with this feature, DPDK always= =0A= >> tries to take over this virtio-pci device, which is unwanted behavior.= =0A= >> Using blacklist could workaround this issue.=0A= >> However, the real serious problem is that kernel driver is still=0A= >> managing this device.=0A= >>=0A= >> Changchun, Thomas:=0A= >> I think we should fix this, but firstly i wonder why using port IO to=0A= >> get PCI resource is more secure.=0A= > I am not familiar with this, however, shouldn't port IO from=0A= > userspace the most dangerous way to access PCI resource?=0A= >=0A= >>> Also, I am not sure whether I need to (at least) unbind the=0A= >>> virtio-pci driver, so that there should have no kernel driver=0A= >>> running for the virtio device before DPDK using it.=0A= >> If you unbind, you have no entry under /proc/ioports for virtio IO port.= =0A= > I tried to unbind one of the virtio net device, I see the PCI entry=0A= > still there.=0A= >=0A= > Before unbind:=0A= >=0A= > [root@vm proc]# lspci -k -s 00:03.0=0A= > 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device=0A= > Subsystem: Red Hat, Inc Device 0001=0A= > Kernel driver in use: virtio-pci=0A= > [root@vm proc]# cat /proc/ioports | grep c060-c07f=0A= > c060-c07f : 0000:00:03.0=0A= > c060-c07f : virtio-pci=0A= >=0A= > After unbind:=0A= >=0A= > [root@vm proc]# lspci -k -s 00:03.0=0A= > 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device=0A= > Subsystem: Red Hat, Inc Device 0001=0A= > [root@vm proc]# cat /proc/ioports | grep c060-c07f=0A= > c060-c07f : 0000:00:03.0=0A= >=0A= > So... does this means that it is an alternative to black list=0A= > solution?=0A= Oh, we could firstly check if this port is manipulated by kernel driver=0A= in virtio_resource_init/eth_virtio_dev_init, as long as it is not too late.= =0A= >=0A= > Peter=0A= >=0A= >>> Thanks=0A= >>> Peter=0A= >>>=0A= >>>> --yliu=0A= =0A=