From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest Date: Tue, 14 Jul 2015 16:03:42 +0800 Message-ID: <55A4C25E.4040808@intel.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> <1436782521.7019.74.camel@citrix.com> <55A4A1D6.2060108@intel.com> <1436859727.7019.131.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1436859727.7019.131.camel@citrix.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: Ian Campbell Cc: Ian Jackson , xen-devel@lists.xen.org, Wei Liu , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org >>>>> 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. >> >> Okay but please take a close look at this, >> >> libxl__build_pv(gc, domid, info, state) >> | >> + libxl__arch_domain_finalise_hw_description(libxl__gc *gc, >> libxl_domain_build_info *info, >> struct xc_dom_image *dom) >> >> But in our case we need this parameter, struct xc_hvm_build_args *args, >> so how can we handle this conflict? Its not easy to add this, and it >> doesn't make sense as well in pv case. > > This is an internal API, you can feel free to modify it as necessary. I mean struct xc_hvm_build_args[] is a parameter specific to hvm so its wired to pass this in the case of hv. If we wrapper this again its not worth going this way. > > Please note that I started this subthread with "However long term I > think it might make sense ...", This was not a request to redo this > patch now. > Okay lets record this and now just keep moving forward with the original. Thanks Tiejun