From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest Date: Mon, 13 Jul 2015 11:15:21 +0100 Message-ID: <1436782521.7019.74.camel@citrix.com> References: <1436420047-25356-1-git-send-email-tiejun.chen@intel.com> <1436420047-25356-14-git-send-email-tiejun.chen@intel.com> <21918.47807.595901.751327@mariner.uk.xensource.com> <559F5AB0.5040506@intel.com> <1436519889.23508.185.camel@citrix.com> <55A38927.3030205@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55A38927.3030205@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Chen, Tiejun" Cc: Ian Jackson , xen-devel@lists.xen.org, Wei Liu , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Mon, 2015-07-13 at 17:47 +0800, Chen, Tiejun wrote: > > This approach looks like it should work, and I think given the point in > > the release it would be acceptable for 4.6. > > > > However long term I think it might make sense to try and reuse one of > > the existing libxl__arch hooks, i.e. > > libxl__arch_domain_init_hw_description or > > libxl__arch_domain_finalise_hw_description. On ARM these are to do with > > setting the Device Tree Blob, which included the memory map, so it is > > somewhat morally equivalent to configuring the e820 on x86, I think. > > > > Those hooks are only called from libxl__build_pv today, but calling them > > from libxl__build_hvm seems like it would be good too. > > But seems this is raising some potential risks, isn't this? Although > libxl__arch_domain_init_hw_description() and > libxl__arch_domain_finalise_hw_description() are NOP to x86, they're > really working on ARM side. So if we call them inside > libxl__build_hvm(), any affects to ARM? I'm not very sure at this point > unless anyone can validate this change on ARM, or you really ensure my > concerns is unnecessary. All ARM guests use the PV code path so there is no risk. If there was some change to ARM to introduce an HVM style guest then it would want those hooks called in this place too (and they would need fixing as part of implementing such a thing).