Message ID | 1461937456-22943-16-git-send-email-viktorin@rehivetech.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 80CAB5961; Fri, 29 Apr 2016 15:46:35 +0200 (CEST) Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16]) by dpdk.org (Postfix) with ESMTP id ACF015597 for <dev@dpdk.org>; Fri, 29 Apr 2016 15:46:20 +0200 (CEST) Received: from pcviktorin.fit.vutbr.cz (pcviktorin.fit.vutbr.cz [147.229.13.147]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3qxFND3yDlz7RT; Fri, 29 Apr 2016 15:46:20 +0200 (CEST) From: Jan Viktorin <viktorin@rehivetech.com> To: dev@dpdk.org Cc: Jan Viktorin <viktorin@rehivetech.com>, Anatoly Burakov <anatoly.burakov@intel.com>, David Marchand <david.marchand@6wind.com>, Keith Wiles <keith.wiles@intel.com>, Santosh Shukla <sshukla@mvista.com>, Stephen Hemminger <stephen@networkplumber.org> Date: Fri, 29 Apr 2016 15:44:16 +0200 Message-Id: <1461937456-22943-16-git-send-email-viktorin@rehivetech.com> X-Mailer: git-send-email 2.8.0 In-Reply-To: <1461937456-22943-1-git-send-email-viktorin@rehivetech.com> References: <1461937456-22943-1-git-send-email-viktorin@rehivetech.com> Subject: [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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Jan Viktorin
April 29, 2016, 1:44 p.m. UTC
We can now just OR the vfio_enabled sequentially and so adding new VFIO
subsystems (vfio_platform) is possible.
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
---
lib/librte_eal/linuxapp/eal/eal.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
Comments
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 <viktorin@rehivetech.com> > --- > 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) Thanks, Anatoly
Hello Anatoly, On Tue, 10 May 2016 11:50:23 +0000 "Burakov, Anatoly" <anatoly.burakov@intel.com> 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 <viktorin@rehivetech.com> > > --- > > 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
> > 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". OK fair enough :) I haven't yet tested the patchset itself, I'll report back if I get any issues. Thanks, Anatoly
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(); + } - if (pci_vfio_is_enabled()) { + if (vfio_enabled) { /* if we are primary process, create a thread to communicate with * secondary processes. the thread will use a socket to wait for