From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 1E67F6938 for ; Tue, 10 May 2016 13:50:26 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 10 May 2016 04:50:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,604,1455004800"; d="scan'208";a="976441059" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga002.fm.intel.com with ESMTP; 10 May 2016 04:50:24 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.120]) by IRSMSX154.ger.corp.intel.com ([169.254.12.222]) with mapi id 14.03.0248.002; Tue, 10 May 2016 12:50:23 +0100 From: "Burakov, Anatoly" To: Jan Viktorin , "dev@dpdk.org" CC: David Marchand , "Wiles, Keith" , Santosh Shukla , "Stephen Hemminger" Thread-Topic: [PATCH 15/15] vfio: change VFIO init to be extendable Thread-Index: AQHRoh2HPD8BbQ5whEaoDODyztBXHJ+yH5vg Date: Tue, 10 May 2016 11:50:23 +0000 Message-ID: References: <1461937456-22943-1-git-send-email-viktorin@rehivetech.com> <1461937456-22943-16-git-send-email-viktorin@rehivetech.com> In-Reply-To: <1461937456-22943-16-git-send-email-viktorin@rehivetech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjNiZjMwNTMtYTI2Yi00MGNjLTk2ZmEtNDUxMDFlZjBkMmFlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InN5YXRDRlVYR3VDSDRpTzFuVHBFVkJIVzF4M1Y4MjkzSDZyeitVQTczYUU9In0= 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 11:50:27 -0000 Hi Jan, > We can now just OR the vfio_enabled sequentially and so adding new VFIO > subsystems (vfio_platform) is possible. >=20 > Signed-off-by: Jan Viktorin > --- > lib/librte_eal/linuxapp/eal/eal.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) >=20 > 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 stati= c > int rte_eal_vfio_setup(void) { > - if (internal_config.no_pci) > - return 0; > + int vfio_enabled =3D 0; >=20 > - pci_vfio_enable(); > + if (!internal_config.no_pci) { > + pci_vfio_enable(); > + vfio_enabled |=3D pci_vfio_is_enabled(); > + } Could there be a situation where we need to know if a particular VFIO subsy= stem is enabled? Do you think it's worth adding (e.g. vfio_enabled |=3D VFI= O_PCI_ENABLED or something)? (I don't imply it is necessary, just asking) Thanks, Anatoly