From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 0699F9AA0 for ; Tue, 10 May 2016 15:16:35 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 10 May 2016 06:16:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,604,1455004800"; d="scan'208";a="950009757" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga001.jf.intel.com with ESMTP; 10 May 2016 06:16:28 -0700 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 10 May 2016 14:15:45 +0100 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.120]) by irsmsx111.ger.corp.intel.com ([169.254.2.233]) with mapi id 14.03.0248.002; Tue, 10 May 2016 14:15:45 +0100 From: "Burakov, Anatoly" To: Jan Viktorin CC: "dev@dpdk.org" , David Marchand , "Wiles, Keith" , Santosh Shukla , Stephen Hemminger Thread-Topic: [PATCH 15/15] vfio: change VFIO init to be extendable Thread-Index: AQHRoh2HPD8BbQ5whEaoDODyztBXHJ+yH5vggAABlwCAABZtMA== Date: Tue, 10 May 2016 13:15:45 +0000 Message-ID: References: <1461937456-22943-1-git-send-email-viktorin@rehivetech.com> <1461937456-22943-16-git-send-email-viktorin@rehivetech.com> <20160510145432.759a35ff@jvn> In-Reply-To: <20160510145432.759a35ff@jvn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYmM1NGQ4ZjktYThhYi00ZTA5LWEwNDQtOTQ1YTBjMGM0YzYwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InI3UHE3TWh3ZlFMa0ZEd3hWYmE4ck55azBIRW9tNnYyODVxWFwvS1VwZFBRPSJ9 x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 13:16:38 -0000 > > 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 |=3D VFIO_PCI_ENABLED or something)? (I don't imply it is > > necessary, just asking) >=20 > Well... the semantics are quite tricky here. >=20 > There are: vfio-pci, vfio-platform and vfio-amba in the Linux Kernel. I i= gnore > vfio-amba because I don't know any considerable device supported by this. >=20 > 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. >=20 > 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. >=20 > This patch improves the check to cover those situations. Later on, I'll j= ust > append something like: >=20 > if (!internal_config.no_soc) { > soc_vfio_enable(); > vfio_enabled |=3D soc_vfio_is_enabled(); > } >=20 > and the EAL init would be happy... I hope ;). >=20 > The thing is that we don't know which devices will bind to VFIO and we do= n'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 ca= nnot > 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 iss= ues. Thanks, Anatoly