Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall <julien.grall@xxxxxxx>]

(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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel