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