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?

-- 
Shannon


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

Reply via email to