From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16]) by dpdk.org (Postfix) with ESMTP id 211549AEC for ; Tue, 10 May 2016 14:54:29 +0200 (CEST) Received: from jvn (dynamic-109-81-211-184.ipv4.broadband.iol.cz [109.81.211.184]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3r3zjJ50K9z5rK; Tue, 10 May 2016 14:54:28 +0200 (CEST) Date: Tue, 10 May 2016 14:54:32 +0200 From: Jan Viktorin To: "Burakov, Anatoly" Cc: "dev@dpdk.org" , David Marchand , "Wiles, Keith" , Santosh Shukla , "Stephen Hemminger" Message-ID: <20160510145432.759a35ff@jvn> In-Reply-To: References: <1461937456-22943-1-git-send-email-viktorin@rehivetech.com> <1461937456-22943-16-git-send-email-viktorin@rehivetech.com> Organization: RehiveTech X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 15/15] vfio: change VFIO init to be extendable 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, 10 May 2016 12:54:29 -0000 Hello Anatoly, On Tue, 10 May 2016 11:50:23 +0000 "Burakov, Anatoly" wrote: > Hi Jan, > > > We can now just OR the vfio_enabled sequentially and so adding new VFIO > > subsystems (vfio_platform) is possible. > > > > Signed-off-by: Jan Viktorin > > --- > > lib/librte_eal/linuxapp/eal/eal.c | 10 ++++++---- > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c > > index 92225cf..1549fe5 100644 > > --- a/lib/librte_eal/linuxapp/eal/eal.c > > +++ b/lib/librte_eal/linuxapp/eal/eal.c > > @@ -727,12 +727,14 @@ rte_eal_iopl_init(void) #ifdef VFIO_PRESENT static > > int rte_eal_vfio_setup(void) { > > - if (internal_config.no_pci) > > - return 0; > > + int vfio_enabled = 0; > > > > - pci_vfio_enable(); > > + if (!internal_config.no_pci) { > > + pci_vfio_enable(); > > + vfio_enabled |= pci_vfio_is_enabled(); > > + } > > Could there be a situation where we need to know if a particular VFIO subsystem is enabled? Do you think it's worth adding (e.g. vfio_enabled |= VFIO_PCI_ENABLED or something)? (I don't imply it is necessary, just asking) Well... the semantics are quite tricky here. There are: vfio-pci, vfio-platform and vfio-amba in the Linux Kernel. I ignore vfio-amba because I don't know any considerable device supported by this. With respect to the VFIO, if you have both PCI and SoC infra enabled, you have to check for both vfio-pci and vfio-platform. If only PCI is there you have to check only for vfio-pci. But, if you check for vfio-platform as well and it is not there then the EAL init would fail without a reason (because you don't need vfio-platform). Vice-versa for SoC. This patch improves the check to cover those situations. Later on, I'll just append something like: if (!internal_config.no_soc) { soc_vfio_enable(); vfio_enabled |= soc_vfio_is_enabled(); } and the EAL init would be happy... I hope ;). The thing is that we don't know which devices will bind to VFIO and we don't know which of those devices would use vfio-pci and vfio-platform. So, if both PCI and SoC are enabled and only vfio-platform is there we cannot say here "failed because vfio-pci is missing". Jan > > Thanks, > Anatoly -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic