[Xen-devel] [PATCH RESEND 11/14] libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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 
---
 tools/libxl/libxl_arm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

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



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

[Xen-devel] [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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

Signed-off-by: Shannon Zhao 
---
 tools/libxc/include/acpi_defs.h | 277 
 1 file changed, 277 insertions(+)
 create mode 100644 tools/libxc/include/acpi_defs.h

diff --git a/tools/libxc/include/acpi_defs.h b/tools/libxc/include/acpi_defs.h
new file mode 100644
index 000..9389a96
--- /dev/null
+++ b/tools/libxc/include/acpi_defs.h
@@ -0,0 +1,277 @@
+#ifndef _ACPI_DEFS_H_
+#define _ACPI_DEFS_H_
+
+#define ACPI_BUILD_APPNAME6 "XenARM"
+#define ACPI_BUILD_APPNAME4 "Xen "
+
+#pragma pack (1)
+
+/* Root System Description Pointer Structure. */
+struct acpi_rsdp_descriptor {/* Root System Descriptor Pointer */
+uint64_t signature;  /* ACPI signature, contains "RSD PTR " */
+uint8_t  checksum;   /* To make sum of struct == 0 */
+uint8_t  oem_id[6]; /* OEM identification */
+uint8_t  revision;   /* Must be 0 for 1.0, 2 for 2.0 */
+uint32_t rsdt_physical_address;  /* 32-bit physical address of RSDT */
+uint32_t length; /* XSDT Length in bytes including hdr */
+uint64_t xsdt_physical_address;  /* 64-bit physical address of XSDT */
+uint8_t  extended_checksum;  /* Checksum of entire table */
+uint8_t  reserved[3];   /* Reserved field must be 0 */
+};
+
+/* ACPI common table header. */
+struct acpi_table_header {
+uint32_t signature;  /* ACPI signature (4 ASCII characters) */ \
+uint32_t length; /* Length of table, in bytes, including 
header */ \
+uint8_t  revision;   /* ACPI Specification minor version # */ \
+uint8_t  checksum;   /* To make sum of entire table == 0 */ \
+uint8_t  oem_id[6]; /* OEM identification */ \
+uint8_t  oem_table_id[8];   /* OEM table identification */ \
+uint32_t oem_revision;   /* OEM revision number */ \
+uint8_t  asl_compiler_id[4];/* ASL compiler vendor ID */ \
+uint32_t asl_compiler_revision;  /* ASL compiler revision number */
+};
+
+/* Extended System Description Table (XSDT). */
+struct acpi_xsdt_descriptor {
+struct acpi_table_header header;
+uint64_t entry[0];
+};
+
+/* Generic Timer Description Table (GTDT). */
+#define ACPI_GTDT_INTERRUPT_MODE0
+#define ACPI_GTDT_INTERRUPT_POLARITY1
+#define ACPI_GTDT_ALWAYS_ON 2
+
+/* Triggering */
+#define ACPI_LEVEL_SENSITIVE((uint8_t) 0x00)
+#define ACPI_EDGE_SENSITIVE ((uint8_t) 0x01)
+
+/* Polarity */
+#define ACPI_ACTIVE_HIGH((uint8_t) 0x00)
+#define ACPI_ACTIVE_LOW ((uint8_t) 0x01)
+
+struct acpi_gtdt_descriptor {
+struct acpi_table_header header;
+uint64_t counter_block_addresss;
+uint32_t reserved;
+uint32_t secure_el1_interrupt;
+uint32_t secure_el1_flags;
+uint32_t non_secure_el1_interrupt;
+uint32_t non_secure_el1_flags;
+uint32_t virtual_timer_interrupt;
+uint32_t virtual_timer_flags;
+uint32_t non_secure_el2_interrupt;
+uint32_t non_secure_el2_flags;
+uint64_t counter_read_block_address;
+uint32_t platform_timer_count;
+uint32_t platform_timer_offset;
+};
+
+/* Multiple APIC Description Table header definition (MADT). */
+struct acpi_madt_descriptor
+{
+struct acpi_table_header header; /* ACPI common table header */
+uint32_t local_apic_address; /* Physical address of local APIC */
+uint32_t flags;
+};
+
+/* Values for Type in APIC sub-headers. */
+
+#define ACPI_APIC_PROCESSOR  0
+#define ACPI_APIC_IO 1
+#define ACPI_APIC_XRUPT_OVERRIDE 2
+#define ACPI_APIC_NMI3
+#define ACPI_APIC_LOCAL_NMI  4
+#define ACPI_APIC_ADDRESS_OVERRIDE   5
+#define ACPI_APIC_IO_SAPIC   6
+#define ACPI_APIC_LOCAL_SAPIC7
+#define ACPI_APIC_XRUPT_SOURCE   8
+#define ACPI_APIC_LOCAL_X2APIC   9
+#define ACPI_APIC_LOCAL_X2APIC_NMI  10
+#define ACPI_APIC_GENERIC_INTERRUPT 11
+#define ACPI_APIC_GENERIC_DISTRIBUTOR   12
+#define ACPI_APIC_GENERIC_MSI_FRAME 13
+#define ACPI_APIC_GENERIC_REDISTRIBUTOR 14
+#define ACPI_APIC_RESERVED  15   /* 15 and greater are reserved */
+
+/*
+ * MADT sub-structures (Follow MULTIPLE_APIC_DESCRIPTION_TABLE).
+ */
+#define ACPI_SUB_HEADER_DEF   /* Common ACPI sub-structure header */\
+uint8_t  type;   \
+uint8_t  length;
+
+/* Sub-structures for MADT */
+
+struct acpi_madt_generic_interrupt {
+ACPI_SUB_HEADER_DEF
+uint16_t reserved;
+uint32_t cpu_interface_number;
+uint32_t uid;
+uint32_t flags;
+uint32_t parking_version;
+uint32_t performance_interrupt;
+uint64_t parked_address;
+uint64_t base_address;
+

[Xen-devel] [PATCH RESEND 13/14] libxl/arm: initialize memory information of ACPI blob

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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

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

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



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

[Xen-devel] [PATCH RESEND 10/14] libxl/arm: Construct ACPI RSDP table

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 18 ++
 1 file changed, 18 insertions(+)

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



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

[Xen-devel] [PATCH RESEND 09/14] libxl/arm: Construct ACPI XSDT table

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 23 +++
 1 file changed, 23 insertions(+)

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



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

[Xen-devel] [PATCH RESEND 06/14] libxl/arm: Construct ACPI FADT table

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 23 +++
 1 file changed, 23 insertions(+)

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



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

[Xen-devel] [PATCH RESEND 00/14] Xen ARM DomU ACPI support

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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

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

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

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

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

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

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

-- 
2.0.4



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

[Xen-devel] [PATCH RESEND 14/14] libxc/xc_dom_core: Copy ACPI tables to guest memory space

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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

Signed-off-by: Shannon Zhao 
---
 tools/libxc/xc_dom_core.c | 59 +++
 1 file changed, 59 insertions(+)

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



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

[Xen-devel] [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Construct GTDT table with the interrupt information of timers.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 75 -
 1 file changed, 74 insertions(+), 1 deletion(-)

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



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

[Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT
for ARM VM. So only add placeholders for them here.

Signed-off-by: Shannon Zhao 
---
 tools/libxc/include/xc_dom.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6cb10c4..0fe54dd 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -56,6 +56,20 @@ struct xc_dom_phys {
 xen_pfn_t count;
 };
 
+struct acpitable {
+void *table;
+size_t size;
+};
+
+struct acpitable_blob {
+struct acpitable rsdp;
+struct acpitable xsdt;
+struct acpitable gtdt;
+struct acpitable madt;
+struct acpitable fadt;
+struct acpitable dsdt;
+};
+
 struct xc_dom_image {
 /* files */
 void *kernel_blob;
@@ -64,6 +78,8 @@ struct xc_dom_image {
 size_t ramdisk_size;
 void *devicetree_blob;
 size_t devicetree_size;
+struct acpitable_blob *acpitable_blob;
+size_t acpitable_size;
 
 size_t max_kernel_size;
 size_t max_ramdisk_size;
@@ -92,6 +108,7 @@ struct xc_dom_image {
 struct xc_dom_seg p2m_seg;
 struct xc_dom_seg pgtables_seg;
 struct xc_dom_seg devicetree_seg;
+struct xc_dom_seg acpi_seg;
 struct xc_dom_seg start_info_seg; /* HVMlite only */
 xen_pfn_t start_info_pfn;
 xen_pfn_t console_pfn;
-- 
2.0.4



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

[Xen-devel] [PATCH RESEND 01/14] libxl/arm: Fix the function name in error log

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

It should be xc_dom_devicetree_mem instead of xc_dom_devicetree_file.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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



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

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

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Currently there is only the table header in DSDT table.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index c3b8fb4..7949635 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -944,6 +944,20 @@ static void make_acpi_fadt(libxl__gc *gc, struct 
xc_dom_image *dom)
 dom->acpitable_size += dom->acpitable_blob->fadt.size;
 }
 
+static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+struct acpi_table_header *dsdt;
+
+/* Currently there is only the table header in DSDT table. */
+dsdt = libxl__zalloc(gc, sizeof(*dsdt));
+make_acpi_header((void *)dsdt, "DSDT", sizeof(*dsdt), 2);
+
+dom->acpitable_blob->dsdt.table = (void *)dsdt;
+/* Align to 64bit. */
+dom->acpitable_blob->dsdt.size = ROUNDUP(sizeof(*dsdt), 3);
+dom->acpitable_size += ROUNDUP(dom->acpitable_blob->dsdt.size, 3);
+}
+
 static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
@@ -966,6 +980,7 @@ static int prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 
 make_acpi_gtdt(gc, dom);
 make_acpi_fadt(gc, dom);
+make_acpi_dsdt(gc, dom);
 
 return 0;
 }
-- 
2.0.4



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

[Xen-devel] [PATCH RESEND 08/14] libxl/arm: Construct ACPI MADT table

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

According to the gic version, construct the MADT table.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 107 
 1 file changed, 107 insertions(+)

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



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

[Xen-devel] [PATCH RESEND 02/14] libxl/arm: Factor out codes for generating DTB

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

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



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

[Xen-devel] [PATCH RESEND 12/14] libxl/arm: Add ACPI module

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 20 
 1 file changed, 20 insertions(+)

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



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

[Xen-devel] [PATCH] OvmfPkg: Add ACPI support for Virt Xen ARM

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Add ACPI support for Virt Xen ARM and it gets the ACPI tables through
Xen ARM multiboot protocol.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Shannon Zhao 
---
The corresponding Xen patches can be fetched from:
http://git.linaro.org/people/shannon.zhao/xen.git/shortlog/refs/heads/domu_acpi
---
 ArmVirtPkg/ArmVirtXen.dsc |   6 +
 ArmVirtPkg/ArmVirtXen.fdf |   6 +
 OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h|   6 +
 OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c  | 207 ++
 OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatform.c  |  38 
 OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf |  59 ++
 6 files changed, 322 insertions(+)
 create mode 100644 OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c
 create mode 100644 OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatform.c
 create mode 100644 OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf

diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index 594ca64..a0d197f 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -216,3 +216,9 @@
 
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+
+  #
+  # ACPI Support
+  #
+  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
+  OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf
diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
index 13412f9..da30e87 100644
--- a/ArmVirtPkg/ArmVirtXen.fdf
+++ b/ArmVirtPkg/ArmVirtXen.fdf
@@ -179,6 +179,12 @@ READ_LOCK_STATUS   = TRUE
   INF OvmfPkg/XenBusDxe/XenBusDxe.inf
   INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
 
+  #
+  # ACPI Support
+  #
+  INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
+  INF OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf
+
 [FV.FVMAIN_COMPACT]
 FvAlignment= 16
 ERASE_POLARITY = 1
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
index 08dd7f8..325d7e6 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
@@ -69,6 +69,12 @@ InstallXenTables (
 
 EFI_STATUS
 EFIAPI
+InstallXenArmTables (
+  IN   EFI_ACPI_TABLE_PROTOCOL   *AcpiProtocol
+  );
+
+EFI_STATUS
+EFIAPI
 InstallQemuFwCfgTables (
   IN   EFI_ACPI_TABLE_PROTOCOL   *AcpiProtocol
   );
diff --git a/OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c 
b/OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c
new file mode 100644
index 000..c3a351c
--- /dev/null
+++ b/OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c
@@ -0,0 +1,207 @@
+/** @file
+  OVMF ACPI Xen ARM support
+
+  Copyright (C) 2016, Linaro Ltd. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/ 
+
+#include "AcpiPlatform.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER  *XenAcpiRsdpStructurePtr = NULL;
+
+/**
+  Get the address of Xen ACPI Root System Description Pointer (RSDP)
+  structure.
+
+  @param  RsdpStructurePtr   Return pointer to RSDP structure
+
+  @return EFI_SUCCESSFind Xen RSDP structure successfully.
+  @return EFI_NOT_FOUND  Don't find Xen RSDP structure.
+  @return EFI_ABORTEDFind Xen RSDP structure, but it's not integrated.
+
+**/
+EFI_STATUS
+EFIAPI
+GetXenArmAcpiRsdp (
+  OUT   EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   **RsdpPtr
+  )
+{
+  VOID   *Hob;
+  EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   *RsdpStructurePtr;
+  VOID   *DeviceTreeBase;
+  INT32  Node, Depth, Len;
+  CONST CHAR8*Type;
+  CONST VOID *RegProp;
+
+  RsdpStructurePtr = NULL;
+  //
+  // Get the RSDP structure address from DeviceTree
+  //
+  Hob = GetFirstGuidHob();
+  if (Hob == NULL || GET_GUID_HOB_DATA_SIZE (Hob) != sizeof (UINT64)) {
+DEBUG ((EFI_D_ERROR, "%a: Failed to get Fdt Hob\n", __FUNCTION__));
+return EFI_NOT_FOUND;
+  }
+  DeviceTreeBase = (VOID *)(UINTN)*(UINT64 *)GET_GUID_HOB_DATA (Hob);
+
+  if (fdt_check_header (DeviceTreeBase) != 0) {
+DEBUG ((EFI_D_ERROR, "%a: No DTB found @ 0x%p\n", __FUNCTION__, 
DeviceTreeBase));
+return EFI_NOT_FOUND;
+  }
+
+  Node = fdt_path_offset(DeviceTreeBase, "/chosen/modules");
+  if ( Node < 0 ) {
+DEBUG ((EFI_D_ERROR, "%a: NO /chosen/modules found\n", __FUNCTION__));
+return EFI_NOT_FOUND;
+  }
+
+
+  for (Depth = 0;
+   (Node >= 0) && (Depth >= 0);
+   Node = fdt_next_node

[Xen-devel] [qemu-upstream-4.3-testing test] 94966: trouble: blocked/broken

2016-05-30 Thread osstest service owner 
flight 94966 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94966/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  114 days
Testing same since93977  2016-05-10 11:09:16 Z   20 days   86 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

2016-05-30 Thread Shannon Zhao 
Sorry, I Cc'ed the wrong email address of Wei Liu. I'll resend these
patches. Please ignore these ones.

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

-- 
Shannon


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

[Xen-devel] [PATCH 02/14] libxl/arm: Factor out codes for generating DTB

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

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



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

[Xen-devel] [PATCH 04/14] tools: add ACPI tables relevant definitions

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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

Signed-off-by: Shannon Zhao 
---
 tools/libxc/include/acpi_defs.h | 277 
 1 file changed, 277 insertions(+)
 create mode 100644 tools/libxc/include/acpi_defs.h

diff --git a/tools/libxc/include/acpi_defs.h b/tools/libxc/include/acpi_defs.h
new file mode 100644
index 000..9389a96
--- /dev/null
+++ b/tools/libxc/include/acpi_defs.h
@@ -0,0 +1,277 @@
+#ifndef _ACPI_DEFS_H_
+#define _ACPI_DEFS_H_
+
+#define ACPI_BUILD_APPNAME6 "XenARM"
+#define ACPI_BUILD_APPNAME4 "Xen "
+
+#pragma pack (1)
+
+/* Root System Description Pointer Structure. */
+struct acpi_rsdp_descriptor {/* Root System Descriptor Pointer */
+uint64_t signature;  /* ACPI signature, contains "RSD PTR " */
+uint8_t  checksum;   /* To make sum of struct == 0 */
+uint8_t  oem_id[6]; /* OEM identification */
+uint8_t  revision;   /* Must be 0 for 1.0, 2 for 2.0 */
+uint32_t rsdt_physical_address;  /* 32-bit physical address of RSDT */
+uint32_t length; /* XSDT Length in bytes including hdr */
+uint64_t xsdt_physical_address;  /* 64-bit physical address of XSDT */
+uint8_t  extended_checksum;  /* Checksum of entire table */
+uint8_t  reserved[3];   /* Reserved field must be 0 */
+};
+
+/* ACPI common table header. */
+struct acpi_table_header {
+uint32_t signature;  /* ACPI signature (4 ASCII characters) */ \
+uint32_t length; /* Length of table, in bytes, including 
header */ \
+uint8_t  revision;   /* ACPI Specification minor version # */ \
+uint8_t  checksum;   /* To make sum of entire table == 0 */ \
+uint8_t  oem_id[6]; /* OEM identification */ \
+uint8_t  oem_table_id[8];   /* OEM table identification */ \
+uint32_t oem_revision;   /* OEM revision number */ \
+uint8_t  asl_compiler_id[4];/* ASL compiler vendor ID */ \
+uint32_t asl_compiler_revision;  /* ASL compiler revision number */
+};
+
+/* Extended System Description Table (XSDT). */
+struct acpi_xsdt_descriptor {
+struct acpi_table_header header;
+uint64_t entry[0];
+};
+
+/* Generic Timer Description Table (GTDT). */
+#define ACPI_GTDT_INTERRUPT_MODE0
+#define ACPI_GTDT_INTERRUPT_POLARITY1
+#define ACPI_GTDT_ALWAYS_ON 2
+
+/* Triggering */
+#define ACPI_LEVEL_SENSITIVE((uint8_t) 0x00)
+#define ACPI_EDGE_SENSITIVE ((uint8_t) 0x01)
+
+/* Polarity */
+#define ACPI_ACTIVE_HIGH((uint8_t) 0x00)
+#define ACPI_ACTIVE_LOW ((uint8_t) 0x01)
+
+struct acpi_gtdt_descriptor {
+struct acpi_table_header header;
+uint64_t counter_block_addresss;
+uint32_t reserved;
+uint32_t secure_el1_interrupt;
+uint32_t secure_el1_flags;
+uint32_t non_secure_el1_interrupt;
+uint32_t non_secure_el1_flags;
+uint32_t virtual_timer_interrupt;
+uint32_t virtual_timer_flags;
+uint32_t non_secure_el2_interrupt;
+uint32_t non_secure_el2_flags;
+uint64_t counter_read_block_address;
+uint32_t platform_timer_count;
+uint32_t platform_timer_offset;
+};
+
+/* Multiple APIC Description Table header definition (MADT). */
+struct acpi_madt_descriptor
+{
+struct acpi_table_header header; /* ACPI common table header */
+uint32_t local_apic_address; /* Physical address of local APIC */
+uint32_t flags;
+};
+
+/* Values for Type in APIC sub-headers. */
+
+#define ACPI_APIC_PROCESSOR  0
+#define ACPI_APIC_IO 1
+#define ACPI_APIC_XRUPT_OVERRIDE 2
+#define ACPI_APIC_NMI3
+#define ACPI_APIC_LOCAL_NMI  4
+#define ACPI_APIC_ADDRESS_OVERRIDE   5
+#define ACPI_APIC_IO_SAPIC   6
+#define ACPI_APIC_LOCAL_SAPIC7
+#define ACPI_APIC_XRUPT_SOURCE   8
+#define ACPI_APIC_LOCAL_X2APIC   9
+#define ACPI_APIC_LOCAL_X2APIC_NMI  10
+#define ACPI_APIC_GENERIC_INTERRUPT 11
+#define ACPI_APIC_GENERIC_DISTRIBUTOR   12
+#define ACPI_APIC_GENERIC_MSI_FRAME 13
+#define ACPI_APIC_GENERIC_REDISTRIBUTOR 14
+#define ACPI_APIC_RESERVED  15   /* 15 and greater are reserved */
+
+/*
+ * MADT sub-structures (Follow MULTIPLE_APIC_DESCRIPTION_TABLE).
+ */
+#define ACPI_SUB_HEADER_DEF   /* Common ACPI sub-structure header */\
+uint8_t  type;   \
+uint8_t  length;
+
+/* Sub-structures for MADT */
+
+struct acpi_madt_generic_interrupt {
+ACPI_SUB_HEADER_DEF
+uint16_t reserved;
+uint32_t cpu_interface_number;
+uint32_t uid;
+uint32_t flags;
+uint32_t parking_version;
+uint32_t performance_interrupt;
+uint64_t parked_address;
+uint64_t base_address;
+

[Xen-devel] [PATCH 13/14] libxl/arm: initialize memory information of ACPI blob

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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

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

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



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

[Xen-devel] [PATCH 12/14] libxl/arm: Add ACPI module

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 20 
 1 file changed, 20 insertions(+)

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



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

[Xen-devel] [PATCH 08/14] libxl/arm: Construct ACPI MADT table

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

According to the gic version, construct the MADT table.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 107 
 1 file changed, 107 insertions(+)

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



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

[Xen-devel] [PATCH 14/14] libxc/xc_dom_core: Copy ACPI tables to guest memory space

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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

Signed-off-by: Shannon Zhao 
---
 tools/libxc/xc_dom_core.c | 59 +++
 1 file changed, 59 insertions(+)

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



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

[Xen-devel] [PATCH 05/14] libxl/arm: Construct ACPI GTDT table

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Construct GTDT table with the interrupt information of timers.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 75 -
 1 file changed, 74 insertions(+), 1 deletion(-)

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



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

[Xen-devel] [PATCH 10/14] libxl/arm: Construct ACPI RSDP table

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 18 ++
 1 file changed, 18 insertions(+)

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



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

[Xen-devel] [PATCH 03/14] libxc: Add placeholders for ACPI tables blob and size

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT
for ARM VM. So only add placeholders for them here.

Signed-off-by: Shannon Zhao 
---
 tools/libxc/include/xc_dom.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6cb10c4..0fe54dd 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -56,6 +56,20 @@ struct xc_dom_phys {
 xen_pfn_t count;
 };
 
+struct acpitable {
+void *table;
+size_t size;
+};
+
+struct acpitable_blob {
+struct acpitable rsdp;
+struct acpitable xsdt;
+struct acpitable gtdt;
+struct acpitable madt;
+struct acpitable fadt;
+struct acpitable dsdt;
+};
+
 struct xc_dom_image {
 /* files */
 void *kernel_blob;
@@ -64,6 +78,8 @@ struct xc_dom_image {
 size_t ramdisk_size;
 void *devicetree_blob;
 size_t devicetree_size;
+struct acpitable_blob *acpitable_blob;
+size_t acpitable_size;
 
 size_t max_kernel_size;
 size_t max_ramdisk_size;
@@ -92,6 +108,7 @@ struct xc_dom_image {
 struct xc_dom_seg p2m_seg;
 struct xc_dom_seg pgtables_seg;
 struct xc_dom_seg devicetree_seg;
+struct xc_dom_seg acpi_seg;
 struct xc_dom_seg start_info_seg; /* HVMlite only */
 xen_pfn_t start_info_pfn;
 xen_pfn_t console_pfn;
-- 
2.0.4



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

[Xen-devel] [PATCH 09/14] libxl/arm: Construct ACPI XSDT table

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 23 +++
 1 file changed, 23 insertions(+)

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



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

[Xen-devel] [PATCH 11/14] libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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 
---
 tools/libxl/libxl_arm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

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



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

[Xen-devel] [PATCH 06/14] libxl/arm: Construct ACPI FADT table

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 23 +++
 1 file changed, 23 insertions(+)

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



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

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

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

Currently there is only the table header in DSDT table.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index c3b8fb4..7949635 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -944,6 +944,20 @@ static void make_acpi_fadt(libxl__gc *gc, struct 
xc_dom_image *dom)
 dom->acpitable_size += dom->acpitable_blob->fadt.size;
 }
 
+static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+struct acpi_table_header *dsdt;
+
+/* Currently there is only the table header in DSDT table. */
+dsdt = libxl__zalloc(gc, sizeof(*dsdt));
+make_acpi_header((void *)dsdt, "DSDT", sizeof(*dsdt), 2);
+
+dom->acpitable_blob->dsdt.table = (void *)dsdt;
+/* Align to 64bit. */
+dom->acpitable_blob->dsdt.size = ROUNDUP(sizeof(*dsdt), 3);
+dom->acpitable_size += ROUNDUP(dom->acpitable_blob->dsdt.size, 3);
+}
+
 static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
@@ -966,6 +980,7 @@ static int prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 
 make_acpi_gtdt(gc, dom);
 make_acpi_fadt(gc, dom);
+make_acpi_dsdt(gc, dom);
 
 return 0;
 }
-- 
2.0.4



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

[Xen-devel] [PATCH 01/14] libxl/arm: Fix the function name in error log

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

It should be xc_dom_devicetree_mem instead of xc_dom_devicetree_file.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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



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

[Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

2016-05-30 Thread Shannon Zhao 
From: Shannon Zhao 

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

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

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

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

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

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

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

-- 
2.0.4



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

[Xen-devel] [PATCH RESEND 3/4] qdisk, hw/block/xen_disk: Perform grant copy instead of grant map.

2016-05-30 Thread Paulina Szubarczyk 
Grant copy operation is divided into two phases different for
'read' and 'write' operation.

For a 'read' operation the flow is as follow:
1. allocate local buffers for all the segments contained in
   a request.
2. fill the request io vectors with the buffers' addresses
3. invoke read operation by qemu device
4. in the completition call grant copy
5. free the buffers

Function 'ioreq_read_init' implements 1. and 2. step. It is called
instead of 'ioreq_map' in 'ioreq_runio_qemu_aio'. Then the function
'ioreq_runio_qemu_aio' continues withouth changes performing step 3.
Steps 4. and 5. are called in the callback function
'qemu_aio_complete'. The ioreq_read' function is implemented for
step 4 which calls the new function 'xc_gnttab_copy_grant' presented
in the other part of the patch.

For a 'write' operation steps 4. happens before step 2.. First data
are copied from calling guest domains and then qemu operates on
them.
---
 hw/block/xen_disk.c | 185 
 1 file changed, 185 insertions(+)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 3b7882e..43cd9c9 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -284,6 +284,154 @@ err:
 return -1;
 }
 
+
+static void* get_buffer(void) {
+void *buf;
+
+buf = mmap(NULL, 1 << XC_PAGE_SHIFT, PROT_READ | PROT_WRITE, 
+   MAP_SHARED | MAP_ANONYMOUS, -1, 0);
+
+if (unlikely(buf == MAP_FAILED))
+return NULL;
+
+return buf;
+}
+
+static int free_buffer(void* buf) {
+return munmap(buf, 1 << XC_PAGE_SHIFT);
+}
+
+static int free_buffers(void** page, int count) 
+{
+int i, r = 0;
+
+for (i = 0; i < count; i++) { 
+
+if(free_buffer(page[i])) 
+r = 1;
+
+page[i] = NULL;
+}
+
+return r;
+}
+
+static int ioreq_write(struct ioreq *ioreq) 
+{
+XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
+uint16_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+uint32_t offset[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+uint32_t len[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+void *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+int i, count = 0, rc, r;
+/* Copy the data for write operation from guest grant pages addressed by 
+ * domids, refs, offset, len to local buffers.
+ * 
+ * Bufferes are then mapped to the pending request for further 
+ * completition.
+ */
+
+if (ioreq->v.niov == 0) {
+r = 0; goto out;
+}
+
+count = ioreq->v.niov;
+for (i = 0; i < count; i++) {
+domids[i] = ioreq->domids[i];
+refs[i]   = ioreq->refs[i];
+offset[i] = ioreq->req.seg[i].first_sect * ioreq->blkdev->file_blk;
+len[i] = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 
1) 
+  * ioreq->blkdev->file_blk;
+pages[i]  = get_buffer();
+
+if(!pages[i]) {
+xen_be_printf(>blkdev->xendev, 0, 
+  "failed to alloc page, errno %d \n", errno);
+r = 1; goto out;
+}
+}
+rc = xc_gnttab_copy_grant(gnt, count, domids, refs, pages, offset, len, 1);
+
+if(rc) {
+xen_be_printf(>blkdev->xendev, 0, 
+  "failed to copy data for write %d \n", rc);
+
+if(free_buffers(ioreq->page, ioreq->v.niov)) {
+xen_be_printf(>blkdev->xendev, 0, 
+  "failed to free page, errno %d \n", errno);
+}
+r = 1; goto out;
+}
+
+for (i = 0; i < ioreq->v.niov; i++) {
+ioreq->page[i] = pages[i];
+ioreq->v.iov[i].iov_base += (uintptr_t)pages[i];
+}
+
+r = 0;
+out:
+return r;
+}
+
+static int ioreq_read_init(struct ioreq *ioreq) 
+{
+int i;
+
+if (ioreq->v.niov == 0) {
+return 0;
+}
+
+for (i = 0; i < ioreq->v.niov; i++) {
+ioreq->page[i] = get_buffer();
+if(!ioreq->page[i]) {
+return -1;
+}
+ioreq->v.iov[i].iov_base += (uintptr_t)ioreq->page[i];
+}
+
+return 0;
+}
+
+static int ioreq_read(struct ioreq *ioreq) 
+{
+XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
+uint16_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+uint32_t offset[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+uint32_t len[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+void *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+int i, count = 0, rc;
+
+/* Copy the data from local buffers to guest grant pages addressed by 
+ * domids, refs, offset on the completition of read operation.
+ */
+
+if (ioreq->v.niov == 0) {
+return 0;
+}
+
+count = ioreq->v.niov;
+for (i = 0; i < count; i++) {
+domids[i] = ioreq->domids[i];
+refs[i]   = ioreq->refs[i];
+offset[i] = ioreq->req.seg[i].first_sect * ioreq->blkdev->file_blk;
+len[i] = (ioreq->req.seg[i].last_sect -

[Xen-devel] [PATCH RESEND 4/4] qemu-xen-dir/hw/block: Cache local buffers used in grant copy

2016-05-30 Thread Paulina Szubarczyk 
If there are still pending requests the buffers are not free() but
cached in an array of a size max_request*BLKIF_MAX_SEGMENTS_PER_REQUEST

---
 hw/block/xen_disk.c | 60 +
 1 file changed, 47 insertions(+), 13 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 43cd9c9..cf80897 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -125,6 +125,10 @@ struct XenBlkDev {
 /* */
 gbooleanfeature_discard;
 
+/* request buffer cache */
+void**buf_cache;
+int buf_cache_free;
+
 /* qemu block driver */
 DriveInfo   *dinfo;
 BlockBackend*blk;
@@ -284,12 +288,16 @@ err:
 return -1;
 }
 
-
-static void* get_buffer(void) {
+static void* get_buffer(struct XenBlkDev *blkdev) {
 void *buf;
 
-buf = mmap(NULL, 1 << XC_PAGE_SHIFT, PROT_READ | PROT_WRITE, 
+if(blkdev->buf_cache_free <= 0) {
+buf = mmap(NULL, 1 << XC_PAGE_SHIFT, PROT_READ | PROT_WRITE, 
MAP_SHARED | MAP_ANONYMOUS, -1, 0);
+} else {
+blkdev->buf_cache_free--;
+buf = blkdev->buf_cache[blkdev->buf_cache_free];
+}
 
 if (unlikely(buf == MAP_FAILED))
 return NULL;
@@ -301,21 +309,40 @@ static int free_buffer(void* buf) {
 return munmap(buf, 1 << XC_PAGE_SHIFT);
 }
 
-static int free_buffers(void** page, int count) 
+static int free_buffers(void** page, int count, struct XenBlkDev *blkdev) 
 {
-int i, r = 0;
+int i, put_buf_cache = 0, r = 0;
+
+if (blkdev->more_work && blkdev->requests_inflight < max_requests) {
+put_buf_cache = max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST
+- blkdev->buf_cache_free;
+}
 
 for (i = 0; i < count; i++) { 
-
-if(free_buffer(page[i])) 
-r = 1;
-
+if(put_buf_cache > 0) {
+blkdev->buf_cache[blkdev->buf_cache_free++] = page[i];
+put_buf_cache--;
+} else { 
+if(free_buffer(page[i])) 
+r = 1;
+}
+
 page[i] = NULL;
 }
 
 return r;
 }
 
+static void free_buf_cache(struct XenBlkDev *blkdev) {
+int i;
+for(i = 0; i < blkdev->buf_cache_free; i++) {
+free_buffer(blkdev->buf_cache[i]);
+}
+
+blkdev->buf_cache_free = 0;
+free(blkdev->buf_cache);
+}
+
 static int ioreq_write(struct ioreq *ioreq) 
 {
 XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
@@ -343,7 +370,7 @@ static int ioreq_write(struct ioreq *ioreq)
 offset[i] = ioreq->req.seg[i].first_sect * ioreq->blkdev->file_blk;
 len[i] = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 
1) 
   * ioreq->blkdev->file_blk;
-pages[i]  = get_buffer();
+pages[i]  = get_buffer(ioreq->blkdev);
 
 if(!pages[i]) {
 xen_be_printf(>blkdev->xendev, 0, 
@@ -357,7 +384,7 @@ static int ioreq_write(struct ioreq *ioreq)
 xen_be_printf(>blkdev->xendev, 0, 
   "failed to copy data for write %d \n", rc);
 
-if(free_buffers(ioreq->page, ioreq->v.niov)) {
+if(free_buffers(ioreq->page, ioreq->v.niov, ioreq->blkdev)) {
 xen_be_printf(>blkdev->xendev, 0, 
   "failed to free page, errno %d \n", errno);
 }
@@ -383,7 +410,7 @@ static int ioreq_read_init(struct ioreq *ioreq)
 }
 
 for (i = 0; i < ioreq->v.niov; i++) {
-ioreq->page[i] = get_buffer();
+ioreq->page[i] = get_buffer(ioreq->blkdev);
 if(!ioreq->page[i]) {
 return -1;
 }
@@ -469,7 +496,7 @@ static void qemu_aio_complete(void *opaque, int ret)
   "failed to copy read data to guest\n");
 }
 case BLKIF_OP_WRITE:
-if(free_buffers(ioreq->page, ioreq->v.niov)) {
+if(free_buffers(ioreq->page, ioreq->v.niov, ioreq->blkdev)) {
 xen_be_printf(>blkdev->xendev, 0, 
   "failed to free page, errno %d \n", errno);
 }
@@ -936,6 +963,11 @@ static int blk_connect(struct XenDevice *xendev)
 }
 blkdev->cnt_map++;
 
+/* create buffer cache for grant copy operations*/
+blkdev->buf_cache_free = 0;
+blkdev->buf_cache = calloc(max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST, 
+   sizeof(void *));
+
 switch (blkdev->protocol) {
 case BLKIF_PROTOCOL_NATIVE:
 {
@@ -972,6 +1004,8 @@ static void blk_disconnect(struct XenDevice *xendev)
 {
 struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
 
+free_buf_cache(blkdev);
+
 if (blkdev->blk) {
 blk_detach_dev(blkdev->blk, blkdev);
 blk_unref(blkdev->blk);
-- 
1.9.1


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

[Xen-devel] [PATCH RESEND 1/4] libs, gnttab, libxc: Interface for grant copy operation

2016-05-30 Thread Paulina Szubarczyk 
Implentation of interface to grant copy operation called through
libxc. An ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) system call is
invoked for linux. In the mini-os the operation is yet not
implemented.

* In the file "tools/include/xen-sys/Linux/gntdev.h" added
  - 'struct ioctl_gntdev_grant_copy_segment'
The structure is analogous to 'struct gntdev_grant_copy_segment'
defined in linux code include/uapi/xen/gntdev.h. Typdefs are
replaced by they original types:
  typedef uint16_t domid_t;
  typedef uint32_t grant_ref_t;
That leads to defining domids array with type uint16_t in libs,
differently then in other functions concerning grant table
operations in that library.

` - macro #define IOCTL_GNTDEV_GRANT_COPY

  - 'struct ioctl_gntdev_grant_copy'
taken from linux code as higher. Structure aggregating
'struct gntdev_grant_copy_segment'

* In the file libs/gnttab/linux.c
  - function int osdep_gnttab_grant_copy(xengnttab_handle *xgt,
  uint32_t count,
  uint16_t *domids, uint32_t *refs, void
  **bufs, uint32_t *offset, uint32_t *len,
  int type, uint32_t notify_offset,
  evtchn_port_t notify_port)

It is a function used to perform grant copy opertion. It allocats
'ioctl_gntdev_grant_copy' and 'ioctl_gntdev_grant_copy_segment'.
Segments are filled from the passed values.

When @type is different then zero the source to copy from are guest
domain grant pages addressed by @refs and the destination is local
memory accessed from @bufs, the operation flag is then set to
'GNTCOPY_source_gref', contrarily for @type equal zero.

@offset is the offset on the page
@len is the amount of data to copy,
@offset[i] + @len[i] should not exceed XEN_PAGE_SIZE
- the condition is checked in gntdev device.

Notification is yet not implemented.
---
 tools/include/xen-sys/Linux/gntdev.h  | 21 ++
 tools/libs/gnttab/gnttab_core.c   | 12 ++
 tools/libs/gnttab/include/xengnttab.h | 18 +
 tools/libs/gnttab/libxengnttab.map|  2 +
 tools/libs/gnttab/linux.c | 72 +++
 tools/libs/gnttab/minios.c|  8 
 tools/libs/gnttab/private.h   |  6 +++
 tools/libxc/include/xenctrl_compat.h  |  8 
 tools/libxc/xc_gnttab_compat.c| 12 ++
 9 files changed, 159 insertions(+)

diff --git a/tools/include/xen-sys/Linux/gntdev.h 
b/tools/include/xen-sys/Linux/gntdev.h
index caf6fb4..0ca07c9 100644
--- a/tools/include/xen-sys/Linux/gntdev.h
+++ b/tools/include/xen-sys/Linux/gntdev.h
@@ -147,4 +147,25 @@ struct ioctl_gntdev_unmap_notify {
 /* Send an interrupt on the indicated event channel */
 #define UNMAP_NOTIFY_SEND_EVENT 0x2
 
+struct ioctl_gntdev_grant_copy_segment {
+union {
+void *virt;
+struct {
+uint32_t ref;
+uint16_t offset;
+uint16_t domid;
+} foreign;
+} source, dest;
+uint16_t len;
+uint16_t flags;
+int16_t status;
+};
+
+#define IOCTL_GNTDEV_GRANT_COPY \
+_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
+struct ioctl_gntdev_grant_copy {
+unsigned int count;
+struct ioctl_gntdev_grant_copy_segment *segments;
+};
+
 #endif /* __LINUX_PUBLIC_GNTDEV_H__ */
diff --git a/tools/libs/gnttab/gnttab_core.c b/tools/libs/gnttab/gnttab_core.c
index 5d0474d..1e014f8 100644
--- a/tools/libs/gnttab/gnttab_core.c
+++ b/tools/libs/gnttab/gnttab_core.c
@@ -113,6 +113,18 @@ int xengnttab_unmap(xengnttab_handle *xgt, void 
*start_address, uint32_t count)
 return osdep_gnttab_unmap(xgt, start_address, count);
 }
 
+int xengnttab_copy_grant(xengnttab_handle *xgt,
+ uint32_t count,
+ uint16_t *domids,
+ uint32_t *refs,
+ void **bufs,
+ uint32_t *offset, 
+ uint32_t *len,
+ int type)
+{
+return osdep_gnttab_grant_copy(xgt, count, domids, refs, bufs, offset, 
len, 
+   type, -1, -1);
+}
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/gnttab/include/xengnttab.h 
b/tools/libs/gnttab/include/xengnttab.h
index 0431dcf..923e022 100644
--- a/tools/libs/gnttab/include/xengnttab.h
+++ b/tools/libs/gnttab/include/xengnttab.h
@@ -258,6 +258,24 @@ int xengnttab_unmap(xengnttab_handle *xgt, void 
*start_address, uint32_t count);
 int xengnttab_set_max_grants(xengnttab_handle *xgt,
  uint32_t nr_grants);
 
+/**
+ * Copy memory from or to the domains defined in domids array.
+ * When @type is different then zero data is copied from grant pages addressed 
+ * by @refs to @bufs, and contrarily for @type equal zero. 
+ *
+ * @offset is the offset on the page 
+ * @len is the amount of data to copy 
+ *

[Xen-devel] [PATCH RESEND 2/4] qdisk, hw/block/xen_disk: Removal of grant mapping

2016-05-30 Thread Paulina Szubarczyk 
Grant mapping related functions and variables are removed
on behalf of grant copy operation introduced in following commits.
---
 hw/block/xen_disk.c | 284 ++--
 1 file changed, 10 insertions(+), 274 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 37e14d1..3b7882e 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -79,13 +79,12 @@ struct ioreq {
 int postsync;
 uint8_t mapped;
 
-/* grant mapping */
-uint32_tdomids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+/* grant copy */
+uint16_tdomids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 int prot;
 void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 void*pages;
-int num_unmap;
 
 /* aio status */
 int aio_inflight;
@@ -123,13 +122,8 @@ struct XenBlkDev {
 int requests_inflight;
 int requests_finished;
 
-/* Persistent grants extension */
+/* */
 gbooleanfeature_discard;
-gbooleanfeature_persistent;
-GTree   *persistent_gnts;
-GSList  *persistent_regions;
-unsigned intpersistent_gnt_count;
-unsigned intmax_grants;
 
 /* qemu block driver */
 DriveInfo   *dinfo;
@@ -164,46 +158,6 @@ static void ioreq_reset(struct ioreq *ioreq)
 qemu_iovec_reset(>v);
 }
 
-static gint int_cmp(gconstpointer a, gconstpointer b, gpointer user_data)
-{
-uint ua = GPOINTER_TO_UINT(a);
-uint ub = GPOINTER_TO_UINT(b);
-return (ua > ub) - (ua < ub);
-}
-
-static void destroy_grant(gpointer pgnt)
-{
-PersistentGrant *grant = pgnt;
-XenGnttab gnt = grant->blkdev->xendev.gnttabdev;
-
-if (xc_gnttab_munmap(gnt, grant->page, 1) != 0) {
-xen_be_printf(>blkdev->xendev, 0,
-  "xc_gnttab_munmap failed: %s\n",
-  strerror(errno));
-}
-grant->blkdev->persistent_gnt_count--;
-xen_be_printf(>blkdev->xendev, 3,
-  "unmapped grant %p\n", grant->page);
-g_free(grant);
-}
-
-static void remove_persistent_region(gpointer data, gpointer dev)
-{
-PersistentRegion *region = data;
-struct XenBlkDev *blkdev = dev;
-XenGnttab gnt = blkdev->xendev.gnttabdev;
-
-if (xc_gnttab_munmap(gnt, region->addr, region->num) != 0) {
-xen_be_printf(>xendev, 0,
-  "xc_gnttab_munmap region %p failed: %s\n",
-  region->addr, strerror(errno));
-}
-xen_be_printf(>xendev, 3,
-  "unmapped grant region %p with %d pages\n",
-  region->addr, region->num);
-g_free(region);
-}
-
 static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
 {
 struct ioreq *ioreq = NULL;
@@ -314,7 +268,9 @@ static int ioreq_parse(struct ioreq *ioreq)
 ioreq->refs[i]   = ioreq->req.seg[i].gref;
 
 mem = ioreq->req.seg[i].first_sect * blkdev->file_blk;
-len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 1) 
* blkdev->file_blk;
+len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 1) 
+  * blkdev->file_blk;
+
 qemu_iovec_add(>v, (void*)mem, len);
 }
 if (ioreq->start + ioreq->v.size > blkdev->file_size) {
@@ -328,178 +284,6 @@ err:
 return -1;
 }
 
-static void ioreq_unmap(struct ioreq *ioreq)
-{
-XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
-int i;
-
-if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
-return;
-}
-if (batch_maps) {
-if (!ioreq->pages) {
-return;
-}
-if (xc_gnttab_munmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
-xen_be_printf(>blkdev->xendev, 0, "xc_gnttab_munmap failed: 
%s\n",
-  strerror(errno));
-}
-ioreq->blkdev->cnt_map -= ioreq->num_unmap;
-ioreq->pages = NULL;
-} else {
-for (i = 0; i < ioreq->num_unmap; i++) {
-if (!ioreq->page[i]) {
-continue;
-}
-if (xc_gnttab_munmap(gnt, ioreq->page[i], 1) != 0) {
-xen_be_printf(>blkdev->xendev, 0, "xc_gnttab_munmap 
failed: %s\n",
-  strerror(errno));
-}
-ioreq->blkdev->cnt_map--;
-ioreq->page[i] = NULL;
-}
-}
-ioreq->mapped = 0;
-}
-
-static int ioreq_map(struct ioreq *ioreq)
-{
-XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
-uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-int i, j, new_maps = 0;
-PersistentGrant *grant;
-PersistentRegion *region;
-/* domids and refs variables will contain the information necessary
- * to

[Xen-devel] [PATCH RESEND 0/4] qemu-qdisk: Replace grant map by grant copy.

2016-05-30 Thread Paulina Szubarczyk 
Hi,

The patches are resend with split of patch #2.

It is a proposition for implementation of the replacement of the grant map 
operation with grant copy. 

I would appreciate an opinion about the approach if is proper or maybe 
I assumed something wrongly, and if you see any possibility of improvement
or the things that need to be changed.
If the approach is any good, I need to still rethink batch mode, 
notification(?) 
and implementation for mini-os.

In the libs, gnttab, linbxc there is added interface and invocation of 
an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) system call on the gnttdev 
device. 
Described in details in the following messages. It is not implemented for 
mini-os.

The grant map operation is replaced on the behalf of grant copy in 
qemu-xen-dir/hw/block/xen_disk. The implementation is described in the patch.

For the functional test I attached the device with a qdisk backend to the guest.
I successfully mounted it and stored files there. During creation of 
a file system on the device BLKIF_OP_DISCARD operation seems to fail(ret value 
different then zero) but it also fails for the original version due to error 
return from qemu.

I made fio tests before[0] and after[1] the changes with different iodepth and 
size of the block. The test which I run can be accessed on my github[2] but 
mainly after the warm up I run for 60 seconds:
fio --time_based \
--clocksource=clock_gettime \
--rw=randread \
--random_distribution=pareto:0.9 \
--size=10g \
--direct='1' \
--ioengine=libaio \
--filename=$DEV \
--iodepth=$IODEPTH \
--bs=$BS \
--name=$NAME \
--runtime=$RUNTIME >> $FILENAME
The test were repeated at least three times. 

Although before the changes results looks coherent for me, after there are
considerable peaks for iodepth = {4,8}.

[0] 
https://docs.google.com/spreadsheets/d/1n0lraodhF5jlNO-YWNTgl57Aoe3K5S7Qke8YQQkGCDQ/edit?usp=sharing
[1] 
https://docs.google.com/spreadsheets/d/1E6AMiB8ceJpExL6jWpH9u2yy6DZxzhmDUyFf-eUuJ0c/edit?usp=sharing
- domU sheets
[2] https://github.com/paulina-szubarczyk/xen-benchmark
- multitest_with_iodepth.sh


Thanks and regards, 
Paulina

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

[Xen-devel] [ovmf test] 94963: regressions - FAIL

2016-05-30 Thread osstest service owner 
flight 94963 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94963/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 3ab7066e8d8ae43d9cdee76600b90918f8bee5d9
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z6 days
Failing since 94750  2016-05-25 03:43:08 Z6 days   18 attempts
Testing same since94958  2016-05-30 13:43:03 Z0 days2 attempts


People who touched revisions under test:
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  Eugene Cohen 
  Gary Lin 
  Hao Wu 
  Jeff Fan 
  Jiaxin Wu 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Star Zeng 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 683 lines long.)

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

[Xen-devel] [PATCH v4 4/4] xen/arm: arm64: Remove MPIDR multiprocessing extensions check

2016-05-30 Thread Wei Chen 
In AArch32, MPIDR bit 31 is defined as multiprocessing extensions bit.
But in AArch64, this bit is always RES1. So the value check for this
bit is no longer necessary in AArch64.

Signed-off-by: Wei Chen 
Reviewed-by: Julien Grall 
---
v3-->v4:
1. Add missed Reviewed-by tag.

v2--v3:
1. Fix a typo in commit messages.
2. Add Julien's Reviewed-by.

v1-->v2:
Make clear the status of MPIDR.SMP bit in AArch32 and AArch64.
---
 xen/arch/arm/arm64/head.S | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 3090beb..91e2817 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -267,7 +267,6 @@ common_start:
   * find that multiprocessor extensions are
   * present and the system is SMP  */
 mrs   x0, mpidr_el1
-tbz   x0, _MPIDR_SMP, 1f /* Multiprocessor extension not 
supported? */
 tbnz  x0, _MPIDR_UP, 1f  /* Uniprocessor system? */
 
 ldr   x13, =(~MPIDR_HWID_MASK)
-- 
2.7.4


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

[Xen-devel] [PATCH v4 0/4] xen/arm: arm64: Widen register access to mpidr to 64-bits

2016-05-30 Thread Wei Chen 
In ARM64 the MPIDR register is mapped to MPIDR_EL1, and the register
bits are expanded to 64-bits. But Xen 64-bit ARM code treats this it
as 32-bit register.
We have to provide correct accessing to this register to avoid
unexpected issues that is caused by incorrect MPIDR value.

Wei Chen (4):
  xen/arm: Change the variable type of cpu_logical_map to register_t
  xen/arm: Make AFFINITY_MASK generate correct mask for level3
  xen:arm: arm64: Add correct MPIDR_HWID_MASK value for ARM64
  xen/arm: arm64: Remove MPIDR multiprocessing extensions check

 xen/arch/arm/arm64/head.S   |  3 +--
 xen/arch/arm/gic-v3.c   |  2 +-
 xen/arch/arm/smpboot.c  | 13 +++--
 xen/include/asm-arm/processor.h |  9 +++--
 4 files changed, 16 insertions(+), 11 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH v4 2/4] xen/arm: Make AFFINITY_MASK generate correct mask for level3

2016-05-30 Thread Wei Chen 
The original affinity shift bits algorithm in AFFINITY_MASK is buggy,
it could not generate correct affinity shift bits of level3.
The macro MPIDR_LEVEL_SHIFT can calculate level3 affinity shift bits
correctly. We use this macro in AFFINITY_MASK to generate correct
mask for level3.

Signed-off-by: Wei Chen 
Reviewed-by: Julien Grall 
---
v3-->v4:
Add missed Reviewed-by tag.

v2-->v3:
Update version numnber.

v1-->v2:
Add Julien's reviewed-by.
---
 xen/include/asm-arm/processor.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 7de9c8e..b4cce7e 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -21,7 +21,6 @@
 #define MPIDR_HWID_MASK _AC(0xff,U)
 #define MPIDR_INVALID   (~MPIDR_HWID_MASK)
 #define MPIDR_LEVEL_BITS(8)
-#define AFFINITY_MASK(level)~((_AC(0x1,U) << ((level) * MPIDR_LEVEL_BITS)) 
- 1)
 
 
 /*
@@ -37,6 +36,8 @@
 #define MPIDR_AFFINITY_LEVEL(mpidr, level) \
  ((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
 
+#define AFFINITY_MASK(level)~((_AC(0x1,UL) << MPIDR_LEVEL_SHIFT(level)) - 
1)
+
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_EAE_AC(0x8000,U)
 #define TTBCR_N_MASK _AC(0x07,U)
-- 
2.7.4


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

[Xen-devel] [PATCH v4 3/4] xen:arm: arm64: Add correct MPIDR_HWID_MASK value for ARM64

2016-05-30 Thread Wei Chen 
Currently, MPIDR_HWID_MASK is using the bit definition of AArch32
MPIDR register. But from D7.2.67 of ARM ARM (DDI 0487A.i) we can see
there are 4 levels of affinity on AArch64 whilst AArch32 has only 3.
So, this value is not correct when Xen is running on AArch64.

Now, we use the value 0xff00ff for this macro on AArch64. But
neither of this value and its bitwise invert value can be used in mov
instruction with the encoding of {imm16:shift} or {imms:immr}. So we
have to use ldr to load the bitwise invert value to register.

The details of mov immediate encoding are listed in C4.2.5 of ARM ARM
(DDI 0487A.i).

Signed-off-by: Wei Chen 
---
v3-->v4:
1. Update version number.

v2-->v3:
1. Add version information of mentioned ARM ARM.

v1-->v2: Address Julien's comments
1. Fix typos in commit messages.
2. Explain valid MPIDR_HWID_MASK value in AArch64.
3. Simply explain mov immediate encoding.
---
 xen/arch/arm/arm64/head.S   | 2 +-
 xen/include/asm-arm/processor.h | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index d5831f2..3090beb 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -270,7 +270,7 @@ common_start:
 tbz   x0, _MPIDR_SMP, 1f /* Multiprocessor extension not 
supported? */
 tbnz  x0, _MPIDR_UP, 1f  /* Uniprocessor system? */
 
-mov   x13, #(~MPIDR_HWID_MASK)
+ldr   x13, =(~MPIDR_HWID_MASK)
 bic   x24, x0, x13   /* Mask out flags to get CPU ID */
 1:
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index b4cce7e..284ad6a 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -18,7 +18,11 @@
 #define MPIDR_SMP   (_AC(1,U) << _MPIDR_SMP)
 #define MPIDR_AFF0_SHIFT(0)
 #define MPIDR_AFF0_MASK (_AC(0xff,U) << MPIDR_AFF0_SHIFT)
+#ifdef CONFIG_ARM_64
+#define MPIDR_HWID_MASK _AC(0xff00ff,UL)
+#else
 #define MPIDR_HWID_MASK _AC(0xff,U)
+#endif
 #define MPIDR_INVALID   (~MPIDR_HWID_MASK)
 #define MPIDR_LEVEL_BITS(8)
 
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v3 0/4] xen/arm: arm64: Widen register access to mpidr to 64-bits

2016-05-30 Thread Wei Chen 
Hi Stefano,

On 30 May 2016 at 21:24, Stefano Stabellini  wrote:
> On Mon, 30 May 2016, Wei Chen wrote:
>> In ARM64 the MPIDR register is mapped to MPIDR_EL1, and the register
>> bits are expanded to 64-bits. But Xen 64-bit ARM code treats this it
>> as 32-bit register.
>> We have to provide correct accessing to this register to avoid
>> unexpected issues that is caused by incorrect MPIDR value.
>
> Please don't drop acked-by and reviewed-by tags in the future (unless
> you make significant changes to the patches).
>
Thanks for your kindly reminder!

>
>> Wei Chen (4):
>>   xen/arm: Change the variable type of cpu_logical_map to register_t
>>   xen/arm: Make AFFINITY_MASK generate correct mask for level3
>>   xen:arm: arm64: Add correct MPIDR_HWID_MASK value for ARM64
>>   xen/arm: arm64: Remove MPIDR multiprocessing extensions check
>>
>>  xen/arch/arm/arm64/head.S   |  3 +--
>>  xen/arch/arm/gic-v3.c   |  2 +-
>>  xen/arch/arm/smpboot.c  | 13 +++--
>>  xen/include/asm-arm/processor.h |  9 +++--
>>  4 files changed, 16 insertions(+), 11 deletions(-)
>>
>> --
>> 2.7.4
>>

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

Re: [Xen-devel] [PATCH] arm/acpi: Fix the deadlock in function vgic_lock_rank()

2016-05-30 Thread Shannon Zhao 


On 2016/5/31 3:45, Julien Grall wrote:
> (CC Wei Liu)
> 
> Hi Stefano,
> 
> On 30/05/2016 14:16, Stefano Stabellini wrote:
>> On Fri, 27 May 2016, Julien Grall wrote:
>>> Hello Shanker,
>>>
>>> On 27/05/16 01:39, Shanker Donthineni wrote:
 Commit 9d77b3c01d1261c (Configure SPI interrupt type and route to
 Dom0 dynamically) causing dead loop inside the spinlock function.
 Note that spinlocks in XEN are not recursive. Re-acquiring a spinlock
 that has already held by calling CPU leads to deadlock. This happens
 whenever dom0 does writes to GICD regs ISENABLER/ICENABLER.
>>>
>>> Thank you for spotting it, I have not noticed it while I was 
>>> reviewing, only
>>> tested on a model without any SPIs.
>>>
 The following call trace explains the problem.

 DOM0 writes GICD_ISENABLER/GICD_ICENABLER
vgic_v3_distr_common_mmio_write()
  vgic_lock_rank()  -->  acquiring first time
vgic_enable_irqs()
  route_irq_to_guest()
gic_route_irq_to_guest()
  vgic_get_target_vcpu()
vgic_lock_rank()  -->  attemping acquired lock

 The simple fix release spinlock before calling vgic_enable_irqs()
 and vgic_disable_irqs().
>>>
>>> You should explain why you think it is valid to release the lock
>>> earlier.
>>>
>>> In this case, I think the fix is not correct because the lock is
>>> protecting
>>> both the register value and the internal state in Xen (modified by
>>> vgic_enable_irqs). By releasing the lock earlier, they may become
>>> inconsistent
>>> if another vCPU is disabling the IRQs at the same time.
>>
>> I agree, the vgic_enable_irqs call need to stay within the
>> vgic_lock_rank/vgic_unlock_rank region.
>>
>>
>>> I cannot find an easy fix which does not involve release the lock.
>>> When I was
>>> reviewing this patch, I suggested to split the IRQ configuration from
>>> the
>>> routing.
>>
>> Yes, the routing doesn't need to be done from vgic_enable_irqs. It is
>> not nice. That would be the ideal fix, but it is not trivial.
>>
>> For 4.7 we could consider reverting 9d77b3c01d1261c. The only other
>> thing that I can come up with which is simple would be improving
>> gic_route_irq_to_guest to cope with callers that have the vgic rank lock
>> already held (see below, untested) but it's pretty ugly.
> 
> We are close to release Xen 4.7, so I think we should avoid to touch the
> common interrupt code (i.e not only used by ACPI).
> 
> ACPI can only be enabled in expert mode and will be a tech-preview for
> Xen 4.7. So I would revert the patch.  SPIs will not be routed, but it
> is better than a deadlock.
> 
> I would also replace the patch with a warning until the issue will be
> fixed in Xen 4.8.
> 
> Any opinions?

I agree and I'm so sorry for this problem.

Thanks,
-- 
Shannon


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

[Xen-devel] [qemu-upstream-4.3-testing test] 94964: trouble: blocked/broken

2016-05-30 Thread osstest service owner 
flight 94964 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94964/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  114 days
Testing same since93977  2016-05-10 11:09:16 Z   20 days   85 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked

[Xen-devel] [xen-unstable test] 94959: tolerable FAIL - PUSHED

2016-05-30 Thread osstest service owner 
flight 94959 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94959/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 94943
 build-i386-rumpuserxen6 xen-buildfail   like 94943
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94943
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94943
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94943
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 94943
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94943

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  8b3d6858ecbe5f958f45ac5d8e5da6fa5a18266d
baseline version:
 xen  5ff371e9d87f468bf73acfafd65ba5a0d1b7bd4f

Last test of basis94943  2016-05-30 02:02:55 Z0 days
Testing same since94959  2016-05-30 14:42:17 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Julien Grall 
  Stefano Stabellini 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern

Re: [Xen-devel] [PATCH] xen/arm: setup: initialize xenheap mappings after boot pages avaiable

2016-05-30 Thread Julien Grall 

Hi Peng,

On 27/05/2016 06:31, Peng Fan wrote:

To ARM64, setup_xenheap_mappings may call alloc_boot_pages to allocate
first level page table, if there is a big chunk memory (ie, >512GB).


Out of interest, have you found the bug by testing Xen on a platform 
with 512GB of RAM? :)



So, need to make sure boot pages are ready before setup xenheap mappings.


init_boot_pages is using mfn_to_virt (see bootmem_region_add), which 
cannot work until xenheap_mfn_start is initialized. This is done by 
setup_xenheap_mappings.


I would be happy to give you hint on how to solve this, but I am not 
sure to fully understand your issue. Can you give more details?


Regards,



Signed-off-by: Peng Fan 
Cc: Julien Grall 
Cc: Stefano Stabellini 
---
 xen/arch/arm/setup.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index dcb23b7..24cf9d3 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -641,8 +641,6 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 ram_start = min(ram_start,bank_start);
 ram_end = max(ram_end,bank_end);

-setup_xenheap_mappings(bank_start>>PAGE_SHIFT, bank_size>>PAGE_SHIFT);
-
 s = bank_start;
 while ( s < bank_end )
 {
@@ -663,6 +661,8 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 dt_unreserved_regions(s, e, init_boot_pages, 0);
 s = n;
 }
+
+setup_xenheap_mappings(bank_start>>PAGE_SHIFT, bank_size>>PAGE_SHIFT);
 }

 total_pages += ram_size >> PAGE_SHIFT;



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers

2016-05-30 Thread Tamas K Lengyel 
On Mon, May 30, 2016 at 3:35 PM, Julien Grall  wrote:
>
>
> On 30/05/2016 21:37, Tamas K Lengyel wrote:
>>
>> On Mon, May 30, 2016 at 2:20 PM, Julien Grall 
>> wrote:
>>>
>>> Hi Tamas,
>>>
>>> On 30/05/2016 20:47, Tamas K Lengyel wrote:


 On Mon, May 30, 2016 at 5:50 AM, Jan Beulich  wrote:
>>
>>
>> +struct vm_event_regs_arm64 {
>> +uint64_t x0;
>> +uint64_t x1;
>> +uint64_t x2;
>> +uint64_t x3;
>> +uint64_t x4;
>> +uint64_t x5;
>> +uint64_t x6;
>> +uint64_t x7;
>> +uint64_t x8;
>> +uint64_t x9;
>> +uint64_t x10;
>> +uint64_t x16;
>> +uint64_t lr;
>> +uint64_t fp;
>> +uint64_t pc;
>> +uint64_t sp_el0;
>> +uint64_t sp_el1;
>> +uint32_t spsr_el1;
>> +uint32_t _pad;
>> +};
>
>
>
> My ARM knowledge is certainly quite limited, but the incomplete set
> of GPRs here is quite obvious: Is there a reason to not make all of
> them available here? And if there is, could the criteria of which
> registers got put here please be documented in a comment (so that
> the next person noticing the incomplete set won't ask again)?



 There already is a comment in place that explains why we are not
 sending the full set of registers here.
>>>
>>>
>>>
>>> Your comment only says:
>>> "Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM
>>> so as to not fill the vm_event ring buffer too quickly." it does not
>>> explain
>>> the criteria of which registers got put here.
>>
>>
>> Well, as we discussed it in the previous revision, there is no
>> hard-set rule of what can and cannot be transmitted here. The only
>> thing to keep in mind is to not grow this struct to be too large. The
>> registers sent right now represent a "best guess" of what may be
>> useful for performance-sensitive vm_event applications on ARM. It can
>> be adjusted in the future if applications require other registers.
>> Right now there are no applications at all in this space so we don't
>> have any specifications to rely on for making this selection. I'm
>> happy to make adjustments to the selection if others have a better
>> idea what to send, the only registers I certainly find very useful are
>> TTBR0/1, cpsr and pc at this time.
>
>
> Please log it in the commit message and the code. If someone emitted
> multiple time the same concern on previous version, it likely means that
> your commit message was not clear enough and should be updated.
>
> The number of patch to review on Xen-devel is very consequence, so we cannot
> really afford to spend a lot of time digging into previous threads. As a
> maintainer of a subsystem, you should be aware of that.
>
> We are trying, at least on ARM, to get as much details as possible in the
> commit message and document any possible unclear code to help developer
> understanding why it has been done like that. It also helps us (the
> reviewers and maintainers) to give useful advice later on.
>

Of course, thanks.

Tamas

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

Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers

2016-05-30 Thread Julien Grall 



On 30/05/2016 21:37, Tamas K Lengyel wrote:

On Mon, May 30, 2016 at 2:20 PM, Julien Grall  wrote:

Hi Tamas,

On 30/05/2016 20:47, Tamas K Lengyel wrote:


On Mon, May 30, 2016 at 5:50 AM, Jan Beulich  wrote:


+struct vm_event_regs_arm64 {
+uint64_t x0;
+uint64_t x1;
+uint64_t x2;
+uint64_t x3;
+uint64_t x4;
+uint64_t x5;
+uint64_t x6;
+uint64_t x7;
+uint64_t x8;
+uint64_t x9;
+uint64_t x10;
+uint64_t x16;
+uint64_t lr;
+uint64_t fp;
+uint64_t pc;
+uint64_t sp_el0;
+uint64_t sp_el1;
+uint32_t spsr_el1;
+uint32_t _pad;
+};



My ARM knowledge is certainly quite limited, but the incomplete set
of GPRs here is quite obvious: Is there a reason to not make all of
them available here? And if there is, could the criteria of which
registers got put here please be documented in a comment (so that
the next person noticing the incomplete set won't ask again)?



There already is a comment in place that explains why we are not
sending the full set of registers here.



Your comment only says:
"Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM
so as to not fill the vm_event ring buffer too quickly." it does not explain
the criteria of which registers got put here.


Well, as we discussed it in the previous revision, there is no
hard-set rule of what can and cannot be transmitted here. The only
thing to keep in mind is to not grow this struct to be too large. The
registers sent right now represent a "best guess" of what may be
useful for performance-sensitive vm_event applications on ARM. It can
be adjusted in the future if applications require other registers.
Right now there are no applications at all in this space so we don't
have any specifications to rely on for making this selection. I'm
happy to make adjustments to the selection if others have a better
idea what to send, the only registers I certainly find very useful are
TTBR0/1, cpsr and pc at this time.


Please log it in the commit message and the code. If someone emitted 
multiple time the same concern on previous version, it likely means that 
your commit message was not clear enough and should be updated.


The number of patch to review on Xen-devel is very consequence, so we 
cannot really afford to spend a lot of time digging into previous 
threads. As a maintainer of a subsystem, you should be aware of that.


We are trying, at least on ARM, to get as much details as possible in 
the commit message and document any possible unclear code to help 
developer understanding why it has been done like that. It also helps us 
(the reviewers and maintainers) to give useful advice later on.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 8/8] x86/vm_event: Add HVM debug exception vm_events

2016-05-30 Thread Andrew Cooper 

>>> @@ -3393,8 +3409,9 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>>  }
>>>  else {
>>>  int handled =
>>> -hvm_monitor_breakpoint(regs->eip,
>>> -   
>>> HVM_MONITOR_SOFTWARE_BREAKPOINT);
>>> +hvm_monitor_debug(regs->eip,
>>> +  HVM_MONITOR_SOFTWARE_BREAKPOINT,
>>> +  X86_EVENTTYPE_SW_EXCEPTION, 1);
>> Please let's not add further mistakes like this, assuming INT3 can't
>> have any prefixes. It can, even if they're useless.
> You mean the instruction length is not necessarily 1? Ultimately it
> doesn't seem to matter because reinjecting it with xc_hvm_inject_trap
> ignores this field. Instruction length is only required to be properly
> set AFAICT for a subset of debug exceptions during reinjection.

Almost all x86 instructions can have redundant prefixes which change
their length without altering their functionality.

This specific area was the subject of XSA-106, and is astoundingly fragile.

Luckily, I have an available functional test which confirms correct
behaviour from the point of view of the guest.

http://xenbits.xen.org/people/andrewcoop/xen-test-framework/test-swint-emulation.html

Please confirm that this test returns success even when being monitored
with this new functionality.

~Andrew

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

Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers

2016-05-30 Thread Tamas K Lengyel 
On Mon, May 30, 2016 at 2:46 PM, Razvan Cojocaru
 wrote:
> On 05/30/16 23:37, Tamas K Lengyel wrote:
>> Well, as we discussed it in the previous revision, there is no
>> hard-set rule of what can and cannot be transmitted here. The only
>> thing to keep in mind is to not grow this struct to be too large. The
>> registers sent right now represent a "best guess" of what may be
>> useful for performance-sensitive vm_event applications on ARM. It can
>> be adjusted in the future if applications require other registers.
>
> Obviously I agree with Tamas here, my only comment would be that in my
> humble opinion multipage vm_event ring buffers are probably the way to
> go in the long run. I'm not sure if other parts of Xen already employ
> such devices (or if indeed there's support for this at all at this
> time), but this might be something worth looking into.
>
> Again, this does not imply that there's anything wrong with this patch
> or that this is an issue this series should address.

Yeap, something ackin to libvchan would be very handy to have for
guest-hypervisor communication as well. I recall it popping up on the
mailinglist before, not sure if there was any consensus on it in the
end.

Tamas

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

Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers

2016-05-30 Thread Razvan Cojocaru 
On 05/30/16 23:37, Tamas K Lengyel wrote:
> Well, as we discussed it in the previous revision, there is no
> hard-set rule of what can and cannot be transmitted here. The only
> thing to keep in mind is to not grow this struct to be too large. The
> registers sent right now represent a "best guess" of what may be
> useful for performance-sensitive vm_event applications on ARM. It can
> be adjusted in the future if applications require other registers.

Obviously I agree with Tamas here, my only comment would be that in my
humble opinion multipage vm_event ring buffers are probably the way to
go in the long run. I'm not sure if other parts of Xen already employ
such devices (or if indeed there's support for this at all at this
time), but this might be something worth looking into.

Again, this does not imply that there's anything wrong with this patch
or that this is an issue this series should address.


Thanks,
Razvan

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

[Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

2016-05-30 Thread Olaf Hering 
With staging-4.6 this domU boots from xvda, qemu creates an emulated
disk. With staging no disk is found, unless the name is changed to hda.
Looks like qemu-2.6 does not handle xvda either.

Is such setup not part of OSS test, does OSS default to 'vdev=hda'?

Olaf

name="domU"
uuid="64dfa382-6365-46aa-88d8-0d9ca9a09ead"
memory=1024
serial="pty"
builder="hvm"
boot="cd"
#dtype="ahci"
disk=[
'format=qcow2, vdev=xvda, access=rw, target=/disk0.qcow2',
]
keymap="de"
vfb = [
'type=vnc,vncunused=1,keymap=de'
]
usb=1
usbdevice='tablet'


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

Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers

2016-05-30 Thread Tamas K Lengyel 
On Mon, May 30, 2016 at 2:20 PM, Julien Grall  wrote:
> Hi Tamas,
>
> On 30/05/2016 20:47, Tamas K Lengyel wrote:
>>
>> On Mon, May 30, 2016 at 5:50 AM, Jan Beulich  wrote:

 +struct vm_event_regs_arm64 {
 +uint64_t x0;
 +uint64_t x1;
 +uint64_t x2;
 +uint64_t x3;
 +uint64_t x4;
 +uint64_t x5;
 +uint64_t x6;
 +uint64_t x7;
 +uint64_t x8;
 +uint64_t x9;
 +uint64_t x10;
 +uint64_t x16;
 +uint64_t lr;
 +uint64_t fp;
 +uint64_t pc;
 +uint64_t sp_el0;
 +uint64_t sp_el1;
 +uint32_t spsr_el1;
 +uint32_t _pad;
 +};
>>>
>>>
>>> My ARM knowledge is certainly quite limited, but the incomplete set
>>> of GPRs here is quite obvious: Is there a reason to not make all of
>>> them available here? And if there is, could the criteria of which
>>> registers got put here please be documented in a comment (so that
>>> the next person noticing the incomplete set won't ask again)?
>>
>>
>> There already is a comment in place that explains why we are not
>> sending the full set of registers here.
>
>
> Your comment only says:
> "Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM
> so as to not fill the vm_event ring buffer too quickly." it does not explain
> the criteria of which registers got put here.

Well, as we discussed it in the previous revision, there is no
hard-set rule of what can and cannot be transmitted here. The only
thing to keep in mind is to not grow this struct to be too large. The
registers sent right now represent a "best guess" of what may be
useful for performance-sensitive vm_event applications on ARM. It can
be adjusted in the future if applications require other registers.
Right now there are no applications at all in this space so we don't
have any specifications to rely on for making this selection. I'm
happy to make adjustments to the selection if others have a better
idea what to send, the only registers I certainly find very useful are
TTBR0/1, cpsr and pc at this time.

>
> I already mentioned it on a previous version, and it seems to have been
> dropped from the commit message.
>
> Anyway, we should avoid to be stingy with comments. They are helpful for
> anyone interested by the vm_event subsystem and even you in few years if you
> decide to modify this code.

Certainly, I would be happy to put the above description into a comment here.

>
>>>
>>> I'm also puzzled by fp and lr - I'm not aware of registers of those
>>> names (and gas also doesn't accept them afaict).
>>
>>
>> Not sure why but Xen names x29 fp and x30 lr. See
>> include/asm-arm/arm64/processor.h.
>
>
> They are not officially called "lr" and "fp" in the ARM ARM. However the
> AAPCS64 [1] (5.1.1) defines x29 and x30 as special registers holding resp.
> "lr" and "fp".
>
> The convention is used internally in Xen for convenience. However, the
> public header uses x29 and x30 (see include/public/arch-arm.h).
>
> I would prefer if you use the official name in the public headers.

Sounds good to me.

Thanks,
Tamas

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

[Xen-devel] [qemu-upstream-4.3-testing test] 94961: trouble: blocked/broken

2016-05-30 Thread osstest service owner 
flight 94961 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94961/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  114 days
Testing same since93977  2016-05-10 11:09:16 Z   20 days   84 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked

[Xen-devel] Odgovor: Basic bare metal ARM domain interface

2016-05-30 Thread Ivan Pavić2 
Hello, 

>> I used FreeRTOS code for console output. It is based on Mini OS code. There 
>> are two problems as I've >determined
>> with debugging. First is that vsnprintf blocks for some reason in print 
>> function so i commented it out. After the

>snprintf blocks...

>> hypercall function blocked as well. I modified hypercall function so it 
>> looks like this:
>>(void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes");

>As the call failed I decided to make hypervisor call directly in boot 
>procedure, so I put this assembler code just >before
>branch to main:

>mov r12, #18 ; console io code
>mov r0, #0 ; write operation(first parameter)
>mov r1, #5 ; length of message (second parameter)
>   ldr r2, =msg ; message address (third parameter)
>.long 0xe140ea71 ; hvc instruction
>b main ; branch to main

>msg is defined as:

>msg:
>.asciz "hello"

>I get deadbeef in registers, apperently something happened (xenctx output):
>PC:   4000c5bc
>CPSR: 61f3
>USR:   SP: LR:
>SVC: SPSR: SP:4011c200 LR:400080a8
>FIQ: SPSR: SP:40124200 LR:
>IRQ: SPSR: SP:40120200 LR:
>ABT: SPSR: SP:40128200 LR:
>UND: SPSR: SP:4012c200 LR:

 >r0_usr: r1_usr: deadbeefr2_usr: deadbeef
 >r3_usr: r4_usr: r5_usr: 
 >r6_usr: r7_usr: r8_usr: 
 >r9_usr: 0064   r10_usr: 0064   r11_usr: 
>r12_usr: deadbeef


>According to arch-arm.h r0 is return value of call. It is 0, operation 
>successful Still I don't get output on
>console...

>Thank you in advance,

>Regards,

>Ivan Pavic

I still didn't solve why I don't see no output on emergency console, I think I 
should because if deadbeef in registers it 
do_console_io should have been called. However new problem emerged i tried to 
add iomem 
parameter in configuration file to get access over gpio but domain won't start 
because operation is not permitted. 
Should I somehow release disable that memory space for dom0, perhaps in dts for 
dom0? 

Snippet from dom.cfg file:

iomem = ["0x1340,1@0x4140"]

0x1340 is base address of GPIO that I want to use.

I get this error: (snippet from xl -vvv create -c dom.cfg)

libxl: debug: libxl_create.c:1213:domcreate_launch_dm: dom4 iomem 
1340-1340
libxl: error: libxl_create.c:1220:domcreate_launch_dm: failed give dom4 access 
to iomem range 1340-1340: Operation not permitted
libxl: debug: libxl.c:1719:devices_destroy_cb: forked pid 3835 for destroy of 
domain 4

Thank you in advance,

Ivan Pavic
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers

2016-05-30 Thread Julien Grall 

Hi Tamas,

On 30/05/2016 20:47, Tamas K Lengyel wrote:

On Mon, May 30, 2016 at 5:50 AM, Jan Beulich  wrote:

+struct vm_event_regs_arm64 {
+uint64_t x0;
+uint64_t x1;
+uint64_t x2;
+uint64_t x3;
+uint64_t x4;
+uint64_t x5;
+uint64_t x6;
+uint64_t x7;
+uint64_t x8;
+uint64_t x9;
+uint64_t x10;
+uint64_t x16;
+uint64_t lr;
+uint64_t fp;
+uint64_t pc;
+uint64_t sp_el0;
+uint64_t sp_el1;
+uint32_t spsr_el1;
+uint32_t _pad;
+};


My ARM knowledge is certainly quite limited, but the incomplete set
of GPRs here is quite obvious: Is there a reason to not make all of
them available here? And if there is, could the criteria of which
registers got put here please be documented in a comment (so that
the next person noticing the incomplete set won't ask again)?


There already is a comment in place that explains why we are not
sending the full set of registers here.


Your comment only says:
"Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM
so as to not fill the vm_event ring buffer too quickly." it does not 
explain the criteria of which registers got put here.


I already mentioned it on a previous version, and it seems to have been 
dropped from the commit message.


Anyway, we should avoid to be stingy with comments. They are helpful for 
anyone interested by the vm_event subsystem and even you in few years if 
you decide to modify this code.




I'm also puzzled by fp and lr - I'm not aware of registers of those
names (and gas also doesn't accept them afaict).


Not sure why but Xen names x29 fp and x30 lr. See
include/asm-arm/arm64/processor.h.


They are not officially called "lr" and "fp" in the ARM ARM. However the 
AAPCS64 [1] (5.1.1) defines x29 and x30 as special registers holding 
resp. "lr" and "fp".


The convention is used internally in Xen for convenience. However, the 
public header uses x29 and x30 (see include/public/arch-arm.h).


I would prefer if you use the official name in the public headers.

Regards,

[1] 
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 8/8] x86/vm_event: Add HVM debug exception vm_events

2016-05-30 Thread Tamas K Lengyel 
On Mon, May 30, 2016 at 8:16 AM, Jan Beulich  wrote:
 On 30.05.16 at 00:37,  wrote:
>> @@ -117,7 +133,11 @@ int hvm_monitor_breakpoint(unsigned long rip,
>>
>>  req.vcpu_id = curr->vcpu_id;
>>
>> -return vm_event_monitor_traps(curr, 1, );
>> +rc = vm_event_monitor_traps(curr, sync, );
>> +if ( type == HVM_MONITOR_DEBUG_EXCEPTION && rc == 1 && !sync )
>> +rc = 0;
>> +
>> +return rc;
>>  }
>
> To someone like me, not intimately familiar with the code, this added
> logic looks pretty arbitrary. Please add a comment indicating why
> under these special circumstances rc needs to be altered here, which
> then will hopefully also clarify why that can't be done right in
> vm_event_monitor_traps().

Yea, vm_event_monitor_traps is not the most straight forward function
in regards of what the return value means. I'll see if I can clean it
up a bit in another patch.

>
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -3377,9 +3377,25 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>  HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
>>  write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
>>  if ( !v->domain->debugger_attached )
>> -vmx_propagate_intr(intr_info);
>> +{
>> +unsigned long insn_length = 0;
>> +int handled;
>
> The variable name suggests it wants to be bool_t, but ...
>
>> +unsigned long trap_type = MASK_EXTR(intr_info,
>> +
>> INTR_INFO_INTR_TYPE_MASK);
>> +
>> +if( trap_type >= X86_EVENTTYPE_SW_INTERRUPT )
>> +__vmread(VM_EXIT_INSTRUCTION_LEN, _length);
>> +
>> +handled = hvm_monitor_debug(regs->eip,
>> +HVM_MONITOR_DEBUG_EXCEPTION,
>> +trap_type, insn_length);
>> +if ( handled <= 0 )
>
> ... it clearly can't. Please use a better name (could by just "rc" or
> "ret"). (Otoh I see that code you modify further down uses that
> same naming for a similar purpose variable. Let's see what the VMX
> maintainers say.)
>
>> +vmx_propagate_intr(intr_info);
>> +
>> +}
>>  else
>>  domain_pause_for_debugger();
>> +
>>  break;
>>  case TRAP_int3:
>
> If anywhere, this added blank line wants to go after the break.
>
>> @@ -3393,8 +3409,9 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>  }
>>  else {
>>  int handled =
>> -hvm_monitor_breakpoint(regs->eip,
>> -   HVM_MONITOR_SOFTWARE_BREAKPOINT);
>> +hvm_monitor_debug(regs->eip,
>> +  HVM_MONITOR_SOFTWARE_BREAKPOINT,
>> +  X86_EVENTTYPE_SW_EXCEPTION, 1);
>
> Please let's not add further mistakes like this, assuming INT3 can't
> have any prefixes. It can, even if they're useless.

You mean the instruction length is not necessarily 1? Ultimately it
doesn't seem to matter because reinjecting it with xc_hvm_inject_trap
ignores this field. Instruction length is only required to be properly
set AFAICT for a subset of debug exceptions during reinjection.

>
>> @@ -3721,8 +3738,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>  vmx_update_cpu_exec_control(v);
>>  if ( v->arch.hvm_vcpu.single_step )
>>  {
>> -hvm_monitor_breakpoint(regs->eip,
>> -   HVM_MONITOR_SINGLESTEP_BREAKPOINT);
>> +hvm_monitor_debug(regs->eip, HVM_MONITOR_SINGLESTEP_BREAKPOINT, 
>> 0, 0);
>
> How come the 3rd argument is literal zero here?

Instruction length is only meaningful for a subset of debug exceptions
that could be reinjected to the guest using xc_hvm_inject_trap.
Monitor trap flag events are external to the guest so there is nothing
to inject. The instruction length field won't even exist for this type
of singlestep events (we distinguish vm_event_singlestep and
vm_event_debug structs for this reason), so 0 here is arbitrary. We
could set it to ~0 to make it more obvious that it's just a
placeholder in this context.

> Also you're creating a long line here.

Ack.

Thanks,
Tamas

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

Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers

2016-05-30 Thread Tamas K Lengyel 
On Mon, May 30, 2016 at 5:50 AM, Jan Beulich  wrote:
 On 30.05.16 at 00:37,  wrote:
>> +struct vm_event_regs_arm32 {
>> +uint32_t r0_usr;
>> +uint32_t r1_usr;
>> +uint32_t r2_usr;
>> +uint32_t r3_usr;
>> +uint32_t r4_usr;
>> +uint32_t r5_usr;
>> +uint32_t r6_usr;
>> +uint32_t r7_usr;
>> +uint32_t r8_usr;
>> +uint32_t r9_usr;
>> +uint32_t r10_usr;
>> +uint32_t r12_usr;
>> +uint32_t lr_usr;
>> +uint32_t fp;
>> +uint32_t pc;
>> +uint32_t sp_usr;
>> +uint32_t sp_svc;
>> +uint32_t spsr_svc;
>> +};
>
> It would seem more natural for the "ordinary" registers to be
> arranged in the numerical sequence, i.e. fp, r12, sp, lr, pc.

Not sure I follow.

>
>> +struct vm_event_regs_arm64 {
>> +uint64_t x0;
>> +uint64_t x1;
>> +uint64_t x2;
>> +uint64_t x3;
>> +uint64_t x4;
>> +uint64_t x5;
>> +uint64_t x6;
>> +uint64_t x7;
>> +uint64_t x8;
>> +uint64_t x9;
>> +uint64_t x10;
>> +uint64_t x16;
>> +uint64_t lr;
>> +uint64_t fp;
>> +uint64_t pc;
>> +uint64_t sp_el0;
>> +uint64_t sp_el1;
>> +uint32_t spsr_el1;
>> +uint32_t _pad;
>> +};
>
> My ARM knowledge is certainly quite limited, but the incomplete set
> of GPRs here is quite obvious: Is there a reason to not make all of
> them available here? And if there is, could the criteria of which
> registers got put here please be documented in a comment (so that
> the next person noticing the incomplete set won't ask again)?

There already is a comment in place that explains why we are not
sending the full set of registers here.

>
> I'm also puzzled by fp and lr - I'm not aware of registers of those
> names (and gas also doesn't accept them afaict).

Not sure why but Xen names x29 fp and x30 lr. See
include/asm-arm/arm64/processor.h.

>
>> +struct vm_event_regs_arm {
>> +uint32_t cpsr; /* PSR_MODE_BIT is set iff arm32 is used below */
>
> Explicit padding missing after this one.

Ack.

Thanks,
Tamas

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

Re: [Xen-devel] [PATCH] arm/acpi: Fix the deadlock in function vgic_lock_rank()

2016-05-30 Thread Julien Grall 

(CC Wei Liu)

Hi Stefano,

On 30/05/2016 14:16, Stefano Stabellini wrote:

On Fri, 27 May 2016, Julien Grall wrote:

Hello Shanker,

On 27/05/16 01:39, Shanker Donthineni wrote:

Commit 9d77b3c01d1261c (Configure SPI interrupt type and route to
Dom0 dynamically) causing dead loop inside the spinlock function.
Note that spinlocks in XEN are not recursive. Re-acquiring a spinlock
that has already held by calling CPU leads to deadlock. This happens
whenever dom0 does writes to GICD regs ISENABLER/ICENABLER.


Thank you for spotting it, I have not noticed it while I was  reviewing, only
tested on a model without any SPIs.


The following call trace explains the problem.

DOM0 writes GICD_ISENABLER/GICD_ICENABLER
   vgic_v3_distr_common_mmio_write()
 vgic_lock_rank()  -->  acquiring first time
   vgic_enable_irqs()
 route_irq_to_guest()
   gic_route_irq_to_guest()
 vgic_get_target_vcpu()
   vgic_lock_rank()  -->  attemping acquired lock

The simple fix release spinlock before calling vgic_enable_irqs()
and vgic_disable_irqs().


You should explain why you think it is valid to release the lock earlier.

In this case, I think the fix is not correct because the lock is protecting
both the register value and the internal state in Xen (modified by
vgic_enable_irqs). By releasing the lock earlier, they may become inconsistent
if another vCPU is disabling the IRQs at the same time.


I agree, the vgic_enable_irqs call need to stay within the
vgic_lock_rank/vgic_unlock_rank region.



I cannot find an easy fix which does not involve release the lock. When I was
reviewing this patch, I suggested to split the IRQ configuration from the
routing.


Yes, the routing doesn't need to be done from vgic_enable_irqs. It is
not nice. That would be the ideal fix, but it is not trivial.

For 4.7 we could consider reverting 9d77b3c01d1261c. The only other
thing that I can come up with which is simple would be improving
gic_route_irq_to_guest to cope with callers that have the vgic rank lock
already held (see below, untested) but it's pretty ugly.


We are close to release Xen 4.7, so I think we should avoid to touch the 
common interrupt code (i.e not only used by ACPI).


ACPI can only be enabled in expert mode and will be a tech-preview for 
Xen 4.7. So I would revert the patch.  SPIs will not be routed, but it 
is better than a deadlock.


I would also replace the patch with a warning until the issue will be 
fixed in Xen 4.8.


Any opinions?


+int gic_route_irq_to_guest(struct domain *d, unsigned int virq,
+   struct irq_desc *desc, unsigned int priority)
+{
+unsigned long flags;
+int lock = 0, retval;
+struct vgic_irq_rank *rank;
+
+/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
+ * route SPIs to guests, it doesn't make any difference. */
+rank = vgic_rank_irq(d->vcpu[0], virq);
+
+/* Take the rank spinlock unless it has already been taken by the
+ * caller. */
+if ( !spin_is_locked(>lock) ) {


AFAICT, spin_is_locked only tell us that someone has locked the rank. So 
this would be unsafe.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V9] vm_event: Allow subscribing to write events for specific MSR-s

2016-05-30 Thread Tamas K Lengyel 
On Mon, May 30, 2016 at 4:13 AM, Jan Beulich  wrote:
 On 30.05.16 at 09:13,  wrote:
>> On 05/13/2016 02:35 PM, Jan Beulich wrote:
>> On 06.05.16 at 16:33,  wrote:
 Previously, subscribing to MSR write events was an all-or-none
 approach, with special cases for introspection MSR-s. This patch
 allows the vm_event consumer to specify exactly what MSR-s it is
 interested in, and as a side-effect gets rid of the
 vmx_introspection_force_enabled_msrs[] special case.
 The patch also introduces arch_monitor_init_domain() and
 arch_monitor_cleanup_domain(), to do monitor-specific work
 (as opposed to the previous way of doing all the setup in
 vm_event_init_domain() / vm_event_cleanup_domain()).
 This replaces the previously posted "xen: Filter out MSR write
 events" patch.

 Signed-off-by: Razvan Cojocaru 
 Acked-by: Wei Liu 
 Acked-by: Kevin Tian 
>>>
>>> Acked-by: Jan Beulich 
>>
>> Does this patch require additional acks? Tamas' maybe?
>
> Yes, quite clearly (looking at the diffstat).

Hm, I thought I already acked it.

Acked-by: Tamas K Lengyel 

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

[Xen-devel] [ovmf test] 94958: regressions - FAIL

2016-05-30 Thread osstest service owner 
flight 94958 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94958/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 3ab7066e8d8ae43d9cdee76600b90918f8bee5d9
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z5 days
Failing since 94750  2016-05-25 03:43:08 Z5 days   17 attempts
Testing same since94958  2016-05-30 13:43:03 Z0 days1 attempts


People who touched revisions under test:
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  Eugene Cohen 
  Gary Lin 
  Hao Wu 
  Jeff Fan 
  Jiaxin Wu 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Star Zeng 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 683 lines long.)

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

[Xen-devel] [qemu-upstream-4.3-testing test] 94957: trouble: blocked/broken

2016-05-30 Thread osstest service owner 
flight 94957 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94957/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  114 days
Testing same since93977  2016-05-10 11:09:16 Z   20 days   83 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked

Re: [Xen-devel] [RFC 10/16] xen/arm: Introduce alternative runtime patching

2016-05-30 Thread Julien Grall 

Hi Stefano,

On 30/05/2016 15:45, Stefano Stabellini wrote:

On Mon, 23 May 2016, Julien Grall wrote:

Hi Stefano,

On 21/05/16 16:09, Stefano Stabellini wrote:

On Thu, 5 May 2016, Julien Grall wrote:

+void __init apply_alternatives_all(void)
+{
+int ret;
+
+   /* better not try code patching on a live SMP system */
+ret = stop_machine_run(__apply_alternatives_multi_stop, NULL,
NR_CPUS);


Why not just call stop_machine_run, passing 0 as the cpu to run
__apply_alternatives_multi_stop on? Given that you already have
secondary cpus spinning in __apply_alternatives_multi_stop.  What am I
missing?


Someone as to call __apply_alternatives_multi_stop on secondary CPUs.


Why? Secondary cpus would be just left spinning at the beginning of the
function. You might as well leave them spinning in
stopmachine_wait_state.



Because, we may need to patch the stop_machine state machine 
(spinlock,...). So the safest place whilst the code is patched is 
__apply_alternatives_multi_stop.


Note that there is a comment on top of __apply_alternatives_multi_stop 
to explain the reason.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 10/15] xen/arm: Detect silicon revision and set cap bits accordingly

2016-05-30 Thread Julien Grall 

Hi Stefano,

On 30/05/2016 16:02, Stefano Stabellini wrote:

On Mon, 23 May 2016, Julien Grall wrote:

After each CPU has been started, we iterate through a list of CPU
errata to detect CPUs which need from hypervisor code patches.

For each bug there is a function which check if that a particular CPU is
affected. This needs to be done on every CPUs to cover heterogenous
system properly.

If a certain erratum has been detected, the capability bit will be set
and later the call to apply_alternatives() will trigger the actual code
patching.

The code is based on the file arch/arm64/kernel/cpu_errata.c in Linux
v4.6-rc3.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Use XENLOG_INFO for the loglevel of the message
---
 xen/arch/arm/Makefile|  1 +
 xen/arch/arm/cpuerrata.c | 26 ++
 xen/arch/arm/cpufeature.c| 16 
 xen/arch/arm/setup.c |  3 +++
 xen/arch/arm/smpboot.c   |  3 +++
 xen/include/asm-arm/cpuerrata.h  |  6 ++
 xen/include/asm-arm/cpufeature.h | 15 +++
 7 files changed, 70 insertions(+)
 create mode 100644 xen/arch/arm/cpuerrata.c
 create mode 100644 xen/include/asm-arm/cpuerrata.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 2d330aa..307578c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -7,6 +7,7 @@ subdir-$(CONFIG_ACPI) += acpi
 obj-$(CONFIG_ALTERNATIVE) += alternative.o
 obj-y += bootfdt.o
 obj-y += cpu.o
+obj-y += cpuerrata.o
 obj-y += cpufeature.o
 obj-y += decode.o
 obj-y += device.o
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
new file mode 100644
index 000..52d39f8
--- /dev/null
+++ b/xen/arch/arm/cpuerrata.c
@@ -0,0 +1,26 @@
+#include 
+#include 
+#include 
+
+#define MIDR_RANGE(model, min, max) \
+.matches = is_affected_midr_range,  \
+.midr_model = model,\
+.midr_range_min = min,  \
+.midr_range_max = max
+
+static bool_t __maybe_unused


I would remove __maybe_unused given that you are going to use this
function in later patches.


The user can decide to disable all the errata, so this function will be 
unused.


Also, if I drop the __may_unused now, the compilation will fail because 
nobody is use it so far.



+is_affected_midr_range(const struct arm_cpu_capabilities *entry)
+{
+return MIDR_IS_CPU_MODEL_RANGE(boot_cpu_data.midr.bits, entry->midr_model,
+   entry->midr_range_min,
+   entry->midr_range_max);
+}
+
+static const struct arm_cpu_capabilities arm_errata[] = {
+{},
+};
+
+void check_local_cpu_errata(void)
+{
+update_cpu_capabilities(arm_errata, "enabled workaround for");
+}


update_cpu_capabilities should actually be called on arm64 only, right?
Given that runtime patching is unimplemented on arm32. I wouldn't want
to rely on the fact that we don't have any arm32 workarounds at the
moment.


Whilst runtime patching is making use of the cpu features, not all the 
features (or erratum) may require runtime patching.


So I deliberately keep this code enabled on ARM32.


diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 7a1b56b..088625b 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -24,6 +24,22 @@

 DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);

+void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
+ const char *info)


The info parameter is unnecessary.


It is used in the printk below:

printk(XENLOG_INFO "%s: %s\n", info, caps[i].desc);

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 15/15] xen/arm: arm64: Document Cortex-A57 erratum 834220

2016-05-30 Thread Julien Grall 



On 30/05/2016 17:19, Stefano Stabellini wrote:

"Erratum #834220: Xen needs to check that the Stage 1 translation does not
generate a fault before handling Stage 2 fault. If it is a stage 1 translation
fault, return to the guest to let the project injecting the correct fault.

XXX: This can be optimized to avoid some unnecessary translation."


What about adding a lengthy and detailed description of the erratum
elsewhere and just having a one liner at the call sites, such as:


I don't see any problem to have "lengthy" comment twice. It could 
actually be 3 lines because the last one is a TODO.


I thought about merging some bits of do_trap_instr_abort_guest and 
do_trap_data_abort_guest, but at first glance it is not that simple.



/* Erratum #834220: check Stage1 translation does not generate faults first! */

so that developers can easily grep for #834220 through the code to have
the full explanation?


Where would you put the full explanation? do_trap_hypervisor does not 
make sense because it does not deal with the erratum. When we will come 
back in few months time, we will wonder why the comment is there.


Regards,

--
Julien Grall

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

[Xen-devel] [PATCH for-4.7 0/2] assembly test fixes

2016-05-30 Thread Roger Pau Monne 
Hello,

The following series attempts to fix the build issue introduced by 
7fb252bd41, and to make sure the same assembler is used thorough all the 
build process. It also supersedes the fix by Jan Beulich for this same issue 
[0].

Roger.

[0] http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02822.html


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

[Xen-devel] [PATCH for-4.7 1/2] build/clang: disable the usage of the integrated clang assembler

2016-05-30 Thread Roger Pau Monne 
For all the build process, not only the assembly-only files.

This prevents assembling certain code with the integrated assembler, while
other code would be assembled by the external assembler.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Rules.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 961d533..12efd6a 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -71,7 +71,7 @@ endif
 AFLAGS-y+= -D__ASSEMBLY__ -include 
$(BASEDIR)/include/xen/config.h
 
 # Clang's built-in assembler can't handle .code16/.code32/.code64 yet
-AFLAGS-$(clang) += -no-integrated-as
+CFLAGS-$(clang) += -no-integrated-as
 
 ALL_OBJS := $(ALL_OBJS-y)
 
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH for-4.7 2/2] build: use CFLAGS instead of AFLAGS for as-insn checks

2016-05-30 Thread Roger Pau Monne 
The test code is a C file with inline assembly, not plain assembly.

This fixes the fallout introduced by commit 7fb252bd41 ("build/xen: fix
assembler instruction tests")

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index 5ddfbf8..13475e0 100644
--- a/Config.mk
+++ b/Config.mk
@@ -150,7 +150,7 @@ endif
 # as-insn: Check whether assembler supports an instruction.
 # Usage: cflags-y += $(call as-insn "insn",option-yes,option-no)
 as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
-   | $(1) $(AFLAGS) -c -x c -o /dev/null - 2>&1),$(4),$(3))
+   | $(1) $(CFLAGS) -c -x c -o /dev/null - 2>&1),$(4),$(3))
 
 # as-insn-check: Add an option to compilation flags, but only if insn is
 #supported by assembler.
-- 
2.7.4 (Apple Git-66)


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

Re: [Xen-devel] [PATCH v2 15/15] xen/arm: arm64: Document Cortex-A57 erratum 834220

2016-05-30 Thread Stefano Stabellini 
On Mon, 30 May 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 30/05/2016 16:11, Stefano Stabellini wrote:
> > On Mon, 23 May 2016, Julien Grall wrote:
> > > The ARM erratum applies to certain revisions of Cortex-A57. The
> > > processor may report a Stage 2 translation fault as the result of
> > > Stage 1 fault for load crossing a page boundary when there is a
> > > permission fault or device memory fault at stage 1 and a translation
> > > fault at Stage 2.
> > > 
> > > So Xen needs to check that Stage 1 translation does not generate a fault
> > > before handling the Stage 2 fault. If it is a Stage 1 translation fault,
> > > return to the guest to let the processor injecting the correct fault.
> > > 
> > > Only document it as this is already the behavior of the fault handlers.
> > > Note that some optimization could be done to avoid unecessary translation
> > > fault. This is because HPFAR_EL2 is valid for more use case. For the
> > > moment,
> > > the code is left unmodified.
> > > 
> > > Signed-off-by: Julien Grall 
> > > ---
> > >  docs/misc/arm/silicon-errata.txt |  1 +
> > >  xen/arch/arm/traps.c | 30 ++
> > >  2 files changed, 31 insertions(+)
> > > 
> > > diff --git a/docs/misc/arm/silicon-errata.txt
> > > b/docs/misc/arm/silicon-errata.txt
> > > index ab2e5bc..1ac365d 100644
> > > --- a/docs/misc/arm/silicon-errata.txt
> > > +++ b/docs/misc/arm/silicon-errata.txt
> > > @@ -47,3 +47,4 @@ stable hypervisors.
> > >  | ARM| Cortex-A53  | #819472 |
> > > ARM64_ERRATUM_819472|
> > >  | ARM| Cortex-A57  | #852523 | N/A
> > > |
> > >  | ARM| Cortex-A57  | #832075 |
> > > ARM64_ERRATUM_832075|
> > > +| ARM| Cortex-A57  | #834220 | N/A
> > > |
> > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > index 3acdba0..bbd5309 100644
> > > --- a/xen/arch/arm/traps.c
> > > +++ b/xen/arch/arm/traps.c
> > > @@ -2396,6 +2396,21 @@ static void do_trap_instr_abort_guest(struct
> > > cpu_user_regs *regs,
> > >  .kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt :
> > > npfec_kind_with_gla
> > >  };
> > > 
> > > +/*
> > > + * Erratum #834220: The processor may report a Stage 2
> > > + * translation fault as the result of Stage 1 fault for load
> > > + * crossing a page boundary when there is a permission fault or
> > > + * device memory alignment fault at Stage 1 and a translation
> > > + * fault at Stage 2.
> > > + *
> > > + * So Xen needs to check that the Stage 1 translation does not
> > > + * generate a fault before handling stage 2 fault. If it is a
> > > Stage
> > > + * 1 translation fault, return to the guest to let the processor
> > > + * injecting the correct fault.
> > > + *
> > > + * XXX: This can be optimized to avoid some unecessary
> > > + * translation.
> > > + */
> > >  if ( hsr.iabt.s1ptw )
> > >  gpa = get_faulting_ipa();
> > >  else
> > 
> > Please write the comment only once, maybe in do_trap_hypervisor before
> > the calls to do_trap_instr_abort_guest and do_trap_data_abort_guest.
> 
> I wrote this comment at these two specific places because developers and
> reviewers can spot directly that the code has been written in a specific way
> to avoid an erratum.
> 
> If we happen to fix one place and not the other, the comment would still be
> there. do_trap_hypervisor would be the wrong place for this comment because it
> is "far away" in the code and will be less likely read.
> 
> I can shrink down the message. What about:
> 
> "Erratum #834220: Xen needs to check that the Stage 1 translation does not
> generate a fault before handling Stage 2 fault. If it is a stage 1 translation
> fault, return to the guest to let the project injecting the correct fault.
> 
> XXX: This can be optimized to avoid some unnecessary translation."

What about adding a lengthy and detailed description of the erratum
elsewhere and just having a one liner at the call sites, such as:

/* Erratum #834220: check Stage1 translation does not generate faults first! */

so that developers can easily grep for #834220 through the code to have
the full explanation?

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

Re: [Xen-devel] [PATCH v2 15/15] xen/arm: arm64: Document Cortex-A57 erratum 834220

2016-05-30 Thread Julien Grall 

Hi Stefano,

On 30/05/2016 16:11, Stefano Stabellini wrote:

On Mon, 23 May 2016, Julien Grall wrote:

The ARM erratum applies to certain revisions of Cortex-A57. The
processor may report a Stage 2 translation fault as the result of
Stage 1 fault for load crossing a page boundary when there is a
permission fault or device memory fault at stage 1 and a translation
fault at Stage 2.

So Xen needs to check that Stage 1 translation does not generate a fault
before handling the Stage 2 fault. If it is a Stage 1 translation fault,
return to the guest to let the processor injecting the correct fault.

Only document it as this is already the behavior of the fault handlers.
Note that some optimization could be done to avoid unecessary translation
fault. This is because HPFAR_EL2 is valid for more use case. For the moment,
the code is left unmodified.

Signed-off-by: Julien Grall 
---
 docs/misc/arm/silicon-errata.txt |  1 +
 xen/arch/arm/traps.c | 30 ++
 2 files changed, 31 insertions(+)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index ab2e5bc..1ac365d 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -47,3 +47,4 @@ stable hypervisors.
 | ARM| Cortex-A53  | #819472 | ARM64_ERRATUM_819472
|
 | ARM| Cortex-A57  | #852523 | N/A 
|
 | ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075
|
+| ARM| Cortex-A57  | #834220 | N/A 
|
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 3acdba0..bbd5309 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2396,6 +2396,21 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 .kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
 };

+/*
+ * Erratum #834220: The processor may report a Stage 2
+ * translation fault as the result of Stage 1 fault for load
+ * crossing a page boundary when there is a permission fault or
+ * device memory alignment fault at Stage 1 and a translation
+ * fault at Stage 2.
+ *
+ * So Xen needs to check that the Stage 1 translation does not
+ * generate a fault before handling stage 2 fault. If it is a Stage
+ * 1 translation fault, return to the guest to let the processor
+ * injecting the correct fault.
+ *
+ * XXX: This can be optimized to avoid some unecessary
+ * translation.
+ */
 if ( hsr.iabt.s1ptw )
 gpa = get_faulting_ipa();
 else


Please write the comment only once, maybe in do_trap_hypervisor before
the calls to do_trap_instr_abort_guest and do_trap_data_abort_guest.


I wrote this comment at these two specific places because developers and 
reviewers can spot directly that the code has been written in a specific 
way to avoid an erratum.


If we happen to fix one place and not the other, the comment would still 
be there. do_trap_hypervisor would be the wrong place for this comment 
because it is "far away" in the code and will be less likely read.


I can shrink down the message. What about:

"Erratum #834220: Xen needs to check that the Stage 1 translation does 
not generate a fault before handling Stage 2 fault. If it is a stage 1 
translation fault, return to the guest to let the project injecting the 
correct fault.


XXX: This can be optimized to avoid some unnecessary translation."

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen: Clean up includes

2016-05-30 Thread Stefano Stabellini 
On Tue, 24 May 2016, Peter Maydell wrote:
> Clean up includes so that osdep.h is included first and headers
> which it implies are not included manually.
> 
> This commit was created with scripts/clean-includes.
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Stefano Stabellini 

Added to my queue


>  hw/usb/xen-usb.c | 5 +
>  include/hw/xen/xen.h | 1 -
>  2 files changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
> index 664df04..8fa47ed 100644
> --- a/hw/usb/xen-usb.c
> +++ b/hw/usb/xen-usb.c
> @@ -19,13 +19,10 @@
>   *  GNU GPL, version 2 or (at your option) any later version.
>   */
>  
> +#include "qemu/osdep.h"
>  #include 
> -#include 
> -#include 
>  #include 
> -#include 
>  
> -#include "qemu/osdep.h"
>  #include "qemu-common.h"
>  #include "qemu/config-file.h"
>  #include "hw/sysbus.h"
> diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
> index 6365483..b2cd992 100644
> --- a/include/hw/xen/xen.h
> +++ b/include/hw/xen/xen.h
> @@ -8,7 +8,6 @@
>   */
>  
>  #include "qemu-common.h"
> -#include "qemu/typedefs.h"
>  #include "exec/cpu-common.h"
>  #include "hw/irq.h"
>  
> -- 
> 1.9.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [PATCH v2 15/15] xen/arm: arm64: Document Cortex-A57 erratum 834220

2016-05-30 Thread Stefano Stabellini 
On Mon, 23 May 2016, Julien Grall wrote:
> The ARM erratum applies to certain revisions of Cortex-A57. The
> processor may report a Stage 2 translation fault as the result of
> Stage 1 fault for load crossing a page boundary when there is a
> permission fault or device memory fault at stage 1 and a translation
> fault at Stage 2.
> 
> So Xen needs to check that Stage 1 translation does not generate a fault
> before handling the Stage 2 fault. If it is a Stage 1 translation fault,
> return to the guest to let the processor injecting the correct fault.
> 
> Only document it as this is already the behavior of the fault handlers.
> Note that some optimization could be done to avoid unecessary translation
> fault. This is because HPFAR_EL2 is valid for more use case. For the moment,
> the code is left unmodified.
> 
> Signed-off-by: Julien Grall 
> ---
>  docs/misc/arm/silicon-errata.txt |  1 +
>  xen/arch/arm/traps.c | 30 ++
>  2 files changed, 31 insertions(+)
> 
> diff --git a/docs/misc/arm/silicon-errata.txt 
> b/docs/misc/arm/silicon-errata.txt
> index ab2e5bc..1ac365d 100644
> --- a/docs/misc/arm/silicon-errata.txt
> +++ b/docs/misc/arm/silicon-errata.txt
> @@ -47,3 +47,4 @@ stable hypervisors.
>  | ARM| Cortex-A53  | #819472 | ARM64_ERRATUM_819472  
>   |
>  | ARM| Cortex-A57  | #852523 | N/A   
>   |
>  | ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075  
>   |
> +| ARM| Cortex-A57  | #834220 | N/A   
>   |
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 3acdba0..bbd5309 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2396,6 +2396,21 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  .kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
>  };
>  
> +/*
> + * Erratum #834220: The processor may report a Stage 2
> + * translation fault as the result of Stage 1 fault for load
> + * crossing a page boundary when there is a permission fault or
> + * device memory alignment fault at Stage 1 and a translation
> + * fault at Stage 2.
> + *
> + * So Xen needs to check that the Stage 1 translation does not
> + * generate a fault before handling stage 2 fault. If it is a Stage
> + * 1 translation fault, return to the guest to let the processor
> + * injecting the correct fault.
> + *
> + * XXX: This can be optimized to avoid some unecessary
> + * translation.
> + */
>  if ( hsr.iabt.s1ptw )
>  gpa = get_faulting_ipa();
>  else

Please write the comment only once, maybe in do_trap_hypervisor before
the calls to do_trap_instr_abort_guest and do_trap_data_abort_guest.


> @@ -2445,6 +2460,21 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  info.gva = READ_SYSREG64(FAR_EL2);
>  #endif
>  
> +/*
> + * Erratum #834220: The processor may report a Stage 2
> + * translation fault as the result of Stage 1 fault for load
> + * crossing a page boundary when there is a permission fault or
> + * device memory alignment fault at Stage 1 and a translation
> + * fault at Stage 2.
> + *
> + * So Xen needs to check that the Stage 1 translation does not
> + * generate a fault before handling stage 2 fault. If it is a Stage
> + * 1 translation fault, return to the guest to let the processor
> + * injecting the correct fault.
> + *
> + * XXX: This can be optimized to avoid some unecessary
> + * translation.
> + */
>  if ( dabt.s1ptw )
>  info.gpa = get_faulting_ipa();
>  else
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH v2 11/15] xen/arm: Document the errata implemented in Xen

2016-05-30 Thread Stefano Stabellini 
On Mon, 23 May 2016, Julien Grall wrote:
> The new document will help to keep track of all the erratum that Xen is
> able to handle.
> 
> The text is based on the Linux doc in Documents/arm64/silicon-errata.txt.
> 
> Also list the current errata that Xen is aware of.
> 
> Signed-off-by: Julien Grall 
> ---
>  docs/misc/arm/silicon-errata.txt | 45 
> 
>  1 file changed, 45 insertions(+)
>  create mode 100644 docs/misc/arm/silicon-errata.txt
> 
> diff --git a/docs/misc/arm/silicon-errata.txt 
> b/docs/misc/arm/silicon-errata.txt
> new file mode 100644
> index 000..3f0d32b
> --- /dev/null
> +++ b/docs/misc/arm/silicon-errata.txt
> @@ -0,0 +1,45 @@
> +Silicon Errata and Software Workarounds
> +===
> +
> +It is an unfortunate fact of life that hardware is often produced with
> +so-called "errata", which can cause it to deviate from the architecture
> +under specific circumstances.  For hardware produced by ARM, these
> +errata are broadly classified into the following categories:
> +
> +  Category A: A critical error without a viable workaround.
> +  Category B: A significant or critical error with an acceptable
> +  workaround.
> +  Category C: A minor error that is not expected to occur under normal
> +  operation.
> +
> +For more information, consult one of the "Software Developers Errata
> +Notice" documents available on infocenter.arm.com (registration
> +required).
> +
> +As far as Xen is concerned, Category B errata may require some special
> +treatment in the hypervisor. For example, avoiding a particular sequence
> +of code, or configuring the processor in a particular way. A less common
> +situation may require similar actions in order to declassify a Category A
> +erratum into a Category C erratum. These are collectively known as
> +"software workarounds" and are only required in the minority of cases
> +(e.g. those cases that both require a non-secure workaround *and* can
> +be triggered by Linux).
   ^by Xen


> +For software workarounds that may adversely impact systems unaffected by
> +the erratum in question, a Kconfig entry is added under "ARM errata
> +workarounds via the alternatives framework". These are enabled by default
> +and patched in at runtime when an affected CPU is detected. For
> +less-intrusive workarounds, a Kconfig option is not available and the code
> +is structured (preferably with a comment) in such a way that the erratum
> +will not be hit.
> +
> +This approach can make it slightly onerous to determine exactly which
> +errata are worked around in an arbitrary hypervisor source tree, so this
> +file acts as a registry of software workarounds in the Xen hypervisor and
> +will be updated when new workarounds are committed and backported to
> +stable hypervisors.
> +
> +| Implementor| Component   | Erratum ID  | Kconfig   
>   |
> +++-+-+-+
> +| ARM| Cortex-A15  | #766422 | N/A   
>   |
> +| ARM| Cortex-A57  | #852523 | N/A   
>   |
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH v2 10/15] xen/arm: Detect silicon revision and set cap bits accordingly

2016-05-30 Thread Stefano Stabellini 
On Mon, 23 May 2016, Julien Grall wrote:
> After each CPU has been started, we iterate through a list of CPU
> errata to detect CPUs which need from hypervisor code patches.
> 
> For each bug there is a function which check if that a particular CPU is
> affected. This needs to be done on every CPUs to cover heterogenous
> system properly.
> 
> If a certain erratum has been detected, the capability bit will be set
> and later the call to apply_alternatives() will trigger the actual code
> patching.
> 
> The code is based on the file arch/arm64/kernel/cpu_errata.c in Linux
> v4.6-rc3.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> Changes in v2:
> - Use XENLOG_INFO for the loglevel of the message
> ---
>  xen/arch/arm/Makefile|  1 +
>  xen/arch/arm/cpuerrata.c | 26 ++
>  xen/arch/arm/cpufeature.c| 16 
>  xen/arch/arm/setup.c |  3 +++
>  xen/arch/arm/smpboot.c   |  3 +++
>  xen/include/asm-arm/cpuerrata.h  |  6 ++
>  xen/include/asm-arm/cpufeature.h | 15 +++
>  7 files changed, 70 insertions(+)
>  create mode 100644 xen/arch/arm/cpuerrata.c
>  create mode 100644 xen/include/asm-arm/cpuerrata.h
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 2d330aa..307578c 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -7,6 +7,7 @@ subdir-$(CONFIG_ACPI) += acpi
>  obj-$(CONFIG_ALTERNATIVE) += alternative.o
>  obj-y += bootfdt.o
>  obj-y += cpu.o
> +obj-y += cpuerrata.o
>  obj-y += cpufeature.o
>  obj-y += decode.o
>  obj-y += device.o
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> new file mode 100644
> index 000..52d39f8
> --- /dev/null
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -0,0 +1,26 @@
> +#include 
> +#include 
> +#include 
> +
> +#define MIDR_RANGE(model, min, max) \
> +.matches = is_affected_midr_range,  \
> +.midr_model = model,\
> +.midr_range_min = min,  \
> +.midr_range_max = max
> +
> +static bool_t __maybe_unused

I would remove __maybe_unused given that you are going to use this
function in later patches.


> +is_affected_midr_range(const struct arm_cpu_capabilities *entry)
> +{
> +return MIDR_IS_CPU_MODEL_RANGE(boot_cpu_data.midr.bits, 
> entry->midr_model,
> +   entry->midr_range_min,
> +   entry->midr_range_max);
> +}
> +
> +static const struct arm_cpu_capabilities arm_errata[] = {
> +{},
> +};
> +
> +void check_local_cpu_errata(void)
> +{
> +update_cpu_capabilities(arm_errata, "enabled workaround for");
> +}

update_cpu_capabilities should actually be called on arm64 only, right?
Given that runtime patching is unimplemented on arm32. I wouldn't want
to rely on the fact that we don't have any arm32 workarounds at the
moment.


> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> index 7a1b56b..088625b 100644
> --- a/xen/arch/arm/cpufeature.c
> +++ b/xen/arch/arm/cpufeature.c
> @@ -24,6 +24,22 @@
>  
>  DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
>  
> +void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
> + const char *info)

The info parameter is unnecessary.


> +{
> +int i;
> +
> +for ( i = 0; caps[i].matches; i++ )
> +{
> +if ( !caps[i].matches([i]) )
> +continue;
> +
> +if ( !cpus_have_cap(caps[i].capability) && caps[i].desc )
> +printk(XENLOG_INFO "%s: %s\n", info, caps[i].desc);
> +cpus_set_cap(caps[i].capability);
> +}
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index c4389ef..67eb13b 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -43,6 +43,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -171,6 +172,8 @@ static void __init processor_id(void)
>  }
>  
>  processor_setup();
> +
> +check_local_cpu_errata();
>  }
>  
>  void dt_unreserved_regions(paddr_t s, paddr_t e,
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index c5109bf..3f5a77b 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -316,6 +317,8 @@ void start_secondary(unsigned long boot_phys_offset,
>  local_irq_enable();
>  local_abort_enable();
>  
> +check_local_cpu_errata();
> +
>  printk(XENLOG_DEBUG "CPU %u booted.\n", smp_processor_id());
>  
>  startup_cpu_idle_loop();
> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
> new file mode 100644
> index 000..8ffd7ba
> --- /dev/null
> +++ b/xen/include/asm-arm/cpuerrata.h
> @@ -0,0 +1,6 @@
> +#ifndef __ARM_CPUERRATA_H
> +#define __ARM_CPUERRATA_H
> +
> +void check_local_cpu_errata(void);
> +

Re: [Xen-devel] [PATCH v2 14/15] xen/arm: traps: Don't inject a fault if the translation VA -> IPA fails

2016-05-30 Thread Stefano Stabellini 
On Mon, 23 May 2016, Julien Grall wrote:
> Based on ARM ARM (D4.5.3 in ARM DDI 0486A and B3.12.7 in ARM DDI 0406C.c),
> a Stage 1 translation error has priority over a Stage 2 translation error.
> 
> Therefore gva_to_ipa can only fail if another vCPU is playing with the
> page table.
> 
> Rather than injecting a custom fault, replay the instruction and let the
> processor injecting the correct fault.
> 
> This is fine as Xen is handling all the pending softirqs
> (see leave_hypervisor_tail) before returning to the guest. One of them
> is the scheduler which could reschuled the vCPU.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


> Changes in v2:
> - Update commit message to explain why a guest cannot DoS the
> hypervisor with it.
> ---
>  xen/arch/arm/traps.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index c0325d5..3acdba0 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2410,7 +2410,7 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  
>  rc = gva_to_ipa(gva, , GV2M_READ);
>  if ( rc == -EFAULT )
> -goto bad_insn_abort;
> +return; /* Try again */
>  }
>  
>  rc = p2m_mem_access_check(gpa, gva, npfec);
> @@ -2422,7 +2422,6 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  break;
>  }
>  
> -bad_insn_abort:
>  inject_iabt_exception(regs, gva, hsr.len);
>  }
>  
> @@ -2452,7 +2451,7 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  {
>  rc = gva_to_ipa(info.gva, , GV2M_READ);
>  if ( rc == -EFAULT )
> -goto bad_data_abort;
> +return; /* Try again */
>  }
>  
>  switch ( dabt.dfsc & 0x3f )
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [RFC 10/16] xen/arm: Introduce alternative runtime patching

2016-05-30 Thread Stefano Stabellini 
On Mon, 23 May 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 21/05/16 16:09, Stefano Stabellini wrote:
> > On Thu, 5 May 2016, Julien Grall wrote:
> > > +void __init apply_alternatives_all(void)
> > > +{
> > > +int ret;
> > > +
> > > + /* better not try code patching on a live SMP system */
> > > +ret = stop_machine_run(__apply_alternatives_multi_stop, NULL,
> > > NR_CPUS);
> > 
> > Why not just call stop_machine_run, passing 0 as the cpu to run
> > __apply_alternatives_multi_stop on? Given that you already have
> > secondary cpus spinning in __apply_alternatives_multi_stop.  What am I
> > missing?
> 
> Someone as to call __apply_alternatives_multi_stop on secondary CPUs.

Why? Secondary cpus would be just left spinning at the beginning of the
function. You might as well leave them spinning in
stopmachine_wait_state.

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

[Xen-devel] [xen-unstable-smoke test] 94956: tolerable all pass - PUSHED

2016-05-30 Thread osstest service owner 
flight 94956 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94956/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  8b3d6858ecbe5f958f45ac5d8e5da6fa5a18266d
baseline version:
 xen  5ff371e9d87f468bf73acfafd65ba5a0d1b7bd4f

Last test of basis94851  2016-05-27 19:01:55 Z2 days
Testing same since94956  2016-05-30 13:00:53 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Julien Grall 
  Stefano Stabellini 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=8b3d6858ecbe5f958f45ac5d8e5da6fa5a18266d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
8b3d6858ecbe5f958f45ac5d8e5da6fa5a18266d
+ branch=xen-unstable-smoke
+ revision=8b3d6858ecbe5f958f45ac5d8e5da6fa5a18266d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x8b3d6858ecbe5f958f45ac5d8e5da6fa5a18266d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local

Re: [Xen-devel] [PATCH v2 08/15] xen/arm: arm64: Add helpers to decode and encode branch instructions

2016-05-30 Thread Stefano Stabellini 
On Mon, 23 May 2016, Julien Grall wrote:
> We may need to update branch instruction when patching Xen.
> 
> The code has been imported from the files arch/arm64/kernel/insn.c
> and arch/arm64/include/asm/insn.h in Linux v4.6.
> 
> Note that only the necessary helpers have been imported.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


> Changes in v2:
> - Re-sync with Linux v4.6
> - Drop any reference to arm32
> ---
>  xen/arch/arm/arm64/Makefile  |   1 +
>  xen/arch/arm/arm64/insn.c| 219 
> +++
>  xen/include/asm-arm/arm64/insn.h |  72 +
>  xen/include/asm-arm/insn.h   |  20 
>  4 files changed, 312 insertions(+)
>  create mode 100644 xen/arch/arm/arm64/insn.c
>  create mode 100644 xen/include/asm-arm/arm64/insn.h
>  create mode 100644 xen/include/asm-arm/insn.h
> 
> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> index 39c6ac6..c1fa43f 100644
> --- a/xen/arch/arm/arm64/Makefile
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -5,6 +5,7 @@ obj-$(EARLY_PRINTK) += debug.o
>  obj-y += domctl.o
>  obj-y += domain.o
>  obj-y += entry.o
> +obj-y += insn.o
>  obj-y += smpboot.o
>  obj-y += traps.o
>  obj-y += vfp.o
> diff --git a/xen/arch/arm/arm64/insn.c b/xen/arch/arm/arm64/insn.c
> new file mode 100644
> index 000..12b4d96
> --- /dev/null
> +++ b/xen/arch/arm/arm64/insn.c
> @@ -0,0 +1,219 @@
> +/*
> + * Based on Linux v4.6 arch/arm64/kernel.ins.c

 arch/arm64/kernel/insn.c ?



> + * Copyright (C) 2013 Huawei Ltd.
> + * Author: Jiang Liu 
> + *
> + * Copyright (C) 2014-2016 Zi Shen Lim 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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 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 .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define __kprobes
> +#define pr_err(fmt, ...) printk(XENLOG_ERR fmt, ## __VA_ARGS__)
> +
> +bool aarch64_insn_is_branch_imm(u32 insn)
> +{
> + return (aarch64_insn_is_b(insn) || aarch64_insn_is_bl(insn) ||
> + aarch64_insn_is_tbz(insn) || aarch64_insn_is_tbnz(insn) ||
> + aarch64_insn_is_cbz(insn) || aarch64_insn_is_cbnz(insn) ||
> + aarch64_insn_is_bcond(insn));
> +}
> +
> +static int __kprobes aarch64_get_imm_shift_mask(enum aarch64_insn_imm_type 
> type,
> + u32 *maskp, int *shiftp)
> +{
> + u32 mask;
> + int shift;
> +
> + switch (type) {
> + case AARCH64_INSN_IMM_26:
> + mask = BIT(26) - 1;
> + shift = 0;
> + break;
> + case AARCH64_INSN_IMM_19:
> + mask = BIT(19) - 1;
> + shift = 5;
> + break;
> + case AARCH64_INSN_IMM_16:
> + mask = BIT(16) - 1;
> + shift = 5;
> + break;
> + case AARCH64_INSN_IMM_14:
> + mask = BIT(14) - 1;
> + shift = 5;
> + break;
> + case AARCH64_INSN_IMM_12:
> + mask = BIT(12) - 1;
> + shift = 10;
> + break;
> + case AARCH64_INSN_IMM_9:
> + mask = BIT(9) - 1;
> + shift = 12;
> + break;
> + case AARCH64_INSN_IMM_7:
> + mask = BIT(7) - 1;
> + shift = 15;
> + break;
> + case AARCH64_INSN_IMM_6:
> + case AARCH64_INSN_IMM_S:
> + mask = BIT(6) - 1;
> + shift = 10;
> + break;
> + case AARCH64_INSN_IMM_R:
> + mask = BIT(6) - 1;
> + shift = 16;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + *maskp = mask;
> + *shiftp = shift;
> +
> + return 0;
> +}
> +
> +#define ADR_IMM_HILOSPLIT2
> +#define ADR_IMM_SIZE SZ_2M
> +#define ADR_IMM_LOMASK   ((1 << ADR_IMM_HILOSPLIT) - 1)
> +#define ADR_IMM_HIMASK   ((ADR_IMM_SIZE >> ADR_IMM_HILOSPLIT) - 
> 1)
> +#define ADR_IMM_LOSHIFT  29
> +#define ADR_IMM_HISHIFT  5
> +
> +u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn)
> +{
> + u32 immlo, immhi, mask;
> + int shift;
> +
> + switch (type) {
> + case AARCH64_INSN_IMM_ADR:
> + shift = 0;
> + immlo = (insn >> ADR_IMM_LOSHIFT) & ADR_IMM_LOMASK;
> + immhi = (insn >>

Re: [Xen-devel] [PATCH v2 04/15] xen/arm: Add cpu_hwcap bitmap

2016-05-30 Thread Stefano Stabellini 
On Mon, 23 May 2016, Julien Grall wrote:
> This will be used to know if a feature, which Xen cares, is available accross
> all the CPUs.
> 
> This code is a light version of arch/arm64/kernel/cpufeature.c from
> Linux v4.6-rc3.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


>  xen/arch/arm/Makefile|  1 +
>  xen/arch/arm/cpufeature.c| 34 ++
>  xen/include/asm-arm/cpufeature.h | 29 +
>  3 files changed, 64 insertions(+)
>  create mode 100644 xen/arch/arm/cpufeature.c
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 8e0d2f6..9122f78 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -6,6 +6,7 @@ subdir-$(CONFIG_ACPI) += acpi
>  
>  obj-y += bootfdt.o
>  obj-y += cpu.o
> +obj-y += cpufeature.o
>  obj-y += decode.o
>  obj-y += device.o
>  obj-y += domain.o
> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> new file mode 100644
> index 000..7a1b56b
> --- /dev/null
> +++ b/xen/arch/arm/cpufeature.c
> @@ -0,0 +1,34 @@
> +/*
> + * Contains CPU feature definitions
> + *
> + * Copyright (C) 2015 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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 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 .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/include/asm-arm/cpufeature.h 
> b/xen/include/asm-arm/cpufeature.h
> index 7b519cd..2bebad1 100644
> --- a/xen/include/asm-arm/cpufeature.h
> +++ b/xen/include/asm-arm/cpufeature.h
> @@ -35,6 +35,35 @@
>  #endif
>  #define cpu_has_security  (boot_cpu_feature32(security) > 0)
>  
> +#define ARM_NCAPS   0
> +
> +#ifndef __ASSEMBLY__
> +
> +#include 
> +#include 
> +#include 
> +
> +extern DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
> +
> +static inline bool_t cpus_have_cap(unsigned int num)
> +{
> +if ( num >= ARM_NCAPS )
> +return 0;
> +
> +return test_bit(num, cpu_hwcaps);
> +}
> +
> +static inline void cpus_set_cap(unsigned int num)
> +{
> +if (num >= ARM_NCAPS)
> +printk(XENLOG_WARNING "Attempt to set an illegal CPU capability (%d 
> >= %d)\n",
> +   num, ARM_NCAPS);
> +else
> +__set_bit(num, cpu_hwcaps);
> +}
> +
> +#endif /* __ASSEMBLY__ */
> +
>  #endif
>  /*
>   * Local variables:
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH v4 8/8] x86/vm_event: Add HVM debug exception vm_events

2016-05-30 Thread Jan Beulich 
>>> On 30.05.16 at 00:37,  wrote:
> @@ -117,7 +133,11 @@ int hvm_monitor_breakpoint(unsigned long rip,
>  
>  req.vcpu_id = curr->vcpu_id;
>  
> -return vm_event_monitor_traps(curr, 1, );
> +rc = vm_event_monitor_traps(curr, sync, );
> +if ( type == HVM_MONITOR_DEBUG_EXCEPTION && rc == 1 && !sync )
> +rc = 0;
> +
> +return rc;
>  }

To someone like me, not intimately familiar with the code, this added
logic looks pretty arbitrary. Please add a comment indicating why
under these special circumstances rc needs to be altered here, which
then will hopefully also clarify why that can't be done right in
vm_event_monitor_traps().

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3377,9 +3377,25 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>  HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
>  write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
>  if ( !v->domain->debugger_attached )
> -vmx_propagate_intr(intr_info);
> +{
> +unsigned long insn_length = 0;
> +int handled;

The variable name suggests it wants to be bool_t, but ...

> +unsigned long trap_type = MASK_EXTR(intr_info,
> +
> INTR_INFO_INTR_TYPE_MASK);
> +
> +if( trap_type >= X86_EVENTTYPE_SW_INTERRUPT )
> +__vmread(VM_EXIT_INSTRUCTION_LEN, _length);
> +
> +handled = hvm_monitor_debug(regs->eip,
> +HVM_MONITOR_DEBUG_EXCEPTION,
> +trap_type, insn_length);
> +if ( handled <= 0 )

... it clearly can't. Please use a better name (could by just "rc" or
"ret"). (Otoh I see that code you modify further down uses that
same naming for a similar purpose variable. Let's see what the VMX
maintainers say.)

> +vmx_propagate_intr(intr_info);
> +
> +}
>  else
>  domain_pause_for_debugger();
> +
>  break;
>  case TRAP_int3: 

If anywhere, this added blank line wants to go after the break.

> @@ -3393,8 +3409,9 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>  }
>  else {
>  int handled =
> -hvm_monitor_breakpoint(regs->eip,
> -   HVM_MONITOR_SOFTWARE_BREAKPOINT);
> +hvm_monitor_debug(regs->eip,
> +  HVM_MONITOR_SOFTWARE_BREAKPOINT,
> +  X86_EVENTTYPE_SW_EXCEPTION, 1);

Please let's not add further mistakes like this, assuming INT3 can't
have any prefixes. It can, even if they're useless.

> @@ -3721,8 +3738,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>  vmx_update_cpu_exec_control(v);
>  if ( v->arch.hvm_vcpu.single_step )
>  {
> -hvm_monitor_breakpoint(regs->eip,
> -   HVM_MONITOR_SINGLESTEP_BREAKPOINT);
> +hvm_monitor_debug(regs->eip, HVM_MONITOR_SINGLESTEP_BREAKPOINT, 
> 0, 0);

How come the 3rd argument is literal zero here?

Also you're creating a long line here.

Jan


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

Re: [Xen-devel] [PATCH v4 2/8] monitor: Rename vm_event_monitor_guest_request

2016-05-30 Thread Jan Beulich 
>>> On 30.05.16 at 00:37,  wrote:
> Mechanical renaming and relocation to the monitor subsystem.
> 
> Signed-off-by: Tamas K Lengyel 

Non-VM-event parts
Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v4 3/8] monitor: Rename hvm/event to hvm/monitor

2016-05-30 Thread Jan Beulich 
>>> On 30.05.16 at 00:37,  wrote:
> Mechanical renaming to better describe that the code in hvm/event is part of
> the monitor subsystem.
> 
> Signed-off-by: Tamas K Lengyel 
> Acked-by: Kevin Tian 

General x86/hvm parts
Acked-by: Jan Beulich 


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

[Xen-devel] [PATCH] kexec: allow relaxed placement specification via command line

2016-05-30 Thread Jan Beulich 
Rather than just allowing a fixed address or fully automatic placement,
also allow for specifying an upper bound. Especially on EFI systems,
where firmware memory use is commonly less predictable than on legacy
BIOS ones, this makes success of the reservation more likely when
automatic placement is not an option (e.g. because of special DMA
restrictions of devices involved in actually carrying out the dump).

Also take the opportunity to actually add text to the "crashkernel"
entry in the command line option doc.

Signed-off-by: Jan Beulich 

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -458,7 +458,18 @@ Specify the maximum address to allocate
 combination with the `low_crashinfo` command line option.
 
 ### crashkernel
-> `= :[,...][@]`
+> `= :[,...][{@,<}]`
+> `= [{@,<}]`
+
+Specify sizes and optionally placement of the kexec reservation area.
+The `:' pairs indicate how much memory to set
+aside for kexec (`') for a given range of installed RAM
+(`').  Each `' is of the form
+`-[]'.
+
+A trailing `@' specifies the exact address this area should be
+placed at, whereas `<' in place of `@' just specifies an upper bound of
+the address range the area should fall into.
 
 ### credit2\_balance\_over
 > `= `
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1044,13 +1044,19 @@ void __init noreturn __start_xen(unsigne
 }
 
 #ifdef CONFIG_KEXEC
-/* Don't overlap with modules. */
-e = consider_modules(s, e, PAGE_ALIGN(kexec_crash_area.size),
- mod, mbi->mods_count, -1);
-if ( !kexec_crash_area.start && (s < e) )
+while ( !kexec_crash_area.start )
 {
-e = (e - kexec_crash_area.size) & PAGE_MASK;
-kexec_crash_area.start = e;
+/* Don't overlap with modules. */
+e = consider_modules(s, e, PAGE_ALIGN(kexec_crash_area.size),
+ mod, mbi->mods_count, -1);
+if ( s >= e )
+break;
+if ( e > kexec_crash_area_limit )
+{
+e = kexec_crash_area_limit & PAGE_MASK;
+continue;
+}
+kexec_crash_area.start = (e - kexec_crash_area.size) & PAGE_MASK;
 }
 #endif
 }
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -60,6 +60,7 @@ static unsigned char vmcoreinfo_data[VMC
 static size_t vmcoreinfo_size = 0;
 
 xen_kexec_reserve_t kexec_crash_area;
+paddr_t __initdata kexec_crash_area_limit = ~(paddr_t)0;
 static struct {
 u64 start, end;
 unsigned long size;
@@ -86,7 +87,7 @@ static void *crash_heap_current = NULL,
 /*
  * Parse command lines in the format
  *
- *   crashkernel=:[,...][@]
+ *   crashkernel=:[,...][{@,<}]
  *
  * with  being of form
  *
@@ -94,7 +95,7 @@ static void *crash_heap_current = NULL,
  *
  * as well as the legacy ones in the format
  *
- *   crashkernel=[@]
+ *   crashkernel=[{@,<}]
  */
 static void __init parse_crashkernel(const char *str)
 {
@@ -109,7 +110,7 @@ static void __init parse_crashkernel(con
 {
 printk(XENLOG_WARNING "crashkernel: too many ranges\n");
 cur = NULL;
-str = strchr(str, '@');
+str = strpbrk(str, "@<");
 break;
 }
 
@@ -154,9 +155,16 @@ static void __init parse_crashkernel(con
 }
 else
 kexec_crash_area.size = parse_size_and_unit(cur = str, );
-if ( cur != str && *str == '@' )
-kexec_crash_area.start = parse_size_and_unit(cur = str + 1, );
-if ( cur == str )
+if ( cur != str )
+{
+if ( *str == '@' )
+kexec_crash_area.start = parse_size_and_unit(cur = str + 1, );
+else if ( *str == '<' )
+kexec_crash_area_limit = parse_size_and_unit(cur = str + 1, );
+else
+printk(XENLOG_WARNING "crashkernel: '%s' ignored\n", str);
+}
+if ( cur && cur == str )
 printk(XENLOG_WARNING "crashkernel: memory value expected\n");
 }
 custom_param("crashkernel", parse_crashkernel);
--- a/xen/include/xen/kexec.h
+++ b/xen/include/xen/kexec.h
@@ -14,6 +14,7 @@ typedef struct xen_kexec_reserve {
 } xen_kexec_reserve_t;
 
 extern xen_kexec_reserve_t kexec_crash_area;
+extern paddr_t kexec_crash_area_limit;
 
 extern bool_t kexecing;
 


kexec: allow relaxed placement specification via command line

Rather than just allowing a fixed address or fully automatic placement,
also allow for specifying an upper bound. Especially on EFI systems,
where firmware memory use is commonly less predictable than on legacy
BIOS ones, this makes success of the reservation more likely when
automatic placement is not an option (e.g. because of special DMA
restrictions of devices involved in actually carrying out the dump).

Also take the opportunity to actually add text to the "crashkernel"
entry in the command line option doc.

Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH v3 0/4] xen/arm: arm64: Widen register access to mpidr to 64-bits

2016-05-30 Thread Stefano Stabellini 
On Mon, 30 May 2016, Wei Chen wrote:
> In ARM64 the MPIDR register is mapped to MPIDR_EL1, and the register
> bits are expanded to 64-bits. But Xen 64-bit ARM code treats this it
> as 32-bit register.
> We have to provide correct accessing to this register to avoid
> unexpected issues that is caused by incorrect MPIDR value.

Please don't drop acked-by and reviewed-by tags in the future (unless
you make significant changes to the patches).


> Wei Chen (4):
>   xen/arm: Change the variable type of cpu_logical_map to register_t
>   xen/arm: Make AFFINITY_MASK generate correct mask for level3
>   xen:arm: arm64: Add correct MPIDR_HWID_MASK value for ARM64
>   xen/arm: arm64: Remove MPIDR multiprocessing extensions check
> 
>  xen/arch/arm/arm64/head.S   |  3 +--
>  xen/arch/arm/gic-v3.c   |  2 +-
>  xen/arch/arm/smpboot.c  | 13 +++--
>  xen/include/asm-arm/processor.h |  9 +++--
>  4 files changed, 16 insertions(+), 11 deletions(-)
> 
> -- 
> 2.7.4
> 

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

[Xen-devel] [ovmf test] 94949: regressions - FAIL

2016-05-30 Thread osstest service owner 
flight 94949 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94949/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 265fff39483bc2e1550bbb9546b9c330e6118e25
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z5 days
Failing since 94750  2016-05-25 03:43:08 Z5 days   16 attempts
Testing same since94940  2016-05-30 01:43:31 Z0 days2 attempts


People who touched revisions under test:
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  Eugene Cohen 
  Gary Lin 
  Hao Wu 
  Jeff Fan 
  Jiaxin Wu 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Star Zeng 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 669 lines long.)

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

Re: [Xen-devel] [PATCH] arm/acpi: Fix the deadlock in function vgic_lock_rank()

2016-05-30 Thread Stefano Stabellini 
On Fri, 27 May 2016, Julien Grall wrote:
> Hello Shanker,
> 
> On 27/05/16 01:39, Shanker Donthineni wrote:
> > Commit 9d77b3c01d1261c (Configure SPI interrupt type and route to
> > Dom0 dynamically) causing dead loop inside the spinlock function.
> > Note that spinlocks in XEN are not recursive. Re-acquiring a spinlock
> > that has already held by calling CPU leads to deadlock. This happens
> > whenever dom0 does writes to GICD regs ISENABLER/ICENABLER.
> 
> Thank you for spotting it, I have not noticed it while I was  reviewing, only
> tested on a model without any SPIs.
> 
> > The following call trace explains the problem.
> > 
> > DOM0 writes GICD_ISENABLER/GICD_ICENABLER
> >vgic_v3_distr_common_mmio_write()
> >  vgic_lock_rank()  -->  acquiring first time
> >vgic_enable_irqs()
> >  route_irq_to_guest()
> >gic_route_irq_to_guest()
> >  vgic_get_target_vcpu()
> >vgic_lock_rank()  -->  attemping acquired lock
> > 
> > The simple fix release spinlock before calling vgic_enable_irqs()
> > and vgic_disable_irqs().
> 
> You should explain why you think it is valid to release the lock earlier.
> 
> In this case, I think the fix is not correct because the lock is protecting
> both the register value and the internal state in Xen (modified by
> vgic_enable_irqs). By releasing the lock earlier, they may become inconsistent
> if another vCPU is disabling the IRQs at the same time.

I agree, the vgic_enable_irqs call need to stay within the
vgic_lock_rank/vgic_unlock_rank region.


> I cannot find an easy fix which does not involve release the lock. When I was
> reviewing this patch, I suggested to split the IRQ configuration from the
> routing.

Yes, the routing doesn't need to be done from vgic_enable_irqs. It is
not nice. That would be the ideal fix, but it is not trivial.

For 4.7 we could consider reverting 9d77b3c01d1261c. The only other
thing that I can come up with which is simple would be improving
gic_route_irq_to_guest to cope with callers that have the vgic rank lock
already held (see below, untested) but it's pretty ugly.



diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 2bfe4de..57f3f3f 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -127,15 +127,12 @@ void gic_route_irq_to_xen(struct irq_desc *desc, const 
cpumask_t *cpu_mask,
 
 /* Program the GIC to route an interrupt to a guest
  *   - desc.lock must be held
+ *   - rank lock must be held
  */
-int gic_route_irq_to_guest(struct domain *d, unsigned int virq,
+static int __gic_route_irq_to_guest(struct domain *d, unsigned int virq,
struct irq_desc *desc, unsigned int priority)
 {
-unsigned long flags;
-/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
- * route SPIs to guests, it doesn't make any difference. */
-struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
-struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
+struct vcpu *v_target = __vgic_get_target_vcpu(d->vcpu[0], virq);
 struct pending_irq *p = irq_to_pending(v_target, virq);
 int res = -EBUSY;
 
@@ -144,12 +141,10 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 
virq,
 ASSERT(virq >= 32);
 ASSERT(virq < vgic_num_irqs(d));
 
-vgic_lock_rank(v_target, rank, flags);
-
 if ( p->desc ||
  /* The VIRQ should not be already enabled by the guest */
  test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
-goto out;
+return res;
 
 desc->handler = gic_hw_ops->gic_guest_irq_type;
 set_bit(_IRQ_GUEST, >status);
@@ -159,12 +154,36 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 
virq,
 p->desc = desc;
 res = 0;
 
-out:
-vgic_unlock_rank(v_target, rank, flags);
-
 return res;
 }
 
+int gic_route_irq_to_guest(struct domain *d, unsigned int virq,
+   struct irq_desc *desc, unsigned int priority)
+{
+unsigned long flags;
+int lock = 0, retval;
+struct vgic_irq_rank *rank;
+
+/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
+ * route SPIs to guests, it doesn't make any difference. */
+rank = vgic_rank_irq(d->vcpu[0], virq);
+
+/* Take the rank spinlock unless it has already been taken by the
+ * caller. */
+if ( !spin_is_locked(>lock) ) {
+vgic_lock_rank(d->vcpu[0], rank, flags);
+lock = 1;
+}
+
+retval = __gic_route_irq_to_guest(d, virq, desc, GIC_PRI_IRQ);
+
+if ( lock )
+vgic_unlock_rank(d->vcpu[0], rank, flags);
+
+return retval;
+
+}
+
 /* This function only works with SPIs for now */
 int gic_remove_irq_from_guest(struct domain *d, unsigned int virq,
   struct irq_desc *desc)
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index aa420bb..e45669f 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -215,7 +215,7 @@ int vcpu_vgic_free(struct vcpu *v)
 }
 
 /* The function

[Xen-devel] [qemu-upstream-4.3-testing test] 94952: trouble: blocked/broken

2016-05-30 Thread osstest service owner 
flight 94952 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94952/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  113 days
Testing same since93977  2016-05-10 11:09:16 Z   20 days   82 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked

[Xen-devel] [PATCH RFC] x86emul: conditionally clear BNDn for branches

2016-05-30 Thread Jan Beulich 
Considering that we surface MPX to HVM guests, instructions we emulate
should also correctly deal with MPX state. While for now BND*
instructions don't get emulated, the effect of branches (which we do
emulate) without BND prefix should be taken care of.

Signed-off-by: Jan Beulich 
---
RFC reasons:
- I haven't been able to find a layout specification for the BNDCSR
  area in the SDM, therefore struct xstate_bndcsr's layout is guessed.
- The SDM volumes contradict one another regarding short conditional
  branch behavior: SDM Vol 1 says they init BNDn (except for
  J{,E,R}CXZ), while Vol 2 says BND only affects near branches. The
  code for now assumes only near ones are affected.
- The SDM leaves open whether only taken Jcc will cause BNDn init, or
  also not taken ones. The code for now assumes only taken ones do.
- It is also left unclear whether addressing forms without base address
  register are valid for BNDMK (the instruction page references
  SRCMEM.base without indicating what this means in that specific
  case). The code uses an explicit base register for that reason (which
  also yields slightly smaller code).

--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -10,11 +10,15 @@ typedef bool bool_t;
 
 #define is_canonical_address(x) (((int64_t)(x) >> 47) == ((int64_t)(x) >> 63))
 
+#define EFER_SCE   (1 << 0)
+#define EFER_LMA   (1 << 10)
+
 #define BUG() abort()
 #define ASSERT assert
 
 #define cpu_has_amd_erratum(nr) 0
 #define mark_regs_dirty(r) ((void)(r))
+#define read_bndcfgu() 0
 
 #define __packed __attribute__((packed))
 
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -14,6 +14,7 @@ $(call as-insn-check,CFLAGS,CC,"vmcall",
 $(call as-insn-check,CFLAGS,CC,"vmcall",-DHAVE_GAS_VMX)
 $(call as-insn-check,CFLAGS,CC,"invept (%rax)$$(comma)%rax",-DHAVE_GAS_EPT)
 $(call as-insn-check,CFLAGS,CC,"rdfsbase %rax",-DHAVE_GAS_FSGSBASE)
+$(call as-insn-check,CFLAGS,CC,"bndmov %bnd0$$(comma)%bnd0",-DHAVE_GAS_MPX)
 $(call as-insn-check,CFLAGS,CC,".equ \"x\"$$(comma)1", \
  -U__OBJECT_LABEL__ -DHAVE_GAS_QUOTED_SYM \
  '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$$@')
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -421,6 +421,8 @@ int vcpu_initialise(struct vcpu *v)
 
 vmce_init_vcpu(v);
 }
+else if ( (rc = xstate_alloc_save_area(v)) != 0 )
+return rc;
 
 spin_lock_init(>arch.vpmu.vpmu_lock);
 
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2623,6 +2623,11 @@ static int vmx_msr_read_intercept(unsign
 case MSR_IA32_DEBUGCTLMSR:
 __vmread(GUEST_IA32_DEBUGCTL, msr_content);
 break;
+case MSR_IA32_BNDCFGS:
+if ( !cpu_has_mpx )
+goto gp_fault;
+__vmread(GUEST_BNDCFGS, msr_content);
+break;
 case IA32_FEATURE_CONTROL_MSR:
 case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_TRUE_ENTRY_CTLS:
 if ( !nvmx_msr_read_intercept(msr, msr_content) )
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -13,6 +13,7 @@
 #include 
 #include  /* mark_regs_dirty() */
 #include  /* current_cpu_info */
+#include  /* read_bndcfgu() */
 #include  /* cpu_has_amd_erratum() */
 
 /* Avoid namespace pollution. */
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -355,9 +355,10 @@ typedef union {
 #define MSR_SYSENTER_CS  0x0174
 #define MSR_SYSENTER_ESP 0x0175
 #define MSR_SYSENTER_EIP 0x0176
+#define MSR_BNDCFGS  0x0d90
+#define BNDCFG_ENABLE(1 << 0)
+#define BNDCFG_PRESERVE  (1 << 1)
 #define MSR_EFER 0xc080
-#define EFER_SCE (1u<<0)
-#define EFER_LMA (1u<<10)
 #define MSR_STAR 0xc081
 #define MSR_LSTAR0xc082
 #define MSR_CSTAR0xc083
@@ -1090,6 +1091,7 @@ static bool_t vcpu_has(
 #define vcpu_has_clflush() vcpu_has(   1, EDX, 19, ctxt, ops)
 #define vcpu_has_lzcnt() vcpu_has(0x8001, ECX,  5, ctxt, ops)
 #define vcpu_has_bmi1()  vcpu_has(0x0007, EBX,  3, ctxt, ops)
+#define vcpu_has_mpx()   vcpu_has(0x0007, EBX, 14, ctxt, ops)
 
 #define vcpu_must_have(leaf, reg, bit) \
 generate_exception_if(!vcpu_has(leaf, reg, bit, ctxt, ops), EXC_UD, -1)
@@ -1491,6 +1493,41 @@ static int inject_swint(enum x86_swint_t
 return ops->inject_hw_exception(fault_type, error_code, ctxt);
 }
 
+static void clear_bnd(struct x86_emulate_ctxt *ctxt,
+  const struct x86_emulate_ops *ops, enum vex_pfx pfx)
+{
+uint64_t bndcfg;
+int rc;
+
+if ( pfx == vex_f2 || !vcpu_has_mpx() )
+return;
+
+#ifdef __XEN__
+ASSERT(cpu_has_mpx);
+#endif
+
+if ( !mode_ring0() )
+bndcfg = read_bndcfgu();
+else if ( !ops->read_msr ||
+  ops->read_msr(MSR_BNDCFGS, , ctxt) )
+return;
+if ( (bndcfg & BNDCFG_ENABLE) && !(bndcfg & BNDCFG_PRESERVE) )
+{
+#if HAVE_GAS_MPX
+

Re: [Xen-devel] [PATCH] arm/acpi: Add Server Base System Architecture UART support

2016-05-30 Thread Julien Grall 



On 30/05/2016 13:08, Julien Grall wrote:



On 30/05/2016 13:00, Stefano Stabellini wrote:

On Fri, 27 May 2016, Julien Grall wrote:

Hello Shanker,

On 27/05/16 15:01, Shanker Donthineni wrote:

On 05/27/2016 08:04 AM, Julien Grall wrote:

On 27/05/16 01:28, Shanker Donthineni wrote:

The ARM Server Base System Architecture describes a generic UART
interface. It doesn't support clock control registers to set
baudrate. So, extend the driver probe() to handle SBSA interface
types and set the baudrate to 115200 for SBSA interfaces.


I cannot find any mention of the baudrate in the SBSA. Where does
it come
from?


Yes, no where mentioned about the baudrate in SBSA document. I used
115200
based on the  the Linux  PL011 driver.


Looking at the Linux code, it is a default when there is no valid
configuration (which may not be suitable for any platform?).

Whilst Linux userspace cares about the baudrate, Xen only use it to
configure
the hardware. Given that the UART should have been configured by the
hardware-specific software, the proper value should be BAUD_AUTO.

If you look at the code, pl011_init_preirq will read the baud rate when
uart->baud == BAUD_AUTO but will never be used after.


The problem is that IBRD and FBRD are not part of the SBSA doc, so to
make the driver compliant, we would have to skip reading the baudrate
too, which shouldn't be a problem.


Well, we are reading the baud rate, but it is never used within the
driver except. So I would drop the code rather than skip it.


Actually, looking a bit more at the code. The code to handle a fixed 
baud rate (baud != BAUD_AUTO) is likely buggy because the clock 
frequency (clk_hz) is hardcoded in Xen. Based on the commit log, the 
value is versatile express specific.


Anyway, the driver is always setting the baud rate to auto. So I will 
send a patch to drop completely the selection of the baud rate.


Note, that this may not be sufficient to support the SBSA UART.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] arm/acpi: Add Server Base System Architecture UART support

2016-05-30 Thread Julien Grall 



On 30/05/2016 13:00, Stefano Stabellini wrote:

On Fri, 27 May 2016, Julien Grall wrote:

Hello Shanker,

On 27/05/16 15:01, Shanker Donthineni wrote:

On 05/27/2016 08:04 AM, Julien Grall wrote:

On 27/05/16 01:28, Shanker Donthineni wrote:

The ARM Server Base System Architecture describes a generic UART
interface. It doesn't support clock control registers to set
baudrate. So, extend the driver probe() to handle SBSA interface
types and set the baudrate to 115200 for SBSA interfaces.


I cannot find any mention of the baudrate in the SBSA. Where does it come
from?


Yes, no where mentioned about the baudrate in SBSA document. I used 115200
based on the  the Linux  PL011 driver.


Looking at the Linux code, it is a default when there is no valid
configuration (which may not be suitable for any platform?).

Whilst Linux userspace cares about the baudrate, Xen only use it to configure
the hardware. Given that the UART should have been configured by the
hardware-specific software, the proper value should be BAUD_AUTO.

If you look at the code, pl011_init_preirq will read the baud rate when
uart->baud == BAUD_AUTO but will never be used after.


The problem is that IBRD and FBRD are not part of the SBSA doc, so to
make the driver compliant, we would have to skip reading the baudrate
too, which shouldn't be a problem.


Well, we are reading the baud rate, but it is never used within the 
driver except. So I would drop the code rather than skip it.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] arm/acpi: Add Server Base System Architecture UART support

2016-05-30 Thread Stefano Stabellini 
On Fri, 27 May 2016, Julien Grall wrote:
> Hello Shanker,
> 
> On 27/05/16 15:01, Shanker Donthineni wrote:
> > On 05/27/2016 08:04 AM, Julien Grall wrote:
> > > On 27/05/16 01:28, Shanker Donthineni wrote:
> > > > The ARM Server Base System Architecture describes a generic UART
> > > > interface. It doesn't support clock control registers to set
> > > > baudrate. So, extend the driver probe() to handle SBSA interface
> > > > types and set the baudrate to 115200 for SBSA interfaces.
> > > 
> > > I cannot find any mention of the baudrate in the SBSA. Where does it come
> > > from?
> > > 
> > Yes, no where mentioned about the baudrate in SBSA document. I used 115200
> > based on the  the Linux  PL011 driver.
> 
> Looking at the Linux code, it is a default when there is no valid
> configuration (which may not be suitable for any platform?).
> 
> Whilst Linux userspace cares about the baudrate, Xen only use it to configure
> the hardware. Given that the UART should have been configured by the
> hardware-specific software, the proper value should be BAUD_AUTO.
> 
> If you look at the code, pl011_init_preirq will read the baud rate when
> uart->baud == BAUD_AUTO but will never be used after.

The problem is that IBRD and FBRD are not part of the SBSA doc, so to
make the driver compliant, we would have to skip reading the baudrate
too, which shouldn't be a problem.

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

[Xen-devel] [RFC v2] dma-mapping: Use unsigned long for dma_attrs

2016-05-30 Thread Krzysztof Kozlowski 
The dma-mapping core and the implementations do not change the
DMA attributes passed by pointer.  Thus the pointer can point to const
data.  However the attributes do not have to be a bitfield. Instead
unsigned long will do fine:

1. This is just simpler.  Both in terms of reading the code and setting
   attributes.  Instead of initializing local attributes on the stack and
   passing pointer to it to dma_set_attr(), just set the bits.

2. It brings safeness and checking for const correctness because the
   attributes are passed by value.

Please have in mind that this is RFC, not finished yet.  Only ARM and
ARM64 are fixed (and not everywhere).
However other API users also have to be converted which is quite
intrusive.  I would rather avoid it until the overall approach is
accepted.

Signed-off-by: Krzysztof Kozlowski 
---
 Documentation/DMA-API.txt |   2 +-
 Documentation/DMA-attributes.txt  |   2 +-
 arch/arm/include/asm/dma-mapping.h|  13 ++--
 arch/arm/include/asm/xen/page-coherent.h  |  16 ++---
 arch/arm/mm/dma-mapping.c |  82 +++
 arch/arm/xen/mm.c |   4 +-
 arch/arm64/mm/dma-mapping.c   |  57 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |   1 -
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |  20 +++---
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |   2 +-
 drivers/iommu/dma-iommu.c |   6 +-
 drivers/xen/swiotlb-xen.c |  14 ++--
 include/linux/dma-attrs.h |  71 
 include/linux/dma-iommu.h |   6 +-
 include/linux/dma-mapping.h   | 105 +-
 include/linux/swiotlb.h   |  10 +--
 include/xen/swiotlb-xen.h |  12 ++--
 lib/dma-noop.c|   9 +--
 lib/swiotlb.c |  13 ++--
 20 files changed, 195 insertions(+), 252 deletions(-)
 delete mode 100644 include/linux/dma-attrs.h

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 45ef3f279c3b..0b55cb7c5aaa 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -391,7 +391,7 @@ without the _attrs suffixes, except that they pass an 
optional
 struct dma_attrs*.
 
 struct dma_attrs encapsulates a set of "DMA attributes". For the
-definition of struct dma_attrs see linux/dma-attrs.h.
+definition of struct dma_attrs see linux/dma-mapping.h.
 
 The interpretation of DMA attributes is architecture-specific, and
 each attribute should be documented in Documentation/DMA-attributes.txt.
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index e8cf9cf873b3..2d455a5cf671 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -2,7 +2,7 @@
==
 
 This document describes the semantics of the DMA attributes that are
-defined in linux/dma-attrs.h.
+defined in linux/dma-mapping.h.
 
 DMA_ATTR_WRITE_BARRIER
 --
diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index a83570f10124..d009f7911ffc 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -5,7 +5,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -174,7 +173,7 @@ static inline void dma_mark_clean(void *addr, size_t size) 
{ }
  * to be the device-viewed address.
  */
 extern void *arm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
-  gfp_t gfp, struct dma_attrs *attrs);
+  gfp_t gfp, unsigned long attrs);
 
 /**
  * arm_dma_free - free memory allocated by arm_dma_alloc
@@ -191,7 +190,7 @@ extern void *arm_dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
  * during and after this call executing are illegal.
  */
 extern void arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
-dma_addr_t handle, struct dma_attrs *attrs);
+dma_addr_t handle, unsigned long attrs);
 
 /**
  * arm_dma_mmap - map a coherent DMA allocation into user space
@@ -208,7 +207,7 @@ extern void arm_dma_free(struct device *dev, size_t size, 
void *cpu_addr,
  */
 extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
-   struct dma_attrs *attrs);
+   unsigned long attrs);
 
 /*
  * This can be called during early boot to increase the size of the atomic
@@ -262,16 +261,16 @@ extern void dmabounce_unregister_dev(struct device *);
  * The scatter list versions of the above methods.
  */
 extern int arm_dma_map_sg(struct device *, struct scatterlist *, int,
-   enum dma_data_direction, struct dma_attrs *attrs);
+   enum dma_data_direction,

Re: [Xen-devel] [for-4.7 v3 0/2] xen: XENMEM_add_to_physmap_batch: Mark 'foreign_id" as reserved for dev_mmio

2016-05-30 Thread Wei Liu 
On Fri, May 27, 2016 at 05:06:19PM +0100, Julien Grall wrote:
> Hello all,
> 
> This series is based on the thread [1]. To allow future extension, the new
> space dev_mmio should have all unused fields marked as reserved.
> 
> This series is candidate for Xen 4.7, the first patch ensure a clean ABI
> for the new space which will allow future extension.
> 
> See in each patch for all the changes.
> 
> Regards,
> 
> [1] http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02328.html
> 
> Julien Grall (2):
>   xen: XENMEM_add_to_physmap_batch: Mark 'foreign_id' as reserved for
> dev_mmio
>   xen/arm: Document the behavior of XENMAPSPACE_dev_mmio
> 
>  xen/arch/arm/mm.c   |  9 +++--
>  xen/arch/x86/mm.c   |  4 ++--
>  xen/common/compat/memory.c  |  7 +++
>  xen/common/memory.c | 12 +---
>  xen/include/public/memory.h | 16 ++--
>  xen/include/xen/mm.h|  3 ++-
>  6 files changed, 41 insertions(+), 10 deletions(-)
> 
> -- 
> 1.9.1
> 

Release-acked-by: Wei Liu 

Thanks everyone.

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

[Xen-devel] [RFC v2] Change dma_attrs from bitfield to unsigned long

2016-05-30 Thread Krzysztof Kozlowski 
Hi,


This is second attempt to bring some safeness to dma_attrs.
In v1 [0] I added const to data pointed by attrs. However Christoph
Hellwig suggested getting rid of struct dma_attrs in favor of
some simpler data type.


Benefits of unsigned long for dma_attrs:
1. This is just simpler.  Both in terms of reading the code and setting
   attributes.  Instead of initializing local attributes on the stack and
   passing pointer to it to dma_set_attr(), just set the bits.

2. It brings safeness and checking for const correctness because the
   attributes are passed by value.


The problem is that the patch touches the dma-mapping API so all
the users have to be converted (ARM and ARM64 as of now).

Any ideas to split it per smaller patches?

The work is not finished yet, I would rather get some feedback before
progressing further.


Best regards,
Krzysztof


Krzysztof Kozlowski (1):
  dma-mapping: Use unsigned long for dma_attrs

 Documentation/DMA-API.txt |   2 +-
 Documentation/DMA-attributes.txt  |   2 +-
 arch/arm/include/asm/dma-mapping.h|  13 ++--
 arch/arm/include/asm/xen/page-coherent.h  |  16 ++---
 arch/arm/mm/dma-mapping.c |  82 +++
 arch/arm/xen/mm.c |   4 +-
 arch/arm64/mm/dma-mapping.c   |  57 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |   1 -
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |  20 +++---
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |   2 +-
 drivers/iommu/dma-iommu.c |   6 +-
 drivers/xen/swiotlb-xen.c |  14 ++--
 include/linux/dma-attrs.h |  71 
 include/linux/dma-iommu.h |   6 +-
 include/linux/dma-mapping.h   | 105 +-
 include/linux/swiotlb.h   |  10 +--
 include/xen/swiotlb-xen.h |  12 ++--
 lib/dma-noop.c|   9 +--
 lib/swiotlb.c |  13 ++--
 20 files changed, 195 insertions(+), 252 deletions(-)
 delete mode 100644 include/linux/dma-attrs.h

-- 
1.9.1


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

Re: [Xen-devel] [for-4.7 v3 1/2] xen: XENMEM_add_to_physmap_batch: Mark 'foreign_id' as reserved for dev_mmio

2016-05-30 Thread Jan Beulich 
>>> On 27.05.16 at 18:06,  wrote:
> The field 'foreign_id' is not used when the space is dev_mmio. As the
> space is not yet part of the stable ABI, the field is marked as reserved
> for future use.
> 
> The value should always be 0, other values will return -EOPNOTSUPP.
> 
> Signed-off-by: Julien Grall 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers

2016-05-30 Thread Jan Beulich 
>>> On 30.05.16 at 00:37,  wrote:
> +struct vm_event_regs_arm32 {
> +uint32_t r0_usr;
> +uint32_t r1_usr;
> +uint32_t r2_usr;
> +uint32_t r3_usr;
> +uint32_t r4_usr;
> +uint32_t r5_usr;
> +uint32_t r6_usr;
> +uint32_t r7_usr;
> +uint32_t r8_usr;
> +uint32_t r9_usr;
> +uint32_t r10_usr;
> +uint32_t r12_usr;
> +uint32_t lr_usr;
> +uint32_t fp;
> +uint32_t pc;
> +uint32_t sp_usr;
> +uint32_t sp_svc;
> +uint32_t spsr_svc;
> +};

It would seem more natural for the "ordinary" registers to be
arranged in the numerical sequence, i.e. fp, r12, sp, lr, pc.

> +struct vm_event_regs_arm64 {
> +uint64_t x0;
> +uint64_t x1;
> +uint64_t x2;
> +uint64_t x3;
> +uint64_t x4;
> +uint64_t x5;
> +uint64_t x6;
> +uint64_t x7;
> +uint64_t x8;
> +uint64_t x9;
> +uint64_t x10;
> +uint64_t x16;
> +uint64_t lr;
> +uint64_t fp;
> +uint64_t pc;
> +uint64_t sp_el0;
> +uint64_t sp_el1;
> +uint32_t spsr_el1;
> +uint32_t _pad;
> +};

My ARM knowledge is certainly quite limited, but the incomplete set
of GPRs here is quite obvious: Is there a reason to not make all of
them available here? And if there is, could the criteria of which
registers got put here please be documented in a comment (so that
the next person noticing the incomplete set won't ask again)?

I'm also puzzled by fp and lr - I'm not aware of registers of those
names (and gas also doesn't accept them afaict).

> +struct vm_event_regs_arm {
> +uint32_t cpsr; /* PSR_MODE_BIT is set iff arm32 is used below */

Explicit padding missing after this one.

Jan


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

Re: [Xen-devel] [for-4.8 v2 0/2] xen/arm: Convert DEBUG_DT to Kconfig

2016-05-30 Thread Stefano Stabellini 
On Fri, 27 May 2016, Julien Grall wrote:
> Hello all,
> 
> This small patch series converts DEBUG_DT to Kconfig. This is easier
> to enable than having to modify the code when the user wants to debug
> the device tree parsing.
> 
> This series is based on the version 4 of "Kconfig debug options" [1].

In my queue for 4.8 (but not in next-4.8 as I don't want to import the
dependency).


> Yours sincerely,
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2016-05/msg02093.html
> 
> Julien Grall (2):
>   xen/arm: Convert DEBUG_DT to Kconfig
>   xen/arm: Provide device tree debugging helper in a single place
> 
>  xen/Kconfig.debug |  8 +
>  xen/arch/arm/domain_build.c   | 73 
> ---
>  xen/common/device_tree.c  |  6 +---
>  xen/include/xen/device_tree.h |  9 ++
>  4 files changed, 52 insertions(+), 44 deletions(-)
> 
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH] xen/arm: setup: fix typo

2016-05-30 Thread Stefano Stabellini 
On Fri, 27 May 2016, Julien Grall wrote:
> Hello Peng,
> 
> On 27/05/16 06:20, Peng Fan wrote:
> > Typo fix: fdt_get_mem_rsc -> fdt_get_mem_rsv
> > 
> > Signed-off-by: Peng Fan 
> > Cc: Julien Grall 
> > Cc: Stefano Stabellini 
> 
> Reviewed-by: Julien Grall 

committed to my next-4.8 branch

> 
> > ---
> >   xen/arch/arm/setup.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 09ff1ea..dcb23b7 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -185,7 +185,7 @@ void dt_unreserved_regions(paddr_t s, paddr_t e,
> >   /* If we can't read it, pretend it doesn't exist... */
> >   continue;
> > 
> > -r_e += r_s; /* fdt_get_mem_rsc returns length */
> > +r_e += r_s; /* fdt_get_mem_rsv returns length */
> > 
> >   if ( s < r_e && r_s < e )
> >   {
> > 
> 
> -- 
> Julien Grall
> 

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

  1   2   >