xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RESEND 00/14] Xen ARM DomU ACPI support
@ 2016-05-31  5:02 Shannon Zhao
  2016-05-31  5:02 ` [PATCH RESEND 01/14] libxl/arm: Fix the function name in error log Shannon Zhao
                   ` (17 more replies)
  0 siblings, 18 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:02 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.

Then, it copies these ACPI tables to DomU memory space and passes
them to UEFI firmware through the "ARM multiboot" protocol.

At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
and installs these tables like the usual way and passes both ACPI and DT
information to the Xen DomU.

Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
since it's enough now.

This has been tested using guest kernel with the Dom0 ACPI support
patches which could be fetched from:
https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen

Shannon Zhao (14):
  libxl/arm: Fix the function name in error log
  libxl/arm: Factor out codes for generating DTB
  libxc: Add placeholders for ACPI tables blob and size
  tools: add ACPI tables relevant definitions
  libxl/arm: Construct ACPI GTDT table
  libxl/arm: Construct ACPI FADT table
  libxl/arm: Construct ACPI DSDT table
  libxl/arm: Construct ACPI MADT table
  libxl/arm: Construct ACPI XSDT table
  libxl/arm: Construct ACPI RSDP table
  libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
  libxl/arm: Add ACPI module
  libxl/arm: initialize memory information of ACPI blob
  libxc/xc_dom_core: Copy ACPI tables to guest memory space

 tools/libxc/include/acpi_defs.h | 277 ++++++++++++++++++++++++++++++++
 tools/libxc/include/xc_dom.h    |  17 ++
 tools/libxc/xc_dom_arm.c        |  16 +-
 tools/libxc/xc_dom_core.c       |  59 +++++++
 tools/libxl/libxl_arm.c         | 345 +++++++++++++++++++++++++++++++++++++++-
 5 files changed, 706 insertions(+), 8 deletions(-)
 create mode 100644 tools/libxc/include/acpi_defs.h

-- 
2.0.4



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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* [PATCH RESEND 01/14] libxl/arm: Fix the function name in error log
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
@ 2016-05-31  5:02 ` Shannon Zhao
  2016-06-03 19:25   ` Wei Liu
  2016-05-31  5:02 ` [PATCH RESEND 02/14] libxl/arm: Factor out codes for generating DTB Shannon Zhao
                   ` (16 subsequent siblings)
  17 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:02 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

It should be xc_dom_devicetree_mem instead of xc_dom_devicetree_file.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/libxl_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 1195b37..c6d77e3 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -872,7 +872,7 @@ next_resize:
 
     res = xc_dom_devicetree_mem(dom, fdt, fdt_totalsize(fdt));
     if (res) {
-        LOGE(ERROR, "xc_dom_devicetree_file failed");
+        LOGE(ERROR, "xc_dom_devicetree_mem failed");
         rc = ERROR_FAIL;
         goto out;
     }
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 02/14] libxl/arm: Factor out codes for generating DTB
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
  2016-05-31  5:02 ` [PATCH RESEND 01/14] libxl/arm: Fix the function name in error log Shannon Zhao
@ 2016-05-31  5:02 ` Shannon Zhao
  2016-06-03 19:25   ` Wei Liu
  2016-05-31  5:02 ` [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size Shannon Zhao
                   ` (15 subsequent siblings)
  17 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:02 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

Factor out codes for generating DTB to prepare for adding ACPI tables
generation codes.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/libxl_arm.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index c6d77e3..9e99159 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -747,10 +747,9 @@ static int copy_partial_fdt(libxl__gc *gc, void *fdt, void *pfdt)
 
 #define FDT_MAX_SIZE (1<<20)
 
-int libxl__arch_domain_init_hw_description(libxl__gc *gc,
-                                           libxl_domain_build_info *info,
-                                           libxl__domain_build_state *state,
-                                           struct xc_dom_image *dom)
+static int prepare_dtb(libxl__gc *gc, libxl_domain_build_info *info,
+                       libxl__domain_build_state *state,
+                       struct xc_dom_image *dom)
 {
     void *fdt = NULL;
     void *pfdt = NULL;
@@ -764,8 +763,6 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
     /* convenience aliases */
     xc_domain_configuration_t *xc_config = &state->config;
 
-    assert(info->type == LIBXL_DOMAIN_TYPE_PV);
-
     vers = libxl_get_version_info(CTX);
     if (vers == NULL) return ERROR_FAIL;
 
@@ -883,6 +880,15 @@ out:
     return rc;
 }
 
+int libxl__arch_domain_init_hw_description(libxl__gc *gc,
+                                           libxl_domain_build_info *info,
+                                           libxl__domain_build_state *state,
+                                           struct xc_dom_image *dom)
+{
+    assert(info->type == LIBXL_DOMAIN_TYPE_PV);
+    return prepare_dtb(gc, info, state, dom);
+}
+
 static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
                                      uint64_t base, uint64_t size)
 {
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
  2016-05-31  5:02 ` [PATCH RESEND 01/14] libxl/arm: Fix the function name in error log Shannon Zhao
  2016-05-31  5:02 ` [PATCH RESEND 02/14] libxl/arm: Factor out codes for generating DTB Shannon Zhao
@ 2016-05-31  5:02 ` Shannon Zhao
  2016-06-06 10:00   ` Stefano Stabellini
  2016-06-07 11:05   ` Julien Grall
  2016-05-31  5:02 ` [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions Shannon Zhao
                   ` (14 subsequent siblings)
  17 siblings, 2 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:02 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@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.zhao@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;
+};
+
 struct xc_dom_image {
     /* files */
     void *kernel_blob;
@@ -64,6 +78,8 @@ struct xc_dom_image {
     size_t ramdisk_size;
     void *devicetree_blob;
     size_t devicetree_size;
+    struct acpitable_blob *acpitable_blob;
+    size_t acpitable_size;
 
     size_t max_kernel_size;
     size_t max_ramdisk_size;
@@ -92,6 +108,7 @@ struct xc_dom_image {
     struct xc_dom_seg p2m_seg;
     struct xc_dom_seg pgtables_seg;
     struct xc_dom_seg devicetree_seg;
+    struct xc_dom_seg acpi_seg;
     struct xc_dom_seg start_info_seg; /* HVMlite only */
     xen_pfn_t start_info_pfn;
     xen_pfn_t console_pfn;
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (2 preceding siblings ...)
  2016-05-31  5:02 ` [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size Shannon Zhao
@ 2016-05-31  5:02 ` Shannon Zhao
  2016-06-06 10:04   ` Stefano Stabellini
  2016-05-31  5:02 ` [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table Shannon Zhao
                   ` (13 subsequent siblings)
  17 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:02 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

Add ACPI tables relevant definitions for generating ACPI tables for ARM
guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT tables will
be used.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxc/include/acpi_defs.h | 277 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 277 insertions(+)
 create mode 100644 tools/libxc/include/acpi_defs.h

diff --git a/tools/libxc/include/acpi_defs.h b/tools/libxc/include/acpi_defs.h
new file mode 100644
index 0000000..9389a96
--- /dev/null
+++ b/tools/libxc/include/acpi_defs.h
@@ -0,0 +1,277 @@
+#ifndef _ACPI_DEFS_H_
+#define _ACPI_DEFS_H_
+
+#define ACPI_BUILD_APPNAME6 "XenARM"
+#define ACPI_BUILD_APPNAME4 "Xen "
+
+#pragma pack (1)
+
+/* Root System Description Pointer Structure. */
+struct acpi_rsdp_descriptor {        /* Root System Descriptor Pointer */
+    uint64_t signature;              /* ACPI signature, contains "RSD PTR " */
+    uint8_t  checksum;               /* To make sum of struct == 0 */
+    uint8_t  oem_id[6];             /* OEM identification */
+    uint8_t  revision;               /* Must be 0 for 1.0, 2 for 2.0 */
+    uint32_t rsdt_physical_address;  /* 32-bit physical address of RSDT */
+    uint32_t length;                 /* XSDT Length in bytes including hdr */
+    uint64_t xsdt_physical_address;  /* 64-bit physical address of XSDT */
+    uint8_t  extended_checksum;      /* Checksum of entire table */
+    uint8_t  reserved[3];           /* Reserved field must be 0 */
+};
+
+/* ACPI common table header. */
+struct acpi_table_header {
+    uint32_t signature;          /* ACPI signature (4 ASCII characters) */ \
+    uint32_t length;                 /* Length of table, in bytes, including header */ \
+    uint8_t  revision;               /* ACPI Specification minor version # */ \
+    uint8_t  checksum;               /* To make sum of entire table == 0 */ \
+    uint8_t  oem_id[6];             /* OEM identification */ \
+    uint8_t  oem_table_id[8];       /* OEM table identification */ \
+    uint32_t oem_revision;           /* OEM revision number */ \
+    uint8_t  asl_compiler_id[4];    /* ASL compiler vendor ID */ \
+    uint32_t asl_compiler_revision;  /* ASL compiler revision number */
+};
+
+/* Extended System Description Table (XSDT). */
+struct acpi_xsdt_descriptor {
+    struct acpi_table_header header;
+    uint64_t entry[0];
+};
+
+/* Generic Timer Description Table (GTDT). */
+#define ACPI_GTDT_INTERRUPT_MODE        0
+#define ACPI_GTDT_INTERRUPT_POLARITY    1
+#define ACPI_GTDT_ALWAYS_ON             2
+
+/* Triggering */
+#define ACPI_LEVEL_SENSITIVE            ((uint8_t) 0x00)
+#define ACPI_EDGE_SENSITIVE             ((uint8_t) 0x01)
+
+/* Polarity */
+#define ACPI_ACTIVE_HIGH                ((uint8_t) 0x00)
+#define ACPI_ACTIVE_LOW                 ((uint8_t) 0x01)
+
+struct acpi_gtdt_descriptor {
+    struct acpi_table_header header;
+    uint64_t counter_block_addresss;
+    uint32_t reserved;
+    uint32_t secure_el1_interrupt;
+    uint32_t secure_el1_flags;
+    uint32_t non_secure_el1_interrupt;
+    uint32_t non_secure_el1_flags;
+    uint32_t virtual_timer_interrupt;
+    uint32_t virtual_timer_flags;
+    uint32_t non_secure_el2_interrupt;
+    uint32_t non_secure_el2_flags;
+    uint64_t counter_read_block_address;
+    uint32_t platform_timer_count;
+    uint32_t platform_timer_offset;
+};
+
+/* Multiple APIC Description Table header definition (MADT). */
+struct acpi_madt_descriptor
+{
+    struct acpi_table_header header;     /* ACPI common table header */
+    uint32_t local_apic_address;     /* Physical address of local APIC */
+    uint32_t flags;
+};
+
+/* Values for Type in APIC sub-headers. */
+
+#define ACPI_APIC_PROCESSOR          0
+#define ACPI_APIC_IO                 1
+#define ACPI_APIC_XRUPT_OVERRIDE     2
+#define ACPI_APIC_NMI                3
+#define ACPI_APIC_LOCAL_NMI          4
+#define ACPI_APIC_ADDRESS_OVERRIDE   5
+#define ACPI_APIC_IO_SAPIC           6
+#define ACPI_APIC_LOCAL_SAPIC        7
+#define ACPI_APIC_XRUPT_SOURCE       8
+#define ACPI_APIC_LOCAL_X2APIC       9
+#define ACPI_APIC_LOCAL_X2APIC_NMI      10
+#define ACPI_APIC_GENERIC_INTERRUPT     11
+#define ACPI_APIC_GENERIC_DISTRIBUTOR   12
+#define ACPI_APIC_GENERIC_MSI_FRAME     13
+#define ACPI_APIC_GENERIC_REDISTRIBUTOR 14
+#define ACPI_APIC_RESERVED              15   /* 15 and greater are reserved */
+
+/*
+ * MADT sub-structures (Follow MULTIPLE_APIC_DESCRIPTION_TABLE).
+ */
+#define ACPI_SUB_HEADER_DEF   /* Common ACPI sub-structure header */\
+    uint8_t  type;                               \
+    uint8_t  length;
+
+/* Sub-structures for MADT */
+
+struct acpi_madt_generic_interrupt {
+    ACPI_SUB_HEADER_DEF
+    uint16_t reserved;
+    uint32_t cpu_interface_number;
+    uint32_t uid;
+    uint32_t flags;
+    uint32_t parking_version;
+    uint32_t performance_interrupt;
+    uint64_t parked_address;
+    uint64_t base_address;
+    uint64_t gicv_base_address;
+    uint64_t gich_base_address;
+    uint32_t vgic_interrupt;
+    uint64_t gicr_base_address;
+    uint64_t arm_mpidr;
+};
+
+struct acpi_madt_generic_distributor {
+    ACPI_SUB_HEADER_DEF
+    uint16_t reserved;
+    uint32_t gic_id;
+    uint64_t base_address;
+    uint32_t global_irq_base;
+    uint8_t version;
+    uint8_t reserved2[3];
+};
+
+struct acpi_madt_generic_msi_frame {
+    ACPI_SUB_HEADER_DEF
+    uint16_t reserved;
+    uint32_t gic_msi_frame_id;
+    uint64_t base_address;
+    uint32_t flags;
+    uint16_t spi_count;
+    uint16_t spi_base;
+};
+
+struct acpi_madt_generic_redistributor {
+    ACPI_SUB_HEADER_DEF
+    uint16_t reserved;
+    uint64_t base_address;
+    uint32_t range_length;
+};
+
+enum {
+    ACPI_FADT_F_WBINVD,
+    ACPI_FADT_F_WBINVD_FLUSH,
+    ACPI_FADT_F_PROC_C1,
+    ACPI_FADT_F_P_LVL2_UP,
+    ACPI_FADT_F_PWR_BUTTON,
+    ACPI_FADT_F_SLP_BUTTON,
+    ACPI_FADT_F_FIX_RTC,
+    ACPI_FADT_F_RTC_S4,
+    ACPI_FADT_F_TMR_VAL_EXT,
+    ACPI_FADT_F_DCK_CAP,
+    ACPI_FADT_F_RESET_REG_SUP,
+    ACPI_FADT_F_SEALED_CASE,
+    ACPI_FADT_F_HEADLESS,
+    ACPI_FADT_F_CPU_SW_SLP,
+    ACPI_FADT_F_PCI_EXP_WAK,
+    ACPI_FADT_F_USE_PLATFORM_CLOCK,
+    ACPI_FADT_F_S4_RTC_STS_VALID,
+    ACPI_FADT_F_REMOTE_POWER_ON_CAPABLE,
+    ACPI_FADT_F_FORCE_APIC_CLUSTER_MODEL,
+    ACPI_FADT_F_FORCE_APIC_PHYSICAL_DESTINATION_MODE,
+    ACPI_FADT_F_HW_REDUCED_ACPI,
+    ACPI_FADT_F_LOW_POWER_S0_IDLE_CAPABLE,
+};
+
+enum {
+    ACPI_FADT_ARM_USE_PSCI_G_0_2 = 0,
+    ACPI_FADT_ARM_PSCI_USE_HVC = 1,
+};
+
+struct acpi_generic_address {
+    uint8_t space_id;        /* Address space where struct or register exists */
+    uint8_t bit_width;       /* Size in bits of given register */
+    uint8_t bit_offset;      /* Bit offset within the register */
+    uint8_t access_width;    /* Minimum Access size (ACPI 3.0) */
+    uint64_t address;        /* 64-bit address of struct or register */
+};
+
+struct acpi_fadt_descriptor {
+    struct acpi_table_header header;    /* ACPI common table header */ \
+    uint32_t firmware_ctrl;  /* Physical address of FACS */ \
+    uint32_t dsdt;         /* Physical address of DSDT */ \
+    uint8_t  model;        /* System Interrupt Model */ \
+    uint8_t  reserved1;    /* Reserved */ \
+    uint16_t sci_int;      /* System vector of SCI interrupt */ \
+    uint32_t smi_cmd;      /* Port address of SMI command port */ \
+    uint8_t  acpi_enable;  /* Value to write to smi_cmd to enable ACPI */ \
+    uint8_t  acpi_disable; /* Value to write to smi_cmd to disable ACPI */ \
+    /* Value to write to SMI CMD to enter S4BIOS state */ \
+    uint8_t  S4bios_req; \
+    uint8_t  reserved2;    /* Reserved - must be zero */ \
+    /* Port address of Power Mgt 1a acpi_event Reg Blk */ \
+    uint32_t pm1a_evt_blk; \
+    /* Port address of Power Mgt 1b acpi_event Reg Blk */ \
+    uint32_t pm1b_evt_blk; \
+    uint32_t pm1a_cnt_blk; /* Port address of Power Mgt 1a Control Reg Blk */ \
+    uint32_t pm1b_cnt_blk; /* Port address of Power Mgt 1b Control Reg Blk */ \
+    uint32_t pm2_cnt_blk;  /* Port address of Power Mgt 2 Control Reg Blk */ \
+    uint32_t pm_tmr_blk;   /* Port address of Power Mgt Timer Ctrl Reg Blk */ \
+    /* Port addr of General Purpose acpi_event 0 Reg Blk */ \
+    uint32_t gpe0_blk; \
+    /* Port addr of General Purpose acpi_event 1 Reg Blk */ \
+    uint32_t gpe1_blk; \
+    uint8_t  pm1_evt_len;  /* Byte length of ports at pm1_x_evt_blk */ \
+    uint8_t  pm1_cnt_len;  /* Byte length of ports at pm1_x_cnt_blk */ \
+    uint8_t  pm2_cnt_len;  /* Byte Length of ports at pm2_cnt_blk */ \
+    uint8_t  pm_tmr_len;   /* Byte Length of ports at pm_tm_blk */ \
+    uint8_t  gpe0_blk_len; /* Byte Length of ports at gpe0_blk */ \
+    uint8_t  gpe1_blk_len; /* Byte Length of ports at gpe1_blk */ \
+    uint8_t  gpe1_base;    /* Offset in gpe model where gpe1 events start */ \
+    uint8_t  reserved3;    /* Reserved */ \
+    uint16_t plvl2_lat;    /* Worst case HW latency to enter/exit C2 state */ \
+    uint16_t plvl3_lat;    /* Worst case HW latency to enter/exit C3 state */ \
+    uint16_t flush_size;   /* Size of area read to flush caches */ \
+    uint16_t flush_stride; /* Stride used in flushing caches */ \
+    uint8_t  duty_offset;  /* Bit location of duty cycle field in p_cnt reg */ \
+    uint8_t  duty_width;   /* Bit width of duty cycle field in p_cnt reg */ \
+    uint8_t  day_alrm;     /* Index to day-of-month alarm in RTC CMOS RAM */ \
+    uint8_t  mon_alrm;     /* Index to month-of-year alarm in RTC CMOS RAM */ \
+    uint8_t  century;      /* Index to century in RTC CMOS RAM */
+    /* IA-PC Boot Architecture Flags (see below for individual flags) */
+    uint16_t boot_flags;
+    uint8_t reserved;    /* Reserved, must be zero */
+    /* Miscellaneous flag bits (see below for individual flags) */
+    uint32_t flags;
+    /* 64-bit address of the Reset register */
+    struct acpi_generic_address reset_register;
+    /* Value to write to the reset_register port to reset the system */
+    uint8_t reset_value;
+    /* ARM-Specific Boot Flags (see below for individual flags) (ACPI 5.1) */
+    uint16_t arm_boot_flags;
+    uint8_t minor_revision;  /* FADT Minor Revision (ACPI 5.1) */
+    uint64_t Xfacs;          /* 64-bit physical address of FACS */
+    uint64_t Xdsdt;          /* 64-bit physical address of DSDT */
+    /* 64-bit Extended Power Mgt 1a Event Reg Blk address */
+    struct acpi_generic_address xpm1a_event_block;
+    /* 64-bit Extended Power Mgt 1b Event Reg Blk address */
+    struct acpi_generic_address xpm1b_event_block;
+    /* 64-bit Extended Power Mgt 1a Control Reg Blk address */
+    struct acpi_generic_address xpm1a_control_block;
+    /* 64-bit Extended Power Mgt 1b Control Reg Blk address */
+    struct acpi_generic_address xpm1b_control_block;
+    /* 64-bit Extended Power Mgt 2 Control Reg Blk address */
+    struct acpi_generic_address xpm2_control_block;
+    /* 64-bit Extended Power Mgt Timer Ctrl Reg Blk address */
+    struct acpi_generic_address xpm_timer_block;
+    /* 64-bit Extended General Purpose Event 0 Reg Blk address */
+    struct acpi_generic_address xgpe0_block;
+    /* 64-bit Extended General Purpose Event 1 Reg Blk address */
+    struct acpi_generic_address xgpe1_block;
+    /* 64-bit Sleep Control register (ACPI 5.0) */
+    struct acpi_generic_address sleep_control;
+    /* 64-bit Sleep Status register (ACPI 5.0) */
+    struct acpi_generic_address sleep_status;
+};
+
+#endif /* _ACPI_DEFS_H_ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (3 preceding siblings ...)
  2016-05-31  5:02 ` [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions Shannon Zhao
@ 2016-05-31  5:02 ` Shannon Zhao
  2016-06-06 11:40   ` Stefano Stabellini
                     ` (2 more replies)
  2016-05-31  5:02 ` [PATCH RESEND 06/14] libxl/arm: Construct ACPI FADT table Shannon Zhao
                   ` (12 subsequent siblings)
  17 siblings, 3 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:02 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

Construct GTDT table with the interrupt information of timers.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/libxl_arm.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 74 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 9e99159..0fb4f69 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -3,6 +3,7 @@
 #include "libxl_libfdt_compat.h"
 
 #include <xc_dom.h>
+#include <acpi_defs.h>
 #include <stdbool.h>
 #include <libfdt.h>
 #include <assert.h>
@@ -880,13 +881,85 @@ out:
     return rc;
 }
 
+static void make_acpi_header(struct acpi_table_header *h, const char *sig,
+                             int len, uint8_t rev)
+{
+    memcpy(&h->signature, sig, 4);
+    h->length = len;
+    h->revision = rev;
+    memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
+    memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
+    memcpy(h->oem_table_id + 4, sig, 4);
+    h->oem_revision = 1;
+    memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
+    h->asl_compiler_revision = 1;
+    h->checksum = 0;
+}
+
+static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+    struct acpi_gtdt_descriptor *gtdt;
+
+    gtdt = libxl__zalloc(gc, sizeof(*gtdt));
+
+    gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
+    gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
+                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
+    gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
+    gtdt->non_secure_el1_flags =
+                             (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
+                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
+    gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
+    gtdt->virtual_timer_flags =
+                             (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
+                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
+
+    make_acpi_header(&gtdt->header, "GTDT", sizeof(*gtdt), 2);
+
+    dom->acpitable_blob->gtdt.table = (void *)gtdt;
+    /* Align to 64bit. */
+    dom->acpitable_blob->gtdt.size = sizeof(*gtdt);
+    dom->acpitable_size += dom->acpitable_blob->gtdt.size;
+}
+
+static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
+                        libxl__domain_build_state *state,
+                        struct xc_dom_image *dom)
+{
+    const libxl_version_info *vers;
+
+    /* convenience aliases */
+    xc_domain_configuration_t *xc_config = &state->config;
+
+    vers = libxl_get_version_info(CTX);
+    if (vers == NULL)
+        return ERROR_FAIL;
+
+    LOG(DEBUG, "constructing ACPI tables for Xen version %d.%d guest",
+        vers->xen_version_major, vers->xen_version_minor);
+
+    /* Alloc memory for ACPI blob placeholders. */
+    dom->acpitable_blob = libxl__zalloc(gc, sizeof(struct acpitable_blob));
+    dom->acpitable_size = 0;
+
+    make_acpi_gtdt(gc, dom);
+
+    return 0;
+}
+
 int libxl__arch_domain_init_hw_description(libxl__gc *gc,
                                            libxl_domain_build_info *info,
                                            libxl__domain_build_state *state,
                                            struct xc_dom_image *dom)
 {
+    int rc;
+
     assert(info->type == LIBXL_DOMAIN_TYPE_PV);
-    return prepare_dtb(gc, info, state, dom);
+    rc = prepare_dtb(gc, info, state, dom);
+    if (rc)
+        return rc;
+
+    return prepare_acpi(gc, info, state, dom);
 }
 
 static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 06/14] libxl/arm: Construct ACPI FADT table
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (4 preceding siblings ...)
  2016-05-31  5:02 ` [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table Shannon Zhao
@ 2016-05-31  5:02 ` Shannon Zhao
  2016-06-07 13:17   ` Julien Grall
  2016-05-31  5:02 ` [PATCH RESEND 07/14] libxl/arm: Construct ACPI DSDT table Shannon Zhao
                   ` (11 subsequent siblings)
  17 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:02 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/libxl_arm.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 0fb4f69..c3b8fb4 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -922,6 +922,28 @@ static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
     dom->acpitable_size += dom->acpitable_blob->gtdt.size;
 }
 
+static void make_acpi_fadt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+    struct acpi_fadt_descriptor *fadt;
+
+    fadt = libxl__zalloc(gc, sizeof(*fadt));
+
+    /* Hardware Reduced = 1 and use PSCI 0.2+ and with HVC */
+    fadt->flags = 1 << ACPI_FADT_F_HW_REDUCED_ACPI;
+    fadt->arm_boot_flags = (1 << ACPI_FADT_ARM_USE_PSCI_G_0_2) |
+                           (1 << ACPI_FADT_ARM_PSCI_USE_HVC);
+
+    /* ACPI v5.1 (fadt->revision.fadt->minor_revision) */
+    fadt->minor_revision = 0x1;
+
+    make_acpi_header(&fadt->header, "FACP", sizeof(*fadt), 5);
+
+    dom->acpitable_blob->fadt.table = (void *)fadt;
+    /* Align to 64bit. */
+    dom->acpitable_blob->fadt.size = sizeof(*fadt);
+    dom->acpitable_size += dom->acpitable_blob->fadt.size;
+}
+
 static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
@@ -943,6 +965,7 @@ static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
     dom->acpitable_size = 0;
 
     make_acpi_gtdt(gc, dom);
+    make_acpi_fadt(gc, dom);
 
     return 0;
 }
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 07/14] libxl/arm: Construct ACPI DSDT table
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (5 preceding siblings ...)
  2016-05-31  5:02 ` [PATCH RESEND 06/14] libxl/arm: Construct ACPI FADT table Shannon Zhao
@ 2016-05-31  5:02 ` Shannon Zhao
  2016-06-07 13:42   ` Julien Grall
  2016-05-31  5:03 ` [PATCH RESEND 08/14] libxl/arm: Construct ACPI MADT table Shannon Zhao
                   ` (10 subsequent siblings)
  17 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:02 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

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. */
+    dsdt = libxl__zalloc(gc, sizeof(*dsdt));
+    make_acpi_header((void *)dsdt, "DSDT", sizeof(*dsdt), 2);
+
+    dom->acpitable_blob->dsdt.table = (void *)dsdt;
+    /* Align to 64bit. */
+    dom->acpitable_blob->dsdt.size = ROUNDUP(sizeof(*dsdt), 3);
+    dom->acpitable_size += ROUNDUP(dom->acpitable_blob->dsdt.size, 3);
+}
+
 static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
@@ -966,6 +980,7 @@ static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 
     make_acpi_gtdt(gc, dom);
     make_acpi_fadt(gc, dom);
+    make_acpi_dsdt(gc, dom);
 
     return 0;
 }
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 08/14] libxl/arm: Construct ACPI MADT table
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (6 preceding siblings ...)
  2016-05-31  5:02 ` [PATCH RESEND 07/14] libxl/arm: Construct ACPI DSDT table Shannon Zhao
@ 2016-05-31  5:03 ` Shannon Zhao
  2016-06-07 13:40   ` Julien Grall
  2016-05-31  5:03 ` [PATCH RESEND 09/14] libxl/arm: Construct ACPI XSDT table Shannon Zhao
                   ` (9 subsequent siblings)
  17 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:03 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

According to the gic version, construct the MADT table.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/libxl_arm.c | 107 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 107 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 7949635..f72f692 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -958,11 +958,115 @@ static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
     dom->acpitable_size += ROUNDUP(dom->acpitable_blob->dsdt.size, 3);
 }
 
+static void make_acpi_madt_gicc(void *table, int nr_cpus, uint64_t gicc_base)
+{
+    uint32_t i;
+    uint64_t mpidr_aff;
+    struct acpi_madt_generic_interrupt *gicc = table;
+
+    for (i = 0; i < nr_cpus; i++) {
+        gicc->type = ACPI_APIC_GENERIC_INTERRUPT;
+        gicc->length = sizeof(*gicc);
+        gicc->base_address = gicc_base;
+        gicc->cpu_interface_number = i;
+
+        /*
+         * We will use AFF0 and AFF1 when constructing the MPIDR value of the
+         * guest at the moment, for it is enough for the current max vcpu
+         * number.
+         */
+        mpidr_aff = (i & 0x0f) | (((i >> 4) & 0xff) << 8);
+        gicc->arm_mpidr = mpidr_aff;
+        gicc->uid = i;
+        gicc->flags = 1;
+
+        gicc += 1;
+    }
+}
+
+static void make_acpi_madt_gicd(void *table, uint64_t gicd_base,
+                                uint8_t gic_version)
+{
+    struct acpi_madt_generic_distributor *gicd = table;
+
+    gicd->type = ACPI_APIC_GENERIC_DISTRIBUTOR;
+    gicd->length = sizeof(*gicd);
+    gicd->base_address = gicd_base;
+    gicd->version = gic_version;
+}
+
+static void make_acpi_madt_gicr(void *table, uint64_t gicr_base,
+                                uint64_t gicr_size)
+{
+    struct acpi_madt_generic_redistributor *gicr = table;
+
+    gicr->type = ACPI_APIC_GENERIC_REDISTRIBUTOR;
+    gicr->length = sizeof(*gicr);
+    gicr->base_address = gicr_base;
+    gicr->range_length = gicr_size;
+}
+
+static int make_acpi_madt(libxl__gc *gc, struct xc_dom_image *dom, int nr_cpus,
+                          xc_domain_configuration_t *xc_config)
+{
+    uint32_t size;
+    void *table;
+    struct acpi_madt_descriptor *madt;
+
+    switch (xc_config->gic_version) {
+    case XEN_DOMCTL_CONFIG_GIC_V2:
+        size = sizeof(struct acpi_madt_descriptor) +
+               sizeof(struct acpi_madt_generic_interrupt) * nr_cpus +
+               sizeof(struct acpi_madt_generic_distributor);
+        table = libxl__zalloc(gc, size);
+        madt = (struct acpi_madt_descriptor *)table;
+
+        table += sizeof(struct acpi_madt_descriptor);
+        make_acpi_madt_gicc(table, nr_cpus, GUEST_GICC_BASE);
+
+        table += sizeof(struct acpi_madt_generic_interrupt) * nr_cpus;
+        make_acpi_madt_gicd(table, GUEST_GICD_BASE, 2);
+        break;
+    case XEN_DOMCTL_CONFIG_GIC_V3:
+        size = sizeof(struct acpi_madt_descriptor) +
+               sizeof(struct acpi_madt_generic_interrupt) * nr_cpus +
+               sizeof(struct acpi_madt_generic_distributor) +
+               sizeof(struct acpi_madt_generic_redistributor);
+        table = libxl__zalloc(gc, size);
+        madt = (struct acpi_madt_descriptor *)table;
+
+        table += sizeof(struct acpi_madt_descriptor);
+        make_acpi_madt_gicc(table, nr_cpus, 0);
+
+        table += sizeof(struct acpi_madt_generic_interrupt) * nr_cpus;
+        make_acpi_madt_gicd(table, GUEST_GICV3_GICD_BASE, 3);
+
+        table += sizeof(struct acpi_madt_generic_distributor);
+        make_acpi_madt_gicr(table, GUEST_GICV3_GICR0_BASE,
+                            GUEST_GICV3_GICR0_SIZE);
+        break;
+    default:
+        LOG(ERROR, "Unknown GIC version %s",
+            gicv_to_string(xc_config->gic_version));
+        return ERROR_FAIL;
+    }
+
+    make_acpi_header(&madt->header, "APIC", size, 3);
+
+    dom->acpitable_blob->madt.table = (void *)madt;
+    /* Align to 64bit. */
+    dom->acpitable_blob->madt.size = size;
+    dom->acpitable_size += dom->acpitable_blob->madt.size;
+
+    return 0;
+}
+
 static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
 {
     const libxl_version_info *vers;
+    int rc;
 
     /* convenience aliases */
     xc_domain_configuration_t *xc_config = &state->config;
@@ -981,6 +1085,9 @@ static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
     make_acpi_gtdt(gc, dom);
     make_acpi_fadt(gc, dom);
     make_acpi_dsdt(gc, dom);
+    rc = make_acpi_madt(gc, dom, info->max_vcpus, xc_config);
+    if (rc)
+	return rc;
 
     return 0;
 }
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 09/14] libxl/arm: Construct ACPI XSDT table
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (7 preceding siblings ...)
  2016-05-31  5:03 ` [PATCH RESEND 08/14] libxl/arm: Construct ACPI MADT table Shannon Zhao
@ 2016-05-31  5:03 ` Shannon Zhao
  2016-05-31  5:03 ` [PATCH RESEND 10/14] libxl/arm: Construct ACPI RSDP table Shannon Zhao
                   ` (8 subsequent siblings)
  17 siblings, 0 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:03 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/libxl_arm.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index f72f692..84ea8b6 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1061,6 +1061,27 @@ static int make_acpi_madt(libxl__gc *gc, struct xc_dom_image *dom, int nr_cpus,
     return 0;
 }
 
+static void make_acpi_xsdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+    uint32_t size;
+    struct acpi_xsdt_descriptor *xsdt;
+
+    /*
+     * Currently only 3 tables(GTDT, FADT, MADT) are pointed by XSDT. Alloc
+     * entries for them but the entry values will be specified when they are
+     * copied to the guest memory.
+     */
+    size = sizeof(*xsdt) + sizeof(uint64_t) * 3;
+    xsdt = libxl__zalloc(gc, size);
+
+    make_acpi_header(&xsdt->header, "XSDT", size, 1);
+
+    dom->acpitable_blob->xsdt.table = (void *)xsdt;
+    /* Align to 64bit. */
+    dom->acpitable_blob->xsdt.size = size;
+    dom->acpitable_size += dom->acpitable_blob->xsdt.size;
+}
+
 static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
@@ -1089,6 +1110,8 @@ static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
     if (rc)
 	return rc;
 
+    make_acpi_xsdt(gc, dom);
+
     return 0;
 }
 
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 10/14] libxl/arm: Construct ACPI RSDP table
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (8 preceding siblings ...)
  2016-05-31  5:03 ` [PATCH RESEND 09/14] libxl/arm: Construct ACPI XSDT table Shannon Zhao
@ 2016-05-31  5:03 ` Shannon Zhao
  2016-05-31  5:03 ` [PATCH RESEND 11/14] libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ Shannon Zhao
                   ` (7 subsequent siblings)
  17 siblings, 0 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:03 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/libxl_arm.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 84ea8b6..1bef9b0 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1082,6 +1082,23 @@ static void make_acpi_xsdt(libxl__gc *gc, struct xc_dom_image *dom)
     dom->acpitable_size += dom->acpitable_blob->xsdt.size;
 }
 
+static void make_acpi_rsdp(libxl__gc *gc, struct xc_dom_image *dom)
+{
+    struct acpi_rsdp_descriptor *rsdp;
+
+    rsdp = libxl__zalloc(gc, sizeof(*rsdp));
+    memcpy(&rsdp->signature, "RSD PTR ", sizeof(rsdp->signature));
+    memcpy(rsdp->oem_id, ACPI_BUILD_APPNAME6, sizeof(rsdp->oem_id));
+    rsdp->length = sizeof(*rsdp);
+    rsdp->revision = 0x02;
+    rsdp->checksum = 0;
+
+    dom->acpitable_blob->rsdp.table = (void *)rsdp;
+    /* Align to 64bit. */
+    dom->acpitable_blob->rsdp.size = sizeof(*rsdp);
+    dom->acpitable_size += dom->acpitable_blob->rsdp.size;
+}
+
 static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
@@ -1111,6 +1128,7 @@ static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 	return rc;
 
     make_acpi_xsdt(gc, dom);
+    make_acpi_rsdp(gc, dom);
 
     return 0;
 }
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 11/14] libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (9 preceding siblings ...)
  2016-05-31  5:03 ` [PATCH RESEND 10/14] libxl/arm: Construct ACPI RSDP table Shannon Zhao
@ 2016-05-31  5:03 ` Shannon Zhao
  2016-05-31  5:03 ` [PATCH RESEND 12/14] libxl/arm: Add ACPI module Shannon Zhao
                   ` (6 subsequent siblings)
  17 siblings, 0 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:03 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

If Xen guest boots with ACPI, the guest kernel will get the event
channel interrupt information via domain param HVM_PARAM_CALLBACK_IRQ.
Initialize that domain param.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/libxl_arm.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 1bef9b0..13259f8 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1105,6 +1105,7 @@ static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 {
     const libxl_version_info *vers;
     int rc;
+    uint64_t val;
 
     /* convenience aliases */
     xc_domain_configuration_t *xc_config = &state->config;
@@ -1130,7 +1131,12 @@ static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
     make_acpi_xsdt(gc, dom);
     make_acpi_rsdp(gc, dom);
 
-    return 0;
+    /* Set the value of domain param HVM_PARAM_CALLBACK_IRQ. */
+    val = (uint64_t)HVM_PARAM_CALLBACK_TYPE_PPI << 56;
+    val |= (2 << 8); /* Active-low level-sensitive  */
+    val |= GUEST_EVTCHN_PPI & 0xff;
+    return xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CALLBACK_IRQ,
+                            val);
 }
 
 int libxl__arch_domain_init_hw_description(libxl__gc *gc,
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 12/14] libxl/arm: Add ACPI module
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (10 preceding siblings ...)
  2016-05-31  5:03 ` [PATCH RESEND 11/14] libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ Shannon Zhao
@ 2016-05-31  5:03 ` Shannon Zhao
  2016-06-07 13:47   ` Julien Grall
  2016-05-31  5:03 ` [PATCH RESEND 13/14] libxl/arm: initialize memory information of ACPI blob Shannon Zhao
                   ` (5 subsequent siblings)
  17 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:03 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

Add the ARM Multiboot module for ACPI, so UEFI can get the base address
of ACPI tables from it.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/libxl_arm.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 13259f8..e7cb578 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -285,6 +285,26 @@ static int make_chosen_node(libxl__gc *gc, void *fdt, bool ramdisk,
         if (res) return res;
     }
 
+    res = fdt_begin_node(fdt, "modules");
+    if (res) return res;
+
+    res = fdt_begin_node(fdt, "module@0");
+    if (res) return res;
+
+    res = fdt_property_compat(gc, fdt, 2, "xen,linux-acpi",
+                              "xen,multiboot-module");
+    if (res) return res;
+
+    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
+                                1, 0, 0);
+    if (res) return res;
+
+    res = fdt_end_node(fdt);
+    if (res) return res;
+
+    res = fdt_end_node(fdt);
+    if (res) return res;
+
     res = fdt_end_node(fdt);
     if (res) return res;
 
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 13/14] libxl/arm: initialize memory information of ACPI blob
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (11 preceding siblings ...)
  2016-05-31  5:03 ` [PATCH RESEND 12/14] libxl/arm: Add ACPI module Shannon Zhao
@ 2016-05-31  5:03 ` Shannon Zhao
  2016-06-06 11:40   ` Stefano Stabellini
  2016-05-31  5:03 ` [PATCH RESEND 14/14] libxc/xc_dom_core: Copy ACPI tables to guest memory space Shannon Zhao
                   ` (4 subsequent siblings)
  17 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:03 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

Assign the guest memory space for ACPI tables and replace the reg in DT
with real values.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxc/xc_dom_arm.c | 16 +++++++++++++++-
 tools/libxl/libxl_arm.c  | 40 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 64a8b67..e21e3e9 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -383,9 +383,11 @@ static int meminit(struct xc_dom_image *dom)
     const uint64_t kernsize = kernend - kernbase;
     const uint64_t dtb_size = dom->devicetree_blob ?
         ROUNDUP(dom->devicetree_size, XC_PAGE_SHIFT) : 0;
+    const uint64_t acpi_size = dom->acpitable_blob ?
+        ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) : 0;
     const uint64_t ramdisk_size = dom->ramdisk_blob ?
         ROUNDUP(dom->ramdisk_size, XC_PAGE_SHIFT) : 0;
-    const uint64_t modsize = dtb_size + ramdisk_size;
+    const uint64_t modsize = dtb_size + acpi_size + ramdisk_size;
     const uint64_t ram128mb = bankbase[0] + (128<<20);
 
     xen_pfn_t p2m_size;
@@ -500,6 +502,18 @@ static int meminit(struct xc_dom_image *dom)
         modbase += dtb_size;
     }
 
+    if ( acpi_size )
+    {
+        dom->acpi_seg.vstart = modbase;
+        dom->acpi_seg.vend = modbase + acpi_size;
+
+        DOMPRINTF("%s: acpi: 0x%" PRIx64 " -> 0x%" PRIx64 "",
+                  __FUNCTION__,
+                  dom->acpi_seg.vstart, dom->acpi_seg.vend);
+
+        modbase += dtb_size;
+    }
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index e7cb578..bf1eeea 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -230,6 +230,27 @@ static int fdt_property_regs(libxl__gc *gc, void *fdt,
     return fdt_property(fdt, "reg", regs, sizeof(regs));
 }
 
+static int fdt_property_inplace_regs(void *fdt, int nodeoffset,
+                                     unsigned addr_cells, unsigned size_cells,
+                                     unsigned num_regs, ...)
+{
+    uint32_t regs[num_regs*(addr_cells+size_cells)];
+    be32 *cells = &regs[0];
+    int i;
+    va_list ap;
+    uint64_t base, size;
+
+    va_start(ap, num_regs);
+    for (i = 0 ; i < num_regs; i++) {
+        base = addr_cells ? va_arg(ap, uint64_t) : 0;
+        size = size_cells ? va_arg(ap, uint64_t) : 0;
+        set_range(&cells, addr_cells, size_cells, base, size);
+    }
+    va_end(ap);
+
+    return fdt_setprop_inplace(fdt, nodeoffset, "reg", regs, sizeof(regs));
+}
+
 static int make_root_properties(libxl__gc *gc,
                                 const libxl_version_info *vers,
                                 void *fdt)
@@ -1209,6 +1230,8 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
 
     const struct xc_dom_seg *ramdisk = dom->ramdisk_blob ?
         &dom->ramdisk_seg : NULL;
+    const struct xc_dom_seg *acpi = dom->acpitable_blob ?
+        &dom->acpi_seg : NULL;
 
     if (ramdisk) {
         int chosen, res;
@@ -1238,6 +1261,23 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
 
     }
 
+    if (acpi)
+    {
+        int module, res;
+
+        module = fdt_path_offset(fdt, "/chosen/modules/module@0");
+        assert(module > 0);
+
+        LOG(DEBUG, "/chosen/modules/module@0 updating acpi properties to cover "
+            "%"PRIx64"-%"PRIx64,
+            acpi->vstart, acpi->vend);
+
+        res = fdt_property_inplace_regs(fdt, module, ROOT_ADDRESS_CELLS,
+                                        ROOT_SIZE_CELLS, 1, acpi->vstart,
+                                        acpi->vend - acpi->vstart + 1);
+        assert(!res);
+    }
+
     for (i = 0; i < GUEST_RAM_BANKS; i++) {
         const uint64_t size = (uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT;
 
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* [PATCH RESEND 14/14] libxc/xc_dom_core: Copy ACPI tables to guest memory space
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (12 preceding siblings ...)
  2016-05-31  5:03 ` [PATCH RESEND 13/14] libxl/arm: initialize memory information of ACPI blob Shannon Zhao
@ 2016-05-31  5:03 ` Shannon Zhao
  2016-05-31 10:47 ` [PATCH RESEND 00/14] Xen ARM DomU ACPI support Julien Grall
                   ` (3 subsequent siblings)
  17 siblings, 0 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31  5:03 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng,
	julien.grall, shannon.zhao

From: Shannon Zhao <shannon.zhao@linaro.org>

Copy all the ACPI tables to guest memory space and also initialize the
address of the tables.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxc/xc_dom_core.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index 55c779d..6d91a46 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -33,6 +33,7 @@
 
 #include "xg_private.h"
 #include "xc_dom.h"
+#include "acpi_defs.h"
 
 /* ------------------------------------------------------------------------ */
 /* debugging                                                                */
@@ -1096,6 +1097,64 @@ int xc_dom_build_image(struct xc_dom_image *dom)
         memcpy(devicetreemap, dom->devicetree_blob, dom->devicetree_size);
     }
 
+    /* load ACPI tables */
+    if ( dom->acpitable_blob )
+    {
+        void *acpitablemap;
+        uint64_t start = dom->acpi_seg.vstart;
+        struct acpi_xsdt_descriptor *xsdt;
+        struct acpi_rsdp_descriptor *rsdp;
+        struct acpi_fadt_descriptor *fadt;
+
+        if ( xc_dom_alloc_segment(dom, &dom->acpi_seg, "acpitable",
+                                  start, dom->acpitable_size) != 0 )
+            goto err;
+
+        acpitablemap = xc_dom_seg_to_ptr(dom, &dom->acpi_seg);
+        if ( acpitablemap == NULL )
+        {
+            DOMPRINTF("%s: xc_dom_seg_to_ptr(dom, &dom->acpi_seg) => NULL",
+                      __FUNCTION__);
+            goto err;
+        }
+
+        rsdp = (struct acpi_rsdp_descriptor *)acpitablemap;
+        memcpy(acpitablemap, dom->acpitable_blob->rsdp.table,
+               dom->acpitable_blob->rsdp.size);
+        start += dom->acpitable_blob->rsdp.size;
+        acpitablemap += dom->acpitable_blob->rsdp.size;
+
+        xsdt = (struct acpi_xsdt_descriptor *)acpitablemap;
+        memcpy(acpitablemap, dom->acpitable_blob->xsdt.table,
+               dom->acpitable_blob->xsdt.size);
+        rsdp->xsdt_physical_address = start;
+        start += dom->acpitable_blob->xsdt.size;
+        acpitablemap += dom->acpitable_blob->xsdt.size;
+
+        memcpy(acpitablemap, dom->acpitable_blob->madt.table,
+               dom->acpitable_blob->madt.size);
+        xsdt->entry[0] = start;
+        start += dom->acpitable_blob->madt.size;
+        acpitablemap += dom->acpitable_blob->madt.size;
+
+        memcpy(acpitablemap, dom->acpitable_blob->gtdt.table,
+               dom->acpitable_blob->gtdt.size);
+        xsdt->entry[1] = start;
+        start += dom->acpitable_blob->gtdt.size;
+        acpitablemap += dom->acpitable_blob->gtdt.size;
+
+        fadt = (struct acpi_fadt_descriptor *)acpitablemap;
+        memcpy(acpitablemap, dom->acpitable_blob->fadt.table,
+               dom->acpitable_blob->fadt.size);
+        xsdt->entry[2] = start;
+        start += dom->acpitable_blob->fadt.size;
+        acpitablemap += dom->acpitable_blob->fadt.size;
+
+        memcpy(acpitablemap, dom->acpitable_blob->dsdt.table,
+               dom->acpitable_blob->dsdt.size);
+        fadt->dsdt = start;
+    }
+
     /* allocate other pages */
     if ( !dom->arch_hooks->p2m_base_supported ||
          dom->parms.p2m_base >= dom->parms.virt_base ||
-- 
2.0.4



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

^ permalink raw reply related	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (13 preceding siblings ...)
  2016-05-31  5:03 ` [PATCH RESEND 14/14] libxc/xc_dom_core: Copy ACPI tables to guest memory space Shannon Zhao
@ 2016-05-31 10:47 ` Julien Grall
  2016-05-31 14:19   ` Shannon Zhao
  2016-06-03 19:24 ` Wei Liu
                   ` (2 subsequent siblings)
  17 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-05-31 10:47 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng

Hi Shannon,

On 31/05/16 06:02, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> The design of this feature is described as below.
> Firstly, the toolstack (libxl) generates the ACPI tables according the
> number of vcpus and gic controller.
>
> Then, it copies these ACPI tables to DomU memory space and passes
> them to UEFI firmware through the "ARM multiboot" protocol.
>
> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
> and installs these tables like the usual way and passes both ACPI and DT
> information to the Xen DomU.
>
> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
> since it's enough now.
>
> This has been tested using guest kernel with the Dom0 ACPI support
> patches which could be fetched from:
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen

Where can I find the UEFI firmware? What is the guest configuration to use?

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-05-31 10:47 ` [PATCH RESEND 00/14] Xen ARM DomU ACPI support Julien Grall
@ 2016-05-31 14:19   ` Shannon Zhao
  0 siblings, 0 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-05-31 14:19 UTC (permalink / raw)
  To: Julien Grall, Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, peter.huangpeng

Hi Julien,

On 2016年05月31日 18:47, Julien Grall wrote:
> Hi Shannon,
> 
> On 31/05/16 06:02, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> The design of this feature is described as below.
>> Firstly, the toolstack (libxl) generates the ACPI tables according the
>> number of vcpus and gic controller.
>>
>> Then, it copies these ACPI tables to DomU memory space and passes
>> them to UEFI firmware through the "ARM multiboot" protocol.
>>
>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>> and installs these tables like the usual way and passes both ACPI and DT
>> information to the Xen DomU.
>>
>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
>> since it's enough now.
>>
>> This has been tested using guest kernel with the Dom0 ACPI support
>> patches which could be fetched from:
>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>
> 
> Where can I find the UEFI firmware? What is the guest configuration to use?
> 
The corresponding UEFI patch can be found from below url:
https://www.mail-archive.com/xen-devel@lists.xen.org/msg69468.html

You can use the above guest kernel with defconfig.

Thanks,
-- 
Shannon

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (14 preceding siblings ...)
  2016-05-31 10:47 ` [PATCH RESEND 00/14] Xen ARM DomU ACPI support Julien Grall
@ 2016-06-03 19:24 ` Wei Liu
  2016-06-03 20:02   ` Konrad Rzeszutek Wilk
  2016-06-06 11:41 ` Stefano Stabellini
  2016-06-06 12:26 ` Wei Liu
  17 siblings, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-06-03 19:24 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> The design of this feature is described as below.
> Firstly, the toolstack (libxl) generates the ACPI tables according the
> number of vcpus and gic controller.
> 
> Then, it copies these ACPI tables to DomU memory space and passes
> them to UEFI firmware through the "ARM multiboot" protocol.
> 
> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
> and installs these tables like the usual way and passes both ACPI and DT
> information to the Xen DomU.
> 
> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
> since it's enough now.
> 
> This has been tested using guest kernel with the Dom0 ACPI support
> patches which could be fetched from:
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
> 
> Shannon Zhao (14):
>   libxl/arm: Fix the function name in error log
>   libxl/arm: Factor out codes for generating DTB
>   libxc: Add placeholders for ACPI tables blob and size
>   tools: add ACPI tables relevant definitions
>   libxl/arm: Construct ACPI GTDT table
>   libxl/arm: Construct ACPI FADT table
>   libxl/arm: Construct ACPI DSDT table
>   libxl/arm: Construct ACPI MADT table
>   libxl/arm: Construct ACPI XSDT table
>   libxl/arm: Construct ACPI RSDP table
>   libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>   libxl/arm: Add ACPI module
>   libxl/arm: initialize memory information of ACPI blob
>   libxc/xc_dom_core: Copy ACPI tables to guest memory space
> 
>  tools/libxc/include/acpi_defs.h | 277 ++++++++++++++++++++++++++++++++
>  tools/libxc/include/xc_dom.h    |  17 ++
>  tools/libxc/xc_dom_arm.c        |  16 +-
>  tools/libxc/xc_dom_core.c       |  59 +++++++
>  tools/libxl/libxl_arm.c         | 345 +++++++++++++++++++++++++++++++++++++++-
>  5 files changed, 706 insertions(+), 8 deletions(-)
>  create mode 100644 tools/libxc/include/acpi_defs.h
> 

I seem to remember someone suggested that x86 and arm share some code.
Is that suggestion taken? Shall I review this series?

Wei.

> -- 
> 2.0.4
> 
> 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 01/14] libxl/arm: Fix the function name in error log
  2016-05-31  5:02 ` [PATCH RESEND 01/14] libxl/arm: Fix the function name in error log Shannon Zhao
@ 2016-06-03 19:25   ` Wei Liu
  2016-06-17 10:46     ` Wei Liu
  0 siblings, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-06-03 19:25 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On Tue, May 31, 2016 at 01:02:53PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> It should be xc_dom_devicetree_mem instead of xc_dom_devicetree_file.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>

Acked-by: Wei Liu <wei.liu2@citrix.com>

> ---
>  tools/libxl/libxl_arm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 1195b37..c6d77e3 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -872,7 +872,7 @@ next_resize:
>  
>      res = xc_dom_devicetree_mem(dom, fdt, fdt_totalsize(fdt));
>      if (res) {
> -        LOGE(ERROR, "xc_dom_devicetree_file failed");
> +        LOGE(ERROR, "xc_dom_devicetree_mem failed");
>          rc = ERROR_FAIL;
>          goto out;
>      }
> -- 
> 2.0.4
> 
> 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 02/14] libxl/arm: Factor out codes for generating DTB
  2016-05-31  5:02 ` [PATCH RESEND 02/14] libxl/arm: Factor out codes for generating DTB Shannon Zhao
@ 2016-06-03 19:25   ` Wei Liu
  0 siblings, 0 replies; 104+ messages in thread
From: Wei Liu @ 2016-06-03 19:25 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On Tue, May 31, 2016 at 01:02:54PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> Factor out codes for generating DTB to prepare for adding ACPI tables
> generation codes.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  tools/libxl/libxl_arm.c | 18 ++++++++++++------
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index c6d77e3..9e99159 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -747,10 +747,9 @@ static int copy_partial_fdt(libxl__gc *gc, void *fdt, void *pfdt)
>  
>  #define FDT_MAX_SIZE (1<<20)
>  
> -int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> -                                           libxl_domain_build_info *info,
> -                                           libxl__domain_build_state *state,
> -                                           struct xc_dom_image *dom)
> +static int prepare_dtb(libxl__gc *gc, libxl_domain_build_info *info,
> +                       libxl__domain_build_state *state,
> +                       struct xc_dom_image *dom)

Please name this function libxl__prepare_dtb.

Other than this:

Acked-by: Wei Liu <wei.liu2@citrix.com>

>  {
>      void *fdt = NULL;
>      void *pfdt = NULL;
> @@ -764,8 +763,6 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>      /* convenience aliases */
>      xc_domain_configuration_t *xc_config = &state->config;
>  
> -    assert(info->type == LIBXL_DOMAIN_TYPE_PV);
> -
>      vers = libxl_get_version_info(CTX);
>      if (vers == NULL) return ERROR_FAIL;
>  
> @@ -883,6 +880,15 @@ out:
>      return rc;
>  }
>  
> +int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> +                                           libxl_domain_build_info *info,
> +                                           libxl__domain_build_state *state,
> +                                           struct xc_dom_image *dom)
> +{
> +    assert(info->type == LIBXL_DOMAIN_TYPE_PV);
> +    return prepare_dtb(gc, info, state, dom);
> +}
> +
>  static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
>                                       uint64_t base, uint64_t size)
>  {
> -- 
> 2.0.4
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-03 19:24 ` Wei Liu
@ 2016-06-03 20:02   ` Konrad Rzeszutek Wilk
  2016-06-03 20:20     ` Boris Ostrovsky
  0 siblings, 1 reply; 104+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-06-03 20:02 UTC (permalink / raw)
  To: wei Liu, boris.ostrovsky, roger.pau
  Cc: sstabellini, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao, Shannon Zhao

On Fri, Jun 03, 2016 at 08:24:53PM +0100, Wei Liu wrote:
> On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@linaro.org>
> > 
> > The design of this feature is described as below.
> > Firstly, the toolstack (libxl) generates the ACPI tables according the
> > number of vcpus and gic controller.
> > 
> > Then, it copies these ACPI tables to DomU memory space and passes
> > them to UEFI firmware through the "ARM multiboot" protocol.
> > 
> > At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
> > and installs these tables like the usual way and passes both ACPI and DT
> > information to the Xen DomU.
> > 
> > Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
> > since it's enough now.
> > 
> > This has been tested using guest kernel with the Dom0 ACPI support
> > patches which could be fetched from:
> > https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
> > 
> > Shannon Zhao (14):
> >   libxl/arm: Fix the function name in error log
> >   libxl/arm: Factor out codes for generating DTB
> >   libxc: Add placeholders for ACPI tables blob and size
> >   tools: add ACPI tables relevant definitions
> >   libxl/arm: Construct ACPI GTDT table
> >   libxl/arm: Construct ACPI FADT table
> >   libxl/arm: Construct ACPI DSDT table
> >   libxl/arm: Construct ACPI MADT table
> >   libxl/arm: Construct ACPI XSDT table
> >   libxl/arm: Construct ACPI RSDP table
> >   libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
> >   libxl/arm: Add ACPI module
> >   libxl/arm: initialize memory information of ACPI blob
> >   libxc/xc_dom_core: Copy ACPI tables to guest memory space
> > 
> >  tools/libxc/include/acpi_defs.h | 277 ++++++++++++++++++++++++++++++++
> >  tools/libxc/include/xc_dom.h    |  17 ++
> >  tools/libxc/xc_dom_arm.c        |  16 +-
> >  tools/libxc/xc_dom_core.c       |  59 +++++++
> >  tools/libxl/libxl_arm.c         | 345 +++++++++++++++++++++++++++++++++++++++-
> >  5 files changed, 706 insertions(+), 8 deletions(-)
> >  create mode 100644 tools/libxc/include/acpi_defs.h
> > 
> 
> I seem to remember someone suggested that x86 and arm share some code.

That was me.
> Is that suggestion taken? Shall I review this series?

Boris, Roger?

I think the idea was that some of it could be - like the ACPI RSDT?

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

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-03 20:02   ` Konrad Rzeszutek Wilk
@ 2016-06-03 20:20     ` Boris Ostrovsky
  2016-06-03 20:27       ` Wei Liu
  0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-06-03 20:20 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk, wei Liu, roger.pau
  Cc: sstabellini, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao, Shannon Zhao

On 06/03/2016 04:02 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 03, 2016 at 08:24:53PM +0100, Wei Liu wrote:
>>
>> I seem to remember someone suggested that x86 and arm share some code.
> That was me.
>> Is that suggestion taken? Shall I review this series?
> Boris, Roger?
>
> I think the idea was that some of it could be - like the ACPI RSDT?


Given how much difference there is between ARM and x86 APCI it's not
clear whether we should try to do this now. Only a couple of tables may
be in common.

I suggest we wait with trying to merge this until PVHv2 dom0 support is
there and then see what we can do with both userland and hypervisor/dom0
ACPI.

-boris




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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-03 20:20     ` Boris Ostrovsky
@ 2016-06-03 20:27       ` Wei Liu
  2016-06-03 20:36         ` Boris Ostrovsky
  0 siblings, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-06-03 20:27 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: sstabellini, wei Liu, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao, Shannon Zhao, roger.pau

On Fri, Jun 03, 2016 at 04:20:55PM -0400, Boris Ostrovsky wrote:
> On 06/03/2016 04:02 PM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jun 03, 2016 at 08:24:53PM +0100, Wei Liu wrote:
> >>
> >> I seem to remember someone suggested that x86 and arm share some code.
> > That was me.
> >> Is that suggestion taken? Shall I review this series?
> > Boris, Roger?
> >
> > I think the idea was that some of it could be - like the ACPI RSDT?
> 
> 
> Given how much difference there is between ARM and x86 APCI it's not
> clear whether we should try to do this now. Only a couple of tables may
> be in common.
> 
> I suggest we wait with trying to merge this until PVHv2 dom0 support is
> there and then see what we can do with both userland and hypervisor/dom0
> ACPI.
> 

OK. FAOD you don't suggest this series to wait until that happens,
right? I.e. we should still aim to get something for ARM and possibly
merge two implementations later.

Wei.

> -boris
> 
> 
> 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-03 20:27       ` Wei Liu
@ 2016-06-03 20:36         ` Boris Ostrovsky
  0 siblings, 0 replies; 104+ messages in thread
From: Boris Ostrovsky @ 2016-06-03 20:36 UTC (permalink / raw)
  To: Wei Liu
  Cc: sstabellini, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao, Shannon Zhao, roger.pau

On 06/03/2016 04:27 PM, Wei Liu wrote:
> On Fri, Jun 03, 2016 at 04:20:55PM -0400, Boris Ostrovsky wrote:
>> On 06/03/2016 04:02 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Jun 03, 2016 at 08:24:53PM +0100, Wei Liu wrote:
>>>> I seem to remember someone suggested that x86 and arm share some code.
>>> That was me.
>>>> Is that suggestion taken? Shall I review this series?
>>> Boris, Roger?
>>>
>>> I think the idea was that some of it could be - like the ACPI RSDT?
>>
>> Given how much difference there is between ARM and x86 APCI it's not
>> clear whether we should try to do this now. Only a couple of tables may
>> be in common.
>>
>> I suggest we wait with trying to merge this until PVHv2 dom0 support is
>> there and then see what we can do with both userland and hypervisor/dom0
>> ACPI.
>>
> OK. FAOD you don't suggest this series to wait until that happens,
> right? I.e. we should still aim to get something for ARM and possibly
> merge two implementations later.

Right.

-boris


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-05-31  5:02 ` [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size Shannon Zhao
@ 2016-06-06 10:00   ` Stefano Stabellini
  2016-06-06 12:16     ` Wei Liu
  2016-06-07 11:05   ` Julien Grall
  1 sibling, 1 reply; 104+ messages in thread
From: Stefano Stabellini @ 2016-06-06 10:00 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On Tue, 31 May 2016, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@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.zhao@linaro.org>

If we are going to make this ARM only, then maybe we should consider
moving these structs to an ARM specific header?


>  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;
> +};
> +
>  struct xc_dom_image {
>      /* files */
>      void *kernel_blob;
> @@ -64,6 +78,8 @@ struct xc_dom_image {
>      size_t ramdisk_size;
>      void *devicetree_blob;
>      size_t devicetree_size;
> +    struct acpitable_blob *acpitable_blob;
> +    size_t acpitable_size;
>  
>      size_t max_kernel_size;
>      size_t max_ramdisk_size;
> @@ -92,6 +108,7 @@ struct xc_dom_image {
>      struct xc_dom_seg p2m_seg;
>      struct xc_dom_seg pgtables_seg;
>      struct xc_dom_seg devicetree_seg;
> +    struct xc_dom_seg acpi_seg;
>      struct xc_dom_seg start_info_seg; /* HVMlite only */
>      xen_pfn_t start_info_pfn;
>      xen_pfn_t console_pfn;
> -- 
> 2.0.4
> 
> 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions
  2016-05-31  5:02 ` [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions Shannon Zhao
@ 2016-06-06 10:04   ` Stefano Stabellini
  2016-06-06 10:11     ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Stefano Stabellini @ 2016-06-06 10:04 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On Tue, 31 May 2016, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> Add ACPI tables relevant definitions for generating ACPI tables for ARM
> guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT tables will
> be used.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  tools/libxc/include/acpi_defs.h | 277 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 277 insertions(+)
>  create mode 100644 tools/libxc/include/acpi_defs.h
> 
> diff --git a/tools/libxc/include/acpi_defs.h b/tools/libxc/include/acpi_defs.h
> new file mode 100644
> index 0000000..9389a96
> --- /dev/null
> +++ b/tools/libxc/include/acpi_defs.h
> @@ -0,0 +1,277 @@
> +#ifndef _ACPI_DEFS_H_
> +#define _ACPI_DEFS_H_
> +
> +#define ACPI_BUILD_APPNAME6 "XenARM"
> +#define ACPI_BUILD_APPNAME4 "Xen "

This header is actually ARM specific (also see the gic stuff below). It
is probably best to rename it to acpi_arm_defs.h.


> +#pragma pack (1)
> +
> +/* Root System Description Pointer Structure. */
> +struct acpi_rsdp_descriptor {        /* Root System Descriptor Pointer */
> +    uint64_t signature;              /* ACPI signature, contains "RSD PTR " */
> +    uint8_t  checksum;               /* To make sum of struct == 0 */
> +    uint8_t  oem_id[6];             /* OEM identification */
> +    uint8_t  revision;               /* Must be 0 for 1.0, 2 for 2.0 */
> +    uint32_t rsdt_physical_address;  /* 32-bit physical address of RSDT */
> +    uint32_t length;                 /* XSDT Length in bytes including hdr */
> +    uint64_t xsdt_physical_address;  /* 64-bit physical address of XSDT */
> +    uint8_t  extended_checksum;      /* Checksum of entire table */
> +    uint8_t  reserved[3];           /* Reserved field must be 0 */
> +};
> +
> +/* ACPI common table header. */
> +struct acpi_table_header {
> +    uint32_t signature;          /* ACPI signature (4 ASCII characters) */ \
> +    uint32_t length;                 /* Length of table, in bytes, including header */ \
> +    uint8_t  revision;               /* ACPI Specification minor version # */ \
> +    uint8_t  checksum;               /* To make sum of entire table == 0 */ \
> +    uint8_t  oem_id[6];             /* OEM identification */ \
> +    uint8_t  oem_table_id[8];       /* OEM table identification */ \
> +    uint32_t oem_revision;           /* OEM revision number */ \
> +    uint8_t  asl_compiler_id[4];    /* ASL compiler vendor ID */ \
> +    uint32_t asl_compiler_revision;  /* ASL compiler revision number */
> +};
> +
> +/* Extended System Description Table (XSDT). */
> +struct acpi_xsdt_descriptor {
> +    struct acpi_table_header header;
> +    uint64_t entry[0];
> +};
> +
> +/* Generic Timer Description Table (GTDT). */
> +#define ACPI_GTDT_INTERRUPT_MODE        0
> +#define ACPI_GTDT_INTERRUPT_POLARITY    1
> +#define ACPI_GTDT_ALWAYS_ON             2
> +
> +/* Triggering */
> +#define ACPI_LEVEL_SENSITIVE            ((uint8_t) 0x00)
> +#define ACPI_EDGE_SENSITIVE             ((uint8_t) 0x01)
> +
> +/* Polarity */
> +#define ACPI_ACTIVE_HIGH                ((uint8_t) 0x00)
> +#define ACPI_ACTIVE_LOW                 ((uint8_t) 0x01)
> +
> +struct acpi_gtdt_descriptor {
> +    struct acpi_table_header header;
> +    uint64_t counter_block_addresss;
> +    uint32_t reserved;
> +    uint32_t secure_el1_interrupt;
> +    uint32_t secure_el1_flags;
> +    uint32_t non_secure_el1_interrupt;
> +    uint32_t non_secure_el1_flags;
> +    uint32_t virtual_timer_interrupt;
> +    uint32_t virtual_timer_flags;
> +    uint32_t non_secure_el2_interrupt;
> +    uint32_t non_secure_el2_flags;
> +    uint64_t counter_read_block_address;
> +    uint32_t platform_timer_count;
> +    uint32_t platform_timer_offset;
> +};
> +
> +/* Multiple APIC Description Table header definition (MADT). */
> +struct acpi_madt_descriptor
> +{
> +    struct acpi_table_header header;     /* ACPI common table header */
> +    uint32_t local_apic_address;     /* Physical address of local APIC */
> +    uint32_t flags;
> +};
> +
> +/* Values for Type in APIC sub-headers. */
> +
> +#define ACPI_APIC_PROCESSOR          0
> +#define ACPI_APIC_IO                 1
> +#define ACPI_APIC_XRUPT_OVERRIDE     2
> +#define ACPI_APIC_NMI                3
> +#define ACPI_APIC_LOCAL_NMI          4
> +#define ACPI_APIC_ADDRESS_OVERRIDE   5
> +#define ACPI_APIC_IO_SAPIC           6
> +#define ACPI_APIC_LOCAL_SAPIC        7
> +#define ACPI_APIC_XRUPT_SOURCE       8
> +#define ACPI_APIC_LOCAL_X2APIC       9
> +#define ACPI_APIC_LOCAL_X2APIC_NMI      10
> +#define ACPI_APIC_GENERIC_INTERRUPT     11
> +#define ACPI_APIC_GENERIC_DISTRIBUTOR   12
> +#define ACPI_APIC_GENERIC_MSI_FRAME     13
> +#define ACPI_APIC_GENERIC_REDISTRIBUTOR 14
> +#define ACPI_APIC_RESERVED              15   /* 15 and greater are reserved */
> +
> +/*
> + * MADT sub-structures (Follow MULTIPLE_APIC_DESCRIPTION_TABLE).
> + */
> +#define ACPI_SUB_HEADER_DEF   /* Common ACPI sub-structure header */\
> +    uint8_t  type;                               \
> +    uint8_t  length;
> +
> +/* Sub-structures for MADT */
> +
> +struct acpi_madt_generic_interrupt {
> +    ACPI_SUB_HEADER_DEF
> +    uint16_t reserved;
> +    uint32_t cpu_interface_number;
> +    uint32_t uid;
> +    uint32_t flags;
> +    uint32_t parking_version;
> +    uint32_t performance_interrupt;
> +    uint64_t parked_address;
> +    uint64_t base_address;
> +    uint64_t gicv_base_address;
> +    uint64_t gich_base_address;
> +    uint32_t vgic_interrupt;
> +    uint64_t gicr_base_address;
> +    uint64_t arm_mpidr;
> +};
> +
> +struct acpi_madt_generic_distributor {
> +    ACPI_SUB_HEADER_DEF
> +    uint16_t reserved;
> +    uint32_t gic_id;
> +    uint64_t base_address;
> +    uint32_t global_irq_base;
> +    uint8_t version;
> +    uint8_t reserved2[3];
> +};
> +
> +struct acpi_madt_generic_msi_frame {
> +    ACPI_SUB_HEADER_DEF
> +    uint16_t reserved;
> +    uint32_t gic_msi_frame_id;
> +    uint64_t base_address;
> +    uint32_t flags;
> +    uint16_t spi_count;
> +    uint16_t spi_base;
> +};
> +
> +struct acpi_madt_generic_redistributor {
> +    ACPI_SUB_HEADER_DEF
> +    uint16_t reserved;
> +    uint64_t base_address;
> +    uint32_t range_length;
> +};
> +
> +enum {
> +    ACPI_FADT_F_WBINVD,
> +    ACPI_FADT_F_WBINVD_FLUSH,
> +    ACPI_FADT_F_PROC_C1,
> +    ACPI_FADT_F_P_LVL2_UP,
> +    ACPI_FADT_F_PWR_BUTTON,
> +    ACPI_FADT_F_SLP_BUTTON,
> +    ACPI_FADT_F_FIX_RTC,
> +    ACPI_FADT_F_RTC_S4,
> +    ACPI_FADT_F_TMR_VAL_EXT,
> +    ACPI_FADT_F_DCK_CAP,
> +    ACPI_FADT_F_RESET_REG_SUP,
> +    ACPI_FADT_F_SEALED_CASE,
> +    ACPI_FADT_F_HEADLESS,
> +    ACPI_FADT_F_CPU_SW_SLP,
> +    ACPI_FADT_F_PCI_EXP_WAK,
> +    ACPI_FADT_F_USE_PLATFORM_CLOCK,
> +    ACPI_FADT_F_S4_RTC_STS_VALID,
> +    ACPI_FADT_F_REMOTE_POWER_ON_CAPABLE,
> +    ACPI_FADT_F_FORCE_APIC_CLUSTER_MODEL,
> +    ACPI_FADT_F_FORCE_APIC_PHYSICAL_DESTINATION_MODE,
> +    ACPI_FADT_F_HW_REDUCED_ACPI,
> +    ACPI_FADT_F_LOW_POWER_S0_IDLE_CAPABLE,
> +};
> +
> +enum {
> +    ACPI_FADT_ARM_USE_PSCI_G_0_2 = 0,
> +    ACPI_FADT_ARM_PSCI_USE_HVC = 1,
> +};
> +
> +struct acpi_generic_address {
> +    uint8_t space_id;        /* Address space where struct or register exists */
> +    uint8_t bit_width;       /* Size in bits of given register */
> +    uint8_t bit_offset;      /* Bit offset within the register */
> +    uint8_t access_width;    /* Minimum Access size (ACPI 3.0) */
> +    uint64_t address;        /* 64-bit address of struct or register */
> +};
> +
> +struct acpi_fadt_descriptor {
> +    struct acpi_table_header header;    /* ACPI common table header */ \
> +    uint32_t firmware_ctrl;  /* Physical address of FACS */ \
> +    uint32_t dsdt;         /* Physical address of DSDT */ \
> +    uint8_t  model;        /* System Interrupt Model */ \
> +    uint8_t  reserved1;    /* Reserved */ \
> +    uint16_t sci_int;      /* System vector of SCI interrupt */ \
> +    uint32_t smi_cmd;      /* Port address of SMI command port */ \
> +    uint8_t  acpi_enable;  /* Value to write to smi_cmd to enable ACPI */ \
> +    uint8_t  acpi_disable; /* Value to write to smi_cmd to disable ACPI */ \
> +    /* Value to write to SMI CMD to enter S4BIOS state */ \
> +    uint8_t  S4bios_req; \
> +    uint8_t  reserved2;    /* Reserved - must be zero */ \
> +    /* Port address of Power Mgt 1a acpi_event Reg Blk */ \
> +    uint32_t pm1a_evt_blk; \
> +    /* Port address of Power Mgt 1b acpi_event Reg Blk */ \
> +    uint32_t pm1b_evt_blk; \
> +    uint32_t pm1a_cnt_blk; /* Port address of Power Mgt 1a Control Reg Blk */ \
> +    uint32_t pm1b_cnt_blk; /* Port address of Power Mgt 1b Control Reg Blk */ \
> +    uint32_t pm2_cnt_blk;  /* Port address of Power Mgt 2 Control Reg Blk */ \
> +    uint32_t pm_tmr_blk;   /* Port address of Power Mgt Timer Ctrl Reg Blk */ \
> +    /* Port addr of General Purpose acpi_event 0 Reg Blk */ \
> +    uint32_t gpe0_blk; \
> +    /* Port addr of General Purpose acpi_event 1 Reg Blk */ \
> +    uint32_t gpe1_blk; \
> +    uint8_t  pm1_evt_len;  /* Byte length of ports at pm1_x_evt_blk */ \
> +    uint8_t  pm1_cnt_len;  /* Byte length of ports at pm1_x_cnt_blk */ \
> +    uint8_t  pm2_cnt_len;  /* Byte Length of ports at pm2_cnt_blk */ \
> +    uint8_t  pm_tmr_len;   /* Byte Length of ports at pm_tm_blk */ \
> +    uint8_t  gpe0_blk_len; /* Byte Length of ports at gpe0_blk */ \
> +    uint8_t  gpe1_blk_len; /* Byte Length of ports at gpe1_blk */ \
> +    uint8_t  gpe1_base;    /* Offset in gpe model where gpe1 events start */ \
> +    uint8_t  reserved3;    /* Reserved */ \
> +    uint16_t plvl2_lat;    /* Worst case HW latency to enter/exit C2 state */ \
> +    uint16_t plvl3_lat;    /* Worst case HW latency to enter/exit C3 state */ \
> +    uint16_t flush_size;   /* Size of area read to flush caches */ \
> +    uint16_t flush_stride; /* Stride used in flushing caches */ \
> +    uint8_t  duty_offset;  /* Bit location of duty cycle field in p_cnt reg */ \
> +    uint8_t  duty_width;   /* Bit width of duty cycle field in p_cnt reg */ \
> +    uint8_t  day_alrm;     /* Index to day-of-month alarm in RTC CMOS RAM */ \
> +    uint8_t  mon_alrm;     /* Index to month-of-year alarm in RTC CMOS RAM */ \
> +    uint8_t  century;      /* Index to century in RTC CMOS RAM */
> +    /* IA-PC Boot Architecture Flags (see below for individual flags) */
> +    uint16_t boot_flags;
> +    uint8_t reserved;    /* Reserved, must be zero */
> +    /* Miscellaneous flag bits (see below for individual flags) */
> +    uint32_t flags;
> +    /* 64-bit address of the Reset register */
> +    struct acpi_generic_address reset_register;
> +    /* Value to write to the reset_register port to reset the system */
> +    uint8_t reset_value;
> +    /* ARM-Specific Boot Flags (see below for individual flags) (ACPI 5.1) */
> +    uint16_t arm_boot_flags;
> +    uint8_t minor_revision;  /* FADT Minor Revision (ACPI 5.1) */
> +    uint64_t Xfacs;          /* 64-bit physical address of FACS */
> +    uint64_t Xdsdt;          /* 64-bit physical address of DSDT */
> +    /* 64-bit Extended Power Mgt 1a Event Reg Blk address */
> +    struct acpi_generic_address xpm1a_event_block;
> +    /* 64-bit Extended Power Mgt 1b Event Reg Blk address */
> +    struct acpi_generic_address xpm1b_event_block;
> +    /* 64-bit Extended Power Mgt 1a Control Reg Blk address */
> +    struct acpi_generic_address xpm1a_control_block;
> +    /* 64-bit Extended Power Mgt 1b Control Reg Blk address */
> +    struct acpi_generic_address xpm1b_control_block;
> +    /* 64-bit Extended Power Mgt 2 Control Reg Blk address */
> +    struct acpi_generic_address xpm2_control_block;
> +    /* 64-bit Extended Power Mgt Timer Ctrl Reg Blk address */
> +    struct acpi_generic_address xpm_timer_block;
> +    /* 64-bit Extended General Purpose Event 0 Reg Blk address */
> +    struct acpi_generic_address xgpe0_block;
> +    /* 64-bit Extended General Purpose Event 1 Reg Blk address */
> +    struct acpi_generic_address xgpe1_block;
> +    /* 64-bit Sleep Control register (ACPI 5.0) */
> +    struct acpi_generic_address sleep_control;
> +    /* 64-bit Sleep Status register (ACPI 5.0) */
> +    struct acpi_generic_address sleep_status;
> +};
> +
> +#endif /* _ACPI_DEFS_H_ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> -- 
> 2.0.4
> 
> 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions
  2016-06-06 10:04   ` Stefano Stabellini
@ 2016-06-06 10:11     ` Julien Grall
  2016-06-06 10:27       ` Shannon Zhao
  0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-06 10:11 UTC (permalink / raw)
  To: Stefano Stabellini, Shannon Zhao
  Cc: wei.liu2, peter.huangpeng, ian.jackson, shannon.zhao, xen-devel

Hi Stefano,

On 06/06/2016 11:04, Stefano Stabellini wrote:
> On Tue, 31 May 2016, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> Add ACPI tables relevant definitions for generating ACPI tables for ARM
>> guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT tables will
>> be used.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> ---
>>  tools/libxc/include/acpi_defs.h | 277 ++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 277 insertions(+)
>>  create mode 100644 tools/libxc/include/acpi_defs.h
>>
>> diff --git a/tools/libxc/include/acpi_defs.h b/tools/libxc/include/acpi_defs.h
>> new file mode 100644
>> index 0000000..9389a96
>> --- /dev/null
>> +++ b/tools/libxc/include/acpi_defs.h
>> @@ -0,0 +1,277 @@
>> +#ifndef _ACPI_DEFS_H_
>> +#define _ACPI_DEFS_H_
>> +
>> +#define ACPI_BUILD_APPNAME6 "XenARM"
>> +#define ACPI_BUILD_APPNAME4 "Xen "
>
> This header is actually ARM specific (also see the gic stuff below). It
> is probably best to rename it to acpi_arm_defs.h.

Should not just we re-use the ACPI headers from xen/include/acpi/ ?

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions
  2016-06-06 10:11     ` Julien Grall
@ 2016-06-06 10:27       ` Shannon Zhao
  2016-06-06 12:16         ` Wei Liu
  0 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-06 10:27 UTC (permalink / raw)
  To: Julien Grall, Stefano Stabellini
  Cc: wei.liu2, peter.huangpeng, ian.jackson, shannon.zhao, xen-devel



On 2016/6/6 18:11, Julien Grall wrote:
> Hi Stefano,
> 
> On 06/06/2016 11:04, Stefano Stabellini wrote:
>> On Tue, 31 May 2016, Shannon Zhao wrote:
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> Add ACPI tables relevant definitions for generating ACPI tables for ARM
>>> guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT tables will
>>> be used.
>>>
>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>> ---
>>>  tools/libxc/include/acpi_defs.h | 277
>>> ++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 277 insertions(+)
>>>  create mode 100644 tools/libxc/include/acpi_defs.h
>>>
>>> diff --git a/tools/libxc/include/acpi_defs.h
>>> b/tools/libxc/include/acpi_defs.h
>>> new file mode 100644
>>> index 0000000..9389a96
>>> --- /dev/null
>>> +++ b/tools/libxc/include/acpi_defs.h
>>> @@ -0,0 +1,277 @@
>>> +#ifndef _ACPI_DEFS_H_
>>> +#define _ACPI_DEFS_H_
>>> +
>>> +#define ACPI_BUILD_APPNAME6 "XenARM"
>>> +#define ACPI_BUILD_APPNAME4 "Xen "
>>
>> This header is actually ARM specific (also see the gic stuff below). It
>> is probably best to rename it to acpi_arm_defs.h.
> 
> Should not just we re-use the ACPI headers from xen/include/acpi/ ?
So how to include those headers in tools/libxl/libxl_arm.c ?

Thanks,
-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 13/14] libxl/arm: initialize memory information of ACPI blob
  2016-05-31  5:03 ` [PATCH RESEND 13/14] libxl/arm: initialize memory information of ACPI blob Shannon Zhao
@ 2016-06-06 11:40   ` Stefano Stabellini
  2016-06-06 14:35     ` Shannon Zhao
  0 siblings, 1 reply; 104+ messages in thread
From: Stefano Stabellini @ 2016-06-06 11:40 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On Tue, 31 May 2016, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> Assign the guest memory space for ACPI tables and replace the reg in DT
> with real values.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  tools/libxc/xc_dom_arm.c | 16 +++++++++++++++-
>  tools/libxl/libxl_arm.c  | 40 ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 55 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> index 64a8b67..e21e3e9 100644
> --- a/tools/libxc/xc_dom_arm.c
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -383,9 +383,11 @@ static int meminit(struct xc_dom_image *dom)
>      const uint64_t kernsize = kernend - kernbase;
>      const uint64_t dtb_size = dom->devicetree_blob ?
>          ROUNDUP(dom->devicetree_size, XC_PAGE_SHIFT) : 0;
> +    const uint64_t acpi_size = dom->acpitable_blob ?
> +        ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) : 0;
>      const uint64_t ramdisk_size = dom->ramdisk_blob ?
>          ROUNDUP(dom->ramdisk_size, XC_PAGE_SHIFT) : 0;
> -    const uint64_t modsize = dtb_size + ramdisk_size;
> +    const uint64_t modsize = dtb_size + acpi_size + ramdisk_size;
>      const uint64_t ram128mb = bankbase[0] + (128<<20);
>  
>      xen_pfn_t p2m_size;
> @@ -500,6 +502,18 @@ static int meminit(struct xc_dom_image *dom)
>          modbase += dtb_size;
>      }
>  
> +    if ( acpi_size )
> +    {
> +        dom->acpi_seg.vstart = modbase;
> +        dom->acpi_seg.vend = modbase + acpi_size;
> +
> +        DOMPRINTF("%s: acpi: 0x%" PRIx64 " -> 0x%" PRIx64 "",
> +                  __FUNCTION__,
> +                  dom->acpi_seg.vstart, dom->acpi_seg.vend);
> +
> +        modbase += dtb_size;

shouldn't this be 

modbase += acpi_size

?


> +    }
> +
>      return 0;
>  }
>  
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index e7cb578..bf1eeea 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -230,6 +230,27 @@ static int fdt_property_regs(libxl__gc *gc, void *fdt,
>      return fdt_property(fdt, "reg", regs, sizeof(regs));
>  }
>  
> +static int fdt_property_inplace_regs(void *fdt, int nodeoffset,
> +                                     unsigned addr_cells, unsigned size_cells,
> +                                     unsigned num_regs, ...)
> +{
> +    uint32_t regs[num_regs*(addr_cells+size_cells)];
> +    be32 *cells = &regs[0];
> +    int i;
> +    va_list ap;
> +    uint64_t base, size;
> +
> +    va_start(ap, num_regs);
> +    for (i = 0 ; i < num_regs; i++) {
> +        base = addr_cells ? va_arg(ap, uint64_t) : 0;
> +        size = size_cells ? va_arg(ap, uint64_t) : 0;
> +        set_range(&cells, addr_cells, size_cells, base, size);
> +    }
> +    va_end(ap);
> +
> +    return fdt_setprop_inplace(fdt, nodeoffset, "reg", regs, sizeof(regs));
> +}

The va_arg stuff is a bit overkill. Also, can't you call
finalise_one_memory_node instead?


>  static int make_root_properties(libxl__gc *gc,
>                                  const libxl_version_info *vers,
>                                  void *fdt)
> @@ -1209,6 +1230,8 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
>  
>      const struct xc_dom_seg *ramdisk = dom->ramdisk_blob ?
>          &dom->ramdisk_seg : NULL;
> +    const struct xc_dom_seg *acpi = dom->acpitable_blob ?
> +        &dom->acpi_seg : NULL;
>  
>      if (ramdisk) {
>          int chosen, res;
> @@ -1238,6 +1261,23 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
>  
>      }
>  
> +    if (acpi)
> +    {
> +        int module, res;
> +
> +        module = fdt_path_offset(fdt, "/chosen/modules/module@0");
> +        assert(module > 0);
> +
> +        LOG(DEBUG, "/chosen/modules/module@0 updating acpi properties to cover "
> +            "%"PRIx64"-%"PRIx64,
> +            acpi->vstart, acpi->vend);
> +
> +        res = fdt_property_inplace_regs(fdt, module, ROOT_ADDRESS_CELLS,
> +                                        ROOT_SIZE_CELLS, 1, acpi->vstart,
> +                                        acpi->vend - acpi->vstart + 1);
> +        assert(!res);
> +    }
> +
>      for (i = 0; i < GUEST_RAM_BANKS; i++) {
>          const uint64_t size = (uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT;
>  
> -- 
> 2.0.4
> 
> 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-05-31  5:02 ` [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table Shannon Zhao
@ 2016-06-06 11:40   ` Stefano Stabellini
  2016-06-06 11:52     ` Julien Grall
  2016-06-17  3:29     ` Shannon Zhao
  2016-06-06 12:18   ` Wei Liu
  2016-06-07 11:19   ` Julien Grall
  2 siblings, 2 replies; 104+ messages in thread
From: Stefano Stabellini @ 2016-06-06 11:40 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On Tue, 31 May 2016, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> Construct GTDT table with the interrupt information of timers.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  tools/libxl/libxl_arm.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 74 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 9e99159..0fb4f69 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -3,6 +3,7 @@
>  #include "libxl_libfdt_compat.h"
>  
>  #include <xc_dom.h>
> +#include <acpi_defs.h>
>  #include <stdbool.h>
>  #include <libfdt.h>
>  #include <assert.h>
> @@ -880,13 +881,85 @@ out:
>      return rc;
>  }
>  
> +static void make_acpi_header(struct acpi_table_header *h, const char *sig,
> +                             int len, uint8_t rev)
> +{
> +    memcpy(&h->signature, sig, 4);
> +    h->length = len;
> +    h->revision = rev;
> +    memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
> +    memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
> +    memcpy(h->oem_table_id + 4, sig, 4);
> +    h->oem_revision = 1;
> +    memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
> +    h->asl_compiler_revision = 1;
> +    h->checksum = 0;
> +}
> +
> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +    struct acpi_gtdt_descriptor *gtdt;
> +
> +    gtdt = libxl__zalloc(gc, sizeof(*gtdt));
> +
> +    gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
> +    gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
> +                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
> +    gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
> +    gtdt->non_secure_el1_flags =
> +                             (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
> +                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
> +    gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
> +    gtdt->virtual_timer_flags =
> +                             (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
> +                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
> +
> +    make_acpi_header(&gtdt->header, "GTDT", sizeof(*gtdt), 2);
> +
> +    dom->acpitable_blob->gtdt.table = (void *)gtdt;
> +    /* Align to 64bit. */
> +    dom->acpitable_blob->gtdt.size = sizeof(*gtdt);
> +    dom->acpitable_size += dom->acpitable_blob->gtdt.size;
> +}
> +
> +static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
> +                        libxl__domain_build_state *state,
> +                        struct xc_dom_image *dom)
> +{
> +    const libxl_version_info *vers;
> +
> +    /* convenience aliases */
> +    xc_domain_configuration_t *xc_config = &state->config;
> +
> +    vers = libxl_get_version_info(CTX);
> +    if (vers == NULL)
> +        return ERROR_FAIL;
> +
> +    LOG(DEBUG, "constructing ACPI tables for Xen version %d.%d guest",
> +        vers->xen_version_major, vers->xen_version_minor);
> +
> +    /* Alloc memory for ACPI blob placeholders. */
> +    dom->acpitable_blob = libxl__zalloc(gc, sizeof(struct acpitable_blob));
> +    dom->acpitable_size = 0;
> +
> +    make_acpi_gtdt(gc, dom);
> +
> +    return 0;
> +}
> +
>  int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>                                             libxl_domain_build_info *info,
>                                             libxl__domain_build_state *state,
>                                             struct xc_dom_image *dom)
>  {
> +    int rc;
> +
>      assert(info->type == LIBXL_DOMAIN_TYPE_PV);
> -    return prepare_dtb(gc, info, state, dom);
> +    rc = prepare_dtb(gc, info, state, dom);
> +    if (rc)
> +        return rc;
> +
> +    return prepare_acpi(gc, info, state, dom);
>  }

ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
config file enables them, with default off.

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (15 preceding siblings ...)
  2016-06-03 19:24 ` Wei Liu
@ 2016-06-06 11:41 ` Stefano Stabellini
  2016-06-06 12:26 ` Wei Liu
  17 siblings, 0 replies; 104+ messages in thread
From: Stefano Stabellini @ 2016-06-06 11:41 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On Tue, 31 May 2016, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> The design of this feature is described as below.
> Firstly, the toolstack (libxl) generates the ACPI tables according the
> number of vcpus and gic controller.
> 
> Then, it copies these ACPI tables to DomU memory space and passes
> them to UEFI firmware through the "ARM multiboot" protocol.
> 
> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
> and installs these tables like the usual way and passes both ACPI and DT
> information to the Xen DomU.
> 
> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
> since it's enough now.
> 
> This has been tested using guest kernel with the Dom0 ACPI support
> patches which could be fetched from:
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen

Thanks for your work, Shannon. The series is pretty good.


> Shannon Zhao (14):
>   libxl/arm: Fix the function name in error log
>   libxl/arm: Factor out codes for generating DTB
>   libxc: Add placeholders for ACPI tables blob and size
>   tools: add ACPI tables relevant definitions
>   libxl/arm: Construct ACPI GTDT table
>   libxl/arm: Construct ACPI FADT table
>   libxl/arm: Construct ACPI DSDT table
>   libxl/arm: Construct ACPI MADT table
>   libxl/arm: Construct ACPI XSDT table
>   libxl/arm: Construct ACPI RSDP table
>   libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>   libxl/arm: Add ACPI module
>   libxl/arm: initialize memory information of ACPI blob
>   libxc/xc_dom_core: Copy ACPI tables to guest memory space
> 
>  tools/libxc/include/acpi_defs.h | 277 ++++++++++++++++++++++++++++++++
>  tools/libxc/include/xc_dom.h    |  17 ++
>  tools/libxc/xc_dom_arm.c        |  16 +-
>  tools/libxc/xc_dom_core.c       |  59 +++++++
>  tools/libxl/libxl_arm.c         | 345 +++++++++++++++++++++++++++++++++++++++-
>  5 files changed, 706 insertions(+), 8 deletions(-)
>  create mode 100644 tools/libxc/include/acpi_defs.h
> 
> -- 
> 2.0.4
> 
> 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-06 11:40   ` Stefano Stabellini
@ 2016-06-06 11:52     ` Julien Grall
  2016-06-06 12:04       ` Stefano Stabellini
  2016-06-17  3:29     ` Shannon Zhao
  1 sibling, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-06 11:52 UTC (permalink / raw)
  To: Stefano Stabellini, Shannon Zhao
  Cc: wei.liu2, peter.huangpeng, ian.jackson, shannon.zhao, xen-devel

Hello,

On 06/06/16 12:40, Stefano Stabellini wrote:
> On Tue, 31 May 2016, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> Construct GTDT table with the interrupt information of timers.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> ---
>>   tools/libxl/libxl_arm.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++-
>>   1 file changed, 74 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> index 9e99159..0fb4f69 100644
>> --- a/tools/libxl/libxl_arm.c
>> +++ b/tools/libxl/libxl_arm.c
>> @@ -3,6 +3,7 @@
>>   #include "libxl_libfdt_compat.h"
>>
>>   #include <xc_dom.h>
>> +#include <acpi_defs.h>
>>   #include <stdbool.h>
>>   #include <libfdt.h>
>>   #include <assert.h>
>> @@ -880,13 +881,85 @@ out:
>>       return rc;
>>   }
>>
>> +static void make_acpi_header(struct acpi_table_header *h, const char *sig,
>> +                             int len, uint8_t rev)
>> +{
>> +    memcpy(&h->signature, sig, 4);
>> +    h->length = len;
>> +    h->revision = rev;
>> +    memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
>> +    memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
>> +    memcpy(h->oem_table_id + 4, sig, 4);
>> +    h->oem_revision = 1;
>> +    memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
>> +    h->asl_compiler_revision = 1;
>> +    h->checksum = 0;
>> +}
>> +
>> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
>> +{
>> +    struct acpi_gtdt_descriptor *gtdt;
>> +
>> +    gtdt = libxl__zalloc(gc, sizeof(*gtdt));
>> +
>> +    gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
>> +    gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
>> +                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
>> +    gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
>> +    gtdt->non_secure_el1_flags =
>> +                             (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
>> +                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
>> +    gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
>> +    gtdt->virtual_timer_flags =
>> +                             (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
>> +                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
>> +
>> +    make_acpi_header(&gtdt->header, "GTDT", sizeof(*gtdt), 2);
>> +
>> +    dom->acpitable_blob->gtdt.table = (void *)gtdt;
>> +    /* Align to 64bit. */
>> +    dom->acpitable_blob->gtdt.size = sizeof(*gtdt);
>> +    dom->acpitable_size += dom->acpitable_blob->gtdt.size;
>> +}
>> +
>> +static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>> +                        libxl__domain_build_state *state,
>> +                        struct xc_dom_image *dom)
>> +{
>> +    const libxl_version_info *vers;
>> +
>> +    /* convenience aliases */
>> +    xc_domain_configuration_t *xc_config = &state->config;
>> +
>> +    vers = libxl_get_version_info(CTX);
>> +    if (vers == NULL)
>> +        return ERROR_FAIL;
>> +
>> +    LOG(DEBUG, "constructing ACPI tables for Xen version %d.%d guest",
>> +        vers->xen_version_major, vers->xen_version_minor);
>> +
>> +    /* Alloc memory for ACPI blob placeholders. */
>> +    dom->acpitable_blob = libxl__zalloc(gc, sizeof(struct acpitable_blob));
>> +    dom->acpitable_size = 0;
>> +
>> +    make_acpi_gtdt(gc, dom);
>> +
>> +    return 0;
>> +}
>> +
>>   int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>>                                              libxl_domain_build_info *info,
>>                                              libxl__domain_build_state *state,
>>                                              struct xc_dom_image *dom)
>>   {
>> +    int rc;
>> +
>>       assert(info->type == LIBXL_DOMAIN_TYPE_PV);
>> -    return prepare_dtb(gc, info, state, dom);
>> +    rc = prepare_dtb(gc, info, state, dom);
>> +    if (rc)
>> +        return rc;
>> +
>> +    return prepare_acpi(gc, info, state, dom);
>>   }
>
> ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
> config file enables them, with default off.

The VM system specification for ARM [1] mandates that both ACPI and DT 
should be provided and described the entire VM and its peripheral (see 
the section "Hardware Description").

Furthermore, the user may not know if the guest OS will use ACPI or DT 
For instance Redhat is using ACPI whilst Debian is using DT.

So we have to provide both by default. However, 32-bit domain should 
only have Device-Tree table created.

Anyway, the reason should have been described in the commit message. I 
would split this patch in two: introducing prepare ACPI and then GTDT 
table. So we can provide details in the commit message.

Regards,

[1] 
http://people.linaro.org/~christoffer.dall/VMSystemSpecificationForARM-v2.0-rc1.pdf

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-06 11:52     ` Julien Grall
@ 2016-06-06 12:04       ` Stefano Stabellini
  2016-06-06 14:31         ` Shannon Zhao
  2016-06-06 15:35         ` Julien Grall
  0 siblings, 2 replies; 104+ messages in thread
From: Stefano Stabellini @ 2016-06-06 12:04 UTC (permalink / raw)
  To: Julien Grall
  Cc: Stefano Stabellini, wei.liu2, ian.jackson, peter.huangpeng,
	xen-devel, shannon.zhao, Shannon Zhao

On Mon, 6 Jun 2016, Julien Grall wrote:
> Hello,
> 
> On 06/06/16 12:40, Stefano Stabellini wrote:
> > On Tue, 31 May 2016, Shannon Zhao wrote:
> > > From: Shannon Zhao <shannon.zhao@linaro.org>
> > > 
> > > Construct GTDT table with the interrupt information of timers.
> > > 
> > > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> > > ---
> > >   tools/libxl/libxl_arm.c | 75
> > > ++++++++++++++++++++++++++++++++++++++++++++++++-
> > >   1 file changed, 74 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> > > index 9e99159..0fb4f69 100644
> > > --- a/tools/libxl/libxl_arm.c
> > > +++ b/tools/libxl/libxl_arm.c
> > > @@ -3,6 +3,7 @@
> > >   #include "libxl_libfdt_compat.h"
> > > 
> > >   #include <xc_dom.h>
> > > +#include <acpi_defs.h>
> > >   #include <stdbool.h>
> > >   #include <libfdt.h>
> > >   #include <assert.h>
> > > @@ -880,13 +881,85 @@ out:
> > >       return rc;
> > >   }
> > > 
> > > +static void make_acpi_header(struct acpi_table_header *h, const char
> > > *sig,
> > > +                             int len, uint8_t rev)
> > > +{
> > > +    memcpy(&h->signature, sig, 4);
> > > +    h->length = len;
> > > +    h->revision = rev;
> > > +    memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
> > > +    memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
> > > +    memcpy(h->oem_table_id + 4, sig, 4);
> > > +    h->oem_revision = 1;
> > > +    memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
> > > +    h->asl_compiler_revision = 1;
> > > +    h->checksum = 0;
> > > +}
> > > +
> > > +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
> > > +{
> > > +    struct acpi_gtdt_descriptor *gtdt;
> > > +
> > > +    gtdt = libxl__zalloc(gc, sizeof(*gtdt));
> > > +
> > > +    gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
> > > +    gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE <<
> > > ACPI_GTDT_INTERRUPT_MODE)
> > > +                             |(ACPI_ACTIVE_LOW <<
> > > ACPI_GTDT_INTERRUPT_POLARITY);
> > > +    gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
> > > +    gtdt->non_secure_el1_flags =
> > > +                             (ACPI_LEVEL_SENSITIVE <<
> > > ACPI_GTDT_INTERRUPT_MODE)
> > > +                             |(ACPI_ACTIVE_LOW <<
> > > ACPI_GTDT_INTERRUPT_POLARITY);
> > > +    gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
> > > +    gtdt->virtual_timer_flags =
> > > +                             (ACPI_LEVEL_SENSITIVE <<
> > > ACPI_GTDT_INTERRUPT_MODE)
> > > +                             |(ACPI_ACTIVE_LOW <<
> > > ACPI_GTDT_INTERRUPT_POLARITY);
> > > +
> > > +    make_acpi_header(&gtdt->header, "GTDT", sizeof(*gtdt), 2);
> > > +
> > > +    dom->acpitable_blob->gtdt.table = (void *)gtdt;
> > > +    /* Align to 64bit. */
> > > +    dom->acpitable_blob->gtdt.size = sizeof(*gtdt);
> > > +    dom->acpitable_size += dom->acpitable_blob->gtdt.size;
> > > +}
> > > +
> > > +static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
> > > +                        libxl__domain_build_state *state,
> > > +                        struct xc_dom_image *dom)
> > > +{
> > > +    const libxl_version_info *vers;
> > > +
> > > +    /* convenience aliases */
> > > +    xc_domain_configuration_t *xc_config = &state->config;
> > > +
> > > +    vers = libxl_get_version_info(CTX);
> > > +    if (vers == NULL)
> > > +        return ERROR_FAIL;
> > > +
> > > +    LOG(DEBUG, "constructing ACPI tables for Xen version %d.%d guest",
> > > +        vers->xen_version_major, vers->xen_version_minor);
> > > +
> > > +    /* Alloc memory for ACPI blob placeholders. */
> > > +    dom->acpitable_blob = libxl__zalloc(gc, sizeof(struct
> > > acpitable_blob));
> > > +    dom->acpitable_size = 0;
> > > +
> > > +    make_acpi_gtdt(gc, dom);
> > > +
> > > +    return 0;
> > > +}
> > > +
> > >   int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> > >                                              libxl_domain_build_info
> > > *info,
> > >                                              libxl__domain_build_state
> > > *state,
> > >                                              struct xc_dom_image *dom)
> > >   {
> > > +    int rc;
> > > +
> > >       assert(info->type == LIBXL_DOMAIN_TYPE_PV);
> > > -    return prepare_dtb(gc, info, state, dom);
> > > +    rc = prepare_dtb(gc, info, state, dom);
> > > +    if (rc)
> > > +        return rc;
> > > +
> > > +    return prepare_acpi(gc, info, state, dom);
> > >   }
> > 
> > ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
> > config file enables them, with default off.
> 
> The VM system specification for ARM [1] mandates that both ACPI and DT should
> be provided and described the entire VM and its peripheral (see the section
> "Hardware Description").
> 
> Furthermore, the user may not know if the guest OS will use ACPI or DT For
> instance Redhat is using ACPI whilst Debian is using DT.
> 
> So we have to provide both by default. However, 32-bit domain should only have
> Device-Tree table created.
> 
> Anyway, the reason should have been described in the commit message. I would
> split this patch in two: introducing prepare ACPI and then GTDT table. So we
> can provide details in the commit message.

All right, let me rephrase then: we should have a VMSPEC=on or off to
enable or disable compliance with the VM system specification for ARM.
(The good thing about specifications is that there are so many to choose
from.) With compliance disabled, we can avoid introducing ACPI tables
for the guest.

Given that "VMSPEC" is cumbersome, I suggest to introduce a simpler and
more meaningful alias: "ACPI" :-)

I am open to discussion on what the default should be, but there needs
to be a way to disable ACPI.

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-06 10:00   ` Stefano Stabellini
@ 2016-06-06 12:16     ` Wei Liu
  2016-06-06 14:20       ` Shannon Zhao
  0 siblings, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-06-06 12:16 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: wei.liu2, ian.jackson, peter.huangpeng, xen-devel, julien.grall,
	shannon.zhao, Shannon Zhao

On Mon, Jun 06, 2016 at 11:00:37AM +0100, Stefano Stabellini wrote:
> On Tue, 31 May 2016, Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@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.zhao@linaro.org>
> 
> If we are going to make this ARM only, then maybe we should consider
> moving these structs to an ARM specific header?
> 

Agreed. Or at least have some ifdefs around the fields.

> 
> >  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;
> > +};
> > +
> >  struct xc_dom_image {
> >      /* files */
> >      void *kernel_blob;
> > @@ -64,6 +78,8 @@ struct xc_dom_image {
> >      size_t ramdisk_size;
> >      void *devicetree_blob;
> >      size_t devicetree_size;
> > +    struct acpitable_blob *acpitable_blob;
> > +    size_t acpitable_size;
> >  
> >      size_t max_kernel_size;
> >      size_t max_ramdisk_size;
> > @@ -92,6 +108,7 @@ struct xc_dom_image {
> >      struct xc_dom_seg p2m_seg;
> >      struct xc_dom_seg pgtables_seg;
> >      struct xc_dom_seg devicetree_seg;
> > +    struct xc_dom_seg acpi_seg;
> >      struct xc_dom_seg start_info_seg; /* HVMlite only */
> >      xen_pfn_t start_info_pfn;
> >      xen_pfn_t console_pfn;
> > -- 
> > 2.0.4
> > 
> > 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions
  2016-06-06 10:27       ` Shannon Zhao
@ 2016-06-06 12:16         ` Wei Liu
  2016-06-06 14:19           ` Shannon Zhao
  2016-06-22  3:24           ` Shannon Zhao
  0 siblings, 2 replies; 104+ messages in thread
From: Wei Liu @ 2016-06-06 12:16 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: Stefano Stabellini, wei.liu2, ian.jackson, peter.huangpeng,
	xen-devel, Julien Grall, shannon.zhao

On Mon, Jun 06, 2016 at 06:27:25PM +0800, Shannon Zhao wrote:
> 
> 
> On 2016/6/6 18:11, Julien Grall wrote:
> > Hi Stefano,
> > 
> > On 06/06/2016 11:04, Stefano Stabellini wrote:
> >> On Tue, 31 May 2016, Shannon Zhao wrote:
> >>> From: Shannon Zhao <shannon.zhao@linaro.org>
> >>>
> >>> Add ACPI tables relevant definitions for generating ACPI tables for ARM
> >>> guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT tables will
> >>> be used.
> >>>
> >>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> >>> ---
> >>>  tools/libxc/include/acpi_defs.h | 277
> >>> ++++++++++++++++++++++++++++++++++++++++
> >>>  1 file changed, 277 insertions(+)
> >>>  create mode 100644 tools/libxc/include/acpi_defs.h
> >>>
> >>> diff --git a/tools/libxc/include/acpi_defs.h
> >>> b/tools/libxc/include/acpi_defs.h
> >>> new file mode 100644
> >>> index 0000000..9389a96
> >>> --- /dev/null
> >>> +++ b/tools/libxc/include/acpi_defs.h
> >>> @@ -0,0 +1,277 @@
> >>> +#ifndef _ACPI_DEFS_H_
> >>> +#define _ACPI_DEFS_H_
> >>> +
> >>> +#define ACPI_BUILD_APPNAME6 "XenARM"
> >>> +#define ACPI_BUILD_APPNAME4 "Xen "
> >>
> >> This header is actually ARM specific (also see the gic stuff below). It
> >> is probably best to rename it to acpi_arm_defs.h.
> > 
> > Should not just we re-use the ACPI headers from xen/include/acpi/ ?
> So how to include those headers in tools/libxl/libxl_arm.c ?
> 

Is it public headers? If so, it might already be available in
tools/include. If not, is it feasible to be made public?

If in the end the file you need can't end up as a public header, you
need to manipulate CFLAGS. There is one example in libxc's Makefile.
Search for libelf.

But please make sure the CFLAGS doesn't get modified when it is not
necessary.  I would expect the CFLAGS is explicitly altered for a list
of files.

Wei.

> Thanks,
> -- 
> Shannon
> 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-05-31  5:02 ` [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table Shannon Zhao
  2016-06-06 11:40   ` Stefano Stabellini
@ 2016-06-06 12:18   ` Wei Liu
  2016-06-07 11:02     ` Julien Grall
  2016-06-07 11:19   ` Julien Grall
  2 siblings, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-06-06 12:18 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On Tue, May 31, 2016 at 01:02:57PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> Construct GTDT table with the interrupt information of timers.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  tools/libxl/libxl_arm.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 74 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 9e99159..0fb4f69 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -3,6 +3,7 @@
>  #include "libxl_libfdt_compat.h"
>  
>  #include <xc_dom.h>
> +#include <acpi_defs.h>
>  #include <stdbool.h>
>  #include <libfdt.h>
>  #include <assert.h>
> @@ -880,13 +881,85 @@ out:
>      return rc;
>  }
>  
> +static void make_acpi_header(struct acpi_table_header *h, const char *sig,
> +                             int len, uint8_t rev)
> +{
> +    memcpy(&h->signature, sig, 4);
> +    h->length = len;
> +    h->revision = rev;
> +    memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
> +    memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
> +    memcpy(h->oem_table_id + 4, sig, 4);
> +    h->oem_revision = 1;
> +    memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
> +    h->asl_compiler_revision = 1;
> +    h->checksum = 0;
> +}
> +
> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +    struct acpi_gtdt_descriptor *gtdt;
> +
> +    gtdt = libxl__zalloc(gc, sizeof(*gtdt));
> +
> +    gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
> +    gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
> +                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
> +    gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
> +    gtdt->non_secure_el1_flags =
> +                             (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
> +                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
> +    gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
> +    gtdt->virtual_timer_flags =
> +                             (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
> +                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
> +
> +    make_acpi_header(&gtdt->header, "GTDT", sizeof(*gtdt), 2);
> +
> +    dom->acpitable_blob->gtdt.table = (void *)gtdt;
> +    /* Align to 64bit. */
> +    dom->acpitable_blob->gtdt.size = sizeof(*gtdt);
> +    dom->acpitable_size += dom->acpitable_blob->gtdt.size;
> +}
> +
> +static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
> +                        libxl__domain_build_state *state,
> +                        struct xc_dom_image *dom)

libxl__prepare_acpi

I would also suggest moving ACPI related functions to a dedicated file
(libxl_arm_acpi.c) so that the possible future merger with x86 code can
be made easier.

Wei.

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
                   ` (16 preceding siblings ...)
  2016-06-06 11:41 ` Stefano Stabellini
@ 2016-06-06 12:26 ` Wei Liu
  2016-06-06 15:37   ` Boris Ostrovsky
  2016-06-06 15:48   ` Julien Grall
  17 siblings, 2 replies; 104+ messages in thread
From: Wei Liu @ 2016-06-06 12:26 UTC (permalink / raw)
  To: Shannon Zhao, Boris Ostrovsky
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> The design of this feature is described as below.
> Firstly, the toolstack (libxl) generates the ACPI tables according the
> number of vcpus and gic controller.
> 
> Then, it copies these ACPI tables to DomU memory space and passes
> them to UEFI firmware through the "ARM multiboot" protocol.
> 
> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
> and installs these tables like the usual way and passes both ACPI and DT
> information to the Xen DomU.
> 
> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
> since it's enough now.
> 
> This has been tested using guest kernel with the Dom0 ACPI support
> patches which could be fetched from:
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
> 
> Shannon Zhao (14):
>   libxl/arm: Fix the function name in error log
>   libxl/arm: Factor out codes for generating DTB
>   libxc: Add placeholders for ACPI tables blob and size
>   tools: add ACPI tables relevant definitions
>   libxl/arm: Construct ACPI GTDT table
>   libxl/arm: Construct ACPI FADT table
>   libxl/arm: Construct ACPI DSDT table
>   libxl/arm: Construct ACPI MADT table
>   libxl/arm: Construct ACPI XSDT table
>   libxl/arm: Construct ACPI RSDP table
>   libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>   libxl/arm: Add ACPI module
>   libxl/arm: initialize memory information of ACPI blob
>   libxc/xc_dom_core: Copy ACPI tables to guest memory space
> 

After going through this series, I think the code mostly looks good.

There is one higher level question: you seem to have put a lot of the
table construction code in libxl, while I failed to see why specific
libxl information is needed. Have you considered moving the code to
libxc?

What I don't want to see is that x86 builds its ACPI table in libxc
while ARM builds its in libxl. That would make future merger harder.

Boris?

(Please don't update your code before we come to a conclusion to avoid
wasting your effort)

Wei.

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions
  2016-06-06 12:16         ` Wei Liu
@ 2016-06-06 14:19           ` Shannon Zhao
  2016-06-22  3:24           ` Shannon Zhao
  1 sibling, 0 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-06-06 14:19 UTC (permalink / raw)
  To: Wei Liu, Shannon Zhao
  Cc: Julien Grall, Stefano Stabellini, ian.jackson, peter.huangpeng,
	xen-devel

On 2016年06月06日 20:16, Wei Liu wrote:
> On Mon, Jun 06, 2016 at 06:27:25PM +0800, Shannon Zhao wrote:
>> > 
>> > 
>> > On 2016/6/6 18:11, Julien Grall wrote:
>>> > > Hi Stefano,
>>> > > 
>>> > > On 06/06/2016 11:04, Stefano Stabellini wrote:
>>>> > >> On Tue, 31 May 2016, Shannon Zhao wrote:
>>>>> > >>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>> > >>>
>>>>> > >>> Add ACPI tables relevant definitions for generating ACPI tables for ARM
>>>>> > >>> guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT tables will
>>>>> > >>> be used.
>>>>> > >>>
>>>>> > >>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>>> > >>> ---
>>>>> > >>>  tools/libxc/include/acpi_defs.h | 277
>>>>> > >>> ++++++++++++++++++++++++++++++++++++++++
>>>>> > >>>  1 file changed, 277 insertions(+)
>>>>> > >>>  create mode 100644 tools/libxc/include/acpi_defs.h
>>>>> > >>>
>>>>> > >>> diff --git a/tools/libxc/include/acpi_defs.h
>>>>> > >>> b/tools/libxc/include/acpi_defs.h
>>>>> > >>> new file mode 100644
>>>>> > >>> index 0000000..9389a96
>>>>> > >>> --- /dev/null
>>>>> > >>> +++ b/tools/libxc/include/acpi_defs.h
>>>>> > >>> @@ -0,0 +1,277 @@
>>>>> > >>> +#ifndef _ACPI_DEFS_H_
>>>>> > >>> +#define _ACPI_DEFS_H_
>>>>> > >>> +
>>>>> > >>> +#define ACPI_BUILD_APPNAME6 "XenARM"
>>>>> > >>> +#define ACPI_BUILD_APPNAME4 "Xen "
>>>> > >>
>>>> > >> This header is actually ARM specific (also see the gic stuff below). It
>>>> > >> is probably best to rename it to acpi_arm_defs.h.
>>> > > 
>>> > > Should not just we re-use the ACPI headers from xen/include/acpi/ ?
>> > So how to include those headers in tools/libxl/libxl_arm.c ?
>> > 
> Is it public headers?
no, it's not public.

> If so, it might already be available in
> tools/include. If not, is it feasible to be made public?
> 
I'm not sure it's ok to make ACPI defs public since there are not xen
specific.

> If in the end the file you need can't end up as a public header, you
> need to manipulate CFLAGS. There is one example in libxc's Makefile.
> Search for libelf.
> 
> But please make sure the CFLAGS doesn't get modified when it is not
> necessary.  I would expect the CFLAGS is explicitly altered for a list
> of files.
Thanks, I'll have a look.

-- 
Shannon

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-06 12:16     ` Wei Liu
@ 2016-06-06 14:20       ` Shannon Zhao
  0 siblings, 0 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-06-06 14:20 UTC (permalink / raw)
  To: Wei Liu, Stefano Stabellini
  Cc: julien.grall, xen-devel, ian.jackson, peter.huangpeng, Shannon Zhao

On 2016年06月06日 20:16, Wei Liu wrote:
> On Mon, Jun 06, 2016 at 11:00:37AM +0100, Stefano Stabellini wrote:
>> > On Tue, 31 May 2016, Shannon Zhao wrote:
>>> > > From: Shannon Zhao <shannon.zhao@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.zhao@linaro.org>
>> > 
>> > If we are going to make this ARM only, then maybe we should consider
>> > moving these structs to an ARM specific header?
>> > 
> Agreed. Or at least have some ifdefs around the fields.
> 
Ok, will change. Thanks.

-- 
Shannon

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-06 12:04       ` Stefano Stabellini
@ 2016-06-06 14:31         ` Shannon Zhao
  2016-06-06 14:50           ` Stefano Stabellini
  2016-06-06 15:35         ` Julien Grall
  1 sibling, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-06 14:31 UTC (permalink / raw)
  To: Stefano Stabellini, Julien Grall
  Cc: wei.liu2, xen-devel, ian.jackson, peter.huangpeng, Shannon Zhao

On 2016年06月06日 20:04, Stefano Stabellini wrote:
> On Mon, 6 Jun 2016, Julien Grall wrote:
>> > Hello,
>> > 
>> > On 06/06/16 12:40, Stefano Stabellini wrote:
>>> > > On Tue, 31 May 2016, Shannon Zhao wrote:
>>>> > > > From: Shannon Zhao <shannon.zhao@linaro.org>
>>>> > > > 
>>>> > > > Construct GTDT table with the interrupt information of timers.
>>>> > > > 
>>>> > > > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>> > > > ---
>>>> > > >   tools/libxl/libxl_arm.c | 75
>>>> > > > ++++++++++++++++++++++++++++++++++++++++++++++++-
>>>> > > >   1 file changed, 74 insertions(+), 1 deletion(-)
>>>> > > > 
>>>> > > > diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>>>> > > > index 9e99159..0fb4f69 100644
>>>> > > > --- a/tools/libxl/libxl_arm.c
>>>> > > > +++ b/tools/libxl/libxl_arm.c
>>>> > > > @@ -3,6 +3,7 @@
>>>> > > >   #include "libxl_libfdt_compat.h"
>>>> > > > 
>>>> > > >   #include <xc_dom.h>
>>>> > > > +#include <acpi_defs.h>
>>>> > > >   #include <stdbool.h>
>>>> > > >   #include <libfdt.h>
>>>> > > >   #include <assert.h>
>>>> > > > @@ -880,13 +881,85 @@ out:
>>>> > > >       return rc;
>>>> > > >   }
>>>> > > > 
>>>> > > > +static void make_acpi_header(struct acpi_table_header *h, const char
>>>> > > > *sig,
>>>> > > > +                             int len, uint8_t rev)
>>>> > > > +{
>>>> > > > +    memcpy(&h->signature, sig, 4);
>>>> > > > +    h->length = len;
>>>> > > > +    h->revision = rev;
>>>> > > > +    memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
>>>> > > > +    memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
>>>> > > > +    memcpy(h->oem_table_id + 4, sig, 4);
>>>> > > > +    h->oem_revision = 1;
>>>> > > > +    memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
>>>> > > > +    h->asl_compiler_revision = 1;
>>>> > > > +    h->checksum = 0;
>>>> > > > +}
>>>> > > > +
>>>> > > > +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
>>>> > > > +{
>>>> > > > +    struct acpi_gtdt_descriptor *gtdt;
>>>> > > > +
>>>> > > > +    gtdt = libxl__zalloc(gc, sizeof(*gtdt));
>>>> > > > +
>>>> > > > +    gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
>>>> > > > +    gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE <<
>>>> > > > ACPI_GTDT_INTERRUPT_MODE)
>>>> > > > +                             |(ACPI_ACTIVE_LOW <<
>>>> > > > ACPI_GTDT_INTERRUPT_POLARITY);
>>>> > > > +    gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
>>>> > > > +    gtdt->non_secure_el1_flags =
>>>> > > > +                             (ACPI_LEVEL_SENSITIVE <<
>>>> > > > ACPI_GTDT_INTERRUPT_MODE)
>>>> > > > +                             |(ACPI_ACTIVE_LOW <<
>>>> > > > ACPI_GTDT_INTERRUPT_POLARITY);
>>>> > > > +    gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
>>>> > > > +    gtdt->virtual_timer_flags =
>>>> > > > +                             (ACPI_LEVEL_SENSITIVE <<
>>>> > > > ACPI_GTDT_INTERRUPT_MODE)
>>>> > > > +                             |(ACPI_ACTIVE_LOW <<
>>>> > > > ACPI_GTDT_INTERRUPT_POLARITY);
>>>> > > > +
>>>> > > > +    make_acpi_header(&gtdt->header, "GTDT", sizeof(*gtdt), 2);
>>>> > > > +
>>>> > > > +    dom->acpitable_blob->gtdt.table = (void *)gtdt;
>>>> > > > +    /* Align to 64bit. */
>>>> > > > +    dom->acpitable_blob->gtdt.size = sizeof(*gtdt);
>>>> > > > +    dom->acpitable_size += dom->acpitable_blob->gtdt.size;
>>>> > > > +}
>>>> > > > +
>>>> > > > +static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>>>> > > > +                        libxl__domain_build_state *state,
>>>> > > > +                        struct xc_dom_image *dom)
>>>> > > > +{
>>>> > > > +    const libxl_version_info *vers;
>>>> > > > +
>>>> > > > +    /* convenience aliases */
>>>> > > > +    xc_domain_configuration_t *xc_config = &state->config;
>>>> > > > +
>>>> > > > +    vers = libxl_get_version_info(CTX);
>>>> > > > +    if (vers == NULL)
>>>> > > > +        return ERROR_FAIL;
>>>> > > > +
>>>> > > > +    LOG(DEBUG, "constructing ACPI tables for Xen version %d.%d guest",
>>>> > > > +        vers->xen_version_major, vers->xen_version_minor);
>>>> > > > +
>>>> > > > +    /* Alloc memory for ACPI blob placeholders. */
>>>> > > > +    dom->acpitable_blob = libxl__zalloc(gc, sizeof(struct
>>>> > > > acpitable_blob));
>>>> > > > +    dom->acpitable_size = 0;
>>>> > > > +
>>>> > > > +    make_acpi_gtdt(gc, dom);
>>>> > > > +
>>>> > > > +    return 0;
>>>> > > > +}
>>>> > > > +
>>>> > > >   int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>>>> > > >                                              libxl_domain_build_info
>>>> > > > *info,
>>>> > > >                                              libxl__domain_build_state
>>>> > > > *state,
>>>> > > >                                              struct xc_dom_image *dom)
>>>> > > >   {
>>>> > > > +    int rc;
>>>> > > > +
>>>> > > >       assert(info->type == LIBXL_DOMAIN_TYPE_PV);
>>>> > > > -    return prepare_dtb(gc, info, state, dom);
>>>> > > > +    rc = prepare_dtb(gc, info, state, dom);
>>>> > > > +    if (rc)
>>>> > > > +        return rc;
>>>> > > > +
>>>> > > > +    return prepare_acpi(gc, info, state, dom);
>>>> > > >   }
>>> > > 
>>> > > ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
>>> > > config file enables them, with default off.
>> > 
>> > The VM system specification for ARM [1] mandates that both ACPI and DT should
>> > be provided and described the entire VM and its peripheral (see the section
>> > "Hardware Description").
>> > 
>> > Furthermore, the user may not know if the guest OS will use ACPI or DT For
>> > instance Redhat is using ACPI whilst Debian is using DT.
>> > 
>> > So we have to provide both by default. However, 32-bit domain should only have
>> > Device-Tree table created.
>> > 
>> > Anyway, the reason should have been described in the commit message. I would
>> > split this patch in two: introducing prepare ACPI and then GTDT table. So we
>> > can provide details in the commit message.
> All right, let me rephrase then: we should have a VMSPEC=on or off to
> enable or disable compliance with the VM system specification for ARM.
> (The good thing about specifications is that there are so many to choose
> from.) With compliance disabled, we can avoid introducing ACPI tables
> for the guest.
> 
> Given that "VMSPEC" is cumbersome, I suggest to introduce a simpler and
> more meaningful alias: "ACPI" :-)
> 
> I am open to discussion on what the default should be, but there needs
> to be a way to disable ACPI.
I don't know why we need to disable ACPI because we can provide ACPI
tables but guest could choose to not use it. And for ARM32 domain, since
the linux guest kernel doesn't support ACPI, even we provide ACPI
tables, it can't use it, anyway.

Thanks,
-- 
Shannon

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 13/14] libxl/arm: initialize memory information of ACPI blob
  2016-06-06 11:40   ` Stefano Stabellini
@ 2016-06-06 14:35     ` Shannon Zhao
  0 siblings, 0 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-06-06 14:35 UTC (permalink / raw)
  To: Stefano Stabellini, Shannon Zhao
  Cc: wei.liu2, julien.grall, ian.jackson, peter.huangpeng, xen-devel

On 2016年06月06日 19:40, Stefano Stabellini wrote:
> On Tue, 31 May 2016, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> Assign the guest memory space for ACPI tables and replace the reg in DT
>> with real values.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> ---
>>  tools/libxc/xc_dom_arm.c | 16 +++++++++++++++-
>>  tools/libxl/libxl_arm.c  | 40 ++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 55 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
>> index 64a8b67..e21e3e9 100644
>> --- a/tools/libxc/xc_dom_arm.c
>> +++ b/tools/libxc/xc_dom_arm.c
>> @@ -383,9 +383,11 @@ static int meminit(struct xc_dom_image *dom)
>>      const uint64_t kernsize = kernend - kernbase;
>>      const uint64_t dtb_size = dom->devicetree_blob ?
>>          ROUNDUP(dom->devicetree_size, XC_PAGE_SHIFT) : 0;
>> +    const uint64_t acpi_size = dom->acpitable_blob ?
>> +        ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) : 0;
>>      const uint64_t ramdisk_size = dom->ramdisk_blob ?
>>          ROUNDUP(dom->ramdisk_size, XC_PAGE_SHIFT) : 0;
>> -    const uint64_t modsize = dtb_size + ramdisk_size;
>> +    const uint64_t modsize = dtb_size + acpi_size + ramdisk_size;
>>      const uint64_t ram128mb = bankbase[0] + (128<<20);
>>  
>>      xen_pfn_t p2m_size;
>> @@ -500,6 +502,18 @@ static int meminit(struct xc_dom_image *dom)
>>          modbase += dtb_size;
>>      }
>>  
>> +    if ( acpi_size )
>> +    {
>> +        dom->acpi_seg.vstart = modbase;
>> +        dom->acpi_seg.vend = modbase + acpi_size;
>> +
>> +        DOMPRINTF("%s: acpi: 0x%" PRIx64 " -> 0x%" PRIx64 "",
>> +                  __FUNCTION__,
>> +                  dom->acpi_seg.vstart, dom->acpi_seg.vend);
>> +
>> +        modbase += dtb_size;
> 
> shouldn't this be 
> 
> modbase += acpi_size
> 
> ?
> 
right, will fix.

> 
>> +    }
>> +
>>      return 0;
>>  }
>>  
>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> index e7cb578..bf1eeea 100644
>> --- a/tools/libxl/libxl_arm.c
>> +++ b/tools/libxl/libxl_arm.c
>> @@ -230,6 +230,27 @@ static int fdt_property_regs(libxl__gc *gc, void *fdt,
>>      return fdt_property(fdt, "reg", regs, sizeof(regs));
>>  }
>>  
>> +static int fdt_property_inplace_regs(void *fdt, int nodeoffset,
>> +                                     unsigned addr_cells, unsigned size_cells,
>> +                                     unsigned num_regs, ...)
>> +{
>> +    uint32_t regs[num_regs*(addr_cells+size_cells)];
>> +    be32 *cells = &regs[0];
>> +    int i;
>> +    va_list ap;
>> +    uint64_t base, size;
>> +
>> +    va_start(ap, num_regs);
>> +    for (i = 0 ; i < num_regs; i++) {
>> +        base = addr_cells ? va_arg(ap, uint64_t) : 0;
>> +        size = size_cells ? va_arg(ap, uint64_t) : 0;
>> +        set_range(&cells, addr_cells, size_cells, base, size);
>> +    }
>> +    va_end(ap);
>> +
>> +    return fdt_setprop_inplace(fdt, nodeoffset, "reg", regs, sizeof(regs));
>> +}
> 
> The va_arg stuff is a bit overkill. Also, can't you call
> finalise_one_memory_node instead?
> 
OK, thank you.

-- 
Shannon

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-06 14:31         ` Shannon Zhao
@ 2016-06-06 14:50           ` Stefano Stabellini
  2016-06-06 15:42             ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Stefano Stabellini @ 2016-06-06 14:50 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: Stefano Stabellini, wei.liu2, ian.jackson, peter.huangpeng,
	xen-devel, Julien Grall, Shannon Zhao

[-- Attachment #1: Type: TEXT/PLAIN, Size: 7747 bytes --]

On Mon, 6 Jun 2016, Shannon Zhao wrote:
> On 2016年06月06日 20:04, Stefano Stabellini wrote:
> > On Mon, 6 Jun 2016, Julien Grall wrote:
> >> > Hello,
> >> > 
> >> > On 06/06/16 12:40, Stefano Stabellini wrote:
> >>> > > On Tue, 31 May 2016, Shannon Zhao wrote:
> >>>> > > > From: Shannon Zhao <shannon.zhao@linaro.org>
> >>>> > > > 
> >>>> > > > Construct GTDT table with the interrupt information of timers.
> >>>> > > > 
> >>>> > > > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> >>>> > > > ---
> >>>> > > >   tools/libxl/libxl_arm.c | 75
> >>>> > > > ++++++++++++++++++++++++++++++++++++++++++++++++-
> >>>> > > >   1 file changed, 74 insertions(+), 1 deletion(-)
> >>>> > > > 
> >>>> > > > diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> >>>> > > > index 9e99159..0fb4f69 100644
> >>>> > > > --- a/tools/libxl/libxl_arm.c
> >>>> > > > +++ b/tools/libxl/libxl_arm.c
> >>>> > > > @@ -3,6 +3,7 @@
> >>>> > > >   #include "libxl_libfdt_compat.h"
> >>>> > > > 
> >>>> > > >   #include <xc_dom.h>
> >>>> > > > +#include <acpi_defs.h>
> >>>> > > >   #include <stdbool.h>
> >>>> > > >   #include <libfdt.h>
> >>>> > > >   #include <assert.h>
> >>>> > > > @@ -880,13 +881,85 @@ out:
> >>>> > > >       return rc;
> >>>> > > >   }
> >>>> > > > 
> >>>> > > > +static void make_acpi_header(struct acpi_table_header *h, const char
> >>>> > > > *sig,
> >>>> > > > +                             int len, uint8_t rev)
> >>>> > > > +{
> >>>> > > > +    memcpy(&h->signature, sig, 4);
> >>>> > > > +    h->length = len;
> >>>> > > > +    h->revision = rev;
> >>>> > > > +    memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
> >>>> > > > +    memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
> >>>> > > > +    memcpy(h->oem_table_id + 4, sig, 4);
> >>>> > > > +    h->oem_revision = 1;
> >>>> > > > +    memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
> >>>> > > > +    h->asl_compiler_revision = 1;
> >>>> > > > +    h->checksum = 0;
> >>>> > > > +}
> >>>> > > > +
> >>>> > > > +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
> >>>> > > > +{
> >>>> > > > +    struct acpi_gtdt_descriptor *gtdt;
> >>>> > > > +
> >>>> > > > +    gtdt = libxl__zalloc(gc, sizeof(*gtdt));
> >>>> > > > +
> >>>> > > > +    gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
> >>>> > > > +    gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE <<
> >>>> > > > ACPI_GTDT_INTERRUPT_MODE)
> >>>> > > > +                             |(ACPI_ACTIVE_LOW <<
> >>>> > > > ACPI_GTDT_INTERRUPT_POLARITY);
> >>>> > > > +    gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
> >>>> > > > +    gtdt->non_secure_el1_flags =
> >>>> > > > +                             (ACPI_LEVEL_SENSITIVE <<
> >>>> > > > ACPI_GTDT_INTERRUPT_MODE)
> >>>> > > > +                             |(ACPI_ACTIVE_LOW <<
> >>>> > > > ACPI_GTDT_INTERRUPT_POLARITY);
> >>>> > > > +    gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
> >>>> > > > +    gtdt->virtual_timer_flags =
> >>>> > > > +                             (ACPI_LEVEL_SENSITIVE <<
> >>>> > > > ACPI_GTDT_INTERRUPT_MODE)
> >>>> > > > +                             |(ACPI_ACTIVE_LOW <<
> >>>> > > > ACPI_GTDT_INTERRUPT_POLARITY);
> >>>> > > > +
> >>>> > > > +    make_acpi_header(&gtdt->header, "GTDT", sizeof(*gtdt), 2);
> >>>> > > > +
> >>>> > > > +    dom->acpitable_blob->gtdt.table = (void *)gtdt;
> >>>> > > > +    /* Align to 64bit. */
> >>>> > > > +    dom->acpitable_blob->gtdt.size = sizeof(*gtdt);
> >>>> > > > +    dom->acpitable_size += dom->acpitable_blob->gtdt.size;
> >>>> > > > +}
> >>>> > > > +
> >>>> > > > +static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
> >>>> > > > +                        libxl__domain_build_state *state,
> >>>> > > > +                        struct xc_dom_image *dom)
> >>>> > > > +{
> >>>> > > > +    const libxl_version_info *vers;
> >>>> > > > +
> >>>> > > > +    /* convenience aliases */
> >>>> > > > +    xc_domain_configuration_t *xc_config = &state->config;
> >>>> > > > +
> >>>> > > > +    vers = libxl_get_version_info(CTX);
> >>>> > > > +    if (vers == NULL)
> >>>> > > > +        return ERROR_FAIL;
> >>>> > > > +
> >>>> > > > +    LOG(DEBUG, "constructing ACPI tables for Xen version %d.%d guest",
> >>>> > > > +        vers->xen_version_major, vers->xen_version_minor);
> >>>> > > > +
> >>>> > > > +    /* Alloc memory for ACPI blob placeholders. */
> >>>> > > > +    dom->acpitable_blob = libxl__zalloc(gc, sizeof(struct
> >>>> > > > acpitable_blob));
> >>>> > > > +    dom->acpitable_size = 0;
> >>>> > > > +
> >>>> > > > +    make_acpi_gtdt(gc, dom);
> >>>> > > > +
> >>>> > > > +    return 0;
> >>>> > > > +}
> >>>> > > > +
> >>>> > > >   int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> >>>> > > >                                              libxl_domain_build_info
> >>>> > > > *info,
> >>>> > > >                                              libxl__domain_build_state
> >>>> > > > *state,
> >>>> > > >                                              struct xc_dom_image *dom)
> >>>> > > >   {
> >>>> > > > +    int rc;
> >>>> > > > +
> >>>> > > >       assert(info->type == LIBXL_DOMAIN_TYPE_PV);
> >>>> > > > -    return prepare_dtb(gc, info, state, dom);
> >>>> > > > +    rc = prepare_dtb(gc, info, state, dom);
> >>>> > > > +    if (rc)
> >>>> > > > +        return rc;
> >>>> > > > +
> >>>> > > > +    return prepare_acpi(gc, info, state, dom);
> >>>> > > >   }
> >>> > > 
> >>> > > ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
> >>> > > config file enables them, with default off.
> >> > 
> >> > The VM system specification for ARM [1] mandates that both ACPI and DT should
> >> > be provided and described the entire VM and its peripheral (see the section
> >> > "Hardware Description").
> >> > 
> >> > Furthermore, the user may not know if the guest OS will use ACPI or DT For
> >> > instance Redhat is using ACPI whilst Debian is using DT.
> >> > 
> >> > So we have to provide both by default. However, 32-bit domain should only have
> >> > Device-Tree table created.
> >> > 
> >> > Anyway, the reason should have been described in the commit message. I would
> >> > split this patch in two: introducing prepare ACPI and then GTDT table. So we
> >> > can provide details in the commit message.
> > All right, let me rephrase then: we should have a VMSPEC=on or off to
> > enable or disable compliance with the VM system specification for ARM.
> > (The good thing about specifications is that there are so many to choose
> > from.) With compliance disabled, we can avoid introducing ACPI tables
> > for the guest.
> > 
> > Given that "VMSPEC" is cumbersome, I suggest to introduce a simpler and
> > more meaningful alias: "ACPI" :-)
> > 
> > I am open to discussion on what the default should be, but there needs
> > to be a way to disable ACPI.
> I don't know why we need to disable ACPI because we can provide ACPI
> tables but guest could choose to not use it. And for ARM32 domain, since
> the linux guest kernel doesn't support ACPI, even we provide ACPI
> tables, it can't use it, anyway.

Memory usage. Simplicity: if you know you are not going to use ACPI, you
might as well disable it to have one less moving piece (every line of
code is potential for a bug). Guest configuration: if your guest
operating system supports both ACPI and Device Tree and you want to be
sure that Device Tree is the one that gets used, then you can do it by
disabling ACPI at the VM level. Linux offers a command line option to do
that, but other OSes might not and could choose ACPI by default.
Debugging: it might be helpful to be able to enable/disable ACPI at the
VM level just to test different code paths in the guest. These are just
the first few reasons that come to mind.

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-06 12:04       ` Stefano Stabellini
  2016-06-06 14:31         ` Shannon Zhao
@ 2016-06-06 15:35         ` Julien Grall
  2016-06-07  9:48           ` Stefano Stabellini
  1 sibling, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-06 15:35 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: wei.liu2, ian.jackson, peter.huangpeng, xen-devel, shannon.zhao,
	Shannon Zhao

Hello,

On 06/06/16 13:04, Stefano Stabellini wrote:
> On Mon, 6 Jun 2016, Julien Grall wrote:
>> On 06/06/16 12:40, Stefano Stabellini wrote:
>>> On Tue, 31 May 2016, Shannon Zhao wrote:
>>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
>>> config file enables them, with default off.
>>
>> The VM system specification for ARM [1] mandates that both ACPI and DT should
>> be provided and described the entire VM and its peripheral (see the section
>> "Hardware Description").
>>
>> Furthermore, the user may not know if the guest OS will use ACPI or DT For
>> instance Redhat is using ACPI whilst Debian is using DT.
>>
>> So we have to provide both by default. However, 32-bit domain should only have
>> Device-Tree table created.
>>
>> Anyway, the reason should have been described in the commit message. I would
>> split this patch in two: introducing prepare ACPI and then GTDT table. So we
>> can provide details in the commit message.
>
> All right, let me rephrase then: we should have a VMSPEC=on or off to
> enable or disable compliance with the VM system specification for ARM.
> (The good thing about specifications is that there are so many to choose
> from.) With compliance disabled, we can avoid introducing ACPI tables
> for the guest.
>
> Given that "VMSPEC" is cumbersome, I suggest to introduce a simpler and
> more meaningful alias: "ACPI" :-)

The VM specification introduces other components such as a SBSA UART 
emulation (which is not yet implemented by Xen).

Do we want an option for each components?

>
> I am open to discussion on what the default should be, but there needs
> to be a way to disable ACPI.

Agree with that.

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-06 12:26 ` Wei Liu
@ 2016-06-06 15:37   ` Boris Ostrovsky
  2016-06-06 16:50     ` Boris Ostrovsky
  2016-06-06 15:48   ` Julien Grall
  1 sibling, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-06-06 15:37 UTC (permalink / raw)
  To: Wei Liu, Shannon Zhao
  Cc: sstabellini, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On 06/06/2016 08:26 AM, Wei Liu wrote:
> On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> The design of this feature is described as below.
>> Firstly, the toolstack (libxl) generates the ACPI tables according the
>> number of vcpus and gic controller.
>>
>> Then, it copies these ACPI tables to DomU memory space and passes
>> them to UEFI firmware through the "ARM multiboot" protocol.
>>
>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>> and installs these tables like the usual way and passes both ACPI and DT
>> information to the Xen DomU.
>>
>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
>> since it's enough now.
>>
>> This has been tested using guest kernel with the Dom0 ACPI support
>> patches which could be fetched from:
>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>
>> Shannon Zhao (14):
>>   libxl/arm: Fix the function name in error log
>>   libxl/arm: Factor out codes for generating DTB
>>   libxc: Add placeholders for ACPI tables blob and size
>>   tools: add ACPI tables relevant definitions
>>   libxl/arm: Construct ACPI GTDT table
>>   libxl/arm: Construct ACPI FADT table
>>   libxl/arm: Construct ACPI DSDT table
>>   libxl/arm: Construct ACPI MADT table
>>   libxl/arm: Construct ACPI XSDT table
>>   libxl/arm: Construct ACPI RSDP table
>>   libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>>   libxl/arm: Add ACPI module
>>   libxl/arm: initialize memory information of ACPI blob
>>   libxc/xc_dom_core: Copy ACPI tables to guest memory space
>>
> After going through this series, I think the code mostly looks good.
>
> There is one higher level question: you seem to have put a lot of the
> table construction code in libxl, while I failed to see why specific
> libxl information is needed. Have you considered moving the code to
> libxc?
>
> What I don't want to see is that x86 builds its ACPI table in libxc
> while ARM builds its in libxl. That would make future merger harder.
>
> Boris?

TBH, I am not sure which library this should really belong to. I felt
libxc would be more appropriate.

-boris


>
> (Please don't update your code before we come to a conclusion to avoid
> wasting your effort)
>
> Wei.



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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-06 14:50           ` Stefano Stabellini
@ 2016-06-06 15:42             ` Julien Grall
  2016-06-07  9:41               ` Stefano Stabellini
  0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-06 15:42 UTC (permalink / raw)
  To: Stefano Stabellini, Shannon Zhao
  Cc: wei.liu2, xen-devel, ian.jackson, peter.huangpeng, Shannon Zhao

Hi Stefano,

On 06/06/16 15:50, Stefano Stabellini wrote:
> On Mon, 6 Jun 2016, Shannon Zhao wrote:
>> I don't know why we need to disable ACPI because we can provide ACPI
>> tables but guest could choose to not use it. And for ARM32 domain, since
>> the linux guest kernel doesn't support ACPI, even we provide ACPI
>> tables, it can't use it, anyway.
>
> Memory usage. Simplicity: if you know you are not going to use ACPI, you
> might as well disable it to have one less moving piece (every line of
> code is potential for a bug). Guest configuration: if your guest
> operating system supports both ACPI and Device Tree and you want to be
> sure that Device Tree is the one that gets used, then you can do it by
> disabling ACPI at the VM level. Linux offers a command line option to do
> that, but other OSes might not and could choose ACPI by default.

Other OSes would have the same problem on baremetal. A VM should 
reproduce the baremetal behavior. If you have enabled both ACPI and DT 
in your kernel, then you greed to let the kernel choose for you.

However, I agree that an having option to enable/disable ACPI is useful. 
The main use case would be embedded environment where ACPI will less used.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-06 12:26 ` Wei Liu
  2016-06-06 15:37   ` Boris Ostrovsky
@ 2016-06-06 15:48   ` Julien Grall
  2016-06-07  1:07     ` Shannon Zhao
  1 sibling, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-06 15:48 UTC (permalink / raw)
  To: Wei Liu, Shannon Zhao, Boris Ostrovsky
  Cc: peter.huangpeng, sstabellini, ian.jackson, shannon.zhao, xen-devel

Hi Wei,

On 06/06/16 13:26, Wei Liu wrote:
> On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> The design of this feature is described as below.
>> Firstly, the toolstack (libxl) generates the ACPI tables according the
>> number of vcpus and gic controller.
>>
>> Then, it copies these ACPI tables to DomU memory space and passes
>> them to UEFI firmware through the "ARM multiboot" protocol.
>>
>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>> and installs these tables like the usual way and passes both ACPI and DT
>> information to the Xen DomU.
>>
>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
>> since it's enough now.
>>
>> This has been tested using guest kernel with the Dom0 ACPI support
>> patches which could be fetched from:
>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>
>> Shannon Zhao (14):
>>    libxl/arm: Fix the function name in error log
>>    libxl/arm: Factor out codes for generating DTB
>>    libxc: Add placeholders for ACPI tables blob and size
>>    tools: add ACPI tables relevant definitions
>>    libxl/arm: Construct ACPI GTDT table
>>    libxl/arm: Construct ACPI FADT table
>>    libxl/arm: Construct ACPI DSDT table
>>    libxl/arm: Construct ACPI MADT table
>>    libxl/arm: Construct ACPI XSDT table
>>    libxl/arm: Construct ACPI RSDP table
>>    libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>>    libxl/arm: Add ACPI module
>>    libxl/arm: initialize memory information of ACPI blob
>>    libxc/xc_dom_core: Copy ACPI tables to guest memory space
>>
>
> After going through this series, I think the code mostly looks good.
>
> There is one higher level question: you seem to have put a lot of the
> table construction code in libxl, while I failed to see why specific
> libxl information is needed. Have you considered moving the code to
> libxc?

I would rather avoid to have the device tree built by libxl and ACPI 
tables built by libxc.

I don't remember why we have decided to implement DT building in libxl, 
I guess it is because we need to know which GIC version is used (GICv2 
vs GICv3).

In the long run, we might also need to have more part of the firmware 
configurable (performance monitor support, memory layout, UART...).

Most of those information are available easily in libxl, we would to 
export them of libxc.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-06 15:37   ` Boris Ostrovsky
@ 2016-06-06 16:50     ` Boris Ostrovsky
  2016-06-07 10:54       ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-06-06 16:50 UTC (permalink / raw)
  To: Wei Liu, Shannon Zhao
  Cc: sstabellini, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On 06/06/2016 11:37 AM, Boris Ostrovsky wrote:
> On 06/06/2016 08:26 AM, Wei Liu wrote:
>> On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote:
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> The design of this feature is described as below.
>>> Firstly, the toolstack (libxl) generates the ACPI tables according the
>>> number of vcpus and gic controller.
>>>
>>> Then, it copies these ACPI tables to DomU memory space and passes
>>> them to UEFI firmware through the "ARM multiboot" protocol.
>>>
>>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>>> and installs these tables like the usual way and passes both ACPI and DT
>>> information to the Xen DomU.
>>>
>>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
>>> since it's enough now.
>>>
>>> This has been tested using guest kernel with the Dom0 ACPI support
>>> patches which could be fetched from:
>>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>>
>>> Shannon Zhao (14):
>>>   libxl/arm: Fix the function name in error log
>>>   libxl/arm: Factor out codes for generating DTB
>>>   libxc: Add placeholders for ACPI tables blob and size
>>>   tools: add ACPI tables relevant definitions
>>>   libxl/arm: Construct ACPI GTDT table
>>>   libxl/arm: Construct ACPI FADT table
>>>   libxl/arm: Construct ACPI DSDT table
>>>   libxl/arm: Construct ACPI MADT table
>>>   libxl/arm: Construct ACPI XSDT table
>>>   libxl/arm: Construct ACPI RSDP table
>>>   libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>>>   libxl/arm: Add ACPI module
>>>   libxl/arm: initialize memory information of ACPI blob
>>>   libxc/xc_dom_core: Copy ACPI tables to guest memory space
>>>
>> After going through this series, I think the code mostly looks good.
>>
>> There is one higher level question: you seem to have put a lot of the
>> table construction code in libxl, while I failed to see why specific
>> libxl information is needed. Have you considered moving the code to
>> libxc?
>>
>> What I don't want to see is that x86 builds its ACPI table in libxc
>> while ARM builds its in libxl. That would make future merger harder.
>>
>> Boris?
> TBH, I am not sure which library this should really belong to. I felt
> libxc would be more appropriate.

Actually, I now remember why I picked libxc: because I wanted ACPI pages
to be loaded as part of xc_dom_build_image().

-boris



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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-06 15:48   ` Julien Grall
@ 2016-06-07  1:07     ` Shannon Zhao
  2016-06-07 11:00       ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-07  1:07 UTC (permalink / raw)
  To: Julien Grall, Wei Liu, Boris Ostrovsky
  Cc: peter.huangpeng, sstabellini, ian.jackson, shannon.zhao, xen-devel



On 2016/6/6 23:48, Julien Grall wrote:
> Hi Wei,
> 
> On 06/06/16 13:26, Wei Liu wrote:
>> On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote:
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> The design of this feature is described as below.
>>> Firstly, the toolstack (libxl) generates the ACPI tables according the
>>> number of vcpus and gic controller.
>>>
>>> Then, it copies these ACPI tables to DomU memory space and passes
>>> them to UEFI firmware through the "ARM multiboot" protocol.
>>>
>>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>>> and installs these tables like the usual way and passes both ACPI and DT
>>> information to the Xen DomU.
>>>
>>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
>>> since it's enough now.
>>>
>>> This has been tested using guest kernel with the Dom0 ACPI support
>>> patches which could be fetched from:
>>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>>
>>>
>>> Shannon Zhao (14):
>>>    libxl/arm: Fix the function name in error log
>>>    libxl/arm: Factor out codes for generating DTB
>>>    libxc: Add placeholders for ACPI tables blob and size
>>>    tools: add ACPI tables relevant definitions
>>>    libxl/arm: Construct ACPI GTDT table
>>>    libxl/arm: Construct ACPI FADT table
>>>    libxl/arm: Construct ACPI DSDT table
>>>    libxl/arm: Construct ACPI MADT table
>>>    libxl/arm: Construct ACPI XSDT table
>>>    libxl/arm: Construct ACPI RSDP table
>>>    libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>>>    libxl/arm: Add ACPI module
>>>    libxl/arm: initialize memory information of ACPI blob
>>>    libxc/xc_dom_core: Copy ACPI tables to guest memory space
>>>
>>
>> After going through this series, I think the code mostly looks good.
>>
>> There is one higher level question: you seem to have put a lot of the
>> table construction code in libxl, while I failed to see why specific
>> libxl information is needed. Have you considered moving the code to
>> libxc?
> 
> I would rather avoid to have the device tree built by libxl and ACPI
> tables built by libxc.
> 
> I don't remember why we have decided to implement DT building in libxl,
> I guess it is because we need to know which GIC version is used (GICv2
> vs GICv3).
> 
> In the long run, we might also need to have more part of the firmware
> configurable (performance monitor support, memory layout, UART...).
> 
> Most of those information are available easily in libxl, we would to
> export them of libxc.
Yes, and one more reason is that to support ACPI, it also needs to add
the ACPI multiboot module in DT.

Thanks,
-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-06 15:42             ` Julien Grall
@ 2016-06-07  9:41               ` Stefano Stabellini
  0 siblings, 0 replies; 104+ messages in thread
From: Stefano Stabellini @ 2016-06-07  9:41 UTC (permalink / raw)
  To: Julien Grall
  Cc: Stefano Stabellini, wei.liu2, ian.jackson, peter.huangpeng,
	xen-devel, Shannon Zhao, Shannon Zhao

On Mon, 6 Jun 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 06/06/16 15:50, Stefano Stabellini wrote:
> > On Mon, 6 Jun 2016, Shannon Zhao wrote:
> > > I don't know why we need to disable ACPI because we can provide ACPI
> > > tables but guest could choose to not use it. And for ARM32 domain, since
> > > the linux guest kernel doesn't support ACPI, even we provide ACPI
> > > tables, it can't use it, anyway.
> > 
> > Memory usage. Simplicity: if you know you are not going to use ACPI, you
> > might as well disable it to have one less moving piece (every line of
> > code is potential for a bug). Guest configuration: if your guest
> > operating system supports both ACPI and Device Tree and you want to be
> > sure that Device Tree is the one that gets used, then you can do it by
> > disabling ACPI at the VM level. Linux offers a command line option to do
> > that, but other OSes might not and could choose ACPI by default.
> 
> Other OSes would have the same problem on baremetal. A VM should reproduce the
> baremetal behavior. If you have enabled both ACPI and DT in your kernel, then
> you greed to let the kernel choose for you.
> 
> However, I agree that an having option to enable/disable ACPI is useful. The
> main use case would be embedded environment where ACPI will less used.

That's right.

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-06 15:35         ` Julien Grall
@ 2016-06-07  9:48           ` Stefano Stabellini
  2016-06-07 11:55             ` Wei Liu
  0 siblings, 1 reply; 104+ messages in thread
From: Stefano Stabellini @ 2016-06-07  9:48 UTC (permalink / raw)
  To: Julien Grall
  Cc: Stefano Stabellini, wei.liu2, ian.jackson, peter.huangpeng,
	xen-devel, shannon.zhao, Shannon Zhao

On Mon, 6 Jun 2016, Julien Grall wrote:
> Hello,
> 
> On 06/06/16 13:04, Stefano Stabellini wrote:
> > On Mon, 6 Jun 2016, Julien Grall wrote:
> > > On 06/06/16 12:40, Stefano Stabellini wrote:
> > > > On Tue, 31 May 2016, Shannon Zhao wrote:
> > > > > From: Shannon Zhao <shannon.zhao@linaro.org>
> > > > 
> > > > ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
> > > > config file enables them, with default off.
> > > 
> > > The VM system specification for ARM [1] mandates that both ACPI and DT
> > > should
> > > be provided and described the entire VM and its peripheral (see the
> > > section
> > > "Hardware Description").
> > > 
> > > Furthermore, the user may not know if the guest OS will use ACPI or DT For
> > > instance Redhat is using ACPI whilst Debian is using DT.
> > > 
> > > So we have to provide both by default. However, 32-bit domain should only
> > > have
> > > Device-Tree table created.
> > > 
> > > Anyway, the reason should have been described in the commit message. I
> > > would
> > > split this patch in two: introducing prepare ACPI and then GTDT table. So
> > > we
> > > can provide details in the commit message.
> > 
> > All right, let me rephrase then: we should have a VMSPEC=on or off to
> > enable or disable compliance with the VM system specification for ARM.
> > (The good thing about specifications is that there are so many to choose
> > from.) With compliance disabled, we can avoid introducing ACPI tables
> > for the guest.
> > 
> > Given that "VMSPEC" is cumbersome, I suggest to introduce a simpler and
> > more meaningful alias: "ACPI" :-)
> 
> The VM specification introduces other components such as a SBSA UART emulation
> (which is not yet implemented by Xen).
> 
> Do we want an option for each components?

This is a good point. If one wants to avoid ACPI then she probably would
want to avoid SBSA UART emulation too. So maybe after all it might be
better to have a single

vm_system_spec=1/0

option? I am OK with both having multiple options or just one.

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-06 16:50     ` Boris Ostrovsky
@ 2016-06-07 10:54       ` Julien Grall
  2016-06-07 14:24         ` Boris Ostrovsky
  0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-07 10:54 UTC (permalink / raw)
  To: Boris Ostrovsky, Wei Liu, Shannon Zhao
  Cc: peter.huangpeng, sstabellini, ian.jackson, shannon.zhao, xen-devel

Hello Boris,

On 06/06/16 17:50, Boris Ostrovsky wrote:
> On 06/06/2016 11:37 AM, Boris Ostrovsky wrote:
>>> What I don't want to see is that x86 builds its ACPI table in libxc
>>> while ARM builds its in libxl. That would make future merger harder.
>>>
>>> Boris?
>> TBH, I am not sure which library this should really belong to. I felt
>> libxc would be more appropriate.
>
> Actually, I now remember why I picked libxc: because I wanted ACPI pages
> to be loaded as part of xc_dom_build_image().

What about adding a new field in xc_dom_image? For the device tree, 
libxl is provide a buffer which will be loaded as part of 
xc_dom_build_image (see devicetree_blob).

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-07  1:07     ` Shannon Zhao
@ 2016-06-07 11:00       ` Julien Grall
  2016-06-16 11:20         ` Wei Liu
  0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-07 11:00 UTC (permalink / raw)
  To: Shannon Zhao, Wei Liu, Boris Ostrovsky
  Cc: peter.huangpeng, sstabellini, ian.jackson, shannon.zhao, xen-devel

Hello Shannon,

On 07/06/16 02:07, Shannon Zhao wrote:
> On 2016/6/6 23:48, Julien Grall wrote:
>> On 06/06/16 13:26, Wei Liu wrote:
>>> On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote:
>>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>
>>>> The design of this feature is described as below.
>>>> Firstly, the toolstack (libxl) generates the ACPI tables according the
>>>> number of vcpus and gic controller.
>>>>
>>>> Then, it copies these ACPI tables to DomU memory space and passes
>>>> them to UEFI firmware through the "ARM multiboot" protocol.
>>>>
>>>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>>>> and installs these tables like the usual way and passes both ACPI and DT
>>>> information to the Xen DomU.
>>>>
>>>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
>>>> since it's enough now.
>>>>
>>>> This has been tested using guest kernel with the Dom0 ACPI support
>>>> patches which could be fetched from:
>>>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>>>
>>>>
>>>> Shannon Zhao (14):
>>>>     libxl/arm: Fix the function name in error log
>>>>     libxl/arm: Factor out codes for generating DTB
>>>>     libxc: Add placeholders for ACPI tables blob and size
>>>>     tools: add ACPI tables relevant definitions
>>>>     libxl/arm: Construct ACPI GTDT table
>>>>     libxl/arm: Construct ACPI FADT table
>>>>     libxl/arm: Construct ACPI DSDT table
>>>>     libxl/arm: Construct ACPI MADT table
>>>>     libxl/arm: Construct ACPI XSDT table
>>>>     libxl/arm: Construct ACPI RSDP table
>>>>     libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>>>>     libxl/arm: Add ACPI module
>>>>     libxl/arm: initialize memory information of ACPI blob
>>>>     libxc/xc_dom_core: Copy ACPI tables to guest memory space
>>>>
>>>
>>> After going through this series, I think the code mostly looks good.
>>>
>>> There is one higher level question: you seem to have put a lot of the
>>> table construction code in libxl, while I failed to see why specific
>>> libxl information is needed. Have you considered moving the code to
>>> libxc?
>>
>> I would rather avoid to have the device tree built by libxl and ACPI
>> tables built by libxc.
>>
>> I don't remember why we have decided to implement DT building in libxl,
>> I guess it is because we need to know which GIC version is used (GICv2
>> vs GICv3).
>>
>> In the long run, we might also need to have more part of the firmware
>> configurable (performance monitor support, memory layout, UART...).
>>
>> Most of those information are available easily in libxl, we would to
>> export them of libxc.
> Yes, and one more reason is that to support ACPI, it also needs to add
> the ACPI multiboot module in DT.

I don't consider this as a reason for building the ACPI tables in libxl. 
I am more concerned about building the firmwares in different place.

If we decide to build the ACPI tables in libxc, then the code to build 
the device tree should move in libxc too.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-06 12:18   ` Wei Liu
@ 2016-06-07 11:02     ` Julien Grall
  0 siblings, 0 replies; 104+ messages in thread
From: Julien Grall @ 2016-06-07 11:02 UTC (permalink / raw)
  To: Wei Liu, Shannon Zhao
  Cc: peter.huangpeng, sstabellini, ian.jackson, shannon.zhao, xen-devel

Hello,

On 06/06/16 13:18, Wei Liu wrote:
> On Tue, May 31, 2016 at 01:02:57PM +0800, Shannon Zhao wrote:
>> +static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>> +                        libxl__domain_build_state *state,
>> +                        struct xc_dom_image *dom)
>
> libxl__prepare_acpi
>
> I would also suggest moving ACPI related functions to a dedicated file
> (libxl_arm_acpi.c) so that the possible future merger with x86 code can
> be made easier.

+1 and it makes sense to have the code to build the Device Tree and the 
ACPI tables in a separate files.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-05-31  5:02 ` [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size Shannon Zhao
  2016-06-06 10:00   ` Stefano Stabellini
@ 2016-06-07 11:05   ` Julien Grall
  2016-06-07 11:13     ` Shannon Zhao
  1 sibling, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-07 11:05 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng

Hello Shannon,

On 31/05/16 06:02, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@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.zhao@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.

> +
>   struct xc_dom_image {
>       /* files */
>       void *kernel_blob;
> @@ -64,6 +78,8 @@ struct xc_dom_image {
>       size_t ramdisk_size;
>       void *devicetree_blob;
>       size_t devicetree_size;
> +    struct acpitable_blob *acpitable_blob;
> +    size_t acpitable_size;
>
>       size_t max_kernel_size;
>       size_t max_ramdisk_size;
> @@ -92,6 +108,7 @@ struct xc_dom_image {
>       struct xc_dom_seg p2m_seg;
>       struct xc_dom_seg pgtables_seg;
>       struct xc_dom_seg devicetree_seg;
> +    struct xc_dom_seg acpi_seg;
>       struct xc_dom_seg start_info_seg; /* HVMlite only */
>       xen_pfn_t start_info_pfn;
>       xen_pfn_t console_pfn;
>

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-07 11:05   ` Julien Grall
@ 2016-06-07 11:13     ` Shannon Zhao
  2016-06-07 11:27       ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-07 11:13 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng



On 2016/6/7 19:05, Julien Grall wrote:
> Hello Shannon,
> 
> On 31/05/16 06:02, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@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.zhao@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.

So it needs to know the length of each table and copy them separately.

Please see patch 14.

Thanks,
-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-05-31  5:02 ` [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table Shannon Zhao
  2016-06-06 11:40   ` Stefano Stabellini
  2016-06-06 12:18   ` Wei Liu
@ 2016-06-07 11:19   ` Julien Grall
  2016-06-07 11:30     ` Shannon Zhao
  2 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-07 11:19 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng

Hello Shannon,

On 31/05/16 06:02, Shannon Zhao wrote:
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 9e99159..0fb4f69 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -3,6 +3,7 @@
>   #include "libxl_libfdt_compat.h"
>
>   #include <xc_dom.h>
> +#include <acpi_defs.h>
>   #include <stdbool.h>
>   #include <libfdt.h>
>   #include <assert.h>
> @@ -880,13 +881,85 @@ out:
>       return rc;
>   }
>
> +static void make_acpi_header(struct acpi_table_header *h, const char *sig,
> +                             int len, uint8_t rev)
> +{
> +    memcpy(&h->signature, sig, 4);
> +    h->length = len;
> +    h->revision = rev;
> +    memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
> +    memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
> +    memcpy(h->oem_table_id + 4, sig, 4);
> +    h->oem_revision = 1;
> +    memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
> +    h->asl_compiler_revision = 1;
> +    h->checksum = 0;

Should not we compute the checksum here?

> +}
> +
> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +    struct acpi_gtdt_descriptor *gtdt;
> +
> +    gtdt = libxl__zalloc(gc, sizeof(*gtdt));
> +
> +    gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
> +    gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
> +                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);

There is no secure EL1 for guest, so this should be 0.

> +    gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
> +    gtdt->non_secure_el1_flags =
> +                             (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
> +                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
> +    gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
> +    gtdt->virtual_timer_flags =
> +                             (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
> +                             |(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
> +
> +    make_acpi_header(&gtdt->header, "GTDT", sizeof(*gtdt), 2);
> +
> +    dom->acpitable_blob->gtdt.table = (void *)gtdt;
> +    /* Align to 64bit. */

I am not sure what the comment is for.

> +    dom->acpitable_blob->gtdt.size = sizeof(*gtdt);
> +    dom->acpitable_size += dom->acpitable_blob->gtdt.size;
> +}

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-07 11:13     ` Shannon Zhao
@ 2016-06-07 11:27       ` Julien Grall
  2016-06-07 11:35         ` Shannon Zhao
  0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-07 11:27 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng



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.zhao@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.zhao@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)?

This would make the code a lot simpler and would avoid a duplication of 
the same 5 lines for each tables in patch 14:

+        xsdt = (struct acpi_xsdt_descriptor *)acpitablemap;
+        memcpy(acpitablemap, dom->acpitable_blob->xsdt.table,
+               dom->acpitable_blob->xsdt.size);

[...]

+        start += dom->acpitable_blob->xsdt.size;
+        acpitablemap += dom->acpitable_blob->xsdt.size;

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-07 11:19   ` Julien Grall
@ 2016-06-07 11:30     ` Shannon Zhao
  2016-06-07 11:36       ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-07 11:30 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng



On 2016/6/7 19:19, Julien Grall wrote:
> Hello Shannon,
> 
> On 31/05/16 06:02, Shannon Zhao wrote:
>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> index 9e99159..0fb4f69 100644
>> --- a/tools/libxl/libxl_arm.c
>> +++ b/tools/libxl/libxl_arm.c
>> @@ -3,6 +3,7 @@
>>   #include "libxl_libfdt_compat.h"
>>
>>   #include <xc_dom.h>
>> +#include <acpi_defs.h>
>>   #include <stdbool.h>
>>   #include <libfdt.h>
>>   #include <assert.h>
>> @@ -880,13 +881,85 @@ out:
>>       return rc;
>>   }
>>
>> +static void make_acpi_header(struct acpi_table_header *h, const char
>> *sig,
>> +                             int len, uint8_t rev)
>> +{
>> +    memcpy(&h->signature, sig, 4);
>> +    h->length = len;
>> +    h->revision = rev;
>> +    memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
>> +    memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
>> +    memcpy(h->oem_table_id + 4, sig, 4);
>> +    h->oem_revision = 1;
>> +    memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
>> +    h->asl_compiler_revision = 1;
>> +    h->checksum = 0;
> 
> Should not we compute the checksum here?
> 
Sure.
>> +}
>> +
>> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
>> +{
>> +    struct acpi_gtdt_descriptor *gtdt;
>> +
>> +    gtdt = libxl__zalloc(gc, sizeof(*gtdt));
>> +
>> +    gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
>> +    gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE <<
>> ACPI_GTDT_INTERRUPT_MODE)
>> +                             |(ACPI_ACTIVE_LOW <<
>> ACPI_GTDT_INTERRUPT_POLARITY);
> 
> There is no secure EL1 for guest, so this should be 0.
> 
So why does DT add secure EL1 timer in make_timer_node()?

>> +    gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
>> +    gtdt->non_secure_el1_flags =
>> +                             (ACPI_LEVEL_SENSITIVE <<
>> ACPI_GTDT_INTERRUPT_MODE)
>> +                             |(ACPI_ACTIVE_LOW <<
>> ACPI_GTDT_INTERRUPT_POLARITY);
>> +    gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
>> +    gtdt->virtual_timer_flags =
>> +                             (ACPI_LEVEL_SENSITIVE <<
>> ACPI_GTDT_INTERRUPT_MODE)
>> +                             |(ACPI_ACTIVE_LOW <<
>> ACPI_GTDT_INTERRUPT_POLARITY);
>> +
>> +    make_acpi_header(&gtdt->header, "GTDT", sizeof(*gtdt), 2);
>> +
>> +    dom->acpitable_blob->gtdt.table = (void *)gtdt;
>> +    /* Align to 64bit. */
> 
> I am not sure what the comment is for.
> 
Oops, I planed to make the length of these tables aligned to 64bit, but
it turns out it's unnecessary. And I forgot to delete this.

>> +    dom->acpitable_blob->gtdt.size = sizeof(*gtdt);
>> +    dom->acpitable_size += dom->acpitable_blob->gtdt.size;
>> +}
> 
> Regards,
> 

-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-07 11:27       ` Julien Grall
@ 2016-06-07 11:35         ` Shannon Zhao
  2016-06-07 11:42           ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-07 11:35 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng



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.zhao@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.zhao@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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-07 11:30     ` Shannon Zhao
@ 2016-06-07 11:36       ` Julien Grall
  2016-06-07 11:39         ` Shannon Zhao
  0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-07 11:36 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng



On 07/06/16 12:30, Shannon Zhao wrote:
> On 2016/6/7 19:19, Julien Grall wrote:
>> On 31/05/16 06:02, Shannon Zhao wrote:
>>> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
>>> +{
>>> +    struct acpi_gtdt_descriptor *gtdt;
>>> +
>>> +    gtdt = libxl__zalloc(gc, sizeof(*gtdt));
>>> +
>>> +    gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
>>> +    gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE <<
>>> ACPI_GTDT_INTERRUPT_MODE)
>>> +                             |(ACPI_ACTIVE_LOW <<
>>> ACPI_GTDT_INTERRUPT_POLARITY);
>>
>> There is no secure EL1 for guest, so this should be 0.
>>
> So why does DT add secure EL1 timer in make_timer_node()?

Because the DT binding mandates the secure EL1 IRQ. However this 
interrupt will never be asserted by the virtual timer.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-07 11:36       ` Julien Grall
@ 2016-06-07 11:39         ` Shannon Zhao
  2016-06-07 11:43           ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-07 11:39 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng



On 2016/6/7 19:36, Julien Grall wrote:
> 
> 
> On 07/06/16 12:30, Shannon Zhao wrote:
>> On 2016/6/7 19:19, Julien Grall wrote:
>>> On 31/05/16 06:02, Shannon Zhao wrote:
>>>> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
>>>> +{
>>>> +    struct acpi_gtdt_descriptor *gtdt;
>>>> +
>>>> +    gtdt = libxl__zalloc(gc, sizeof(*gtdt));
>>>> +
>>>> +    gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
>>>> +    gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE <<
>>>> ACPI_GTDT_INTERRUPT_MODE)
>>>> +                             |(ACPI_ACTIVE_LOW <<
>>>> ACPI_GTDT_INTERRUPT_POLARITY);
>>>
>>> There is no secure EL1 for guest, so this should be 0.
>>>
>> So why does DT add secure EL1 timer in make_timer_node()?
> 
> Because the DT binding mandates the secure EL1 IRQ. However this
> interrupt will never be asserted by the virtual timer.
Oh, right. But it's harmless. Anyway, I'll remove this.

-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-07 11:35         ` Shannon Zhao
@ 2016-06-07 11:42           ` Julien Grall
  2016-06-07 11:59             ` Shannon Zhao
  2016-06-07 12:02             ` Julien Grall
  0 siblings, 2 replies; 104+ messages in thread
From: Julien Grall @ 2016-06-07 11:42 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng



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.zhao@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.zhao@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.

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.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-07 11:39         ` Shannon Zhao
@ 2016-06-07 11:43           ` Julien Grall
  0 siblings, 0 replies; 104+ messages in thread
From: Julien Grall @ 2016-06-07 11:43 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng



On 07/06/16 12:39, Shannon Zhao wrote:
>
>
> On 2016/6/7 19:36, Julien Grall wrote:
>>
>>
>> On 07/06/16 12:30, Shannon Zhao wrote:
>>> On 2016/6/7 19:19, Julien Grall wrote:
>>>> On 31/05/16 06:02, Shannon Zhao wrote:
>>>>> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
>>>>> +{
>>>>> +    struct acpi_gtdt_descriptor *gtdt;
>>>>> +
>>>>> +    gtdt = libxl__zalloc(gc, sizeof(*gtdt));
>>>>> +
>>>>> +    gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
>>>>> +    gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE <<
>>>>> ACPI_GTDT_INTERRUPT_MODE)
>>>>> +                             |(ACPI_ACTIVE_LOW <<
>>>>> ACPI_GTDT_INTERRUPT_POLARITY);
>>>>
>>>> There is no secure EL1 for guest, so this should be 0.
>>>>
>>> So why does DT add secure EL1 timer in make_timer_node()?
>>
>> Because the DT binding mandates the secure EL1 IRQ. However this
>> interrupt will never be asserted by the virtual timer.
> Oh, right. But it's harmless. Anyway, I'll remove this.

Correct, but let's not expose things a guest could not use :).

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-07  9:48           ` Stefano Stabellini
@ 2016-06-07 11:55             ` Wei Liu
  0 siblings, 0 replies; 104+ messages in thread
From: Wei Liu @ 2016-06-07 11:55 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: wei.liu2, ian.jackson, peter.huangpeng, xen-devel, Julien Grall,
	shannon.zhao, Shannon Zhao

On Tue, Jun 07, 2016 at 10:48:36AM +0100, Stefano Stabellini wrote:
> On Mon, 6 Jun 2016, Julien Grall wrote:
> > Hello,
> > 
> > On 06/06/16 13:04, Stefano Stabellini wrote:
> > > On Mon, 6 Jun 2016, Julien Grall wrote:
> > > > On 06/06/16 12:40, Stefano Stabellini wrote:
> > > > > On Tue, 31 May 2016, Shannon Zhao wrote:
> > > > > > From: Shannon Zhao <shannon.zhao@linaro.org>
> > > > > 
> > > > > ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
> > > > > config file enables them, with default off.
> > > > 
> > > > The VM system specification for ARM [1] mandates that both ACPI and DT
> > > > should
> > > > be provided and described the entire VM and its peripheral (see the
> > > > section
> > > > "Hardware Description").
> > > > 
> > > > Furthermore, the user may not know if the guest OS will use ACPI or DT For
> > > > instance Redhat is using ACPI whilst Debian is using DT.
> > > > 
> > > > So we have to provide both by default. However, 32-bit domain should only
> > > > have
> > > > Device-Tree table created.
> > > > 
> > > > Anyway, the reason should have been described in the commit message. I
> > > > would
> > > > split this patch in two: introducing prepare ACPI and then GTDT table. So
> > > > we
> > > > can provide details in the commit message.
> > > 
> > > All right, let me rephrase then: we should have a VMSPEC=on or off to
> > > enable or disable compliance with the VM system specification for ARM.
> > > (The good thing about specifications is that there are so many to choose
> > > from.) With compliance disabled, we can avoid introducing ACPI tables
> > > for the guest.
> > > 
> > > Given that "VMSPEC" is cumbersome, I suggest to introduce a simpler and
> > > more meaningful alias: "ACPI" :-)
> > 
> > The VM specification introduces other components such as a SBSA UART emulation
> > (which is not yet implemented by Xen).
> > 
> > Do we want an option for each components?
> 
> This is a good point. If one wants to avoid ACPI then she probably would
> want to avoid SBSA UART emulation too. So maybe after all it might be
> better to have a single
> 
> vm_system_spec=1/0
> 
> option? I am OK with both having multiple options or just one.

If the user is not supposed to pick and choose then using one is fine.
We probably don't want to expose such capability anyway.

Is the spec going to be updated at some point? Maybe make it some sort
of version number?

Wei.

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-07 11:42           ` Julien Grall
@ 2016-06-07 11:59             ` Shannon Zhao
  2016-06-07 12:06               ` Julien Grall
  2016-06-07 12:02             ` Julien Grall
  1 sibling, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-07 11:59 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng



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.zhao@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.zhao@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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-07 11:42           ` Julien Grall
  2016-06-07 11:59             ` Shannon Zhao
@ 2016-06-07 12:02             ` Julien Grall
  2016-06-07 12:27               ` Shannon Zhao
  1 sibling, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-07 12:02 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: sstabellini, wei.liu2, Steve Capper, ian.jackson,
	peter.huangpeng, shannon.zhao

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-07 11:59             ` Shannon Zhao
@ 2016-06-07 12:06               ` Julien Grall
  2016-06-07 12:32                 ` Shannon Zhao
  0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-07 12:06 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng



On 07/06/16 12:59, Shannon Zhao wrote:
>
>
> 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.zhao@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.zhao@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.

Why does UEFI need to relocate the ACPI tables?

Anyway, you rely on the UEFI firmware to always relocating the tables. 
What would happen if they decide to remove this behavior?

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-07 12:02             ` Julien Grall
@ 2016-06-07 12:27               ` Shannon Zhao
  0 siblings, 0 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-06-07 12:27 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: sstabellini, wei.liu2, Steve Capper, ian.jackson,
	peter.huangpeng, shannon.zhao



On 2016/6/7 20:02, Julien Grall wrote:
> 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?
No, this will not work. UEFI will control the memory map by itself.

-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-07 12:06               ` Julien Grall
@ 2016-06-07 12:32                 ` Shannon Zhao
  2016-06-07 13:06                   ` Julien Grall
  2016-06-16 10:49                   ` Wei Liu
  0 siblings, 2 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-06-07 12:32 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng



On 2016/6/7 20:06, Julien Grall wrote:
> 
> 
> On 07/06/16 12:59, Shannon Zhao wrote:
>>
>>
>> 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.zhao@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.zhao@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.
> 
> Why does UEFI need to relocate the ACPI tables?
> 
That's its own mechanism I think and UEFI wants all the memory maps
under its control. And it's same for QEMU(x86 and ARM) and also for Xen
on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
is used for x86 Xen DomU.

> Anyway, you rely on the UEFI firmware to always relocating the tables.
> What would happen if they decide to remove this behavior?
Eh, I don't believe this would happen.

-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-07 12:32                 ` Shannon Zhao
@ 2016-06-07 13:06                   ` Julien Grall
  2016-06-16  6:53                     ` Shannon Zhao
  2016-06-16 10:49                   ` Wei Liu
  1 sibling, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-07 13:06 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: sstabellini, wei.liu2, Steve Capper, ian.jackson,
	peter.huangpeng, shannon.zhao



On 07/06/16 13:32, Shannon Zhao wrote:
>
>
> On 2016/6/7 20:06, Julien Grall wrote:
>>
>>
>> On 07/06/16 12:59, Shannon Zhao wrote:
>>>
>>>
>>> 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.zhao@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.zhao@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.
>>
>> Why does UEFI need to relocate the ACPI tables?
>>
> That's its own mechanism I think and UEFI wants all the memory maps
> under its control. And it's same for QEMU(x86 and ARM) and also for Xen
> on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
> is used for x86 Xen DomU.

UEFI cannot control the memory map because it is not capable to know 
what a region is used for (such as magic pages, grant table...).

In the case of domU for x86, the ACPI table are located in predefine 
physical address by hvmloader. I really don't see any reason that would 
prevent us to do the same on ARM.

If the UEFI firmware wants to relocate the tables, then fine. But we 
should also think about any firmware which may not relocate the tables.

>
>> Anyway, you rely on the UEFI firmware to always relocating the tables.
>> What would happen if they decide to remove this behavior?
> Eh, I don't believe this would happen.

You seem very optimistic. Xen does not rely on a specific UEFI 
implementation nor how a guest will behave. We have to predict what 
could happen and find the best way to do it.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 06/14] libxl/arm: Construct ACPI FADT table
  2016-05-31  5:02 ` [PATCH RESEND 06/14] libxl/arm: Construct ACPI FADT table Shannon Zhao
@ 2016-06-07 13:17   ` Julien Grall
  2016-06-07 14:13     ` Shannon Zhao
  0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-07 13:17 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng

Hello Shannon,

It just occurred to me that the way to build the ACPI tables, I am not 
speaking about the value, is very similar to what QEMU does.

Perhaps, we should copy the copyright from QEMU in libxl_arm.c. In this 
case, moving the ACPI code in a separate file would be the best.

On 31/05/16 06:02, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>   tools/libxl/libxl_arm.c | 23 +++++++++++++++++++++++
>   1 file changed, 23 insertions(+)
>
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 0fb4f69..c3b8fb4 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -922,6 +922,28 @@ static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
>       dom->acpitable_size += dom->acpitable_blob->gtdt.size;
>   }
>
> +static void make_acpi_fadt(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +    struct acpi_fadt_descriptor *fadt;
> +
> +    fadt = libxl__zalloc(gc, sizeof(*fadt));
> +
> +    /* Hardware Reduced = 1 and use PSCI 0.2+ and with HVC */
> +    fadt->flags = 1 << ACPI_FADT_F_HW_REDUCED_ACPI;
> +    fadt->arm_boot_flags = (1 << ACPI_FADT_ARM_USE_PSCI_G_0_2) |
> +                           (1 << ACPI_FADT_ARM_PSCI_USE_HVC);
> +
> +    /* ACPI v5.1 (fadt->revision.fadt->minor_revision) */
> +    fadt->minor_revision = 0x1;
> +
> +    make_acpi_header(&fadt->header, "FACP", sizeof(*fadt), 5);
> +
> +    dom->acpitable_blob->fadt.table = (void *)fadt;

pointless cast.

> +    /* Align to 64bit. */

I am not sure what the comment is for.

> +    dom->acpitable_blob->fadt.size = sizeof(*fadt);
> +    dom->acpitable_size += dom->acpitable_blob->fadt.size;
> +}
> +
>   static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>                           libxl__domain_build_state *state,
>                           struct xc_dom_image *dom)
> @@ -943,6 +965,7 @@ static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>       dom->acpitable_size = 0;
>
>       make_acpi_gtdt(gc, dom);
> +    make_acpi_fadt(gc, dom);
>
>       return 0;
>   }
>

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 08/14] libxl/arm: Construct ACPI MADT table
  2016-05-31  5:03 ` [PATCH RESEND 08/14] libxl/arm: Construct ACPI MADT table Shannon Zhao
@ 2016-06-07 13:40   ` Julien Grall
  0 siblings, 0 replies; 104+ messages in thread
From: Julien Grall @ 2016-06-07 13:40 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng

Hello Shannon,

On 31/05/16 06:03, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> According to the gic version, construct the MADT table.

NIT: s/gic/GIC/

>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>   tools/libxl/libxl_arm.c | 107 ++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 107 insertions(+)
>
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 7949635..f72f692 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -958,11 +958,115 @@ static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
>       dom->acpitable_size += ROUNDUP(dom->acpitable_blob->dsdt.size, 3);
>   }
>
> +static void make_acpi_madt_gicc(void *table, int nr_cpus, uint64_t gicc_base)
> +{
> +    uint32_t i;
> +    uint64_t mpidr_aff;
> +    struct acpi_madt_generic_interrupt *gicc = table;
> +
> +    for (i = 0; i < nr_cpus; i++) {
> +        gicc->type = ACPI_APIC_GENERIC_INTERRUPT;
> +        gicc->length = sizeof(*gicc);
> +        gicc->base_address = gicc_base;
> +        gicc->cpu_interface_number = i;
> +
> +        /*
> +         * We will use AFF0 and AFF1 when constructing the MPIDR value of the
> +         * guest at the moment, for it is enough for the current max vcpu
> +         * number.
> +         */
> +        mpidr_aff = (i & 0x0f) | (((i >> 4) & 0xff) << 8);

I would prefer if you introduce an helper to compute the MPIDR to avoid 
open coding in 2 places (DT and ACPI).

> +        gicc->arm_mpidr = mpidr_aff;
> +        gicc->uid = i;

I don't see any code to create the associated processor device object in 
the DSDT.

> +        gicc->flags = 1;

Please use a define here.

> +
> +        gicc += 1;
> +    }
> +}
> +
> +static void make_acpi_madt_gicd(void *table, uint64_t gicd_base,
> +                                uint8_t gic_version)
> +{
> +    struct acpi_madt_generic_distributor *gicd = table;
> +
> +    gicd->type = ACPI_APIC_GENERIC_DISTRIBUTOR;
> +    gicd->length = sizeof(*gicd);
> +    gicd->base_address = gicd_base;
> +    gicd->version = gic_version;

This field is has been added with ACPI 5.1 errata, which technically is 
not ACPI 5.1.

I don't mind if you use it, however it would need a comment to explain 
that this field had no other meaning before...

> +}
> +
> +static void make_acpi_madt_gicr(void *table, uint64_t gicr_base,
> +                                uint64_t gicr_size)
> +{
> +    struct acpi_madt_generic_redistributor *gicr = table;
> +
> +    gicr->type = ACPI_APIC_GENERIC_REDISTRIBUTOR;
> +    gicr->length = sizeof(*gicr);
> +    gicr->base_address = gicr_base;
> +    gicr->range_length = gicr_size;
> +}
> +
> +static int make_acpi_madt(libxl__gc *gc, struct xc_dom_image *dom, int nr_cpus,
> +                          xc_domain_configuration_t *xc_config)
> +{
> +    uint32_t size;
> +    void *table;
> +    struct acpi_madt_descriptor *madt;
> +
> +    switch (xc_config->gic_version) {
> +    case XEN_DOMCTL_CONFIG_GIC_V2:
> +        size = sizeof(struct acpi_madt_descriptor) +
> +               sizeof(struct acpi_madt_generic_interrupt) * nr_cpus +
> +               sizeof(struct acpi_madt_generic_distributor);
> +        table = libxl__zalloc(gc, size);
> +        madt = (struct acpi_madt_descriptor *)table;
> +
> +        table += sizeof(struct acpi_madt_descriptor);
> +        make_acpi_madt_gicc(table, nr_cpus, GUEST_GICC_BASE);
> +
> +        table += sizeof(struct acpi_madt_generic_interrupt) * nr_cpus;
> +        make_acpi_madt_gicd(table, GUEST_GICD_BASE, 2);
> +        break;
> +    case XEN_DOMCTL_CONFIG_GIC_V3:
> +        size = sizeof(struct acpi_madt_descriptor) +
> +               sizeof(struct acpi_madt_generic_interrupt) * nr_cpus +
> +               sizeof(struct acpi_madt_generic_distributor) +
> +               sizeof(struct acpi_madt_generic_redistributor);
> +        table = libxl__zalloc(gc, size);
> +        madt = (struct acpi_madt_descriptor *)table;
> +
> +        table += sizeof(struct acpi_madt_descriptor);
> +        make_acpi_madt_gicc(table, nr_cpus, 0);
> +
> +        table += sizeof(struct acpi_madt_generic_interrupt) * nr_cpus;
> +        make_acpi_madt_gicd(table, GUEST_GICV3_GICD_BASE, 3);
> +
> +        table += sizeof(struct acpi_madt_generic_distributor);
> +        make_acpi_madt_gicr(table, GUEST_GICV3_GICR0_BASE,
> +                            GUEST_GICV3_GICR0_SIZE);
> +        break;
> +    default:
> +        LOG(ERROR, "Unknown GIC version %s",
> +            gicv_to_string(xc_config->gic_version));
> +        return ERROR_FAIL;
> +    }
> +
> +    make_acpi_header(&madt->header, "APIC", size, 3);
> +
> +    dom->acpitable_blob->madt.table = (void *)madt;

Pointless cast.

> +    /* Align to 64bit. */

Pointless comment.

> +    dom->acpitable_blob->madt.size = size;
> +    dom->acpitable_size += dom->acpitable_blob->madt.size;
> +
> +    return 0;
> +}
> +

Regards,


-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 07/14] libxl/arm: Construct ACPI DSDT table
  2016-05-31  5:02 ` [PATCH RESEND 07/14] libxl/arm: Construct ACPI DSDT table Shannon Zhao
@ 2016-06-07 13:42   ` Julien Grall
  2016-06-16  6:25     ` Shannon Zhao
  0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-07 13:42 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng

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?

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 12/14] libxl/arm: Add ACPI module
  2016-05-31  5:03 ` [PATCH RESEND 12/14] libxl/arm: Add ACPI module Shannon Zhao
@ 2016-06-07 13:47   ` Julien Grall
  0 siblings, 0 replies; 104+ messages in thread
From: Julien Grall @ 2016-06-07 13:47 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng

Hello Shannon,

On 31/05/16 06:03, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add the ARM Multiboot module for ACPI, so UEFI can get the base address
> of ACPI tables from it.

This new binding/compatible needs to be formalized in 
docs/misc/arm/device-tree.

>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>   tools/libxl/libxl_arm.c | 20 ++++++++++++++++++++
>   1 file changed, 20 insertions(+)
>
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 13259f8..e7cb578 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -285,6 +285,26 @@ static int make_chosen_node(libxl__gc *gc, void *fdt, bool ramdisk,
>           if (res) return res;
>       }
>
> +    res = fdt_begin_node(fdt, "modules");
> +    if (res) return res;
> +
> +    res = fdt_begin_node(fdt, "module@0");
> +    if (res) return res;
> +
> +    res = fdt_property_compat(gc, fdt, 2, "xen,linux-acpi",

The ACPI blob is not Linux specific. What about "xen,guest-acpi"?

> +                              "xen,multiboot-module");
> +    if (res) return res;
> +
> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> +                                1, 0, 0);
> +    if (res) return res;
> +
> +    res = fdt_end_node(fdt);
> +    if (res) return res;
> +
> +    res = fdt_end_node(fdt);
> +    if (res) return res;
> +
>       res = fdt_end_node(fdt);
>       if (res) return res;
>
>

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 06/14] libxl/arm: Construct ACPI FADT table
  2016-06-07 13:17   ` Julien Grall
@ 2016-06-07 14:13     ` Shannon Zhao
  2016-06-07 14:14       ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-07 14:13 UTC (permalink / raw)
  To: Julien Grall, Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, peter.huangpeng

On 2016年06月07日 21:17, Julien Grall wrote:
> Hello Shannon,
> 
> It just occurred to me that the way to build the ACPI tables, I am not
> speaking about the value, is very similar to what QEMU does.
> 
Yeah, TBH, I really refer to that in QEMU and there is no special
difference between them to build the tables. And it's also similar to
what we do to generate the ACPI tables for Dom0.

-- 
Shannon

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 06/14] libxl/arm: Construct ACPI FADT table
  2016-06-07 14:13     ` Shannon Zhao
@ 2016-06-07 14:14       ` Julien Grall
  0 siblings, 0 replies; 104+ messages in thread
From: Julien Grall @ 2016-06-07 14:14 UTC (permalink / raw)
  To: Shannon Zhao, Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, peter.huangpeng

On 07/06/16 15:13, Shannon Zhao wrote:
> On 2016年06月07日 21:17, Julien Grall wrote:
>> Hello Shannon,
>>
>> It just occurred to me that the way to build the ACPI tables, I am not
>> speaking about the value, is very similar to what QEMU does.
>>
> Yeah, TBH, I really refer to that in QEMU and there is no special
> difference between them to build the tables. And it's also similar to
> what we do to generate the ACPI tables for Dom0.

We have to retain the copyright then.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-07 10:54       ` Julien Grall
@ 2016-06-07 14:24         ` Boris Ostrovsky
  0 siblings, 0 replies; 104+ messages in thread
From: Boris Ostrovsky @ 2016-06-07 14:24 UTC (permalink / raw)
  To: Julien Grall, Wei Liu, Shannon Zhao
  Cc: peter.huangpeng, sstabellini, ian.jackson, shannon.zhao, xen-devel

On 06/07/2016 06:54 AM, Julien Grall wrote:
> Hello Boris,
>
> On 06/06/16 17:50, Boris Ostrovsky wrote:
>> On 06/06/2016 11:37 AM, Boris Ostrovsky wrote:
>>>> What I don't want to see is that x86 builds its ACPI table in libxc
>>>> while ARM builds its in libxl. That would make future merger harder.
>>>>
>>>> Boris?
>>> TBH, I am not sure which library this should really belong to. I felt
>>> libxc would be more appropriate.
>>
>> Actually, I now remember why I picked libxc: because I wanted ACPI pages
>> to be loaded as part of xc_dom_build_image().
>
> What about adding a new field in xc_dom_image? For the device tree,
> libxl is provide a buffer which will be loaded as part of
> xc_dom_build_image (see devicetree_blob).

Yes, I think we can do this (although I suspect we will need more than
one field there).

Still, we need first to understand where this code should live logically
(i.e. is this the type of things that libxl does or is it the type of
things that libxc does) instead of trying to see where we can jam it.

(And only then we will argue that we can't put it in that logical place
due to whatever excuses we can come up with ;-) )

-boris


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 07/14] libxl/arm: Construct ACPI DSDT table
  2016-06-07 13:42   ` Julien Grall
@ 2016-06-16  6:25     ` Shannon Zhao
  2016-06-16  9:44       ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-16  6:25 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng



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 prefer the latter, but this will add more codes to libxl.

Thanks,
-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-07 13:06                   ` Julien Grall
@ 2016-06-16  6:53                     ` Shannon Zhao
  2016-06-16 10:21                       ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-16  6:53 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: sstabellini, wei.liu2, Steve Capper, ian.jackson,
	peter.huangpeng, shannon.zhao

Hi Julien,

On 2016/6/7 21:06, Julien Grall wrote:
>> That's its own mechanism I think and UEFI wants all the memory maps
>> under its control. And it's same for QEMU(x86 and ARM) and also for Xen
>> on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
>> is used for x86 Xen DomU.
> 
> UEFI cannot control the memory map because it is not capable to know
> what a region is used for (such as magic pages, grant table...).
> 
> In the case of domU for x86, the ACPI table are located in predefine
> physical address by hvmloader.
The truth is that hvmloader puts the tables at address
ACPI_PHYSICAL_ADDRESS(0x000EA020), but UEFI will install the tables and
relocate them as well. You can see OvmfPkg/AcpiPlatformDxe/Xen.c in edk2
source code.

So I think it's same with ARM except x86 puts the tables at one fixed
address while ARM dynamically computes the address and passes the
address information to UEFI through dts.

Yeah, of course we can let ARM put the tables at one fixed address and
also it doesn't need the ACPI module to pass the address and let UEFI
find the RSDP table from the fixed address. But what's the difference
between the fixed and dynamicall ones? Because both ways UEFI will
install and relocate the tables.

> I really don't see any reason that would
> prevent us to do the same on ARM.
> 
> If the UEFI firmware wants to relocate the tables, then fine. But we
> should also think about any firmware which may not relocate the tables.
Can you name one firmware except the UEFI?
Actually I have the same worries before when I handle the RTC device
problem between UEFI and QEMU. You can see the conversation from below urls.

http://permalink.gmane.org/gmane.comp.bios.edk2.devel/6474
https://lists.gnu.org/archive/html/qemu-arm/2016-01/msg00132.html

Thanks,
-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 07/14] libxl/arm: Construct ACPI DSDT table
  2016-06-16  6:25     ` Shannon Zhao
@ 2016-06-16  9:44       ` Julien Grall
  2016-06-16 10:01         ` Stefano Stabellini
  0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-16  9:44 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: wei.liu2, sstabellini, ian.jackson, shannon.zhao, peter.huangpeng

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 07/14] libxl/arm: Construct ACPI DSDT table
  2016-06-16  9:44       ` Julien Grall
@ 2016-06-16 10:01         ` Stefano Stabellini
  0 siblings, 0 replies; 104+ messages in thread
From: Stefano Stabellini @ 2016-06-16 10:01 UTC (permalink / raw)
  To: Julien Grall
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	shannon.zhao, Shannon Zhao

On Thu, 16 Jun 2016, Julien Grall wrote:
> 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?

Indeed, this is the right question. If we can get away with static
tables like on x86, we should. Less code is always better than more code
:-)

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-16  6:53                     ` Shannon Zhao
@ 2016-06-16 10:21                       ` Julien Grall
  2016-06-16 10:45                         ` Shannon Zhao
  0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-16 10:21 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: sstabellini, wei.liu2, Steve Capper, ian.jackson,
	peter.huangpeng, shannon.zhao



On 16/06/16 07:53, Shannon Zhao wrote:
> Hi Julien,

Hi Shannon,

>
> On 2016/6/7 21:06, Julien Grall wrote:
>>> That's its own mechanism I think and UEFI wants all the memory maps
>>> under its control. And it's same for QEMU(x86 and ARM) and also for Xen
>>> on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
>>> is used for x86 Xen DomU.
>>
>> UEFI cannot control the memory map because it is not capable to know
>> what a region is used for (such as magic pages, grant table...).
>>
>> In the case of domU for x86, the ACPI table are located in predefine
>> physical address by hvmloader.
> The truth is that hvmloader puts the tables at address
> ACPI_PHYSICAL_ADDRESS(0x000EA020), but UEFI will install the tables and
> relocate them as well. You can see OvmfPkg/AcpiPlatformDxe/Xen.c in edk2
> source code.
>
> So I think it's same with ARM except x86 puts the tables at one fixed
> address while ARM dynamically computes the address and passes the
> address information to UEFI through dts.
>
> Yeah, of course we can let ARM put the tables at one fixed address and
> also it doesn't need the ACPI module to pass the address and let UEFI
> find the RSDP table from the fixed address. But what's the difference
> between the fixed and dynamicall ones? Because both ways UEFI will
> install and relocate the tables.

You seem to think that OVMF is the only UEFI implementation available 
and its behavior is set in stone. Can you quote the UEFI spec stating 
the ACPI tables will always be relocated?

If not, putting the ACPI module right in the middle of memory is not the 
wisest choice because the tables can not be easily relocated like other 
modules (DT, Kernel, initramfs).

My suggestion to put the ACPI tables at a static address outside the RAM 
is to let the choice to the firmware to do whatever it wants without 
impacting the performance of a kernel if it ever decides to keep in 
place the tables.

However, this static address is from the toolstack point of view. The 
firmware should not assume any static address because the guest memory 
layout is not part of the ABI for Xen ARM (i.e it can be modified 
between two releases). This is to allow us reshuffling the layout to 
make space for new features.

>
>> I really don't see any reason that would
>> prevent us to do the same on ARM.
>>
>> If the UEFI firmware wants to relocate the tables, then fine. But we
>> should also think about any firmware which may not relocate the tables.
> Can you name one firmware except the UEFI?

Sorry I meant any other UEFI implementation (i.e other than OVMF) may 
not relocate the tables.

Cheers,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-16 10:21                       ` Julien Grall
@ 2016-06-16 10:45                         ` Shannon Zhao
  2016-06-16 11:04                           ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-16 10:45 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: sstabellini, wei.liu2, Steve Capper, ian.jackson,
	peter.huangpeng, shannon.zhao



On 2016/6/16 18:21, Julien Grall wrote:
> 
> 
> On 16/06/16 07:53, Shannon Zhao wrote:
>> Hi Julien,
> 
> Hi Shannon,
> 
>>
>> On 2016/6/7 21:06, Julien Grall wrote:
>>>> That's its own mechanism I think and UEFI wants all the memory maps
>>>> under its control. And it's same for QEMU(x86 and ARM) and also for Xen
>>>> on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
>>>> is used for x86 Xen DomU.
>>>
>>> UEFI cannot control the memory map because it is not capable to know
>>> what a region is used for (such as magic pages, grant table...).
>>>
>>> In the case of domU for x86, the ACPI table are located in predefine
>>> physical address by hvmloader.
>> The truth is that hvmloader puts the tables at address
>> ACPI_PHYSICAL_ADDRESS(0x000EA020), but UEFI will install the tables and
>> relocate them as well. You can see OvmfPkg/AcpiPlatformDxe/Xen.c in edk2
>> source code.
>>
>> So I think it's same with ARM except x86 puts the tables at one fixed
>> address while ARM dynamically computes the address and passes the
>> address information to UEFI through dts.
>>
>> Yeah, of course we can let ARM put the tables at one fixed address and
>> also it doesn't need the ACPI module to pass the address and let UEFI
>> find the RSDP table from the fixed address. But what's the difference
>> between the fixed and dynamicall ones? Because both ways UEFI will
>> install and relocate the tables.
> 
> You seem to think that OVMF is the only UEFI implementation available
> and its behavior is set in stone. Can you quote the UEFI spec stating
> the ACPI tables will always be relocated?
> 
> If not, putting the ACPI module right in the middle of memory is not the
> wisest choice because the tables can not be easily relocated like other
> modules (DT, Kernel, initramfs).
> 
The ACPI tables are put after the DT. How could you say the ACPI is in
the middle while DT not?

> My suggestion to put the ACPI tables at a static address outside the RAM
> is to let the choice to the firmware to do whatever it wants without
> impacting the performance of a kernel if it ever decides to keep in
> place the tables.
> 
> However, this static address is from the toolstack point of view. The
> firmware should not assume any static address because the guest memory
> layout is not part of the ABI for Xen ARM (i.e it can be modified
> between two releases). This is to allow us reshuffling the layout to
> make space for new features.
> 
Sure? Currently for Xen x86, edk2 uses XEN_ACPI_PHYSICAL_ADDRESS to find
RSDP. If we put the tables at another address, DomU will fail to boot.

>>
>>> I really don't see any reason that would
>>> prevent us to do the same on ARM.
>>>
>>> If the UEFI firmware wants to relocate the tables, then fine. But we
>>> should also think about any firmware which may not relocate the tables.
>> Can you name one firmware except the UEFI?
> 
> Sorry I meant any other UEFI implementation (i.e other than OVMF) may
> not relocate the tables.
So please tell me the name of other UEFI implementation.

Thanks,
-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-07 12:32                 ` Shannon Zhao
  2016-06-07 13:06                   ` Julien Grall
@ 2016-06-16 10:49                   ` Wei Liu
  2016-06-16 10:53                     ` Shannon Zhao
  1 sibling, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-06-16 10:49 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	Julien Grall, shannon.zhao

On Tue, Jun 07, 2016 at 08:32:26PM +0800, Shannon Zhao wrote:
[...]
> That's its own mechanism I think and UEFI wants all the memory maps
> under its control. And it's same for QEMU(x86 and ARM) and also for Xen
> on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
> is used for x86 Xen DomU.
> 

I don't think Xen relocates ACPI tables in OVMF. The code scans for
signature in code.

I also don't quite get the "control memory map" part. OVMF doesn't
update the memory map, it accepts the memory map provided by hvmloader
as-is. See OvmfPkg/PlatformPei/Xen.c:XenGetE820Map.

Note that I'm talking about this in a pretty out of context way, so I
could be misunderstading what you said.

> > Anyway, you rely on the UEFI firmware to always relocating the tables.
> > What would happen if they decide to remove this behavior?
> Eh, I don't believe this would happen.
> 

I think we can only rely on the spec to be sure.

Wei.

> -- 
> Shannon
> 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-16 10:49                   ` Wei Liu
@ 2016-06-16 10:53                     ` Shannon Zhao
  2016-06-16 11:04                       ` Wei Liu
  0 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-16 10:53 UTC (permalink / raw)
  To: Wei Liu
  Cc: sstabellini, ian.jackson, peter.huangpeng, xen-devel,
	Julien Grall, shannon.zhao



On 2016/6/16 18:49, Wei Liu wrote:
> On Tue, Jun 07, 2016 at 08:32:26PM +0800, Shannon Zhao wrote:
> [...]
>> > That's its own mechanism I think and UEFI wants all the memory maps
>> > under its control. And it's same for QEMU(x86 and ARM) and also for Xen
>> > on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
>> > is used for x86 Xen DomU.
>> > 
> I don't think Xen relocates ACPI tables in OVMF. The code scans for
> signature in code.
Maybe you can have a look at the function InstallXenTables().

Thanks,
-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-16 10:45                         ` Shannon Zhao
@ 2016-06-16 11:04                           ` Julien Grall
  0 siblings, 0 replies; 104+ messages in thread
From: Julien Grall @ 2016-06-16 11:04 UTC (permalink / raw)
  To: Shannon Zhao, xen-devel
  Cc: sstabellini, wei.liu2, Steve Capper, ian.jackson,
	peter.huangpeng, shannon.zhao

Hello Shannon,

On 16/06/16 11:45, Shannon Zhao wrote:
>>> On 2016/6/7 21:06, Julien Grall wrote:
>>>>> That's its own mechanism I think and UEFI wants all the memory maps
>>>>> under its control. And it's same for QEMU(x86 and ARM) and also for Xen
>>>>> on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
>>>>> is used for x86 Xen DomU.
>>>>
>>>> UEFI cannot control the memory map because it is not capable to know
>>>> what a region is used for (such as magic pages, grant table...).
>>>>
>>>> In the case of domU for x86, the ACPI table are located in predefine
>>>> physical address by hvmloader.
>>> The truth is that hvmloader puts the tables at address
>>> ACPI_PHYSICAL_ADDRESS(0x000EA020), but UEFI will install the tables and
>>> relocate them as well. You can see OvmfPkg/AcpiPlatformDxe/Xen.c in edk2
>>> source code.
>>>
>>> So I think it's same with ARM except x86 puts the tables at one fixed
>>> address while ARM dynamically computes the address and passes the
>>> address information to UEFI through dts.
>>>
>>> Yeah, of course we can let ARM put the tables at one fixed address and
>>> also it doesn't need the ACPI module to pass the address and let UEFI
>>> find the RSDP table from the fixed address. But what's the difference
>>> between the fixed and dynamicall ones? Because both ways UEFI will
>>> install and relocate the tables.
>>
>> You seem to think that OVMF is the only UEFI implementation available
>> and its behavior is set in stone. Can you quote the UEFI spec stating
>> the ACPI tables will always be relocated?
>>
>> If not, putting the ACPI module right in the middle of memory is not the
>> wisest choice because the tables can not be easily relocated like other
>> modules (DT, Kernel, initramfs).
>>
> The ACPI tables are put after the DT. How could you say the ACPI is in
> the middle while DT not?

Because the position of the DT in the memory is defined by the Linux 
boot ABI (see section 4.b in Documentation/arm/Booting).

>
>> My suggestion to put the ACPI tables at a static address outside the RAM
>> is to let the choice to the firmware to do whatever it wants without
>> impacting the performance of a kernel if it ever decides to keep in
>> place the tables.
>>
>> However, this static address is from the toolstack point of view. The
>> firmware should not assume any static address because the guest memory
>> layout is not part of the ABI for Xen ARM (i.e it can be modified
>> between two releases). This is to allow us reshuffling the layout to
>> make space for new features.
>>
> Sure? Currently for Xen x86, edk2 uses XEN_ACPI_PHYSICAL_ADDRESS to find
> RSDP. If we put the tables at another address, DomU will fail to boot.

I am not sure to follow here. Why do you mention x86 here? My point was 
only for ARM and we are not tight to what x86 does.

>
>>>
>>>> I really don't see any reason that would
>>>> prevent us to do the same on ARM.
>>>>
>>>> If the UEFI firmware wants to relocate the tables, then fine. But we
>>>> should also think about any firmware which may not relocate the tables.
>>> Can you name one firmware except the UEFI?
>>
>> Sorry I meant any other UEFI implementation (i.e other than OVMF) may
>> not relocate the tables.
> So please tell me the name of other UEFI implementation.

What is the point? All our decision should be based on the specification 
and not ONE specific implementation.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
  2016-06-16 10:53                     ` Shannon Zhao
@ 2016-06-16 11:04                       ` Wei Liu
  0 siblings, 0 replies; 104+ messages in thread
From: Wei Liu @ 2016-06-16 11:04 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: sstabellini, Wei Liu, ian.jackson, peter.huangpeng, xen-devel,
	Julien Grall, shannon.zhao

On Thu, Jun 16, 2016 at 06:53:37PM +0800, Shannon Zhao wrote:
> 
> 
> On 2016/6/16 18:49, Wei Liu wrote:
> > On Tue, Jun 07, 2016 at 08:32:26PM +0800, Shannon Zhao wrote:
> > [...]
> >> > That's its own mechanism I think and UEFI wants all the memory maps
> >> > under its control. And it's same for QEMU(x86 and ARM) and also for Xen
> >> > on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
> >> > is used for x86 Xen DomU.
> >> > 
> > I don't think Xen relocates ACPI tables in OVMF. The code scans for
> > signature in code.
> Maybe you can have a look at the function InstallXenTables().
> 

Oh, I thought you were talking about Xen specific code. That's my
misunderstanding.

So that function (InstallXenTables) calls InstallAcpiTable, which
eventually calls AcpiProtocol->InstallAcpiTable.

Does it imply "UEFI wants all memory maps under its control"? Does it
imply UEFI will relocate those tables (or keep a copy to itself)?  The
answer "implementation specific" or "not sure" is not good enough to
address Julien's concern.

Maybe this is just due to miscommunication or using the wrong term. I
will refrain from commenting further now because the issue is quite ARM
specific. Don't want to distract you guys further.

Wei.

> Thanks,
> -- 
> Shannon
> 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-07 11:00       ` Julien Grall
@ 2016-06-16 11:20         ` Wei Liu
  2016-06-16 13:25           ` Boris Ostrovsky
                             ` (2 more replies)
  0 siblings, 3 replies; 104+ messages in thread
From: Wei Liu @ 2016-06-16 11:20 UTC (permalink / raw)
  To: Julien Grall
  Cc: sstabellini, Wei Liu, ian.jackson, peter.huangpeng, xen-devel,
	shannon.zhao, Shannon Zhao, Boris Ostrovsky

On Tue, Jun 07, 2016 at 12:00:26PM +0100, Julien Grall wrote:
> Hello Shannon,
> 
> On 07/06/16 02:07, Shannon Zhao wrote:
> >On 2016/6/6 23:48, Julien Grall wrote:
> >>On 06/06/16 13:26, Wei Liu wrote:
> >>>On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote:
> >>>>From: Shannon Zhao <shannon.zhao@linaro.org>
> >>>>
> >>>>The design of this feature is described as below.
> >>>>Firstly, the toolstack (libxl) generates the ACPI tables according the
> >>>>number of vcpus and gic controller.
> >>>>
> >>>>Then, it copies these ACPI tables to DomU memory space and passes
> >>>>them to UEFI firmware through the "ARM multiboot" protocol.
> >>>>
> >>>>At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
> >>>>and installs these tables like the usual way and passes both ACPI and DT
> >>>>information to the Xen DomU.
> >>>>
> >>>>Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
> >>>>since it's enough now.
> >>>>
> >>>>This has been tested using guest kernel with the Dom0 ACPI support
> >>>>patches which could be fetched from:
> >>>>https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
> >>>>
> >>>>
> >>>>Shannon Zhao (14):
> >>>>    libxl/arm: Fix the function name in error log
> >>>>    libxl/arm: Factor out codes for generating DTB
> >>>>    libxc: Add placeholders for ACPI tables blob and size
> >>>>    tools: add ACPI tables relevant definitions
> >>>>    libxl/arm: Construct ACPI GTDT table
> >>>>    libxl/arm: Construct ACPI FADT table
> >>>>    libxl/arm: Construct ACPI DSDT table
> >>>>    libxl/arm: Construct ACPI MADT table
> >>>>    libxl/arm: Construct ACPI XSDT table
> >>>>    libxl/arm: Construct ACPI RSDP table
> >>>>    libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
> >>>>    libxl/arm: Add ACPI module
> >>>>    libxl/arm: initialize memory information of ACPI blob
> >>>>    libxc/xc_dom_core: Copy ACPI tables to guest memory space
> >>>>
> >>>
> >>>After going through this series, I think the code mostly looks good.
> >>>
> >>>There is one higher level question: you seem to have put a lot of the
> >>>table construction code in libxl, while I failed to see why specific
> >>>libxl information is needed. Have you considered moving the code to
> >>>libxc?
> >>
> >>I would rather avoid to have the device tree built by libxl and ACPI
> >>tables built by libxc.
> >>
> >>I don't remember why we have decided to implement DT building in libxl,
> >>I guess it is because we need to know which GIC version is used (GICv2
> >>vs GICv3).
> >>
> >>In the long run, we might also need to have more part of the firmware
> >>configurable (performance monitor support, memory layout, UART...).
> >>
> >>Most of those information are available easily in libxl, we would to
> >>export them of libxc.
> >Yes, and one more reason is that to support ACPI, it also needs to add
> >the ACPI multiboot module in DT.
> 
> I don't consider this as a reason for building the ACPI tables in libxl. I
> am more concerned about building the firmwares in different place.
> 
> If we decide to build the ACPI tables in libxc, then the code to build the
> device tree should move in libxc too.
> 

I've read this sub-thread and the other thread in which Boris replied, I
think due to the fact that libxl has more information at hand and libxc
is intended to be simple, I think having the building code in libxl
makes sense.

Shannon, Boris and Julien, what do you guys think? Can we agree on
something so that Shannon can move on with next iteration?

Wei.

> Regards,
> 
> -- 
> Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-16 11:20         ` Wei Liu
@ 2016-06-16 13:25           ` Boris Ostrovsky
  2016-06-17 10:14             ` Wei Liu
  2016-06-17  2:03           ` Shannon Zhao
  2016-06-17  8:18           ` Julien Grall
  2 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-06-16 13:25 UTC (permalink / raw)
  To: Wei Liu, Julien Grall
  Cc: sstabellini, ian.jackson, peter.huangpeng, xen-devel,
	shannon.zhao, Shannon Zhao

On 06/16/2016 07:20 AM, Wei Liu wrote:
> On Tue, Jun 07, 2016 at 12:00:26PM +0100, Julien Grall wrote:
>> Hello Shannon,
>>
>> On 07/06/16 02:07, Shannon Zhao wrote:
>>> On 2016/6/6 23:48, Julien Grall wrote:
>>>> On 06/06/16 13:26, Wei Liu wrote:
>>>>> On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote:
>>>>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>>>
>>>>>> The design of this feature is described as below.
>>>>>> Firstly, the toolstack (libxl) generates the ACPI tables according the
>>>>>> number of vcpus and gic controller.
>>>>>>
>>>>>> Then, it copies these ACPI tables to DomU memory space and passes
>>>>>> them to UEFI firmware through the "ARM multiboot" protocol.
>>>>>>
>>>>>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>>>>>> and installs these tables like the usual way and passes both ACPI and DT
>>>>>> information to the Xen DomU.
>>>>>>
>>>>>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
>>>>>> since it's enough now.
>>>>>>
>>>>>> This has been tested using guest kernel with the Dom0 ACPI support
>>>>>> patches which could be fetched from:
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>>>>>
>>>>>>
>>>>>> Shannon Zhao (14):
>>>>>>    libxl/arm: Fix the function name in error log
>>>>>>    libxl/arm: Factor out codes for generating DTB
>>>>>>    libxc: Add placeholders for ACPI tables blob and size
>>>>>>    tools: add ACPI tables relevant definitions
>>>>>>    libxl/arm: Construct ACPI GTDT table
>>>>>>    libxl/arm: Construct ACPI FADT table
>>>>>>    libxl/arm: Construct ACPI DSDT table
>>>>>>    libxl/arm: Construct ACPI MADT table
>>>>>>    libxl/arm: Construct ACPI XSDT table
>>>>>>    libxl/arm: Construct ACPI RSDP table
>>>>>>    libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
>>>>>>    libxl/arm: Add ACPI module
>>>>>>    libxl/arm: initialize memory information of ACPI blob
>>>>>>    libxc/xc_dom_core: Copy ACPI tables to guest memory space
>>>>>>
>>>>> After going through this series, I think the code mostly looks good.
>>>>>
>>>>> There is one higher level question: you seem to have put a lot of the
>>>>> table construction code in libxl, while I failed to see why specific
>>>>> libxl information is needed. Have you considered moving the code to
>>>>> libxc?
>>>> I would rather avoid to have the device tree built by libxl and ACPI
>>>> tables built by libxc.
>>>>
>>>> I don't remember why we have decided to implement DT building in libxl,
>>>> I guess it is because we need to know which GIC version is used (GICv2
>>>> vs GICv3).
>>>>
>>>> In the long run, we might also need to have more part of the firmware
>>>> configurable (performance monitor support, memory layout, UART...).
>>>>
>>>> Most of those information are available easily in libxl, we would to
>>>> export them of libxc.
>>> Yes, and one more reason is that to support ACPI, it also needs to add
>>> the ACPI multiboot module in DT.
>> I don't consider this as a reason for building the ACPI tables in libxl. I
>> am more concerned about building the firmwares in different place.
>>
>> If we decide to build the ACPI tables in libxc, then the code to build the
>> device tree should move in libxc too.
>>
> I've read this sub-thread and the other thread in which Boris replied, I
> think due to the fact that libxl has more information at hand and libxc
> is intended to be simple, I think having the building code in libxl
> makes sense.
>
> Shannon, Boris and Julien, what do you guys think? Can we agree on
> something so that Shannon can move on with next iteration?

I kind of agree that libxl is perhaps a better place but it would be
good to have something more than "libxc is intended to be simple" that
tells us what goes where. In other words -- what libxl is for and what
libxc is for.

For example libxl_x86.c and xc_dom86.c. The latter has a comment at the
top that says this is for arch-specific code. But there is plenty of
arch-specific stuff (e820) in libxl file.

-boris


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-16 11:20         ` Wei Liu
  2016-06-16 13:25           ` Boris Ostrovsky
@ 2016-06-17  2:03           ` Shannon Zhao
  2016-06-17  8:18           ` Julien Grall
  2 siblings, 0 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-06-17  2:03 UTC (permalink / raw)
  To: Wei Liu, Julien Grall
  Cc: sstabellini, ian.jackson, peter.huangpeng, xen-devel,
	shannon.zhao, Boris Ostrovsky



On 2016/6/16 19:20, Wei Liu wrote:
> I've read this sub-thread and the other thread in which Boris replied, I
> think due to the fact that libxl has more information at hand and libxc
> is intended to be simple, I think having the building code in libxl
> makes sense.
> 
> Shannon, Boris and Julien, what do you guys think? Can we agree on
> something so that Shannon can move on with next iteration?
I agree with this and will work on the next version of this series.

Thanks,
-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-06 11:40   ` Stefano Stabellini
  2016-06-06 11:52     ` Julien Grall
@ 2016-06-17  3:29     ` Shannon Zhao
  2016-06-17  8:17       ` Julien Grall
  1 sibling, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-17  3:29 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: wei.liu2, ian.jackson, peter.huangpeng, xen-devel, julien.grall,
	shannon.zhao



On 2016/6/6 19:40, Stefano Stabellini wrote:
> ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
> config file enables them, with default off.
While the configuration "acpi" already exists for HVM guest
configuration, do we plan to reuse it or use a new name, e.g. arm_acpi?

Thanks,
-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-17  3:29     ` Shannon Zhao
@ 2016-06-17  8:17       ` Julien Grall
  2016-06-17  9:15         ` Stefano Stabellini
  0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-17  8:17 UTC (permalink / raw)
  To: Shannon Zhao, Stefano Stabellini
  Cc: wei.liu2, peter.huangpeng, ian.jackson, shannon.zhao, xen-devel

Hello Shannon,

On 17/06/16 04:29, Shannon Zhao wrote:
> On 2016/6/6 19:40, Stefano Stabellini wrote:
>> ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
>> config file enables them, with default off.
> While the configuration "acpi" already exists for HVM guest
> configuration, do we plan to reuse it or use a new name, e.g. arm_acpi?

We always try to re-use options unless their meaning are completely 
different.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-16 11:20         ` Wei Liu
  2016-06-16 13:25           ` Boris Ostrovsky
  2016-06-17  2:03           ` Shannon Zhao
@ 2016-06-17  8:18           ` Julien Grall
  2 siblings, 0 replies; 104+ messages in thread
From: Julien Grall @ 2016-06-17  8:18 UTC (permalink / raw)
  To: Wei Liu
  Cc: sstabellini, ian.jackson, peter.huangpeng, xen-devel,
	shannon.zhao, Shannon Zhao, Boris Ostrovsky

Hi Wei,

On 16/06/16 12:20, Wei Liu wrote:
> On Tue, Jun 07, 2016 at 12:00:26PM +0100, Julien Grall wrote:
> I've read this sub-thread and the other thread in which Boris replied, I
> think due to the fact that libxl has more information at hand and libxc
> is intended to be simple, I think having the building code in libxl
> makes sense.
>
> Shannon, Boris and Julien, what do you guys think? Can we agree on
> something so that Shannon can move on with next iteration?

It sounds good to me.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-17  8:17       ` Julien Grall
@ 2016-06-17  9:15         ` Stefano Stabellini
  2016-06-17 13:27           ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Stefano Stabellini @ 2016-06-17  9:15 UTC (permalink / raw)
  To: Julien Grall
  Cc: Stefano Stabellini, wei.liu2, ian.jackson, peter.huangpeng,
	xen-devel, shannon.zhao, Shannon Zhao

On Fri, 17 Jun 2016, Julien Grall wrote:
> Hello Shannon,
> 
> On 17/06/16 04:29, Shannon Zhao wrote:
> > On 2016/6/6 19:40, Stefano Stabellini wrote:
> > > ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
> > > config file enables them, with default off.
> > While the configuration "acpi" already exists for HVM guest
> > configuration, do we plan to reuse it or use a new name, e.g. arm_acpi?
> 
> We always try to re-use options unless their meaning are completely different.
 
I agree. "acpi" is a good name for it. I would avoid introducing
something like "arm_acpi".

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 00/14] Xen ARM DomU ACPI support
  2016-06-16 13:25           ` Boris Ostrovsky
@ 2016-06-17 10:14             ` Wei Liu
  0 siblings, 0 replies; 104+ messages in thread
From: Wei Liu @ 2016-06-17 10:14 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: sstabellini, Wei Liu, ian.jackson, peter.huangpeng, xen-devel,
	Julien Grall, shannon.zhao, Shannon Zhao

On Thu, Jun 16, 2016 at 09:25:20AM -0400, Boris Ostrovsky wrote:
> On 06/16/2016 07:20 AM, Wei Liu wrote:
> > On Tue, Jun 07, 2016 at 12:00:26PM +0100, Julien Grall wrote:
> >> Hello Shannon,
> >>
> >> On 07/06/16 02:07, Shannon Zhao wrote:
> >>> On 2016/6/6 23:48, Julien Grall wrote:
> >>>> On 06/06/16 13:26, Wei Liu wrote:
> >>>>> On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote:
> >>>>>> From: Shannon Zhao <shannon.zhao@linaro.org>
> >>>>>>
> >>>>>> The design of this feature is described as below.
> >>>>>> Firstly, the toolstack (libxl) generates the ACPI tables according the
> >>>>>> number of vcpus and gic controller.
> >>>>>>
> >>>>>> Then, it copies these ACPI tables to DomU memory space and passes
> >>>>>> them to UEFI firmware through the "ARM multiboot" protocol.
> >>>>>>
> >>>>>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
> >>>>>> and installs these tables like the usual way and passes both ACPI and DT
> >>>>>> information to the Xen DomU.
> >>>>>>
> >>>>>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
> >>>>>> since it's enough now.
> >>>>>>
> >>>>>> This has been tested using guest kernel with the Dom0 ACPI support
> >>>>>> patches which could be fetched from:
> >>>>>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
> >>>>>>
> >>>>>>
> >>>>>> Shannon Zhao (14):
> >>>>>>    libxl/arm: Fix the function name in error log
> >>>>>>    libxl/arm: Factor out codes for generating DTB
> >>>>>>    libxc: Add placeholders for ACPI tables blob and size
> >>>>>>    tools: add ACPI tables relevant definitions
> >>>>>>    libxl/arm: Construct ACPI GTDT table
> >>>>>>    libxl/arm: Construct ACPI FADT table
> >>>>>>    libxl/arm: Construct ACPI DSDT table
> >>>>>>    libxl/arm: Construct ACPI MADT table
> >>>>>>    libxl/arm: Construct ACPI XSDT table
> >>>>>>    libxl/arm: Construct ACPI RSDP table
> >>>>>>    libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
> >>>>>>    libxl/arm: Add ACPI module
> >>>>>>    libxl/arm: initialize memory information of ACPI blob
> >>>>>>    libxc/xc_dom_core: Copy ACPI tables to guest memory space
> >>>>>>
> >>>>> After going through this series, I think the code mostly looks good.
> >>>>>
> >>>>> There is one higher level question: you seem to have put a lot of the
> >>>>> table construction code in libxl, while I failed to see why specific
> >>>>> libxl information is needed. Have you considered moving the code to
> >>>>> libxc?
> >>>> I would rather avoid to have the device tree built by libxl and ACPI
> >>>> tables built by libxc.
> >>>>
> >>>> I don't remember why we have decided to implement DT building in libxl,
> >>>> I guess it is because we need to know which GIC version is used (GICv2
> >>>> vs GICv3).
> >>>>
> >>>> In the long run, we might also need to have more part of the firmware
> >>>> configurable (performance monitor support, memory layout, UART...).
> >>>>
> >>>> Most of those information are available easily in libxl, we would to
> >>>> export them of libxc.
> >>> Yes, and one more reason is that to support ACPI, it also needs to add
> >>> the ACPI multiboot module in DT.
> >> I don't consider this as a reason for building the ACPI tables in libxl. I
> >> am more concerned about building the firmwares in different place.
> >>
> >> If we decide to build the ACPI tables in libxc, then the code to build the
> >> device tree should move in libxc too.
> >>
> > I've read this sub-thread and the other thread in which Boris replied, I
> > think due to the fact that libxl has more information at hand and libxc
> > is intended to be simple, I think having the building code in libxl
> > makes sense.
> >
> > Shannon, Boris and Julien, what do you guys think? Can we agree on
> > something so that Shannon can move on with next iteration?
> 
> I kind of agree that libxl is perhaps a better place but it would be
> good to have something more than "libxc is intended to be simple" that
> tells us what goes where. In other words -- what libxl is for and what
> libxc is for.
> 
> For example libxl_x86.c and xc_dom86.c. The latter has a comment at the
> top that says this is for arch-specific code. But there is plenty of
> arch-specific stuff (e820) in libxl file.
> 

I myself have long been following the convention that any complex
decision should be made inside libxl because it just has more
information than libxc and a plethora of machinery at its disposal.
Libxc should merely be a wrapper for the underlying hypervisor
interface. There are, of course, exceptions that the libxc functions
look a bit more complex because we want to provide some compatibility
where we can, but keep in mind that libxc is meant to be unstable so
that semantics is subject to change at any time.

Overtime the evolution of libraries will certainly leave some areas
unclear.  The E820 code is an example that libxc is not able to make
decision on its own and we move that to libxl. I wouldn't want libxc to
know how to construct memory map for RDM + vNUMA + whatever comes next.

Wei.

> -boris
> 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 01/14] libxl/arm: Fix the function name in error log
  2016-06-03 19:25   ` Wei Liu
@ 2016-06-17 10:46     ` Wei Liu
  2016-06-20  1:12       ` Shannon Zhao
  0 siblings, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-06-17 10:46 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: sstabellini, wei.liu2, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao

On Fri, Jun 03, 2016 at 08:25:05PM +0100, Wei Liu wrote:
> On Tue, May 31, 2016 at 01:02:53PM +0800, Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@linaro.org>
> > 
> > It should be xc_dom_devicetree_mem instead of xc_dom_devicetree_file.
> > 
> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> 
> Acked-by: Wei Liu <wei.liu2@citrix.com>
> 

I've pushed this to staging to reduce the length of your patch queue.

Wei.

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
  2016-06-17  9:15         ` Stefano Stabellini
@ 2016-06-17 13:27           ` Julien Grall
  0 siblings, 0 replies; 104+ messages in thread
From: Julien Grall @ 2016-06-17 13:27 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: wei.liu2, ian.jackson, peter.huangpeng, xen-devel, shannon.zhao,
	Shannon Zhao



On 17/06/16 10:15, Stefano Stabellini wrote:
> On Fri, 17 Jun 2016, Julien Grall wrote:
>> Hello Shannon,
>>
>> On 17/06/16 04:29, Shannon Zhao wrote:
>>> On 2016/6/6 19:40, Stefano Stabellini wrote:
>>>> ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
>>>> config file enables them, with default off.
>>> While the configuration "acpi" already exists for HVM guest
>>> configuration, do we plan to reuse it or use a new name, e.g. arm_acpi?
>>
>> We always try to re-use options unless their meaning are completely different.
>
> I agree. "acpi" is a good name for it. I would avoid introducing
> something like "arm_acpi".

BTW, this value should be default false for at least 32-bit domain.

I am not sure if we agreed what should be the default for 64-bit domain.

Cheers,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 01/14] libxl/arm: Fix the function name in error log
  2016-06-17 10:46     ` Wei Liu
@ 2016-06-20  1:12       ` Shannon Zhao
  0 siblings, 0 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-06-20  1:12 UTC (permalink / raw)
  To: Wei Liu
  Cc: sstabellini, ian.jackson, peter.huangpeng, xen-devel,
	julien.grall, shannon.zhao



On 2016/6/17 18:46, Wei Liu wrote:
> On Fri, Jun 03, 2016 at 08:25:05PM +0100, Wei Liu wrote:
>> > On Tue, May 31, 2016 at 01:02:53PM +0800, Shannon Zhao wrote:
>>> > > From: Shannon Zhao <shannon.zhao@linaro.org>
>>> > > 
>>> > > It should be xc_dom_devicetree_mem instead of xc_dom_devicetree_file.
>>> > > 
>>> > > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > 
>> > Acked-by: Wei Liu <wei.liu2@citrix.com>
>> > 
> I've pushed this to staging to reduce the length of your patch queue.
Thanks a lot, Wei.

-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions
  2016-06-06 12:16         ` Wei Liu
  2016-06-06 14:19           ` Shannon Zhao
@ 2016-06-22  3:24           ` Shannon Zhao
  2016-06-22  8:35             ` Julien Grall
  2016-06-22  9:38             ` [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions (and more) Wei Liu
  1 sibling, 2 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-06-22  3:24 UTC (permalink / raw)
  To: Wei Liu
  Cc: Stefano Stabellini, ian.jackson, peter.huangpeng, xen-devel,
	Julien Grall, shannon.zhao



On 2016/6/6 20:16, Wei Liu wrote:
> On Mon, Jun 06, 2016 at 06:27:25PM +0800, Shannon Zhao wrote:
>> > 
>> > 
>> > On 2016/6/6 18:11, Julien Grall wrote:
>>> > > Hi Stefano,
>>> > > 
>>> > > On 06/06/2016 11:04, Stefano Stabellini wrote:
>>>> > >> On Tue, 31 May 2016, Shannon Zhao wrote:
>>>>> > >>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>> > >>>
>>>>> > >>> Add ACPI tables relevant definitions for generating ACPI tables for ARM
>>>>> > >>> guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT tables will
>>>>> > >>> be used.
>>>>> > >>>
>>>>> > >>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>>> > >>> ---
>>>>> > >>>  tools/libxc/include/acpi_defs.h | 277
>>>>> > >>> ++++++++++++++++++++++++++++++++++++++++
>>>>> > >>>  1 file changed, 277 insertions(+)
>>>>> > >>>  create mode 100644 tools/libxc/include/acpi_defs.h
>>>>> > >>>
>>>>> > >>> diff --git a/tools/libxc/include/acpi_defs.h
>>>>> > >>> b/tools/libxc/include/acpi_defs.h
>>>>> > >>> new file mode 100644
>>>>> > >>> index 0000000..9389a96
>>>>> > >>> --- /dev/null
>>>>> > >>> +++ b/tools/libxc/include/acpi_defs.h
>>>>> > >>> @@ -0,0 +1,277 @@
>>>>> > >>> +#ifndef _ACPI_DEFS_H_
>>>>> > >>> +#define _ACPI_DEFS_H_
>>>>> > >>> +
>>>>> > >>> +#define ACPI_BUILD_APPNAME6 "XenARM"
>>>>> > >>> +#define ACPI_BUILD_APPNAME4 "Xen "
>>>> > >>
>>>> > >> This header is actually ARM specific (also see the gic stuff below). It
>>>> > >> is probably best to rename it to acpi_arm_defs.h.
>>> > > 
>>> > > Should not just we re-use the ACPI headers from xen/include/acpi/ ?
>> > So how to include those headers in tools/libxl/libxl_arm.c ?
>> > 
> Is it public headers? If so, it might already be available in
> tools/include. If not, is it feasible to be made public?
> 
> If in the end the file you need can't end up as a public header, you
> need to manipulate CFLAGS. There is one example in libxc's Makefile.
> Search for libelf.
> 
> But please make sure the CFLAGS doesn't get modified when it is not
> necessary.  I would expect the CFLAGS is explicitly altered for a list
> of files.
I'm trying to do this. Make the libxl acpi codes compile like below in
Makefile:

+libxl_arm_acpi.o: libxl_arm_acpi.c
+       $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c

Add #include <acpi/actbl.h> which includes the tables definitions in
libxl_arm_acpi.c. But there are a lot of compiling errors like below:
error: unknown type name 'u8'
error: unknown type name 'u32'
Looks like these types are defined in xen/include/asm-arm/types.h. I add
#include <asm-arm/types.h> in libxl_arm_acpi.c but it still compiles failed.
In file included from ../../xen/include/asm-arm/types.h:6:0,
                 from libxl_arm_acpi.c:30:
../../xen/include/xen/config.h:10:32: fatal error: generated/autoconf.h:
No such file or directory
 #include <generated/autoconf.h>

Looks like if we try to use the acpi headers under xen/include/acpi like
this way, tools compilation will depends on hypervisor compilation. I
think this is not what we want, right?

Any suggestion?

Thanks,
-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions
  2016-06-22  3:24           ` Shannon Zhao
@ 2016-06-22  8:35             ` Julien Grall
  2016-06-22  8:50               ` Shannon Zhao
  2016-06-22  9:38             ` [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions (and more) Wei Liu
  1 sibling, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-06-22  8:35 UTC (permalink / raw)
  To: Shannon Zhao, Wei Liu
  Cc: peter.huangpeng, Stefano Stabellini, ian.jackson, shannon.zhao,
	xen-devel

Hi Shannon,

On 22/06/2016 04:24, Shannon Zhao wrote:
> On 2016/6/6 20:16, Wei Liu wrote:
>> On Mon, Jun 06, 2016 at 06:27:25PM +0800, Shannon Zhao wrote:
>>>>
>>>>
>>>> On 2016/6/6 18:11, Julien Grall wrote:
>>>>>> Hi Stefano,
>>>>>>
>>>>>> On 06/06/2016 11:04, Stefano Stabellini wrote:
>>>>>>>> On Tue, 31 May 2016, Shannon Zhao wrote:
>>>>>>>>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>>>>>>>
>>>>>>>>>> Add ACPI tables relevant definitions for generating ACPI tables for ARM
>>>>>>>>>> guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT tables will
>>>>>>>>>> be used.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>>>>>>>> ---
>>>>>>>>>>  tools/libxc/include/acpi_defs.h | 277
>>>>>>>>>> ++++++++++++++++++++++++++++++++++++++++
>>>>>>>>>>  1 file changed, 277 insertions(+)
>>>>>>>>>>  create mode 100644 tools/libxc/include/acpi_defs.h
>>>>>>>>>>
>>>>>>>>>> diff --git a/tools/libxc/include/acpi_defs.h
>>>>>>>>>> b/tools/libxc/include/acpi_defs.h
>>>>>>>>>> new file mode 100644
>>>>>>>>>> index 0000000..9389a96
>>>>>>>>>> --- /dev/null
>>>>>>>>>> +++ b/tools/libxc/include/acpi_defs.h
>>>>>>>>>> @@ -0,0 +1,277 @@
>>>>>>>>>> +#ifndef _ACPI_DEFS_H_
>>>>>>>>>> +#define _ACPI_DEFS_H_
>>>>>>>>>> +
>>>>>>>>>> +#define ACPI_BUILD_APPNAME6 "XenARM"
>>>>>>>>>> +#define ACPI_BUILD_APPNAME4 "Xen "
>>>>>>>>
>>>>>>>> This header is actually ARM specific (also see the gic stuff below). It
>>>>>>>> is probably best to rename it to acpi_arm_defs.h.
>>>>>>
>>>>>> Should not just we re-use the ACPI headers from xen/include/acpi/ ?
>>>> So how to include those headers in tools/libxl/libxl_arm.c ?
>>>>
>> Is it public headers? If so, it might already be available in
>> tools/include. If not, is it feasible to be made public?
>>
>> If in the end the file you need can't end up as a public header, you
>> need to manipulate CFLAGS. There is one example in libxc's Makefile.
>> Search for libelf.
>>
>> But please make sure the CFLAGS doesn't get modified when it is not
>> necessary.  I would expect the CFLAGS is explicitly altered for a list
>> of files.
> I'm trying to do this. Make the libxl acpi codes compile like below in
> Makefile:
>
> +libxl_arm_acpi.o: libxl_arm_acpi.c
> +       $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
>
> Add #include <acpi/actbl.h> which includes the tables definitions in
> libxl_arm_acpi.c. But there are a lot of compiling errors like below:
> error: unknown type name 'u8'
> error: unknown type name 'u32'
> Looks like these types are defined in xen/include/asm-arm/types.h. I add
> #include <asm-arm/types.h> in libxl_arm_acpi.c but it still compiles failed.
> In file included from ../../xen/include/asm-arm/types.h:6:0,
>                  from libxl_arm_acpi.c:30:
> ../../xen/include/xen/config.h:10:32: fatal error: generated/autoconf.h:
> No such file or directory
>  #include <generated/autoconf.h>
>
> Looks like if we try to use the acpi headers under xen/include/acpi like
> this way, tools compilation will depends on hypervisor compilation. I
> think this is not what we want, right?

You could define our own u8, u32 types in libxc. They are just aliased 
to uint8_t, uint32_t.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions
  2016-06-22  8:35             ` Julien Grall
@ 2016-06-22  8:50               ` Shannon Zhao
  2016-06-22  8:55                 ` Julien Grall
  0 siblings, 1 reply; 104+ messages in thread
From: Shannon Zhao @ 2016-06-22  8:50 UTC (permalink / raw)
  To: Julien Grall, Wei Liu
  Cc: peter.huangpeng, Stefano Stabellini, ian.jackson, shannon.zhao,
	xen-devel



On 2016/6/22 16:35, Julien Grall wrote:
> Hi Shannon,
> 
> On 22/06/2016 04:24, Shannon Zhao wrote:
>> On 2016/6/6 20:16, Wei Liu wrote:
>>> On Mon, Jun 06, 2016 at 06:27:25PM +0800, Shannon Zhao wrote:
>>>>>
>>>>>
>>>>> On 2016/6/6 18:11, Julien Grall wrote:
>>>>>>> Hi Stefano,
>>>>>>>
>>>>>>> On 06/06/2016 11:04, Stefano Stabellini wrote:
>>>>>>>>> On Tue, 31 May 2016, Shannon Zhao wrote:
>>>>>>>>>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>>>>>>>>
>>>>>>>>>>> Add ACPI tables relevant definitions for generating ACPI
>>>>>>>>>>> tables for ARM
>>>>>>>>>>> guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT
>>>>>>>>>>> tables will
>>>>>>>>>>> be used.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>>>>>>>>> ---
>>>>>>>>>>>  tools/libxc/include/acpi_defs.h | 277
>>>>>>>>>>> ++++++++++++++++++++++++++++++++++++++++
>>>>>>>>>>>  1 file changed, 277 insertions(+)
>>>>>>>>>>>  create mode 100644 tools/libxc/include/acpi_defs.h
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/tools/libxc/include/acpi_defs.h
>>>>>>>>>>> b/tools/libxc/include/acpi_defs.h
>>>>>>>>>>> new file mode 100644
>>>>>>>>>>> index 0000000..9389a96
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/tools/libxc/include/acpi_defs.h
>>>>>>>>>>> @@ -0,0 +1,277 @@
>>>>>>>>>>> +#ifndef _ACPI_DEFS_H_
>>>>>>>>>>> +#define _ACPI_DEFS_H_
>>>>>>>>>>> +
>>>>>>>>>>> +#define ACPI_BUILD_APPNAME6 "XenARM"
>>>>>>>>>>> +#define ACPI_BUILD_APPNAME4 "Xen "
>>>>>>>>>
>>>>>>>>> This header is actually ARM specific (also see the gic stuff
>>>>>>>>> below). It
>>>>>>>>> is probably best to rename it to acpi_arm_defs.h.
>>>>>>>
>>>>>>> Should not just we re-use the ACPI headers from xen/include/acpi/ ?
>>>>> So how to include those headers in tools/libxl/libxl_arm.c ?
>>>>>
>>> Is it public headers? If so, it might already be available in
>>> tools/include. If not, is it feasible to be made public?
>>>
>>> If in the end the file you need can't end up as a public header, you
>>> need to manipulate CFLAGS. There is one example in libxc's Makefile.
>>> Search for libelf.
>>>
>>> But please make sure the CFLAGS doesn't get modified when it is not
>>> necessary.  I would expect the CFLAGS is explicitly altered for a list
>>> of files.
>> I'm trying to do this. Make the libxl acpi codes compile like below in
>> Makefile:
>>
>> +libxl_arm_acpi.o: libxl_arm_acpi.c
>> +       $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
>>
>> Add #include <acpi/actbl.h> which includes the tables definitions in
>> libxl_arm_acpi.c. But there are a lot of compiling errors like below:
>> error: unknown type name 'u8'
>> error: unknown type name 'u32'
>> Looks like these types are defined in xen/include/asm-arm/types.h. I add
>> #include <asm-arm/types.h> in libxl_arm_acpi.c but it still compiles
>> failed.
>> In file included from ../../xen/include/asm-arm/types.h:6:0,
>>                  from libxl_arm_acpi.c:30:
>> ../../xen/include/xen/config.h:10:32: fatal error: generated/autoconf.h:
>> No such file or directory
>>  #include <generated/autoconf.h>
>>
>> Looks like if we try to use the acpi headers under xen/include/acpi like
>> this way, tools compilation will depends on hypervisor compilation. I
>> think this is not what we want, right?
> 
> You could define our own u8, u32 types in libxc. They are just aliased
> to uint8_t, uint32_t.
Ah, right. But looking at the types.h it defines u64 differently for
ARM_32 and ARM_64. Do we need to do that? If so, how could we get the
CONFIG_ARM_32 and CONFIG_ARM_64 since they are dynamically generated?

Or since we only generate ACPI tables for 64bit domain, could we just
assume it's ARM64 for ACPI?

Thanks?
-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions
  2016-06-22  8:50               ` Shannon Zhao
@ 2016-06-22  8:55                 ` Julien Grall
  0 siblings, 0 replies; 104+ messages in thread
From: Julien Grall @ 2016-06-22  8:55 UTC (permalink / raw)
  To: Shannon Zhao, Wei Liu
  Cc: peter.huangpeng, Stefano Stabellini, ian.jackson, shannon.zhao,
	xen-devel

Hi Shannon,

On 22/06/2016 09:50, Shannon Zhao wrote:
>> You could define our own u8, u32 types in libxc. They are just aliased
>> to uint8_t, uint32_t.
> Ah, right. But looking at the types.h it defines u64 differently for
> ARM_32 and ARM_64. Do we need to do that? If so, how could we get the
> CONFIG_ARM_32 and CONFIG_ARM_64 since they are dynamically generated?

You can use the type uint64_t which is defined by stdint.h.

> Or since we only generate ACPI tables for 64bit domain, could we just
> assume it's ARM64 for ACPI?

The toolstack may run in a 32-bit domain even on top of a 64-bit Xen ARM.

Cheers,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions (and more)
  2016-06-22  3:24           ` Shannon Zhao
  2016-06-22  8:35             ` Julien Grall
@ 2016-06-22  9:38             ` Wei Liu
  2016-06-22 10:06               ` Shannon Zhao
  1 sibling, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-06-22  9:38 UTC (permalink / raw)
  To: Shannon Zhao
  Cc: Stefano Stabellini, Wei Liu, ian.jackson, peter.huangpeng,
	xen-devel, Julien Grall, shannon.zhao

On Wed, Jun 22, 2016 at 11:24:07AM +0800, Shannon Zhao wrote:
[...]
> > But please make sure the CFLAGS doesn't get modified when it is not
> > necessary.  I would expect the CFLAGS is explicitly altered for a list
> > of files.
> I'm trying to do this. Make the libxl acpi codes compile like below in
> Makefile:
> 
> +libxl_arm_acpi.o: libxl_arm_acpi.c
> +       $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> 
> Add #include <acpi/actbl.h> which includes the tables definitions in
> libxl_arm_acpi.c. But there are a lot of compiling errors like below:
> error: unknown type name 'u8'
> error: unknown type name 'u32'
> Looks like these types are defined in xen/include/asm-arm/types.h. I add
> #include <asm-arm/types.h> in libxl_arm_acpi.c but it still compiles failed.
> In file included from ../../xen/include/asm-arm/types.h:6:0,
>                  from libxl_arm_acpi.c:30:
> ../../xen/include/xen/config.h:10:32: fatal error: generated/autoconf.h:
> No such file or directory
>  #include <generated/autoconf.h>
> 
> Looks like if we try to use the acpi headers under xen/include/acpi like
> this way, tools compilation will depends on hypervisor compilation. I
> think this is not what we want, right?
> 

Hmm... I thought all the ACPI headers are self-contained, but they are
actually not from your description.

But, we do have one precedent -- the libelf header. If you look at
xen/include/xen/libelf.h, the header itself contains define guards to
include the right header. Can you do the same for ACPI header?

Julien wrote:
> You could define our own u8, u32 types in libxc. They are just aliased
> to uint8_t, uint32_t.

I would avoid doing that. I would rather you confine what is necessary
in acpi headers.

Feel free to ask more questions if you're in doubt.

Wei.

> Any suggestion?
> 
> Thanks,
> -- 
> Shannon
> 

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

^ permalink raw reply	[flat|nested] 104+ messages in thread

* Re: [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions (and more)
  2016-06-22  9:38             ` [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions (and more) Wei Liu
@ 2016-06-22 10:06               ` Shannon Zhao
  0 siblings, 0 replies; 104+ messages in thread
From: Shannon Zhao @ 2016-06-22 10:06 UTC (permalink / raw)
  To: Wei Liu
  Cc: Stefano Stabellini, ian.jackson, peter.huangpeng, xen-devel,
	Julien Grall, shannon.zhao



On 2016/6/22 17:38, Wei Liu wrote:
> On Wed, Jun 22, 2016 at 11:24:07AM +0800, Shannon Zhao wrote:
> [...]
>>> > > But please make sure the CFLAGS doesn't get modified when it is not
>>> > > necessary.  I would expect the CFLAGS is explicitly altered for a list
>>> > > of files.
>> > I'm trying to do this. Make the libxl acpi codes compile like below in
>> > Makefile:
>> > 
>> > +libxl_arm_acpi.o: libxl_arm_acpi.c
>> > +       $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
>> > 
>> > Add #include <acpi/actbl.h> which includes the tables definitions in
>> > libxl_arm_acpi.c. But there are a lot of compiling errors like below:
>> > error: unknown type name 'u8'
>> > error: unknown type name 'u32'
>> > Looks like these types are defined in xen/include/asm-arm/types.h. I add
>> > #include <asm-arm/types.h> in libxl_arm_acpi.c but it still compiles failed.
>> > In file included from ../../xen/include/asm-arm/types.h:6:0,
>> >                  from libxl_arm_acpi.c:30:
>> > ../../xen/include/xen/config.h:10:32: fatal error: generated/autoconf.h:
>> > No such file or directory
>> >  #include <generated/autoconf.h>
>> > 
>> > Looks like if we try to use the acpi headers under xen/include/acpi like
>> > this way, tools compilation will depends on hypervisor compilation. I
>> > think this is not what we want, right?
>> > 
> Hmm... I thought all the ACPI headers are self-contained, but they are
> actually not from your description.
> 
> But, we do have one precedent -- the libelf header. If you look at
> xen/include/xen/libelf.h, the header itself contains define guards to
> include the right header. Can you do the same for ACPI header?
> 
> Julien wrote:
>> > You could define our own u8, u32 types in libxc. They are just aliased
>> > to uint8_t, uint32_t.
> I would avoid doing that. I would rather you confine what is necessary
> in acpi headers.

Yeah, we needs the contents of the actbl.h but it relies on the
definition of u8, u32, etc.

Thanks,
-- 
Shannon


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

^ permalink raw reply	[flat|nested] 104+ messages in thread

end of thread, other threads:[~2016-06-22 10:06 UTC | newest]

Thread overview: 104+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-31  5:02 [PATCH RESEND 00/14] Xen ARM DomU ACPI support Shannon Zhao
2016-05-31  5:02 ` [PATCH RESEND 01/14] libxl/arm: Fix the function name in error log Shannon Zhao
2016-06-03 19:25   ` Wei Liu
2016-06-17 10:46     ` Wei Liu
2016-06-20  1:12       ` Shannon Zhao
2016-05-31  5:02 ` [PATCH RESEND 02/14] libxl/arm: Factor out codes for generating DTB Shannon Zhao
2016-06-03 19:25   ` Wei Liu
2016-05-31  5:02 ` [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size Shannon Zhao
2016-06-06 10:00   ` Stefano Stabellini
2016-06-06 12:16     ` Wei Liu
2016-06-06 14:20       ` Shannon Zhao
2016-06-07 11:05   ` Julien Grall
2016-06-07 11:13     ` Shannon Zhao
2016-06-07 11:27       ` Julien Grall
2016-06-07 11:35         ` Shannon Zhao
2016-06-07 11:42           ` Julien Grall
2016-06-07 11:59             ` Shannon Zhao
2016-06-07 12:06               ` Julien Grall
2016-06-07 12:32                 ` Shannon Zhao
2016-06-07 13:06                   ` Julien Grall
2016-06-16  6:53                     ` Shannon Zhao
2016-06-16 10:21                       ` Julien Grall
2016-06-16 10:45                         ` Shannon Zhao
2016-06-16 11:04                           ` Julien Grall
2016-06-16 10:49                   ` Wei Liu
2016-06-16 10:53                     ` Shannon Zhao
2016-06-16 11:04                       ` Wei Liu
2016-06-07 12:02             ` Julien Grall
2016-06-07 12:27               ` Shannon Zhao
2016-05-31  5:02 ` [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions Shannon Zhao
2016-06-06 10:04   ` Stefano Stabellini
2016-06-06 10:11     ` Julien Grall
2016-06-06 10:27       ` Shannon Zhao
2016-06-06 12:16         ` Wei Liu
2016-06-06 14:19           ` Shannon Zhao
2016-06-22  3:24           ` Shannon Zhao
2016-06-22  8:35             ` Julien Grall
2016-06-22  8:50               ` Shannon Zhao
2016-06-22  8:55                 ` Julien Grall
2016-06-22  9:38             ` [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions (and more) Wei Liu
2016-06-22 10:06               ` Shannon Zhao
2016-05-31  5:02 ` [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table Shannon Zhao
2016-06-06 11:40   ` Stefano Stabellini
2016-06-06 11:52     ` Julien Grall
2016-06-06 12:04       ` Stefano Stabellini
2016-06-06 14:31         ` Shannon Zhao
2016-06-06 14:50           ` Stefano Stabellini
2016-06-06 15:42             ` Julien Grall
2016-06-07  9:41               ` Stefano Stabellini
2016-06-06 15:35         ` Julien Grall
2016-06-07  9:48           ` Stefano Stabellini
2016-06-07 11:55             ` Wei Liu
2016-06-17  3:29     ` Shannon Zhao
2016-06-17  8:17       ` Julien Grall
2016-06-17  9:15         ` Stefano Stabellini
2016-06-17 13:27           ` Julien Grall
2016-06-06 12:18   ` Wei Liu
2016-06-07 11:02     ` Julien Grall
2016-06-07 11:19   ` Julien Grall
2016-06-07 11:30     ` Shannon Zhao
2016-06-07 11:36       ` Julien Grall
2016-06-07 11:39         ` Shannon Zhao
2016-06-07 11:43           ` Julien Grall
2016-05-31  5:02 ` [PATCH RESEND 06/14] libxl/arm: Construct ACPI FADT table Shannon Zhao
2016-06-07 13:17   ` Julien Grall
2016-06-07 14:13     ` Shannon Zhao
2016-06-07 14:14       ` Julien Grall
2016-05-31  5:02 ` [PATCH RESEND 07/14] libxl/arm: Construct ACPI DSDT table Shannon Zhao
2016-06-07 13:42   ` Julien Grall
2016-06-16  6:25     ` Shannon Zhao
2016-06-16  9:44       ` Julien Grall
2016-06-16 10:01         ` Stefano Stabellini
2016-05-31  5:03 ` [PATCH RESEND 08/14] libxl/arm: Construct ACPI MADT table Shannon Zhao
2016-06-07 13:40   ` Julien Grall
2016-05-31  5:03 ` [PATCH RESEND 09/14] libxl/arm: Construct ACPI XSDT table Shannon Zhao
2016-05-31  5:03 ` [PATCH RESEND 10/14] libxl/arm: Construct ACPI RSDP table Shannon Zhao
2016-05-31  5:03 ` [PATCH RESEND 11/14] libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ Shannon Zhao
2016-05-31  5:03 ` [PATCH RESEND 12/14] libxl/arm: Add ACPI module Shannon Zhao
2016-06-07 13:47   ` Julien Grall
2016-05-31  5:03 ` [PATCH RESEND 13/14] libxl/arm: initialize memory information of ACPI blob Shannon Zhao
2016-06-06 11:40   ` Stefano Stabellini
2016-06-06 14:35     ` Shannon Zhao
2016-05-31  5:03 ` [PATCH RESEND 14/14] libxc/xc_dom_core: Copy ACPI tables to guest memory space Shannon Zhao
2016-05-31 10:47 ` [PATCH RESEND 00/14] Xen ARM DomU ACPI support Julien Grall
2016-05-31 14:19   ` Shannon Zhao
2016-06-03 19:24 ` Wei Liu
2016-06-03 20:02   ` Konrad Rzeszutek Wilk
2016-06-03 20:20     ` Boris Ostrovsky
2016-06-03 20:27       ` Wei Liu
2016-06-03 20:36         ` Boris Ostrovsky
2016-06-06 11:41 ` Stefano Stabellini
2016-06-06 12:26 ` Wei Liu
2016-06-06 15:37   ` Boris Ostrovsky
2016-06-06 16:50     ` Boris Ostrovsky
2016-06-07 10:54       ` Julien Grall
2016-06-07 14:24         ` Boris Ostrovsky
2016-06-06 15:48   ` Julien Grall
2016-06-07  1:07     ` Shannon Zhao
2016-06-07 11:00       ` Julien Grall
2016-06-16 11:20         ` Wei Liu
2016-06-16 13:25           ` Boris Ostrovsky
2016-06-17 10:14             ` Wei Liu
2016-06-17  2:03           ` Shannon Zhao
2016-06-17  8:18           ` Julien Grall

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).