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 C40702E89 for ; Thu, 6 Nov 2014 18:21:57 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 06 Nov 2014 09:31:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,327,1413270000"; d="scan'208";a="632774876" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.32]) by orsmga002.jf.intel.com with SMTP; 06 Nov 2014 09:31:00 -0800 Received: by (sSMTP sendmail emulation); Thu, 06 Nov 2014 17:30:59 +0025 Date: Thu, 6 Nov 2014 17:30:59 +0000 From: Bruce Richardson To: "Burakov, Anatoly" Message-ID: <20141106173059.GA7948@bricha3-MOBL3> References: <1415193919-17361-1-git-send-email-liang.xu@cinfotech.cn> <1415287928-14513-1-git-send-email-liang.xu@cinfotech.cn> <176911891.PG8FvFrDef@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v5] eal: map uio resources after hugepages when the base_virtaddr is configured. 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: Thu, 06 Nov 2014 17:21:59 -0000 On Thu, Nov 06, 2014 at 04:10:15PM +0000, Burakov, Anatoly wrote: > Well, removing --base-virtaddr is not what I'm asking about. > > The issue at hand here is that, given our secondary process mechanism (that you don't like :-) ), some stuff may be attempted to be mapped into space a secondary process may already have mapped something else into (some libraries, for example). This issue was originally discovered by OVDK, so we added a --base-virtaddr option to try and map hugepages at exact virtual address, rather than wherever mmap decides to do so on its own. > > The issue encountered by Liang (the author of the patch) is similar, only it's not the hugepages are mapped into the occupied space, but rather the PCI resources (which are mapped with NULL by default, so can be mapped anywhere). Therefore he suggested a patch that maps the PCI resources into a space just after the last hugepage when --base-virtaddr is provided. I'm not sure we need the dependence on --base-virtaddr though, it can probably be done unconditionally. If you have no opinion on the matter, we can leave this detail of the patch as it is, then. > > Also, I would suspect that if we are to modify where UIO resources are mapped, VFIO code should be modified the same way to avoid inconsistency between the two. > I find nothing wrong with your logic, Anatoly, it makes sense to me. :-) I'm curious, however, as to what Thomas has in mind for how we might improve the base-virtaddr flag. /Bruce > Thanks, > Anatoly > > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Thursday, November 6, 2014 3:58 PM > To: Burakov, Anatoly > Cc: lxu; dev@dpdk.org; De Lara Guarch, Pablo > Subject: Re: [PATCH v5] eal: map uio resources after hugepages when the base_virtaddr is configured. > > 2014-11-06 15:41, Burakov, Anatoly: > > Thomas, do we need to do similar changes to VFIO code, to keep consistency? > > Also, do we really need for this to depend on --base-virtaddr? Why not > > do it unconditionally, i.e. map PCI resources right after hugepages in memory? > > I don't really like the secondary process mechanism at all. > So I won't give good advice here ;) > But I feel this option --base-virtaddr should be improved or removed. > > -- > Thomas