From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <viktorin@rehivetech.com>
Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16])
by dpdk.org (Postfix) with ESMTP id 211549AEC
for <dev@dpdk.org>; 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 <viktorin@rehivetech.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, David Marchand
<david.marchand@6wind.com>, "Wiles, Keith" <keith.wiles@intel.com>, Santosh
Shukla <sshukla@mvista.com>, "Stephen Hemminger"
<stephen@networkplumber.org>
Message-ID: <20160510145432.759a35ff@jvn>
In-Reply-To: <C6ECDF3AB251BE4894318F4E451236978210B7DA@IRSMSX109.ger.corp.intel.com>
References: <1461937456-22943-1-git-send-email-viktorin@rehivetech.com>
<1461937456-22943-16-git-send-email-viktorin@rehivetech.com>
<C6ECDF3AB251BE4894318F4E451236978210B7DA@IRSMSX109.ger.corp.intel.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 <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>
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" <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
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic