On 2016/6/7 19:42, Julien Grall wrote: > > > On 07/06/16 12:35, Shannon Zhao wrote: >> >> >> On 2016/6/7 19:27, Julien Grall wrote: >>> >>> >>> On 07/06/16 12:13, Shannon Zhao wrote: >>>> >>>> >>>> On 2016/6/7 19:05, Julien Grall wrote: >>>>> Hello Shannon, >>>>> >>>>> On 31/05/16 06:02, Shannon Zhao wrote: >>>>>> From: Shannon Zhao <shannon.z...@linaro.org> >>>>>> >>>>>> Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT >>>>>> for ARM VM. So only add placeholders for them here. >>>>>> >>>>>> Signed-off-by: Shannon Zhao <shannon.z...@linaro.org> >>>>>> --- >>>>>> tools/libxc/include/xc_dom.h | 17 +++++++++++++++++ >>>>>> 1 file changed, 17 insertions(+) >>>>>> >>>>>> diff --git a/tools/libxc/include/xc_dom.h >>>>>> b/tools/libxc/include/xc_dom.h >>>>>> index 6cb10c4..0fe54dd 100644 >>>>>> --- a/tools/libxc/include/xc_dom.h >>>>>> +++ b/tools/libxc/include/xc_dom.h >>>>>> @@ -56,6 +56,20 @@ struct xc_dom_phys { >>>>>> xen_pfn_t count; >>>>>> }; >>>>>> >>>>>> +struct acpitable { >>>>>> + void *table; >>>>>> + size_t size; >>>>>> +}; >>>>>> + >>>>>> +struct acpitable_blob { >>>>>> + struct acpitable rsdp; >>>>>> + struct acpitable xsdt; >>>>>> + struct acpitable gtdt; >>>>>> + struct acpitable madt; >>>>>> + struct acpitable fadt; >>>>>> + struct acpitable dsdt; >>>>>> +}; >>>>> >>>>> 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. > No, this doesn't like what you say. UEFI will install and relocate the ACPI tables again for guest kernel. That means the ACPI tables guest gets are not from the original place where toolstack puts them at.
-- Shannon _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel