Re: [PATCH RESEND 07/14] libxl/arm: Construct ACPI DSDT table

[Julien Grall <julien.grall@arm.com>]

Hi Shannon,

On 16/06/16 07:25, Shannon Zhao wrote:
>
>
> On 2016/6/7 21:42, Julien Grall wrote:
>> Hello Shannon,
>>
>> On 31/05/16 06:02, Shannon Zhao wrote:
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> Currently there is only the table header in DSDT table.
>>>
>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>> ---
>>>    tools/libxl/libxl_arm.c | 15 +++++++++++++++
>>>    1 file changed, 15 insertions(+)
>>>
>>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>>> index c3b8fb4..7949635 100644
>>> --- a/tools/libxl/libxl_arm.c
>>> +++ b/tools/libxl/libxl_arm.c
>>> @@ -944,6 +944,20 @@ static void make_acpi_fadt(libxl__gc *gc, struct
>>> xc_dom_image *dom)
>>>        dom->acpitable_size += dom->acpitable_blob->fadt.size;
>>>    }
>>>
>>> +static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
>>> +{
>>> +    struct acpi_table_header *dsdt;
>>> +
>>> +    /* Currently there is only the table header in DSDT table. */
>>
>> What about the processor device objects?
>
> Ah, yes. It should add processor device objects. Since DSDT table is
> special, what's your suggestion about how to generate DSDT table? Use
> static table which X86 use(tools/firmware/hvmloader/acpi/mk_dsdt.c) or
> import what QEMU uses?

I would do the choice depending on what we need to expose through the 
DTST. If it is only dummy processor containers, then ~1500 lines of code 
(see qemu/hw/acpi/aml-build.c) seems a bit overkill.

> I prefer the latter, but this will add more codes to libxl.

What would be the benefits to build dynamically those tables?

Regards,

-- 
Julien Grall

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