[PATCH v2 00/17] Xen ARM DomU ACPI support

[PATCH v2 00/17] Xen ARM DomU ACPI support

[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 non-RAM memory map 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

The UEFI binary could be fetched from:
http://people.linaro.org/~shannon.zhao/DomU_ACPI/XEN_EFI.fd

This series can be fetched from:
https://git.linaro.org/people/shannon.zhao/xen.git  domu_acpi_v2

Changes since v1:
* move ACPI tables generation codes to a new file
* use static asl file to generate DSDT table and include processor
  device objects
* assign a non-RAM map for ACPI blob
* use existing ACPI table definitions under xen/include/acpi/
* add a configuration for user to enable/disable ACPI generation
* calculate the ACPI table checksum

Shannon Zhao (17):
  libxl/arm: Factor out codes for generating DTB
  libxc: Add placeholders for ACPI tables blob and size
  libxl/arm: Add a configuration option for ARM DomU ACPI
  libxl/arm: prepare for constructing ACPI tables
  libxl/arm: Construct ACPI RSDP table
  libxl/arm: Construct ACPI XSDT table
  libxl/arm: Construct ACPI GTDT table
  libxl/arm: Factor MPIDR computing codes out as a helper
  libxl/arm: Construct ACPI MADT table
  libxl/arm: Construct ACPI FADT table
  libxl/arm: Construct ACPI DSDT table
  libxl/arm: Add a helper to calculate the ACPI table checksum
  libxl/arm: Link all ACPI tables into one buffer
  libxl/arm: Factor finalise_one_memory_node as a gerneric function
  libxl/arm: Add ACPI module
  libxc/xc_dom_arm: Copy ACPI tables to guest space
  libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ

 docs/misc/arm/device-tree/acpi.txt   |  23 +++
 tools/libxc/include/xc_dom.h         |   2 +
 tools/libxc/xc_dom_arm.c             |  51 +++++
 tools/libxl/Makefile                 |  26 +++
 tools/libxl/libxl_arm.c              |  78 +++++--
 tools/libxl/libxl_arm_acpi.c         | 391 +++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_arm_acpi.h         |  46 +++++
 tools/libxl/libxl_empty_dsdt_arm.asl |  22 ++
 tools/libxl/libxl_mk_dsdt_arm.c      |  94 +++++++++
 tools/libxl/libxl_types.idl          |   1 +
 tools/libxl/xl_cmdimpl.c             |   4 +
 xen/include/public/arch-arm.h        |   5 +
 12 files changed, 726 insertions(+), 17 deletions(-)
 create mode 100644 docs/misc/arm/device-tree/acpi.txt
 create mode 100644 tools/libxl/libxl_arm_acpi.c
 create mode 100644 tools/libxl/libxl_arm_acpi.h
 create mode 100644 tools/libxl/libxl_empty_dsdt_arm.asl
 create mode 100644 tools/libxl/libxl_mk_dsdt_arm.c

-- 
2.0.4



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

[PATCH v2 01/17] libxl/arm: Factor out codes for generating DTB

[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>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
 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..8f15d9b 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 libxl__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 libxl__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

[PATCH v2 02/17] libxc: Add placeholders for ACPI tables blob and size

[Shannon Zhao]

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

Add placeholders for ACPI tables blob and size here so that ACPI blob
can be accessed from libxl and libxc.

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

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6cb10c4..cbeb4fb 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -64,6 +64,8 @@ struct xc_dom_image {
     size_t ramdisk_size;
     void *devicetree_blob;
     size_t devicetree_size;
+    void *acpitable_blob;
+    size_t acpitable_size;
 
     size_t max_kernel_size;
     size_t max_ramdisk_size;
-- 
2.0.4



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

[PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Shannon Zhao]

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

Add a configuration option for ARM DomU so that user can deicde to use
ACPI or not. This option is defaultly false.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/libxl_arm.c       | 3 +++
 tools/libxl/libxl_types.idl   | 1 +
 tools/libxl/xl_cmdimpl.c      | 4 ++++
 xen/include/public/arch-arm.h | 1 +
 4 files changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 8f15d9b..cc5a717 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -77,6 +77,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         return ERROR_FAIL;
     }
 
+    xc_config->acpi = libxl_defbool_val(d_config->b_info.arch_arm.acpi)
+                      ? true : false;
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ef614be..426b868 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -560,6 +560,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 
 
     ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
+                               ("acpi", libxl_defbool),
                               ])),
 
     ], dir=DIR_IN
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 6459eec..0634ffa 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2506,6 +2506,10 @@ skip_usbdev:
         }
      }
 
+    if (xlu_cfg_get_defbool(config, "acpi", &b_info->arch_arm.acpi, 0)) {
+        libxl_defbool_set(&b_info->arch_arm.acpi, 0);
+    }
+
     xlu_cfg_destroy(config);
 }
 
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 870bc3b..05e4a58 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -306,6 +306,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 struct xen_arch_domainconfig {
     /* IN/OUT */
     uint8_t gic_version;
+    uint8_t acpi;
     /* IN */
     uint32_t nr_spis;
     /*
-- 
2.0.4



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

[PATCH v2 04/17] libxl/arm: prepare for constructing ACPI tables

[Shannon Zhao]

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

It only constructs the ACPI tables for 64-bit ARM DomU when user enables
acpi because 32-bit DomU doesn't support ACPI.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/Makefile         |  4 +++
 tools/libxl/libxl_arm.c      | 19 +++++++++-
 tools/libxl/libxl_arm_acpi.c | 85 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_arm_acpi.h | 32 +++++++++++++++++
 4 files changed, 139 insertions(+), 1 deletion(-)
 create mode 100644 tools/libxl/libxl_arm_acpi.c
 create mode 100644 tools/libxl/libxl_arm_acpi.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 9fee752..264b6ef 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -77,6 +77,10 @@ endif
 
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
+
+libxl_arm_acpi.o: libxl_arm_acpi.c
+	$(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index cc5a717..f5db74b 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1,6 +1,7 @@
 #include "libxl_internal.h"
 #include "libxl_arch.h"
 #include "libxl_libfdt_compat.h"
+#include "libxl_arm_acpi.h"
 
 #include <xc_dom.h>
 #include <stdbool.h>
@@ -888,8 +889,24 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
                                            libxl__domain_build_state *state,
                                            struct xc_dom_image *dom)
 {
+    int rc;
+
     assert(info->type == LIBXL_DOMAIN_TYPE_PV);
-    return libxl__prepare_dtb(gc, info, state, dom);
+    rc = libxl__prepare_dtb(gc, info, state, dom);
+    if (rc)
+        return rc;
+
+    if (!state->config.acpi) {
+        LOG(DEBUG, "Generating ACPI tables is disabled by user.");
+        return 0;
+    }
+
+    if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
+        LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
+        state->config.acpi = false;
+    }
+
+    return libxl__prepare_acpi(gc, info, state, dom);
 }
 
 static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
new file mode 100644
index 0000000..60c31f9
--- /dev/null
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -0,0 +1,85 @@
+/*
+ * ARM DmoU ACPI generation
+ *
+ * Copyright (C) 2008-2010  Kevin O'Connor <kevin@koconnor.net>
+ * Copyright (C) 2006 Fabrice Bellard
+ * Copyright (C) 2013 Red Hat Inc
+ *
+ * Author: Michael S. Tsirkin <mst@redhat.com>
+ *
+ * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO.,LTD.
+ *
+ * Author: Shannon Zhao <zhaoshenglong@huawei.com>
+ *
+ * Copyright (C) 2016      Linaro Ltd.
+ *
+ * Author: Shannon Zhao <shannon.zhao@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_arm_acpi.h"
+
+#include <stdint.h>
+typedef uint8_t u8;
+typedef uint16_t u16;
+typedef uint32_t u32;
+typedef uint64_t u64;
+#include <acpi/acconfig.h>
+#include <acpi/actbl.h>
+
+enum {
+    RSDP,
+    XSDT,
+    GTDT,
+    MADT,
+    FADT,
+    DSDT,
+    NUMS,
+};
+
+struct acpitable {
+    void *table;
+    size_t size;
+};
+
+static struct acpitable acpitables[NUMS];
+
+int libxl__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;
+
+    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);
+
+    dom->acpitable_blob = NULL;
+    dom->acpitable_size = 0;
+
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
new file mode 100644
index 0000000..5899210
--- /dev/null
+++ b/tools/libxl/libxl_arm_acpi.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2016      Linaro Ltd.
+ *
+ * Author: Shannon Zhao <shannon.zhao@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+#include <xc_dom.h>
+
+int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
+                        libxl__domain_build_state *state,
+                        struct xc_dom_image *dom);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.0.4



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

[PATCH v2 05/17] libxl/arm: Construct ACPI RSDP table

[Shannon Zhao]

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

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

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 60c31f9..5f332fa 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -53,6 +53,24 @@ struct acpitable {
 
 static struct acpitable acpitables[NUMS];
 
+static void make_acpi_rsdp(libxl__gc *gc, struct xc_dom_image *dom)
+{
+    struct acpi_table_rsdp *rsdp;
+    size_t size = sizeof(*rsdp);
+
+    rsdp = libxl__zalloc(gc, size);
+    memcpy(rsdp->signature, "RSD PTR ", sizeof(rsdp->signature));
+    memcpy(rsdp->oem_id, ACPI_BUILD_APPNAME6, sizeof(rsdp->oem_id));
+    rsdp->length = size;
+    rsdp->revision = 0x02;
+    rsdp->checksum = 0;
+
+    acpitables[RSDP].table = rsdp;
+    acpitables[RSDP].size = size;
+    /* Align to 64 bit. */
+    dom->acpitable_size += ROUNDUP(acpitables[RSDP].size, 3);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
@@ -73,6 +91,8 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
     dom->acpitable_blob = NULL;
     dom->acpitable_size = 0;
 
+    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

[PATCH v2 06/17] libxl/arm: Construct ACPI XSDT table

[Shannon Zhao]

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

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

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 5f332fa..d5ffedf 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -36,6 +36,9 @@ typedef uint64_t u64;
 #include <acpi/acconfig.h>
 #include <acpi/actbl.h>
 
+#define ACPI_BUILD_APPNAME6 "XenARM"
+#define ACPI_BUILD_APPNAME4 "Xen "
+
 enum {
     RSDP,
     XSDT,
@@ -71,6 +74,42 @@ static void make_acpi_rsdp(libxl__gc *gc, struct xc_dom_image *dom)
     dom->acpitable_size += ROUNDUP(acpitables[RSDP].size, 3);
 }
 
+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_xsdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+    uint32_t size;
+    struct acpi_table_xsdt *xsdt;
+
+    /*
+     * Currently only 3 tables(GTDT, FADT, MADT) are pointed by XSDT. Alloc
+     * entries for them but the entry values will be specified when the tables
+     * are linked together later.
+     */
+    size = sizeof(*xsdt) + sizeof(uint64_t) * 2;
+    xsdt = libxl__zalloc(gc, size);
+
+    make_acpi_header(&xsdt->header, "XSDT", size, 1);
+
+    acpitables[XSDT].table = xsdt;
+    acpitables[XSDT].size = size;
+    /* Align to 64bit. */
+    dom->acpitable_size += ROUNDUP(acpitables[XSDT].size, 3);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
@@ -92,6 +131,7 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
     dom->acpitable_size = 0;
 
     make_acpi_rsdp(gc, dom);
+    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

[PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[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_acpi.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index d5ffedf..de863f4 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -39,6 +39,9 @@ typedef uint64_t u64;
 #define ACPI_BUILD_APPNAME6 "XenARM"
 #define ACPI_BUILD_APPNAME4 "Xen "
 
+#define ACPI_LEVEL_SENSITIVE            (u8) 0x00
+#define ACPI_ACTIVE_LOW                 (u8) 0x01
+
 enum {
     RSDP,
     XSDT,
@@ -110,6 +113,30 @@ static void make_acpi_xsdt(libxl__gc *gc, struct xc_dom_image *dom)
     dom->acpitable_size += ROUNDUP(acpitables[XSDT].size, 3);
 }
 
+static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+    struct acpi_table_gtdt *gtdt;
+    size_t size = sizeof(*gtdt);
+
+    gtdt = libxl__zalloc(gc, size);
+
+    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", size, 2);
+
+    acpitables[GTDT].table = gtdt;
+    acpitables[GTDT].size = size;
+    /* Align to 64bit. */
+    dom->acpitable_size += ROUNDUP(acpitables[GTDT].size, 3);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
@@ -132,6 +159,7 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 
     make_acpi_rsdp(gc, dom);
     make_acpi_xsdt(gc, dom);
+    make_acpi_gtdt(gc, dom);
 
     return 0;
 }
-- 
2.0.4



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

[PATCH v2 08/17] libxl/arm: Factor MPIDR computing codes out as a helper

[Shannon Zhao]

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

Factor MPIDR computing codes out as a helper, so it could be shared
between DT and ACPI.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/libxl_arm.c      |  8 +-------
 tools/libxl/libxl_arm_acpi.h | 12 ++++++++++++
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index f5db74b..a766732 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -312,13 +312,7 @@ static int make_cpus_node(libxl__gc *gc, void *fdt, int nr_cpus,
     for (i = 0; i < nr_cpus; i++) {
         const char *name;
 
-        /*
-         * According to ARM CPUs bindings, the reg field should match
-         * the MPIDR's affinity bits. We will use AFF0 and AFF1 when
-         * constructing the reg 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);
+        mpidr_aff = libxl__compute_mpdir(i);
         name = GCSPRINTF("cpu@%"PRIx64, mpidr_aff);
 
         res = fdt_begin_node(fdt, name);
diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
index 5899210..9b58de6 100644
--- a/tools/libxl/libxl_arm_acpi.h
+++ b/tools/libxl/libxl_arm_acpi.h
@@ -23,6 +23,18 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom);
 
+static inline uint64_t libxl__compute_mpdir(int index)
+{
+    /*
+     * According to ARM CPUs bindings, the reg field should match
+     * the MPIDR's affinity bits. We will use AFF0 and AFF1 when
+     * constructing the reg value of the guest at the moment, for it
+     * is enough for the current max vcpu number.
+     */
+    assert(index >= 0);
+    return (index & 0x0f) | (((index >> 4) & 0xff) << 8);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.0.4



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

[PATCH v2 09/17] libxl/arm: Construct ACPI MADT table

[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_acpi.c | 100 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 100 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index de863f4..659dbfa 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -42,6 +42,8 @@ typedef uint64_t u64;
 #define ACPI_LEVEL_SENSITIVE            (u8) 0x00
 #define ACPI_ACTIVE_LOW                 (u8) 0x01
 
+#define ACPI_GICC_ENABLED 1
+
 enum {
     RSDP,
     XSDT,
@@ -137,6 +139,101 @@ static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
     dom->acpitable_size += ROUNDUP(acpitables[GTDT].size, 3);
 }
 
+static void make_acpi_madt_gicc(void *table, int nr_cpus, uint64_t gicc_base)
+{
+    uint32_t i;
+    struct acpi_madt_generic_interrupt *gicc = table;
+
+    for (i = 0; i < nr_cpus; i++) {
+        gicc->header.type = ACPI_MADT_TYPE_GENERIC_INTERRUPT;
+        gicc->header.length = sizeof(*gicc);
+        gicc->base_address = gicc_base;
+        gicc->cpu_interface_number = i;
+        gicc->arm_mpidr = libxl__compute_mpdir(i);
+        gicc->uid = i;
+        gicc->flags = ACPI_GICC_ENABLED;
+        gicc++;
+    }
+}
+
+static void make_acpi_madt_gicd(void *table, uint64_t gicd_base,
+                                uint8_t gic_version)
+{
+    struct acpi_madt_generic_distributor *gicd = table;
+
+    gicd->header.type = ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR;
+    gicd->header.length = sizeof(*gicd);
+    gicd->base_address = gicd_base;
+    /* This version filed has no meaning before ACPI 5.1 errata. */
+    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->header.type = ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR;
+    gicr->header.length = sizeof(*gicr);
+    gicr->base_address = gicr_base;
+    gicr->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)
+{
+    size_t size;
+    void *table;
+    struct acpi_table_madt *madt;
+
+    switch (xc_config->gic_version) {
+    case XEN_DOMCTL_CONFIG_GIC_V2:
+        size = sizeof(struct acpi_table_madt) +
+               sizeof(struct acpi_madt_generic_interrupt) * nr_cpus +
+               sizeof(struct acpi_madt_generic_distributor);
+        table = libxl__zalloc(gc, size);
+        madt = (struct acpi_table_madt *)table;
+
+        table += sizeof(struct acpi_table_madt);
+        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, ACPI_MADT_GIC_VERSION_V2);
+        break;
+    case XEN_DOMCTL_CONFIG_GIC_V3:
+        size = sizeof(struct acpi_table_madt) +
+               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_table_madt *)table;
+
+        table += sizeof(struct acpi_table_madt);
+        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,
+                            ACPI_MADT_GIC_VERSION_V3);
+
+        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");
+        return ERROR_FAIL;
+    }
+
+    make_acpi_header(&madt->header, "APIC", size, 3);
+
+    acpitables[MADT].table = madt;
+    acpitables[MADT].size = size;
+    /* Align to 64bit. */
+    dom->acpitable_size += ROUNDUP(acpitables[MADT].size, 3);
+
+    return 0;
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
@@ -160,6 +257,9 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
     make_acpi_rsdp(gc, dom);
     make_acpi_xsdt(gc, dom);
     make_acpi_gtdt(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

[PATCH v2 10/17] libxl/arm: Construct ACPI FADT table

[Shannon Zhao]

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

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

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 659dbfa..353d774 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -234,6 +234,28 @@ static int make_acpi_madt(libxl__gc *gc, struct xc_dom_image *dom, int nr_cpus,
     return 0;
 }
 
+static void make_acpi_fadt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+    struct acpi_table_fadt *fadt;
+    size_t size = sizeof(*fadt);
+
+    fadt = libxl__zalloc(gc, size);
+
+    /* Hardware Reduced = 1 and use PSCI 0.2+ and with HVC */
+    fadt->flags = ACPI_FADT_HW_REDUCED;
+    fadt->arm_boot_flags = (ACPI_FADT_PSCI_COMPLIANT) | ACPI_FADT_PSCI_USE_HVC;
+
+    /* ACPI v5.1 (fadt->revision.fadt->minor_revision) */
+    fadt->minor_revision = 0x1;
+
+    make_acpi_header(&fadt->header, "FACP", size, 5);
+
+    acpitables[FADT].table = fadt;
+    acpitables[FADT].size = size;
+    /* Align to 64bit. */
+    dom->acpitable_size += ROUNDUP(acpitables[FADT].size, 3);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
@@ -261,6 +283,8 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
     if (rc)
 	return rc;
 
+    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

[PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Shannon Zhao]

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

It uses static DSDT table like the way x86 uses. Currently the DSDT
table only contains processor device objects and it generates the
maximal objects which so far is 128.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/Makefile                 | 24 ++++++++-
 tools/libxl/libxl_arm_acpi.c         | 15 ++++++
 tools/libxl/libxl_arm_acpi.h         |  2 +
 tools/libxl/libxl_empty_dsdt_arm.asl | 22 +++++++++
 tools/libxl/libxl_mk_dsdt_arm.c      | 94 ++++++++++++++++++++++++++++++++++++
 5 files changed, 156 insertions(+), 1 deletion(-)
 create mode 100644 tools/libxl/libxl_empty_dsdt_arm.asl
 create mode 100644 tools/libxl/libxl_mk_dsdt_arm.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 264b6ef..5347480 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -77,7 +77,29 @@ endif
 
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
-LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
+
+vpath iasl $(PATH)
+libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
+	$(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
+
+libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
+	awk 'NR > 1 {print s} {s=$$0}' $< > $@
+	./libxl_mk_dsdt_arm >> $@
+
+libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
+	iasl -vs -p $* -tc $*.asl
+	sed -e 's/AmlCode/$*/g' $*.hex >$@
+	echo "int $*_len=sizeof($*);" >>$@
+	rm -f $*.aml $*.hex
+
+iasl:
+	@echo
+	@echo "ACPI ASL compiler (iasl) is needed"
+	@echo "Download and install Intel ACPI CA from"
+	@echo "http://acpica.org/downloads/"
+	@echo
+	@exit 1
 
 libxl_arm_acpi.o: libxl_arm_acpi.c
 	$(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 353d774..45fc354 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -54,6 +54,9 @@ enum {
     NUMS,
 };
 
+extern unsigned char libxl_dsdt_anycpu_arm[];
+extern int libxl_dsdt_anycpu_arm_len;
+
 struct acpitable {
     void *table;
     size_t size;
@@ -256,6 +259,17 @@ static void make_acpi_fadt(libxl__gc *gc, struct xc_dom_image *dom)
     dom->acpitable_size += ROUNDUP(acpitables[FADT].size, 3);
 }
 
+static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+    acpitables[DSDT].table = libxl__zalloc(gc, libxl_dsdt_anycpu_arm_len);
+    memcpy(acpitables[DSDT].table, libxl_dsdt_anycpu_arm,
+           libxl_dsdt_anycpu_arm_len);
+
+    acpitables[DSDT].size = libxl_dsdt_anycpu_arm_len;
+    /* Align to 64bit. */
+    dom->acpitable_size += ROUNDUP(acpitables[DSDT].size, 3);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
@@ -284,6 +298,7 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 	return rc;
 
     make_acpi_fadt(gc, dom);
+    make_acpi_dsdt(gc, dom);
 
     return 0;
 }
diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
index 9b58de6..b0fd9ce 100644
--- a/tools/libxl/libxl_arm_acpi.h
+++ b/tools/libxl/libxl_arm_acpi.h
@@ -19,6 +19,8 @@
 
 #include <xc_dom.h>
 
+#define DOMU_MAX_VCPUS 128
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom);
diff --git a/tools/libxl/libxl_empty_dsdt_arm.asl b/tools/libxl/libxl_empty_dsdt_arm.asl
new file mode 100644
index 0000000..005fa6a
--- /dev/null
+++ b/tools/libxl/libxl_empty_dsdt_arm.asl
@@ -0,0 +1,22 @@
+/******************************************************************************
+ * DSDT for Xen ARM DomU
+ *
+ * Copyright (c) 2004, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+DefinitionBlock ("DSDT.aml", "DSDT", 3, "XenARM", "Xen DSDT", 1)
+{
+
+}
diff --git a/tools/libxl/libxl_mk_dsdt_arm.c b/tools/libxl/libxl_mk_dsdt_arm.c
new file mode 100644
index 0000000..96fadbd
--- /dev/null
+++ b/tools/libxl/libxl_mk_dsdt_arm.c
@@ -0,0 +1,94 @@
+#include <stdio.h>
+#include <stdarg.h>
+#include <stdint.h>
+#include <string.h>
+#include <stdlib.h>
+#include "libxl_arm_acpi.h"
+
+static unsigned int indent_level;
+
+static void indent(void)
+{
+    unsigned int i;
+    for ( i = 0; i < indent_level; i++ )
+        printf("    ");
+}
+
+static __attribute__((format(printf, 2, 3)))
+void _stmt(const char *name, const char *fmt, ...)
+{
+    va_list args;
+
+    indent();
+    printf("%s", name);
+
+    if ( !fmt )
+        return;
+
+    printf(" ( ");
+    va_start(args, fmt);
+    vprintf(fmt, args);
+    va_end(args);
+    printf(" )");
+}
+
+#define stmt(n, f, a...)                        \
+    do {                                        \
+        _stmt(n, f , ## a );                    \
+        printf("\n");                           \
+    } while (0)
+
+#define push_block(n, f, a...)                  \
+    do {                                        \
+        _stmt(n, f , ## a );                    \
+        printf(" {\n");                         \
+        indent_level++;                         \
+    } while (0)
+
+static void pop_block(void)
+{
+    indent_level--;
+    indent();
+    printf("}\n");
+}
+
+int main(int argc, char **argv)
+{
+    unsigned int cpu, max_cpus = DOMU_MAX_VCPUS;
+
+    /**** DSDT DefinitionBlock start ****/
+    /* (we append to existing DSDT definition block) */
+    indent_level++;
+
+    /**** Processor start ****/
+    push_block("Scope", "\\_SB");
+
+    /* Define processor objects and control methods. */
+    for ( cpu = 0; cpu < max_cpus; cpu++)
+    {
+        push_block("Processor", "PR%02X, %d, 0x0000b010, 0x06", cpu, cpu);
+
+        stmt("Name", "_HID, \"ACPI0007\"");
+        stmt("Name", "_UID, %d", cpu);
+
+        pop_block();
+    }
+
+    pop_block();
+    /**** Processor end ****/
+
+    pop_block();
+    /**** DSDT DefinitionBlock end ****/
+
+    return 0;
+}
+
+/*
+ * 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

[PATCH v2 12/17] libxl/arm: Add a helper to calculate the ACPI table checksum

[Shannon Zhao]

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

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

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 45fc354..d8779af 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -270,6 +270,21 @@ static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
     dom->acpitable_size += ROUNDUP(acpitables[DSDT].size, 3);
 }
 
+static void calculate_checksum(void *table, uint32_t checksum_offset,
+                               uint32_t length)
+{
+    uint8_t *p, sum = 0;
+
+    p = table;
+    p[checksum_offset] = 0;
+
+    while ( length-- )
+        sum = sum + *p++;
+
+    p = table;
+    p[checksum_offset] = -sum;
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
-- 
2.0.4



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

[PATCH v2 13/17] libxl/arm: Link all ACPI tables into one buffer

[Shannon Zhao]

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

Link all ACPI tables into one buffer, fill in the addresses of
tables and update checksum of each table.

Reserve a memory map space for ACPI tables.

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 tools/libxl/libxl_arm_acpi.c  | 58 +++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/arch-arm.h |  4 +++
 2 files changed, 62 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index d8779af..263b5de 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -285,6 +285,63 @@ static void calculate_checksum(void *table, uint32_t checksum_offset,
     p[checksum_offset] = -sum;
 }
 
+static void link_acpi_tables(libxl__gc *gc, struct xc_dom_image *dom)
+{
+    uint64_t offset = 0;
+    struct acpi_table_xsdt *xsdt;
+    struct acpi_table_rsdp *rsdp;
+    struct acpi_table_fadt *fadt;
+
+    assert(dom->acpitable_size <= GUEST_ACPI_SIZE);
+    dom->acpitable_blob = libxl__zalloc(gc, dom->acpitable_size);
+
+    rsdp = (struct acpi_table_rsdp *)(dom->acpitable_blob + offset);
+    memcpy(dom->acpitable_blob + offset, acpitables[RSDP].table,
+           acpitables[RSDP].size);
+    offset += ROUNDUP(acpitables[RSDP].size, 3);
+
+    xsdt = (struct acpi_table_xsdt *)(dom->acpitable_blob + offset);
+    memcpy(dom->acpitable_blob + offset, acpitables[XSDT].table,
+           acpitables[XSDT].size);
+    rsdp->xsdt_physical_address = GUEST_ACPI_BASE + offset;
+    calculate_checksum(rsdp, offsetof(struct acpi_table_header, checksum),
+                       acpitables[RSDP].size);
+    offset += ROUNDUP(acpitables[XSDT].size, 3);
+
+    memcpy(dom->acpitable_blob + offset, acpitables[MADT].table,
+           acpitables[MADT].size);
+    calculate_checksum(dom->acpitable_blob + offset,
+                       offsetof(struct acpi_table_header, checksum),
+                       acpitables[MADT].size);
+    xsdt->table_offset_entry[0] = GUEST_ACPI_BASE + offset;
+    offset += ROUNDUP(acpitables[MADT].size, 3);
+
+    memcpy(dom->acpitable_blob + offset, acpitables[GTDT].table,
+           acpitables[GTDT].size);
+    calculate_checksum(dom->acpitable_blob + offset,
+                       offsetof(struct acpi_table_header, checksum),
+                       acpitables[GTDT].size);
+    xsdt->table_offset_entry[1] = GUEST_ACPI_BASE + offset;
+    offset += ROUNDUP(acpitables[GTDT].size, 3);
+
+    fadt = (struct acpi_table_fadt *)(dom->acpitable_blob + offset);
+    memcpy(dom->acpitable_blob + offset, acpitables[FADT].table,
+           acpitables[FADT].size);
+    xsdt->table_offset_entry[2] = GUEST_ACPI_BASE + offset;
+    calculate_checksum(xsdt, offsetof(struct acpi_table_header, checksum),
+                       acpitables[XSDT].size);
+    offset += ROUNDUP(acpitables[FADT].size, 3);
+
+    memcpy(dom->acpitable_blob + offset, acpitables[DSDT].table,
+           acpitables[DSDT].size);
+    calculate_checksum(dom->acpitable_blob + offset,
+                       offsetof(struct acpi_table_header, checksum),
+                       acpitables[DSDT].size);
+    fadt->dsdt = GUEST_ACPI_BASE + offset;
+    calculate_checksum(fadt, offsetof(struct acpi_table_header, checksum),
+                       acpitables[FADT].size);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
                         libxl__domain_build_state *state,
                         struct xc_dom_image *dom)
@@ -314,6 +371,7 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 
     make_acpi_fadt(gc, dom);
     make_acpi_dsdt(gc, dom);
+    link_acpi_tables(gc, dom);
 
     return 0;
 }
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 05e4a58..0911d16 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -407,6 +407,10 @@ typedef uint64_t xen_callback_t;
 #define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU127 */
 #define GUEST_GICV3_GICR0_SIZE     0x01000000ULL
 
+/* ACPI tables physical address */
+#define GUEST_ACPI_BASE 0x20000000ULL
+#define GUEST_ACPI_SIZE 0x00200000ULL
+
 /*
  * 16MB == 4096 pages reserved for guest to use as a region to map its
  * grant table in.
-- 
2.0.4



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

[PATCH v2 14/17] libxl/arm: Factor finalise_one_memory_node as a gerneric function

[Shannon Zhao]

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

Rename finalise_one_memory_node to finalise_one_node and pass the node
name via function parameter.

This is useful for adding ACPI module which will be added by a later
patch.

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

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index a766732..97958ed 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -903,11 +903,11 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
     return libxl__prepare_acpi(gc, info, state, dom);
 }
 
-static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
-                                     uint64_t base, uint64_t size)
+static void finalise_one_node(libxl__gc *gc, void *fdt, const char *uname,
+                              uint64_t base, uint64_t size)
 {
     int node, res;
-    const char *name = GCSPRINTF("/memory@%"PRIx64, base);
+    const char *name = GCSPRINTF("%s@%"PRIx64, uname, base);
 
     node = fdt_path_offset(fdt, name);
     assert(node > 0);
@@ -970,7 +970,7 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
     for (i = 0; i < GUEST_RAM_BANKS; i++) {
         const uint64_t size = (uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT;
 
-        finalise_one_memory_node(gc, fdt, bankbase[i], size);
+        finalise_one_node(gc, fdt, "/memory", bankbase[i], size);
     }
 
     debug_dump_fdt(gc, fdt);
-- 
2.0.4



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

[PATCH v2 15/17] libxl/arm: Add ACPI module

[Shannon Zhao]

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

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

Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
---
 docs/misc/arm/device-tree/acpi.txt | 23 +++++++++++++++++++++++
 tools/libxl/libxl_arm.c            | 24 ++++++++++++++++++++++++
 2 files changed, 47 insertions(+)
 create mode 100644 docs/misc/arm/device-tree/acpi.txt

diff --git a/docs/misc/arm/device-tree/acpi.txt b/docs/misc/arm/device-tree/acpi.txt
new file mode 100644
index 0000000..c39c4d0
--- /dev/null
+++ b/docs/misc/arm/device-tree/acpi.txt
@@ -0,0 +1,23 @@
+DomU ACPI module
+================================
+
+Xen toolstack passes the domU ACPI tables via a reference in the /chosen node of
+the device tree.
+
+Each node contains the following properties:
+
+- compatible
+
+	"xen,guest-acpi", "multiboot,module"
+
+- reg
+
+	Specifies the physical address and the length of the module.
+
+Examples
+========
+
+	module@0x20000000 {
+		compatible = "xen,guest-acpi", "multiboot,module";
+		reg = <0x20000000 0x1234>;
+	};
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 97958ed..240a215 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -288,6 +288,25 @@ static int make_chosen_node(libxl__gc *gc, void *fdt, bool ramdisk,
         if (res) return res;
     }
 
+    if (state->config.acpi) {
+        const uint64_t acpi_base = GUEST_ACPI_BASE;
+        const char *name = GCSPRINTF("module@%"PRIx64, acpi_base);
+
+        res = fdt_begin_node(fdt, name);
+        if (res) return res;
+
+        res = fdt_property_compat(gc, fdt, 2, "xen,guest-acpi",
+                                  "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;
 
@@ -973,6 +992,11 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
         finalise_one_node(gc, fdt, "/memory", bankbase[i], size);
     }
 
+    if (dom->acpitable_blob) {
+        finalise_one_node(gc, fdt, "/chosen/module", GUEST_ACPI_BASE,
+                          dom->acpitable_size);
+    }
+
     debug_dump_fdt(gc, fdt);
 
     return 0;
-- 
2.0.4



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

[PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Shannon Zhao]

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

Copy all the ACPI tables to guest space so that UEFI or guest could
access them.

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

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 64a8b67..6a0a5b7 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -63,6 +63,47 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
 
 /* ------------------------------------------------------------------------ */
 
+static int xc_dom_copy_acpi(struct xc_dom_image *dom)
+{
+    int rc, i;
+    uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
+                         XC_PAGE_SHIFT;
+    const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
+    xen_pfn_t *p2m;
+    void *acpi_pages;
+
+    p2m = malloc(pages_num * sizeof(*p2m));
+    for (i = 0; i < pages_num; i++)
+        p2m[i] = base + i;
+
+    rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
+                                          pages_num, 0, 0, p2m);
+    if ( rc )
+    {
+        DOMPRINTF("%s: xc_domain_populate_physmap_exact failed with %d",
+                  __FUNCTION__, rc);
+        goto out;
+    }
+
+    acpi_pages = xc_map_foreign_range(dom->xch, dom->guest_domid,
+                                      PAGE_SIZE * pages_num,
+                                      PROT_READ | PROT_WRITE, base);
+    if ( !acpi_pages )
+    {
+        DOMPRINTF("%s Can't map acpi_pages", __FUNCTION__);
+        rc = -1;
+        goto out;
+    }
+
+    memcpy(acpi_pages, dom->acpitable_blob, dom->acpitable_size);
+
+out:
+    munmap(acpi_pages, pages_num * PAGE_SIZE);
+    free(p2m);
+
+    return rc;
+}
+
 static int alloc_magic_pages(struct xc_dom_image *dom)
 {
     int rc, i;
@@ -100,6 +141,16 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
     xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN,
             dom->xenstore_evtchn);
 
+    if ( dom->acpitable_blob && dom->acpitable_size > 0 )
+    {
+        rc = xc_dom_copy_acpi(dom);
+        if ( rc != 0 )
+        {
+            DOMPRINTF("Unable to copy ACPI tables");
+            return rc;
+        }
+    }
+
     return 0;
 }
 
-- 
2.0.4



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

[PATCH v2 17/17] libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ

[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_acpi.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 263b5de..8a42125 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -348,6 +348,7 @@ int libxl__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;
@@ -373,7 +374,12 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
     make_acpi_dsdt(gc, dom);
     link_acpi_tables(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);
 }
 
 /*
-- 
2.0.4



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

Re: [PATCH v2 04/17] libxl/arm: prepare for constructing ACPI tables

[Stefano Stabellini]

On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> It only constructs the ACPI tables for 64-bit ARM DomU when user enables
> acpi because 32-bit DomU doesn't support ACPI.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  tools/libxl/Makefile         |  4 +++
>  tools/libxl/libxl_arm.c      | 19 +++++++++-
>  tools/libxl/libxl_arm_acpi.c | 85 ++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_arm_acpi.h | 32 +++++++++++++++++
>  4 files changed, 139 insertions(+), 1 deletion(-)
>  create mode 100644 tools/libxl/libxl_arm_acpi.c
>  create mode 100644 tools/libxl/libxl_arm_acpi.h
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 9fee752..264b6ef 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -77,6 +77,10 @@ endif
>  
>  LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>  LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
> +
> +libxl_arm_acpi.o: libxl_arm_acpi.c
> +	$(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
>  
>  ifeq ($(CONFIG_NetBSD),y)
>  LIBXL_OBJS-y += libxl_netbsd.o
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index cc5a717..f5db74b 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -1,6 +1,7 @@
>  #include "libxl_internal.h"
>  #include "libxl_arch.h"
>  #include "libxl_libfdt_compat.h"
> +#include "libxl_arm_acpi.h"
>  
>  #include <xc_dom.h>
>  #include <stdbool.h>
> @@ -888,8 +889,24 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>                                             libxl__domain_build_state *state,
>                                             struct xc_dom_image *dom)
>  {
> +    int rc;
> +
>      assert(info->type == LIBXL_DOMAIN_TYPE_PV);
> -    return libxl__prepare_dtb(gc, info, state, dom);
> +    rc = libxl__prepare_dtb(gc, info, state, dom);
> +    if (rc)
> +        return rc;
> +
> +    if (!state->config.acpi) {
> +        LOG(DEBUG, "Generating ACPI tables is disabled by user.");
> +        return 0;
> +    }
> +
> +    if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
> +        LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
> +        state->config.acpi = false;

Shouldn't we return here?


> +    }
> +
> +    return libxl__prepare_acpi(gc, info, state, dom);
>  }
>  
>  static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> new file mode 100644
> index 0000000..60c31f9
> --- /dev/null
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -0,0 +1,85 @@
> +/*
> + * ARM DmoU ACPI generation
> + *
> + * Copyright (C) 2008-2010  Kevin O'Connor <kevin@koconnor.net>
> + * Copyright (C) 2006 Fabrice Bellard
> + * Copyright (C) 2013 Red Hat Inc
> + *
> + * Author: Michael S. Tsirkin <mst@redhat.com>
> + *
> + * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO.,LTD.
> + *
> + * Author: Shannon Zhao <zhaoshenglong@huawei.com>
> + *
> + * Copyright (C) 2016      Linaro Ltd.
> + *
> + * Author: Shannon Zhao <shannon.zhao@linaro.org>

Uhm... If in doubt just remove all the Author lines: git log provides
more than enough information about who wrote this code.


> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +#include "libxl_arm_acpi.h"
> +
> +#include <stdint.h>
> +typedef uint8_t u8;
> +typedef uint16_t u16;
> +typedef uint32_t u32;
> +typedef uint64_t u64;
> +#include <acpi/acconfig.h>
> +#include <acpi/actbl.h>
> +
> +enum {
> +    RSDP,
> +    XSDT,
> +    GTDT,
> +    MADT,
> +    FADT,
> +    DSDT,
> +    NUMS,
> +};
> +
> +struct acpitable {
> +    void *table;
> +    size_t size;
> +};
> +
> +static struct acpitable acpitables[NUMS];
> +
> +int libxl__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;
> +
> +    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);
> +
> +    dom->acpitable_blob = NULL;
> +    dom->acpitable_size = 0;
> +
> +    return 0;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
> new file mode 100644
> index 0000000..5899210
> --- /dev/null
> +++ b/tools/libxl/libxl_arm_acpi.h
> @@ -0,0 +1,32 @@
> +/*
> + * Copyright (C) 2016      Linaro Ltd.
> + *
> + * Author: Shannon Zhao <shannon.zhao@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +#include "libxl_internal.h"
> +#include "libxl_arch.h"
> +
> +#include <xc_dom.h>
> +
> +int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
> +                        libxl__domain_build_state *state,
> +                        struct xc_dom_image *dom);
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> -- 
> 2.0.4
> 
> 

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Stefano Stabellini]

On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> Add a configuration option for ARM DomU so that user can deicde to use
> ACPI or not. This option is defaultly false.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  tools/libxl/libxl_arm.c       | 3 +++
>  tools/libxl/libxl_types.idl   | 1 +
>  tools/libxl/xl_cmdimpl.c      | 4 ++++
>  xen/include/public/arch-arm.h | 1 +
>  4 files changed, 9 insertions(+)
> 
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 8f15d9b..cc5a717 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -77,6 +77,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>          return ERROR_FAIL;
>      }
>  
> +    xc_config->acpi = libxl_defbool_val(d_config->b_info.arch_arm.acpi)
> +                      ? true : false;
> +
>      return 0;
>  }
>  
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index ef614be..426b868 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -560,6 +560,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>  
>  
>      ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
> +                               ("acpi", libxl_defbool),
>                                ])),
>  
>      ], dir=DIR_IN
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 6459eec..0634ffa 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2506,6 +2506,10 @@ skip_usbdev:
>          }
>       }
>  
> +    if (xlu_cfg_get_defbool(config, "acpi", &b_info->arch_arm.acpi, 0)) {
> +        libxl_defbool_set(&b_info->arch_arm.acpi, 0);
> +    }

We cannot share the existing code to parse the acpi paramter because
that is saved in b_info->u.hvm.acpi, right? It's a pity. I wonder if we
could refactor the existing code so that we can actually share the acpi
parameter between x86 and arm.


>      xlu_cfg_destroy(config);
>  }
>  
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 870bc3b..05e4a58 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -306,6 +306,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
>  struct xen_arch_domainconfig {
>      /* IN/OUT */
>      uint8_t gic_version;
> +    uint8_t acpi;
>      /* IN */
>      uint32_t nr_spis;
>      /*
> -- 
> 2.0.4
> 
> 

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

Re: [PATCH v2 04/17] libxl/arm: prepare for constructing ACPI tables

[Shannon Zhao]

On 2016年06月23日 21:37, Stefano Stabellini wrote:
> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>> +
>> +    if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
>> +        LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
>> +        state->config.acpi = false;
> 
> Shouldn't we return here?
> 
Ah, right, thanks!
> 
>> +    }
>> +
>> +    return libxl__prepare_acpi(gc, info, state, dom);
>>  }
>>  
>>  static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
>> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
>> new file mode 100644
>> index 0000000..60c31f9
>> --- /dev/null
>> +++ b/tools/libxl/libxl_arm_acpi.c
>> @@ -0,0 +1,85 @@
>> +/*
>> + * ARM DmoU ACPI generation
>> + *
>> + * Copyright (C) 2008-2010  Kevin O'Connor <kevin@koconnor.net>
>> + * Copyright (C) 2006 Fabrice Bellard
>> + * Copyright (C) 2013 Red Hat Inc
>> + *
>> + * Author: Michael S. Tsirkin <mst@redhat.com>
>> + *
>> + * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO.,LTD.
>> + *
>> + * Author: Shannon Zhao <zhaoshenglong@huawei.com>
>> + *
>> + * Copyright (C) 2016      Linaro Ltd.
>> + *
>> + * Author: Shannon Zhao <shannon.zhao@linaro.org>
> 
> Uhm... If in doubt just remove all the Author lines: git log provides
> more than enough information about who wrote this code.
> 
Ahm... Julien suggested I should import the copyright from QEMU since I
refer to that. While what I didn't say before is that even if I didn't
refer to QEMU codes, the implementation will be like this because for
the tables except DSDT we just fill in the contents of the tables. But
for DSDT generation, it's totally different compared with QEMU.

I think I'll remove this. :)

Thanks,
-- 
Shannon

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

Re: [PATCH v2 04/17] libxl/arm: prepare for constructing ACPI tables

[Stefano Stabellini]

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

On Thu, 23 Jun 2016, Shannon Zhao wrote:
> On 2016年06月23日 21:37, Stefano Stabellini wrote:
> > On Thu, 23 Jun 2016, Shannon Zhao wrote:
> >> +
> >> +    if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
> >> +        LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
> >> +        state->config.acpi = false;
> > 
> > Shouldn't we return here?
> > 
> Ah, right, thanks!
> > 
> >> +    }
> >> +
> >> +    return libxl__prepare_acpi(gc, info, state, dom);
> >>  }
> >>  
> >>  static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
> >> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> >> new file mode 100644
> >> index 0000000..60c31f9
> >> --- /dev/null
> >> +++ b/tools/libxl/libxl_arm_acpi.c
> >> @@ -0,0 +1,85 @@
> >> +/*
> >> + * ARM DmoU ACPI generation
> >> + *
> >> + * Copyright (C) 2008-2010  Kevin O'Connor <kevin@koconnor.net>
> >> + * Copyright (C) 2006 Fabrice Bellard
> >> + * Copyright (C) 2013 Red Hat Inc
> >> + *
> >> + * Author: Michael S. Tsirkin <mst@redhat.com>
> >> + *
> >> + * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO.,LTD.
> >> + *
> >> + * Author: Shannon Zhao <zhaoshenglong@huawei.com>
> >> + *
> >> + * Copyright (C) 2016      Linaro Ltd.
> >> + *
> >> + * Author: Shannon Zhao <shannon.zhao@linaro.org>
> > 
> > Uhm... If in doubt just remove all the Author lines: git log provides
> > more than enough information about who wrote this code.
> > 
> Ahm... Julien suggested I should import the copyright from QEMU since I
> refer to that. While what I didn't say before is that even if I didn't
> refer to QEMU codes, the implementation will be like this because for
> the tables except DSDT we just fill in the contents of the tables. But
> for DSDT generation, it's totally different compared with QEMU.
> 
> I think I'll remove this. :)

I see. It's important to keep all the right signed-off-by, acked-by and
reviewed-by in the commit message. But the author list on source files
doesn't make much sense these days.

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

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Shannon Zhao]

On 2016年06月23日 21:39, Stefano Stabellini wrote:
> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.zhao@linaro.org>
>> > 
>> > Add a configuration option for ARM DomU so that user can deicde to use
>> > ACPI or not. This option is defaultly false.
>> > 
>> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > ---
>> >  tools/libxl/libxl_arm.c       | 3 +++
>> >  tools/libxl/libxl_types.idl   | 1 +
>> >  tools/libxl/xl_cmdimpl.c      | 4 ++++
>> >  xen/include/public/arch-arm.h | 1 +
>> >  4 files changed, 9 insertions(+)
>> > 
>> > diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> > index 8f15d9b..cc5a717 100644
>> > --- a/tools/libxl/libxl_arm.c
>> > +++ b/tools/libxl/libxl_arm.c
>> > @@ -77,6 +77,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>> >          return ERROR_FAIL;
>> >      }
>> >  
>> > +    xc_config->acpi = libxl_defbool_val(d_config->b_info.arch_arm.acpi)
>> > +                      ? true : false;
>> > +
>> >      return 0;
>> >  }
>> >  
>> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> > index ef614be..426b868 100644
>> > --- a/tools/libxl/libxl_types.idl
>> > +++ b/tools/libxl/libxl_types.idl
>> > @@ -560,6 +560,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>> >  
>> >  
>> >      ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
>> > +                               ("acpi", libxl_defbool),
>> >                                ])),
>> >  
>> >      ], dir=DIR_IN
>> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> > index 6459eec..0634ffa 100644
>> > --- a/tools/libxl/xl_cmdimpl.c
>> > +++ b/tools/libxl/xl_cmdimpl.c
>> > @@ -2506,6 +2506,10 @@ skip_usbdev:
>> >          }
>> >       }
>> >  
>> > +    if (xlu_cfg_get_defbool(config, "acpi", &b_info->arch_arm.acpi, 0)) {
>> > +        libxl_defbool_set(&b_info->arch_arm.acpi, 0);
>> > +    }
> We cannot share the existing code to parse the acpi paramter because
> that is saved in b_info->u.hvm.acpi, right? 
Yes.
> It's a pity. I wonder if we
> could refactor the existing code so that we can actually share the acpi
> parameter between x86 and arm.
> 
I have no idea about this since I'm not familiar with this. But is there
any downsides of current way? Because for x86, it will use
b_info->u.hvm.acpi and for ARM it will use b_info->arch_arm.acpi. I
think they don't conflict even though we store it at two places.

Or could we add some codes to check the arch and decide where to store it?

Thanks,
-- 
Shannon

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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Stefano Stabellini]

On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> It uses static DSDT table like the way x86 uses. Currently the DSDT
> table only contains processor device objects and it generates the
> maximal objects which so far is 128.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  tools/libxl/Makefile                 | 24 ++++++++-
>  tools/libxl/libxl_arm_acpi.c         | 15 ++++++
>  tools/libxl/libxl_arm_acpi.h         |  2 +
>  tools/libxl/libxl_empty_dsdt_arm.asl | 22 +++++++++
>  tools/libxl/libxl_mk_dsdt_arm.c      | 94 ++++++++++++++++++++++++++++++++++++
>  5 files changed, 156 insertions(+), 1 deletion(-)
>  create mode 100644 tools/libxl/libxl_empty_dsdt_arm.asl
>  create mode 100644 tools/libxl/libxl_mk_dsdt_arm.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 264b6ef..5347480 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -77,7 +77,29 @@ endif
>  
>  LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>  LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
> +
> +vpath iasl $(PATH)
> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
> +	$(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
> +
> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
> +	awk 'NR > 1 {print s} {s=$$0}' $< > $@
> +	./libxl_mk_dsdt_arm >> $@
> +
> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
> +	iasl -vs -p $* -tc $*.asl
> +	sed -e 's/AmlCode/$*/g' $*.hex >$@
> +	echo "int $*_len=sizeof($*);" >>$@
> +	rm -f $*.aml $*.hex
> +
> +iasl:
> +	@echo
> +	@echo "ACPI ASL compiler (iasl) is needed"
> +	@echo "Download and install Intel ACPI CA from"
> +	@echo "http://acpica.org/downloads/"
> +	@echo
> +	@exit 1
>  
>  libxl_arm_acpi.o: libxl_arm_acpi.c
>  	$(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index 353d774..45fc354 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -54,6 +54,9 @@ enum {
>      NUMS,
>  };
>  
> +extern unsigned char libxl_dsdt_anycpu_arm[];
> +extern int libxl_dsdt_anycpu_arm_len;
> +
>  struct acpitable {
>      void *table;
>      size_t size;
> @@ -256,6 +259,17 @@ static void make_acpi_fadt(libxl__gc *gc, struct xc_dom_image *dom)
>      dom->acpitable_size += ROUNDUP(acpitables[FADT].size, 3);
>  }
>  
> +static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +    acpitables[DSDT].table = libxl__zalloc(gc, libxl_dsdt_anycpu_arm_len);
> +    memcpy(acpitables[DSDT].table, libxl_dsdt_anycpu_arm,
> +           libxl_dsdt_anycpu_arm_len);
> +
> +    acpitables[DSDT].size = libxl_dsdt_anycpu_arm_len;
> +    /* Align to 64bit. */
> +    dom->acpitable_size += ROUNDUP(acpitables[DSDT].size, 3);
> +}
> +
>  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>                          libxl__domain_build_state *state,
>                          struct xc_dom_image *dom)
> @@ -284,6 +298,7 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>  	return rc;
>  
>      make_acpi_fadt(gc, dom);
> +    make_acpi_dsdt(gc, dom);
>  
>      return 0;
>  }
> diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
> index 9b58de6..b0fd9ce 100644
> --- a/tools/libxl/libxl_arm_acpi.h
> +++ b/tools/libxl/libxl_arm_acpi.h
> @@ -19,6 +19,8 @@
>  
>  #include <xc_dom.h>
>  
> +#define DOMU_MAX_VCPUS 128
> +
>  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>                          libxl__domain_build_state *state,
>                          struct xc_dom_image *dom);
> diff --git a/tools/libxl/libxl_empty_dsdt_arm.asl b/tools/libxl/libxl_empty_dsdt_arm.asl
> new file mode 100644
> index 0000000..005fa6a
> --- /dev/null
> +++ b/tools/libxl/libxl_empty_dsdt_arm.asl
> @@ -0,0 +1,22 @@
> +/******************************************************************************
> + * DSDT for Xen ARM DomU
> + *
> + * Copyright (c) 2004, Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program; If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +DefinitionBlock ("DSDT.aml", "DSDT", 3, "XenARM", "Xen DSDT", 1)
> +{
> +
> +}

Why do we need C code to generate the "static" asl? Can't we just
manually writing the asl code here and get rid of libxl_mk_dsdt_arm.c?


> diff --git a/tools/libxl/libxl_mk_dsdt_arm.c b/tools/libxl/libxl_mk_dsdt_arm.c
> new file mode 100644
> index 0000000..96fadbd
> --- /dev/null
> +++ b/tools/libxl/libxl_mk_dsdt_arm.c
> @@ -0,0 +1,94 @@
> +#include <stdio.h>
> +#include <stdarg.h>
> +#include <stdint.h>
> +#include <string.h>
> +#include <stdlib.h>
> +#include "libxl_arm_acpi.h"
> +
> +static unsigned int indent_level;
> +
> +static void indent(void)
> +{
> +    unsigned int i;
> +    for ( i = 0; i < indent_level; i++ )
> +        printf("    ");
> +}
> +
> +static __attribute__((format(printf, 2, 3)))
> +void _stmt(const char *name, const char *fmt, ...)
> +{
> +    va_list args;
> +
> +    indent();
> +    printf("%s", name);
> +
> +    if ( !fmt )
> +        return;
> +
> +    printf(" ( ");
> +    va_start(args, fmt);
> +    vprintf(fmt, args);
> +    va_end(args);
> +    printf(" )");
> +}
> +
> +#define stmt(n, f, a...)                        \
> +    do {                                        \
> +        _stmt(n, f , ## a );                    \
> +        printf("\n");                           \
> +    } while (0)
> +
> +#define push_block(n, f, a...)                  \
> +    do {                                        \
> +        _stmt(n, f , ## a );                    \
> +        printf(" {\n");                         \
> +        indent_level++;                         \
> +    } while (0)
> +
> +static void pop_block(void)
> +{
> +    indent_level--;
> +    indent();
> +    printf("}\n");
> +}
> +
> +int main(int argc, char **argv)
> +{
> +    unsigned int cpu, max_cpus = DOMU_MAX_VCPUS;
> +
> +    /**** DSDT DefinitionBlock start ****/
> +    /* (we append to existing DSDT definition block) */
> +    indent_level++;
> +
> +    /**** Processor start ****/
> +    push_block("Scope", "\\_SB");
> +
> +    /* Define processor objects and control methods. */
> +    for ( cpu = 0; cpu < max_cpus; cpu++)
> +    {
> +        push_block("Processor", "PR%02X, %d, 0x0000b010, 0x06", cpu, cpu);
> +
> +        stmt("Name", "_HID, \"ACPI0007\"");
> +        stmt("Name", "_UID, %d", cpu);
> +
> +        pop_block();
> +    }
> +
> +    pop_block();
> +    /**** Processor end ****/
> +
> +    pop_block();
> +    /**** DSDT DefinitionBlock end ****/
> +
> +    return 0;
> +}
> +
> +/*
> + * 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

Re: [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Stefano Stabellini]

On Thu, 23 Jun 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_acpi.c | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index d5ffedf..de863f4 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -39,6 +39,9 @@ typedef uint64_t u64;
>  #define ACPI_BUILD_APPNAME6 "XenARM"
>  #define ACPI_BUILD_APPNAME4 "Xen "
>  
> +#define ACPI_LEVEL_SENSITIVE            (u8) 0x00
> +#define ACPI_ACTIVE_LOW                 (u8) 0x01
> +
>  enum {
>      RSDP,
>      XSDT,
> @@ -110,6 +113,30 @@ static void make_acpi_xsdt(libxl__gc *gc, struct xc_dom_image *dom)
>      dom->acpitable_size += ROUNDUP(acpitables[XSDT].size, 3);
>  }
>  
> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +    struct acpi_table_gtdt *gtdt;
> +    size_t size = sizeof(*gtdt);
> +
> +    gtdt = libxl__zalloc(gc, size);
> +
> +    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", size, 2);
> +
> +    acpitables[GTDT].table = gtdt;
> +    acpitables[GTDT].size = size;
> +    /* Align to 64bit. */
> +    dom->acpitable_size += ROUNDUP(acpitables[GTDT].size, 3);
> +}

Many of this tables look pretty much static. Any reason why we can't
define them and initialize them on an header somewhere like:

    struct acpi_gtdt xen_acpi_gtdt {
        .non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
        .non_secure_el1_flags = (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE) | (ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
        .virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
        .virtual_timer_flags = (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)|(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);    
    };

it would make the code shorter and easier to read.


>  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>                          libxl__domain_build_state *state,
>                          struct xc_dom_image *dom)
> @@ -132,6 +159,7 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>  
>      make_acpi_rsdp(gc, dom);
>      make_acpi_xsdt(gc, dom);
> +    make_acpi_gtdt(gc, dom);
>  
>      return 0;
>  }
> -- 
> 2.0.4
> 
> 

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add a configuration option for ARM DomU so that user can deicde to use
> ACPI or not. This option is defaultly false.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>   tools/libxl/libxl_arm.c       | 3 +++
>   tools/libxl/libxl_types.idl   | 1 +
>   tools/libxl/xl_cmdimpl.c      | 4 ++++
>   xen/include/public/arch-arm.h | 1 +
>   4 files changed, 9 insertions(+)
>
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 8f15d9b..cc5a717 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -77,6 +77,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>           return ERROR_FAIL;
>       }
>
> +    xc_config->acpi = libxl_defbool_val(d_config->b_info.arch_arm.acpi)
> +                      ? true : false;
> +
>       return 0;
>   }
>
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index ef614be..426b868 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -560,6 +560,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>
>
>       ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
> +                               ("acpi", libxl_defbool),

If we are going towards a new field, you will need add a new define for 
advertising external toolstack of the presence of arch_arm.acpi in 
libxl.h (see LIBXL_HAVE_BUILDINFO_ARM_GIC_VERSION for instance).

>                                 ])),
>
>       ], dir=DIR_IN
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 6459eec..0634ffa 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2506,6 +2506,10 @@ skip_usbdev:
>           }
>        }
>
> +    if (xlu_cfg_get_defbool(config, "acpi", &b_info->arch_arm.acpi, 0)) {
> +        libxl_defbool_set(&b_info->arch_arm.acpi, 0);
> +    }
> +
>       xlu_cfg_destroy(config);
>   }
>
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 870bc3b..05e4a58 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -306,6 +306,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
>   struct xen_arch_domainconfig {
>       /* IN/OUT */
>       uint8_t gic_version;
> +    uint8_t acpi;

This structure is used to pass information to the hypervisor. I do not 
think the hypervisor has to know the domain is using ACPI.

>       /* IN */
>       uint32_t nr_spis;
>       /*
>

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 04/17] libxl/arm: prepare for constructing ACPI tables

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, Shannon Zhao wrote:

[...]

> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index cc5a717..f5db74b 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -1,6 +1,7 @@
>   #include "libxl_internal.h"
>   #include "libxl_arch.h"
>   #include "libxl_libfdt_compat.h"
> +#include "libxl_arm_acpi.h"
>
>   #include <xc_dom.h>
>   #include <stdbool.h>
> @@ -888,8 +889,24 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
>                                              libxl__domain_build_state *state,
>                                              struct xc_dom_image *dom)
>   {
> +    int rc;
> +
>       assert(info->type == LIBXL_DOMAIN_TYPE_PV);
> -    return libxl__prepare_dtb(gc, info, state, dom);
> +    rc = libxl__prepare_dtb(gc, info, state, dom);
> +    if (rc)
> +        return rc;
> +
> +    if (!state->config.acpi) {
> +        LOG(DEBUG, "Generating ACPI tables is disabled by user.");
> +        return 0;
> +    }
> +
> +    if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
> +        LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
> +        state->config.acpi = false;

Silently ignores the user configuration is usually not a good thing. So 
should not we return an error here?

> +    }
> +
> +    return libxl__prepare_acpi(gc, info, state, dom);
>   }
>
>   static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> new file mode 100644
> index 0000000..60c31f9
> --- /dev/null
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -0,0 +1,85 @@
> +/*
> + * ARM DmoU ACPI generation

s/DmoU/DomU/

[...]

> +#include "libxl_arm_acpi.h"
> +
> +#include <stdint.h>

Please add a newline here for clarity.

> +typedef uint8_t u8;
> +typedef uint16_t u16;
> +typedef uint32_t u32;
> +typedef uint64_t u64;

Ditto.

> +#include <acpi/acconfig.h>
> +#include <acpi/actbl.h>
> +
> +enum {
> +    RSDP,
> +    XSDT,
> +    GTDT,
> +    MADT,
> +    FADT,
> +    DSDT,
> +    NUMS,
> +};
> +
> +struct acpitable {
> +    void *table;
> +    size_t size;
> +};
> +
> +static struct acpitable acpitables[NUMS];

libxl is a library which can be used to implement daemon. So anything 
domain specific should not be static nor global.

> +
> +int libxl__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;
> +
> +    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);
> +
> +    dom->acpitable_blob = NULL;
> +    dom->acpitable_size = 0;
> +
> +    return 0;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
> new file mode 100644
> index 0000000..5899210
> --- /dev/null
> +++ b/tools/libxl/libxl_arm_acpi.h
> @@ -0,0 +1,32 @@

[...]

> +#include "libxl_internal.h"
> +#include "libxl_arch.h"
> +
> +#include <xc_dom.h>
> +
> +int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,

The function should be prefixed with _hidden.

> +                        libxl__domain_build_state *state,
> +                        struct xc_dom_image *dom);
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
>

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Julien Grall]

Hi,

On 23/06/16 16:00, Stefano Stabellini wrote:
> On Thu, 23 Jun 2016, Shannon Zhao wrote:

[...]

>> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
>> +{
>> +    struct acpi_table_gtdt *gtdt;
>> +    size_t size = sizeof(*gtdt);
>> +
>> +    gtdt = libxl__zalloc(gc, size);
>> +
>> +    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", size, 2);
>> +
>> +    acpitables[GTDT].table = gtdt;
>> +    acpitables[GTDT].size = size;
>> +    /* Align to 64bit. */
>> +    dom->acpitable_size += ROUNDUP(acpitables[GTDT].size, 3);
>> +}
>
> Many of this tables look pretty much static. Any reason why we can't
> define them and initialize them on an header somewhere like:
>
>      struct acpi_gtdt xen_acpi_gtdt {
>          .non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
>          .non_secure_el1_flags = (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE) | (ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
>          .virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
>          .virtual_timer_flags = (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)|(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
>      };
>
> it would make the code shorter and easier to read.

I agree with Stefano on this point.

>>   int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>>                           libxl__domain_build_state *state,
>>                           struct xc_dom_image *dom)
>> @@ -132,6 +159,7 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>>
>>       make_acpi_rsdp(gc, dom);
>>       make_acpi_xsdt(gc, dom);
>> +    make_acpi_gtdt(gc, dom);
>>
>>       return 0;
>>   }
>> --
>> 2.0.4
>>
>>
>

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, 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_acpi.c | 28 ++++++++++++++++++++++++++++
>   1 file changed, 28 insertions(+)
>
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index d5ffedf..de863f4 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -39,6 +39,9 @@ typedef uint64_t u64;
>   #define ACPI_BUILD_APPNAME6 "XenARM"
>   #define ACPI_BUILD_APPNAME4 "Xen "
>
> +#define ACPI_LEVEL_SENSITIVE            (u8) 0x00
> +#define ACPI_ACTIVE_LOW                 (u8) 0x01
> +

Why did not you include actypes.h rather than define these two defines?

>   enum {
>       RSDP,
>       XSDT,
> @@ -110,6 +113,30 @@ static void make_acpi_xsdt(libxl__gc *gc, struct xc_dom_image *dom)
>       dom->acpitable_size += ROUNDUP(acpitables[XSDT].size, 3);
>   }
>
> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +    struct acpi_table_gtdt *gtdt;
> +    size_t size = sizeof(*gtdt);
> +
> +    gtdt = libxl__zalloc(gc, size);
> +
> +    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", size, 2);
> +
> +    acpitables[GTDT].table = gtdt;
> +    acpitables[GTDT].size = size;
> +    /* Align to 64bit. */
> +    dom->acpitable_size += ROUNDUP(acpitables[GTDT].size, 3);

I am not sure how ROUNDUP(..., 3) will align to 64-bit.

> +}
> +
>   int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>                           libxl__domain_build_state *state,
>                           struct xc_dom_image *dom)
> @@ -132,6 +159,7 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>
>       make_acpi_rsdp(gc, dom);
>       make_acpi_xsdt(gc, dom);
> +    make_acpi_gtdt(gc, dom);
>
>       return 0;
>   }
>

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 08/17] libxl/arm: Factor MPIDR computing codes out as a helper

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Factor MPIDR computing codes out as a helper, so it could be shared
> between DT and ACPI.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>   tools/libxl/libxl_arm.c      |  8 +-------
>   tools/libxl/libxl_arm_acpi.h | 12 ++++++++++++
>   2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index f5db74b..a766732 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -312,13 +312,7 @@ static int make_cpus_node(libxl__gc *gc, void *fdt, int nr_cpus,
>       for (i = 0; i < nr_cpus; i++) {
>           const char *name;
>
> -        /*
> -         * According to ARM CPUs bindings, the reg field should match
> -         * the MPIDR's affinity bits. We will use AFF0 and AFF1 when
> -         * constructing the reg 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);
> +        mpidr_aff = libxl__compute_mpdir(i);
>           name = GCSPRINTF("cpu@%"PRIx64, mpidr_aff);
>
>           res = fdt_begin_node(fdt, name);
> diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
> index 5899210..9b58de6 100644
> --- a/tools/libxl/libxl_arm_acpi.h
> +++ b/tools/libxl/libxl_arm_acpi.h

I do not think libxl_arm_acpi.h is the right place to add 
libxl__compute_mpidr. This function is clearly not ACPI specific. You 
may want to rename this file libxl_arm.h instead.

> @@ -23,6 +23,18 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>                           libxl__domain_build_state *state,
>                           struct xc_dom_image *dom);
>
> +static inline uint64_t libxl__compute_mpdir(int index)

'index' should be unsigned int. It would also make sense to name this 
variable 'cpuid'.

> +{
> +    /*
> +     * According to ARM CPUs bindings, the reg field should match
> +     * the MPIDR's affinity bits. We will use AFF0 and AFF1 when
> +     * constructing the reg value of the guest at the moment, for it
> +     * is enough for the current max vcpu number.
> +     */
> +    assert(index >= 0);

This will avoid this assert here.

> +    return (index & 0x0f) | (((index >> 4) & 0xff) << 8);
> +}
> +
>   /*
>    * Local variables:
>    * mode: C
>

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 09/17] libxl/arm: Construct ACPI MADT table

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, Shannon Zhao wrote:
> 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_acpi.c | 100 +++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 100 insertions(+)
>
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index de863f4..659dbfa 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -42,6 +42,8 @@ typedef uint64_t u64;
>   #define ACPI_LEVEL_SENSITIVE            (u8) 0x00
>   #define ACPI_ACTIVE_LOW                 (u8) 0x01
>
> +#define ACPI_GICC_ENABLED 1

Is there any reason to not use ACPI_MADT_ENABLED?

> +
>   enum {
>       RSDP,
>       XSDT,
> @@ -137,6 +139,101 @@ static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
>       dom->acpitable_size += ROUNDUP(acpitables[GTDT].size, 3);
>   }
>
> +static void make_acpi_madt_gicc(void *table, int nr_cpus, uint64_t gicc_base)
> +{
> +    uint32_t i;
> +    struct acpi_madt_generic_interrupt *gicc = table;
> +
> +    for (i = 0; i < nr_cpus; i++) {
> +        gicc->header.type = ACPI_MADT_TYPE_GENERIC_INTERRUPT;
> +        gicc->header.length = sizeof(*gicc);
> +        gicc->base_address = gicc_base;
> +        gicc->cpu_interface_number = i;
> +        gicc->arm_mpidr = libxl__compute_mpdir(i);
> +        gicc->uid = i;
> +        gicc->flags = ACPI_GICC_ENABLED;
> +        gicc++;
> +    }
> +}
> +
> +static void make_acpi_madt_gicd(void *table, uint64_t gicd_base,
> +                                uint8_t gic_version)
> +{
> +    struct acpi_madt_generic_distributor *gicd = table;
> +
> +    gicd->header.type = ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR;
> +    gicd->header.length = sizeof(*gicd);
> +    gicd->base_address = gicd_base;
> +    /* This version filed has no meaning before ACPI 5.1 errata. */

s/filed/field/

> +    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->header.type = ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR;
> +    gicr->header.length = sizeof(*gicr);
> +    gicr->base_address = gicr_base;
> +    gicr->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)
> +{


[...]

> +
> +    make_acpi_header(&madt->header, "APIC", size, 3);
> +
> +    acpitables[MADT].table = madt;
> +    acpitables[MADT].size = size;
> +    /* Align to 64bit. */
> +    dom->acpitable_size += ROUNDUP(acpitables[MADT].size, 3);

I am not sure how ROUNDUP(..., 3) will align to 64-bit.

> +
> +    return 0;
> +}
> +
>   int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>                           libxl__domain_build_state *state,
>                           struct xc_dom_image *dom)
> @@ -160,6 +257,9 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>       make_acpi_rsdp(gc, dom);
>       make_acpi_xsdt(gc, dom);
>       make_acpi_gtdt(gc, dom);
> +    rc = make_acpi_madt(gc, dom, info->max_vcpus, xc_config);
> +    if (rc)
> +	return rc;
>
>       return 0;
>   }
>

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Julien Grall]

Hi,

On 23/06/16 15:50, Stefano Stabellini wrote:
> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>> diff --git a/tools/libxl/libxl_empty_dsdt_arm.asl b/tools/libxl/libxl_empty_dsdt_arm.asl
>> new file mode 100644
>> index 0000000..005fa6a
>> --- /dev/null
>> +++ b/tools/libxl/libxl_empty_dsdt_arm.asl
>> @@ -0,0 +1,22 @@
>> +/******************************************************************************
>> + * DSDT for Xen ARM DomU
>> + *
>> + * Copyright (c) 2004, Intel Corporation.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along with
>> + * this program; If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +DefinitionBlock ("DSDT.aml", "DSDT", 3, "XenARM", "Xen DSDT", 1)
>> +{
>> +
>> +}
>
> Why do we need C code to generate the "static" asl? Can't we just
> manually writing the asl code here and get rid of libxl_mk_dsdt_arm.c?

Whilst I agree that manually writing the asl code sounds more appealing, 
we need to write one node per processor. So currently this would be 128 
nodes and this will likely increase in the future.

Generating the asl has the advantage to be able to add new property in 
the processor node easily without having to modify one by one all the nodes.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Julien Grall]

On 23/06/16 17:26, Julien Grall wrote:
>>   enum {
>>       RSDP,
>>       XSDT,
>> @@ -110,6 +113,30 @@ static void make_acpi_xsdt(libxl__gc *gc, struct
>> xc_dom_image *dom)
>>       dom->acpitable_size += ROUNDUP(acpitables[XSDT].size, 3);
>>   }
>>
>> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
>> +{
>> +    struct acpi_table_gtdt *gtdt;
>> +    size_t size = sizeof(*gtdt);
>> +
>> +    gtdt = libxl__zalloc(gc, size);
>> +
>> +    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", size, 2);
>> +
>> +    acpitables[GTDT].table = gtdt;
>> +    acpitables[GTDT].size = size;
>> +    /* Align to 64bit. */
>> +    dom->acpitable_size += ROUNDUP(acpitables[GTDT].size, 3);
>
> I am not sure how ROUNDUP(..., 3) will align to 64-bit.

Hmmm I found why. The ROUNDUP macro in libxl is taking an order which is 
odd.

Cheers,

-- 
Julien Grall

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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, Shannon Zhao wrote:

[...]

> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 264b6ef..5347480 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -77,7 +77,29 @@ endif
>
>   LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>   LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
> +
> +vpath iasl $(PATH)
> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
> +	$(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
> +
> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
> +	awk 'NR > 1 {print s} {s=$$0}' $< > $@
> +	./libxl_mk_dsdt_arm >> $@
> +
> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
> +	iasl -vs -p $* -tc $*.asl
> +	sed -e 's/AmlCode/$*/g' $*.hex >$@
> +	echo "int $*_len=sizeof($*);" >>$@
> +	rm -f $*.aml $*.hex
> +

I don't like the idea to add iasl as a dependency for all ARM platforms. 
For instance ARMv7 platform will not use ACPI, but we still ask users to 
install iasl. So I think we should allow the user to opt-in/opt-out for 
ACPI.

Any opinions?

> +iasl:
> +	@echo
> +	@echo "ACPI ASL compiler (iasl) is needed"
> +	@echo "Download and install Intel ACPI CA from"
> +	@echo "http://acpica.org/downloads/"
> +	@echo
> +	@exit 1

It is really a pain to discover the dependency in the middle of a build. 
The presence of iasl should be done by the configure.

>
>   libxl_arm_acpi.o: libxl_arm_acpi.c
>   	$(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index 353d774..45fc354 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -54,6 +54,9 @@ enum {
>       NUMS,
>   };
>
> +extern unsigned char libxl_dsdt_anycpu_arm[];
> +extern int libxl_dsdt_anycpu_arm_len;

Not sure this is the right place to mention it, but I don't find the 
actual declaration.

Both variables should be const and _hidden. Also, the *_len should be at 
least const int.

> +
>   struct acpitable {
>       void *table;
>       size_t size;
> @@ -256,6 +259,17 @@ static void make_acpi_fadt(libxl__gc *gc, struct xc_dom_image *dom)
>       dom->acpitable_size += ROUNDUP(acpitables[FADT].size, 3);
>   }
>
> +static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +    acpitables[DSDT].table = libxl__zalloc(gc, libxl_dsdt_anycpu_arm_len);
> +    memcpy(acpitables[DSDT].table, libxl_dsdt_anycpu_arm,
> +           libxl_dsdt_anycpu_arm_len);
> +
> +    acpitables[DSDT].size = libxl_dsdt_anycpu_arm_len;
> +    /* Align to 64bit. */
> +    dom->acpitable_size += ROUNDUP(acpitables[DSDT].size, 3);
> +}
> +
>   int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>                           libxl__domain_build_state *state,
>                           struct xc_dom_image *dom)
> @@ -284,6 +298,7 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>   	return rc;
>
>       make_acpi_fadt(gc, dom);
> +    make_acpi_dsdt(gc, dom);
>
>       return 0;
>   }
> diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
> index 9b58de6..b0fd9ce 100644
> --- a/tools/libxl/libxl_arm_acpi.h
> +++ b/tools/libxl/libxl_arm_acpi.h
> @@ -19,6 +19,8 @@
>
>   #include <xc_dom.h>
>
> +#define DOMU_MAX_VCPUS 128
> +

I would rather define the maximum number of VCPUS in public/arch_arm.h 
to avoid defining the current number of vCPUs supported in multiple places.

>   int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>                           libxl__domain_build_state *state,
>                           struct xc_dom_image *dom);
> diff --git a/tools/libxl/libxl_empty_dsdt_arm.asl b/tools/libxl/libxl_empty_dsdt_arm.asl
> new file mode 100644
> index 0000000..005fa6a
> --- /dev/null
> +++ b/tools/libxl/libxl_empty_dsdt_arm.asl
> @@ -0,0 +1,22 @@
> +/******************************************************************************
> + * DSDT for Xen ARM DomU
> + *
> + * Copyright (c) 2004, Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program; If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +DefinitionBlock ("DSDT.aml", "DSDT", 3, "XenARM", "Xen DSDT", 1)
> +{
> +
> +}
> diff --git a/tools/libxl/libxl_mk_dsdt_arm.c b/tools/libxl/libxl_mk_dsdt_arm.c
> new file mode 100644
> index 0000000..96fadbd
> --- /dev/null
> +++ b/tools/libxl/libxl_mk_dsdt_arm.c

Can we share the code from tools/firmware/acpi/mk_dsdt.c?

> @@ -0,0 +1,94 @@
> +#include <stdio.h>
> +#include <stdarg.h>
> +#include <stdint.h>
> +#include <string.h>
> +#include <stdlib.h>
> +#include "libxl_arm_acpi.h"
> +
> +static unsigned int indent_level;
> +
> +static void indent(void)
> +{
> +    unsigned int i;
> +    for ( i = 0; i < indent_level; i++ )
> +        printf("    ");
> +}
> +
> +static __attribute__((format(printf, 2, 3)))
> +void _stmt(const char *name, const char *fmt, ...)
> +{
> +    va_list args;
> +
> +    indent();
> +    printf("%s", name);
> +
> +    if ( !fmt )
> +        return;
> +
> +    printf(" ( ");
> +    va_start(args, fmt);
> +    vprintf(fmt, args);
> +    va_end(args);
> +    printf(" )");
> +}
> +
> +#define stmt(n, f, a...)                        \
> +    do {                                        \
> +        _stmt(n, f , ## a );                    \
> +        printf("\n");                           \
> +    } while (0)
> +
> +#define push_block(n, f, a...)                  \
> +    do {                                        \
> +        _stmt(n, f , ## a );                    \
> +        printf(" {\n");                         \
> +        indent_level++;                         \
> +    } while (0)
> +
> +static void pop_block(void)
> +{
> +    indent_level--;
> +    indent();
> +    printf("}\n");
> +}
> +
> +int main(int argc, char **argv)
> +{
> +    unsigned int cpu, max_cpus = DOMU_MAX_VCPUS;
> +
> +    /**** DSDT DefinitionBlock start ****/
> +    /* (we append to existing DSDT definition block) */
> +    indent_level++;
> +
> +    /**** Processor start ****/
> +    push_block("Scope", "\\_SB");
> +
> +    /* Define processor objects and control methods. */
> +    for ( cpu = 0; cpu < max_cpus; cpu++)
> +    {
> +        push_block("Processor", "PR%02X, %d, 0x0000b010, 0x06", cpu, cpu);
> +
> +        stmt("Name", "_HID, \"ACPI0007\"");
> +        stmt("Name", "_UID, %d", cpu);
> +
> +        pop_block();
> +    }
> +
> +    pop_block();
> +    /**** Processor end ****/
> +
> +    pop_block();
> +    /**** DSDT DefinitionBlock end ****/
> +
> +    return 0;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
>

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 12/17] libxl/arm: Add a helper to calculate the ACPI table checksum

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>   tools/libxl/libxl_arm_acpi.c | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
>
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index 45fc354..d8779af 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -270,6 +270,21 @@ static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
>       dom->acpitable_size += ROUNDUP(acpitables[DSDT].size, 3);
>   }
>
> +static void calculate_checksum(void *table, uint32_t checksum_offset,
> +                               uint32_t length)

This will break compilation and therefore bisection as nobody is using 
this function. Please make sure that all the patch can build one by one.

> +{
> +    uint8_t *p, sum = 0;
> +
> +    p = table;
> +    p[checksum_offset] = 0;
> +
> +    while ( length-- )
> +        sum = sum + *p++;
> +
> +    p = table;
> +    p[checksum_offset] = -sum;
> +}
> +
>   int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>                           libxl__domain_build_state *state,
>                           struct xc_dom_image *dom)
>

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 13/17] libxl/arm: Link all ACPI tables into one buffer

[Julien Grall]

Hi Shannon,

On 23/06/16 04:17, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Link all ACPI tables into one buffer, fill in the addresses of
> tables and update checksum of each table.

Is there any reason to not allocate the acpitable_blob buffer before 
hand (and even reallocate if not enough space) and write the table 
directly in it?

Regards,

>
> Reserve a memory map space for ACPI tables.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>   tools/libxl/libxl_arm_acpi.c  | 58 +++++++++++++++++++++++++++++++++++++++++++
>   xen/include/public/arch-arm.h |  4 +++
>   2 files changed, 62 insertions(+)
>
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index d8779af..263b5de 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -285,6 +285,63 @@ static void calculate_checksum(void *table, uint32_t checksum_offset,
>       p[checksum_offset] = -sum;
>   }
>
> +static void link_acpi_tables(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +    uint64_t offset = 0;
> +    struct acpi_table_xsdt *xsdt;
> +    struct acpi_table_rsdp *rsdp;
> +    struct acpi_table_fadt *fadt;
> +
> +    assert(dom->acpitable_size <= GUEST_ACPI_SIZE);
> +    dom->acpitable_blob = libxl__zalloc(gc, dom->acpitable_size);
> +
> +    rsdp = (struct acpi_table_rsdp *)(dom->acpitable_blob + offset);
> +    memcpy(dom->acpitable_blob + offset, acpitables[RSDP].table,
> +           acpitables[RSDP].size);
> +    offset += ROUNDUP(acpitables[RSDP].size, 3);
> +
> +    xsdt = (struct acpi_table_xsdt *)(dom->acpitable_blob + offset);
> +    memcpy(dom->acpitable_blob + offset, acpitables[XSDT].table,
> +           acpitables[XSDT].size);
> +    rsdp->xsdt_physical_address = GUEST_ACPI_BASE + offset;
> +    calculate_checksum(rsdp, offsetof(struct acpi_table_header, checksum),
> +                       acpitables[RSDP].size);
> +    offset += ROUNDUP(acpitables[XSDT].size, 3);
> +
> +    memcpy(dom->acpitable_blob + offset, acpitables[MADT].table,
> +           acpitables[MADT].size);
> +    calculate_checksum(dom->acpitable_blob + offset,
> +                       offsetof(struct acpi_table_header, checksum),
> +                       acpitables[MADT].size);
> +    xsdt->table_offset_entry[0] = GUEST_ACPI_BASE + offset;
> +    offset += ROUNDUP(acpitables[MADT].size, 3);
> +
> +    memcpy(dom->acpitable_blob + offset, acpitables[GTDT].table,
> +           acpitables[GTDT].size);
> +    calculate_checksum(dom->acpitable_blob + offset,
> +                       offsetof(struct acpi_table_header, checksum),
> +                       acpitables[GTDT].size);
> +    xsdt->table_offset_entry[1] = GUEST_ACPI_BASE + offset;
> +    offset += ROUNDUP(acpitables[GTDT].size, 3);
> +
> +    fadt = (struct acpi_table_fadt *)(dom->acpitable_blob + offset);
> +    memcpy(dom->acpitable_blob + offset, acpitables[FADT].table,
> +           acpitables[FADT].size);
> +    xsdt->table_offset_entry[2] = GUEST_ACPI_BASE + offset;
> +    calculate_checksum(xsdt, offsetof(struct acpi_table_header, checksum),
> +                       acpitables[XSDT].size);
> +    offset += ROUNDUP(acpitables[FADT].size, 3);
> +
> +    memcpy(dom->acpitable_blob + offset, acpitables[DSDT].table,
> +           acpitables[DSDT].size);
> +    calculate_checksum(dom->acpitable_blob + offset,
> +                       offsetof(struct acpi_table_header, checksum),
> +                       acpitables[DSDT].size);
> +    fadt->dsdt = GUEST_ACPI_BASE + offset;
> +    calculate_checksum(fadt, offsetof(struct acpi_table_header, checksum),
> +                       acpitables[FADT].size);
> +}
> +
>   int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>                           libxl__domain_build_state *state,
>                           struct xc_dom_image *dom)
> @@ -314,6 +371,7 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>
>       make_acpi_fadt(gc, dom);
>       make_acpi_dsdt(gc, dom);
> +    link_acpi_tables(gc, dom);
>
>       return 0;
>   }
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 05e4a58..0911d16 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -407,6 +407,10 @@ typedef uint64_t xen_callback_t;
>   #define GUEST_GICV3_GICR0_BASE     0x03020000ULL    /* vCPU0 - vCPU127 */
>   #define GUEST_GICV3_GICR0_SIZE     0x01000000ULL
>
> +/* ACPI tables physical address */
> +#define GUEST_ACPI_BASE 0x20000000ULL
> +#define GUEST_ACPI_SIZE 0x00200000ULL
> +
>   /*
>    * 16MB == 4096 pages reserved for guest to use as a region to map its
>    * grant table in.
>

-- 
Julien Grall

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

Re: [PATCH v2 15/17] libxl/arm: Add ACPI module

[Julien Grall]

Hi Shannon,

On 23/06/2016 04:17, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Add the ARM Multiboot module for ACPI, so UEFI or DomU can get the base
> address of ACPI tables from it.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  docs/misc/arm/device-tree/acpi.txt | 23 +++++++++++++++++++++++
>  tools/libxl/libxl_arm.c            | 24 ++++++++++++++++++++++++
>  2 files changed, 47 insertions(+)
>  create mode 100644 docs/misc/arm/device-tree/acpi.txt
>
> diff --git a/docs/misc/arm/device-tree/acpi.txt b/docs/misc/arm/device-tree/acpi.txt
> new file mode 100644
> index 0000000..c39c4d0
> --- /dev/null
> +++ b/docs/misc/arm/device-tree/acpi.txt
> @@ -0,0 +1,23 @@
> +DomU ACPI module
> +================================
> +
> +Xen toolstack passes the domU ACPI tables via a reference in the /chosen node of
> +the device tree.
> +
> +Each node contains the following properties:
> +
> +- compatible
> +
> +	"xen,guest-acpi", "multiboot,module"
> +
> +- reg
> +
> +	Specifies the physical address and the length of the module.

We need to clarify how the firmware can find the RSDP. I.e will it 
always be at the beginning of the region?

Also, do we really need the size of the region? Would not be simpler to 
give the base address of RSDP?

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hi Shannon,

On 23/06/2016 04:17, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao@linaro.org>
>
> Copy all the ACPI tables to guest space so that UEFI or guest could
> access them.
>
> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> ---
>  tools/libxc/xc_dom_arm.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
>
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> index 64a8b67..6a0a5b7 100644
> --- a/tools/libxc/xc_dom_arm.c
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -63,6 +63,47 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
>
>  /* ------------------------------------------------------------------------ */
>
> +static int xc_dom_copy_acpi(struct xc_dom_image *dom)
> +{
> +    int rc, i;
> +    uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
> +                         XC_PAGE_SHIFT;
> +    const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
> +    xen_pfn_t *p2m;
> +    void *acpi_pages;
> +
> +    p2m = malloc(pages_num * sizeof(*p2m));
> +    for (i = 0; i < pages_num; i++)
> +        p2m[i] = base + i;
> +
> +    rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
> +                                          pages_num, 0, 0, p2m);

Hmmmm... it looks like this is working because libxl is setting the 
maximum size of the domain with some slack (1MB). However, I guess the 
slack was for something else. Wei, Stefano, Ian, can you confirm?

> +    if ( rc )
> +    {
> +        DOMPRINTF("%s: xc_domain_populate_physmap_exact failed with %d",
> +                  __FUNCTION__, rc);
> +        goto out;
> +    }
> +
> +    acpi_pages = xc_map_foreign_range(dom->xch, dom->guest_domid,
> +                                      PAGE_SIZE * pages_num,
> +                                      PROT_READ | PROT_WRITE, base);
> +    if ( !acpi_pages )
> +    {
> +        DOMPRINTF("%s Can't map acpi_pages", __FUNCTION__);
> +        rc = -1;
> +        goto out;
> +    }
> +
> +    memcpy(acpi_pages, dom->acpitable_blob, dom->acpitable_size);
> +
> +out:
> +    munmap(acpi_pages, pages_num * PAGE_SIZE);
> +    free(p2m);
> +
> +    return rc;
> +}
> +
>  static int alloc_magic_pages(struct xc_dom_image *dom)
>  {
	>      int rc, i;
> @@ -100,6 +141,16 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
>      xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN,
>              dom->xenstore_evtchn);
>
> +    if ( dom->acpitable_blob && dom->acpitable_size > 0 )
> +    {
> +        rc = xc_dom_copy_acpi(dom);
> +        if ( rc != 0 )
> +        {
> +            DOMPRINTF("Unable to copy ACPI tables");
> +            return rc;
> +        }
> +    }

alloc_magic_pages looks the wrong place with this function. Any reason 
to not have a generic ACPI blob loading in xc_dom_core.c as we do for 
devicetree?

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 17/17] libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ

[Julien Grall]

Hi Shannon,

On 23/06/2016 04:17, Shannon Zhao wrote:
> 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_acpi.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index 263b5de..8a42125 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -348,6 +348,7 @@ int libxl__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;
> @@ -373,7 +374,12 @@ int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>      make_acpi_dsdt(gc, dom);
>      link_acpi_tables(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);

This is not ACPI specific. It could be done even if ACPI is not inuse. 
Actually it what we are doing for DOM0. So we need to keep consistent.

>  }
>
>  /*
>

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 15/17] libxl/arm: Add ACPI module

[Shannon Zhao]

On 2016/6/24 2:35, Julien Grall wrote:
> Hi Shannon,
> 
> On 23/06/2016 04:17, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> Add the ARM Multiboot module for ACPI, so UEFI or DomU can get the base
>> address of ACPI tables from it.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> ---
>>  docs/misc/arm/device-tree/acpi.txt | 23 +++++++++++++++++++++++
>>  tools/libxl/libxl_arm.c            | 24 ++++++++++++++++++++++++
>>  2 files changed, 47 insertions(+)
>>  create mode 100644 docs/misc/arm/device-tree/acpi.txt
>>
>> diff --git a/docs/misc/arm/device-tree/acpi.txt
>> b/docs/misc/arm/device-tree/acpi.txt
>> new file mode 100644
>> index 0000000..c39c4d0
>> --- /dev/null
>> +++ b/docs/misc/arm/device-tree/acpi.txt
>> @@ -0,0 +1,23 @@
>> +DomU ACPI module
>> +================================
>> +
>> +Xen toolstack passes the domU ACPI tables via a reference in the
>> /chosen node of
>> +the device tree.
>> +
>> +Each node contains the following properties:
>> +
>> +- compatible
>> +
>> +    "xen,guest-acpi", "multiboot,module"
>> +
>> +- reg
>> +
>> +    Specifies the physical address and the length of the module.
> 
> We need to clarify how the firmware can find the RSDP. I.e will it
> always be at the beginning of the region?
> 
> Also, do we really need the size of the region? Would not be simpler to
> give the base address of RSDP?

Maybe it needs for some other UEFI implementations which will directly
pass the ACPI tables information with a UEFI memory map to guest like
you said. So maybe it needs the size to construct the UEFI memory map.

Thanks,
-- 
Shannon


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

Re: [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Shannon Zhao]

On 2016/6/24 0:26, Julien Grall wrote:
> On 23/06/16 04:16, 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_acpi.c | 28 ++++++++++++++++++++++++++++
>>   1 file changed, 28 insertions(+)
>>
>> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
>> index d5ffedf..de863f4 100644
>> --- a/tools/libxl/libxl_arm_acpi.c
>> +++ b/tools/libxl/libxl_arm_acpi.c
>> @@ -39,6 +39,9 @@ typedef uint64_t u64;
>>   #define ACPI_BUILD_APPNAME6 "XenARM"
>>   #define ACPI_BUILD_APPNAME4 "Xen "
>>
>> +#define ACPI_LEVEL_SENSITIVE            (u8) 0x00
>> +#define ACPI_ACTIVE_LOW                 (u8) 0x01
>> +
> 
> Why did not you include actypes.h rather than define these two defines?
If we include actypes.h, there will be some compiling errors.

../../xen/include/acpi/actypes.h:55:2: error: #error ACPI_MACHINE_WIDTH
not defined
 #error ACPI_MACHINE_WIDTH not defined
  ^
../../xen/include/acpi/actypes.h:130:9: error: unknown type name
'COMPILER_DEPENDENT_UINT64'
 typedef COMPILER_DEPENDENT_UINT64 UINT64;
         ^
../../xen/include/acpi/actypes.h:131:9: error: unknown type name
'COMPILER_DEPENDENT_INT64'
 typedef COMPILER_DEPENDENT_INT64 INT64;
         ^
../../xen/include/acpi/actypes.h:202:2: error: #error unknown
ACPI_MACHINE_WIDTH
 #error unknown ACPI_MACHINE_WIDTH
  ^
../../xen/include/acpi/actypes.h:207:9: error: unknown type name
'acpi_native_uint'
 typedef acpi_native_uint acpi_size;
         ^
../../xen/include/acpi/actypes.h:617:3: error: unknown type name
'acpi_io_address'
   acpi_io_address pblk_address;

Yeah, it maybe can be solved by defining ACPI_MACHINE_WIDTH and
COMPILER_DEPENDENT_INT64 here, but since we only needs
ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW, I think it's ok to define them
here.

Thanks,
-- 
Shannon


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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Shannon Zhao]

On 2016/6/24 0:42, Julien Grall wrote:
> 
> 
> On 23/06/16 15:50, Stefano Stabellini wrote:
>> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>>> diff --git a/tools/libxl/libxl_empty_dsdt_arm.asl
>>> b/tools/libxl/libxl_empty_dsdt_arm.asl
>>> new file mode 100644
>>> index 0000000..005fa6a
>>> --- /dev/null
>>> +++ b/tools/libxl/libxl_empty_dsdt_arm.asl
>>> @@ -0,0 +1,22 @@
>>> +/******************************************************************************
>>>
>>> + * DSDT for Xen ARM DomU
>>> + *
>>> + * Copyright (c) 2004, Intel Corporation.
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify it
>>> + * under the terms and conditions of the GNU General Public License,
>>> + * version 2, as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope it will be useful, but
>>> WITHOUT
>>> + * ANY WARRANTY; without even the implied warranty of
>>> MERCHANTABILITY or
>>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
>>> License for
>>> + * more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> along with
>>> + * this program; If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +DefinitionBlock ("DSDT.aml", "DSDT", 3, "XenARM", "Xen DSDT", 1)
>>> +{
>>> +
>>> +}
>>
>> Why do we need C code to generate the "static" asl? Can't we just
>> manually writing the asl code here and get rid of libxl_mk_dsdt_arm.c?
> 
> Whilst I agree that manually writing the asl code sounds more appealing,
> we need to write one node per processor. So currently this would be 128
> nodes and this will likely increase in the future.
> 
> Generating the asl has the advantage to be able to add new property in
> the processor node easily without having to modify one by one all the
> nodes.
Yes, and maybe in the future it needs to add other information in DSDT.

Thanks,
-- 
Shannon


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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Shannon Zhao]

On 2016/6/24 1:03, Julien Grall wrote:
> Hi Shannon,
> 
> On 23/06/16 04:16, Shannon Zhao wrote:
> 
> [...]
> 
>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>> index 264b6ef..5347480 100644
>> --- a/tools/libxl/Makefile
>> +++ b/tools/libxl/Makefile
>> @@ -77,7 +77,29 @@ endif
>>
>>   LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>>   LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o
>> libxl_libfdt_compat.o
>> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
>> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
>> +
>> +vpath iasl $(PATH)
>> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
>> +    $(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
>> +
>> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
>> +    awk 'NR > 1 {print s} {s=$$0}' $< > $@
>> +    ./libxl_mk_dsdt_arm >> $@
>> +
>> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
>> +    iasl -vs -p $* -tc $*.asl
>> +    sed -e 's/AmlCode/$*/g' $*.hex >$@
>> +    echo "int $*_len=sizeof($*);" >>$@
>> +    rm -f $*.aml $*.hex
>> +
> 
> I don't like the idea to add iasl as a dependency for all ARM platforms.
> For instance ARMv7 platform will not use ACPI, but we still ask users to
> install iasl. So I think we should allow the user to opt-in/opt-out for
> ACPI.
> 
> Any opinions?
> 
I agree. But how to exclude for ARMv7. I notice it only has the option
CONFIG_ARM which doesn't distinguish ARM32 and ARM64.

>> +iasl:
>> +    @echo
>> +    @echo "ACPI ASL compiler (iasl) is needed"
>> +    @echo "Download and install Intel ACPI CA from"
>> +    @echo "http://acpica.org/downloads/"
>> +    @echo
>> +    @exit 1
> 
> It is really a pain to discover the dependency in the middle of a build.
> The presence of iasl should be done by the configure.
> 
>>
>>   libxl_arm_acpi.o: libxl_arm_acpi.c
>>       $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
>> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
>> index 353d774..45fc354 100644
>> --- a/tools/libxl/libxl_arm_acpi.c
>> +++ b/tools/libxl/libxl_arm_acpi.c
>> @@ -54,6 +54,9 @@ enum {
>>       NUMS,
>>   };
>>
>> +extern unsigned char libxl_dsdt_anycpu_arm[];
>> +extern int libxl_dsdt_anycpu_arm_len;
> 
> Not sure this is the right place to mention it, but I don't find the
> actual declaration.
> 
The declarations are in libxl_dsdt_anycpu_arm.c which is generated by
iasl. You can see that in the Makefile above.

> Both variables should be const and _hidden. Also, the *_len should be at
> least const int.
> 
>> +
>>   struct acpitable {
>>       void *table;
>>       size_t size;
>> @@ -256,6 +259,17 @@ static void make_acpi_fadt(libxl__gc *gc, struct
>> xc_dom_image *dom)
>>       dom->acpitable_size += ROUNDUP(acpitables[FADT].size, 3);
>>   }
>>
>> +static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
>> +{
>> +    acpitables[DSDT].table = libxl__zalloc(gc,
>> libxl_dsdt_anycpu_arm_len);
>> +    memcpy(acpitables[DSDT].table, libxl_dsdt_anycpu_arm,
>> +           libxl_dsdt_anycpu_arm_len);
>> +
>> +    acpitables[DSDT].size = libxl_dsdt_anycpu_arm_len;
>> +    /* Align to 64bit. */
>> +    dom->acpitable_size += ROUNDUP(acpitables[DSDT].size, 3);
>> +}
>> +
>>   int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>>                           libxl__domain_build_state *state,
>>                           struct xc_dom_image *dom)
>> @@ -284,6 +298,7 @@ int libxl__prepare_acpi(libxl__gc *gc,
>> libxl_domain_build_info *info,
>>       return rc;
>>
>>       make_acpi_fadt(gc, dom);
>> +    make_acpi_dsdt(gc, dom);
>>
>>       return 0;
>>   }
>> diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
>> index 9b58de6..b0fd9ce 100644
>> --- a/tools/libxl/libxl_arm_acpi.h
>> +++ b/tools/libxl/libxl_arm_acpi.h
>> @@ -19,6 +19,8 @@
>>
>>   #include <xc_dom.h>
>>
>> +#define DOMU_MAX_VCPUS 128
>> +
> 
> I would rather define the maximum number of VCPUS in public/arch_arm.h
> to avoid defining the current number of vCPUs supported in multiple places.
> 
>>   int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>>                           libxl__domain_build_state *state,
>>                           struct xc_dom_image *dom);
>> diff --git a/tools/libxl/libxl_empty_dsdt_arm.asl
>> b/tools/libxl/libxl_empty_dsdt_arm.asl
>> new file mode 100644
>> index 0000000..005fa6a
>> --- /dev/null
>> +++ b/tools/libxl/libxl_empty_dsdt_arm.asl
>> @@ -0,0 +1,22 @@
>> +/******************************************************************************
>>
>> + * DSDT for Xen ARM DomU
>> + *
>> + * Copyright (c) 2004, Intel Corporation.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but
>> WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
>> License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> along with
>> + * this program; If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +DefinitionBlock ("DSDT.aml", "DSDT", 3, "XenARM", "Xen DSDT", 1)
>> +{
>> +
>> +}
>> diff --git a/tools/libxl/libxl_mk_dsdt_arm.c
>> b/tools/libxl/libxl_mk_dsdt_arm.c
>> new file mode 100644
>> index 0000000..96fadbd
>> --- /dev/null
>> +++ b/tools/libxl/libxl_mk_dsdt_arm.c
> 
> Can we share the code from tools/firmware/acpi/mk_dsdt.c?
>
Yeah, we can share push_block(), pop_block() stmt() and indent() but the
main() function is totally different since there are only the processor
device objects for ARM DSDT but there are many other things in x86.

I think that since Boris will move the codes under
tools/firmware/hvmloader/acpi to other place, after that we could see
how to share codes then.

>> @@ -0,0 +1,94 @@
>> +#include <stdio.h>
>> +#include <stdarg.h>
>> +#include <stdint.h>
>> +#include <string.h>
>> +#include <stdlib.h>
>> +#include "libxl_arm_acpi.h"
>> +
>> +static unsigned int indent_level;
>> +
>> +static void indent(void)
>> +{
>> +    unsigned int i;
>> +    for ( i = 0; i < indent_level; i++ )
>> +        printf("    ");
>> +}
>> +
>> +static __attribute__((format(printf, 2, 3)))
>> +void _stmt(const char *name, const char *fmt, ...)
>> +{
>> +    va_list args;
>> +
>> +    indent();
>> +    printf("%s", name);
>> +
>> +    if ( !fmt )
>> +        return;
>> +
>> +    printf(" ( ");
>> +    va_start(args, fmt);
>> +    vprintf(fmt, args);
>> +    va_end(args);
>> +    printf(" )");
>> +}
>> +
>> +#define stmt(n, f, a...)                        \
>> +    do {                                        \
>> +        _stmt(n, f , ## a );                    \
>> +        printf("\n");                           \
>> +    } while (0)
>> +
>> +#define push_block(n, f, a...)                  \
>> +    do {                                        \
>> +        _stmt(n, f , ## a );                    \
>> +        printf(" {\n");                         \
>> +        indent_level++;                         \
>> +    } while (0)
>> +
>> +static void pop_block(void)
>> +{
>> +    indent_level--;
>> +    indent();
>> +    printf("}\n");
>> +}
>> +
>> +int main(int argc, char **argv)
>> +{
>> +    unsigned int cpu, max_cpus = DOMU_MAX_VCPUS;
>> +
>> +    /**** DSDT DefinitionBlock start ****/
>> +    /* (we append to existing DSDT definition block) */
>> +    indent_level++;
>> +
>> +    /**** Processor start ****/
>> +    push_block("Scope", "\\_SB");
>> +
>> +    /* Define processor objects and control methods. */
>> +    for ( cpu = 0; cpu < max_cpus; cpu++)
>> +    {
>> +        push_block("Processor", "PR%02X, %d, 0x0000b010, 0x06", cpu,
>> cpu);
>> +
>> +        stmt("Name", "_HID, \"ACPI0007\"");
>> +        stmt("Name", "_UID, %d", cpu);
>> +
>> +        pop_block();
>> +    }
>> +
>> +    pop_block();
>> +    /**** Processor end ****/
>> +
>> +    pop_block();
>> +    /**** DSDT DefinitionBlock end ****/
>> +
>> +    return 0;
>> +}
>> +
>> +/*
>> + * Local variables:
>> + * mode: C
>> + * c-file-style: "BSD"
>> + * c-basic-offset: 4
>> + * tab-width: 4
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>>
> 
> Regards,
> 

-- 
Shannon


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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Shannon Zhao]

On 2016/6/24 2:46, Julien Grall wrote:
>> +
>>  static int alloc_magic_pages(struct xc_dom_image *dom)
>>  {
>     >      int rc, i;
>> @@ -100,6 +141,16 @@ static int alloc_magic_pages(struct xc_dom_image
>> *dom)
>>      xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN,
>>              dom->xenstore_evtchn);
>>
>> +    if ( dom->acpitable_blob && dom->acpitable_size > 0 )
>> +    {
>> +        rc = xc_dom_copy_acpi(dom);
>> +        if ( rc != 0 )
>> +        {
>> +            DOMPRINTF("Unable to copy ACPI tables");
>> +            return rc;
>> +        }
>> +    }
> 
> alloc_magic_pages looks the wrong place with this function. Any reason
> to not have a generic ACPI blob loading in xc_dom_core.c as we do for
> devicetree?
Looks like xc_dom_build_image is used for allocating pages in guest RAM
while ACPI blob is not put in guest RAM.

Thanks,
-- 
Shannon


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

Re: [PATCH v2 15/17] libxl/arm: Add ACPI module

[Julien Grall]

Hi Shannon,

On 25/06/16 04:22, Shannon Zhao wrote:
>
>
> On 2016/6/24 2:35, Julien Grall wrote:
>> Hi Shannon,
>>
>> On 23/06/2016 04:17, Shannon Zhao wrote:
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> Add the ARM Multiboot module for ACPI, so UEFI or DomU can get the base
>>> address of ACPI tables from it.
>>>
>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>> ---
>>>   docs/misc/arm/device-tree/acpi.txt | 23 +++++++++++++++++++++++
>>>   tools/libxl/libxl_arm.c            | 24 ++++++++++++++++++++++++
>>>   2 files changed, 47 insertions(+)
>>>   create mode 100644 docs/misc/arm/device-tree/acpi.txt
>>>
>>> diff --git a/docs/misc/arm/device-tree/acpi.txt
>>> b/docs/misc/arm/device-tree/acpi.txt
>>> new file mode 100644
>>> index 0000000..c39c4d0
>>> --- /dev/null
>>> +++ b/docs/misc/arm/device-tree/acpi.txt
>>> @@ -0,0 +1,23 @@
>>> +DomU ACPI module
>>> +================================
>>> +
>>> +Xen toolstack passes the domU ACPI tables via a reference in the
>>> /chosen node of
>>> +the device tree.
>>> +
>>> +Each node contains the following properties:
>>> +
>>> +- compatible
>>> +
>>> +    "xen,guest-acpi", "multiboot,module"
>>> +
>>> +- reg
>>> +
>>> +    Specifies the physical address and the length of the module.
>>
>> We need to clarify how the firmware can find the RSDP. I.e will it
>> always be at the beginning of the region?
>>
>> Also, do we really need the size of the region? Would not be simpler to
>> give the base address of RSDP?
>
> Maybe it needs for some other UEFI implementations which will directly
> pass the ACPI tables information with a UEFI memory map to guest like
> you said. So maybe it needs the size to construct the UEFI memory map.

Good point.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Julien Grall]

Hi Shannon,

On 27/06/16 02:44, Shannon Zhao wrote:
> On 2016/6/24 0:26, Julien Grall wrote:
>> On 23/06/16 04:16, 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_acpi.c | 28 ++++++++++++++++++++++++++++
>>>    1 file changed, 28 insertions(+)
>>>
>>> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
>>> index d5ffedf..de863f4 100644
>>> --- a/tools/libxl/libxl_arm_acpi.c
>>> +++ b/tools/libxl/libxl_arm_acpi.c
>>> @@ -39,6 +39,9 @@ typedef uint64_t u64;
>>>    #define ACPI_BUILD_APPNAME6 "XenARM"
>>>    #define ACPI_BUILD_APPNAME4 "Xen "
>>>
>>> +#define ACPI_LEVEL_SENSITIVE            (u8) 0x00
>>> +#define ACPI_ACTIVE_LOW                 (u8) 0x01
>>> +
>>
>> Why did not you include actypes.h rather than define these two defines?
> If we include actypes.h, there will be some compiling errors.
>
> ../../xen/include/acpi/actypes.h:55:2: error: #error ACPI_MACHINE_WIDTH
> not defined
>   #error ACPI_MACHINE_WIDTH not defined
>    ^
> ../../xen/include/acpi/actypes.h:130:9: error: unknown type name
> 'COMPILER_DEPENDENT_UINT64'
>   typedef COMPILER_DEPENDENT_UINT64 UINT64;
>           ^
> ../../xen/include/acpi/actypes.h:131:9: error: unknown type name
> 'COMPILER_DEPENDENT_INT64'
>   typedef COMPILER_DEPENDENT_INT64 INT64;
>           ^
> ../../xen/include/acpi/actypes.h:202:2: error: #error unknown
> ACPI_MACHINE_WIDTH
>   #error unknown ACPI_MACHINE_WIDTH
>    ^
> ../../xen/include/acpi/actypes.h:207:9: error: unknown type name
> 'acpi_native_uint'
>   typedef acpi_native_uint acpi_size;
>           ^
> ../../xen/include/acpi/actypes.h:617:3: error: unknown type name
> 'acpi_io_address'
>     acpi_io_address pblk_address;
>
> Yeah, it maybe can be solved by defining ACPI_MACHINE_WIDTH and
> COMPILER_DEPENDENT_INT64 here, but since we only needs
> ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW, I think it's ok to define them
> here.

We should avoid to redefine value as much as possible. The 2 missing 
values are easy to define (see below) so there is no point to redefine 
in a less obvious way: no comment to explain what the values are for, 
and only a part of the set defined.

#define ACPI_MACHINE_WIDTH BITS_PER_LONG
#define COMPILER_DEPENDENT_INT64 int64_t

Wei, Ian, Stefano, do you have any opinions?

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Julien Grall]

(CC Boris and Doug)

Hi Shannon,

On 27/06/16 07:01, Shannon Zhao wrote:
> On 2016/6/24 1:03, Julien Grall wrote:
>> On 23/06/16 04:16, Shannon Zhao wrote:
>>
>> [...]
>>
>>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>>> index 264b6ef..5347480 100644
>>> --- a/tools/libxl/Makefile
>>> +++ b/tools/libxl/Makefile
>>> @@ -77,7 +77,29 @@ endif
>>>
>>>    LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>>>    LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o
>>> libxl_libfdt_compat.o
>>> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
>>> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
>>> +
>>> +vpath iasl $(PATH)
>>> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
>>> +    $(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
>>> +
>>> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
>>> +    awk 'NR > 1 {print s} {s=$$0}' $< > $@
>>> +    ./libxl_mk_dsdt_arm >> $@
>>> +
>>> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
>>> +    iasl -vs -p $* -tc $*.asl
>>> +    sed -e 's/AmlCode/$*/g' $*.hex >$@
>>> +    echo "int $*_len=sizeof($*);" >>$@
>>> +    rm -f $*.aml $*.hex
>>> +
>>
>> I don't like the idea to add iasl as a dependency for all ARM platforms.
>> For instance ARMv7 platform will not use ACPI, but we still ask users to
>> install iasl. So I think we should allow the user to opt-in/opt-out for
>> ACPI.
>>
>> Any opinions?
>>
> I agree. But how to exclude for ARMv7. I notice it only has the option
> CONFIG_ARM which doesn't distinguish ARM32 and ARM64.

I am not sure if we plan to introduce Kconfig for tools. If not, you can 
add an option to the configure to enable/disable ACPI for guest.

This would be gated by the presence of "iasl".

[...]

>>> diff --git a/tools/libxl/libxl_mk_dsdt_arm.c
>>> b/tools/libxl/libxl_mk_dsdt_arm.c
>>> new file mode 100644
>>> index 0000000..96fadbd
>>> --- /dev/null
>>> +++ b/tools/libxl/libxl_mk_dsdt_arm.c
>>
>> Can we share the code from tools/firmware/acpi/mk_dsdt.c?
>>
> Yeah, we can share push_block(), pop_block() stmt() and indent() but the
> main() function is totally different since there are only the processor
> device objects for ARM DSDT but there are many other things in x86.
>
> I think that since Boris will move the codes under
> tools/firmware/hvmloader/acpi to other place, after that we could see
> how to share codes then.

I would prefer if we discuss about it now in order to avoid code 
duplication (I have CCed Boris).

For instance we can create a new directory under tools for mk_dsdt.c. 
The main could be different, although it might be possible to gate ARM 
options, and the rest of the code would be shared.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Julien Grall]

Hi Shannon,

On 23/06/16 15:34, Shannon Zhao wrote:
> On 2016年06月23日 21:39, Stefano Stabellini wrote:
>> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>
>>>> Add a configuration option for ARM DomU so that user can deicde to use
>>>> ACPI or not. This option is defaultly false.
>>>>
>>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>> ---
>>>>   tools/libxl/libxl_arm.c       | 3 +++
>>>>   tools/libxl/libxl_types.idl   | 1 +
>>>>   tools/libxl/xl_cmdimpl.c      | 4 ++++
>>>>   xen/include/public/arch-arm.h | 1 +
>>>>   4 files changed, 9 insertions(+)
>>>>
>>>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>>>> index 8f15d9b..cc5a717 100644
>>>> --- a/tools/libxl/libxl_arm.c
>>>> +++ b/tools/libxl/libxl_arm.c
>>>> @@ -77,6 +77,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>>>>           return ERROR_FAIL;
>>>>       }
>>>>
>>>> +    xc_config->acpi = libxl_defbool_val(d_config->b_info.arch_arm.acpi)
>>>> +                      ? true : false;
>>>> +
>>>>       return 0;
>>>>   }
>>>>
>>>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>>>> index ef614be..426b868 100644
>>>> --- a/tools/libxl/libxl_types.idl
>>>> +++ b/tools/libxl/libxl_types.idl
>>>> @@ -560,6 +560,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>>>>
>>>>
>>>>       ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
>>>> +                               ("acpi", libxl_defbool),
>>>>                                 ])),
>>>>
>>>>       ], dir=DIR_IN
>>>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>>>> index 6459eec..0634ffa 100644
>>>> --- a/tools/libxl/xl_cmdimpl.c
>>>> +++ b/tools/libxl/xl_cmdimpl.c
>>>> @@ -2506,6 +2506,10 @@ skip_usbdev:
>>>>           }
>>>>        }
>>>>
>>>> +    if (xlu_cfg_get_defbool(config, "acpi", &b_info->arch_arm.acpi, 0)) {
>>>> +        libxl_defbool_set(&b_info->arch_arm.acpi, 0);
>>>> +    }
>> We cannot share the existing code to parse the acpi paramter because
>> that is saved in b_info->u.hvm.acpi, right?
> Yes.
>> It's a pity. I wonder if we
>> could refactor the existing code so that we can actually share the acpi
>> parameter between x86 and arm.
>>
> I have no idea about this since I'm not familiar with this. But is there
> any downsides of current way? Because for x86, it will use
> b_info->u.hvm.acpi and for ARM it will use b_info->arch_arm.acpi. I
> think they don't conflict even though we store it at two places.

Yes, there is a downside.  Toolstack, such as libvirt, would need to 
have separate code for x86 and ARM in order to enable/disable ACPI.

I would introduce a new generic acpi parameters, deprecate 
b_info->u.hvm.acpi. Ian, Stefano, Wei, any opinions?

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

(CC Boris)

On 27/06/16 07:25, Shannon Zhao wrote:
>
>
> On 2016/6/24 2:46, Julien Grall wrote:
>>> +
>>>   static int alloc_magic_pages(struct xc_dom_image *dom)
>>>   {
>>      >      int rc, i;
>>> @@ -100,6 +141,16 @@ static int alloc_magic_pages(struct xc_dom_image
>>> *dom)
>>>       xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN,
>>>               dom->xenstore_evtchn);
>>>
>>> +    if ( dom->acpitable_blob && dom->acpitable_size > 0 )
>>> +    {
>>> +        rc = xc_dom_copy_acpi(dom);
>>> +        if ( rc != 0 )
>>> +        {
>>> +            DOMPRINTF("Unable to copy ACPI tables");
>>> +            return rc;
>>> +        }
>>> +    }
>>
>> alloc_magic_pages looks the wrong place with this function. Any reason
>> to not have a generic ACPI blob loading in xc_dom_core.c as we do for
>> devicetree?
> Looks like xc_dom_build_image is used for allocating pages in guest RAM
> while ACPI blob is not put in guest RAM.

The function xc_dom_build_image is used to load blob into the guest 
memory and allocate others pages (such as magic pages) which may not be 
part of the actual guest RAM.

The callback alloc_magic_pages is used to allocate per-architecture 
specific pages. However, the ACPI blob is pretty much generic. So I am 
not sure why we would want to do it for ARM only.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Boris Ostrovsky]

On 06/27/2016 06:29 AM, Julien Grall wrote:
> (CC Boris and Doug)
>
> Hi Shannon,
>
> On 27/06/16 07:01, Shannon Zhao wrote:
>> On 2016/6/24 1:03, Julien Grall wrote:
>>> On 23/06/16 04:16, Shannon Zhao wrote:
>>>
>>> [...]
>>>
>>>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>>>> index 264b6ef..5347480 100644
>>>> --- a/tools/libxl/Makefile
>>>> +++ b/tools/libxl/Makefile
>>>> @@ -77,7 +77,29 @@ endif
>>>>
>>>>    LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>>>>    LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o
>>>> libxl_libfdt_compat.o
>>>> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
>>>> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
>>>> +
>>>> +vpath iasl $(PATH)
>>>> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
>>>> +    $(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
>>>> +
>>>> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
>>>> +    awk 'NR > 1 {print s} {s=$$0}' $< > $@
>>>> +    ./libxl_mk_dsdt_arm >> $@
>>>> +
>>>> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
>>>> +    iasl -vs -p $* -tc $*.asl
>>>> +    sed -e 's/AmlCode/$*/g' $*.hex >$@
>>>> +    echo "int $*_len=sizeof($*);" >>$@
>>>> +    rm -f $*.aml $*.hex
>>>> +
>>>
>>> I don't like the idea to add iasl as a dependency for all ARM 
>>> platforms.
>>> For instance ARMv7 platform will not use ACPI, but we still ask 
>>> users to
>>> install iasl. So I think we should allow the user to opt-in/opt-out for
>>> ACPI.
>>>
>>> Any opinions?
>>>
>> I agree. But how to exclude for ARMv7. I notice it only has the option
>> CONFIG_ARM which doesn't distinguish ARM32 and ARM64.
>
> I am not sure if we plan to introduce Kconfig for tools. If not, you 
> can add an option to the configure to enable/disable ACPI for guest.
>
> This would be gated by the presence of "iasl".
>
> [...]
>
>>>> diff --git a/tools/libxl/libxl_mk_dsdt_arm.c
>>>> b/tools/libxl/libxl_mk_dsdt_arm.c
>>>> new file mode 100644
>>>> index 0000000..96fadbd
>>>> --- /dev/null
>>>> +++ b/tools/libxl/libxl_mk_dsdt_arm.c
>>>
>>> Can we share the code from tools/firmware/acpi/mk_dsdt.c?
>>>
>> Yeah, we can share push_block(), pop_block() stmt() and indent() but the
>> main() function is totally different since there are only the processor
>> device objects for ARM DSDT but there are many other things in x86.
>>
>> I think that since Boris will move the codes under
>> tools/firmware/hvmloader/acpi to other place, after that we could see
>> how to share codes then.
>
> I would prefer if we discuss about it now in order to avoid code 
> duplication (I have CCed Boris).
>
> For instance we can create a new directory under tools for mk_dsdt.c. 
> The main could be different, although it might be possible to gate ARM 
> options, and the rest of the code would be shared.


So I think we decided earlier to keep ARM and x86 ACPI builders 
separate, at least for now. However, looking at the Makefile and mk_dsdt 
I wonder whether it would make sense to put the builders in the same 
directory (I am currently using tools/libacpi) so that those two files 
can be kept common as much as possible, with the sources being 
different. E.g. something like

tools/libacpi:
     Makefile
     mk_dsdt.c
     acpi_x86.[ch]
     acpi_arm.[ch]
     *asl
     etc.

The objects will be built in tools/libxl (there will be no libacpi.so) 
but the infrastructure and sources will live together.

-boris

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky]

On 06/27/2016 06:49 AM, Julien Grall wrote:
> (CC Boris)
>
> On 27/06/16 07:25, Shannon Zhao wrote:
>>
>>
>> On 2016/6/24 2:46, Julien Grall wrote:
>>>> +
>>>>   static int alloc_magic_pages(struct xc_dom_image *dom)
>>>>   {
>>>      >      int rc, i;
>>>> @@ -100,6 +141,16 @@ static int alloc_magic_pages(struct xc_dom_image
>>>> *dom)
>>>>       xc_hvm_param_set(dom->xch, dom->guest_domid, 
>>>> HVM_PARAM_STORE_EVTCHN,
>>>>               dom->xenstore_evtchn);
>>>>
>>>> +    if ( dom->acpitable_blob && dom->acpitable_size > 0 )
>>>> +    {
>>>> +        rc = xc_dom_copy_acpi(dom);
>>>> +        if ( rc != 0 )
>>>> +        {
>>>> +            DOMPRINTF("Unable to copy ACPI tables");
>>>> +            return rc;
>>>> +        }
>>>> +    }
>>>
>>> alloc_magic_pages looks the wrong place with this function. Any reason
>>> to not have a generic ACPI blob loading in xc_dom_core.c as we do for
>>> devicetree?
>> Looks like xc_dom_build_image is used for allocating pages in guest RAM
>> while ACPI blob is not put in guest RAM.
>
> The function xc_dom_build_image is used to load blob into the guest 
> memory and allocate others pages (such as magic pages) which may not 
> be part of the actual guest RAM.
>
> The callback alloc_magic_pages is used to allocate per-architecture 
> specific pages. However, the ACPI blob is pretty much generic. So I am 
> not sure why we would want to do it for ARM only.


FWIW, for PVH I don't plan, at least for now, to keep a pointer to ACPI 
stuff in xc_dom_image. I am building the tables and loading them into 
the guest right away.

(As a separate point, I noticed that this series adds 4th type of blob 
(in addition to kernel, ramdisk and devicetree) so I wonder whether 
introducing a struct blob might be useful.)

-boris


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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Shannon Zhao]

On 2016/6/27 20:05, Boris Ostrovsky wrote:
> 
> 
> On 06/27/2016 06:29 AM, Julien Grall wrote:
>> (CC Boris and Doug)
>>
>> Hi Shannon,
>>
>> On 27/06/16 07:01, Shannon Zhao wrote:
>>> On 2016/6/24 1:03, Julien Grall wrote:
>>>> On 23/06/16 04:16, Shannon Zhao wrote:
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>>>>> index 264b6ef..5347480 100644
>>>>> --- a/tools/libxl/Makefile
>>>>> +++ b/tools/libxl/Makefile
>>>>> @@ -77,7 +77,29 @@ endif
>>>>>
>>>>>    LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>>>>>    LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o
>>>>> libxl_libfdt_compat.o
>>>>> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
>>>>> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
>>>>> +
>>>>> +vpath iasl $(PATH)
>>>>> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
>>>>> +    $(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
>>>>> +
>>>>> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
>>>>> +    awk 'NR > 1 {print s} {s=$$0}' $< > $@
>>>>> +    ./libxl_mk_dsdt_arm >> $@
>>>>> +
>>>>> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
>>>>> +    iasl -vs -p $* -tc $*.asl
>>>>> +    sed -e 's/AmlCode/$*/g' $*.hex >$@
>>>>> +    echo "int $*_len=sizeof($*);" >>$@
>>>>> +    rm -f $*.aml $*.hex
>>>>> +
>>>>
>>>> I don't like the idea to add iasl as a dependency for all ARM
>>>> platforms.
>>>> For instance ARMv7 platform will not use ACPI, but we still ask
>>>> users to
>>>> install iasl. So I think we should allow the user to opt-in/opt-out for
>>>> ACPI.
>>>>
>>>> Any opinions?
>>>>
>>> I agree. But how to exclude for ARMv7. I notice it only has the option
>>> CONFIG_ARM which doesn't distinguish ARM32 and ARM64.
>>
>> I am not sure if we plan to introduce Kconfig for tools. If not, you
>> can add an option to the configure to enable/disable ACPI for guest.
>>
>> This would be gated by the presence of "iasl".
>>
>> [...]
>>
>>>>> diff --git a/tools/libxl/libxl_mk_dsdt_arm.c
>>>>> b/tools/libxl/libxl_mk_dsdt_arm.c
>>>>> new file mode 100644
>>>>> index 0000000..96fadbd
>>>>> --- /dev/null
>>>>> +++ b/tools/libxl/libxl_mk_dsdt_arm.c
>>>>
>>>> Can we share the code from tools/firmware/acpi/mk_dsdt.c?
>>>>
>>> Yeah, we can share push_block(), pop_block() stmt() and indent() but the
>>> main() function is totally different since there are only the processor
>>> device objects for ARM DSDT but there are many other things in x86.
>>>
>>> I think that since Boris will move the codes under
>>> tools/firmware/hvmloader/acpi to other place, after that we could see
>>> how to share codes then.
>>
>> I would prefer if we discuss about it now in order to avoid code
>> duplication (I have CCed Boris).
>>
>> For instance we can create a new directory under tools for mk_dsdt.c.
>> The main could be different, although it might be possible to gate ARM
>> options, and the rest of the code would be shared.
> 
> 
> So I think we decided earlier to keep ARM and x86 ACPI builders
> separate, at least for now. 
I think so as well.

> However, looking at the Makefile and mk_dsdt
> I wonder whether it would make sense to put the builders in the same
> directory (I am currently using tools/libacpi) so that those two files
> can be kept common as much as possible, with the sources being
> different. E.g. something like
> 
> tools/libacpi:
>     Makefile
>     mk_dsdt.c
>     acpi_x86.[ch]
>     acpi_arm.[ch]
>     *asl
>     etc.
> 
> The objects will be built in tools/libxl (there will be no libacpi.so)
> but the infrastructure and sources will live together.
I'm fine with this. But I think the patch moving the codes into
tools/libacpi should be posted firstly, since this series depend on it.
Boris, could you please send that patch? Then I can add the
corresponding ARM patch on top of that.

Thanks,
-- 
Shannon


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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Boris Ostrovsky]

On 06/28/2016 07:03 AM, Shannon Zhao wrote:
>
> On 2016/6/27 20:05, Boris Ostrovsky wrote:
>>
>> On 06/27/2016 06:29 AM, Julien Grall wrote:
>>> (CC Boris and Doug)
>>>
>>> Hi Shannon,
>>>
>>> On 27/06/16 07:01, Shannon Zhao wrote:
>>>> On 2016/6/24 1:03, Julien Grall wrote:
>>>>> On 23/06/16 04:16, Shannon Zhao wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>>>>>> index 264b6ef..5347480 100644
>>>>>> --- a/tools/libxl/Makefile
>>>>>> +++ b/tools/libxl/Makefile
>>>>>> @@ -77,7 +77,29 @@ endif
>>>>>>
>>>>>>    LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>>>>>>    LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o
>>>>>> libxl_libfdt_compat.o
>>>>>> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
>>>>>> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
>>>>>> +
>>>>>> +vpath iasl $(PATH)
>>>>>> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
>>>>>> +    $(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
>>>>>> +
>>>>>> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
>>>>>> +    awk 'NR > 1 {print s} {s=$$0}' $< > $@
>>>>>> +    ./libxl_mk_dsdt_arm >> $@
>>>>>> +
>>>>>> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
>>>>>> +    iasl -vs -p $* -tc $*.asl
>>>>>> +    sed -e 's/AmlCode/$*/g' $*.hex >$@
>>>>>> +    echo "int $*_len=sizeof($*);" >>$@
>>>>>> +    rm -f $*.aml $*.hex
>>>>>> +
>>>>> I don't like the idea to add iasl as a dependency for all ARM
>>>>> platforms.
>>>>> For instance ARMv7 platform will not use ACPI, but we still ask
>>>>> users to
>>>>> install iasl. So I think we should allow the user to opt-in/opt-out for
>>>>> ACPI.
>>>>>
>>>>> Any opinions?
>>>>>
>>>> I agree. But how to exclude for ARMv7. I notice it only has the option
>>>> CONFIG_ARM which doesn't distinguish ARM32 and ARM64.
>>> I am not sure if we plan to introduce Kconfig for tools. If not, you
>>> can add an option to the configure to enable/disable ACPI for guest.
>>>
>>> This would be gated by the presence of "iasl".
>>>
>>> [...]
>>>
>>>>>> diff --git a/tools/libxl/libxl_mk_dsdt_arm.c
>>>>>> b/tools/libxl/libxl_mk_dsdt_arm.c
>>>>>> new file mode 100644
>>>>>> index 0000000..96fadbd
>>>>>> --- /dev/null
>>>>>> +++ b/tools/libxl/libxl_mk_dsdt_arm.c
>>>>> Can we share the code from tools/firmware/acpi/mk_dsdt.c?
>>>>>
>>>> Yeah, we can share push_block(), pop_block() stmt() and indent() but the
>>>> main() function is totally different since there are only the processor
>>>> device objects for ARM DSDT but there are many other things in x86.
>>>>
>>>> I think that since Boris will move the codes under
>>>> tools/firmware/hvmloader/acpi to other place, after that we could see
>>>> how to share codes then.
>>> I would prefer if we discuss about it now in order to avoid code
>>> duplication (I have CCed Boris).
>>>
>>> For instance we can create a new directory under tools for mk_dsdt.c.
>>> The main could be different, although it might be possible to gate ARM
>>> options, and the rest of the code would be shared.
>>
>> So I think we decided earlier to keep ARM and x86 ACPI builders
>> separate, at least for now. 
> I think so as well.
>
>> However, looking at the Makefile and mk_dsdt
>> I wonder whether it would make sense to put the builders in the same
>> directory (I am currently using tools/libacpi) so that those two files
>> can be kept common as much as possible, with the sources being
>> different. E.g. something like
>>
>> tools/libacpi:
>>     Makefile
>>     mk_dsdt.c
>>     acpi_x86.[ch]
>>     acpi_arm.[ch]
>>     *asl
>>     etc.
>>
>> The objects will be built in tools/libxl (there will be no libacpi.so)
>> but the infrastructure and sources will live together.
> I'm fine with this. But I think the patch moving the codes into
> tools/libacpi should be posted firstly, since this series depend on it.
> Boris, could you please send that patch? Then I can add the
> corresponding ARM patch on top of that.


I thought I had it almost ready yesterday but I encountered a problem
that I need to resolve before I post it. If I don't get it fixed in the
next couple of days I will send you a link to my repository so that you
can see what I have.

-boris


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

Re: [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Shannon Zhao]

On 2016/6/27 18:17, Julien Grall wrote:
> Hi Shannon,
> 
> On 27/06/16 02:44, Shannon Zhao wrote:
>> On 2016/6/24 0:26, Julien Grall wrote:
>>> On 23/06/16 04:16, 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_acpi.c | 28 ++++++++++++++++++++++++++++
>>>>    1 file changed, 28 insertions(+)
>>>>
>>>> diff --git a/tools/libxl/libxl_arm_acpi.c
>>>> b/tools/libxl/libxl_arm_acpi.c
>>>> index d5ffedf..de863f4 100644
>>>> --- a/tools/libxl/libxl_arm_acpi.c
>>>> +++ b/tools/libxl/libxl_arm_acpi.c
>>>> @@ -39,6 +39,9 @@ typedef uint64_t u64;
>>>>    #define ACPI_BUILD_APPNAME6 "XenARM"
>>>>    #define ACPI_BUILD_APPNAME4 "Xen "
>>>>
>>>> +#define ACPI_LEVEL_SENSITIVE            (u8) 0x00
>>>> +#define ACPI_ACTIVE_LOW                 (u8) 0x01
>>>> +
>>>
>>> Why did not you include actypes.h rather than define these two defines?
>> If we include actypes.h, there will be some compiling errors.
>>
>> ../../xen/include/acpi/actypes.h:55:2: error: #error ACPI_MACHINE_WIDTH
>> not defined
>>   #error ACPI_MACHINE_WIDTH not defined
>>    ^
>> ../../xen/include/acpi/actypes.h:130:9: error: unknown type name
>> 'COMPILER_DEPENDENT_UINT64'
>>   typedef COMPILER_DEPENDENT_UINT64 UINT64;
>>           ^
>> ../../xen/include/acpi/actypes.h:131:9: error: unknown type name
>> 'COMPILER_DEPENDENT_INT64'
>>   typedef COMPILER_DEPENDENT_INT64 INT64;
>>           ^
>> ../../xen/include/acpi/actypes.h:202:2: error: #error unknown
>> ACPI_MACHINE_WIDTH
>>   #error unknown ACPI_MACHINE_WIDTH
>>    ^
>> ../../xen/include/acpi/actypes.h:207:9: error: unknown type name
>> 'acpi_native_uint'
>>   typedef acpi_native_uint acpi_size;
>>           ^
>> ../../xen/include/acpi/actypes.h:617:3: error: unknown type name
>> 'acpi_io_address'
>>     acpi_io_address pblk_address;
>>
>> Yeah, it maybe can be solved by defining ACPI_MACHINE_WIDTH and
>> COMPILER_DEPENDENT_INT64 here, but since we only needs
>> ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW, I think it's ok to define them
>> here.
> 
> We should avoid to redefine value as much as possible. The 2 missing
> values are easy to define (see below) so there is no point to redefine
> in a less obvious way: no comment to explain what the values are for,
> and only a part of the set defined.
> 
> #define ACPI_MACHINE_WIDTH BITS_PER_LONG
> #define COMPILER_DEPENDENT_INT64 int64_t
> 
Actually not work. I add below codes but get compiling errors as well.
So it needs the BITS_PER_LONG but it exists asm-arm/config.h

+#define ACPI_MACHINE_WIDTH BITS_PER_LONG
+#define COMPILER_DEPENDENT_INT64 int64_t
+#define COMPILER_DEPENDENT_UINT64 uint64_t
+#include <acpi/actypes.h>

In file included from libxl_arm_acpi.c:34:0:
../../xen/include/acpi/actypes.h:202:2: error: #error unknown
ACPI_MACHINE_WIDTH
 #error unknown ACPI_MACHINE_WIDTH
  ^
../../xen/include/acpi/actypes.h:207:9: error: unknown type name
'acpi_native_uint'
 typedef acpi_native_uint acpi_size;
         ^
../../xen/include/acpi/actypes.h:617:3: error: unknown type name
'acpi_io_address'
   acpi_io_address pblk_address;

Thanks,
-- 
Shannon


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

Re: [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Julien Grall]

Hi Shannon,

On 29/06/2016 10:29, Shannon Zhao wrote:
>
>
> On 2016/6/27 18:17, Julien Grall wrote:
>> On 27/06/16 02:44, Shannon Zhao wrote:
>>> On 2016/6/24 0:26, Julien Grall wrote:
>>>> On 23/06/16 04:16, 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_acpi.c | 28 ++++++++++++++++++++++++++++
>>>>>    1 file changed, 28 insertions(+)
>>>>>
>>>>> diff --git a/tools/libxl/libxl_arm_acpi.c
>>>>> b/tools/libxl/libxl_arm_acpi.c
>>>>> index d5ffedf..de863f4 100644
>>>>> --- a/tools/libxl/libxl_arm_acpi.c
>>>>> +++ b/tools/libxl/libxl_arm_acpi.c
>>>>> @@ -39,6 +39,9 @@ typedef uint64_t u64;
>>>>>    #define ACPI_BUILD_APPNAME6 "XenARM"
>>>>>    #define ACPI_BUILD_APPNAME4 "Xen "
>>>>>
>>>>> +#define ACPI_LEVEL_SENSITIVE            (u8) 0x00
>>>>> +#define ACPI_ACTIVE_LOW                 (u8) 0x01
>>>>> +
>>>>
>>>> Why did not you include actypes.h rather than define these two defines?
>>> If we include actypes.h, there will be some compiling errors.
>>>
>>> ../../xen/include/acpi/actypes.h:55:2: error: #error ACPI_MACHINE_WIDTH
>>> not defined
>>>   #error ACPI_MACHINE_WIDTH not defined
>>>    ^
>>> ../../xen/include/acpi/actypes.h:130:9: error: unknown type name
>>> 'COMPILER_DEPENDENT_UINT64'
>>>   typedef COMPILER_DEPENDENT_UINT64 UINT64;
>>>           ^
>>> ../../xen/include/acpi/actypes.h:131:9: error: unknown type name
>>> 'COMPILER_DEPENDENT_INT64'
>>>   typedef COMPILER_DEPENDENT_INT64 INT64;
>>>           ^
>>> ../../xen/include/acpi/actypes.h:202:2: error: #error unknown
>>> ACPI_MACHINE_WIDTH
>>>   #error unknown ACPI_MACHINE_WIDTH
>>>    ^
>>> ../../xen/include/acpi/actypes.h:207:9: error: unknown type name
>>> 'acpi_native_uint'
>>>   typedef acpi_native_uint acpi_size;
>>>           ^
>>> ../../xen/include/acpi/actypes.h:617:3: error: unknown type name
>>> 'acpi_io_address'
>>>     acpi_io_address pblk_address;
>>>
>>> Yeah, it maybe can be solved by defining ACPI_MACHINE_WIDTH and
>>> COMPILER_DEPENDENT_INT64 here, but since we only needs
>>> ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW, I think it's ok to define them
>>> here.
>>
>> We should avoid to redefine value as much as possible. The 2 missing
>> values are easy to define (see below) so there is no point to redefine
>> in a less obvious way: no comment to explain what the values are for,
>> and only a part of the set defined.
>>
>> #define ACPI_MACHINE_WIDTH BITS_PER_LONG
>> #define COMPILER_DEPENDENT_INT64 int64_t
>>
> Actually not work. I add below codes but get compiling errors as well.
> So it needs the BITS_PER_LONG but it exists asm-arm/config.h

Give a look to bitperlongs.h in /usr/include. Although the name is 
__BITS_PER_LONG.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Shannon Zhao]

On 2016年06月29日 17:42, Julien Grall wrote:
> On 29/06/2016 10:29, Shannon Zhao wrote:
>>
>>
>> On 2016/6/27 18:17, Julien Grall wrote:
>>> On 27/06/16 02:44, Shannon Zhao wrote:
>>>> On 2016/6/24 0:26, Julien Grall wrote:
>>>>> On 23/06/16 04:16, 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_acpi.c | 28 ++++++++++++++++++++++++++++
>>>>>>    1 file changed, 28 insertions(+)
>>>>>>
>>>>>> diff --git a/tools/libxl/libxl_arm_acpi.c
>>>>>> b/tools/libxl/libxl_arm_acpi.c
>>>>>> index d5ffedf..de863f4 100644
>>>>>> --- a/tools/libxl/libxl_arm_acpi.c
>>>>>> +++ b/tools/libxl/libxl_arm_acpi.c
>>>>>> @@ -39,6 +39,9 @@ typedef uint64_t u64;
>>>>>>    #define ACPI_BUILD_APPNAME6 "XenARM"
>>>>>>    #define ACPI_BUILD_APPNAME4 "Xen "
>>>>>>
>>>>>> +#define ACPI_LEVEL_SENSITIVE            (u8) 0x00
>>>>>> +#define ACPI_ACTIVE_LOW                 (u8) 0x01
>>>>>> +
>>>>>
>>>>> Why did not you include actypes.h rather than define these two
>>>>> defines?
>>>> If we include actypes.h, there will be some compiling errors.
>>>>
>>>> ../../xen/include/acpi/actypes.h:55:2: error: #error ACPI_MACHINE_WIDTH
>>>> not defined
>>>>   #error ACPI_MACHINE_WIDTH not defined
>>>>    ^
>>>> ../../xen/include/acpi/actypes.h:130:9: error: unknown type name
>>>> 'COMPILER_DEPENDENT_UINT64'
>>>>   typedef COMPILER_DEPENDENT_UINT64 UINT64;
>>>>           ^
>>>> ../../xen/include/acpi/actypes.h:131:9: error: unknown type name
>>>> 'COMPILER_DEPENDENT_INT64'
>>>>   typedef COMPILER_DEPENDENT_INT64 INT64;
>>>>           ^
>>>> ../../xen/include/acpi/actypes.h:202:2: error: #error unknown
>>>> ACPI_MACHINE_WIDTH
>>>>   #error unknown ACPI_MACHINE_WIDTH
>>>>    ^
>>>> ../../xen/include/acpi/actypes.h:207:9: error: unknown type name
>>>> 'acpi_native_uint'
>>>>   typedef acpi_native_uint acpi_size;
>>>>           ^
>>>> ../../xen/include/acpi/actypes.h:617:3: error: unknown type name
>>>> 'acpi_io_address'
>>>>     acpi_io_address pblk_address;
>>>>
>>>> Yeah, it maybe can be solved by defining ACPI_MACHINE_WIDTH and
>>>> COMPILER_DEPENDENT_INT64 here, but since we only needs
>>>> ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW, I think it's ok to define
>>>> them
>>>> here.
>>>
>>> We should avoid to redefine value as much as possible. The 2 missing
>>> values are easy to define (see below) so there is no point to redefine
>>> in a less obvious way: no comment to explain what the values are for,
>>> and only a part of the set defined.
>>>
>>> #define ACPI_MACHINE_WIDTH BITS_PER_LONG
>>> #define COMPILER_DEPENDENT_INT64 int64_t
>>>
>> Actually not work. I add below codes but get compiling errors as well.
>> So it needs the BITS_PER_LONG but it exists asm-arm/config.h
> 
> Give a look to bitperlongs.h in /usr/include. Although the name is
> __BITS_PER_LONG.
Oh, Thanks. I'm wondering why other codes define own BITS_PER_LONG
rather than use __BITS_PER_LONG directly.

-- 
Shannon

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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Boris Ostrovsky]

On 06/28/2016 09:41 AM, Boris Ostrovsky wrote:
> On 06/28/2016 07:03 AM, Shannon Zhao wrote:
>> On 2016/6/27 20:05, Boris Ostrovsky wrote:
>>> On 06/27/2016 06:29 AM, Julien Grall wrote:
>>>> (CC Boris and Doug)
>>>>
>>>> Hi Shannon,
>>>>
>>>> On 27/06/16 07:01, Shannon Zhao wrote:
>>>>> On 2016/6/24 1:03, Julien Grall wrote:
>>>>>> On 23/06/16 04:16, Shannon Zhao wrote:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>>>>>>> index 264b6ef..5347480 100644
>>>>>>> --- a/tools/libxl/Makefile
>>>>>>> +++ b/tools/libxl/Makefile
>>>>>>> @@ -77,7 +77,29 @@ endif
>>>>>>>
>>>>>>>    LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>>>>>>>    LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o
>>>>>>> libxl_libfdt_compat.o
>>>>>>> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
>>>>>>> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
>>>>>>> +
>>>>>>> +vpath iasl $(PATH)
>>>>>>> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
>>>>>>> +    $(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
>>>>>>> +
>>>>>>> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
>>>>>>> +    awk 'NR > 1 {print s} {s=$$0}' $< > $@
>>>>>>> +    ./libxl_mk_dsdt_arm >> $@
>>>>>>> +
>>>>>>> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
>>>>>>> +    iasl -vs -p $* -tc $*.asl
>>>>>>> +    sed -e 's/AmlCode/$*/g' $*.hex >$@
>>>>>>> +    echo "int $*_len=sizeof($*);" >>$@
>>>>>>> +    rm -f $*.aml $*.hex
>>>>>>> +
>>>>>> I don't like the idea to add iasl as a dependency for all ARM
>>>>>> platforms.
>>>>>> For instance ARMv7 platform will not use ACPI, but we still ask
>>>>>> users to
>>>>>> install iasl. So I think we should allow the user to opt-in/opt-out for
>>>>>> ACPI.
>>>>>>
>>>>>> Any opinions?
>>>>>>
>>>>> I agree. But how to exclude for ARMv7. I notice it only has the option
>>>>> CONFIG_ARM which doesn't distinguish ARM32 and ARM64.
>>>> I am not sure if we plan to introduce Kconfig for tools. If not, you
>>>> can add an option to the configure to enable/disable ACPI for guest.
>>>>
>>>> This would be gated by the presence of "iasl".
>>>>
>>>> [...]
>>>>
>>>>>>> diff --git a/tools/libxl/libxl_mk_dsdt_arm.c
>>>>>>> b/tools/libxl/libxl_mk_dsdt_arm.c
>>>>>>> new file mode 100644
>>>>>>> index 0000000..96fadbd
>>>>>>> --- /dev/null
>>>>>>> +++ b/tools/libxl/libxl_mk_dsdt_arm.c
>>>>>> Can we share the code from tools/firmware/acpi/mk_dsdt.c?
>>>>>>
>>>>> Yeah, we can share push_block(), pop_block() stmt() and indent() but the
>>>>> main() function is totally different since there are only the processor
>>>>> device objects for ARM DSDT but there are many other things in x86.
>>>>>
>>>>> I think that since Boris will move the codes under
>>>>> tools/firmware/hvmloader/acpi to other place, after that we could see
>>>>> how to share codes then.
>>>> I would prefer if we discuss about it now in order to avoid code
>>>> duplication (I have CCed Boris).
>>>>
>>>> For instance we can create a new directory under tools for mk_dsdt.c.
>>>> The main could be different, although it might be possible to gate ARM
>>>> options, and the rest of the code would be shared.
>>> So I think we decided earlier to keep ARM and x86 ACPI builders
>>> separate, at least for now. 
>> I think so as well.
>>
>>> However, looking at the Makefile and mk_dsdt
>>> I wonder whether it would make sense to put the builders in the same
>>> directory (I am currently using tools/libacpi) so that those two files
>>> can be kept common as much as possible, with the sources being
>>> different. E.g. something like
>>>
>>> tools/libacpi:
>>>     Makefile
>>>     mk_dsdt.c
>>>     acpi_x86.[ch]
>>>     acpi_arm.[ch]
>>>     *asl
>>>     etc.
>>>
>>> The objects will be built in tools/libxl (there will be no libacpi.so)
>>> but the infrastructure and sources will live together.
>> I'm fine with this. But I think the patch moving the codes into
>> tools/libacpi should be posted firstly, since this series depend on it.
>> Boris, could you please send that patch? Then I can add the
>> corresponding ARM patch on top of that.
>
> I thought I had it almost ready yesterday but I encountered a problem
> that I need to resolve before I post it. If I don't get it fixed in the
> next couple of days I will send you a link to my repository so that you
> can see what I have.


This may take me longer than I thought so here is the repo:

git://oss.oracle.com/git/bostrovs/xen.git:acpi_v1_wip


-boris



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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Shannon Zhao]

On 2016/6/30 2:58, Boris Ostrovsky wrote:
> On 06/28/2016 09:41 AM, Boris Ostrovsky wrote:
>> > On 06/28/2016 07:03 AM, Shannon Zhao wrote:
>>> >> On 2016/6/27 20:05, Boris Ostrovsky wrote:
>>>> >>> On 06/27/2016 06:29 AM, Julien Grall wrote:
>>>>> >>>> (CC Boris and Doug)
>>>>> >>>>
>>>>> >>>> Hi Shannon,
>>>>> >>>>
>>>>> >>>> On 27/06/16 07:01, Shannon Zhao wrote:
>>>>>> >>>>> On 2016/6/24 1:03, Julien Grall wrote:
>>>>>>> >>>>>> On 23/06/16 04:16, Shannon Zhao wrote:
>>>>>>> >>>>>>
>>>>>>> >>>>>> [...]
>>>>>>> >>>>>>
>>>>>>>> >>>>>>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>>>>>>>> >>>>>>> index 264b6ef..5347480 100644
>>>>>>>> >>>>>>> --- a/tools/libxl/Makefile
>>>>>>>> >>>>>>> +++ b/tools/libxl/Makefile
>>>>>>>> >>>>>>> @@ -77,7 +77,29 @@ endif
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>>    LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>>>>>>>> >>>>>>>    LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o
>>>>>>>> >>>>>>> libxl_libfdt_compat.o
>>>>>>>> >>>>>>> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
>>>>>>>> >>>>>>> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
>>>>>>>> >>>>>>> +
>>>>>>>> >>>>>>> +vpath iasl $(PATH)
>>>>>>>> >>>>>>> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
>>>>>>>> >>>>>>> +    $(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
>>>>>>>> >>>>>>> +
>>>>>>>> >>>>>>> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
>>>>>>>> >>>>>>> +    awk 'NR > 1 {print s} {s=$$0}' $< > $@
>>>>>>>> >>>>>>> +    ./libxl_mk_dsdt_arm >> $@
>>>>>>>> >>>>>>> +
>>>>>>>> >>>>>>> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
>>>>>>>> >>>>>>> +    iasl -vs -p $* -tc $*.asl
>>>>>>>> >>>>>>> +    sed -e 's/AmlCode/$*/g' $*.hex >$@
>>>>>>>> >>>>>>> +    echo "int $*_len=sizeof($*);" >>$@
>>>>>>>> >>>>>>> +    rm -f $*.aml $*.hex
>>>>>>>> >>>>>>> +
>>>>>>> >>>>>> I don't like the idea to add iasl as a dependency for all ARM
>>>>>>> >>>>>> platforms.
>>>>>>> >>>>>> For instance ARMv7 platform will not use ACPI, but we still ask
>>>>>>> >>>>>> users to
>>>>>>> >>>>>> install iasl. So I think we should allow the user to opt-in/opt-out for
>>>>>>> >>>>>> ACPI.
>>>>>>> >>>>>>
>>>>>>> >>>>>> Any opinions?
>>>>>>> >>>>>>
>>>>>> >>>>> I agree. But how to exclude for ARMv7. I notice it only has the option
>>>>>> >>>>> CONFIG_ARM which doesn't distinguish ARM32 and ARM64.
>>>>> >>>> I am not sure if we plan to introduce Kconfig for tools. If not, you
>>>>> >>>> can add an option to the configure to enable/disable ACPI for guest.
>>>>> >>>>
>>>>> >>>> This would be gated by the presence of "iasl".
>>>>> >>>>
>>>>> >>>> [...]
>>>>> >>>>
>>>>>>>> >>>>>>> diff --git a/tools/libxl/libxl_mk_dsdt_arm.c
>>>>>>>> >>>>>>> b/tools/libxl/libxl_mk_dsdt_arm.c
>>>>>>>> >>>>>>> new file mode 100644
>>>>>>>> >>>>>>> index 0000000..96fadbd
>>>>>>>> >>>>>>> --- /dev/null
>>>>>>>> >>>>>>> +++ b/tools/libxl/libxl_mk_dsdt_arm.c
>>>>>>> >>>>>> Can we share the code from tools/firmware/acpi/mk_dsdt.c?
>>>>>>> >>>>>>
>>>>>> >>>>> Yeah, we can share push_block(), pop_block() stmt() and indent() but the
>>>>>> >>>>> main() function is totally different since there are only the processor
>>>>>> >>>>> device objects for ARM DSDT but there are many other things in x86.
>>>>>> >>>>>
>>>>>> >>>>> I think that since Boris will move the codes under
>>>>>> >>>>> tools/firmware/hvmloader/acpi to other place, after that we could see
>>>>>> >>>>> how to share codes then.
>>>>> >>>> I would prefer if we discuss about it now in order to avoid code
>>>>> >>>> duplication (I have CCed Boris).
>>>>> >>>>
>>>>> >>>> For instance we can create a new directory under tools for mk_dsdt.c.
>>>>> >>>> The main could be different, although it might be possible to gate ARM
>>>>> >>>> options, and the rest of the code would be shared.
>>>> >>> So I think we decided earlier to keep ARM and x86 ACPI builders
>>>> >>> separate, at least for now. 
>>> >> I think so as well.
>>> >>
>>>> >>> However, looking at the Makefile and mk_dsdt
>>>> >>> I wonder whether it would make sense to put the builders in the same
>>>> >>> directory (I am currently using tools/libacpi) so that those two files
>>>> >>> can be kept common as much as possible, with the sources being
>>>> >>> different. E.g. something like
>>>> >>>
>>>> >>> tools/libacpi:
>>>> >>>     Makefile
>>>> >>>     mk_dsdt.c
>>>> >>>     acpi_x86.[ch]
>>>> >>>     acpi_arm.[ch]
>>>> >>>     *asl
>>>> >>>     etc.
>>>> >>>
>>>> >>> The objects will be built in tools/libxl (there will be no libacpi.so)
>>>> >>> but the infrastructure and sources will live together.
>>> >> I'm fine with this. But I think the patch moving the codes into
>>> >> tools/libacpi should be posted firstly, since this series depend on it.
>>> >> Boris, could you please send that patch? Then I can add the
>>> >> corresponding ARM patch on top of that.
>> >
>> > I thought I had it almost ready yesterday but I encountered a problem
>> > that I need to resolve before I post it. If I don't get it fixed in the
>> > next couple of days I will send you a link to my repository so that you
>> > can see what I have.
> 
> This may take me longer than I thought so here is the repo:
> 
> git://oss.oracle.com/git/bostrovs/xen.git:acpi_v1_wip
Hi Boris,

Thanks a lot!
While I found there is a compiling problem of the last patch.

undefined reference to `libxl__dom_load_acpi'
collect2: error: ld returned 1 exit status

I think you should define the corresponding function for ARM.

Julien, Stefano,

Looks like Boris is going to use libxl__dom_load_acpi to load ACPI
tables, do we need to use it for ARM as well or load the tables in
xc_dom_build_image()?

Thanks,
-- 
Shannon


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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Julien Grall]

Hi Shannon,

On 01/07/16 08:58, Shannon Zhao wrote:
> On 2016/6/30 2:58, Boris Ostrovsky wrote:
>> git://oss.oracle.com/git/bostrovs/xen.git:acpi_v1_wip
> Hi Boris,
>
> Thanks a lot!
> While I found there is a compiling problem of the last patch.
>
> undefined reference to `libxl__dom_load_acpi'
> collect2: error: ld returned 1 exit status
>
> I think you should define the corresponding function for ARM.

And this function should contain arch in the name to show it is 
arch-specific.

However, I am not sure why 
libxl__arch_domain_{init,finalize}_hw_description were not re-used.

>
> Julien, Stefano,
>
> Looks like Boris is going to use libxl__dom_load_acpi to load ACPI
> tables, do we need to use it for ARM as well or load the tables in
> xc_dom_build_image()?

I gave a quick look to the code and it is very similar to ARM for the 
allocation of the memory and copying the ACPI tables. So we may want to 
share some bits here.

I have the feeling it would be better to do it in libxc where all the 
guest memory is handled. But I will let the tools maintainers decide 
where this should be done.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Boris Ostrovsky]

On 07/01/2016 06:18 AM, Julien Grall wrote:
> Hi Shannon,
>
> On 01/07/16 08:58, Shannon Zhao wrote:
>> On 2016/6/30 2:58, Boris Ostrovsky wrote:
>>> git://oss.oracle.com/git/bostrovs/xen.git:acpi_v1_wip
>> Hi Boris,
>>
>> Thanks a lot!
>> While I found there is a compiling problem of the last patch.
>>
>> undefined reference to `libxl__dom_load_acpi'
>> collect2: error: ld returned 1 exit status
>>
>> I think you should define the corresponding function for ARM.
>
> And this function should contain arch in the name to show it is
> arch-specific.
>
> However, I am not sure why
> libxl__arch_domain_{init,finalize}_hw_description were not re-used.


Haven't thought about those, I might be able to do that (finalize is the
likely place).


>
>>
>> Julien, Stefano,
>>
>> Looks like Boris is going to use libxl__dom_load_acpi to load ACPI
>> tables, do we need to use it for ARM as well or load the tables in
>> xc_dom_build_image()?
>
> I gave a quick look to the code and it is very similar to ARM for the
> allocation of the memory and copying the ACPI tables. So we may want
> to share some bits here.
>
> I have the feeling it would be better to do it in libxc where all the
> guest memory is handled. But I will let the tools maintainers decide
> where this should be done.

Haven't we decided that libxl is the better place?

-boris




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

Re: [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Julien Grall]

Hi Boris,

On 01/07/16 15:42, Boris Ostrovsky wrote:
> On 07/01/2016 06:18 AM, Julien Grall wrote:
>> On 01/07/16 08:58, Shannon Zhao wrote:
>>> On 2016/6/30 2:58, Boris Ostrovsky wrote:
>>>> git://oss.oracle.com/git/bostrovs/xen.git:acpi_v1_wip

[...]

>>> Looks like Boris is going to use libxl__dom_load_acpi to load ACPI
>>> tables, do we need to use it for ARM as well or load the tables in
>>> xc_dom_build_image()?
>>
>> I gave a quick look to the code and it is very similar to ARM for the
>> allocation of the memory and copying the ACPI tables. So we may want
>> to share some bits here.
>>
>> I have the feeling it would be better to do it in libxc where all the
>> guest memory is handled. But I will let the tools maintainers decide
>> where this should be done.
>
> Haven't we decided that libxl is the better place?

The discussion was related to building the ACPI tables. I consider 
loading the blob into memory as distinct step.

Currently, the memory layout and loading blobs into the memory is 
handled by libxc (see xc_dom_build_image). It would be rather strange to 
load the ACPI tables in libxl.

For what is worth, on ARM the device tree is built by libxl and loaded 
by libxc.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Stefano Stabellini]

On Mon, 27 Jun 2016, Julien Grall wrote:
> Hi Shannon,
> 
> On 27/06/16 02:44, Shannon Zhao wrote:
> > On 2016/6/24 0:26, Julien Grall wrote:
> > > On 23/06/16 04:16, 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_acpi.c | 28 ++++++++++++++++++++++++++++
> > > >    1 file changed, 28 insertions(+)
> > > > 
> > > > diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> > > > index d5ffedf..de863f4 100644
> > > > --- a/tools/libxl/libxl_arm_acpi.c
> > > > +++ b/tools/libxl/libxl_arm_acpi.c
> > > > @@ -39,6 +39,9 @@ typedef uint64_t u64;
> > > >    #define ACPI_BUILD_APPNAME6 "XenARM"
> > > >    #define ACPI_BUILD_APPNAME4 "Xen "
> > > > 
> > > > +#define ACPI_LEVEL_SENSITIVE            (u8) 0x00
> > > > +#define ACPI_ACTIVE_LOW                 (u8) 0x01
> > > > +
> > > 
> > > Why did not you include actypes.h rather than define these two defines?
> > If we include actypes.h, there will be some compiling errors.
> > 
> > ../../xen/include/acpi/actypes.h:55:2: error: #error ACPI_MACHINE_WIDTH
> > not defined
> >   #error ACPI_MACHINE_WIDTH not defined
> >    ^
> > ../../xen/include/acpi/actypes.h:130:9: error: unknown type name
> > 'COMPILER_DEPENDENT_UINT64'
> >   typedef COMPILER_DEPENDENT_UINT64 UINT64;
> >           ^
> > ../../xen/include/acpi/actypes.h:131:9: error: unknown type name
> > 'COMPILER_DEPENDENT_INT64'
> >   typedef COMPILER_DEPENDENT_INT64 INT64;
> >           ^
> > ../../xen/include/acpi/actypes.h:202:2: error: #error unknown
> > ACPI_MACHINE_WIDTH
> >   #error unknown ACPI_MACHINE_WIDTH
> >    ^
> > ../../xen/include/acpi/actypes.h:207:9: error: unknown type name
> > 'acpi_native_uint'
> >   typedef acpi_native_uint acpi_size;
> >           ^
> > ../../xen/include/acpi/actypes.h:617:3: error: unknown type name
> > 'acpi_io_address'
> >     acpi_io_address pblk_address;
> > 
> > Yeah, it maybe can be solved by defining ACPI_MACHINE_WIDTH and
> > COMPILER_DEPENDENT_INT64 here, but since we only needs
> > ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW, I think it's ok to define them
> > here.
> 
> We should avoid to redefine value as much as possible. The 2 missing values
> are easy to define (see below) so there is no point to redefine in a less
> obvious way: no comment to explain what the values are for, and only a part of
> the set defined.
> 
> #define ACPI_MACHINE_WIDTH BITS_PER_LONG
> #define COMPILER_DEPENDENT_INT64 int64_t
> 
> Wei, Ian, Stefano, do you have any opinions?

I think you are right that we should avoid redefining
ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW. But I think if possible we
should also avoid redefining ACPI_MACHINE_WIDTH and
COMPILER_DEPENDENT_INT64. If possible, we should include the header file
with those definitions too (acpi/platform/acenv.h ?).

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Stefano Stabellini]

On Thu, 23 Jun 2016, Julien Grall wrote:
> Hi Shannon,
> 
> On 23/06/2016 04:17, Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@linaro.org>
> > 
> > Copy all the ACPI tables to guest space so that UEFI or guest could
> > access them.
> > 
> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> > ---
> >  tools/libxc/xc_dom_arm.c | 51
> > ++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 51 insertions(+)
> > 
> > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > index 64a8b67..6a0a5b7 100644
> > --- a/tools/libxc/xc_dom_arm.c
> > +++ b/tools/libxc/xc_dom_arm.c
> > @@ -63,6 +63,47 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
> > 
> >  /* ------------------------------------------------------------------------
> > */
> > 
> > +static int xc_dom_copy_acpi(struct xc_dom_image *dom)
> > +{
> > +    int rc, i;
> > +    uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
> > +                         XC_PAGE_SHIFT;
> > +    const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
> > +    xen_pfn_t *p2m;
> > +    void *acpi_pages;
> > +
> > +    p2m = malloc(pages_num * sizeof(*p2m));
> > +    for (i = 0; i < pages_num; i++)
> > +        p2m[i] = base + i;
> > +
> > +    rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
> > +                                          pages_num, 0, 0, p2m);
> 
> Hmmmm... it looks like this is working because libxl is setting the maximum
> size of the domain with some slack (1MB). However, I guess the slack was for
> something else. Wei, Stefano, Ian, can you confirm?

If I recall correctly, the slack is a magic value coming from the
ancient history of toolstacks.

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hi Stefano,

On 05/07/16 18:13, Stefano Stabellini wrote:
> On Thu, 23 Jun 2016, Julien Grall wrote:
>> On 23/06/2016 04:17, Shannon Zhao wrote:
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> Copy all the ACPI tables to guest space so that UEFI or guest could
>>> access them.
>>>
>>> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>> ---
>>>   tools/libxc/xc_dom_arm.c | 51
>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>>   1 file changed, 51 insertions(+)
>>>
>>> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
>>> index 64a8b67..6a0a5b7 100644
>>> --- a/tools/libxc/xc_dom_arm.c
>>> +++ b/tools/libxc/xc_dom_arm.c
>>> @@ -63,6 +63,47 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
>>>
>>>   /* ------------------------------------------------------------------------
>>> */
>>>
>>> +static int xc_dom_copy_acpi(struct xc_dom_image *dom)
>>> +{
>>> +    int rc, i;
>>> +    uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
>>> +                         XC_PAGE_SHIFT;
>>> +    const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
>>> +    xen_pfn_t *p2m;
>>> +    void *acpi_pages;
>>> +
>>> +    p2m = malloc(pages_num * sizeof(*p2m));
>>> +    for (i = 0; i < pages_num; i++)
>>> +        p2m[i] = base + i;
>>> +
>>> +    rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
>>> +                                          pages_num, 0, 0, p2m);
>>
>> Hmmmm... it looks like this is working because libxl is setting the maximum
>> size of the domain with some slack (1MB). However, I guess the slack was for
>> something else. Wei, Stefano, Ian, can you confirm?
>
> If I recall correctly, the slack is a magic value coming from the
> ancient history of toolstacks.

Does it mean we would need to update the slack to take into account the 
ACPI blob?

Cheers,

-- 
Julien Grall

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

Re: [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Julien Grall]

Hi Stefano,

On 05/07/16 17:42, Stefano Stabellini wrote:
> On Mon, 27 Jun 2016, Julien Grall wrote:
>> On 27/06/16 02:44, Shannon Zhao wrote:
>>> On 2016/6/24 0:26, Julien Grall wrote:
>>>> On 23/06/16 04:16, 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_acpi.c | 28 ++++++++++++++++++++++++++++
>>>>>     1 file changed, 28 insertions(+)
>>>>>
>>>>> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
>>>>> index d5ffedf..de863f4 100644
>>>>> --- a/tools/libxl/libxl_arm_acpi.c
>>>>> +++ b/tools/libxl/libxl_arm_acpi.c
>>>>> @@ -39,6 +39,9 @@ typedef uint64_t u64;
>>>>>     #define ACPI_BUILD_APPNAME6 "XenARM"
>>>>>     #define ACPI_BUILD_APPNAME4 "Xen "
>>>>>
>>>>> +#define ACPI_LEVEL_SENSITIVE            (u8) 0x00
>>>>> +#define ACPI_ACTIVE_LOW                 (u8) 0x01
>>>>> +
>>>>
>>>> Why did not you include actypes.h rather than define these two defines?
>>> If we include actypes.h, there will be some compiling errors.
>>>
>>> ../../xen/include/acpi/actypes.h:55:2: error: #error ACPI_MACHINE_WIDTH
>>> not defined
>>>    #error ACPI_MACHINE_WIDTH not defined
>>>     ^
>>> ../../xen/include/acpi/actypes.h:130:9: error: unknown type name
>>> 'COMPILER_DEPENDENT_UINT64'
>>>    typedef COMPILER_DEPENDENT_UINT64 UINT64;
>>>            ^
>>> ../../xen/include/acpi/actypes.h:131:9: error: unknown type name
>>> 'COMPILER_DEPENDENT_INT64'
>>>    typedef COMPILER_DEPENDENT_INT64 INT64;
>>>            ^
>>> ../../xen/include/acpi/actypes.h:202:2: error: #error unknown
>>> ACPI_MACHINE_WIDTH
>>>    #error unknown ACPI_MACHINE_WIDTH
>>>     ^
>>> ../../xen/include/acpi/actypes.h:207:9: error: unknown type name
>>> 'acpi_native_uint'
>>>    typedef acpi_native_uint acpi_size;
>>>            ^
>>> ../../xen/include/acpi/actypes.h:617:3: error: unknown type name
>>> 'acpi_io_address'
>>>      acpi_io_address pblk_address;
>>>
>>> Yeah, it maybe can be solved by defining ACPI_MACHINE_WIDTH and
>>> COMPILER_DEPENDENT_INT64 here, but since we only needs
>>> ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW, I think it's ok to define them
>>> here.
>>
>> We should avoid to redefine value as much as possible. The 2 missing values
>> are easy to define (see below) so there is no point to redefine in a less
>> obvious way: no comment to explain what the values are for, and only a part of
>> the set defined.
>>
>> #define ACPI_MACHINE_WIDTH BITS_PER_LONG
>> #define COMPILER_DEPENDENT_INT64 int64_t
>>
>> Wei, Ian, Stefano, do you have any opinions?
>
> I think you are right that we should avoid redefining
> ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW. But I think if possible we
> should also avoid redefining ACPI_MACHINE_WIDTH and
> COMPILER_DEPENDENT_INT64. If possible, we should include the header file
> with those definitions too (acpi/platform/acenv.h ?).

acenv.h is including aclinux.h with contains a lot of hypervisor 
specific include. So we would need to rework the include to use it in 
the toolstack.

Or maybe this can be found in /usr/include/?

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Stefano Stabellini]

On Wed, 6 Jul 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 05/07/16 18:13, Stefano Stabellini wrote:
> > On Thu, 23 Jun 2016, Julien Grall wrote:
> > > On 23/06/2016 04:17, Shannon Zhao wrote:
> > > > From: Shannon Zhao <shannon.zhao@linaro.org>
> > > > 
> > > > Copy all the ACPI tables to guest space so that UEFI or guest could
> > > > access them.
> > > > 
> > > > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> > > > ---
> > > >   tools/libxc/xc_dom_arm.c | 51
> > > > ++++++++++++++++++++++++++++++++++++++++++++++++
> > > >   1 file changed, 51 insertions(+)
> > > > 
> > > > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > > > index 64a8b67..6a0a5b7 100644
> > > > --- a/tools/libxc/xc_dom_arm.c
> > > > +++ b/tools/libxc/xc_dom_arm.c
> > > > @@ -63,6 +63,47 @@ static int setup_pgtables_arm(struct xc_dom_image
> > > > *dom)
> > > > 
> > > >   /*
> > > > ------------------------------------------------------------------------
> > > > */
> > > > 
> > > > +static int xc_dom_copy_acpi(struct xc_dom_image *dom)
> > > > +{
> > > > +    int rc, i;
> > > > +    uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
> > > > +                         XC_PAGE_SHIFT;
> > > > +    const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
> > > > +    xen_pfn_t *p2m;
> > > > +    void *acpi_pages;
> > > > +
> > > > +    p2m = malloc(pages_num * sizeof(*p2m));
> > > > +    for (i = 0; i < pages_num; i++)
> > > > +        p2m[i] = base + i;
> > > > +
> > > > +    rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
> > > > +                                          pages_num, 0, 0, p2m);
> > > 
> > > Hmmmm... it looks like this is working because libxl is setting the
> > > maximum
> > > size of the domain with some slack (1MB). However, I guess the slack was
> > > for
> > > something else. Wei, Stefano, Ian, can you confirm?
> > 
> > If I recall correctly, the slack is a magic value coming from the
> > ancient history of toolstacks.
> 
> Does it mean we would need to update the slack to take into account the ACPI
> blob?

Yes, we need to take into account the ACPI blob. Probably not in the
slack but directly in mam_memkb.

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

Re: [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Stefano Stabellini]

On Wed, 6 Jul 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 05/07/16 17:42, Stefano Stabellini wrote:
> > On Mon, 27 Jun 2016, Julien Grall wrote:
> > > On 27/06/16 02:44, Shannon Zhao wrote:
> > > > On 2016/6/24 0:26, Julien Grall wrote:
> > > > > On 23/06/16 04:16, 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_acpi.c | 28 ++++++++++++++++++++++++++++
> > > > > >     1 file changed, 28 insertions(+)
> > > > > > 
> > > > > > diff --git a/tools/libxl/libxl_arm_acpi.c
> > > > > > b/tools/libxl/libxl_arm_acpi.c
> > > > > > index d5ffedf..de863f4 100644
> > > > > > --- a/tools/libxl/libxl_arm_acpi.c
> > > > > > +++ b/tools/libxl/libxl_arm_acpi.c
> > > > > > @@ -39,6 +39,9 @@ typedef uint64_t u64;
> > > > > >     #define ACPI_BUILD_APPNAME6 "XenARM"
> > > > > >     #define ACPI_BUILD_APPNAME4 "Xen "
> > > > > > 
> > > > > > +#define ACPI_LEVEL_SENSITIVE            (u8) 0x00
> > > > > > +#define ACPI_ACTIVE_LOW                 (u8) 0x01
> > > > > > +
> > > > > 
> > > > > Why did not you include actypes.h rather than define these two
> > > > > defines?
> > > > If we include actypes.h, there will be some compiling errors.
> > > > 
> > > > ../../xen/include/acpi/actypes.h:55:2: error: #error ACPI_MACHINE_WIDTH
> > > > not defined
> > > >    #error ACPI_MACHINE_WIDTH not defined
> > > >     ^
> > > > ../../xen/include/acpi/actypes.h:130:9: error: unknown type name
> > > > 'COMPILER_DEPENDENT_UINT64'
> > > >    typedef COMPILER_DEPENDENT_UINT64 UINT64;
> > > >            ^
> > > > ../../xen/include/acpi/actypes.h:131:9: error: unknown type name
> > > > 'COMPILER_DEPENDENT_INT64'
> > > >    typedef COMPILER_DEPENDENT_INT64 INT64;
> > > >            ^
> > > > ../../xen/include/acpi/actypes.h:202:2: error: #error unknown
> > > > ACPI_MACHINE_WIDTH
> > > >    #error unknown ACPI_MACHINE_WIDTH
> > > >     ^
> > > > ../../xen/include/acpi/actypes.h:207:9: error: unknown type name
> > > > 'acpi_native_uint'
> > > >    typedef acpi_native_uint acpi_size;
> > > >            ^
> > > > ../../xen/include/acpi/actypes.h:617:3: error: unknown type name
> > > > 'acpi_io_address'
> > > >      acpi_io_address pblk_address;
> > > > 
> > > > Yeah, it maybe can be solved by defining ACPI_MACHINE_WIDTH and
> > > > COMPILER_DEPENDENT_INT64 here, but since we only needs
> > > > ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW, I think it's ok to define them
> > > > here.
> > > 
> > > We should avoid to redefine value as much as possible. The 2 missing
> > > values
> > > are easy to define (see below) so there is no point to redefine in a less
> > > obvious way: no comment to explain what the values are for, and only a
> > > part of
> > > the set defined.
> > > 
> > > #define ACPI_MACHINE_WIDTH BITS_PER_LONG
> > > #define COMPILER_DEPENDENT_INT64 int64_t
> > > 
> > > Wei, Ian, Stefano, do you have any opinions?
> > 
> > I think you are right that we should avoid redefining
> > ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW. But I think if possible we
> > should also avoid redefining ACPI_MACHINE_WIDTH and
> > COMPILER_DEPENDENT_INT64. If possible, we should include the header file
> > with those definitions too (acpi/platform/acenv.h ?).
> 
> acenv.h is including aclinux.h with contains a lot of hypervisor specific
> include. So we would need to rework the include to use it in the toolstack.
> 
> Or maybe this can be found in /usr/include/?

I was thinking of the one in the Xen tree. If it is not possible to
include it, then OK.

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Wei Liu]

On Mon, Jun 27, 2016 at 11:40:32AM +0100, Julien Grall wrote:
> Hi Shannon,
> 
> On 23/06/16 15:34, Shannon Zhao wrote:
> >On 2016年06月23日 21:39, Stefano Stabellini wrote:
> >>On Thu, 23 Jun 2016, Shannon Zhao wrote:
> >>>>From: Shannon Zhao <shannon.zhao@linaro.org>
> >>>>
> >>>>Add a configuration option for ARM DomU so that user can deicde to use
> >>>>ACPI or not. This option is defaultly false.
> >>>>
> >>>>Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> >>>>---
> >>>>  tools/libxl/libxl_arm.c       | 3 +++
> >>>>  tools/libxl/libxl_types.idl   | 1 +
> >>>>  tools/libxl/xl_cmdimpl.c      | 4 ++++
> >>>>  xen/include/public/arch-arm.h | 1 +
> >>>>  4 files changed, 9 insertions(+)
> >>>>
> >>>>diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> >>>>index 8f15d9b..cc5a717 100644
> >>>>--- a/tools/libxl/libxl_arm.c
> >>>>+++ b/tools/libxl/libxl_arm.c
> >>>>@@ -77,6 +77,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> >>>>          return ERROR_FAIL;
> >>>>      }
> >>>>
> >>>>+    xc_config->acpi = libxl_defbool_val(d_config->b_info.arch_arm.acpi)
> >>>>+                      ? true : false;
> >>>>+
> >>>>      return 0;
> >>>>  }
> >>>>
> >>>>diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> >>>>index ef614be..426b868 100644
> >>>>--- a/tools/libxl/libxl_types.idl
> >>>>+++ b/tools/libxl/libxl_types.idl
> >>>>@@ -560,6 +560,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
> >>>>
> >>>>
> >>>>      ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
> >>>>+                               ("acpi", libxl_defbool),
> >>>>                                ])),
> >>>>
> >>>>      ], dir=DIR_IN
> >>>>diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> >>>>index 6459eec..0634ffa 100644
> >>>>--- a/tools/libxl/xl_cmdimpl.c
> >>>>+++ b/tools/libxl/xl_cmdimpl.c
> >>>>@@ -2506,6 +2506,10 @@ skip_usbdev:
> >>>>          }
> >>>>       }
> >>>>
> >>>>+    if (xlu_cfg_get_defbool(config, "acpi", &b_info->arch_arm.acpi, 0)) {
> >>>>+        libxl_defbool_set(&b_info->arch_arm.acpi, 0);
> >>>>+    }
> >>We cannot share the existing code to parse the acpi paramter because
> >>that is saved in b_info->u.hvm.acpi, right?
> >Yes.
> >>It's a pity. I wonder if we
> >>could refactor the existing code so that we can actually share the acpi
> >>parameter between x86 and arm.
> >>
> >I have no idea about this since I'm not familiar with this. But is there
> >any downsides of current way? Because for x86, it will use
> >b_info->u.hvm.acpi and for ARM it will use b_info->arch_arm.acpi. I
> >think they don't conflict even though we store it at two places.
> 
> Yes, there is a downside.  Toolstack, such as libvirt, would need to have
> separate code for x86 and ARM in order to enable/disable ACPI.
> 
> I would introduce a new generic acpi parameters, deprecate
> b_info->u.hvm.acpi. Ian, Stefano, Wei, any opinions?
> 

Yeah, we can deprecate that field. But we need to take care to not break
users of the old field.

Wei.

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Thu, Jun 23, 2016 at 07:46:42PM +0100, Julien Grall wrote:
> Hi Shannon,
> 
> On 23/06/2016 04:17, Shannon Zhao wrote:
> >From: Shannon Zhao <shannon.zhao@linaro.org>
> >
> >Copy all the ACPI tables to guest space so that UEFI or guest could
> >access them.
> >
> >Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> >---
> > tools/libxc/xc_dom_arm.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 51 insertions(+)
> >
> >diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> >index 64a8b67..6a0a5b7 100644
> >--- a/tools/libxc/xc_dom_arm.c
> >+++ b/tools/libxc/xc_dom_arm.c
> >@@ -63,6 +63,47 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
> >
> > /* ------------------------------------------------------------------------ */
> >
> >+static int xc_dom_copy_acpi(struct xc_dom_image *dom)
> >+{
> >+    int rc, i;
> >+    uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
> >+                         XC_PAGE_SHIFT;
> >+    const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
> >+    xen_pfn_t *p2m;
> >+    void *acpi_pages;
> >+
> >+    p2m = malloc(pages_num * sizeof(*p2m));
> >+    for (i = 0; i < pages_num; i++)
> >+        p2m[i] = base + i;
> >+
> >+    rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
> >+                                          pages_num, 0, 0, p2m);
> 
> Hmmmm... it looks like this is working because libxl is setting the maximum
> size of the domain with some slack (1MB). However, I guess the slack was for
> something else. Wei, Stefano, Ian, can you confirm?

Please don't rely on this slack. Account memory properly please.

Wei.

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Shannon Zhao]

On 2016/7/7 23:30, Wei Liu wrote:
> On Mon, Jun 27, 2016 at 11:40:32AM +0100, Julien Grall wrote:
>> > Hi Shannon,
>> > 
>> > On 23/06/16 15:34, Shannon Zhao wrote:
>>> > >On 2016年06月23日 21:39, Stefano Stabellini wrote:
>>>> > >>On Thu, 23 Jun 2016, Shannon Zhao wrote:
>>>>>> > >>>>From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>>> > >>>>
>>>>>> > >>>>Add a configuration option for ARM DomU so that user can deicde to use
>>>>>> > >>>>ACPI or not. This option is defaultly false.
>>>>>> > >>>>
>>>>>> > >>>>Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>>>> > >>>>---
>>>>>> > >>>>  tools/libxl/libxl_arm.c       | 3 +++
>>>>>> > >>>>  tools/libxl/libxl_types.idl   | 1 +
>>>>>> > >>>>  tools/libxl/xl_cmdimpl.c      | 4 ++++
>>>>>> > >>>>  xen/include/public/arch-arm.h | 1 +
>>>>>> > >>>>  4 files changed, 9 insertions(+)
>>>>>> > >>>>
>>>>>> > >>>>diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>>>>>> > >>>>index 8f15d9b..cc5a717 100644
>>>>>> > >>>>--- a/tools/libxl/libxl_arm.c
>>>>>> > >>>>+++ b/tools/libxl/libxl_arm.c
>>>>>> > >>>>@@ -77,6 +77,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>>>>>> > >>>>          return ERROR_FAIL;
>>>>>> > >>>>      }
>>>>>> > >>>>
>>>>>> > >>>>+    xc_config->acpi = libxl_defbool_val(d_config->b_info.arch_arm.acpi)
>>>>>> > >>>>+                      ? true : false;
>>>>>> > >>>>+
>>>>>> > >>>>      return 0;
>>>>>> > >>>>  }
>>>>>> > >>>>
>>>>>> > >>>>diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>>>>>> > >>>>index ef614be..426b868 100644
>>>>>> > >>>>--- a/tools/libxl/libxl_types.idl
>>>>>> > >>>>+++ b/tools/libxl/libxl_types.idl
>>>>>> > >>>>@@ -560,6 +560,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>>>>>> > >>>>
>>>>>> > >>>>
>>>>>> > >>>>      ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
>>>>>> > >>>>+                               ("acpi", libxl_defbool),
>>>>>> > >>>>                                ])),
>>>>>> > >>>>
>>>>>> > >>>>      ], dir=DIR_IN
>>>>>> > >>>>diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>>>>>> > >>>>index 6459eec..0634ffa 100644
>>>>>> > >>>>--- a/tools/libxl/xl_cmdimpl.c
>>>>>> > >>>>+++ b/tools/libxl/xl_cmdimpl.c
>>>>>> > >>>>@@ -2506,6 +2506,10 @@ skip_usbdev:
>>>>>> > >>>>          }
>>>>>> > >>>>       }
>>>>>> > >>>>
>>>>>> > >>>>+    if (xlu_cfg_get_defbool(config, "acpi", &b_info->arch_arm.acpi, 0)) {
>>>>>> > >>>>+        libxl_defbool_set(&b_info->arch_arm.acpi, 0);
>>>>>> > >>>>+    }
>>>> > >>We cannot share the existing code to parse the acpi paramter because
>>>> > >>that is saved in b_info->u.hvm.acpi, right?
>>> > >Yes.
>>>> > >>It's a pity. I wonder if we
>>>> > >>could refactor the existing code so that we can actually share the acpi
>>>> > >>parameter between x86 and arm.
>>>> > >>
>>> > >I have no idea about this since I'm not familiar with this. But is there
>>> > >any downsides of current way? Because for x86, it will use
>>> > >b_info->u.hvm.acpi and for ARM it will use b_info->arch_arm.acpi. I
>>> > >think they don't conflict even though we store it at two places.
>> > 
>> > Yes, there is a downside.  Toolstack, such as libvirt, would need to have
>> > separate code for x86 and ARM in order to enable/disable ACPI.
>> > 
>> > I would introduce a new generic acpi parameters, deprecate
>> > b_info->u.hvm.acpi. Ian, Stefano, Wei, any opinions?
>> > 
> Yeah, we can deprecate that field. But we need to take care to not break
> users of the old field.
Ok, what name would you suggest?

Thanks,
-- 
Shannon


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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Shannon Zhao]

On 2016/7/6 18:12, Stefano Stabellini wrote:
> On Wed, 6 Jul 2016, Julien Grall wrote:
>> > Hi Stefano,
>> > 
>> > On 05/07/16 18:13, Stefano Stabellini wrote:
>>> > > On Thu, 23 Jun 2016, Julien Grall wrote:
>>>> > > > On 23/06/2016 04:17, Shannon Zhao wrote:
>>>>> > > > > From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>> > > > > 
>>>>> > > > > Copy all the ACPI tables to guest space so that UEFI or guest could
>>>>> > > > > access them.
>>>>> > > > > 
>>>>> > > > > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>>> > > > > ---
>>>>> > > > >   tools/libxc/xc_dom_arm.c | 51
>>>>> > > > > ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> > > > >   1 file changed, 51 insertions(+)
>>>>> > > > > 
>>>>> > > > > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
>>>>> > > > > index 64a8b67..6a0a5b7 100644
>>>>> > > > > --- a/tools/libxc/xc_dom_arm.c
>>>>> > > > > +++ b/tools/libxc/xc_dom_arm.c
>>>>> > > > > @@ -63,6 +63,47 @@ static int setup_pgtables_arm(struct xc_dom_image
>>>>> > > > > *dom)
>>>>> > > > > 
>>>>> > > > >   /*
>>>>> > > > > ------------------------------------------------------------------------
>>>>> > > > > */
>>>>> > > > > 
>>>>> > > > > +static int xc_dom_copy_acpi(struct xc_dom_image *dom)
>>>>> > > > > +{
>>>>> > > > > +    int rc, i;
>>>>> > > > > +    uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
>>>>> > > > > +                         XC_PAGE_SHIFT;
>>>>> > > > > +    const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
>>>>> > > > > +    xen_pfn_t *p2m;
>>>>> > > > > +    void *acpi_pages;
>>>>> > > > > +
>>>>> > > > > +    p2m = malloc(pages_num * sizeof(*p2m));
>>>>> > > > > +    for (i = 0; i < pages_num; i++)
>>>>> > > > > +        p2m[i] = base + i;
>>>>> > > > > +
>>>>> > > > > +    rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
>>>>> > > > > +                                          pages_num, 0, 0, p2m);
>>>> > > > 
>>>> > > > Hmmmm... it looks like this is working because libxl is setting the
>>>> > > > maximum
>>>> > > > size of the domain with some slack (1MB). However, I guess the slack was
>>>> > > > for
>>>> > > > something else. Wei, Stefano, Ian, can you confirm?
>>> > > 
>>> > > If I recall correctly, the slack is a magic value coming from the
>>> > > ancient history of toolstacks.
>> > 
>> > Does it mean we would need to update the slack to take into account the ACPI
>> > blob?
> Yes, we need to take into account the ACPI blob. Probably not in the
> slack but directly in mam_memkb.
Sorry, I'm not sure understand this. I found the b_info->max_memkb but
didn't find the slack you said. And how to fix this? Update
b_info->max_memkb or the slack?

Thanks,
-- 
Shannon


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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Julien Grall]

Hi Shannon,

On 12/07/16 04:40, Shannon Zhao wrote:
>
>
> On 2016/7/7 23:30, Wei Liu wrote:
>> On Mon, Jun 27, 2016 at 11:40:32AM +0100, Julien Grall wrote:
>>>> On 23/06/16 15:34, Shannon Zhao wrote:
>>>>>> On 2016年06月23日 21:39, Stefano Stabellini wrote:
>>>>>>>> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>>>>>>>>>>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>>>>>>>>> +    if (xlu_cfg_get_defbool(config, "acpi", &b_info->arch_arm.acpi, 0)) {
>>>>>>>>>>>> +        libxl_defbool_set(&b_info->arch_arm.acpi, 0);
>>>>>>>>>>>> +    }
>>>>>>>> We cannot share the existing code to parse the acpi paramter because
>>>>>>>> that is saved in b_info->u.hvm.acpi, right?
>>>>>> Yes.
>>>>>>>> It's a pity. I wonder if we
>>>>>>>> could refactor the existing code so that we can actually share the acpi
>>>>>>>> parameter between x86 and arm.
>>>>>>>>
>>>>>> I have no idea about this since I'm not familiar with this. But is there
>>>>>> any downsides of current way? Because for x86, it will use
>>>>>> b_info->u.hvm.acpi and for ARM it will use b_info->arch_arm.acpi. I
>>>>>> think they don't conflict even though we store it at two places.
>>>>
>>>> Yes, there is a downside.  Toolstack, such as libvirt, would need to have
>>>> separate code for x86 and ARM in order to enable/disable ACPI.
>>>>
>>>> I would introduce a new generic acpi parameters, deprecate
>>>> b_info->u.hvm.acpi. Ian, Stefano, Wei, any opinions?
>>>>
>> Yeah, we can deprecate that field. But we need to take care to not break
>> users of the old field.
> Ok, what name would you suggest?

I would suggest b_info->u.acpi

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hi Shannon,

On 12/07/16 04:47, Shannon Zhao wrote:
> On 2016/7/6 18:12, Stefano Stabellini wrote:
>> On Wed, 6 Jul 2016, Julien Grall wrote:
>>>> On 05/07/16 18:13, Stefano Stabellini wrote:
>>>>>> On Thu, 23 Jun 2016, Julien Grall wrote:
>>>>>>>> On 23/06/2016 04:17, Shannon Zhao wrote:
>>>>>>>>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>>>>>>> +static int xc_dom_copy_acpi(struct xc_dom_image *dom)
>>>>>>>>>> +{
>>>>>>>>>> +    int rc, i;
>>>>>>>>>> +    uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
>>>>>>>>>> +                         XC_PAGE_SHIFT;
>>>>>>>>>> +    const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
>>>>>>>>>> +    xen_pfn_t *p2m;
>>>>>>>>>> +    void *acpi_pages;
>>>>>>>>>> +
>>>>>>>>>> +    p2m = malloc(pages_num * sizeof(*p2m));
>>>>>>>>>> +    for (i = 0; i < pages_num; i++)
>>>>>>>>>> +        p2m[i] = base + i;
>>>>>>>>>> +
>>>>>>>>>> +    rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
>>>>>>>>>> +                                          pages_num, 0, 0, p2m);
>>>>>>>>
>>>>>>>> Hmmmm... it looks like this is working because libxl is setting the
>>>>>>>> maximum
>>>>>>>> size of the domain with some slack (1MB). However, I guess the slack was
>>>>>>>> for
>>>>>>>> something else. Wei, Stefano, Ian, can you confirm?
>>>>>>
>>>>>> If I recall correctly, the slack is a magic value coming from the
>>>>>> ancient history of toolstacks.
>>>>
>>>> Does it mean we would need to update the slack to take into account the ACPI
>>>> blob?
>> Yes, we need to take into account the ACPI blob. Probably not in the
>> slack but directly in mam_memkb.
> Sorry, I'm not sure understand this. I found the b_info->max_memkb but
> didn't find the slack you said. And how to fix this? Update
> b_info->max_memkb or the slack?

You can give a look to LIBXL_MAXMEM_CONSTANT.

I am not very familiar with libxl, so I will let Wei and Stefano giving 
you advice on how to fix this.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Wei Liu]

On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
[...]
> >>Yeah, we can deprecate that field. But we need to take care to not break
> >>users of the old field.
> >Ok, what name would you suggest?
> 
> I would suggest b_info->u.acpi
> 

b_info->acpi would be more appropriate.

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ef614be..a57823d 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -494,11 +494,16 @@ libxl_domain_build_info = Struct("domain_build_info",[
     # Note that the partial device tree should avoid to use the phandle
     # 65000 which is reserved by the toolstack.
     ("device_tree",      string),
+    ("acpi",             libxl_defbool),
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
                                        ("bios",             libxl_bios_type),
                                        ("pae",              libxl_defbool),
                                        ("apic",             libxl_defbool),
+                                       # The following acpi field is
+                                       # deprecated. Please use the unified
+                                       # acpi field above which works for both
+                                       # x86 and ARM.
                                        ("acpi",             libxl_defbool),
                                        ("acpi_s3",          libxl_defbool),
                                        ("acpi_s4",          libxl_defbool),


And then:

1. modify xl to set the new field.
2. modify libxl to handle compatibility: user of the old field should
   continue to work.

I know this is a bit terse. Feel free to ask questions if you have any
doubt.

Wei.

> Regards,
> 
> -- 
> Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Tue, Jul 12, 2016 at 11:47:04AM +0800, Shannon Zhao wrote:
> 
> 
> On 2016/7/6 18:12, Stefano Stabellini wrote:
> > On Wed, 6 Jul 2016, Julien Grall wrote:
> >> > Hi Stefano,
> >> > 
> >> > On 05/07/16 18:13, Stefano Stabellini wrote:
> >>> > > On Thu, 23 Jun 2016, Julien Grall wrote:
> >>>> > > > On 23/06/2016 04:17, Shannon Zhao wrote:
> >>>>> > > > > From: Shannon Zhao <shannon.zhao@linaro.org>
> >>>>> > > > > 
> >>>>> > > > > Copy all the ACPI tables to guest space so that UEFI or guest could
> >>>>> > > > > access them.
> >>>>> > > > > 
> >>>>> > > > > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> >>>>> > > > > ---
> >>>>> > > > >   tools/libxc/xc_dom_arm.c | 51
> >>>>> > > > > ++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>> > > > >   1 file changed, 51 insertions(+)
> >>>>> > > > > 
> >>>>> > > > > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> >>>>> > > > > index 64a8b67..6a0a5b7 100644
> >>>>> > > > > --- a/tools/libxc/xc_dom_arm.c
> >>>>> > > > > +++ b/tools/libxc/xc_dom_arm.c
> >>>>> > > > > @@ -63,6 +63,47 @@ static int setup_pgtables_arm(struct xc_dom_image
> >>>>> > > > > *dom)
> >>>>> > > > > 
> >>>>> > > > >   /*
> >>>>> > > > > ------------------------------------------------------------------------
> >>>>> > > > > */
> >>>>> > > > > 
> >>>>> > > > > +static int xc_dom_copy_acpi(struct xc_dom_image *dom)
> >>>>> > > > > +{
> >>>>> > > > > +    int rc, i;
> >>>>> > > > > +    uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
> >>>>> > > > > +                         XC_PAGE_SHIFT;
> >>>>> > > > > +    const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
> >>>>> > > > > +    xen_pfn_t *p2m;
> >>>>> > > > > +    void *acpi_pages;
> >>>>> > > > > +
> >>>>> > > > > +    p2m = malloc(pages_num * sizeof(*p2m));
> >>>>> > > > > +    for (i = 0; i < pages_num; i++)
> >>>>> > > > > +        p2m[i] = base + i;
> >>>>> > > > > +
> >>>>> > > > > +    rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
> >>>>> > > > > +                                          pages_num, 0, 0, p2m);
> >>>> > > > 
> >>>> > > > Hmmmm... it looks like this is working because libxl is setting the
> >>>> > > > maximum
> >>>> > > > size of the domain with some slack (1MB). However, I guess the slack was
> >>>> > > > for
> >>>> > > > something else. Wei, Stefano, Ian, can you confirm?
> >>> > > 
> >>> > > If I recall correctly, the slack is a magic value coming from the
> >>> > > ancient history of toolstacks.
> >> > 
> >> > Does it mean we would need to update the slack to take into account the ACPI
> >> > blob?
> > Yes, we need to take into account the ACPI blob. Probably not in the
> > slack but directly in mam_memkb.
> Sorry, I'm not sure understand this. I found the b_info->max_memkb but
> didn't find the slack you said. And how to fix this? Update
> b_info->max_memkb or the slack?

Can you calculate the size of your payload and add that to max_memkb?

Don't bump the slack.

Wei.

> 
> Thanks,
> -- 
> Shannon
> 

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Shannon Zhao]

On 2016年07月12日 19:33, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
> [...]
>>>> > >>Yeah, we can deprecate that field. But we need to take care to not break
>>>> > >>users of the old field.
>>> > >Ok, what name would you suggest?
>> > 
>> > I would suggest b_info->u.acpi
>> > 
> b_info->acpi would be more appropriate.
> 
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index ef614be..a57823d 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -494,11 +494,16 @@ libxl_domain_build_info = Struct("domain_build_info",[
>      # Note that the partial device tree should avoid to use the phandle
>      # 65000 which is reserved by the toolstack.
>      ("device_tree",      string),
> +    ("acpi",             libxl_defbool),
>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>                  [("hvm", Struct(None, [("firmware",         string),
>                                         ("bios",             libxl_bios_type),
>                                         ("pae",              libxl_defbool),
>                                         ("apic",             libxl_defbool),
> +                                       # The following acpi field is
> +                                       # deprecated. Please use the unified
> +                                       # acpi field above which works for both
> +                                       # x86 and ARM.
>                                         ("acpi",             libxl_defbool),
>                                         ("acpi_s3",          libxl_defbool),
>                                         ("acpi_s4",          libxl_defbool),
> 
> 
> And then:
> 
> 1. modify xl to set the new field.
> 2. modify libxl to handle compatibility: user of the old field should
>    continue to work.
> 
> I know this is a bit terse. Feel free to ask questions if you have any
> doubt.
I'm not sure I understand correctly. While xl is always matching libxl,
so can we just let xl set the new field and libxl to use the new field?
To users, they will still use the configure option "acpi".

Thanks,
-- 
Shannon

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Wei Liu]

On Tue, Jul 12, 2016 at 10:17:20PM +0800, Shannon Zhao wrote:
> On 2016年07月12日 19:33, Wei Liu wrote:
> > On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
> > [...]
> >>>> > >>Yeah, we can deprecate that field. But we need to take care to not break
> >>>> > >>users of the old field.
> >>> > >Ok, what name would you suggest?
> >> > 
> >> > I would suggest b_info->u.acpi
> >> > 
> > b_info->acpi would be more appropriate.
> > 
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index ef614be..a57823d 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -494,11 +494,16 @@ libxl_domain_build_info = Struct("domain_build_info",[
> >      # Note that the partial device tree should avoid to use the phandle
> >      # 65000 which is reserved by the toolstack.
> >      ("device_tree",      string),
> > +    ("acpi",             libxl_defbool),
> >      ("u", KeyedUnion(None, libxl_domain_type, "type",
> >                  [("hvm", Struct(None, [("firmware",         string),
> >                                         ("bios",             libxl_bios_type),
> >                                         ("pae",              libxl_defbool),
> >                                         ("apic",             libxl_defbool),
> > +                                       # The following acpi field is
> > +                                       # deprecated. Please use the unified
> > +                                       # acpi field above which works for both
> > +                                       # x86 and ARM.
> >                                         ("acpi",             libxl_defbool),
> >                                         ("acpi_s3",          libxl_defbool),
> >                                         ("acpi_s4",          libxl_defbool),
> > 
> > 
> > And then:
> > 
> > 1. modify xl to set the new field.
> > 2. modify libxl to handle compatibility: user of the old field should
> >    continue to work.
> > 
> > I know this is a bit terse. Feel free to ask questions if you have any
> > doubt.
> I'm not sure I understand correctly. While xl is always matching libxl,
> so can we just let xl set the new field and libxl to use the new field?
> To users, they will still use the configure option "acpi".
> 

We need to distinguish between the library to control Xen (libxl) and
the user of that library (xl). Xl is just one of the possibly users of
libxl. For example, libvirt uses libxl APIs without involving xl at all,
hence my second point.

Wei.

> Thanks,
> -- 
> Shannon

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Shannon Zhao]

On 2016年07月12日 19:35, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 11:47:04AM +0800, Shannon Zhao wrote:
>> > 
>> > 
>> > On 2016/7/6 18:12, Stefano Stabellini wrote:
>>> > > On Wed, 6 Jul 2016, Julien Grall wrote:
>>>>> > >> > Hi Stefano,
>>>>> > >> > 
>>>>> > >> > On 05/07/16 18:13, Stefano Stabellini wrote:
>>>>>>> > >>> > > On Thu, 23 Jun 2016, Julien Grall wrote:
>>>>>>>>> > >>>> > > > On 23/06/2016 04:17, Shannon Zhao wrote:
>>>>>>>>>>> > >>>>> > > > > From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>>>>>>>> > >>>>> > > > > 
>>>>>>>>>>> > >>>>> > > > > Copy all the ACPI tables to guest space so that UEFI or guest could
>>>>>>>>>>> > >>>>> > > > > access them.
>>>>>>>>>>> > >>>>> > > > > 
>>>>>>>>>>> > >>>>> > > > > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>>>>>>>>>>> > >>>>> > > > > ---
>>>>>>>>>>> > >>>>> > > > >   tools/libxc/xc_dom_arm.c | 51
>>>>>>>>>>> > >>>>> > > > > ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>>>>> > >>>>> > > > >   1 file changed, 51 insertions(+)
>>>>>>>>>>> > >>>>> > > > > 
>>>>>>>>>>> > >>>>> > > > > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
>>>>>>>>>>> > >>>>> > > > > index 64a8b67..6a0a5b7 100644
>>>>>>>>>>> > >>>>> > > > > --- a/tools/libxc/xc_dom_arm.c
>>>>>>>>>>> > >>>>> > > > > +++ b/tools/libxc/xc_dom_arm.c
>>>>>>>>>>> > >>>>> > > > > @@ -63,6 +63,47 @@ static int setup_pgtables_arm(struct xc_dom_image
>>>>>>>>>>> > >>>>> > > > > *dom)
>>>>>>>>>>> > >>>>> > > > > 
>>>>>>>>>>> > >>>>> > > > >   /*
>>>>>>>>>>> > >>>>> > > > > ------------------------------------------------------------------------
>>>>>>>>>>> > >>>>> > > > > */
>>>>>>>>>>> > >>>>> > > > > 
>>>>>>>>>>> > >>>>> > > > > +static int xc_dom_copy_acpi(struct xc_dom_image *dom)
>>>>>>>>>>> > >>>>> > > > > +{
>>>>>>>>>>> > >>>>> > > > > +    int rc, i;
>>>>>>>>>>> > >>>>> > > > > +    uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
>>>>>>>>>>> > >>>>> > > > > +                         XC_PAGE_SHIFT;
>>>>>>>>>>> > >>>>> > > > > +    const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
>>>>>>>>>>> > >>>>> > > > > +    xen_pfn_t *p2m;
>>>>>>>>>>> > >>>>> > > > > +    void *acpi_pages;
>>>>>>>>>>> > >>>>> > > > > +
>>>>>>>>>>> > >>>>> > > > > +    p2m = malloc(pages_num * sizeof(*p2m));
>>>>>>>>>>> > >>>>> > > > > +    for (i = 0; i < pages_num; i++)
>>>>>>>>>>> > >>>>> > > > > +        p2m[i] = base + i;
>>>>>>>>>>> > >>>>> > > > > +
>>>>>>>>>>> > >>>>> > > > > +    rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
>>>>>>>>>>> > >>>>> > > > > +                                          pages_num, 0, 0, p2m);
>>>>>>>>> > >>>> > > > 
>>>>>>>>> > >>>> > > > Hmmmm... it looks like this is working because libxl is setting the
>>>>>>>>> > >>>> > > > maximum
>>>>>>>>> > >>>> > > > size of the domain with some slack (1MB). However, I guess the slack was
>>>>>>>>> > >>>> > > > for
>>>>>>>>> > >>>> > > > something else. Wei, Stefano, Ian, can you confirm?
>>>>>>> > >>> > > 
>>>>>>> > >>> > > If I recall correctly, the slack is a magic value coming from the
>>>>>>> > >>> > > ancient history of toolstacks.
>>>>> > >> > 
>>>>> > >> > Does it mean we would need to update the slack to take into account the ACPI
>>>>> > >> > blob?
>>> > > Yes, we need to take into account the ACPI blob. Probably not in the
>>> > > slack but directly in mam_memkb.
>> > Sorry, I'm not sure understand this. I found the b_info->max_memkb but
>> > didn't find the slack you said. And how to fix this? Update
>> > b_info->max_memkb or the slack?
> Can you calculate the size of your payload and add that to max_memkb?
> 
Yeah, but the size will be changed if we change the tables in the future
and this also should consider x86, right?

Thanks,
-- 
Shannon

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Shannon Zhao]

On 2016年07月12日 22:33, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 10:17:20PM +0800, Shannon Zhao wrote:
>> > On 2016年07月12日 19:33, Wei Liu wrote:
>>> > > On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
>>> > > [...]
>>>>>>>>> > >>>> > >>Yeah, we can deprecate that field. But we need to take care to not break
>>>>>>>>> > >>>> > >>users of the old field.
>>>>>>> > >>> > >Ok, what name would you suggest?
>>>>> > >> > 
>>>>> > >> > I would suggest b_info->u.acpi
>>>>> > >> > 
>>> > > b_info->acpi would be more appropriate.
>>> > > 
>>> > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>>> > > index ef614be..a57823d 100644
>>> > > --- a/tools/libxl/libxl_types.idl
>>> > > +++ b/tools/libxl/libxl_types.idl
>>> > > @@ -494,11 +494,16 @@ libxl_domain_build_info = Struct("domain_build_info",[
>>> > >      # Note that the partial device tree should avoid to use the phandle
>>> > >      # 65000 which is reserved by the toolstack.
>>> > >      ("device_tree",      string),
>>> > > +    ("acpi",             libxl_defbool),
>>> > >      ("u", KeyedUnion(None, libxl_domain_type, "type",
>>> > >                  [("hvm", Struct(None, [("firmware",         string),
>>> > >                                         ("bios",             libxl_bios_type),
>>> > >                                         ("pae",              libxl_defbool),
>>> > >                                         ("apic",             libxl_defbool),
>>> > > +                                       # The following acpi field is
>>> > > +                                       # deprecated. Please use the unified
>>> > > +                                       # acpi field above which works for both
>>> > > +                                       # x86 and ARM.
>>> > >                                         ("acpi",             libxl_defbool),
>>> > >                                         ("acpi_s3",          libxl_defbool),
>>> > >                                         ("acpi_s4",          libxl_defbool),
>>> > > 
>>> > > 
>>> > > And then:
>>> > > 
>>> > > 1. modify xl to set the new field.
>>> > > 2. modify libxl to handle compatibility: user of the old field should
>>> > >    continue to work.
>>> > > 
>>> > > I know this is a bit terse. Feel free to ask questions if you have any
>>> > > doubt.
>> > I'm not sure I understand correctly. While xl is always matching libxl,
>> > so can we just let xl set the new field and libxl to use the new field?
>> > To users, they will still use the configure option "acpi".
>> > 
> We need to distinguish between the library to control Xen (libxl) and
> the user of that library (xl). Xl is just one of the possibly users of
> libxl. For example, libvirt uses libxl APIs without involving xl at all,
> hence my second point.
Oh, I see. Thanks for the clarification.

-- 
Shannon

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
> >>>>> > >> > 
> >>>>> > >> > Does it mean we would need to update the slack to take into account the ACPI
> >>>>> > >> > blob?
> >>> > > Yes, we need to take into account the ACPI blob. Probably not in the
> >>> > > slack but directly in mam_memkb.
> >> > Sorry, I'm not sure understand this. I found the b_info->max_memkb but
> >> > didn't find the slack you said. And how to fix this? Update
> >> > b_info->max_memkb or the slack?
> > Can you calculate the size of your payload and add that to max_memkb?
> > 
> Yeah, but the size will be changed if we change the tables in the future
> and this also should consider x86, right?

That could easily be solved by introducing a function to calculate the
size, right?

Wei.

> 
> Thanks,
> -- 
> Shannon

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Shannon Zhao]

On 2016年07月12日 22:50, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
>>>>>>>>>>> > >>>>> > >> > 
>>>>>>>>>>> > >>>>> > >> > Does it mean we would need to update the slack to take into account the ACPI
>>>>>>>>>>> > >>>>> > >> > blob?
>>>>>>> > >>> > > Yes, we need to take into account the ACPI blob. Probably not in the
>>>>>>> > >>> > > slack but directly in mam_memkb.
>>>>> > >> > Sorry, I'm not sure understand this. I found the b_info->max_memkb but
>>>>> > >> > didn't find the slack you said. And how to fix this? Update
>>>>> > >> > b_info->max_memkb or the slack?
>>> > > Can you calculate the size of your payload and add that to max_memkb?
>>> > > 
>> > Yeah, but the size will be changed if we change the tables in the future
>> > and this also should consider x86, right?
> That could easily be solved by introducing a function to calculate the
> size, right?
Oh, I'm not familiar with this. Let's clarify on this. It can add the
size to max_memkb after generating the ACPI tables and before loading
the tables to guest space and it doesn't have to add the size at
libxl__domain_build_info_setdefault(), right?

Thanks,
-- 
Shannon

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky]

On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> On 2016年07月12日 22:50, Wei Liu wrote:
>> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
>>>>>>>>>>>>>>>>>>>>>> Does it mean we would need to update the slack to take into account the ACPI
>>>>>>>>>>>>>>>>>>>>>> blob?
>>>>>>>>>>>>>> Yes, we need to take into account the ACPI blob. Probably not in the
>>>>>>>>>>>>>> slack but directly in mam_memkb.
>>>>>>>>>> Sorry, I'm not sure understand this. I found the b_info->max_memkb but
>>>>>>>>>> didn't find the slack you said. And how to fix this? Update
>>>>>>>>>> b_info->max_memkb or the slack?
>>>>>> Can you calculate the size of your payload and add that to max_memkb?
>>>>>>
>>>> Yeah, but the size will be changed if we change the tables in the future
>>>> and this also should consider x86, right?
>> That could easily be solved by introducing a function to calculate the
>> size, right?
> Oh, I'm not familiar with this. Let's clarify on this. It can add the
> size to max_memkb after generating the ACPI tables and before loading
> the tables to guest space and it doesn't have to add the size at
> libxl__domain_build_info_setdefault(), right?

This was discussed before: ACPI tables are part of RAM whose size is
specified by the config file (and is reflected in max_memkb I believe).
It may not be presented to the guest as RAM (i.e. on x86 it is labeled
by BIOS (or whoever) as a dedicated type in e820) but it still resides
in DIMMs.

I believe we should not increase memory resources for ACPI tables.

-boris





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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Tue, Jul 12, 2016 at 11:08:47AM -0400, Boris Ostrovsky wrote:
> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> > On 2016年07月12日 22:50, Wei Liu wrote:
> >> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
> >>>>>>>>>>>>>>>>>>>>>> Does it mean we would need to update the slack to take into account the ACPI
> >>>>>>>>>>>>>>>>>>>>>> blob?
> >>>>>>>>>>>>>> Yes, we need to take into account the ACPI blob. Probably not in the
> >>>>>>>>>>>>>> slack but directly in mam_memkb.
> >>>>>>>>>> Sorry, I'm not sure understand this. I found the b_info->max_memkb but
> >>>>>>>>>> didn't find the slack you said. And how to fix this? Update
> >>>>>>>>>> b_info->max_memkb or the slack?
> >>>>>> Can you calculate the size of your payload and add that to max_memkb?
> >>>>>>
> >>>> Yeah, but the size will be changed if we change the tables in the future
> >>>> and this also should consider x86, right?
> >> That could easily be solved by introducing a function to calculate the
> >> size, right?
> > Oh, I'm not familiar with this. Let's clarify on this. It can add the
> > size to max_memkb after generating the ACPI tables and before loading
> > the tables to guest space and it doesn't have to add the size at
> > libxl__domain_build_info_setdefault(), right?
> 

Hmm... I would like to think a bit more about this. But before dwelling
on this too much...

> This was discussed before: ACPI tables are part of RAM whose size is
> specified by the config file (and is reflected in max_memkb I believe).
> It may not be presented to the guest as RAM (i.e. on x86 it is labeled
> by BIOS (or whoever) as a dedicated type in e820) but it still resides
> in DIMMs.
> 
> I believe we should not increase memory resources for ACPI tables.
> 

This is an interesting point. If there is already such resolution I will
be happy to follow it.

Any reference?

Wei.

> -boris
> 
> 
> 
> 

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky]

On 07/12/2016 11:13 AM, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 11:08:47AM -0400, Boris Ostrovsky wrote:
>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>> On 2016年07月12日 22:50, Wei Liu wrote:
>>>> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Does it mean we would need to update the slack to take into account the ACPI
>>>>>>>>>>>>>>>>>>>>>>>> blob?
>>>>>>>>>>>>>>>> Yes, we need to take into account the ACPI blob. Probably not in the
>>>>>>>>>>>>>>>> slack but directly in mam_memkb.
>>>>>>>>>>>> Sorry, I'm not sure understand this. I found the b_info->max_memkb but
>>>>>>>>>>>> didn't find the slack you said. And how to fix this? Update
>>>>>>>>>>>> b_info->max_memkb or the slack?
>>>>>>>> Can you calculate the size of your payload and add that to max_memkb?
>>>>>>>>
>>>>>> Yeah, but the size will be changed if we change the tables in the future
>>>>>> and this also should consider x86, right?
>>>> That could easily be solved by introducing a function to calculate the
>>>> size, right?
>>> Oh, I'm not familiar with this. Let's clarify on this. It can add the
>>> size to max_memkb after generating the ACPI tables and before loading
>>> the tables to guest space and it doesn't have to add the size at
>>> libxl__domain_build_info_setdefault(), right?
> Hmm... I would like to think a bit more about this. But before dwelling
> on this too much...
>
>> This was discussed before: ACPI tables are part of RAM whose size is
>> specified by the config file (and is reflected in max_memkb I believe).
>> It may not be presented to the guest as RAM (i.e. on x86 it is labeled
>> by BIOS (or whoever) as a dedicated type in e820) but it still resides
>> in DIMMs.
>>
>> I believe we should not increase memory resources for ACPI tables.
>>
> This is an interesting point. If there is already such resolution I will
> be happy to follow it.
>
> Any reference?

The last one (that I can find) is
   
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00821.html

(conveniently in the same thread is the one we have been using to talk
about licensing)

-boris



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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Tue, Jul 12, 2016 at 11:21:12AM -0400, Boris Ostrovsky wrote:
> On 07/12/2016 11:13 AM, Wei Liu wrote:
> > On Tue, Jul 12, 2016 at 11:08:47AM -0400, Boris Ostrovsky wrote:
> >> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> >>> On 2016年07月12日 22:50, Wei Liu wrote:
> >>>> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> Does it mean we would need to update the slack to take into account the ACPI
> >>>>>>>>>>>>>>>>>>>>>>>> blob?
> >>>>>>>>>>>>>>>> Yes, we need to take into account the ACPI blob. Probably not in the
> >>>>>>>>>>>>>>>> slack but directly in mam_memkb.
> >>>>>>>>>>>> Sorry, I'm not sure understand this. I found the b_info->max_memkb but
> >>>>>>>>>>>> didn't find the slack you said. And how to fix this? Update
> >>>>>>>>>>>> b_info->max_memkb or the slack?
> >>>>>>>> Can you calculate the size of your payload and add that to max_memkb?
> >>>>>>>>
> >>>>>> Yeah, but the size will be changed if we change the tables in the future
> >>>>>> and this also should consider x86, right?
> >>>> That could easily be solved by introducing a function to calculate the
> >>>> size, right?
> >>> Oh, I'm not familiar with this. Let's clarify on this. It can add the
> >>> size to max_memkb after generating the ACPI tables and before loading
> >>> the tables to guest space and it doesn't have to add the size at
> >>> libxl__domain_build_info_setdefault(), right?
> > Hmm... I would like to think a bit more about this. But before dwelling
> > on this too much...
> >
> >> This was discussed before: ACPI tables are part of RAM whose size is
> >> specified by the config file (and is reflected in max_memkb I believe).
> >> It may not be presented to the guest as RAM (i.e. on x86 it is labeled
> >> by BIOS (or whoever) as a dedicated type in e820) but it still resides
> >> in DIMMs.
> >>
> >> I believe we should not increase memory resources for ACPI tables.
> >>
> > This is an interesting point. If there is already such resolution I will
> > be happy to follow it.
> >
> > Any reference?
> 
> The last one (that I can find) is
>    
> https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00821.html
> 
> (conveniently in the same thread is the one we have been using to talk
> about licensing)
> 

Ah, OK.

Shannon, you don't need to modify max_memkb then. 

Wei.

> -boris
> 
> 

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hello,

On 12/07/2016 16:08, Boris Ostrovsky wrote:
> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>> On 2016年07月12日 22:50, Wei Liu wrote:
>>> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
>>>>>>>>>>>>>>>>>>>>>>> Does it mean we would need to update the slack to take into account the ACPI
>>>>>>>>>>>>>>>>>>>>>>> blob?
>>>>>>>>>>>>>>> Yes, we need to take into account the ACPI blob. Probably not in the
>>>>>>>>>>>>>>> slack but directly in mam_memkb.
>>>>>>>>>>> Sorry, I'm not sure understand this. I found the b_info->max_memkb but
>>>>>>>>>>> didn't find the slack you said. And how to fix this? Update
>>>>>>>>>>> b_info->max_memkb or the slack?
>>>>>>> Can you calculate the size of your payload and add that to max_memkb?
>>>>>>>
>>>>> Yeah, but the size will be changed if we change the tables in the future
>>>>> and this also should consider x86, right?
>>> That could easily be solved by introducing a function to calculate the
>>> size, right?
>> Oh, I'm not familiar with this. Let's clarify on this. It can add the
>> size to max_memkb after generating the ACPI tables and before loading
>> the tables to guest space and it doesn't have to add the size at
>> libxl__domain_build_info_setdefault(), right?
>
> This was discussed before: ACPI tables are part of RAM whose size is
> specified by the config file (and is reflected in max_memkb I believe).
> It may not be presented to the guest as RAM (i.e. on x86 it is labeled
> by BIOS (or whoever) as a dedicated type in e820) but it still resides
> in DIMMs.

I don't think this was the conclusion of the thread. IHMO, "maxmem" is 
the amount of RAM a guest could effectively use.

Whilst the ACPI tables will be in the DIMM from the host point of view. 
 From a guest point of view it will be a ROM.

It will affect some others part of the guest if we don't increment the 
"maxmem" requested by the user. For ARM the ACPI blob will be exposed at 
a specific address that is outside of the guest RAM (see the guest 
memory layout in public/arch-arm.h).

We chose this solution over putting in the RAM because the ACPI tables 
are not easily relocatable (compare to the device tree, initrd and 
kernel) so we could not take advantage of superpage in both stage-2 
(hypervisor) and stage-1 (kernel) page table.

To give you a concrete example. When the user requests 1 gigabytes of 
memory, Xen will try to allocate a 1 gigabytes superpage.

If few kilobytes is removed from this 1 gigabytes, then we would have to 
use 2MB superpage which will impact both performance and memory usage.

So I think we should take into account the size of the ACPI blob in 
libxl and not reduce the memory requested by the user.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky]

On 07/12/2016 12:10 PM, Julien Grall wrote:
> Hello,
>
> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>> On 2016年07月12日 22:50, Wei Liu wrote:
>>>> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Does it mean we would need to update the slack
>>>>>>>>>>>>>>>>>>>>>>>> to take into account the ACPI
>>>>>>>>>>>>>>>>>>>>>>>> blob?
>>>>>>>>>>>>>>>> Yes, we need to take into account the ACPI blob.
>>>>>>>>>>>>>>>> Probably not in the
>>>>>>>>>>>>>>>> slack but directly in mam_memkb.
>>>>>>>>>>>> Sorry, I'm not sure understand this. I found the
>>>>>>>>>>>> b_info->max_memkb but
>>>>>>>>>>>> didn't find the slack you said. And how to fix this? Update
>>>>>>>>>>>> b_info->max_memkb or the slack?
>>>>>>>> Can you calculate the size of your payload and add that to
>>>>>>>> max_memkb?
>>>>>>>>
>>>>>> Yeah, but the size will be changed if we change the tables in the
>>>>>> future
>>>>>> and this also should consider x86, right?
>>>> That could easily be solved by introducing a function to calculate the
>>>> size, right?
>>> Oh, I'm not familiar with this. Let's clarify on this. It can add the
>>> size to max_memkb after generating the ACPI tables and before loading
>>> the tables to guest space and it doesn't have to add the size at
>>> libxl__domain_build_info_setdefault(), right?
>>
>> This was discussed before: ACPI tables are part of RAM whose size is
>> specified by the config file (and is reflected in max_memkb I believe).
>> It may not be presented to the guest as RAM (i.e. on x86 it is labeled
>> by BIOS (or whoever) as a dedicated type in e820) but it still resides
>> in DIMMs.
>
> I don't think this was the conclusion of the thread. IHMO, "maxmem" is
> the amount of RAM a guest could effectively use.
>
> Whilst the ACPI tables will be in the DIMM from the host point of
> view. From a guest point of view it will be a ROM.

The config file specifies resources provided by the host. How the guest
views those resources is not important, I think.

>
> It will affect some others part of the guest if we don't increment the
> "maxmem" requested by the user. For ARM the ACPI blob will be exposed
> at a specific address that is outside of the guest RAM (see the guest
> memory layout in public/arch-arm.h).
>
> We chose this solution over putting in the RAM because the ACPI tables
> are not easily relocatable (compare to the device tree, initrd and
> kernel) so we could not take advantage of superpage in both stage-2
> (hypervisor) and stage-1 (kernel) page table.

Maybe this is something ARM-specific then. For x86 we will want to keep
maxmem unchanged.

-boris


>
> To give you a concrete example. When the user requests 1 gigabytes of
> memory, Xen will try to allocate a 1 gigabytes superpage.
>
> If few kilobytes is removed from this 1 gigabytes, then we would have
> to use 2MB superpage which will impact both performance and memory usage.
>
> So I think we should take into account the size of the ACPI blob in
> libxl and not reduce the memory requested by the user.
>
> Regards,
>



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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Shannon Zhao]

On 2016/7/12 19:33, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
> [...]
>>>> Yeah, we can deprecate that field. But we need to take care to not break
>>>> users of the old field.
>>> Ok, what name would you suggest?
>>
>> I would suggest b_info->u.acpi
>>
> 
> b_info->acpi would be more appropriate.
> 
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index ef614be..a57823d 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -494,11 +494,16 @@ libxl_domain_build_info = Struct("domain_build_info",[
>      # Note that the partial device tree should avoid to use the phandle
>      # 65000 which is reserved by the toolstack.
>      ("device_tree",      string),
> +    ("acpi",             libxl_defbool),
>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>                  [("hvm", Struct(None, [("firmware",         string),
>                                         ("bios",             libxl_bios_type),
>                                         ("pae",              libxl_defbool),
>                                         ("apic",             libxl_defbool),
> +                                       # The following acpi field is
> +                                       # deprecated. Please use the unified
> +                                       # acpi field above which works for both
> +                                       # x86 and ARM.
>                                         ("acpi",             libxl_defbool),
>                                         ("acpi_s3",          libxl_defbool),
>                                         ("acpi_s4",          libxl_defbool),
> 
> 
> And then:
> 
> 1. modify xl to set the new field.
> 2. modify libxl to handle compatibility: user of the old field should
>    continue to work.
> 
I found that the default value of acpi is true on x86. But we decided
before it's should be false by default on ARM. How to deal with this?
Julien, Stefano, can we make acpi true by default?

Thanks,
-- 
Shannon


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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Julien Grall]

Hi Shannon,

On 13/07/2016 08:54, Shannon Zhao wrote:
> On 2016/7/12 19:33, Wei Liu wrote:
>> On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
>> [...]
>>>>> Yeah, we can deprecate that field. But we need to take care to not break
>>>>> users of the old field.
>>>> Ok, what name would you suggest?
>>>
>>> I would suggest b_info->u.acpi
>>>
>>
>> b_info->acpi would be more appropriate.
>>
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> index ef614be..a57823d 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -494,11 +494,16 @@ libxl_domain_build_info = Struct("domain_build_info",[
>>      # Note that the partial device tree should avoid to use the phandle
>>      # 65000 which is reserved by the toolstack.
>>      ("device_tree",      string),
>> +    ("acpi",             libxl_defbool),
>>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>>                  [("hvm", Struct(None, [("firmware",         string),
>>                                         ("bios",             libxl_bios_type),
>>                                         ("pae",              libxl_defbool),
>>                                         ("apic",             libxl_defbool),
>> +                                       # The following acpi field is
>> +                                       # deprecated. Please use the unified
>> +                                       # acpi field above which works for both
>> +                                       # x86 and ARM.
>>                                         ("acpi",             libxl_defbool),
>>                                         ("acpi_s3",          libxl_defbool),
>>                                         ("acpi_s4",          libxl_defbool),
>>
>>
>> And then:
>>
>> 1. modify xl to set the new field.
>> 2. modify libxl to handle compatibility: user of the old field should
>>    continue to work.
>>
> I found that the default value of acpi is true on x86. But we decided
> before it's should be false by default on ARM. How to deal with this?
> Julien, Stefano, can we make acpi true by default?

I already said that I am not in favor of making ACPI true by default at 
least for ARM 32-bit guest.

ARM 32-bit guest will not use ACPI, if we decide to enable it by 
default, we will require the user to install iasl for nothing.

IHMO, ACPI should be disabled by default for any ARM guests. Libxl can 
take this decision easily.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Shannon Zhao]

On 2016/7/13 17:20, Julien Grall wrote:
> On 13/07/2016 08:54, Shannon Zhao wrote:
>> On 2016/7/12 19:33, Wei Liu wrote:
>>> On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
>>> [...]
>>>>>> Yeah, we can deprecate that field. But we need to take care to not
>>>>>> break
>>>>>> users of the old field.
>>>>> Ok, what name would you suggest?
>>>>
>>>> I would suggest b_info->u.acpi
>>>>
>>>
>>> b_info->acpi would be more appropriate.
>>>
>>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>>> index ef614be..a57823d 100644
>>> --- a/tools/libxl/libxl_types.idl
>>> +++ b/tools/libxl/libxl_types.idl
>>> @@ -494,11 +494,16 @@ libxl_domain_build_info =
>>> Struct("domain_build_info",[
>>>      # Note that the partial device tree should avoid to use the phandle
>>>      # 65000 which is reserved by the toolstack.
>>>      ("device_tree",      string),
>>> +    ("acpi",             libxl_defbool),
>>>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>>>                  [("hvm", Struct(None, [("firmware",         string),
>>>                                         ("bios",            
>>> libxl_bios_type),
>>>                                         ("pae",             
>>> libxl_defbool),
>>>                                         ("apic",            
>>> libxl_defbool),
>>> +                                       # The following acpi field is
>>> +                                       # deprecated. Please use the
>>> unified
>>> +                                       # acpi field above which
>>> works for both
>>> +                                       # x86 and ARM.
>>>                                         ("acpi",            
>>> libxl_defbool),
>>>                                         ("acpi_s3",         
>>> libxl_defbool),
>>>                                         ("acpi_s4",         
>>> libxl_defbool),
>>>
>>>
>>> And then:
>>>
>>> 1. modify xl to set the new field.
>>> 2. modify libxl to handle compatibility: user of the old field should
>>>    continue to work.
>>>
>> I found that the default value of acpi is true on x86. But we decided
>> before it's should be false by default on ARM. How to deal with this?
>> Julien, Stefano, can we make acpi true by default?
> 
> I already said that I am not in favor of making ACPI true by default at
> least for ARM 32-bit guest.
> 
> ARM 32-bit guest will not use ACPI, if we decide to enable it by
> default, we will require the user to install iasl for nothing.
> 
> IHMO, ACPI should be disabled by default for any ARM guests. Libxl can
> take this decision easily.
I know but here we want to unify the acpi option for x86 and ARM while
on x86 it's true by default. What I want to ask is that how to
distinguish x86 and ARM in libxl__domain_build_info_setdefault(), so we
can assign acpi with different default value for x86 and ARM.

Thanks,
-- 
Shannon


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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Julien Grall]

On 13/07/2016 10:48, Shannon Zhao wrote:
>
>
> On 2016/7/13 17:20, Julien Grall wrote:
>> On 13/07/2016 08:54, Shannon Zhao wrote:
>>> On 2016/7/12 19:33, Wei Liu wrote:
>>>> On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
>>>> [...]
>>>>>>> Yeah, we can deprecate that field. But we need to take care to not
>>>>>>> break
>>>>>>> users of the old field.
>>>>>> Ok, what name would you suggest?
>>>>>
>>>>> I would suggest b_info->u.acpi
>>>>>
>>>>
>>>> b_info->acpi would be more appropriate.
>>>>
>>>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>>>> index ef614be..a57823d 100644
>>>> --- a/tools/libxl/libxl_types.idl
>>>> +++ b/tools/libxl/libxl_types.idl
>>>> @@ -494,11 +494,16 @@ libxl_domain_build_info =
>>>> Struct("domain_build_info",[
>>>>      # Note that the partial device tree should avoid to use the phandle
>>>>      # 65000 which is reserved by the toolstack.
>>>>      ("device_tree",      string),
>>>> +    ("acpi",             libxl_defbool),
>>>>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>>>>                  [("hvm", Struct(None, [("firmware",         string),
>>>>                                         ("bios",
>>>> libxl_bios_type),
>>>>                                         ("pae",
>>>> libxl_defbool),
>>>>                                         ("apic",
>>>> libxl_defbool),
>>>> +                                       # The following acpi field is
>>>> +                                       # deprecated. Please use the
>>>> unified
>>>> +                                       # acpi field above which
>>>> works for both
>>>> +                                       # x86 and ARM.
>>>>                                         ("acpi",
>>>> libxl_defbool),
>>>>                                         ("acpi_s3",
>>>> libxl_defbool),
>>>>                                         ("acpi_s4",
>>>> libxl_defbool),
>>>>
>>>>
>>>> And then:
>>>>
>>>> 1. modify xl to set the new field.
>>>> 2. modify libxl to handle compatibility: user of the old field should
>>>>    continue to work.
>>>>
>>> I found that the default value of acpi is true on x86. But we decided
>>> before it's should be false by default on ARM. How to deal with this?
>>> Julien, Stefano, can we make acpi true by default?
>>
>> I already said that I am not in favor of making ACPI true by default at
>> least for ARM 32-bit guest.
>>
>> ARM 32-bit guest will not use ACPI, if we decide to enable it by
>> default, we will require the user to install iasl for nothing.
>>
>> IHMO, ACPI should be disabled by default for any ARM guests. Libxl can
>> take this decision easily.
> I know but here we want to unify the acpi option for x86 and ARM while
> on x86 it's true by default. What I want to ask is that how to
> distinguish x86 and ARM in libxl__domain_build_info_setdefault(), so we
> can assign acpi with different default value for x86 and ARM.

By using #ifdef in the code?

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hello,

On 12/07/2016 17:58, Boris Ostrovsky wrote:
> On 07/12/2016 12:10 PM, Julien Grall wrote:
>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>>> On 2016年07月12日 22:50, Wei Liu wrote:
>>>>> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Does it mean we would need to update the slack
>>>>>>>>>>>>>>>>>>>>>>>>> to take into account the ACPI
>>>>>>>>>>>>>>>>>>>>>>>>> blob?
>>>>>>>>>>>>>>>>> Yes, we need to take into account the ACPI blob.
>>>>>>>>>>>>>>>>> Probably not in the
>>>>>>>>>>>>>>>>> slack but directly in mam_memkb.
>>>>>>>>>>>>> Sorry, I'm not sure understand this. I found the
>>>>>>>>>>>>> b_info->max_memkb but
>>>>>>>>>>>>> didn't find the slack you said. And how to fix this? Update
>>>>>>>>>>>>> b_info->max_memkb or the slack?
>>>>>>>>> Can you calculate the size of your payload and add that to
>>>>>>>>> max_memkb?
>>>>>>>>>
>>>>>>> Yeah, but the size will be changed if we change the tables in the
>>>>>>> future
>>>>>>> and this also should consider x86, right?
>>>>> That could easily be solved by introducing a function to calculate the
>>>>> size, right?
>>>> Oh, I'm not familiar with this. Let's clarify on this. It can add the
>>>> size to max_memkb after generating the ACPI tables and before loading
>>>> the tables to guest space and it doesn't have to add the size at
>>>> libxl__domain_build_info_setdefault(), right?
>>>
>>> This was discussed before: ACPI tables are part of RAM whose size is
>>> specified by the config file (and is reflected in max_memkb I believe).
>>> It may not be presented to the guest as RAM (i.e. on x86 it is labeled
>>> by BIOS (or whoever) as a dedicated type in e820) but it still resides
>>> in DIMMs.
>>
>> I don't think this was the conclusion of the thread. IHMO, "maxmem" is
>> the amount of RAM a guest could effectively use.
>>
>> Whilst the ACPI tables will be in the DIMM from the host point of
>> view. From a guest point of view it will be a ROM.
>
> The config file specifies resources provided by the host. How the guest
> views those resources is not important, I think.

This would need to be clarified. For instance special pages (Xenstore, 
Console...) are RAM from the host point of view but not taken into 
account in the "maxmem" provided by the user. For my understanding, some 
kB of the slack is used for that.

>
>>
>> It will affect some others part of the guest if we don't increment the
>> "maxmem" requested by the user. For ARM the ACPI blob will be exposed
>> at a specific address that is outside of the guest RAM (see the guest
>> memory layout in public/arch-arm.h).
>>
>> We chose this solution over putting in the RAM because the ACPI tables
>> are not easily relocatable (compare to the device tree, initrd and
>> kernel) so we could not take advantage of superpage in both stage-2
>> (hypervisor) and stage-1 (kernel) page table.
>
> Maybe this is something ARM-specific then. For x86 we will want to keep
> maxmem unchanged.

I don't think what I described in my previous mail is ARM-specific. The 
pressure will be more important on the TLBs, if Xen does not use 
superpage in the stage 2 page tables (i.e EPT for x86) no matter the 
architecture.

IHMO, this seems to be a bigger drawback compare to add few more 
kilobytes to maxmem in the toolstack for the ACPI blob. You will loose 
them when creating the intermediate page table in any case.

May I ask why you want to keep maxmem unchanged on x86?

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky]

On 07/13/2016 11:22 AM, Julien Grall wrote:
> Hello,
>
> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>> On 07/12/2016 12:10 PM, Julien Grall wrote:
>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>>>> On 2016年07月12日 22:50, Wei Liu wrote:
>>>>>> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Does it mean we would need to update the slack
>>>>>>>>>>>>>>>>>>>>>>>>>> to take into account the ACPI
>>>>>>>>>>>>>>>>>>>>>>>>>> blob?
>>>>>>>>>>>>>>>>>> Yes, we need to take into account the ACPI blob.
>>>>>>>>>>>>>>>>>> Probably not in the
>>>>>>>>>>>>>>>>>> slack but directly in mam_memkb.
>>>>>>>>>>>>>> Sorry, I'm not sure understand this. I found the
>>>>>>>>>>>>>> b_info->max_memkb but
>>>>>>>>>>>>>> didn't find the slack you said. And how to fix this? Update
>>>>>>>>>>>>>> b_info->max_memkb or the slack?
>>>>>>>>>> Can you calculate the size of your payload and add that to
>>>>>>>>>> max_memkb?
>>>>>>>>>>
>>>>>>>> Yeah, but the size will be changed if we change the tables in the
>>>>>>>> future
>>>>>>>> and this also should consider x86, right?
>>>>>> That could easily be solved by introducing a function to
>>>>>> calculate the
>>>>>> size, right?
>>>>> Oh, I'm not familiar with this. Let's clarify on this. It can add the
>>>>> size to max_memkb after generating the ACPI tables and before loading
>>>>> the tables to guest space and it doesn't have to add the size at
>>>>> libxl__domain_build_info_setdefault(), right?
>>>>
>>>> This was discussed before: ACPI tables are part of RAM whose size is
>>>> specified by the config file (and is reflected in max_memkb I
>>>> believe).
>>>> It may not be presented to the guest as RAM (i.e. on x86 it is labeled
>>>> by BIOS (or whoever) as a dedicated type in e820) but it still resides
>>>> in DIMMs.
>>>
>>> I don't think this was the conclusion of the thread. IHMO, "maxmem" is
>>> the amount of RAM a guest could effectively use.
>>>
>>> Whilst the ACPI tables will be in the DIMM from the host point of
>>> view. From a guest point of view it will be a ROM.
>>
>> The config file specifies resources provided by the host. How the guest
>> views those resources is not important, I think.
>
> This would need to be clarified. For instance special pages (Xenstore,
> Console...) are RAM from the host point of view but not taken into
> account in the "maxmem" provided by the user. For my understanding,
> some kB of the slack is used for that.


Are these pages part of guest's address space?


>
>>
>>>
>>> It will affect some others part of the guest if we don't increment the
>>> "maxmem" requested by the user. For ARM the ACPI blob will be exposed
>>> at a specific address that is outside of the guest RAM (see the guest
>>> memory layout in public/arch-arm.h).
>>>
>>> We chose this solution over putting in the RAM because the ACPI tables
>>> are not easily relocatable (compare to the device tree, initrd and
>>> kernel) so we could not take advantage of superpage in both stage-2
>>> (hypervisor) and stage-1 (kernel) page table.
>>
>> Maybe this is something ARM-specific then. For x86 we will want to keep
>> maxmem unchanged.
>
> I don't think what I described in my previous mail is ARM-specific.
> The pressure will be more important on the TLBs, if Xen does not use
> superpage in the stage 2 page tables (i.e EPT for x86) no matter the
> architecture.
>
> IHMO, this seems to be a bigger drawback compare to add few more
> kilobytes to maxmem in the toolstack for the ACPI blob. You will loose
> them when creating the intermediate page table in any case.


Why not have the guest ask for more memory in the config file then?

(OK, I can see that they can't ask for a few KB since we have MB
resolution but they can ask for an extra 1MB)


>
> May I ask why you want to keep maxmem unchanged on x86?

Only to keep resource accounting fair. The guest may decide to use
memory reserved for ACPI as a regular memory.



-boris



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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Wed, Jul 13, 2016 at 01:08:57PM -0400, Boris Ostrovsky wrote:
> On 07/13/2016 11:22 AM, Julien Grall wrote:
> > Hello,
> >
> > On 12/07/2016 17:58, Boris Ostrovsky wrote:
> >> On 07/12/2016 12:10 PM, Julien Grall wrote:
> >>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
> >>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> >>>>> On 2016年07月12日 22:50, Wei Liu wrote:
> >>>>>> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> Does it mean we would need to update the slack
> >>>>>>>>>>>>>>>>>>>>>>>>>> to take into account the ACPI
> >>>>>>>>>>>>>>>>>>>>>>>>>> blob?
> >>>>>>>>>>>>>>>>>> Yes, we need to take into account the ACPI blob.
> >>>>>>>>>>>>>>>>>> Probably not in the
> >>>>>>>>>>>>>>>>>> slack but directly in mam_memkb.
> >>>>>>>>>>>>>> Sorry, I'm not sure understand this. I found the
> >>>>>>>>>>>>>> b_info->max_memkb but
> >>>>>>>>>>>>>> didn't find the slack you said. And how to fix this? Update
> >>>>>>>>>>>>>> b_info->max_memkb or the slack?
> >>>>>>>>>> Can you calculate the size of your payload and add that to
> >>>>>>>>>> max_memkb?
> >>>>>>>>>>
> >>>>>>>> Yeah, but the size will be changed if we change the tables in the
> >>>>>>>> future
> >>>>>>>> and this also should consider x86, right?
> >>>>>> That could easily be solved by introducing a function to
> >>>>>> calculate the
> >>>>>> size, right?
> >>>>> Oh, I'm not familiar with this. Let's clarify on this. It can add the
> >>>>> size to max_memkb after generating the ACPI tables and before loading
> >>>>> the tables to guest space and it doesn't have to add the size at
> >>>>> libxl__domain_build_info_setdefault(), right?
> >>>>
> >>>> This was discussed before: ACPI tables are part of RAM whose size is
> >>>> specified by the config file (and is reflected in max_memkb I
> >>>> believe).
> >>>> It may not be presented to the guest as RAM (i.e. on x86 it is labeled
> >>>> by BIOS (or whoever) as a dedicated type in e820) but it still resides
> >>>> in DIMMs.
> >>>
> >>> I don't think this was the conclusion of the thread. IHMO, "maxmem" is
> >>> the amount of RAM a guest could effectively use.
> >>>
> >>> Whilst the ACPI tables will be in the DIMM from the host point of
> >>> view. From a guest point of view it will be a ROM.
> >>
> >> The config file specifies resources provided by the host. How the guest
> >> views those resources is not important, I think.
> >
> > This would need to be clarified. For instance special pages (Xenstore,
> > Console...) are RAM from the host point of view but not taken into
> > account in the "maxmem" provided by the user. For my understanding,
> > some kB of the slack is used for that.
> 
> 
> Are these pages part of guest's address space?
> 
> 
> >
> >>
> >>>
> >>> It will affect some others part of the guest if we don't increment the
> >>> "maxmem" requested by the user. For ARM the ACPI blob will be exposed
> >>> at a specific address that is outside of the guest RAM (see the guest
> >>> memory layout in public/arch-arm.h).
> >>>
> >>> We chose this solution over putting in the RAM because the ACPI tables
> >>> are not easily relocatable (compare to the device tree, initrd and
> >>> kernel) so we could not take advantage of superpage in both stage-2
> >>> (hypervisor) and stage-1 (kernel) page table.
> >>
> >> Maybe this is something ARM-specific then. For x86 we will want to keep
> >> maxmem unchanged.
> >
> > I don't think what I described in my previous mail is ARM-specific.
> > The pressure will be more important on the TLBs, if Xen does not use
> > superpage in the stage 2 page tables (i.e EPT for x86) no matter the
> > architecture.
> >
> > IHMO, this seems to be a bigger drawback compare to add few more
> > kilobytes to maxmem in the toolstack for the ACPI blob. You will loose
> > them when creating the intermediate page table in any case.
> 
> 
> Why not have the guest ask for more memory in the config file then?
> 
> (OK, I can see that they can't ask for a few KB since we have MB
> resolution but they can ask for an extra 1MB)
> 

It would be trivial to have another option in xl.cfg to allow MB
granularity. But I don't think that's a good idea. Asking for more
memory when you don't really know how much is enough is not very useful.
If an admin can know how much is needed, surely the library can be
taught to obtain that knowledge, too.

We need to decide which model we should go with. And, if we decide to
diverge, document the difference between x86 and ARM model.

Wei.

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hello,

On 13/07/16 18:08, Boris Ostrovsky wrote:
> On 07/13/2016 11:22 AM, Julien Grall wrote:
>> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>>> The config file specifies resources provided by the host. How the guest
>>> views those resources is not important, I think.
>>
>> This would need to be clarified. For instance special pages (Xenstore,
>> Console...) are RAM from the host point of view but not taken into
>> account in the "maxmem" provided by the user. For my understanding,
>> some kB of the slack is used for that.
>
>
> Are these pages part of guest's address space?

Yes, they are used to communicate between the guest and the backend 
(xenconsole, xenstore,...).

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Stefano Stabellini]

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

On Wed, 13 Jul 2016, Julien Grall wrote:
> Hello,
> 
> On 12/07/2016 17:58, Boris Ostrovsky wrote:
> > On 07/12/2016 12:10 PM, Julien Grall wrote:
> > > On 12/07/2016 16:08, Boris Ostrovsky wrote:
> > > > On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> > > > > On 2016年07月12日 22:50, Wei Liu wrote:
> > > > > > On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > Does it mean we would need
> > > > > > > > > > > > > > > > > > > > > > > > > > to update the slack
> > > > > > > > > > > > > > > > > > > > > > > > > > to take into account the
> > > > > > > > > > > > > > > > > > > > > > > > > > ACPI
> > > > > > > > > > > > > > > > > > > > > > > > > > blob?
> > > > > > > > > > > > > > > > > > Yes, we need to take into account the ACPI
> > > > > > > > > > > > > > > > > > blob.
> > > > > > > > > > > > > > > > > > Probably not in the
> > > > > > > > > > > > > > > > > > slack but directly in mam_memkb.
> > > > > > > > > > > > > > Sorry, I'm not sure understand this. I found the
> > > > > > > > > > > > > > b_info->max_memkb but
> > > > > > > > > > > > > > didn't find the slack you said. And how to fix this?
> > > > > > > > > > > > > > Update
> > > > > > > > > > > > > > b_info->max_memkb or the slack?
> > > > > > > > > > Can you calculate the size of your payload and add that to
> > > > > > > > > > max_memkb?
> > > > > > > > > > 
> > > > > > > > Yeah, but the size will be changed if we change the tables in
> > > > > > > > the
> > > > > > > > future
> > > > > > > > and this also should consider x86, right?
> > > > > > That could easily be solved by introducing a function to calculate
> > > > > > the
> > > > > > size, right?
> > > > > Oh, I'm not familiar with this. Let's clarify on this. It can add the
> > > > > size to max_memkb after generating the ACPI tables and before loading
> > > > > the tables to guest space and it doesn't have to add the size at
> > > > > libxl__domain_build_info_setdefault(), right?
> > > > 
> > > > This was discussed before: ACPI tables are part of RAM whose size is
> > > > specified by the config file (and is reflected in max_memkb I believe).
> > > > It may not be presented to the guest as RAM (i.e. on x86 it is labeled
> > > > by BIOS (or whoever) as a dedicated type in e820) but it still resides
> > > > in DIMMs.
> > > 
> > > I don't think this was the conclusion of the thread. IHMO, "maxmem" is
> > > the amount of RAM a guest could effectively use.
> > > 
> > > Whilst the ACPI tables will be in the DIMM from the host point of
> > > view. From a guest point of view it will be a ROM.
> > 
> > The config file specifies resources provided by the host. How the guest
> > views those resources is not important, I think.
> 
> This would need to be clarified. For instance special pages (Xenstore,
> Console...) are RAM from the host point of view but not taken into account in
> the "maxmem" provided by the user. For my understanding, some kB of the slack
> is used for that.
> 
> > 
> > > 
> > > It will affect some others part of the guest if we don't increment the
> > > "maxmem" requested by the user. For ARM the ACPI blob will be exposed
> > > at a specific address that is outside of the guest RAM (see the guest
> > > memory layout in public/arch-arm.h).
> > > 
> > > We chose this solution over putting in the RAM because the ACPI tables
> > > are not easily relocatable (compare to the device tree, initrd and
> > > kernel) so we could not take advantage of superpage in both stage-2
> > > (hypervisor) and stage-1 (kernel) page table.
> > 
> > Maybe this is something ARM-specific then. For x86 we will want to keep
> > maxmem unchanged.
> 
> I don't think what I described in my previous mail is ARM-specific. The
> pressure will be more important on the TLBs, if Xen does not use superpage in
> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
> 
> IHMO, this seems to be a bigger drawback compare to add few more kilobytes to
> maxmem in the toolstack for the ACPI blob. You will loose them when creating
> the intermediate page table in any case.

I agree with Julien. On ARM we have to increase maxmem because I don't
think that shattering a superpage is acceptable for just a few KBs. In
fact, it's not much about increasing maxmem, but it's about keeping the
allocation of guest memory to the value passed by the user in "memory",
so that it can be done in the most efficient way possible. (I am
assuming users are going to allocate VMs of 2048MB, rather than 2049MB.)

I wouldn't want to end up adding to the performance tuning page on the
wiki "Make sure to add 1 more MB to the memory of your VM to get the
most out of the system."

I know that the location of the ACPI blob on x86 is different in guest
memory space, but it seems to me that the problem would be the same. Do
you have 1 gigabyte pages in stage-2 on x86? If so, I would think twice
about this. Otherwise, if you only have 4K and 2MB allocations, then it
might not make that much of a difference.

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

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Shannon Zhao]

On 2016/7/13 18:03, Julien Grall wrote:
> 
> 
> On 13/07/2016 10:48, Shannon Zhao wrote:
>>
>>
>> On 2016/7/13 17:20, Julien Grall wrote:
>>> On 13/07/2016 08:54, Shannon Zhao wrote:
>>>> On 2016/7/12 19:33, Wei Liu wrote:
>>>>> On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
>>>>> [...]
>>>>>>>> Yeah, we can deprecate that field. But we need to take care to not
>>>>>>>> break
>>>>>>>> users of the old field.
>>>>>>> Ok, what name would you suggest?
>>>>>>
>>>>>> I would suggest b_info->u.acpi
>>>>>>
>>>>>
>>>>> b_info->acpi would be more appropriate.
>>>>>
>>>>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>>>>> index ef614be..a57823d 100644
>>>>> --- a/tools/libxl/libxl_types.idl
>>>>> +++ b/tools/libxl/libxl_types.idl
>>>>> @@ -494,11 +494,16 @@ libxl_domain_build_info =
>>>>> Struct("domain_build_info",[
>>>>>      # Note that the partial device tree should avoid to use the
>>>>> phandle
>>>>>      # 65000 which is reserved by the toolstack.
>>>>>      ("device_tree",      string),
>>>>> +    ("acpi",             libxl_defbool),
>>>>>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>>>>>                  [("hvm", Struct(None, [("firmware",         string),
>>>>>                                         ("bios",
>>>>> libxl_bios_type),
>>>>>                                         ("pae",
>>>>> libxl_defbool),
>>>>>                                         ("apic",
>>>>> libxl_defbool),
>>>>> +                                       # The following acpi field is
>>>>> +                                       # deprecated. Please use the
>>>>> unified
>>>>> +                                       # acpi field above which
>>>>> works for both
>>>>> +                                       # x86 and ARM.
>>>>>                                         ("acpi",
>>>>> libxl_defbool),
>>>>>                                         ("acpi_s3",
>>>>> libxl_defbool),
>>>>>                                         ("acpi_s4",
>>>>> libxl_defbool),
>>>>>
>>>>>
>>>>> And then:
>>>>>
>>>>> 1. modify xl to set the new field.
>>>>> 2. modify libxl to handle compatibility: user of the old field should
>>>>>    continue to work.
>>>>>
>>>> I found that the default value of acpi is true on x86. But we decided
>>>> before it's should be false by default on ARM. How to deal with this?
>>>> Julien, Stefano, can we make acpi true by default?
>>>
>>> I already said that I am not in favor of making ACPI true by default at
>>> least for ARM 32-bit guest.
>>>
>>> ARM 32-bit guest will not use ACPI, if we decide to enable it by
>>> default, we will require the user to install iasl for nothing.
>>>
>>> IHMO, ACPI should be disabled by default for any ARM guests. Libxl can
>>> take this decision easily.
>> I know but here we want to unify the acpi option for x86 and ARM while
>> on x86 it's true by default. What I want to ask is that how to
>> distinguish x86 and ARM in libxl__domain_build_info_setdefault(), so we
>> can assign acpi with different default value for x86 and ARM.
> 
> By using #ifdef in the code?
Maybe this could not work since CONFIG_ARM can not be accessed in libxl
in current codes. I'm not sure why it can't work. Wei, do you have any
suggestion?

Thanks,
-- 
Shannon


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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Shannon Zhao]

On 2016/7/15 16:00, Shannon Zhao wrote:
> 
> 
> On 2016/7/13 18:03, Julien Grall wrote:
>>
>>
>> On 13/07/2016 10:48, Shannon Zhao wrote:
>>>
>>>
>>> On 2016/7/13 17:20, Julien Grall wrote:
>>>> On 13/07/2016 08:54, Shannon Zhao wrote:
>>>>> On 2016/7/12 19:33, Wei Liu wrote:
>>>>>> On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
>>>>>> [...]
>>>>>>>>> Yeah, we can deprecate that field. But we need to take care to not
>>>>>>>>> break
>>>>>>>>> users of the old field.
>>>>>>>> Ok, what name would you suggest?
>>>>>>>
>>>>>>> I would suggest b_info->u.acpi
>>>>>>>
>>>>>>
>>>>>> b_info->acpi would be more appropriate.
>>>>>>
>>>>>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>>>>>> index ef614be..a57823d 100644
>>>>>> --- a/tools/libxl/libxl_types.idl
>>>>>> +++ b/tools/libxl/libxl_types.idl
>>>>>> @@ -494,11 +494,16 @@ libxl_domain_build_info =
>>>>>> Struct("domain_build_info",[
>>>>>>      # Note that the partial device tree should avoid to use the
>>>>>> phandle
>>>>>>      # 65000 which is reserved by the toolstack.
>>>>>>      ("device_tree",      string),
>>>>>> +    ("acpi",             libxl_defbool),
>>>>>>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>>>>>>                  [("hvm", Struct(None, [("firmware",         string),
>>>>>>                                         ("bios",
>>>>>> libxl_bios_type),
>>>>>>                                         ("pae",
>>>>>> libxl_defbool),
>>>>>>                                         ("apic",
>>>>>> libxl_defbool),
>>>>>> +                                       # The following acpi field is
>>>>>> +                                       # deprecated. Please use the
>>>>>> unified
>>>>>> +                                       # acpi field above which
>>>>>> works for both
>>>>>> +                                       # x86 and ARM.
>>>>>>                                         ("acpi",
>>>>>> libxl_defbool),
>>>>>>                                         ("acpi_s3",
>>>>>> libxl_defbool),
>>>>>>                                         ("acpi_s4",
>>>>>> libxl_defbool),
>>>>>>
>>>>>>
>>>>>> And then:
>>>>>>
>>>>>> 1. modify xl to set the new field.
>>>>>> 2. modify libxl to handle compatibility: user of the old field should
>>>>>>    continue to work.
>>>>>>
>>>>> I found that the default value of acpi is true on x86. But we decided
>>>>> before it's should be false by default on ARM. How to deal with this?
>>>>> Julien, Stefano, can we make acpi true by default?
>>>>
>>>> I already said that I am not in favor of making ACPI true by default at
>>>> least for ARM 32-bit guest.
>>>>
>>>> ARM 32-bit guest will not use ACPI, if we decide to enable it by
>>>> default, we will require the user to install iasl for nothing.
>>>>
>>>> IHMO, ACPI should be disabled by default for any ARM guests. Libxl can
>>>> take this decision easily.
>>> I know but here we want to unify the acpi option for x86 and ARM while
>>> on x86 it's true by default. What I want to ask is that how to
>>> distinguish x86 and ARM in libxl__domain_build_info_setdefault(), so we
>>> can assign acpi with different default value for x86 and ARM.
>>
>> By using #ifdef in the code?
> Maybe this could not work since CONFIG_ARM can not be accessed in libxl
> in current codes. I'm not sure why it can't work. Wei, do you have any
> suggestion?
> 
And is it ok to use
#if defined(__arm__) || defined(__aarch64__)
?

Thanks,
-- 
Shannon


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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Shannon Zhao]

On 2016/7/14 19:15, Wei Liu wrote:
> On Wed, Jul 13, 2016 at 01:08:57PM -0400, Boris Ostrovsky wrote:
>> On 07/13/2016 11:22 AM, Julien Grall wrote:
>>> Hello,
>>>
>>> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>>>> On 07/12/2016 12:10 PM, Julien Grall wrote:
>>>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>>>>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>>>>>> On 2016年07月12日 22:50, Wei Liu wrote:
>>>>>>>> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Does it mean we would need to update the slack
>>>>>>>>>>>>>>>>>>>>>>>>>>>> to take into account the ACPI
>>>>>>>>>>>>>>>>>>>>>>>>>>>> blob?
>>>>>>>>>>>>>>>>>>>> Yes, we need to take into account the ACPI blob.
>>>>>>>>>>>>>>>>>>>> Probably not in the
>>>>>>>>>>>>>>>>>>>> slack but directly in mam_memkb.
>>>>>>>>>>>>>>>> Sorry, I'm not sure understand this. I found the
>>>>>>>>>>>>>>>> b_info->max_memkb but
>>>>>>>>>>>>>>>> didn't find the slack you said. And how to fix this? Update
>>>>>>>>>>>>>>>> b_info->max_memkb or the slack?
>>>>>>>>>>>> Can you calculate the size of your payload and add that to
>>>>>>>>>>>> max_memkb?
>>>>>>>>>>>>
>>>>>>>>>> Yeah, but the size will be changed if we change the tables in the
>>>>>>>>>> future
>>>>>>>>>> and this also should consider x86, right?
>>>>>>>> That could easily be solved by introducing a function to
>>>>>>>> calculate the
>>>>>>>> size, right?
>>>>>>> Oh, I'm not familiar with this. Let's clarify on this. It can add the
>>>>>>> size to max_memkb after generating the ACPI tables and before loading
>>>>>>> the tables to guest space and it doesn't have to add the size at
>>>>>>> libxl__domain_build_info_setdefault(), right?
>>>>>>
>>>>>> This was discussed before: ACPI tables are part of RAM whose size is
>>>>>> specified by the config file (and is reflected in max_memkb I
>>>>>> believe).
>>>>>> It may not be presented to the guest as RAM (i.e. on x86 it is labeled
>>>>>> by BIOS (or whoever) as a dedicated type in e820) but it still resides
>>>>>> in DIMMs.
>>>>>
>>>>> I don't think this was the conclusion of the thread. IHMO, "maxmem" is
>>>>> the amount of RAM a guest could effectively use.
>>>>>
>>>>> Whilst the ACPI tables will be in the DIMM from the host point of
>>>>> view. From a guest point of view it will be a ROM.
>>>>
>>>> The config file specifies resources provided by the host. How the guest
>>>> views those resources is not important, I think.
>>>
>>> This would need to be clarified. For instance special pages (Xenstore,
>>> Console...) are RAM from the host point of view but not taken into
>>> account in the "maxmem" provided by the user. For my understanding,
>>> some kB of the slack is used for that.
>>
>>
>> Are these pages part of guest's address space?
>>
>>
>>>
>>>>
>>>>>
>>>>> It will affect some others part of the guest if we don't increment the
>>>>> "maxmem" requested by the user. For ARM the ACPI blob will be exposed
>>>>> at a specific address that is outside of the guest RAM (see the guest
>>>>> memory layout in public/arch-arm.h).
>>>>>
>>>>> We chose this solution over putting in the RAM because the ACPI tables
>>>>> are not easily relocatable (compare to the device tree, initrd and
>>>>> kernel) so we could not take advantage of superpage in both stage-2
>>>>> (hypervisor) and stage-1 (kernel) page table.
>>>>
>>>> Maybe this is something ARM-specific then. For x86 we will want to keep
>>>> maxmem unchanged.
>>>
>>> I don't think what I described in my previous mail is ARM-specific.
>>> The pressure will be more important on the TLBs, if Xen does not use
>>> superpage in the stage 2 page tables (i.e EPT for x86) no matter the
>>> architecture.
>>>
>>> IHMO, this seems to be a bigger drawback compare to add few more
>>> kilobytes to maxmem in the toolstack for the ACPI blob. You will loose
>>> them when creating the intermediate page table in any case.
>>
>>
>> Why not have the guest ask for more memory in the config file then?
>>
>> (OK, I can see that they can't ask for a few KB since we have MB
>> resolution but they can ask for an extra 1MB)
>>
> 
> It would be trivial to have another option in xl.cfg to allow MB
> granularity. But I don't think that's a good idea. Asking for more
> memory when you don't really know how much is enough is not very useful.
> If an admin can know how much is needed, surely the library can be
> taught to obtain that knowledge, too.
> 
> We need to decide which model we should go with. And, if we decide to
> diverge, document the difference between x86 and ARM model.
> 
Hi Wei,

Do you decide how to add the size of ACPI blob to max_memkb?

Thanks,
-- 
Shannon


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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Stefano Stabellini]

On Fri, 15 Jul 2016, Shannon Zhao wrote:
> On 2016/7/15 16:00, Shannon Zhao wrote:
> > 
> > 
> > On 2016/7/13 18:03, Julien Grall wrote:
> >>
> >>
> >> On 13/07/2016 10:48, Shannon Zhao wrote:
> >>>
> >>>
> >>> On 2016/7/13 17:20, Julien Grall wrote:
> >>>> On 13/07/2016 08:54, Shannon Zhao wrote:
> >>>>> On 2016/7/12 19:33, Wei Liu wrote:
> >>>>>> On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
> >>>>>> [...]
> >>>>>>>>> Yeah, we can deprecate that field. But we need to take care to not
> >>>>>>>>> break
> >>>>>>>>> users of the old field.
> >>>>>>>> Ok, what name would you suggest?
> >>>>>>>
> >>>>>>> I would suggest b_info->u.acpi
> >>>>>>>
> >>>>>>
> >>>>>> b_info->acpi would be more appropriate.
> >>>>>>
> >>>>>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> >>>>>> index ef614be..a57823d 100644
> >>>>>> --- a/tools/libxl/libxl_types.idl
> >>>>>> +++ b/tools/libxl/libxl_types.idl
> >>>>>> @@ -494,11 +494,16 @@ libxl_domain_build_info =
> >>>>>> Struct("domain_build_info",[
> >>>>>>      # Note that the partial device tree should avoid to use the
> >>>>>> phandle
> >>>>>>      # 65000 which is reserved by the toolstack.
> >>>>>>      ("device_tree",      string),
> >>>>>> +    ("acpi",             libxl_defbool),
> >>>>>>      ("u", KeyedUnion(None, libxl_domain_type, "type",
> >>>>>>                  [("hvm", Struct(None, [("firmware",         string),
> >>>>>>                                         ("bios",
> >>>>>> libxl_bios_type),
> >>>>>>                                         ("pae",
> >>>>>> libxl_defbool),
> >>>>>>                                         ("apic",
> >>>>>> libxl_defbool),
> >>>>>> +                                       # The following acpi field is
> >>>>>> +                                       # deprecated. Please use the
> >>>>>> unified
> >>>>>> +                                       # acpi field above which
> >>>>>> works for both
> >>>>>> +                                       # x86 and ARM.
> >>>>>>                                         ("acpi",
> >>>>>> libxl_defbool),
> >>>>>>                                         ("acpi_s3",
> >>>>>> libxl_defbool),
> >>>>>>                                         ("acpi_s4",
> >>>>>> libxl_defbool),
> >>>>>>
> >>>>>>
> >>>>>> And then:
> >>>>>>
> >>>>>> 1. modify xl to set the new field.
> >>>>>> 2. modify libxl to handle compatibility: user of the old field should
> >>>>>>    continue to work.
> >>>>>>
> >>>>> I found that the default value of acpi is true on x86. But we decided
> >>>>> before it's should be false by default on ARM. How to deal with this?
> >>>>> Julien, Stefano, can we make acpi true by default?
> >>>>
> >>>> I already said that I am not in favor of making ACPI true by default at
> >>>> least for ARM 32-bit guest.
> >>>>
> >>>> ARM 32-bit guest will not use ACPI, if we decide to enable it by
> >>>> default, we will require the user to install iasl for nothing.
> >>>>
> >>>> IHMO, ACPI should be disabled by default for any ARM guests. Libxl can
> >>>> take this decision easily.
> >>> I know but here we want to unify the acpi option for x86 and ARM while
> >>> on x86 it's true by default. What I want to ask is that how to
> >>> distinguish x86 and ARM in libxl__domain_build_info_setdefault(), so we
> >>> can assign acpi with different default value for x86 and ARM.
> >>
> >> By using #ifdef in the code?
> > Maybe this could not work since CONFIG_ARM can not be accessed in libxl
> > in current codes. I'm not sure why it can't work. Wei, do you have any
> > suggestion?
> > 
> And is it ok to use
> #if defined(__arm__) || defined(__aarch64__)
> ?

I am not a Libxl maintainer anymore, but I think that should be OK or at
least it would be a step in the right direction.

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Fri, Jul 15, 2016 at 05:39:32PM +0800, Shannon Zhao wrote:
[...]
> > 
> > It would be trivial to have another option in xl.cfg to allow MB
> > granularity. But I don't think that's a good idea. Asking for more
> > memory when you don't really know how much is enough is not very useful.
> > If an admin can know how much is needed, surely the library can be
> > taught to obtain that knowledge, too.
> > 
> > We need to decide which model we should go with. And, if we decide to
> > diverge, document the difference between x86 and ARM model.
> > 
> Hi Wei,
> 
> Do you decide how to add the size of ACPI blob to max_memkb?
> 

AFAICT ARM and x86 maintainers hold different opinions on how memory
should be accounted.

I would like to have a unified memory accounting model. But if we can't
have that at the moment, I'm fine with divergence, but please document
it somewhere (comment near code snippet, in header, or a file under docs
etc). And the amount added to max_memkb needs to be properly calculated,
not some magic number, so that we have a chance in the future to
confidently change how we do thing.


Wei.

> Thanks,
> -- 
> Shannon
> 

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Wei Liu]

On Mon, Jul 18, 2016 at 12:40:43PM -0700, Stefano Stabellini wrote:
[...]
> > #if defined(__arm__) || defined(__aarch64__)
> > ?
> 
> I am not a Libxl maintainer anymore, but I think that should be OK or at
> least it would be a step in the right direction.

Yes, I think that's the correct ifdefs to use.

Wei.

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

Re: [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Ian Jackson]

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI"):
...
> > >>> I know but here we want to unify the acpi option for x86 and ARM while
> > >>> on x86 it's true by default. What I want to ask is that how to
> > >>> distinguish x86 and ARM in libxl__domain_build_info_setdefault(), so we
> > >>> can assign acpi with different default value for x86 and ARM.
> > >>
> > >> By using #ifdef in the code?

We normally try to deal with this kind of thing by separating the
arch-specific code into separate files, which are compiled as needed.

Maybe libxl__arch_domain_prepare_config is the right place ?

> > > Maybe this could not work since CONFIG_ARM can not be accessed in libxl
> > > in current codes. I'm not sure why it can't work. Wei, do you have any
> > > suggestion?
> > > 
> > And is it ok to use
> > #if defined(__arm__) || defined(__aarch64__)
> > ?
> 
> I am not a Libxl maintainer anymore, but I think that should be OK or at
> least it would be a step in the right direction.

I definitely don't want open-coded alternations like this.  If an
#ifdef is needed, a single feature macro should be (if necessary
invented) and tested.

But as I say I think this can probably be done with libxl_arch.h,
libxl_arm.c, libxl_x86.c, etc.

Thanks,
Ian.

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Shannon Zhao]

On 2016/7/19 18:38, Wei Liu wrote:
> On Fri, Jul 15, 2016 at 05:39:32PM +0800, Shannon Zhao wrote:
> [...]
>>> > > 
>>> > > It would be trivial to have another option in xl.cfg to allow MB
>>> > > granularity. But I don't think that's a good idea. Asking for more
>>> > > memory when you don't really know how much is enough is not very useful.
>>> > > If an admin can know how much is needed, surely the library can be
>>> > > taught to obtain that knowledge, too.
>>> > > 
>>> > > We need to decide which model we should go with. And, if we decide to
>>> > > diverge, document the difference between x86 and ARM model.
>>> > > 
>> > Hi Wei,
>> > 
>> > Do you decide how to add the size of ACPI blob to max_memkb?
>> > 
> AFAICT ARM and x86 maintainers hold different opinions on how memory
> should be accounted.
> 
> I would like to have a unified memory accounting model. But if we can't
> have that at the moment, I'm fine with divergence, but please document
> it somewhere (comment near code snippet, in header, or a file under docs
> etc). And the amount added to max_memkb needs to be properly calculated,
> not some magic number, so that we have a chance in the future to
> confidently change how we do thing.
If it's only allowed to add the size to max_memkb in
libxl__domain_build_info_setdefault(), it only can use a const number
since the tables are not generted and we don;t know the size. But the
const number could be chosen properly since we could know the maximum
ACPI tables size of current ARM approach.

But maybe in the future, if we add some new ACPI tables, it should
increase the size as well. So I think this should be documented.

As I asked before, is it ok to add the size to max_memkb after
generating the ACPI tables and before loading the tables to guest space?

Thanks,
-- 
Shannon


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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Wed, Jul 20, 2016 at 02:52:05PM +0800, Shannon Zhao wrote:
> 
> 
> On 2016/7/19 18:38, Wei Liu wrote:
> > On Fri, Jul 15, 2016 at 05:39:32PM +0800, Shannon Zhao wrote:
> > [...]
> >>> > > 
> >>> > > It would be trivial to have another option in xl.cfg to allow MB
> >>> > > granularity. But I don't think that's a good idea. Asking for more
> >>> > > memory when you don't really know how much is enough is not very useful.
> >>> > > If an admin can know how much is needed, surely the library can be
> >>> > > taught to obtain that knowledge, too.
> >>> > > 
> >>> > > We need to decide which model we should go with. And, if we decide to
> >>> > > diverge, document the difference between x86 and ARM model.
> >>> > > 
> >> > Hi Wei,
> >> > 
> >> > Do you decide how to add the size of ACPI blob to max_memkb?
> >> > 
> > AFAICT ARM and x86 maintainers hold different opinions on how memory
> > should be accounted.
> > 
> > I would like to have a unified memory accounting model. But if we can't
> > have that at the moment, I'm fine with divergence, but please document
> > it somewhere (comment near code snippet, in header, or a file under docs
> > etc). And the amount added to max_memkb needs to be properly calculated,
> > not some magic number, so that we have a chance in the future to
> > confidently change how we do thing.
> If it's only allowed to add the size to max_memkb in
> libxl__domain_build_info_setdefault(), it only can use a const number
> since the tables are not generted and we don;t know the size. But the
> const number could be chosen properly since we could know the maximum
> ACPI tables size of current ARM approach.
> 
> But maybe in the future, if we add some new ACPI tables, it should
> increase the size as well. So I think this should be documented.
> 
> As I asked before, is it ok to add the size to max_memkb after
> generating the ACPI tables and before loading the tables to guest space?
> 

Yes. I don't think shoehorning everything into setdefault is a good
idea.

I think libxl_arm.c:libxl__arch_domain_create would be the right place
to do it.

I am thinking about calling xc_domain_setmaxmem there, but not adding a
number to d_config->b_info.max_memkb. Adding that to ->max_memkb would
be wrong because the bigger ->max_memkb will be recored and the same
algorithm will be applied every time you migrate your guest, so the
max_memkb will grow bigger and bigger.

Given the different approach taken by ARM and x86, maybe we need to also
record the size of acpi blobs somewhere in xenstore (also needs to be
documented) so that subsequent libxl_domain_setmaxmem can extract that
number again.

Please wait a bit for Stefano and Julien to comment before you do work.

I know, memory accounting is a bit messy. I don't claim that I figure
every last detail out. If I'm not clear enough or ignores some basic
facts do let me know.

Wei.

> Thanks,
> -- 
> Shannon
> 

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hi,

On 14/07/16 14:37, Stefano Stabellini wrote:
> On Wed, 13 Jul 2016, Julien Grall wrote:
>> Hello,
>>
>> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>>> On 07/12/2016 12:10 PM, Julien Grall wrote:
>>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>>>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>>> It will affect some others part of the guest if we don't increment the
>>>> "maxmem" requested by the user. For ARM the ACPI blob will be exposed
>>>> at a specific address that is outside of the guest RAM (see the guest
>>>> memory layout in public/arch-arm.h).
>>>>
>>>> We chose this solution over putting in the RAM because the ACPI tables
>>>> are not easily relocatable (compare to the device tree, initrd and
>>>> kernel) so we could not take advantage of superpage in both stage-2
>>>> (hypervisor) and stage-1 (kernel) page table.
>>>
>>> Maybe this is something ARM-specific then. For x86 we will want to keep
>>> maxmem unchanged.
>>
>> I don't think what I described in my previous mail is ARM-specific. The
>> pressure will be more important on the TLBs, if Xen does not use superpage in
>> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
>>
>> IHMO, this seems to be a bigger drawback compare to add few more kilobytes to
>> maxmem in the toolstack for the ACPI blob. You will loose them when creating
>> the intermediate page table in any case.
>
> I agree with Julien. On ARM we have to increase maxmem because I don't
> think that shattering a superpage is acceptable for just a few KBs. In
> fact, it's not much about increasing maxmem, but it's about keeping the
> allocation of guest memory to the value passed by the user in "memory",
> so that it can be done in the most efficient way possible. (I am
> assuming users are going to allocate VMs of 2048MB, rather than 2049MB.)
>
> I wouldn't want to end up adding to the performance tuning page on the
> wiki "Make sure to add 1 more MB to the memory of your VM to get the
> most out of the system."
>
> I know that the location of the ACPI blob on x86 is different in guest
> memory space, but it seems to me that the problem would be the same. Do
> you have 1 gigabyte pages in stage-2 on x86? If so, I would think twice
> about this. Otherwise, if you only have 4K and 2MB allocations, then it
> might not make that much of a difference.

Looking at the x86 code, 1 gigabyte pages seems to be supported.

Boris, do you have any opinions on this?

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky]

On 07/20/2016 08:33 AM, Julien Grall wrote:
> Hi,
>
> On 14/07/16 14:37, Stefano Stabellini wrote:
>> On Wed, 13 Jul 2016, Julien Grall wrote:
>>> Hello,
>>>
>>> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>>>> On 07/12/2016 12:10 PM, Julien Grall wrote:
>>>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>>>>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>>>> It will affect some others part of the guest if we don't increment
>>>>> the
>>>>> "maxmem" requested by the user. For ARM the ACPI blob will be exposed
>>>>> at a specific address that is outside of the guest RAM (see the guest
>>>>> memory layout in public/arch-arm.h).
>>>>>
>>>>> We chose this solution over putting in the RAM because the ACPI
>>>>> tables
>>>>> are not easily relocatable (compare to the device tree, initrd and
>>>>> kernel) so we could not take advantage of superpage in both stage-2
>>>>> (hypervisor) and stage-1 (kernel) page table.
>>>>
>>>> Maybe this is something ARM-specific then. For x86 we will want to
>>>> keep
>>>> maxmem unchanged.
>>>
>>> I don't think what I described in my previous mail is ARM-specific. The
>>> pressure will be more important on the TLBs, if Xen does not use
>>> superpage in
>>> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
>>>
>>> IHMO, this seems to be a bigger drawback compare to add few more
>>> kilobytes to
>>> maxmem in the toolstack for the ACPI blob. You will loose them when
>>> creating
>>> the intermediate page table in any case.
>>
>> I agree with Julien. On ARM we have to increase maxmem because I don't
>> think that shattering a superpage is acceptable for just a few KBs. In
>> fact, it's not much about increasing maxmem, but it's about keeping the
>> allocation of guest memory to the value passed by the user in "memory",
>> so that it can be done in the most efficient way possible. (I am
>> assuming users are going to allocate VMs of 2048MB, rather than 2049MB.)
>>
>> I wouldn't want to end up adding to the performance tuning page on the
>> wiki "Make sure to add 1 more MB to the memory of your VM to get the
>> most out of the system."
>>
>> I know that the location of the ACPI blob on x86 is different in guest
>> memory space, but it seems to me that the problem would be the same. Do
>> you have 1 gigabyte pages in stage-2 on x86? If so, I would think twice
>> about this. Otherwise, if you only have 4K and 2MB allocations, then it
>> might not make that much of a difference.
>
> Looking at the x86 code, 1 gigabyte pages seems to be supported.
>
> Boris, do you have any opinions on this?


I don't think I understand the superpage shattering argument.  In x86
the tables live in regular RAM and a guest is free to use those
addresses as regular memory.

This apparently is different from how ARM manages the tables (you said
in an earlier message that they are not part of RAM) so I can see that
taking memory from RAM allocation to store the tables may affect how
mapping is done, potentially causing GB pages to be broken.

In fact (and I am totally speculating here) padding memory for x86 may
actually *cause* shattering because we will have (for example) 2049MB of
RAM to deal with.

If we were talking about large code difference (and if I am wrong about
what I said above) I'd agree that adding a few KB for x86 is OK. But
given that we are talking about a couple of lines of code ifdef'd by
'ARM' (and maybe a comment explaining why) I'd prefer not adding
anything for x86.

-boris


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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

On 20/07/2016 14:33, Boris Ostrovsky wrote:
> On 07/20/2016 08:33 AM, Julien Grall wrote:
>> Hi,
>>
>> On 14/07/16 14:37, Stefano Stabellini wrote:
>>> On Wed, 13 Jul 2016, Julien Grall wrote:
>>>> Hello,
>>>>
>>>> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>>>>> On 07/12/2016 12:10 PM, Julien Grall wrote:
>>>>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>>>>>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>>>>> It will affect some others part of the guest if we don't increment
>>>>>> the
>>>>>> "maxmem" requested by the user. For ARM the ACPI blob will be exposed
>>>>>> at a specific address that is outside of the guest RAM (see the guest
>>>>>> memory layout in public/arch-arm.h).
>>>>>>
>>>>>> We chose this solution over putting in the RAM because the ACPI
>>>>>> tables
>>>>>> are not easily relocatable (compare to the device tree, initrd and
>>>>>> kernel) so we could not take advantage of superpage in both stage-2
>>>>>> (hypervisor) and stage-1 (kernel) page table.
>>>>>
>>>>> Maybe this is something ARM-specific then. For x86 we will want to
>>>>> keep
>>>>> maxmem unchanged.
>>>>
>>>> I don't think what I described in my previous mail is ARM-specific. The
>>>> pressure will be more important on the TLBs, if Xen does not use
>>>> superpage in
>>>> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
>>>>
>>>> IHMO, this seems to be a bigger drawback compare to add few more
>>>> kilobytes to
>>>> maxmem in the toolstack for the ACPI blob. You will loose them when
>>>> creating
>>>> the intermediate page table in any case.
>>>
>>> I agree with Julien. On ARM we have to increase maxmem because I don't
>>> think that shattering a superpage is acceptable for just a few KBs. In
>>> fact, it's not much about increasing maxmem, but it's about keeping the
>>> allocation of guest memory to the value passed by the user in "memory",
>>> so that it can be done in the most efficient way possible. (I am
>>> assuming users are going to allocate VMs of 2048MB, rather than 2049MB.)
>>>
>>> I wouldn't want to end up adding to the performance tuning page on the
>>> wiki "Make sure to add 1 more MB to the memory of your VM to get the
>>> most out of the system."
>>>
>>> I know that the location of the ACPI blob on x86 is different in guest
>>> memory space, but it seems to me that the problem would be the same. Do
>>> you have 1 gigabyte pages in stage-2 on x86? If so, I would think twice
>>> about this. Otherwise, if you only have 4K and 2MB allocations, then it
>>> might not make that much of a difference.
>>
>> Looking at the x86 code, 1 gigabyte pages seems to be supported.
>>
>> Boris, do you have any opinions on this?
>
>
> I don't think I understand the superpage shattering argument.  In x86
> the tables live in regular RAM and a guest is free to use those
> addresses as regular memory.
>
> This apparently is different from how ARM manages the tables (you said
> in an earlier message that they are not part of RAM) so I can see that
> taking memory from RAM allocation to store the tables may affect how
> mapping is done, potentially causing GB pages to be broken.
>
> In fact (and I am totally speculating here) padding memory for x86 may
> actually *cause* shattering because we will have (for example) 2049MB of
> RAM to deal with.

Correct me if I am wrong. On your series you are populating the page at 
a specific address for the ACPI tables separately to the RAM allocation. 
So you will shatter GB pages if the user provides 2048MB because the 
ACPI tables is accounted in the 2048MB.

The plan is to call setmaxmem with the size of the RAM + size of the 
ACPI tales. The RAM will still be 2048MB and therefore GB pages may be used.

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky]

On 07/20/2016 09:41 AM, Julien Grall wrote:
>
>
> On 20/07/2016 14:33, Boris Ostrovsky wrote:
>> On 07/20/2016 08:33 AM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 14/07/16 14:37, Stefano Stabellini wrote:
>>>> On Wed, 13 Jul 2016, Julien Grall wrote:
>>>>> Hello,
>>>>>
>>>>> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>>>>>> On 07/12/2016 12:10 PM, Julien Grall wrote:
>>>>>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>>>>>>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>>>>>> It will affect some others part of the guest if we don't increment
>>>>>>> the
>>>>>>> "maxmem" requested by the user. For ARM the ACPI blob will be
>>>>>>> exposed
>>>>>>> at a specific address that is outside of the guest RAM (see the
>>>>>>> guest
>>>>>>> memory layout in public/arch-arm.h).
>>>>>>>
>>>>>>> We chose this solution over putting in the RAM because the ACPI
>>>>>>> tables
>>>>>>> are not easily relocatable (compare to the device tree, initrd and
>>>>>>> kernel) so we could not take advantage of superpage in both stage-2
>>>>>>> (hypervisor) and stage-1 (kernel) page table.
>>>>>>
>>>>>> Maybe this is something ARM-specific then. For x86 we will want to
>>>>>> keep
>>>>>> maxmem unchanged.
>>>>>
>>>>> I don't think what I described in my previous mail is
>>>>> ARM-specific. The
>>>>> pressure will be more important on the TLBs, if Xen does not use
>>>>> superpage in
>>>>> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
>>>>>
>>>>> IHMO, this seems to be a bigger drawback compare to add few more
>>>>> kilobytes to
>>>>> maxmem in the toolstack for the ACPI blob. You will loose them when
>>>>> creating
>>>>> the intermediate page table in any case.
>>>>
>>>> I agree with Julien. On ARM we have to increase maxmem because I don't
>>>> think that shattering a superpage is acceptable for just a few KBs. In
>>>> fact, it's not much about increasing maxmem, but it's about keeping
>>>> the
>>>> allocation of guest memory to the value passed by the user in
>>>> "memory",
>>>> so that it can be done in the most efficient way possible. (I am
>>>> assuming users are going to allocate VMs of 2048MB, rather than
>>>> 2049MB.)
>>>>
>>>> I wouldn't want to end up adding to the performance tuning page on the
>>>> wiki "Make sure to add 1 more MB to the memory of your VM to get the
>>>> most out of the system."
>>>>
>>>> I know that the location of the ACPI blob on x86 is different in guest
>>>> memory space, but it seems to me that the problem would be the
>>>> same. Do
>>>> you have 1 gigabyte pages in stage-2 on x86? If so, I would think
>>>> twice
>>>> about this. Otherwise, if you only have 4K and 2MB allocations,
>>>> then it
>>>> might not make that much of a difference.
>>>
>>> Looking at the x86 code, 1 gigabyte pages seems to be supported.
>>>
>>> Boris, do you have any opinions on this?
>>
>>
>> I don't think I understand the superpage shattering argument.  In x86
>> the tables live in regular RAM and a guest is free to use those
>> addresses as regular memory.
>>
>> This apparently is different from how ARM manages the tables (you said
>> in an earlier message that they are not part of RAM) so I can see that
>> taking memory from RAM allocation to store the tables may affect how
>> mapping is done, potentially causing GB pages to be broken.
>>
>> In fact (and I am totally speculating here) padding memory for x86 may
>> actually *cause* shattering because we will have (for example) 2049MB of
>> RAM to deal with.
>
> Correct me if I am wrong. On your series you are populating the page
> at a specific address for the ACPI tables separately to the RAM
> allocation. So you will shatter GB pages if the user provides 2048MB
> because the ACPI tables is accounted in the 2048MB.

And to be honest I am not convinced this was a well selected address
(0xfc000000). I am actually thinking about moving it down (this may
require changing dsdt.asl). I don't know whether I will actually do it
in this version but it is certainly a possibility.

-boris

>
> The plan is to call setmaxmem with the size of the RAM + size of the
> ACPI tales. The RAM will still be 2048MB and therefore GB pages may be
> used.
>



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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Stefano Stabellini]

On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
> On 07/20/2016 09:41 AM, Julien Grall wrote:
> >
> >
> > On 20/07/2016 14:33, Boris Ostrovsky wrote:
> >> On 07/20/2016 08:33 AM, Julien Grall wrote:
> >>> Hi,
> >>>
> >>> On 14/07/16 14:37, Stefano Stabellini wrote:
> >>>> On Wed, 13 Jul 2016, Julien Grall wrote:
> >>>>> Hello,
> >>>>>
> >>>>> On 12/07/2016 17:58, Boris Ostrovsky wrote:
> >>>>>> On 07/12/2016 12:10 PM, Julien Grall wrote:
> >>>>>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
> >>>>>>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> >>>>>>> It will affect some others part of the guest if we don't increment
> >>>>>>> the
> >>>>>>> "maxmem" requested by the user. For ARM the ACPI blob will be
> >>>>>>> exposed
> >>>>>>> at a specific address that is outside of the guest RAM (see the
> >>>>>>> guest
> >>>>>>> memory layout in public/arch-arm.h).
> >>>>>>>
> >>>>>>> We chose this solution over putting in the RAM because the ACPI
> >>>>>>> tables
> >>>>>>> are not easily relocatable (compare to the device tree, initrd and
> >>>>>>> kernel) so we could not take advantage of superpage in both stage-2
> >>>>>>> (hypervisor) and stage-1 (kernel) page table.
> >>>>>>
> >>>>>> Maybe this is something ARM-specific then. For x86 we will want to
> >>>>>> keep
> >>>>>> maxmem unchanged.
> >>>>>
> >>>>> I don't think what I described in my previous mail is
> >>>>> ARM-specific. The
> >>>>> pressure will be more important on the TLBs, if Xen does not use
> >>>>> superpage in
> >>>>> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
> >>>>>
> >>>>> IHMO, this seems to be a bigger drawback compare to add few more
> >>>>> kilobytes to
> >>>>> maxmem in the toolstack for the ACPI blob. You will loose them when
> >>>>> creating
> >>>>> the intermediate page table in any case.
> >>>>
> >>>> I agree with Julien. On ARM we have to increase maxmem because I don't
> >>>> think that shattering a superpage is acceptable for just a few KBs. In
> >>>> fact, it's not much about increasing maxmem, but it's about keeping
> >>>> the
> >>>> allocation of guest memory to the value passed by the user in
> >>>> "memory",
> >>>> so that it can be done in the most efficient way possible. (I am
> >>>> assuming users are going to allocate VMs of 2048MB, rather than
> >>>> 2049MB.)
> >>>>
> >>>> I wouldn't want to end up adding to the performance tuning page on the
> >>>> wiki "Make sure to add 1 more MB to the memory of your VM to get the
> >>>> most out of the system."
> >>>>
> >>>> I know that the location of the ACPI blob on x86 is different in guest
> >>>> memory space, but it seems to me that the problem would be the
> >>>> same. Do
> >>>> you have 1 gigabyte pages in stage-2 on x86? If so, I would think
> >>>> twice
> >>>> about this. Otherwise, if you only have 4K and 2MB allocations,
> >>>> then it
> >>>> might not make that much of a difference.
> >>>
> >>> Looking at the x86 code, 1 gigabyte pages seems to be supported.
> >>>
> >>> Boris, do you have any opinions on this?
> >>
> >>
> >> I don't think I understand the superpage shattering argument.  In x86
> >> the tables live in regular RAM and a guest is free to use those
> >> addresses as regular memory.
> >>
> >> This apparently is different from how ARM manages the tables (you said
> >> in an earlier message that they are not part of RAM) so I can see that
> >> taking memory from RAM allocation to store the tables may affect how
> >> mapping is done, potentially causing GB pages to be broken.
> >>
> >> In fact (and I am totally speculating here) padding memory for x86 may
> >> actually *cause* shattering because we will have (for example) 2049MB of
> >> RAM to deal with.
> >
> > Correct me if I am wrong. On your series you are populating the page
> > at a specific address for the ACPI tables separately to the RAM
> > allocation. So you will shatter GB pages if the user provides 2048MB
> > because the ACPI tables is accounted in the 2048MB.
> 
> And to be honest I am not convinced this was a well selected address
> (0xfc000000). I am actually thinking about moving it down (this may
> require changing dsdt.asl). I don't know whether I will actually do it
> in this version but it is certainly a possibility.

I don't understand how this statement fits in the discussion.

The memory allocation for the ACPI blob is done by the toolstack
separately from the rest of guest memory, leading to two separate
stage-2 pagetable allocations of less than 1-gigabyte pages. Is that
correct?

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky]

On 07/20/2016 01:28 PM, Stefano Stabellini wrote:
> On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
>> On 07/20/2016 09:41 AM, Julien Grall wrote:
>>>
>>> On 20/07/2016 14:33, Boris Ostrovsky wrote:
>>>> On 07/20/2016 08:33 AM, Julien Grall wrote:
>>>>> Hi,
>>>>>
>>>>> On 14/07/16 14:37, Stefano Stabellini wrote:
>>>>>> On Wed, 13 Jul 2016, Julien Grall wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>>>>>>>> On 07/12/2016 12:10 PM, Julien Grall wrote:
>>>>>>>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>>>>>>>>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>>>>>>>> It will affect some others part of the guest if we don't increment
>>>>>>>>> the
>>>>>>>>> "maxmem" requested by the user. For ARM the ACPI blob will be
>>>>>>>>> exposed
>>>>>>>>> at a specific address that is outside of the guest RAM (see the
>>>>>>>>> guest
>>>>>>>>> memory layout in public/arch-arm.h).
>>>>>>>>>
>>>>>>>>> We chose this solution over putting in the RAM because the ACPI
>>>>>>>>> tables
>>>>>>>>> are not easily relocatable (compare to the device tree, initrd and
>>>>>>>>> kernel) so we could not take advantage of superpage in both stage-2
>>>>>>>>> (hypervisor) and stage-1 (kernel) page table.
>>>>>>>> Maybe this is something ARM-specific then. For x86 we will want to
>>>>>>>> keep
>>>>>>>> maxmem unchanged.
>>>>>>> I don't think what I described in my previous mail is
>>>>>>> ARM-specific. The
>>>>>>> pressure will be more important on the TLBs, if Xen does not use
>>>>>>> superpage in
>>>>>>> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
>>>>>>>
>>>>>>> IHMO, this seems to be a bigger drawback compare to add few more
>>>>>>> kilobytes to
>>>>>>> maxmem in the toolstack for the ACPI blob. You will loose them when
>>>>>>> creating
>>>>>>> the intermediate page table in any case.
>>>>>> I agree with Julien. On ARM we have to increase maxmem because I don't
>>>>>> think that shattering a superpage is acceptable for just a few KBs. In
>>>>>> fact, it's not much about increasing maxmem, but it's about keeping
>>>>>> the
>>>>>> allocation of guest memory to the value passed by the user in
>>>>>> "memory",
>>>>>> so that it can be done in the most efficient way possible. (I am
>>>>>> assuming users are going to allocate VMs of 2048MB, rather than
>>>>>> 2049MB.)
>>>>>>
>>>>>> I wouldn't want to end up adding to the performance tuning page on the
>>>>>> wiki "Make sure to add 1 more MB to the memory of your VM to get the
>>>>>> most out of the system."
>>>>>>
>>>>>> I know that the location of the ACPI blob on x86 is different in guest
>>>>>> memory space, but it seems to me that the problem would be the
>>>>>> same. Do
>>>>>> you have 1 gigabyte pages in stage-2 on x86? If so, I would think
>>>>>> twice
>>>>>> about this. Otherwise, if you only have 4K and 2MB allocations,
>>>>>> then it
>>>>>> might not make that much of a difference.
>>>>> Looking at the x86 code, 1 gigabyte pages seems to be supported.
>>>>>
>>>>> Boris, do you have any opinions on this?
>>>>
>>>> I don't think I understand the superpage shattering argument.  In x86
>>>> the tables live in regular RAM and a guest is free to use those
>>>> addresses as regular memory.
>>>>
>>>> This apparently is different from how ARM manages the tables (you said
>>>> in an earlier message that they are not part of RAM) so I can see that
>>>> taking memory from RAM allocation to store the tables may affect how
>>>> mapping is done, potentially causing GB pages to be broken.
>>>>
>>>> In fact (and I am totally speculating here) padding memory for x86 may
>>>> actually *cause* shattering because we will have (for example) 2049MB of
>>>> RAM to deal with.
>>> Correct me if I am wrong. On your series you are populating the page
>>> at a specific address for the ACPI tables separately to the RAM
>>> allocation. So you will shatter GB pages if the user provides 2048MB
>>> because the ACPI tables is accounted in the 2048MB.
>> And to be honest I am not convinced this was a well selected address
>> (0xfc000000). I am actually thinking about moving it down (this may
>> require changing dsdt.asl). I don't know whether I will actually do it
>> in this version but it is certainly a possibility.
> I don't understand how this statement fits in the discussion.
>
> The memory allocation for the ACPI blob is done by the toolstack
> separately from the rest of guest memory, leading to two separate
> stage-2 pagetable allocations of less than 1-gigabyte pages. Is that
> correct?


If I move the table lower into memory we won't have to do any extra
allocation. The memory will have been already allocated for the guest,
we just map it and copy the tables.


-boris


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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Stefano Stabellini]

On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
> On 07/20/2016 01:28 PM, Stefano Stabellini wrote:
> > On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
> >> On 07/20/2016 09:41 AM, Julien Grall wrote:
> >>>
> >>> On 20/07/2016 14:33, Boris Ostrovsky wrote:
> >>>> On 07/20/2016 08:33 AM, Julien Grall wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 14/07/16 14:37, Stefano Stabellini wrote:
> >>>>>> On Wed, 13 Jul 2016, Julien Grall wrote:
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> On 12/07/2016 17:58, Boris Ostrovsky wrote:
> >>>>>>>> On 07/12/2016 12:10 PM, Julien Grall wrote:
> >>>>>>>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
> >>>>>>>>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> >>>>>>>>> It will affect some others part of the guest if we don't increment
> >>>>>>>>> the
> >>>>>>>>> "maxmem" requested by the user. For ARM the ACPI blob will be
> >>>>>>>>> exposed
> >>>>>>>>> at a specific address that is outside of the guest RAM (see the
> >>>>>>>>> guest
> >>>>>>>>> memory layout in public/arch-arm.h).
> >>>>>>>>>
> >>>>>>>>> We chose this solution over putting in the RAM because the ACPI
> >>>>>>>>> tables
> >>>>>>>>> are not easily relocatable (compare to the device tree, initrd and
> >>>>>>>>> kernel) so we could not take advantage of superpage in both stage-2
> >>>>>>>>> (hypervisor) and stage-1 (kernel) page table.
> >>>>>>>> Maybe this is something ARM-specific then. For x86 we will want to
> >>>>>>>> keep
> >>>>>>>> maxmem unchanged.
> >>>>>>> I don't think what I described in my previous mail is
> >>>>>>> ARM-specific. The
> >>>>>>> pressure will be more important on the TLBs, if Xen does not use
> >>>>>>> superpage in
> >>>>>>> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
> >>>>>>>
> >>>>>>> IHMO, this seems to be a bigger drawback compare to add few more
> >>>>>>> kilobytes to
> >>>>>>> maxmem in the toolstack for the ACPI blob. You will loose them when
> >>>>>>> creating
> >>>>>>> the intermediate page table in any case.
> >>>>>> I agree with Julien. On ARM we have to increase maxmem because I don't
> >>>>>> think that shattering a superpage is acceptable for just a few KBs. In
> >>>>>> fact, it's not much about increasing maxmem, but it's about keeping
> >>>>>> the
> >>>>>> allocation of guest memory to the value passed by the user in
> >>>>>> "memory",
> >>>>>> so that it can be done in the most efficient way possible. (I am
> >>>>>> assuming users are going to allocate VMs of 2048MB, rather than
> >>>>>> 2049MB.)
> >>>>>>
> >>>>>> I wouldn't want to end up adding to the performance tuning page on the
> >>>>>> wiki "Make sure to add 1 more MB to the memory of your VM to get the
> >>>>>> most out of the system."
> >>>>>>
> >>>>>> I know that the location of the ACPI blob on x86 is different in guest
> >>>>>> memory space, but it seems to me that the problem would be the
> >>>>>> same. Do
> >>>>>> you have 1 gigabyte pages in stage-2 on x86? If so, I would think
> >>>>>> twice
> >>>>>> about this. Otherwise, if you only have 4K and 2MB allocations,
> >>>>>> then it
> >>>>>> might not make that much of a difference.
> >>>>> Looking at the x86 code, 1 gigabyte pages seems to be supported.
> >>>>>
> >>>>> Boris, do you have any opinions on this?
> >>>>
> >>>> I don't think I understand the superpage shattering argument.  In x86
> >>>> the tables live in regular RAM and a guest is free to use those
> >>>> addresses as regular memory.
> >>>>
> >>>> This apparently is different from how ARM manages the tables (you said
> >>>> in an earlier message that they are not part of RAM) so I can see that
> >>>> taking memory from RAM allocation to store the tables may affect how
> >>>> mapping is done, potentially causing GB pages to be broken.
> >>>>
> >>>> In fact (and I am totally speculating here) padding memory for x86 may
> >>>> actually *cause* shattering because we will have (for example) 2049MB of
> >>>> RAM to deal with.
> >>> Correct me if I am wrong. On your series you are populating the page
> >>> at a specific address for the ACPI tables separately to the RAM
> >>> allocation. So you will shatter GB pages if the user provides 2048MB
> >>> because the ACPI tables is accounted in the 2048MB.
> >> And to be honest I am not convinced this was a well selected address
> >> (0xfc000000). I am actually thinking about moving it down (this may
> >> require changing dsdt.asl). I don't know whether I will actually do it
> >> in this version but it is certainly a possibility.
> > I don't understand how this statement fits in the discussion.
> >
> > The memory allocation for the ACPI blob is done by the toolstack
> > separately from the rest of guest memory, leading to two separate
> > stage-2 pagetable allocations of less than 1-gigabyte pages. Is that
> > correct?
> 
> 
> If I move the table lower into memory we won't have to do any extra
> allocation. The memory will have been already allocated for the guest,
> we just map it and copy the tables.

I see, thanks for the explanation. I think this could work for ARM too
and should avoid the stage-2 shattering issue described above.

Julien, what do you think? I agree that having the ACPI blob separate
would be cleaner, but using the same allocation scheme as x86 is
important.

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hi Stefano,

On 21/07/16 18:53, Stefano Stabellini wrote:
> On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
>> On 07/20/2016 01:28 PM, Stefano Stabellini wrote:
>>> On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
>>>> On 07/20/2016 09:41 AM, Julien Grall wrote:
>>>>>
>>>>> On 20/07/2016 14:33, Boris Ostrovsky wrote:
>>>>>> On 07/20/2016 08:33 AM, Julien Grall wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 14/07/16 14:37, Stefano Stabellini wrote:
>>>>>>>> On Wed, 13 Jul 2016, Julien Grall wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>>>>>>>>>> On 07/12/2016 12:10 PM, Julien Grall wrote:
>>>>>>>>>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>>>>>>>>>>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>>>>>>>>>> It will affect some others part of the guest if we don't increment
>>>>>>>>>>> the
>>>>>>>>>>> "maxmem" requested by the user. For ARM the ACPI blob will be
>>>>>>>>>>> exposed
>>>>>>>>>>> at a specific address that is outside of the guest RAM (see the
>>>>>>>>>>> guest
>>>>>>>>>>> memory layout in public/arch-arm.h).
>>>>>>>>>>>
>>>>>>>>>>> We chose this solution over putting in the RAM because the ACPI
>>>>>>>>>>> tables
>>>>>>>>>>> are not easily relocatable (compare to the device tree, initrd and
>>>>>>>>>>> kernel) so we could not take advantage of superpage in both stage-2
>>>>>>>>>>> (hypervisor) and stage-1 (kernel) page table.
>>>>>>>>>> Maybe this is something ARM-specific then. For x86 we will want to
>>>>>>>>>> keep
>>>>>>>>>> maxmem unchanged.
>>>>>>>>> I don't think what I described in my previous mail is
>>>>>>>>> ARM-specific. The
>>>>>>>>> pressure will be more important on the TLBs, if Xen does not use
>>>>>>>>> superpage in
>>>>>>>>> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
>>>>>>>>>
>>>>>>>>> IHMO, this seems to be a bigger drawback compare to add few more
>>>>>>>>> kilobytes to
>>>>>>>>> maxmem in the toolstack for the ACPI blob. You will loose them when
>>>>>>>>> creating
>>>>>>>>> the intermediate page table in any case.
>>>>>>>> I agree with Julien. On ARM we have to increase maxmem because I don't
>>>>>>>> think that shattering a superpage is acceptable for just a few KBs. In
>>>>>>>> fact, it's not much about increasing maxmem, but it's about keeping
>>>>>>>> the
>>>>>>>> allocation of guest memory to the value passed by the user in
>>>>>>>> "memory",
>>>>>>>> so that it can be done in the most efficient way possible. (I am
>>>>>>>> assuming users are going to allocate VMs of 2048MB, rather than
>>>>>>>> 2049MB.)
>>>>>>>>
>>>>>>>> I wouldn't want to end up adding to the performance tuning page on the
>>>>>>>> wiki "Make sure to add 1 more MB to the memory of your VM to get the
>>>>>>>> most out of the system."
>>>>>>>>
>>>>>>>> I know that the location of the ACPI blob on x86 is different in guest
>>>>>>>> memory space, but it seems to me that the problem would be the
>>>>>>>> same. Do
>>>>>>>> you have 1 gigabyte pages in stage-2 on x86? If so, I would think
>>>>>>>> twice
>>>>>>>> about this. Otherwise, if you only have 4K and 2MB allocations,
>>>>>>>> then it
>>>>>>>> might not make that much of a difference.
>>>>>>> Looking at the x86 code, 1 gigabyte pages seems to be supported.
>>>>>>>
>>>>>>> Boris, do you have any opinions on this?
>>>>>>
>>>>>> I don't think I understand the superpage shattering argument.  In x86
>>>>>> the tables live in regular RAM and a guest is free to use those
>>>>>> addresses as regular memory.
>>>>>>
>>>>>> This apparently is different from how ARM manages the tables (you said
>>>>>> in an earlier message that they are not part of RAM) so I can see that
>>>>>> taking memory from RAM allocation to store the tables may affect how
>>>>>> mapping is done, potentially causing GB pages to be broken.
>>>>>>
>>>>>> In fact (and I am totally speculating here) padding memory for x86 may
>>>>>> actually *cause* shattering because we will have (for example) 2049MB of
>>>>>> RAM to deal with.
>>>>> Correct me if I am wrong. On your series you are populating the page
>>>>> at a specific address for the ACPI tables separately to the RAM
>>>>> allocation. So you will shatter GB pages if the user provides 2048MB
>>>>> because the ACPI tables is accounted in the 2048MB.
>>>> And to be honest I am not convinced this was a well selected address
>>>> (0xfc000000). I am actually thinking about moving it down (this may
>>>> require changing dsdt.asl). I don't know whether I will actually do it
>>>> in this version but it is certainly a possibility.
>>> I don't understand how this statement fits in the discussion.
>>>
>>> The memory allocation for the ACPI blob is done by the toolstack
>>> separately from the rest of guest memory, leading to two separate
>>> stage-2 pagetable allocations of less than 1-gigabyte pages. Is that
>>> correct?
>>
>>
>> If I move the table lower into memory we won't have to do any extra
>> allocation. The memory will have been already allocated for the guest,
>> we just map it and copy the tables.
>
> I see, thanks for the explanation. I think this could work for ARM too
> and should avoid the stage-2 shattering issue described above.

But you will end up to have stage-1 shattering issue if you put the ACPI 
tables lower into the guest RAM, reducing the overall performance. It is 
why I first asked Shannon to put the ACPI outside of the guest RAM.

> Julien, what do you think? I agree that having the ACPI blob separate
> would be cleaner, but using the same allocation scheme as x86 is
> important.

While I agree that having the same scheme is important, I care a lot 
more about performance.

So far, I have concerns about performance on all Boris suggestions. I 
believe that the impact is the same on x86. However it seems that it is 
not important for the x86 folks.

I think the scheme I suggested is the best one, because it will maximize 
the theoretical performance of the guests (a guest is free to not use 
superpage).

I could be convinced to put the ACPI tables at the end of the guest RAM, 
although this would require more code in the toolstack because the ACPI 
base address will not be static anymore.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Stefano Stabellini]

On Thu, 21 Jul 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 21/07/16 18:53, Stefano Stabellini wrote:
> > On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
> > > On 07/20/2016 01:28 PM, Stefano Stabellini wrote:
> > > > On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
> > > > > On 07/20/2016 09:41 AM, Julien Grall wrote:
> > > > > > 
> > > > > > On 20/07/2016 14:33, Boris Ostrovsky wrote:
> > > > > > > On 07/20/2016 08:33 AM, Julien Grall wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On 14/07/16 14:37, Stefano Stabellini wrote:
> > > > > > > > > On Wed, 13 Jul 2016, Julien Grall wrote:
> > > > > > > > > > Hello,
> > > > > > > > > > 
> > > > > > > > > > On 12/07/2016 17:58, Boris Ostrovsky wrote:
> > > > > > > > > > > On 07/12/2016 12:10 PM, Julien Grall wrote:
> > > > > > > > > > > > On 12/07/2016 16:08, Boris Ostrovsky wrote:
> > > > > > > > > > > > > On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> > > > > > > > > > > > It will affect some others part of the guest if we don't
> > > > > > > > > > > > increment
> > > > > > > > > > > > the
> > > > > > > > > > > > "maxmem" requested by the user. For ARM the ACPI blob
> > > > > > > > > > > > will be
> > > > > > > > > > > > exposed
> > > > > > > > > > > > at a specific address that is outside of the guest RAM
> > > > > > > > > > > > (see the
> > > > > > > > > > > > guest
> > > > > > > > > > > > memory layout in public/arch-arm.h).
> > > > > > > > > > > > 
> > > > > > > > > > > > We chose this solution over putting in the RAM because
> > > > > > > > > > > > the ACPI
> > > > > > > > > > > > tables
> > > > > > > > > > > > are not easily relocatable (compare to the device tree,
> > > > > > > > > > > > initrd and
> > > > > > > > > > > > kernel) so we could not take advantage of superpage in
> > > > > > > > > > > > both stage-2
> > > > > > > > > > > > (hypervisor) and stage-1 (kernel) page table.
> > > > > > > > > > > Maybe this is something ARM-specific then. For x86 we will
> > > > > > > > > > > want to
> > > > > > > > > > > keep
> > > > > > > > > > > maxmem unchanged.
> > > > > > > > > > I don't think what I described in my previous mail is
> > > > > > > > > > ARM-specific. The
> > > > > > > > > > pressure will be more important on the TLBs, if Xen does not
> > > > > > > > > > use
> > > > > > > > > > superpage in
> > > > > > > > > > the stage 2 page tables (i.e EPT for x86) no matter the
> > > > > > > > > > architecture.
> > > > > > > > > > 
> > > > > > > > > > IHMO, this seems to be a bigger drawback compare to add few
> > > > > > > > > > more
> > > > > > > > > > kilobytes to
> > > > > > > > > > maxmem in the toolstack for the ACPI blob. You will loose
> > > > > > > > > > them when
> > > > > > > > > > creating
> > > > > > > > > > the intermediate page table in any case.
> > > > > > > > > I agree with Julien. On ARM we have to increase maxmem because
> > > > > > > > > I don't
> > > > > > > > > think that shattering a superpage is acceptable for just a few
> > > > > > > > > KBs. In
> > > > > > > > > fact, it's not much about increasing maxmem, but it's about
> > > > > > > > > keeping
> > > > > > > > > the
> > > > > > > > > allocation of guest memory to the value passed by the user in
> > > > > > > > > "memory",
> > > > > > > > > so that it can be done in the most efficient way possible. (I
> > > > > > > > > am
> > > > > > > > > assuming users are going to allocate VMs of 2048MB, rather
> > > > > > > > > than
> > > > > > > > > 2049MB.)
> > > > > > > > > 
> > > > > > > > > I wouldn't want to end up adding to the performance tuning
> > > > > > > > > page on the
> > > > > > > > > wiki "Make sure to add 1 more MB to the memory of your VM to
> > > > > > > > > get the
> > > > > > > > > most out of the system."
> > > > > > > > > 
> > > > > > > > > I know that the location of the ACPI blob on x86 is different
> > > > > > > > > in guest
> > > > > > > > > memory space, but it seems to me that the problem would be the
> > > > > > > > > same. Do
> > > > > > > > > you have 1 gigabyte pages in stage-2 on x86? If so, I would
> > > > > > > > > think
> > > > > > > > > twice
> > > > > > > > > about this. Otherwise, if you only have 4K and 2MB
> > > > > > > > > allocations,
> > > > > > > > > then it
> > > > > > > > > might not make that much of a difference.
> > > > > > > > Looking at the x86 code, 1 gigabyte pages seems to be supported.
> > > > > > > > 
> > > > > > > > Boris, do you have any opinions on this?
> > > > > > > 
> > > > > > > I don't think I understand the superpage shattering argument.  In
> > > > > > > x86
> > > > > > > the tables live in regular RAM and a guest is free to use those
> > > > > > > addresses as regular memory.
> > > > > > > 
> > > > > > > This apparently is different from how ARM manages the tables (you
> > > > > > > said
> > > > > > > in an earlier message that they are not part of RAM) so I can see
> > > > > > > that
> > > > > > > taking memory from RAM allocation to store the tables may affect
> > > > > > > how
> > > > > > > mapping is done, potentially causing GB pages to be broken.
> > > > > > > 
> > > > > > > In fact (and I am totally speculating here) padding memory for x86
> > > > > > > may
> > > > > > > actually *cause* shattering because we will have (for example)
> > > > > > > 2049MB of
> > > > > > > RAM to deal with.
> > > > > > Correct me if I am wrong. On your series you are populating the page
> > > > > > at a specific address for the ACPI tables separately to the RAM
> > > > > > allocation. So you will shatter GB pages if the user provides 2048MB
> > > > > > because the ACPI tables is accounted in the 2048MB.
> > > > > And to be honest I am not convinced this was a well selected address
> > > > > (0xfc000000). I am actually thinking about moving it down (this may
> > > > > require changing dsdt.asl). I don't know whether I will actually do it
> > > > > in this version but it is certainly a possibility.
> > > > I don't understand how this statement fits in the discussion.
> > > > 
> > > > The memory allocation for the ACPI blob is done by the toolstack
> > > > separately from the rest of guest memory, leading to two separate
> > > > stage-2 pagetable allocations of less than 1-gigabyte pages. Is that
> > > > correct?
> > > 
> > > 
> > > If I move the table lower into memory we won't have to do any extra
> > > allocation. The memory will have been already allocated for the guest,
> > > we just map it and copy the tables.
> > 
> > I see, thanks for the explanation. I think this could work for ARM too
> > and should avoid the stage-2 shattering issue described above.
> 
> But you will end up to have stage-1 shattering issue if you put the ACPI
> tables lower into the guest RAM, reducing the overall performance. It is why I
> first asked Shannon to put the ACPI outside of the guest RAM.

I am not sure about this actually: even with the ACPI blob in the middle
of guest memory, the guest OS could still use a single superpage for its
own stage-1 memory mappings. I don't know if Linux does it that way, but
it should be possible.

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

On 21/07/2016 19:54, Stefano Stabellini wrote:
> On Thu, 21 Jul 2016, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 21/07/16 18:53, Stefano Stabellini wrote:
>>> On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
>>>> On 07/20/2016 01:28 PM, Stefano Stabellini wrote:
>>>>> On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
>>>>>> On 07/20/2016 09:41 AM, Julien Grall wrote:
>>>>>>>
>>>>>>> On 20/07/2016 14:33, Boris Ostrovsky wrote:
>>>>>>>> On 07/20/2016 08:33 AM, Julien Grall wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 14/07/16 14:37, Stefano Stabellini wrote:
>>>>>>>>>> On Wed, 13 Jul 2016, Julien Grall wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>>>>>>>>>>>> On 07/12/2016 12:10 PM, Julien Grall wrote:
>>>>>>>>>>>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>>>>>>>>>>>>>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>>>>>>>>>>>> It will affect some others part of the guest if we don't
>>>>>>>>>>>>> increment
>>>>>>>>>>>>> the
>>>>>>>>>>>>> "maxmem" requested by the user. For ARM the ACPI blob
>>>>>>>>>>>>> will be
>>>>>>>>>>>>> exposed
>>>>>>>>>>>>> at a specific address that is outside of the guest RAM
>>>>>>>>>>>>> (see the
>>>>>>>>>>>>> guest
>>>>>>>>>>>>> memory layout in public/arch-arm.h).
>>>>>>>>>>>>>
>>>>>>>>>>>>> We chose this solution over putting in the RAM because
>>>>>>>>>>>>> the ACPI
>>>>>>>>>>>>> tables
>>>>>>>>>>>>> are not easily relocatable (compare to the device tree,
>>>>>>>>>>>>> initrd and
>>>>>>>>>>>>> kernel) so we could not take advantage of superpage in
>>>>>>>>>>>>> both stage-2
>>>>>>>>>>>>> (hypervisor) and stage-1 (kernel) page table.
>>>>>>>>>>>> Maybe this is something ARM-specific then. For x86 we will
>>>>>>>>>>>> want to
>>>>>>>>>>>> keep
>>>>>>>>>>>> maxmem unchanged.
>>>>>>>>>>> I don't think what I described in my previous mail is
>>>>>>>>>>> ARM-specific. The
>>>>>>>>>>> pressure will be more important on the TLBs, if Xen does not
>>>>>>>>>>> use
>>>>>>>>>>> superpage in
>>>>>>>>>>> the stage 2 page tables (i.e EPT for x86) no matter the
>>>>>>>>>>> architecture.
>>>>>>>>>>>
>>>>>>>>>>> IHMO, this seems to be a bigger drawback compare to add few
>>>>>>>>>>> more
>>>>>>>>>>> kilobytes to
>>>>>>>>>>> maxmem in the toolstack for the ACPI blob. You will loose
>>>>>>>>>>> them when
>>>>>>>>>>> creating
>>>>>>>>>>> the intermediate page table in any case.
>>>>>>>>>> I agree with Julien. On ARM we have to increase maxmem because
>>>>>>>>>> I don't
>>>>>>>>>> think that shattering a superpage is acceptable for just a few
>>>>>>>>>> KBs. In
>>>>>>>>>> fact, it's not much about increasing maxmem, but it's about
>>>>>>>>>> keeping
>>>>>>>>>> the
>>>>>>>>>> allocation of guest memory to the value passed by the user in
>>>>>>>>>> "memory",
>>>>>>>>>> so that it can be done in the most efficient way possible. (I
>>>>>>>>>> am
>>>>>>>>>> assuming users are going to allocate VMs of 2048MB, rather
>>>>>>>>>> than
>>>>>>>>>> 2049MB.)
>>>>>>>>>>
>>>>>>>>>> I wouldn't want to end up adding to the performance tuning
>>>>>>>>>> page on the
>>>>>>>>>> wiki "Make sure to add 1 more MB to the memory of your VM to
>>>>>>>>>> get the
>>>>>>>>>> most out of the system."
>>>>>>>>>>
>>>>>>>>>> I know that the location of the ACPI blob on x86 is different
>>>>>>>>>> in guest
>>>>>>>>>> memory space, but it seems to me that the problem would be the
>>>>>>>>>> same. Do
>>>>>>>>>> you have 1 gigabyte pages in stage-2 on x86? If so, I would
>>>>>>>>>> think
>>>>>>>>>> twice
>>>>>>>>>> about this. Otherwise, if you only have 4K and 2MB
>>>>>>>>>> allocations,
>>>>>>>>>> then it
>>>>>>>>>> might not make that much of a difference.
>>>>>>>>> Looking at the x86 code, 1 gigabyte pages seems to be supported.
>>>>>>>>>
>>>>>>>>> Boris, do you have any opinions on this?
>>>>>>>>
>>>>>>>> I don't think I understand the superpage shattering argument.  In
>>>>>>>> x86
>>>>>>>> the tables live in regular RAM and a guest is free to use those
>>>>>>>> addresses as regular memory.
>>>>>>>>
>>>>>>>> This apparently is different from how ARM manages the tables (you
>>>>>>>> said
>>>>>>>> in an earlier message that they are not part of RAM) so I can see
>>>>>>>> that
>>>>>>>> taking memory from RAM allocation to store the tables may affect
>>>>>>>> how
>>>>>>>> mapping is done, potentially causing GB pages to be broken.
>>>>>>>>
>>>>>>>> In fact (and I am totally speculating here) padding memory for x86
>>>>>>>> may
>>>>>>>> actually *cause* shattering because we will have (for example)
>>>>>>>> 2049MB of
>>>>>>>> RAM to deal with.
>>>>>>> Correct me if I am wrong. On your series you are populating the page
>>>>>>> at a specific address for the ACPI tables separately to the RAM
>>>>>>> allocation. So you will shatter GB pages if the user provides 2048MB
>>>>>>> because the ACPI tables is accounted in the 2048MB.
>>>>>> And to be honest I am not convinced this was a well selected address
>>>>>> (0xfc000000). I am actually thinking about moving it down (this may
>>>>>> require changing dsdt.asl). I don't know whether I will actually do it
>>>>>> in this version but it is certainly a possibility.
>>>>> I don't understand how this statement fits in the discussion.
>>>>>
>>>>> The memory allocation for the ACPI blob is done by the toolstack
>>>>> separately from the rest of guest memory, leading to two separate
>>>>> stage-2 pagetable allocations of less than 1-gigabyte pages. Is that
>>>>> correct?
>>>>
>>>>
>>>> If I move the table lower into memory we won't have to do any extra
>>>> allocation. The memory will have been already allocated for the guest,
>>>> we just map it and copy the tables.
>>>
>>> I see, thanks for the explanation. I think this could work for ARM too
>>> and should avoid the stage-2 shattering issue described above.
>>
>> But you will end up to have stage-1 shattering issue if you put the ACPI
>> tables lower into the guest RAM, reducing the overall performance. It is why I
>> first asked Shannon to put the ACPI outside of the guest RAM.
>
> I am not sure about this actually: even with the ACPI blob in the middle
> of guest memory, the guest OS could still use a single superpage for its
> own stage-1 memory mappings. I don't know if Linux does it that way, but
> it should be possible.

You are assuming that the guest will map the ACPI blob with the same 
attributes as the rest of the superpage.

IHMO, a sane operating system will want to map the ACPI blob read-only.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Stefano Stabellini]

On Thu, 21 Jul 2016, Julien Grall wrote:
> On 21/07/2016 19:54, Stefano Stabellini wrote:
> > On Thu, 21 Jul 2016, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 21/07/16 18:53, Stefano Stabellini wrote:
> > > > On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
> > > > > On 07/20/2016 01:28 PM, Stefano Stabellini wrote:
> > > > > > On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
> > > > > > > On 07/20/2016 09:41 AM, Julien Grall wrote:
> > > > > > > > 
> > > > > > > > On 20/07/2016 14:33, Boris Ostrovsky wrote:
> > > > > > > > > On 07/20/2016 08:33 AM, Julien Grall wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > On 14/07/16 14:37, Stefano Stabellini wrote:
> > > > > > > > > > > On Wed, 13 Jul 2016, Julien Grall wrote:
> > > > > > > > > > > > Hello,
> > > > > > > > > > > > 
> > > > > > > > > > > > On 12/07/2016 17:58, Boris Ostrovsky wrote:
> > > > > > > > > > > > > On 07/12/2016 12:10 PM, Julien Grall wrote:
> > > > > > > > > > > > > > On 12/07/2016 16:08, Boris Ostrovsky wrote:
> > > > > > > > > > > > > > > On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> > > > > > > > > > > > > > It will affect some others part of the guest if we
> > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > increment
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > "maxmem" requested by the user. For ARM the ACPI
> > > > > > > > > > > > > > blob
> > > > > > > > > > > > > > will be
> > > > > > > > > > > > > > exposed
> > > > > > > > > > > > > > at a specific address that is outside of the guest
> > > > > > > > > > > > > > RAM
> > > > > > > > > > > > > > (see the
> > > > > > > > > > > > > > guest
> > > > > > > > > > > > > > memory layout in public/arch-arm.h).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > We chose this solution over putting in the RAM
> > > > > > > > > > > > > > because
> > > > > > > > > > > > > > the ACPI
> > > > > > > > > > > > > > tables
> > > > > > > > > > > > > > are not easily relocatable (compare to the device
> > > > > > > > > > > > > > tree,
> > > > > > > > > > > > > > initrd and
> > > > > > > > > > > > > > kernel) so we could not take advantage of superpage
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > both stage-2
> > > > > > > > > > > > > > (hypervisor) and stage-1 (kernel) page table.
> > > > > > > > > > > > > Maybe this is something ARM-specific then. For x86 we
> > > > > > > > > > > > > will
> > > > > > > > > > > > > want to
> > > > > > > > > > > > > keep
> > > > > > > > > > > > > maxmem unchanged.
> > > > > > > > > > > > I don't think what I described in my previous mail is
> > > > > > > > > > > > ARM-specific. The
> > > > > > > > > > > > pressure will be more important on the TLBs, if Xen does
> > > > > > > > > > > > not
> > > > > > > > > > > > use
> > > > > > > > > > > > superpage in
> > > > > > > > > > > > the stage 2 page tables (i.e EPT for x86) no matter the
> > > > > > > > > > > > architecture.
> > > > > > > > > > > > 
> > > > > > > > > > > > IHMO, this seems to be a bigger drawback compare to add
> > > > > > > > > > > > few
> > > > > > > > > > > > more
> > > > > > > > > > > > kilobytes to
> > > > > > > > > > > > maxmem in the toolstack for the ACPI blob. You will
> > > > > > > > > > > > loose
> > > > > > > > > > > > them when
> > > > > > > > > > > > creating
> > > > > > > > > > > > the intermediate page table in any case.
> > > > > > > > > > > I agree with Julien. On ARM we have to increase maxmem
> > > > > > > > > > > because
> > > > > > > > > > > I don't
> > > > > > > > > > > think that shattering a superpage is acceptable for just a
> > > > > > > > > > > few
> > > > > > > > > > > KBs. In
> > > > > > > > > > > fact, it's not much about increasing maxmem, but it's
> > > > > > > > > > > about
> > > > > > > > > > > keeping
> > > > > > > > > > > the
> > > > > > > > > > > allocation of guest memory to the value passed by the user
> > > > > > > > > > > in
> > > > > > > > > > > "memory",
> > > > > > > > > > > so that it can be done in the most efficient way possible.
> > > > > > > > > > > (I
> > > > > > > > > > > am
> > > > > > > > > > > assuming users are going to allocate VMs of 2048MB, rather
> > > > > > > > > > > than
> > > > > > > > > > > 2049MB.)
> > > > > > > > > > > 
> > > > > > > > > > > I wouldn't want to end up adding to the performance tuning
> > > > > > > > > > > page on the
> > > > > > > > > > > wiki "Make sure to add 1 more MB to the memory of your VM
> > > > > > > > > > > to
> > > > > > > > > > > get the
> > > > > > > > > > > most out of the system."
> > > > > > > > > > > 
> > > > > > > > > > > I know that the location of the ACPI blob on x86 is
> > > > > > > > > > > different
> > > > > > > > > > > in guest
> > > > > > > > > > > memory space, but it seems to me that the problem would be
> > > > > > > > > > > the
> > > > > > > > > > > same. Do
> > > > > > > > > > > you have 1 gigabyte pages in stage-2 on x86? If so, I
> > > > > > > > > > > would
> > > > > > > > > > > think
> > > > > > > > > > > twice
> > > > > > > > > > > about this. Otherwise, if you only have 4K and 2MB
> > > > > > > > > > > allocations,
> > > > > > > > > > > then it
> > > > > > > > > > > might not make that much of a difference.
> > > > > > > > > > Looking at the x86 code, 1 gigabyte pages seems to be
> > > > > > > > > > supported.
> > > > > > > > > > 
> > > > > > > > > > Boris, do you have any opinions on this?
> > > > > > > > > 
> > > > > > > > > I don't think I understand the superpage shattering argument.
> > > > > > > > > In
> > > > > > > > > x86
> > > > > > > > > the tables live in regular RAM and a guest is free to use
> > > > > > > > > those
> > > > > > > > > addresses as regular memory.
> > > > > > > > > 
> > > > > > > > > This apparently is different from how ARM manages the tables
> > > > > > > > > (you
> > > > > > > > > said
> > > > > > > > > in an earlier message that they are not part of RAM) so I can
> > > > > > > > > see
> > > > > > > > > that
> > > > > > > > > taking memory from RAM allocation to store the tables may
> > > > > > > > > affect
> > > > > > > > > how
> > > > > > > > > mapping is done, potentially causing GB pages to be broken.
> > > > > > > > > 
> > > > > > > > > In fact (and I am totally speculating here) padding memory for
> > > > > > > > > x86
> > > > > > > > > may
> > > > > > > > > actually *cause* shattering because we will have (for example)
> > > > > > > > > 2049MB of
> > > > > > > > > RAM to deal with.
> > > > > > > > Correct me if I am wrong. On your series you are populating the
> > > > > > > > page
> > > > > > > > at a specific address for the ACPI tables separately to the RAM
> > > > > > > > allocation. So you will shatter GB pages if the user provides
> > > > > > > > 2048MB
> > > > > > > > because the ACPI tables is accounted in the 2048MB.
> > > > > > > And to be honest I am not convinced this was a well selected
> > > > > > > address
> > > > > > > (0xfc000000). I am actually thinking about moving it down (this
> > > > > > > may
> > > > > > > require changing dsdt.asl). I don't know whether I will actually
> > > > > > > do it
> > > > > > > in this version but it is certainly a possibility.
> > > > > > I don't understand how this statement fits in the discussion.
> > > > > > 
> > > > > > The memory allocation for the ACPI blob is done by the toolstack
> > > > > > separately from the rest of guest memory, leading to two separate
> > > > > > stage-2 pagetable allocations of less than 1-gigabyte pages. Is that
> > > > > > correct?
> > > > > 
> > > > > 
> > > > > If I move the table lower into memory we won't have to do any extra
> > > > > allocation. The memory will have been already allocated for the guest,
> > > > > we just map it and copy the tables.
> > > > 
> > > > I see, thanks for the explanation. I think this could work for ARM too
> > > > and should avoid the stage-2 shattering issue described above.
> > > 
> > > But you will end up to have stage-1 shattering issue if you put the ACPI
> > > tables lower into the guest RAM, reducing the overall performance. It is
> > > why I
> > > first asked Shannon to put the ACPI outside of the guest RAM.
> > 
> > I am not sure about this actually: even with the ACPI blob in the middle
> > of guest memory, the guest OS could still use a single superpage for its
> > own stage-1 memory mappings. I don't know if Linux does it that way, but
> > it should be possible.
> 
> You are assuming that the guest will map the ACPI blob with the same
> attributes as the rest of the superpage.
> 
> IHMO, a sane operating system will want to map the ACPI blob read-only.

That's true. But there are other things which might be mapped
differently and could shatter a stage-1 superpage mapping (especially on
x86 that has a much more complex memory map than ARM). Obviously adding
one more is not doing it any good, but it might not make a difference in
practice.

Anyway, I agree with Julien that his suggestion is the best for ARM. If
the libxl maintainers are willing to accept two different code paths for
this on ARM and x86, then I am fine with it too.

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Shannon Zhao]

On 2016/7/20 17:32, Wei Liu wrote:
> On Wed, Jul 20, 2016 at 02:52:05PM +0800, Shannon Zhao wrote:
>> > 
>> > 
>> > On 2016/7/19 18:38, Wei Liu wrote:
>>> > > On Fri, Jul 15, 2016 at 05:39:32PM +0800, Shannon Zhao wrote:
>>> > > [...]
>>>>>>> > >>> > > 
>>>>>>> > >>> > > It would be trivial to have another option in xl.cfg to allow MB
>>>>>>> > >>> > > granularity. But I don't think that's a good idea. Asking for more
>>>>>>> > >>> > > memory when you don't really know how much is enough is not very useful.
>>>>>>> > >>> > > If an admin can know how much is needed, surely the library can be
>>>>>>> > >>> > > taught to obtain that knowledge, too.
>>>>>>> > >>> > > 
>>>>>>> > >>> > > We need to decide which model we should go with. And, if we decide to
>>>>>>> > >>> > > diverge, document the difference between x86 and ARM model.
>>>>>>> > >>> > > 
>>>>> > >> > Hi Wei,
>>>>> > >> > 
>>>>> > >> > Do you decide how to add the size of ACPI blob to max_memkb?
>>>>> > >> > 
>>> > > AFAICT ARM and x86 maintainers hold different opinions on how memory
>>> > > should be accounted.
>>> > > 
>>> > > I would like to have a unified memory accounting model. But if we can't
>>> > > have that at the moment, I'm fine with divergence, but please document
>>> > > it somewhere (comment near code snippet, in header, or a file under docs
>>> > > etc). And the amount added to max_memkb needs to be properly calculated,
>>> > > not some magic number, so that we have a chance in the future to
>>> > > confidently change how we do thing.
>> > If it's only allowed to add the size to max_memkb in
>> > libxl__domain_build_info_setdefault(), it only can use a const number
>> > since the tables are not generted and we don;t know the size. But the
>> > const number could be chosen properly since we could know the maximum
>> > ACPI tables size of current ARM approach.
>> > 
>> > But maybe in the future, if we add some new ACPI tables, it should
>> > increase the size as well. So I think this should be documented.
>> > 
>> > As I asked before, is it ok to add the size to max_memkb after
>> > generating the ACPI tables and before loading the tables to guest space?
>> > 
> Yes. I don't think shoehorning everything into setdefault is a good
> idea.
> 
> I think libxl_arm.c:libxl__arch_domain_create would be the right place
> to do it.
> 
> I am thinking about calling xc_domain_setmaxmem there, but not adding a
> number to d_config->b_info.max_memkb. Adding that to ->max_memkb would
> be wrong because the bigger ->max_memkb will be recored and the same
> algorithm will be applied every time you migrate your guest, so the
> max_memkb will grow bigger and bigger.
> 
> Given the different approach taken by ARM and x86, maybe we need to also
> record the size of acpi blobs somewhere in xenstore (also needs to be
> documented) so that subsequent libxl_domain_setmaxmem can extract that
> number again.
> 
> Please wait a bit for Stefano and Julien to comment before you do work.
> 
Stefano, Julien,
Any comments regarding how to add the ACPI size to max_memkb?

Thanks,
-- 
Shannon


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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[George Dunlap]

On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
<sstabellini@kernel.org> wrote:
>> You are assuming that the guest will map the ACPI blob with the same
>> attributes as the rest of the superpage.
>>
>> IHMO, a sane operating system will want to map the ACPI blob read-only.
>
> That's true. But there are other things which might be mapped
> differently and could shatter a stage-1 superpage mapping (especially on
> x86 that has a much more complex memory map than ARM). Obviously adding
> one more is not doing it any good, but it might not make a difference in
> practice.
>
> Anyway, I agree with Julien that his suggestion is the best for ARM. If
> the libxl maintainers are willing to accept two different code paths for
> this on ARM and x86, then I am fine with it too.

Sorry to be a bit late to this thread -- there's a interface principle
that I think we should at some point have a larger discussion about:
whether "maxmem" means the amount of RAM which the guest sees as RAM,
or whether "maxmem" means the amount of RAM that the administrator
sees as used by the guest.  At the moment tnhere's no consistent
answer actually; but I am strongly of the opinion that for usability
the best answer is for "memory" to be the *total* amount of *host*
memory used by the guest.  In an ideal world, the admin should be able
to do "xl info", see that there is 3000MiB free, and then start a
guest with 3000MiB and expect it to succeed.  At the moment he has to
guess.

 -George

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hi George,

On 25/07/16 09:38, George Dunlap wrote:
> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
> <sstabellini@kernel.org> wrote:
>>> You are assuming that the guest will map the ACPI blob with the same
>>> attributes as the rest of the superpage.
>>>
>>> IHMO, a sane operating system will want to map the ACPI blob read-only.
>>
>> That's true. But there are other things which might be mapped
>> differently and could shatter a stage-1 superpage mapping (especially on
>> x86 that has a much more complex memory map than ARM). Obviously adding
>> one more is not doing it any good, but it might not make a difference in
>> practice.
>>
>> Anyway, I agree with Julien that his suggestion is the best for ARM. If
>> the libxl maintainers are willing to accept two different code paths for
>> this on ARM and x86, then I am fine with it too.
>
> Sorry to be a bit late to this thread -- there's a interface principle
> that I think we should at some point have a larger discussion about:
> whether "maxmem" means the amount of RAM which the guest sees as RAM,
> or whether "maxmem" means the amount of RAM that the administrator
> sees as used by the guest.  At the moment tnhere's no consistent
> answer actually; but I am strongly of the opinion that for usability
> the best answer is for "memory" to be the *total* amount of *host*
> memory used by the guest.  In an ideal world, the admin should be able
> to do "xl info", see that there is 3000MiB free, and then start a
> guest with 3000MiB and expect it to succeed.  At the moment he has to
> guess.

To confirm, do you include memory allocated by the hypervisor to keep 
track of the guest (i.e struc domain, struct vcpu...)?

If not, the problem stays the same because the admin will have to know 
how much memory Xen will allocate to keep track of the guest. So if "xl 
info" tells you that 3000MiB is free, you will only be able to use 
3000MiB - few kilobytes.

If yes, this would be a problem for migration because a newer version of 
Xen may allocate less/more memory.

Furthermore, with this suggestion, we will likely not be able to take 
advantage of 1GB superpage unless the admin knows how much memory will 
be used by Xen outside of the guest RAM (such as the console page, 
xenstore page, ....).

IHMO, it would be easier if we define "maxmem" as the usable for guest 
RAM and then let the toolstack take add the extra memory (ACPI blob, 
special pages...).

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Stefano Stabellini]

On Mon, 25 Jul 2016, George Dunlap wrote:
> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
> <sstabellini@kernel.org> wrote:
> >> You are assuming that the guest will map the ACPI blob with the same
> >> attributes as the rest of the superpage.
> >>
> >> IHMO, a sane operating system will want to map the ACPI blob read-only.
> >
> > That's true. But there are other things which might be mapped
> > differently and could shatter a stage-1 superpage mapping (especially on
> > x86 that has a much more complex memory map than ARM). Obviously adding
> > one more is not doing it any good, but it might not make a difference in
> > practice.
> >
> > Anyway, I agree with Julien that his suggestion is the best for ARM. If
> > the libxl maintainers are willing to accept two different code paths for
> > this on ARM and x86, then I am fine with it too.
> 
> Sorry to be a bit late to this thread -- there's a interface principle
> that I think we should at some point have a larger discussion about:
> whether "maxmem" means the amount of RAM which the guest sees as RAM,
> or whether "maxmem" means the amount of RAM that the administrator
> sees as used by the guest.  At the moment tnhere's no consistent
> answer actually; but I am strongly of the opinion that for usability
> the best answer is for "memory" to be the *total* amount of *host*
> memory used by the guest.  In an ideal world, the admin should be able
> to do "xl info", see that there is 3000MiB free, and then start a
> guest with 3000MiB and expect it to succeed.  At the moment he has to
> guess.

I don't want to add to the confusion, but maxmem is often higher than
the actual memory allocated for the guest at any given moment, given
that it's the upper limit enforced by the hypervisor (maxmem and mem are
often different, think about ballooning). So how can it be "the amount
of RAM that the administrator sees as used by the guest"? At best it
could be "the amount of RAM that the administrator sees could be at most
used by the guest" or "the amount of RAM that the administrator sees as
allocated on behalf of the guest at boot".


> To confirm, do you include memory allocated by the hypervisor to keep
> track of the guest (i.e struc domain, struct vcpu...)?
> 
> If not, the problem stays the same because the admin will have to know
> how much memory Xen will allocate to keep track of the guest. So if "xl
> info" tells you that 3000MiB is free, you will only be able to use
> 3000MiB - few kilobytes.

That's right, unfortunately all those structs allocated by the
hypervisor are completely unknown to the tootlstack. However they should
be an order of magnitude or two smaller than things like the videoram,
the ethernet blob (on x86) or the ACPI blob. So taking the memory for
ACPI and videoram from the existing maxmem pool without increasing it,
would significantly improve, but not completely solve, the problem
described by George.


Going back to the discussion about how to account for the ACPI blob in
maxmem, let's make this simple, if we increase maxmem by the size of the
ACPI blob:

- the toolstack allocates more RAM than expected (bad)
- when the admin specifies 1GB of RAM, the guest actually gets 1GB of
  usable RAM (good)
- things are faster as Xen and the guest can exploit superpage mappings
  more easily at stage-1 and stage-2 (good)

Let's call this option A.

If we do not increase maxmem:

- the toolstack allocates less RAM, closer to the size specified in the
  VM config file (good)
- the guest gets less usable memory than expected, less than what was
  specified in the VM config file (bad)
- things get slower as one or two 1GB superpage mappings are going to be
  shattered, almost certainly the stage-1 mapping, probably the stage-2
  mapping too, depending on the guest memory layout which is arch
  specific (bad)

Let's call this option B.

Both have pros and cons. Julien feels strongly for option A. I vote for
option A, but I find option B also acceptable. Let's make a decision so
that Shannon can move forward.

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky]

On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
> On Mon, 25 Jul 2016, George Dunlap wrote:
>> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
>> <sstabellini@kernel.org> wrote:
>>>> You are assuming that the guest will map the ACPI blob with the same
>>>> attributes as the rest of the superpage.
>>>>
>>>> IHMO, a sane operating system will want to map the ACPI blob read-only.
>>> That's true. But there are other things which might be mapped
>>> differently and could shatter a stage-1 superpage mapping (especially on
>>> x86 that has a much more complex memory map than ARM). Obviously adding
>>> one more is not doing it any good, but it might not make a difference in
>>> practice.
>>>
>>> Anyway, I agree with Julien that his suggestion is the best for ARM. If
>>> the libxl maintainers are willing to accept two different code paths for
>>> this on ARM and x86, then I am fine with it too.
>> Sorry to be a bit late to this thread -- there's a interface principle
>> that I think we should at some point have a larger discussion about:
>> whether "maxmem" means the amount of RAM which the guest sees as RAM,
>> or whether "maxmem" means the amount of RAM that the administrator
>> sees as used by the guest.  At the moment tnhere's no consistent
>> answer actually; but I am strongly of the opinion that for usability
>> the best answer is for "memory" to be the *total* amount of *host*
>> memory used by the guest.  In an ideal world, the admin should be able
>> to do "xl info", see that there is 3000MiB free, and then start a
>> guest with 3000MiB and expect it to succeed.  At the moment he has to
>> guess.
> I don't want to add to the confusion, but maxmem is often higher than
> the actual memory allocated for the guest at any given moment, given
> that it's the upper limit enforced by the hypervisor (maxmem and mem are
> often different, think about ballooning). So how can it be "the amount
> of RAM that the administrator sees as used by the guest"? At best it
> could be "the amount of RAM that the administrator sees could be at most
> used by the guest" or "the amount of RAM that the administrator sees as
> allocated on behalf of the guest at boot".
>
>
>> To confirm, do you include memory allocated by the hypervisor to keep
>> track of the guest (i.e struc domain, struct vcpu...)?
>>
>> If not, the problem stays the same because the admin will have to know
>> how much memory Xen will allocate to keep track of the guest. So if "xl
>> info" tells you that 3000MiB is free, you will only be able to use
>> 3000MiB - few kilobytes.
> That's right, unfortunately all those structs allocated by the
> hypervisor are completely unknown to the tootlstack. However they should
> be an order of magnitude or two smaller than things like the videoram,
> the ethernet blob (on x86) or the ACPI blob. So taking the memory for
> ACPI and videoram from the existing maxmem pool without increasing it,
> would significantly improve, but not completely solve, the problem
> described by George.
>
>
> Going back to the discussion about how to account for the ACPI blob in
> maxmem, let's make this simple, if we increase maxmem by the size of the
> ACPI blob:
>
> - the toolstack allocates more RAM than expected (bad)
> - when the admin specifies 1GB of RAM, the guest actually gets 1GB of
>   usable RAM (good)
> - things are faster as Xen and the guest can exploit superpage mappings
>   more easily at stage-1 and stage-2 (good)
>
> Let's call this option A.
>
> If we do not increase maxmem:
>
> - the toolstack allocates less RAM, closer to the size specified in the
>   VM config file (good)
> - the guest gets less usable memory than expected, less than what was
>   specified in the VM config file (bad)


Not sure I agree with this, at least for x86/Linux: guest gets 1GB of
usable RAM and part of that RAM stores ACPI stuff. Guest is free to
stash ACPI tables somewhere else or ignore them altogether and use that
memory for whatever it wants.


-boris


> - things get slower as one or two 1GB superpage mappings are going to be
>   shattered, almost certainly the stage-1 mapping, probably the stage-2
>   mapping too, depending on the guest memory layout which is arch
>   specific (bad)
>
> Let's call this option B.
>
> Both have pros and cons. Julien feels strongly for option A. I vote for
> option A, but I find option B also acceptable. Let's make a decision so
> that Shannon can move forward.



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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Stefano Stabellini]

On Mon, 25 Jul 2016, Boris Ostrovsky wrote:
> On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
> > On Mon, 25 Jul 2016, George Dunlap wrote:
> >> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
> >> <sstabellini@kernel.org> wrote:
> >>>> You are assuming that the guest will map the ACPI blob with the same
> >>>> attributes as the rest of the superpage.
> >>>>
> >>>> IHMO, a sane operating system will want to map the ACPI blob read-only.
> >>> That's true. But there are other things which might be mapped
> >>> differently and could shatter a stage-1 superpage mapping (especially on
> >>> x86 that has a much more complex memory map than ARM). Obviously adding
> >>> one more is not doing it any good, but it might not make a difference in
> >>> practice.
> >>>
> >>> Anyway, I agree with Julien that his suggestion is the best for ARM. If
> >>> the libxl maintainers are willing to accept two different code paths for
> >>> this on ARM and x86, then I am fine with it too.
> >> Sorry to be a bit late to this thread -- there's a interface principle
> >> that I think we should at some point have a larger discussion about:
> >> whether "maxmem" means the amount of RAM which the guest sees as RAM,
> >> or whether "maxmem" means the amount of RAM that the administrator
> >> sees as used by the guest.  At the moment tnhere's no consistent
> >> answer actually; but I am strongly of the opinion that for usability
> >> the best answer is for "memory" to be the *total* amount of *host*
> >> memory used by the guest.  In an ideal world, the admin should be able
> >> to do "xl info", see that there is 3000MiB free, and then start a
> >> guest with 3000MiB and expect it to succeed.  At the moment he has to
> >> guess.
> > I don't want to add to the confusion, but maxmem is often higher than
> > the actual memory allocated for the guest at any given moment, given
> > that it's the upper limit enforced by the hypervisor (maxmem and mem are
> > often different, think about ballooning). So how can it be "the amount
> > of RAM that the administrator sees as used by the guest"? At best it
> > could be "the amount of RAM that the administrator sees could be at most
> > used by the guest" or "the amount of RAM that the administrator sees as
> > allocated on behalf of the guest at boot".
> >
> >
> >> To confirm, do you include memory allocated by the hypervisor to keep
> >> track of the guest (i.e struc domain, struct vcpu...)?
> >>
> >> If not, the problem stays the same because the admin will have to know
> >> how much memory Xen will allocate to keep track of the guest. So if "xl
> >> info" tells you that 3000MiB is free, you will only be able to use
> >> 3000MiB - few kilobytes.
> > That's right, unfortunately all those structs allocated by the
> > hypervisor are completely unknown to the tootlstack. However they should
> > be an order of magnitude or two smaller than things like the videoram,
> > the ethernet blob (on x86) or the ACPI blob. So taking the memory for
> > ACPI and videoram from the existing maxmem pool without increasing it,
> > would significantly improve, but not completely solve, the problem
> > described by George.
> >
> >
> > Going back to the discussion about how to account for the ACPI blob in
> > maxmem, let's make this simple, if we increase maxmem by the size of the
> > ACPI blob:
> >
> > - the toolstack allocates more RAM than expected (bad)
> > - when the admin specifies 1GB of RAM, the guest actually gets 1GB of
> >   usable RAM (good)
> > - things are faster as Xen and the guest can exploit superpage mappings
> >   more easily at stage-1 and stage-2 (good)
> >
> > Let's call this option A.
> >
> > If we do not increase maxmem:
> >
> > - the toolstack allocates less RAM, closer to the size specified in the
> >   VM config file (good)
> > - the guest gets less usable memory than expected, less than what was
> >   specified in the VM config file (bad)
> 
> 
> Not sure I agree with this, at least for x86/Linux: guest gets 1GB of
> usable RAM and part of that RAM stores ACPI stuff. Guest is free to
> stash ACPI tables somewhere else or ignore them altogether and use that
> memory for whatever it wants.

On ARM it will be a ROM (from guest POV)

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky]

On 07/25/2016 07:40 PM, Stefano Stabellini wrote:
> On Mon, 25 Jul 2016, Boris Ostrovsky wrote:
>> On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
>>> On Mon, 25 Jul 2016, George Dunlap wrote:
>>>> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
>>>> <sstabellini@kernel.org> wrote:
>>>>>> You are assuming that the guest will map the ACPI blob with the same
>>>>>> attributes as the rest of the superpage.
>>>>>>
>>>>>> IHMO, a sane operating system will want to map the ACPI blob read-only.
>>>>> That's true. But there are other things which might be mapped
>>>>> differently and could shatter a stage-1 superpage mapping (especially on
>>>>> x86 that has a much more complex memory map than ARM). Obviously adding
>>>>> one more is not doing it any good, but it might not make a difference in
>>>>> practice.
>>>>>
>>>>> Anyway, I agree with Julien that his suggestion is the best for ARM. If
>>>>> the libxl maintainers are willing to accept two different code paths for
>>>>> this on ARM and x86, then I am fine with it too.
>>>> Sorry to be a bit late to this thread -- there's a interface principle
>>>> that I think we should at some point have a larger discussion about:
>>>> whether "maxmem" means the amount of RAM which the guest sees as RAM,
>>>> or whether "maxmem" means the amount of RAM that the administrator
>>>> sees as used by the guest.  At the moment tnhere's no consistent
>>>> answer actually; but I am strongly of the opinion that for usability
>>>> the best answer is for "memory" to be the *total* amount of *host*
>>>> memory used by the guest.  In an ideal world, the admin should be able
>>>> to do "xl info", see that there is 3000MiB free, and then start a
>>>> guest with 3000MiB and expect it to succeed.  At the moment he has to
>>>> guess.
>>> I don't want to add to the confusion, but maxmem is often higher than
>>> the actual memory allocated for the guest at any given moment, given
>>> that it's the upper limit enforced by the hypervisor (maxmem and mem are
>>> often different, think about ballooning). So how can it be "the amount
>>> of RAM that the administrator sees as used by the guest"? At best it
>>> could be "the amount of RAM that the administrator sees could be at most
>>> used by the guest" or "the amount of RAM that the administrator sees as
>>> allocated on behalf of the guest at boot".
>>>
>>>
>>>> To confirm, do you include memory allocated by the hypervisor to keep
>>>> track of the guest (i.e struc domain, struct vcpu...)?
>>>>
>>>> If not, the problem stays the same because the admin will have to know
>>>> how much memory Xen will allocate to keep track of the guest. So if "xl
>>>> info" tells you that 3000MiB is free, you will only be able to use
>>>> 3000MiB - few kilobytes.
>>> That's right, unfortunately all those structs allocated by the
>>> hypervisor are completely unknown to the tootlstack. However they should
>>> be an order of magnitude or two smaller than things like the videoram,
>>> the ethernet blob (on x86) or the ACPI blob. So taking the memory for
>>> ACPI and videoram from the existing maxmem pool without increasing it,
>>> would significantly improve, but not completely solve, the problem
>>> described by George.
>>>
>>>
>>> Going back to the discussion about how to account for the ACPI blob in
>>> maxmem, let's make this simple, if we increase maxmem by the size of the
>>> ACPI blob:
>>>
>>> - the toolstack allocates more RAM than expected (bad)
>>> - when the admin specifies 1GB of RAM, the guest actually gets 1GB of
>>>    usable RAM (good)
>>> - things are faster as Xen and the guest can exploit superpage mappings
>>>    more easily at stage-1 and stage-2 (good)
>>>
>>> Let's call this option A.
>>>
>>> If we do not increase maxmem:
>>>
>>> - the toolstack allocates less RAM, closer to the size specified in the
>>>    VM config file (good)
>>> - the guest gets less usable memory than expected, less than what was
>>>    specified in the VM config file (bad)
>>
>> Not sure I agree with this, at least for x86/Linux: guest gets 1GB of
>> usable RAM and part of that RAM stores ACPI stuff. Guest is free to
>> stash ACPI tables somewhere else or ignore them altogether and use that
>> memory for whatever it wants.
> On ARM it will be a ROM (from guest POV)


In which case I don't see why we should take it from maxmem allocation. 
I somehow thought that there was a choice of whether to put it in ROM or 
RAM on ARM but if it's ROM only then I don't think there is an option.

IIUIC the toolstack pretends that the blob goes to memory because that's 
how its interfaces work but that space is not really what we think about 
when we set memory/maxmem in the configuration file. Unlike x86.

-boris


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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hi,

On 26/07/16 02:17, Boris Ostrovsky wrote:
> On 07/25/2016 07:40 PM, Stefano Stabellini wrote:
>> On Mon, 25 Jul 2016, Boris Ostrovsky wrote:
>>> On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
>>>> On Mon, 25 Jul 2016, George Dunlap wrote:
>>>>> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
>>>>> <sstabellini@kernel.org> wrote:
>>>> Going back to the discussion about how to account for the ACPI blob in
>>>> maxmem, let's make this simple, if we increase maxmem by the size of
>>>> the
>>>> ACPI blob:
>>>>
>>>> - the toolstack allocates more RAM than expected (bad)
>>>> - when the admin specifies 1GB of RAM, the guest actually gets 1GB of
>>>>    usable RAM (good)
>>>> - things are faster as Xen and the guest can exploit superpage mappings
>>>>    more easily at stage-1 and stage-2 (good)
>>>>
>>>> Let's call this option A.
>>>>
>>>> If we do not increase maxmem:
>>>>
>>>> - the toolstack allocates less RAM, closer to the size specified in the
>>>>    VM config file (good)
>>>> - the guest gets less usable memory than expected, less than what was
>>>>    specified in the VM config file (bad)
>>>
>>> Not sure I agree with this, at least for x86/Linux: guest gets 1GB of
>>> usable RAM and part of that RAM stores ACPI stuff. Guest is free to
>>> stash ACPI tables somewhere else or ignore them altogether and use that
>>> memory for whatever it wants.
>> On ARM it will be a ROM (from guest POV)
>
>
> In which case I don't see why we should take it from maxmem allocation.
> I somehow thought that there was a choice of whether to put it in ROM or
> RAM on ARM but if it's ROM only then I don't think there is an option.

We have option to do the both on ARM. I just feel that the ROM option is 
a cleaner interface because the ACPI tables are not supposed be modified 
by the guest, so we can prevent to be overridden (+ all the advantages 
mentioned by Stefano with option A).

> IIUIC the toolstack pretends that the blob goes to memory because that's
> how its interfaces work but that space is not really what we think about
> when we set memory/maxmem in the configuration file. Unlike x86.

I think we need to draw a conclusion for Shannon to continue to do the 
work and I would like to see this series in Xen 4.8. From my 
understanding you are for option B, so does George.

Stefano votes for option A, but find B acceptable. Any other opinions?

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hi Shannon,

Sorry for the late answer.

On 25/07/16 08:56, Shannon Zhao wrote:
>
>
> On 2016/7/20 17:32, Wei Liu wrote:
>> On Wed, Jul 20, 2016 at 02:52:05PM +0800, Shannon Zhao wrote:
>>>>
>>>>
>>>> On 2016/7/19 18:38, Wei Liu wrote:
>>>>>> On Fri, Jul 15, 2016 at 05:39:32PM +0800, Shannon Zhao wrote:
>>>>>> [...]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It would be trivial to have another option in xl.cfg to allow MB
>>>>>>>>>>>>>> granularity. But I don't think that's a good idea. Asking for more
>>>>>>>>>>>>>> memory when you don't really know how much is enough is not very useful.
>>>>>>>>>>>>>> If an admin can know how much is needed, surely the library can be
>>>>>>>>>>>>>> taught to obtain that knowledge, too.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We need to decide which model we should go with. And, if we decide to
>>>>>>>>>>>>>> diverge, document the difference between x86 and ARM model.
>>>>>>>>>>>>>>
>>>>>>>>>> Hi Wei,
>>>>>>>>>>
>>>>>>>>>> Do you decide how to add the size of ACPI blob to max_memkb?
>>>>>>>>>>
>>>>>> AFAICT ARM and x86 maintainers hold different opinions on how memory
>>>>>> should be accounted.
>>>>>>
>>>>>> I would like to have a unified memory accounting model. But if we can't
>>>>>> have that at the moment, I'm fine with divergence, but please document
>>>>>> it somewhere (comment near code snippet, in header, or a file under docs
>>>>>> etc). And the amount added to max_memkb needs to be properly calculated,
>>>>>> not some magic number, so that we have a chance in the future to
>>>>>> confidently change how we do thing.
>>>> If it's only allowed to add the size to max_memkb in
>>>> libxl__domain_build_info_setdefault(), it only can use a const number
>>>> since the tables are not generted and we don;t know the size. But the
>>>> const number could be chosen properly since we could know the maximum
>>>> ACPI tables size of current ARM approach.
>>>>
>>>> But maybe in the future, if we add some new ACPI tables, it should
>>>> increase the size as well. So I think this should be documented.
>>>>
>>>> As I asked before, is it ok to add the size to max_memkb after
>>>> generating the ACPI tables and before loading the tables to guest space?
>>>>
>> Yes. I don't think shoehorning everything into setdefault is a good
>> idea.
>>
>> I think libxl_arm.c:libxl__arch_domain_create would be the right place
>> to do it.
>>
>> I am thinking about calling xc_domain_setmaxmem there, but not adding a
>> number to d_config->b_info.max_memkb. Adding that to ->max_memkb would
>> be wrong because the bigger ->max_memkb will be recored and the same
>> algorithm will be applied every time you migrate your guest, so the
>> max_memkb will grow bigger and bigger.
>>
>> Given the different approach taken by ARM and x86, maybe we need to also
>> record the size of acpi blobs somewhere in xenstore (also needs to be
>> documented) so that subsequent libxl_domain_setmaxmem can extract that
>> number again.
>>
>> Please wait a bit for Stefano and Julien to comment before you do work.
>>
> Stefano, Julien,
> Any comments regarding how to add the ACPI size to max_memkb?

I think Wei's suggestion is a good one.

Cheers,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Shannon Zhao]

On 2016年07月28日 19:06, Julien Grall wrote:
> On 26/07/16 02:17, Boris Ostrovsky wrote:
>> On 07/25/2016 07:40 PM, Stefano Stabellini wrote:
>>> On Mon, 25 Jul 2016, Boris Ostrovsky wrote:
>>>> On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
>>>>> On Mon, 25 Jul 2016, George Dunlap wrote:
>>>>>> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
>>>>>> <sstabellini@kernel.org> wrote:
>>>>> Going back to the discussion about how to account for the ACPI blob in
>>>>> maxmem, let's make this simple, if we increase maxmem by the size of
>>>>> the
>>>>> ACPI blob:
>>>>>
>>>>> - the toolstack allocates more RAM than expected (bad)
>>>>> - when the admin specifies 1GB of RAM, the guest actually gets 1GB of
>>>>>    usable RAM (good)
>>>>> - things are faster as Xen and the guest can exploit superpage
>>>>> mappings
>>>>>    more easily at stage-1 and stage-2 (good)
>>>>>
>>>>> Let's call this option A.
>>>>>
>>>>> If we do not increase maxmem:
>>>>>
>>>>> - the toolstack allocates less RAM, closer to the size specified in
>>>>> the
>>>>>    VM config file (good)
>>>>> - the guest gets less usable memory than expected, less than what was
>>>>>    specified in the VM config file (bad)
>>>>
>>>> Not sure I agree with this, at least for x86/Linux: guest gets 1GB of
>>>> usable RAM and part of that RAM stores ACPI stuff. Guest is free to
>>>> stash ACPI tables somewhere else or ignore them altogether and use that
>>>> memory for whatever it wants.
>>> On ARM it will be a ROM (from guest POV)
>>
>>
>> In which case I don't see why we should take it from maxmem allocation.
>> I somehow thought that there was a choice of whether to put it in ROM or
>> RAM on ARM but if it's ROM only then I don't think there is an option.
> 
> We have option to do the both on ARM. I just feel that the ROM option is
> a cleaner interface because the ACPI tables are not supposed be modified
> by the guest, so we can prevent to be overridden (+ all the advantages
> mentioned by Stefano with option A).
> 
>> IIUIC the toolstack pretends that the blob goes to memory because that's
>> how its interfaces work but that space is not really what we think about
>> when we set memory/maxmem in the configuration file. Unlike x86.
> 
> I think we need to draw a conclusion for Shannon to continue to do the
> work and I would like to see this series in Xen 4.8. From my
> understanding you are for option B, so does George.
> 
> Stefano votes for option A, but find B acceptable. Any other opinions?
I agree with Stefano, both are fine.

Thanks,
-- 
Shannon

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Thu, Jul 28, 2016 at 12:06:11PM +0100, Julien Grall wrote:
> Hi,
> 
> On 26/07/16 02:17, Boris Ostrovsky wrote:
> >On 07/25/2016 07:40 PM, Stefano Stabellini wrote:
> >>On Mon, 25 Jul 2016, Boris Ostrovsky wrote:
> >>>On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
> >>>>On Mon, 25 Jul 2016, George Dunlap wrote:
> >>>>>On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
> >>>>><sstabellini@kernel.org> wrote:
> >>>>Going back to the discussion about how to account for the ACPI blob in
> >>>>maxmem, let's make this simple, if we increase maxmem by the size of
> >>>>the
> >>>>ACPI blob:
> >>>>
> >>>>- the toolstack allocates more RAM than expected (bad)
> >>>>- when the admin specifies 1GB of RAM, the guest actually gets 1GB of
> >>>>   usable RAM (good)
> >>>>- things are faster as Xen and the guest can exploit superpage mappings
> >>>>   more easily at stage-1 and stage-2 (good)
> >>>>
> >>>>Let's call this option A.
> >>>>
> >>>>If we do not increase maxmem:
> >>>>
> >>>>- the toolstack allocates less RAM, closer to the size specified in the
> >>>>   VM config file (good)
> >>>>- the guest gets less usable memory than expected, less than what was
> >>>>   specified in the VM config file (bad)
> >>>
> >>>Not sure I agree with this, at least for x86/Linux: guest gets 1GB of
> >>>usable RAM and part of that RAM stores ACPI stuff. Guest is free to
> >>>stash ACPI tables somewhere else or ignore them altogether and use that
> >>>memory for whatever it wants.
> >>On ARM it will be a ROM (from guest POV)
> >
> >
> >In which case I don't see why we should take it from maxmem allocation.
> >I somehow thought that there was a choice of whether to put it in ROM or
> >RAM on ARM but if it's ROM only then I don't think there is an option.
> 
> We have option to do the both on ARM. I just feel that the ROM option is a
> cleaner interface because the ACPI tables are not supposed be modified by
> the guest, so we can prevent to be overridden (+ all the advantages
> mentioned by Stefano with option A).
> 
> >IIUIC the toolstack pretends that the blob goes to memory because that's
> >how its interfaces work but that space is not really what we think about
> >when we set memory/maxmem in the configuration file. Unlike x86.
> 
> I think we need to draw a conclusion for Shannon to continue to do the work
> and I would like to see this series in Xen 4.8. From my understanding you
> are for option B, so does George.
> 
> Stefano votes for option A, but find B acceptable. Any other opinions?
> 

From my PoV I just need things to be clearly documented.

Wei.

> Regards,
> 
> -- 
> Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Thu, Jul 28, 2016 at 08:42:05PM +0800, Shannon Zhao wrote:
> On 2016年07月28日 19:06, Julien Grall wrote:
> > On 26/07/16 02:17, Boris Ostrovsky wrote:
> >> On 07/25/2016 07:40 PM, Stefano Stabellini wrote:
> >>> On Mon, 25 Jul 2016, Boris Ostrovsky wrote:
> >>>> On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
> >>>>> On Mon, 25 Jul 2016, George Dunlap wrote:
> >>>>>> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
> >>>>>> <sstabellini@kernel.org> wrote:
> >>>>> Going back to the discussion about how to account for the ACPI blob in
> >>>>> maxmem, let's make this simple, if we increase maxmem by the size of
> >>>>> the
> >>>>> ACPI blob:
> >>>>>
> >>>>> - the toolstack allocates more RAM than expected (bad)
> >>>>> - when the admin specifies 1GB of RAM, the guest actually gets 1GB of
> >>>>>    usable RAM (good)
> >>>>> - things are faster as Xen and the guest can exploit superpage
> >>>>> mappings
> >>>>>    more easily at stage-1 and stage-2 (good)
> >>>>>
> >>>>> Let's call this option A.
> >>>>>
> >>>>> If we do not increase maxmem:
> >>>>>
> >>>>> - the toolstack allocates less RAM, closer to the size specified in
> >>>>> the
> >>>>>    VM config file (good)
> >>>>> - the guest gets less usable memory than expected, less than what was
> >>>>>    specified in the VM config file (bad)
> >>>>
> >>>> Not sure I agree with this, at least for x86/Linux: guest gets 1GB of
> >>>> usable RAM and part of that RAM stores ACPI stuff. Guest is free to
> >>>> stash ACPI tables somewhere else or ignore them altogether and use that
> >>>> memory for whatever it wants.
> >>> On ARM it will be a ROM (from guest POV)
> >>
> >>
> >> In which case I don't see why we should take it from maxmem allocation.
> >> I somehow thought that there was a choice of whether to put it in ROM or
> >> RAM on ARM but if it's ROM only then I don't think there is an option.
> > 
> > We have option to do the both on ARM. I just feel that the ROM option is
> > a cleaner interface because the ACPI tables are not supposed be modified
> > by the guest, so we can prevent to be overridden (+ all the advantages
> > mentioned by Stefano with option A).
> > 
> >> IIUIC the toolstack pretends that the blob goes to memory because that's
> >> how its interfaces work but that space is not really what we think about
> >> when we set memory/maxmem in the configuration file. Unlike x86.
> > 
> > I think we need to draw a conclusion for Shannon to continue to do the
> > work and I would like to see this series in Xen 4.8. From my
> > understanding you are for option B, so does George.
> > 
> > Stefano votes for option A, but find B acceptable. Any other opinions?
> I agree with Stefano, both are fine.
> 

Sorry for the late reply.

Are you now unblocked? If not, what is not yet decided or needed
clarification?

Wei.

> Thanks,
> -- 
> Shannon

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hi Wei,

On 02/08/16 12:01, Wei Liu wrote:
> On Thu, Jul 28, 2016 at 08:42:05PM +0800, Shannon Zhao wrote:
>> On 2016年07月28日 19:06, Julien Grall wrote:
>>> On 26/07/16 02:17, Boris Ostrovsky wrote:
>>>> On 07/25/2016 07:40 PM, Stefano Stabellini wrote:
>>>>> On Mon, 25 Jul 2016, Boris Ostrovsky wrote:
>>>>>> On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
>>>>>>> On Mon, 25 Jul 2016, George Dunlap wrote:
>>>>>>>> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
>>>>>>>> <sstabellini@kernel.org> wrote:
>>>>>>> Going back to the discussion about how to account for the ACPI blob in
>>>>>>> maxmem, let's make this simple, if we increase maxmem by the size of
>>>>>>> the
>>>>>>> ACPI blob:
>>>>>>>
>>>>>>> - the toolstack allocates more RAM than expected (bad)
>>>>>>> - when the admin specifies 1GB of RAM, the guest actually gets 1GB of
>>>>>>>    usable RAM (good)
>>>>>>> - things are faster as Xen and the guest can exploit superpage
>>>>>>> mappings
>>>>>>>    more easily at stage-1 and stage-2 (good)
>>>>>>>
>>>>>>> Let's call this option A.
>>>>>>>
>>>>>>> If we do not increase maxmem:
>>>>>>>
>>>>>>> - the toolstack allocates less RAM, closer to the size specified in
>>>>>>> the
>>>>>>>    VM config file (good)
>>>>>>> - the guest gets less usable memory than expected, less than what was
>>>>>>>    specified in the VM config file (bad)
>>>>>>
>>>>>> Not sure I agree with this, at least for x86/Linux: guest gets 1GB of
>>>>>> usable RAM and part of that RAM stores ACPI stuff. Guest is free to
>>>>>> stash ACPI tables somewhere else or ignore them altogether and use that
>>>>>> memory for whatever it wants.
>>>>> On ARM it will be a ROM (from guest POV)
>>>>
>>>>
>>>> In which case I don't see why we should take it from maxmem allocation.
>>>> I somehow thought that there was a choice of whether to put it in ROM or
>>>> RAM on ARM but if it's ROM only then I don't think there is an option.
>>>
>>> We have option to do the both on ARM. I just feel that the ROM option is
>>> a cleaner interface because the ACPI tables are not supposed be modified
>>> by the guest, so we can prevent to be overridden (+ all the advantages
>>> mentioned by Stefano with option A).
>>>
>>>> IIUIC the toolstack pretends that the blob goes to memory because that's
>>>> how its interfaces work but that space is not really what we think about
>>>> when we set memory/maxmem in the configuration file. Unlike x86.
>>>
>>> I think we need to draw a conclusion for Shannon to continue to do the
>>> work and I would like to see this series in Xen 4.8. From my
>>> understanding you are for option B, so does George.
>>>
>>> Stefano votes for option A, but find B acceptable. Any other opinions?
>> I agree with Stefano, both are fine.
>>
>
> Sorry for the late reply.
>
> Are you now unblocked? If not, what is not yet decided or needed
> clarification?

I don't think there was a strict consensus. I think this is something we 
can revisit later if necessary as the guest interface does not tie up to 
a specific physical address (The UEFI firmware should retrieve the 
information from the device tree).

So, Shannon could continue towards solution A. I.e the ACPI blob is 
loaded outside of the guest RAM?

If someone disagree please speak up. But we should unblock Shannon to 
get this series in Xen 4.8.

Regards,

-- 
Julien Grall

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

Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Wed, Aug 03, 2016 at 08:20:18PM +0100, Julien Grall wrote:
> Hi Wei,
> 
> On 02/08/16 12:01, Wei Liu wrote:
> >On Thu, Jul 28, 2016 at 08:42:05PM +0800, Shannon Zhao wrote:
> >>On 2016年07月28日 19:06, Julien Grall wrote:
> >>>On 26/07/16 02:17, Boris Ostrovsky wrote:
> >>>>On 07/25/2016 07:40 PM, Stefano Stabellini wrote:
> >>>>>On Mon, 25 Jul 2016, Boris Ostrovsky wrote:
> >>>>>>On 07/25/2016 06:06 PM, Stefano Stabellini wrote:
> >>>>>>>On Mon, 25 Jul 2016, George Dunlap wrote:
> >>>>>>>>On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
> >>>>>>>><sstabellini@kernel.org> wrote:
> >>>>>>>Going back to the discussion about how to account for the ACPI blob in
> >>>>>>>maxmem, let's make this simple, if we increase maxmem by the size of
> >>>>>>>the
> >>>>>>>ACPI blob:
> >>>>>>>
> >>>>>>>- the toolstack allocates more RAM than expected (bad)
> >>>>>>>- when the admin specifies 1GB of RAM, the guest actually gets 1GB of
> >>>>>>>   usable RAM (good)
> >>>>>>>- things are faster as Xen and the guest can exploit superpage
> >>>>>>>mappings
> >>>>>>>   more easily at stage-1 and stage-2 (good)
> >>>>>>>
> >>>>>>>Let's call this option A.
> >>>>>>>
> >>>>>>>If we do not increase maxmem:
> >>>>>>>
> >>>>>>>- the toolstack allocates less RAM, closer to the size specified in
> >>>>>>>the
> >>>>>>>   VM config file (good)
> >>>>>>>- the guest gets less usable memory than expected, less than what was
> >>>>>>>   specified in the VM config file (bad)
> >>>>>>
> >>>>>>Not sure I agree with this, at least for x86/Linux: guest gets 1GB of
> >>>>>>usable RAM and part of that RAM stores ACPI stuff. Guest is free to
> >>>>>>stash ACPI tables somewhere else or ignore them altogether and use that
> >>>>>>memory for whatever it wants.
> >>>>>On ARM it will be a ROM (from guest POV)
> >>>>
> >>>>
> >>>>In which case I don't see why we should take it from maxmem allocation.
> >>>>I somehow thought that there was a choice of whether to put it in ROM or
> >>>>RAM on ARM but if it's ROM only then I don't think there is an option.
> >>>
> >>>We have option to do the both on ARM. I just feel that the ROM option is
> >>>a cleaner interface because the ACPI tables are not supposed be modified
> >>>by the guest, so we can prevent to be overridden (+ all the advantages
> >>>mentioned by Stefano with option A).
> >>>
> >>>>IIUIC the toolstack pretends that the blob goes to memory because that's
> >>>>how its interfaces work but that space is not really what we think about
> >>>>when we set memory/maxmem in the configuration file. Unlike x86.
> >>>
> >>>I think we need to draw a conclusion for Shannon to continue to do the
> >>>work and I would like to see this series in Xen 4.8. From my
> >>>understanding you are for option B, so does George.
> >>>
> >>>Stefano votes for option A, but find B acceptable. Any other opinions?
> >>I agree with Stefano, both are fine.
> >>
> >
> >Sorry for the late reply.
> >
> >Are you now unblocked? If not, what is not yet decided or needed
> >clarification?
> 
> I don't think there was a strict consensus. I think this is something we can
> revisit later if necessary as the guest interface does not tie up to a
> specific physical address (The UEFI firmware should retrieve the information
> from the device tree).
> 
> So, Shannon could continue towards solution A. I.e the ACPI blob is loaded
> outside of the guest RAM?
> 

I'm fine with that, the bottom line is everything should be documented
so that we can confidently make changes later (or confidently refuse to
make changes, heh).

(Given the chance I would still prefer a unified model)

> If someone disagree please speak up. But we should unblock Shannon to get
> this series in Xen 4.8.

Yes, I agree.

Wei.

> 
> Regards,
> 
> -- 
> Julien Grall

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