[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxxxxx>

Currently there is only the table header in DSDT table.

Signed-off-by: Shannon Zhao <shannon.zhao@xxxxxxxxxx>
---
   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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.