From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavan Nikhilesh Subject: Re: [PATCH v2 1/5] bus/fslmc: fix physical addressing check Date: Fri, 12 Oct 2018 21:59:00 +0530 Message-ID: <20181012162607.GA21825@wstn-pvn> References: <20180925125423.7505-1-shreyansh.jain@nxp.com> <20181009112548.7025-1-shreyansh.jain@nxp.com> <20181009112548.7025-2-shreyansh.jain@nxp.com> <20181012090142.GA15154@ltp-pvn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org To: Shreyansh Jain , anatoly.burakov@intel.com, hemant.agrawal@nxp.com, jkollanukkaran@caviumnetworks.com Return-path: Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700078.outbound.protection.outlook.com [40.107.70.78]) by dpdk.org (Postfix) with ESMTP id C02361BA8E for ; Fri, 12 Oct 2018 18:29:27 +0200 (CEST) Content-Disposition: inline In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Oct 12, 2018 at 04:14:36PM +0530, Shreyansh Jain wrote: > On Friday 12 October 2018 02:31 PM, Pavan Nikhilesh wrote: > > Hi Shreyansh, > > > > On Tue, Oct 09, 2018 at 04:55:44PM +0530, Shreyansh Jain wrote: > > > In case RTE_LIBRTE_DPAA2_USE_PHYS_IOVA is enabled, only supported > > > class is RTE_IOVA_PA. > > > > > > Fixes: f7768afac101 ("bus/fslmc: support dynamic IOVA") > > > Cc: hemant.agrawal@nxp.com > > > > > > Signed-off-by: Shreyansh Jain > > > --- > > > drivers/bus/fslmc/fslmc_bus.c | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/drivers/bus/fslmc/fslmc_bus.c b/drivers/bus/fslmc/fslmc_bus.c > > > index bfe81e236..a4f9a9eee 100644 > > > --- a/drivers/bus/fslmc/fslmc_bus.c > > > +++ b/drivers/bus/fslmc/fslmc_bus.c > > > @@ -491,6 +491,10 @@ rte_dpaa2_get_iommu_class(void) > > > bool is_vfio_noiommu_enabled = 1; > > > bool has_iova_va; > > > > > > +#ifdef RTE_LIBRTE_DPAA2_USE_PHYS_IOVA > > > + return RTE_IOVA_PA; > > > +#endif > > > + > > > > As, RTE_LIBRTE_DPAA2_USE_PHYS_IOVA is set to true by default[1] and fslmc bus > > being always registered[2] irrespective of the underlying platform, the IOVA class > > will be always returned as PA. > > This will break multiple platforms as some work only when IOVA as VA. I think > > you need to verify if the underlying platform is really FLMC similar to DPAA[3] > > Thats a good catch and bad patch from me :( - Thanks for review. > I will do this now: > > ---->8--- > static enum rte_iova_mode > rte_dpaa2_get_iommu_class(void) > { > bool is_vfio_noiommu_enabled = 1; > bool has_iova_va; > > - #ifdef RTE_LIBRTE_DPAA2_USE_PHYS_IOVA > - return RTE_IOVA_PA; > - #endif > > if (TAILQ_EMPTY(&rte_fslmc_bus.device_list)) > return RTE_IOVA_DC; > > + #ifdef RTE_LIBRTE_DPAA2_USE_PHYS_IOVA > + return RTE_IOVA_PA; > + #endif > ---->8--- > > In this case, in case no FSLMC device is detected (which would be cases > you are referring to), DC would be returned. > > There is no other explicit way for me to check the PA/VA combination on > the DPAA2 bus. Even for the DPAA function [3]that you have mentioned, > that is not actually checking PA/VA applicability - it is just checking > if we have DPAA enabled or not (complete bus). > > Is that OK? Looks good to me :) cheers - Pavan. > > > > > [1] > > ->[master]ltp-pvn[dpdk] $ grep -nir "RTE_LIBRTE_DPAA2_USE_PHYS_IOVA" config/ > > config/meson.build:86:dpdk_conf.set('RTE_LIBRTE_DPAA2_USE_PHYS_IOVA', true) > > config/common_base:218:CONFIG_RTE_LIBRTE_DPAA2_USE_PHYS_IOVA=y > > > > [2] > > config/common_linuxapp:45:CONFIG_RTE_LIBRTE_FSLMC_BUS=y > > > > [3] > > static enum rte_iova_mode > > rte_dpaa_get_iommu_class(void) > > { > > if ((access(DPAA_DEV_PATH1, F_OK) != 0) && > > (access(DPAA_DEV_PATH2, F_OK) != 0)) { > > return RTE_IOVA_DC; > > } > > return RTE_IOVA_PA; > > } > > > > > > > if (TAILQ_EMPTY(&rte_fslmc_bus.device_list)) > > > return RTE_IOVA_DC; > > > >