[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest

On 2015/7/13 18:15, Ian Campbell wrote:
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.

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.


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).

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.