Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size

[Julien Grall <julien.grall@xxxxxxx>]

Hello Shannon,

On 07/06/16 12:42, Julien Grall wrote:
> > > > > Is there any particular reason to expose the list of the tables
> > > > > outside
> > > > > of the building code?
> > > > >
> > > > > I would provide a single buffer with all the tables inside. Similar to
> > > > > what you did for building the tables in the hypervisor.
> > > > When it loads these tables to guest memory space, it needs to update
> > > > the
> > > > entries (pointing to other tables) of XSDT and also the
> > > > xsdt_physical_address in RSDP.
> > > Why can't we load the ACPI tables at an hardcoded place in the memory
> > > (for instance always at the beginning of the RAM)?
> > I think it's more reasonable to let the codes dynamically compute where
> > it should put these tables at like what it does for the devicetree blob.
> >
> > And to an hardcoded place, can you make sure that kind of place is
> > always available and not used by others?
> Yes, the toolstack is in charge of the memory layout. So it can ensure
> that no-one else is using this region.
>
> My concern is, based on you patch #13, the ACPI tables are allocated
> just after all the other modules. However, they cannot be relocated by
> the kernel because they contain physical address. So they have to stay
> in place for all the life of the domain.
>
> We should put them in a place where it will not impact the memory
> allocation of the guest. The start of the RAM is a good place for that.
I though a bit more on this suggestion. If the ACPI tables are put at 
the beginning of the RAM, a guest may not be able to use super page.
I would suggest to move the ACPI table out of the real RAM to avoid any 
potential issue with the kernel memory allocation.
For instance we could define a IPA range to be use for ACPI (e.g 
0x20000000 - 0x20200000) and expose to the guest using the ACPI_NVS type 
in the UEFI memory map.
Any opinion on this?

Regards,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel