(CC Boris)
On 27/06/16 07:25, Shannon Zhao wrote:
On 2016/6/24 2:46, Julien Grall wrote:
+
static int alloc_magic_pages(struct xc_dom_image *dom)
{
> int rc, i;
@@ -100,6 +141,16 @@ static int alloc_magic_pages(struct xc_dom_image
*dom)
xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN,
dom->xenstore_evtchn);
+ if ( dom->acpitable_blob && dom->acpitable_size > 0 )
+ {
+ rc = xc_dom_copy_acpi(dom);
+ if ( rc != 0 )
+ {
+ DOMPRINTF("Unable to copy ACPI tables");
+ return rc;
+ }
+ }
alloc_magic_pages looks the wrong place with this function. Any reason
to not have a generic ACPI blob loading in xc_dom_core.c as we do for
devicetree?
Looks like xc_dom_build_image is used for allocating pages in guest RAM
while ACPI blob is not put in guest RAM.
The function xc_dom_build_image is used to load blob into the guest
memory and allocate others pages (such as magic pages) which may not be
part of the actual guest RAM.
The callback alloc_magic_pages is used to allocate per-architecture
specific pages. However, the ACPI blob is pretty much generic. So I am
not sure why we would want to do it for ARM only.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel