date:20180208

flight 118713 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118713/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  c9d46c6fba9496478fa9f42c4bbebce8a191527d
baseline version:
 xen  5eaa17357bbef0ae4962daa369573b4dbdee7e83

Last test of basis   118704  2018-02-08 22:22:54 Z0 days
Testing same since   118713  2018-02-09 01:02:02 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  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 :

To xenbits.xen.org:/home/xen/git/xen.git
   5eaa17357b..c9d46c6fba  c9d46c6fba9496478fa9f42c4bbebce8a191527d -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-3.18 test] 118666: regressions - FAIL

flight 118666 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118666/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  9 leak-check/basis(9)  fail REGR. vs. 118488

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118488
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118488
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118488
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118488
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118488
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118488
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linuxcde3537bd1098cd4df322c397ef016015890913c
baseline version:
 linux90aaf2f25609f99b63fcbed280716f80b4bc5f56

Last test of basis   118488  2018-01-31 14:16:23 Z8 days
Testing same since   118666  2018-02-07 21:47:22 Z1 days1 attempts


People who touched revisions under test:
  Aaron Brown 
  Amit Pundir 
  Andrew Elble 
  Ben Hutchings 
  Bo Hu 
  Chun-Yeow Yeoh 
  Colin Ian King 
  David S. Miller 
  Dmitry Torokhov 
  Dmitry Vyukov 
  Eduardo Otubo

[Xen-devel] [PATCH 6/7] drivers/passthrough/arm: Refactor code for arm smmu drivers

Pull common defines for SMMU drives in a local header.

Signed-off-by: Sameer Goel 
---
 xen/drivers/passthrough/arm/arm_smmu.h | 125 +
 xen/drivers/passthrough/arm/smmu-v3.c  |  96 +
 xen/drivers/passthrough/arm/smmu.c | 104 +--
 3 files changed, 128 insertions(+), 197 deletions(-)
 create mode 100644 xen/drivers/passthrough/arm/arm_smmu.h

diff --git a/xen/drivers/passthrough/arm/arm_smmu.h 
b/xen/drivers/passthrough/arm/arm_smmu.h
new file mode 100644
index 00..f49dceb5b4
--- /dev/null
+++ b/xen/drivers/passthrough/arm/arm_smmu.h
@@ -0,0 +1,125 @@
+/**
+ * ./arm_smmu.h
+ *
+ * Common compatibility defines and data_structures for porting arm smmu
+ * drivers from Linux.
+ *
+ * Copyright (c) 2017 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 .
+ */
+
+#ifndef __ARM_SMMU_H__
+#define __ARM_SMMU_H__
+
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Helpers to get device MMIO and IRQs */
+struct resource {
+u64 addr;
+u64 size;
+unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+/* Stub out DMA domain related functions */
+#define iommu_get_dma_cookie(dom) 0
+#define iommu_put_dma_cookie(dom)
+
+#define VA_BITS0 /* Only used for configuring stage-1 input 
size */
+
+#define MODULE_DEVICE_TABLE(type, name)
+#define module_param_named(name, value, type, perm)
+#define MODULE_PARM_DESC(_parm, desc)
+
+#define dma_set_mask_and_coherent(d, b)0
+#define of_dma_is_coherent(n)  0
+
+static void __iomem *devm_ioremap_resource(struct device *dev,
+  struct resource *res)
+{
+void __iomem *ptr;
+
+if ( !res || res->type != IORESOURCE_MEM )
+{
+dev_err(dev, "Invalid resource\n");
+return ERR_PTR(-EINVAL);
+}
+
+ptr = ioremap_nocache(res->addr, res->size);
+if ( !ptr )
+{
+dev_err(dev, "ioremap failed (addr 0x%"PRIx64" size 0x%"PRIx64")\n",
+res->addr, res->size);
+return ERR_PTR(-ENOMEM);
+}
+
+return ptr;
+}
+
+/*
+ * Domain type definitions. Not really needed for Xen, defining to port
+ * Linux code as-is
+ */
+#define IOMMU_DOMAIN_UNMANAGED 0
+#define IOMMU_DOMAIN_DMA 1
+#define IOMMU_DOMAIN_IDENTITY 2
+
+/* Xen: Compatibility define for iommu_domain_geometry.*/
+struct iommu_domain_geometry {
+dma_addr_t aperture_start; /* First address that can be mapped*/
+dma_addr_t aperture_end;   /* Last address that can be mapped */
+bool force_aperture;   /* DMA only allowed in mappable range? */
+};
+
+/* Xen: Dummy iommu_domain */
+struct iommu_domain {
+/* Runtime SMMU configuration for this iommu_domain */
+struct arm_smmu_domain *priv;
+unsigned int   type;
+
+/* Dummy compatibility defines */
+unsigned long pgsize_bitmap;
+struct iommu_domain_geometry geometry;
+
+atomic_t ref;
+/* Used to link iommu_domain contexts for a same domain.
+ * There is at least one per-SMMU to used by the domain.
+ */
+struct list_head   list;
+};
+
+/* Xen: Describes information required for a Xen domain */
+struct arm_smmu_xen_domain {
+spinlock_t lock;
+/* List of iommu domains associated to this domain */
+struct list_head   contexts;
+};
+
+#endif /* __ARM_SMMU_H__ */
+
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index f43485fe6e..f0a61521fb 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -49,28 +49,7 @@
 #include 
 #include 
 
-/* Alias to Xen device tree helpers */
-#define device_node dt_device_node
-#define of_phandle_args dt_phandle_args
-#define of_device_id dt_device_match

[Xen-devel] [PATCH 2/7] xen/bitops: Rename LOG_2 to ilog2

Changing the name of the macro from LOG_2 to ilog2.This makes the function name
similar to its Linux counterpart. Since, this is not used in multiple places,
the code churn is minimal.

This change helps in porting unchanged code from Linux.

Signed-off-by: Sameer Goel 
---
 xen/arch/x86/x86_64/asm-offsets.c | 2 +-
 xen/include/xen/bitops.h  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index 51be528f89..e6d4147525 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -166,7 +166,7 @@ void __dummy__(void)
 BLANK();
 #endif
 
-DEFINE(IRQSTAT_shift, LOG_2(sizeof(irq_cpustat_t)));
+DEFINE(IRQSTAT_shift, ilog2(sizeof(irq_cpustat_t)));
 OFFSET(IRQSTAT_softirq_pending, irq_cpustat_t, __softirq_pending);
 BLANK();
 
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index e2019b02a3..a103e49089 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -223,7 +223,7 @@ static inline __u32 ror32(__u32 word, unsigned int shift)
 #define __L4(_x)  (((_x) & 0x000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
 #define __L8(_x)  (((_x) & 0x00f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
 #define __L16(_x) (((_x) & 0xff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
-#define LOG_2(_x) (((_x) & 0x) ? (16 + __L16((_x)>>16)) : __L16(_x))
+#define ilog2(_x) (((_x) & 0x) ? (16 + __L16((_x)>>16)) : __L16(_x))
 
 /**
  * for_each_set_bit - iterate over every set bit in a memory region
-- 
2.14.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 5/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */
- xen/linux_compat: Add a Linux compat header
  For porting files directly from Linux it is useful to have a function mapping
  definitions from Linux to Xen. This file adds common API functions and
  other defines that are needed for porting arm SMMU drivers.

Signed-off-by: Sameer Goel 
---
 xen/arch/arm/p2m.c|   1 +
 xen/drivers/Kconfig   |   2 +
 xen/drivers/passthrough/arm/Kconfig   |   8 +
 xen/drivers/passthrough/arm/Makefile  |   1 +
 xen/drivers/passthrough/arm/smmu-v3.c | 892 --
 xen/include/xen/linux_compat.h|  84 
 6 files changed, 959 insertions(+), 29 deletions(-)
 create mode 100644 xen/drivers/passthrough/arm/Kconfig
 create mode 100644 xen/include/xen/linux_compat.h

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 65e8b9c6ea..fef7605fd6 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1460,6 +1460,7 @@ err:
 static void __init setup_virt_paging_one(void *data)
 {
 unsigned long val = (unsigned long)data;
+/* SMMUv3 S2 cfg vtcr reuses the following value */
 WRITE_SYSREG32(val, VTCR_EL2);
 isb();
 }
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index bc3a54f0ea..612655386d 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -12,4 +12,6 @@ source "drivers/pci/Kconfig"
 
 source "drivers/video/Kconfig"
 
+source "drivers/passthrough/arm/Kconfig"
+
 endmenu
diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
new file mode 100644
index 00..cda899f608
--- /dev/null
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -0,0 +1,8 @@
+
+config ARM_SMMU_v3
+   bool "ARM SMMUv3 Support"
+   depends on ARM_64
+   help
+Support for implementations of the ARM System MMU architecture
+version 3.
+
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e15d..e14732b55c 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
 obj-y += iommu.o
 obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index e67ba6c40f..f43485fe6e 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -18,28 +18,414 @@
  * Author: Will Deacon 
  *
  * This driver is powered by bad coffee and bombay mix.
+ *
+ *
+ * Based on Linux drivers/iommu/arm-smmu-v3.c
+ * => commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
+ *
+ * Xen modifications:
+ * Sameer Goel 
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource {
+   u64 addr;
+   u64 size;
+   unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+ unsigned int type,
+ unsigned int num)
+{
+   /*
+* The resource is only used between 2 calls of platform_get_resource.
+* It's quite ugly but it's avoid to add too much code in the part
+* imported from Linux
+*/
+   static struct resource res;
+   struct acpi_iort_node *iort_node;
+   struct acpi_iort_smmu_v3 *node_smmu_data;
+   int ret = 0;
+
+   res.type = type;
+
+   switch (type) {
+   case IORESOURCE_MEM:
+   if (pdev->type == DEV_ACPI) {
+   ret = 1;
+   iort_node = pdev->acpi_node;
+   node_smmu_data =
+   (struct acpi_iort_smmu_v3 
*)iort_node->node_data;
+
+   if (node_smmu_data != NULL) {
+   res.addr = node_smmu_data->base_address;
+   res.size =

[Xen-devel] [PATCH 4/7] Add verbatim copy of arm-smmu-v3.c from Linux

Based on commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
This is a verbatim snapshot of arm-smmu-v3.c from Linux kernel source
code.
No Xen code has been added and the file is not built.

Signed-off-by: Sameer Goel 
---
 xen/drivers/passthrough/arm/smmu-v3.c | 2885 +
 1 file changed, 2885 insertions(+)
 create mode 100644 xen/drivers/passthrough/arm/smmu-v3.c

diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
new file mode 100644
index 00..e67ba6c40f
--- /dev/null
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -0,0 +1,2885 @@
+/*
+ * IOMMU API for ARM architected SMMUv3 implementations.
+ *
+ * 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 .
+ *
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Will Deacon 
+ *
+ * This driver is powered by bad coffee and bombay mix.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "io-pgtable.h"
+
+/* MMIO registers */
+#define ARM_SMMU_IDR0  0x0
+#define IDR0_ST_LVL_SHIFT  27
+#define IDR0_ST_LVL_MASK   0x3
+#define IDR0_ST_LVL_2LVL   (1 << IDR0_ST_LVL_SHIFT)
+#define IDR0_STALL_MODEL_SHIFT 24
+#define IDR0_STALL_MODEL_MASK  0x3
+#define IDR0_STALL_MODEL_STALL (0 << IDR0_STALL_MODEL_SHIFT)
+#define IDR0_STALL_MODEL_FORCE (2 << IDR0_STALL_MODEL_SHIFT)
+#define IDR0_TTENDIAN_SHIFT21
+#define IDR0_TTENDIAN_MASK 0x3
+#define IDR0_TTENDIAN_LE   (2 << IDR0_TTENDIAN_SHIFT)
+#define IDR0_TTENDIAN_BE   (3 << IDR0_TTENDIAN_SHIFT)
+#define IDR0_TTENDIAN_MIXED(0 << IDR0_TTENDIAN_SHIFT)
+#define IDR0_CD2L  (1 << 19)
+#define IDR0_VMID16(1 << 18)
+#define IDR0_PRI   (1 << 16)
+#define IDR0_SEV   (1 << 14)
+#define IDR0_MSI   (1 << 13)
+#define IDR0_ASID16(1 << 12)
+#define IDR0_ATS   (1 << 10)
+#define IDR0_HYP   (1 << 9)
+#define IDR0_COHACC(1 << 4)
+#define IDR0_TTF_SHIFT 2
+#define IDR0_TTF_MASK  0x3
+#define IDR0_TTF_AARCH64   (2 << IDR0_TTF_SHIFT)
+#define IDR0_TTF_AARCH32_64(3 << IDR0_TTF_SHIFT)
+#define IDR0_S1P   (1 << 1)
+#define IDR0_S2P   (1 << 0)
+
+#define ARM_SMMU_IDR1  0x4
+#define IDR1_TABLES_PRESET (1 << 30)
+#define IDR1_QUEUES_PRESET (1 << 29)
+#define IDR1_REL   (1 << 28)
+#define IDR1_CMDQ_SHIFT21
+#define IDR1_CMDQ_MASK 0x1f
+#define IDR1_EVTQ_SHIFT16
+#define IDR1_EVTQ_MASK 0x1f
+#define IDR1_PRIQ_SHIFT11
+#define IDR1_PRIQ_MASK 0x1f
+#define IDR1_SSID_SHIFT6
+#define IDR1_SSID_MASK 0x1f
+#define IDR1_SID_SHIFT 0
+#define IDR1_SID_MASK  0x3f
+
+#define ARM_SMMU_IDR5  0x14
+#define IDR5_STALL_MAX_SHIFT   16
+#define IDR5_STALL_MAX_MASK0x
+#define IDR5_GRAN64K   (1 << 6)
+#define IDR5_GRAN16K   (1 << 5)
+#define IDR5_GRAN4K(1 << 4)
+#define IDR5_OAS_SHIFT 0
+#define IDR5_OAS_MASK  0x7
+#define IDR5_OAS_32_BIT(0 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_36_BIT(1 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_40_BIT(2 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_42_BIT(3 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_44_BIT(4 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_48_BIT(5 << IDR5_OAS_SHIFT)
+
+#define ARM_SMMU_CR0   0x20
+#define CR0_CMDQEN (1 << 3)
+#define CR0_EVTQEN (1 << 2)
+#define CR0_PRIQEN (1 << 1)
+#define CR0_SMMUEN (1 << 0)
+
+#define ARM_SMMU_CR0ACK0x24
+
+#define ARM_SMMU_CR1   0x28
+#define CR1_SH_NSH

[Xen-devel] [PATCH 1/7] Port WARN_ON_ONCE() from Linux

Port WARN_ON_ONCE macro from Linux.

Signed-off-by: Sameer Goel 
Acked-by: Julien Grall 
---
 xen/arch/arm/xen.lds.S |  1 +
 xen/arch/x86/xen.lds.S |  1 +
 xen/include/xen/lib.h  | 13 +
 3 files changed, 15 insertions(+)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index b0390180b4..4dc7997cf0 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -87,6 +87,7 @@ SECTIONS
__end_schedulers_array = .;
*(.data.rel)
*(.data.rel.*)
+   *(.data.unlikely)
CONSTRUCTORS
   } :text
 
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 095298048f..353ca148ca 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -240,6 +240,7 @@ SECTIONS
*(.data)
*(.data.rel)
*(.data.rel.*)
+   *(.data.unlikely)
CONSTRUCTORS
   } :text
 
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 1d9771340c..697212a061 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -11,6 +11,19 @@
 #define BUG_ON(p)  do { if (unlikely(p)) BUG();  } while (0)
 #define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0)
 
+#define WARN_ON_ONCE(p) \
+({  \
+static bool __section(".data.unlikely") __warned; \
+int __ret_warn_once = !!(p);\
+\
+if ( unlikely(__ret_warn_once && !__warned) ) \
+{   \
+__warned = true;\
+WARN(); \
+}   \
+unlikely(__ret_warn_once);  \
+})
+
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
 /* Force a compilation error if condition is true */
 #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
-- 
2.14.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 3/7] passthrough/arm: Modify SMMU driver to use generic device definition

Modify the SMMU code to use generic device instead of dt_device_node for
functions that can be used for ACPI based systems too.

Signed-off-by: Sameer Goel 
Acked-by: Julien Grall 
---
 xen/drivers/passthrough/arm/smmu.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 45acb89380..ad956d5b8d 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -76,7 +76,7 @@ struct resource
 
 #define resource_size(res) (res)->size;
 
-#define platform_device dt_device_node
+#define platform_device device
 
 #define IORESOURCE_MEM 0
 #define IORESOURCE_IRQ 1
@@ -97,12 +97,12 @@ static struct resource *platform_get_resource(struct 
platform_device *pdev,
 
switch (type) {
case IORESOURCE_MEM:
-   ret = dt_device_get_address(pdev, num, , );
+   ret = dt_device_get_address(dev_to_dt(pdev), num, , 
);
 
return ((ret) ? NULL : );
 
case IORESOURCE_IRQ:
-   ret = platform_get_irq(pdev, num);
+   ret = platform_get_irq(dev_to_dt(pdev), num);
if (ret < 0)
return NULL;
 
@@ -2286,7 +2286,7 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
const struct of_device_id *of_id;
struct resource *res;
struct arm_smmu_device *smmu;
-   struct device *dev = >dev;
+   struct device *dev = pdev;
struct rb_node *node;
struct of_phandle_args masterspec;
int num_irqs, i, err;
@@ -2339,7 +2339,7 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
}
 
for (i = 0; i < num_irqs; ++i) {
-   int irq = platform_get_irq(pdev, i);
+   int irq = platform_get_irq(dev_to_dt(pdev), i);
 
if (irq < 0) {
dev_err(dev, "failed to get irq index %d\n", i);
@@ -2820,7 +2820,7 @@ static __init int arm_smmu_dt_init(struct dt_device_node 
*dev,
 */
dt_device_set_used_by(dev, DOMID_XEN);
 
-   rc = arm_smmu_device_dt_probe(dev);
+   rc = arm_smmu_device_dt_probe(dt_to_dev(dev));
if (rc)
return rc;
 
-- 
2.14.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 0/7] SMMUv3 driver

This patch set adds support for the SMMUv3 driver. This is a continuation on
a RFCv4.[1]
The IORT support came from [2]. This RFC has some conflicting defines that
have to be addressed by introducing the linux_compat.h header in IORT patch
set. In any case the SMMU changes apply on top of IORT patches.

List of changes:
- Addition of a linux_compat header.
- Addition of a common header for arm smmu defines.
- Rebase of the SMMUv3 driver to the driver in linux kernel 4.14 rc7.
- New config defines for ARM SMMU drivers.

[1] https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg01294.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg7.html
Sameer Goel (7):
  Port WARN_ON_ONCE() from Linux
  xen/bitops: Rename LOG_2 to ilog2
  passthrough/arm: Modify SMMU driver to use generic device definition
  Add verbatim copy of arm-smmu-v3.c from Linux
  xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver
  drivers/passthrough/arm: Refactor code for arm smmu drivers
  xen/smmu: Add a new config define for legacy SMMU

 xen/arch/arm/p2m.c |1 +
 xen/arch/arm/xen.lds.S |1 +
 xen/arch/x86/x86_64/asm-offsets.c  |2 +-
 xen/arch/x86/xen.lds.S |1 +
 xen/drivers/Kconfig|2 +
 xen/drivers/passthrough/arm/Kconfig|   14 +
 xen/drivers/passthrough/arm/Makefile   |3 +-
 xen/drivers/passthrough/arm/arm_smmu.h |  125 ++
 xen/drivers/passthrough/arm/smmu-v3.c  | 3625 
 xen/drivers/passthrough/arm/smmu.c |  114 +-
 xen/include/xen/bitops.h   |2 +-
 xen/include/xen/lib.h  |   13 +
 xen/include/xen/linux_compat.h |   84 +
 13 files changed, 3877 insertions(+), 110 deletions(-)
 create mode 100644 xen/drivers/passthrough/arm/Kconfig
 create mode 100644 xen/drivers/passthrough/arm/arm_smmu.h
 create mode 100644 xen/drivers/passthrough/arm/smmu-v3.c
 create mode 100644 xen/include/xen/linux_compat.h

-- 
2.14.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.7-testing test] 118664: regressions - FAIL

flight 118664 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118664/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-2 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 118337

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118337
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118337
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118337
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 118337
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118337
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118337
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118337
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118337
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 118337
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118337
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118337
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118337
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 118337
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  f50ea840b9a860927c7aca5fa64eb34e14f17164
baseline version:
 xen  fd884d61991cd0de588ae51728cd0602375dfa71

Last test of basis   118337  2018-01-25 17:43:30 Z   14 days
Testing same since   118664  2018-02-07 20:21:09 Z1 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Marc Zyngier

[Xen-devel] libxl - avoid calling block script

2018-02-08 Thread Marek Marczykowski-Górecki

Hi,

I'd like to avoid calling block script to speed up domain startup a
little (there may be multiple disks, all already being block devices).
Right now I have restored setting physical-device xenstore entry in
libxl (by reverting [1]), then applying the patch below (it's on 4.8).
This works well for my case, but maybe there is some option to have it
in vanilla Xen? Right now, this require explicit "script=block" to call
the script (for example to setup loop device).

Alternative idea I have is setting disk->script="block" early
(in libxl_device_disk_init()?), so default do not change, but it's still
possible to change it to NULL and avoid calling the script. The problem
is libxl_device_disk_init() is a generated and I don't see how it could
be modified... Any hints?

Yet another idea is having some specific value for disk->script,
that would avoid calling it, but I find this much less elegant solution.

[1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=e885362

From: Marek Marczykowski-Górecki 
Subject: [PATCH] libxl: do not call default block script

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/libxl/libxl.c   | 8 +---
 tools/libxl/libxl_linux.c | 5 ++---
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 11d94ff..74a2421 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2093,9 +2093,11 @@ static void device_disk_add(libxl__egc *egc, uint32_t 
domid,
 flexarray_append(back, "params");
 flexarray_append(back, dev);
 
-script = libxl__abs_path(gc, disk->script?: "block",
- libxl__xen_script_dir_path());
-flexarray_append_pair(back, "script", script);
+if (disk->script || disk->backend_domid != 
LIBXL_TOOLSTACK_DOMID) {
+script = libxl__abs_path(gc, disk->script?: "block",
+libxl__xen_script_dir_path());
+flexarray_append_pair(back, "script", script);
+}
 
 /* If the user did not supply a block script then we
  * write the physical-device node ourselves.
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 115332a..923a1d0 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -334,9 +334,8 @@ static int libxl__hotplug_disk(libxl__gc *gc, libxl__device 
*dev,
 script = libxl__xs_read(gc, XBT_NULL,
 GCSPRINTF("%s/%s", be_path, "script"));
 if (!script) {
-LOGEV(ERROR, errno, "unable to read script from %s", be_path);
-rc = ERROR_FAIL;
-goto error;
+LOG(INFO, "no script for %s", be_path);
+return 0;
 }
 
 *env = get_hotplug_env(gc, script, dev);
-- 
1.8.1.4


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 0/3] xen/arm: SMCCC fixes and PSCI clean-up

Acked-by and committed with a couple of grammar fixes in the commit
message.

Thanks,

Stefano

On Tue, 6 Feb 2018, Julien Grall wrote:
> Hi all,
> 
> This small patch series contains SMCCC fixes (see #2) and PSCI clean-up.
> 
> Cheers,
> 
> Julien Grall (3):
>   xen/arm: vpsci: Removing dummy MIGRATE and MIGRATE_INFO_UP_CPU
>   xen/arm: vsmc: Don't implement function ID that doesn't exist
>   xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c
> 
>  xen/arch/arm/vpsci.c | 156 
> +--
>  xen/arch/arm/vsmc.c  | 126 ---
>  xen/include/asm-arm/perfc_defn.h |   2 -
>  xen/include/asm-arm/psci.h   |  23 --
>  xen/include/asm-arm/smccc.h  |  20 -
>  xen/include/asm-arm/vpsci.h  |  42 +++
>  6 files changed, 207 insertions(+), 162 deletions(-)
>  create mode 100644 xen/include/asm-arm/vpsci.h
> 
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

flight 118704 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118704/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  5eaa17357bbef0ae4962daa369573b4dbdee7e83
baseline version:
 xen  2f92a0b22e3aa46b2785342d0aa5d54bc30d3be2

Last test of basis   118690  2018-02-08 17:01:12 Z0 days
Testing same since   118704  2018-02-08 22:22:54 Z0 days1 attempts


People who touched revisions under test:
  Andre Przywara 
  Julien Grall 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  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 :

To xenbits.xen.org:/home/xen/git/xen.git
   2f92a0b22e..5eaa17357b  5eaa17357bbef0ae4962daa369573b4dbdee7e83 -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] libxl: do not fail device removal if backend domain is gone

2018-02-08 Thread Marek Marczykowski-Górecki

Backend domain may be independently destroyed - there is no
synchronization of libxl structures (including /libxl tree) elsewhere.
Backend might also remove the device info from its backend xenstore
subtree on its own.
If such situation is detected, do not fail the removal, but finish the
cleanup of the frontend side.

This is just workaround, the real fix should watch when the device
backend is removed (including backend domain destruction) and remove
frontend at that time. And report such event to higher layer code, so
for example libvirt could synchronize its state.

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/libxl/libxl_device.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 1b796bd392..1f58a99a23 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -997,6 +997,13 @@ void libxl__initiate_device_generic_remove(libxl__egc *egc,
 goto out;
 }
 
+/* if state_path is empty, assume backend is gone (backend domain
+ * shutdown?), cleanup frontend only; rc=0 */
+if (!state) {
+LOG(WARN, "backend %s already removed, cleanup frontend only", 
be_path);
+goto out;
+}
+
 rc = libxl__xs_write_checked(gc, t, online_path, "0");
 if (rc)
 goto out;
-- 
2.13.6


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] libxl: allow libxl_domain_suspend to simply suspend a domain, without saving it

2018-02-08 Thread Marek Marczykowski-Górecki

When fd=-1, no savefile will be written, but the domain will still be
suspended (but not destroyed). The main reason for this functionality is
to suspend the host while some domains are running, potentially holding
PCI devices. This will give a chance to a driver in such a domain to
properly suspend device.

It would be better to have separate function for this, but in fact it
should be named libxl_domain_suspend, then the current one renamed to
libxl_domain_save. Since that would break API compatibility, keep it in
the same function.

Signed-off-by: Marek Marczykowski-Górecki 
Signed-off-by: Marcus of Wetware Labs 
---
 tools/libxl/libxl_domain.c | 53 +-
 1 file changed, 38 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 13b1c73d40..c95eaa30ca 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -486,6 +486,13 @@ static void domain_suspend_cb(libxl__egc *egc,
 
 }
 
+static void domain_suspend_empty_cb(libxl__egc *egc,
+  libxl__domain_suspend_state *dss, int rc)
+{
+STATE_AO_GC(dss->ao);
+libxl__ao_complete(egc,ao,rc);
+}
+
 int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
  const libxl_asyncop_how *ao_how)
 {
@@ -498,25 +505,41 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, 
int fd, int flags,
 goto out_err;
 }
 
-libxl__domain_save_state *dss;
-GCNEW(dss);
+if (fd >= 0) {
+libxl__domain_save_state *dss;
+GCNEW(dss);
 
-dss->ao = ao;
-dss->callback = domain_suspend_cb;
+dss->ao = ao;
+dss->callback = domain_suspend_cb;
 
-dss->domid = domid;
-dss->fd = fd;
-dss->type = type;
-dss->live = flags & LIBXL_SUSPEND_LIVE;
-dss->debug = flags & LIBXL_SUSPEND_DEBUG;
-dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_NONE;
+dss->domid = domid;
+dss->fd = fd;
+dss->type = type;
+dss->live = flags & LIBXL_SUSPEND_LIVE;
+dss->debug = flags & LIBXL_SUSPEND_DEBUG;
+dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_NONE;
 
-rc = libxl__fd_flags_modify_save(gc, dss->fd,
- ~(O_NONBLOCK|O_NDELAY), 0,
- >fdfl);
-if (rc < 0) goto out_err;
+rc = libxl__fd_flags_modify_save(gc, dss->fd,
+ ~(O_NONBLOCK|O_NDELAY), 0,
+ >fdfl);
+if (rc < 0) goto out_err;
+
+libxl__domain_save(egc, dss);
+} else {
+libxl__domain_suspend_state *dsps;
+GCNEW(dsps);
+dsps->ao = ao;
+dsps->domid = domid;
+dsps->type = type;
+dsps->guest_evtchn.port = -1;
+dsps->guest_evtchn_lockfd = -1;
+dsps->guest_responded = 0;
+rc = libxl__domain_suspend_init(egc, dsps, type);
+if (rc < 0) goto out_err;
+dsps->callback_common_done = domain_suspend_empty_cb;
+libxl__domain_suspend(egc, dsps);
+}
 
-libxl__domain_save(egc, dss);
 return AO_INPROGRESS;
 
  out_err:
-- 
2.13.6


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.8-testing test] 118663: regressions - FAIL

flight 118663 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118663/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 118465
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 118465

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118446
 test-xtf-amd64-amd64-3  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118465
 test-xtf-amd64-amd64-1  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118465
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118465
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118465
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 118465
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118465
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118465
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 118465
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 118465
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118465
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118465
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen

Re: [Xen-devel] [RFC 07/11] Add kernel helper functions


On 1/2/2018 2:28 AM, manish.ja...@linaro.org wrote:
> From: Manish Jaggi 
>
> Add kalloc kfree functions from linux kernel.
>
> Signed-off-by: Manish Jaggi 
> ---
>  xen/include/xen/kernel.h | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
> index 548b64da9f..78517f6caa 100644
> --- a/xen/include/xen/kernel.h
> +++ b/xen/include/xen/kernel.h
> @@ -7,6 +7,16 @@
>  
>  #include 
>  
You might want to swap 06 and 07. Once you do that I can remove the following 
defines from kernel.h
> +/* Xen: Define compatibility functions */
> +#define FW_BUG "[Firmware Bug]: "
> +#define pr_err(fmt, ...) printk(XENLOG_ERR fmt, ## __VA_ARGS__)
> +#define pr_warn(fmt, ...) printk(XENLOG_WARNING fmt, ## __VA_ARGS__)
> +
> +/* Alias to Xen allocation helpers */
> +#define kfree xfree
> +#define kmalloc(size, flags)_xmalloc(size, sizeof(void *))
> +#define kzalloc(size, flags)_xzalloc(size, sizeof(void *))
> +
>  /*
>   * min()/max() macros that also do
>   * strict type-checking.. See the


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 11/11] Add to_pci_dev macro



On 1/2/2018 2:28 AM, manish.ja...@linaro.org wrote:
> From: Manish Jaggi 
>
> This patch adds to_pci_dev macro
>
> Signed-off-by: Manish Jaggi 
> ---
>  xen/include/xen/pci.h | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
> index 43f21251a5..4c7ff4dd10 100644
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -92,8 +92,11 @@ struct pci_dev {
>  #define PT_FAULT_THRESHOLD 10
>  } fault;
>  u64 vf_rlen[6];
> +struct device dev;
>  };
>  
> +#define to_pci_dev(p) container_of(p, struct pci_dev, dev)
Remove the above function from smmu.c if it needs to be defined here.
> +#define pci_domain_nr(dev) dev->seg
>  #define for_each_pdev(domain, pdev) \
>  list_for_each_entry(pdev, &(domain->arch.pdev_list), domain_list)
>  


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 3/3] libxc: xc_dom_parse_elf_kernel: Return error for invalid kernel images

Commit 96edb111dd ("libxc: panic when trying to create a PVH guest
without kernel support") already improved the handling of non PVH
capable kernels. But xc_dom_parse_elf_kernel() still returned success on
invalid elf images and the domain build only failed later. Now the build
process will fail immediately on detecting the error.

Signed-off-by: Simon Gaiser 
---
 tools/libxc/xc_dom_elfloader.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index c936f92a66..26b2846365 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -64,7 +64,7 @@ static char *xc_dom_guest_type(struct xc_dom_image *dom,
 xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
  "%s: image not capable of booting inside a HVM container",
  __FUNCTION__);
-return "xen-3.0-unknown";
+return NULL;
 }
 
 switch ( machine )
@@ -86,7 +86,10 @@ static char *xc_dom_guest_type(struct xc_dom_image *dom,
 case EM_X86_64:
 return "xen-3.0-x86_64";
 default:
-return "xen-3.0-unknown";
+xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
+ "%s: unkown image type %"PRIu64,
+ __FUNCTION__, machine);
+return NULL;
 }
 }
 
@@ -192,6 +195,8 @@ static elf_negerrnoval xc_dom_parse_elf_kernel(struct 
xc_dom_image *dom)
 dom->kernel_seg.vend   = dom->parms.virt_kend;
 
 dom->guest_type = xc_dom_guest_type(dom, elf);
+if ( dom->guest_type == NULL )
+return -EINVAL;
 DOMPRINTF("%s: %s: 0x%" PRIx64 " -> 0x%" PRIx64 "",
   __FUNCTION__, dom->guest_type,
   dom->kernel_seg.vstart, dom->kernel_seg.vend);
-- 
2.15.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 2/3] libxl: Improve logging in libxl__build_dom()

xc_dom_parse_image() does not set errno (at least in many code paths).
So LOGE() is not useful.

Signed-off-by: Simon Gaiser 
---
 tools/libxl/libxl_dom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ef834e652d..52b6137943 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -715,7 +715,7 @@ static int libxl__build_dom(libxl__gc *gc, uint32_t domid,
 }
 #endif
 if ( (ret = xc_dom_parse_image(dom)) != 0 ) {
-LOGE(ERROR, "xc_dom_parse_image failed");
+LOG(ERROR, "xc_dom_parse_image failed");
 goto out;
 }
 if ( (ret = libxl__arch_domain_init_hw_description(gc, info, state, dom)) 
!= 0 ) {
-- 
2.15.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 1/3] libxc: Cleanup xc_dom_parse_elf_kernel()'s return value

xc_dom_loader.parser() should return elf_negerrnoval.

Signed-off-by: Simon Gaiser 
---
 tools/libxc/xc_dom_elfloader.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 568d7f370c..c936f92a66 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -140,14 +140,10 @@ static elf_negerrnoval xc_dom_probe_elf_kernel(struct 
xc_dom_image *dom)
 return 0;
 }
 
-static elf_errorstatus xc_dom_parse_elf_kernel(struct xc_dom_image *dom)
-/*
- * This function sometimes returns -1 for error and sometimes
- * an errno value.  ?!?!
- */
+static elf_negerrnoval xc_dom_parse_elf_kernel(struct xc_dom_image *dom)
 {
 struct elf_binary *elf;
-elf_errorstatus rc;
+elf_negerrnoval rc;
 
 rc = check_elf_kernel(dom, 1);
 if ( rc != 0 )
@@ -155,9 +151,9 @@ static elf_errorstatus xc_dom_parse_elf_kernel(struct 
xc_dom_image *dom)
 
 elf = xc_dom_malloc(dom, sizeof(*elf));
 if ( elf == NULL )
-return -1;
+return -ENOMEM;
 dom->private_loader = elf;
-rc = elf_init(elf, dom->kernel_blob, dom->kernel_size);
+rc = elf_init(elf, dom->kernel_blob, dom->kernel_size) != 0 ? -EINVAL : 0;
 xc_elf_set_logfile(dom->xch, elf, 1);
 if ( rc != 0 )
 {
@@ -177,8 +173,9 @@ static elf_errorstatus xc_dom_parse_elf_kernel(struct 
xc_dom_image *dom)
 
 /* parse binary and get xen meta info */
 elf_parse_binary(elf);
-if ( (rc = elf_xen_parse(elf, >parms)) != 0 )
+if ( elf_xen_parse(elf, >parms) != 0 )
 {
+rc = -EINVAL;
 goto out;
 }
 
-- 
2.15.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] libx[lc]: Improve error reporting for invalid kernel images

Hi,

this series cleans up the error reporting in case a invalid kernel image
is supplied. For example if the user tries to boot a pre 4.11 Linux in
PVH mode.

Commit 96edb111dd ("libxc: panic when trying to create a PVH guest
without kernel support") already improved the situation:

  xc: error: panic: xc_dom_elfloader.c:66: xc_dom_guest_type: image not capable 
of booting inside a HVM container: Invalid kernel
  xc: error: panic: xc_dom_core.c:734: xc_dom_set_arch_hooks: not found (type 
xen-3.0-unknown): Invalid kernel
  xc: error: panic: xc_dom_core.c:936: xc_dom_mem_init: arch hooks not set: 
Internal error
  libxl: error: libxl_dom.c:729:libxl__build_dom: xc_dom_mem_init failed: No 
such file or directory
  libxl: error: libxl_create.c:1246:domcreate_rebuild_done: Domain 3:cannot 
(re-)build domain: -3

But you still see that the domain build don't fails immediately in
xc_dom_parse_elf_kernel() but only later in xc_dom_set_arch_hooks().
After fixing this there was still an unrelated errno string logged.

With this series the error reporting is cleaned up:

  xc: error: panic: xc_dom_elfloader.c:66: xc_dom_guest_type: image not capable 
of booting inside a HVM container: Invalid kernel
  libxl: error: libxl_dom.c:718:libxl__build_dom: xc_dom_parse_image failed
  libxl: error: libxl_create.c:1246:domcreate_rebuild_done: Domain 4:cannot 
(re-)build domain: -3

For some previous discussion see [1].

Simon

[1]: https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01675.html


Simon Gaiser (3):
  libxc: Cleanup xc_dom_parse_elf_kernel()'s return value
  libxl: Improve logging in libxl__build_dom()
  libxc: xc_dom_parse_elf_kernel: Return error for invalid kernel images

 tools/libxc/xc_dom_elfloader.c | 24 +---
 tools/libxl/libxl_dom.c|  2 +-
 2 files changed, 14 insertions(+), 12 deletions(-)

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [v2, 2/2] arm64: Implement branch predictor hardening for Falkor (fwd)

Hi Shanker,

it looks like that Xen might also need MIDR_QCOM_FALKOR_V1 and
MIDR_QCOM_FALKOR added to xen/arch/arm/cpuerrata.c:arm_errata with the
ARM_HARDEN_BRANCH_PREDICTOR capability set?

Cheers,

Stefano


From patchwork Mon Jan  8 21:31:08 2018
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [v2,2/2] arm64: Implement branch predictor hardening for Falkor
From: Shanker Donthineni 
X-Patchwork-Id: 10150623
Message-Id: <1515447068-20977-2-git-send-email-shank...@codeaurora.org>
To: Marc Zyngier ,
 Christoffer Dall ,
 linux-kernel ,
 linux-arm-kernel ,
 kvmarm 
Cc: Thomas Speier ,
 Vikram Sethi ,
 Sean Campbell , 
 Catalin Marinas ,
 Will Deacon , 
 James Morse , Paolo Bonzini ,
 Shanker Donthineni 
Date: Mon,  8 Jan 2018 15:31:08 -0600

Falkor is susceptible to branch predictor aliasing and can
theoretically be attacked by malicious code. This patch
implements a mitigation for these attacks, preventing any
malicious entries from affecting other victim contexts.

Signed-off-by: Shanker Donthineni 
---
Changes since v1:
  Corrected typo to fix the compilation errors if HARDEN_BRANCH_PREDICTOR=n

This patch requires FALKOR MIDR which is available in upstream v4.15-rc7
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64?h=v4.15-rc7=c622cc013cece073722592cff1ac6643a33b1622
 ans also
  attached this v2 patch series.

 arch/arm64/include/asm/cpucaps.h |  3 ++-
 arch/arm64/include/asm/kvm_asm.h |  2 ++
 arch/arm64/kernel/bpi.S  |  8 +++
 arch/arm64/kernel/cpu_errata.c   | 49 ++--
 arch/arm64/kvm/hyp/entry.S   | 12 ++
 arch/arm64/kvm/hyp/switch.c  | 10 
 6 files changed, 81 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 51616e7..7049b48 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -43,7 +43,8 @@
 #define ARM64_SVE  22
 #define ARM64_UNMAP_KERNEL_AT_EL0  23
 #define ARM64_HARDEN_BRANCH_PREDICTOR  24
+#define ARM64_HARDEN_BP_POST_GUEST_EXIT25
 
-#define ARM64_NCAPS25
+#define ARM64_NCAPS26
 
 #endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index ab4d0a9..24961b7 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -68,6 +68,8 @@
 
 extern u32 __init_stage2_translation(void);
 
+extern void __qcom_hyp_sanitize_btac_predictors(void);
+
 #endif
 
 #endif /* __ARM_KVM_ASM_H__ */
diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
index 2b10d52..44ffcda 100644
--- a/arch/arm64/kernel/bpi.S
+++ b/arch/arm64/kernel/bpi.S
@@ -77,3 +77,11 @@ ENTRY(__psci_hyp_bp_inval_start)
ldp x2, x3, [sp], #16
ldp x0, x1, [sp], #16
 ENTRY(__psci_hyp_bp_inval_end)
+
+ENTRY(__qcom_hyp_sanitize_link_stack_start)
+   stp x29, x30, [sp, #-16]!
+   .rept   16
+   bl  . + 4
+   .endr
+   ldp x29, x30, [sp], #16
+ENTRY(__qcom_hyp_sanitize_link_stack_end)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index cb0fb37..9ee9d2e 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -54,6 +54,8 @@ static int cpu_enable_trap_ctr_access(void *__unused)
 
 #ifdef CONFIG_KVM
 extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
+extern char __qcom_hyp_sanitize_link_stack_start[];
+extern char __qcom_hyp_sanitize_link_stack_end[];
 
 static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
const char *hyp_vecs_end)
@@ -96,8 +98,10 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
spin_unlock(_lock);
 }
 #else
-#define __psci_hyp_bp_inval_start  NULL
-#define __psci_hyp_bp_inval_endNULL
+#define __psci_hyp_bp_inval_start  NULL
+#define __psci_hyp_bp_inval_endNULL
+#define __qcom_hyp_sanitize_link_stack_start   NULL
+#define __qcom_hyp_sanitize_link_stack_end NULL
 
 static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
  const char *hyp_vecs_start,
@@ -138,6 +142,29 @@ static int enable_psci_bp_hardening(void *data)
 
return 0;
 }
+
+static void qcom_link_stack_sanitization(void)
+{
+   u64 tmp;
+
+   asm volatile("mov   %0, x30 \n"
+".rept

[Xen-devel] [PATCH v2 10/15] xen/arm: smccc: Implement SMCCC v1.1 inline primitive

One of the major improvement of SMCCC v1.1 is that it only clobbers the
first 4 registers, both on 32 and 64bit. This means that it becomes very
easy to provide an inline version of the SMC call primitive, and avoid
performing a function call to stash the registers that woudl otherwise
be clobbered by SMCCC v1.0.

This patch has been adapted to Xen from Linux commit f2d3b2e8759a. The
changes mades are:
- Using Xen coding style
- Remove HVC as not used by Xen
- Add arm_smccc_res structure

 Reviewed-by: Robin Murphy 
 Tested-by: Ard Biesheuvel 
 Signed-off-by: Marc Zyngier 
 Signed-off-by: Catalin Marinas 

Signed-off-by: Julien Grall 

---

Note that the patch is in arm64/for-next/core and should be merged
in master soon.

Changes in v2:
- Patch added
---
 xen/include/asm-arm/smccc.h | 119 
 1 file changed, 119 insertions(+)

diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index bc067892c7..154772b728 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -78,6 +78,125 @@ static inline uint32_t smccc_get_owner(register_t funcid)
 return (funcid >> ARM_SMCCC_OWNER_SHIFT) & ARM_SMCCC_OWNER_MASK;
 }
 
+/*
+ * struct arm_smccc_res - Result from SMC call
+ * @a0 - @a3 result values from registers 0 to 3
+ */
+struct arm_smccc_res {
+unsigned long a0;
+unsigned long a1;
+unsigned long a2;
+unsigned long a3;
+};
+
+/* SMCCC v1.1 implementation madness follows */
+#define ___count_args(_0, _1, _2, _3, _4, _5, _6, _7, _8, x, ...) x
+
+#define __count_args(...)   \
+___count_args(__VA_ARGS__, 7, 6, 5, 4, 3, 2, 1, 0)
+
+#define __constraint_write_0\
+"+r" (r0), "=" (r1), "=" (r2), "=" (r3)
+#define __constraint_write_1\
+"+r" (r0), "+r" (r1), "=" (r2), "=" (r3)
+#define __constraint_write_2\
+"+r" (r0), "+r" (r1), "+r" (r2), "=" (r3)
+#define __constraint_write_3\
+"+r" (r0), "+r" (r1), "+r" (r2), "+r" (r3)
+#define __constraint_write_4__constraint_write_3
+#define __constraint_write_5__constraint_write_4
+#define __constraint_write_6__constraint_write_5
+#define __constraint_write_7__constraint_write_6
+
+#define __constraint_read_0
+#define __constraint_read_1
+#define __constraint_read_2
+#define __constraint_read_3
+#define __constraint_read_4 "r" (r4)
+#define __constraint_read_5 __constraint_read_4, "r" (r5)
+#define __constraint_read_6 __constraint_read_5, "r" (r6)
+#define __constraint_read_7 __constraint_read_6, "r" (r7)
+
+#define __declare_arg_0(a0, res)\
+struct arm_smccc_res*___res = res;  \
+register uin32_tr0 asm("r0") = a0;  \
+register unsigned long  r1 asm("r1");   \
+register unsigned long  r2 asm("r2");   \
+register unsigned long  r3 asm("r3")
+
+#define __declare_arg_1(a0, a1, res)\
+struct arm_smccc_res*___res = res;  \
+register uint32_t   r0 asm("r0") = a0;  \
+register typeof(a1) r1 asm("r1") = a1;  \
+register unsigned long  r2 asm("r2");   \
+register unsigned long  r3 asm("r3")
+
+#define __declare_arg_2(a0, a1, a2, res)\
+struct arm_smccc_res*___res = res; \
+register u32r0 asm("r0") = a0;  \
+register typeof(a1) r1 asm("r1") = a1;  \
+register typeof(a2) r2 asm("r2") = a2;  \
+register unsigned long  r3 asm("r3")
+
+#define __declare_arg_3(a0, a1, a2, a3, res)\
+struct arm_smccc_res*___res = res;  \
+register u32r0 asm("r0") = a0;  \
+register typeof(a1) r1 asm("r1") = a1;  \
+register typeof(a2) r2 asm("r2") = a2;  \
+register typeof(a3) r3 asm("r3") = a3
+
+#define __declare_arg_4(a0, a1, a2, a3, a4, res)\
+__declare_arg_3(a0, a1, a2, a3, res);   \
+register typeof(a4) r4 asm("r4") = a4
+
+#define __declare_arg_5(a0, a1, a2, a3, a4, a5, res)\
+__declare_arg_4(a0, a1, a2, a3, a4, res);   \
+register typeof(a5) r5 asm("r5") = a5
+
+#define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res)\
+__declare_arg_5(a0, a1, a2, a3, a4, a5, res);   \
+register typeof(a6) r6 asm("r6") = a6
+
+#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res)\
+__declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res);   \
+register typeof(a7) r7 asm("r7") = a7
+
+#define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__)
+#define __declare_args(count, ...)  ___declare_args(count, __VA_ARGS__)
+
+#define

[Xen-devel] [PATCH v2 01/15] xen/arm: psci: Rework the PSCI definitions

Some PSCI functions are only available in the 32-bit version. After
recent changes, Xen always needs to know whether the call was made using
32-bit id or 64-bit id. So we don't emulate reserved one.

With the current naming scheme, it is not easy to know which call
supports 32-bit and 64-bit id. So rework the definitions to encode the
version in the name. From now the functions will be named PSCI_0_2_FNxx
where xx is 32 or 64.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
Changes in v2:
- Add Volodymyr's reviewed-by
---
 xen/arch/arm/platforms/seattle.c |  4 ++--
 xen/arch/arm/psci.c  | 10 +-
 xen/arch/arm/vpsci.c | 22 +++---
 xen/include/asm-arm/psci.h   | 37 +
 4 files changed, 39 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/platforms/seattle.c b/xen/arch/arm/platforms/seattle.c
index 22c062293f..893cc17972 100644
--- a/xen/arch/arm/platforms/seattle.c
+++ b/xen/arch/arm/platforms/seattle.c
@@ -33,12 +33,12 @@ static const char * const seattle_dt_compat[] __initconst =
  */
 static void seattle_system_reset(void)
 {
-call_smc(PSCI_0_2_FN32(SYSTEM_RESET), 0, 0, 0);
+call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0);
 }
 
 static void seattle_system_off(void)
 {
-call_smc(PSCI_0_2_FN32(SYSTEM_OFF), 0, 0, 0);
+call_smc(PSCI_0_2_FN32_SYSTEM_OFF, 0, 0, 0);
 }
 
 PLATFORM_START(seattle, "SEATTLE")
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 1508a3be3a..5dda35cd7c 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -31,9 +31,9 @@
  * (native-width) function ID.
  */
 #ifdef CONFIG_ARM_64
-#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN64(name)
+#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN64_##name
 #else
-#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN32(name)
+#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN32_##name
 #endif
 
 uint32_t psci_ver;
@@ -48,13 +48,13 @@ int call_psci_cpu_on(int cpu)
 void call_psci_system_off(void)
 {
 if ( psci_ver > PSCI_VERSION(0, 1) )
-call_smc(PSCI_0_2_FN32(SYSTEM_OFF), 0, 0, 0);
+call_smc(PSCI_0_2_FN32_SYSTEM_OFF, 0, 0, 0);
 }
 
 void call_psci_system_reset(void)
 {
 if ( psci_ver > PSCI_VERSION(0, 1) )
-call_smc(PSCI_0_2_FN32(SYSTEM_RESET), 0, 0, 0);
+call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0);
 }
 
 int __init psci_is_smc_method(const struct dt_device_node *psci)
@@ -144,7 +144,7 @@ int __init psci_init_0_2(void)
 }
 }
 
-psci_ver = call_smc(PSCI_0_2_FN32(PSCI_VERSION), 0, 0, 0);
+psci_ver = call_smc(PSCI_0_2_FN32_PSCI_VERSION, 0, 0, 0);
 
 /* For the moment, we only support PSCI 0.2 and PSCI 1.x */
 if ( psci_ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(psci_ver) != 1 )
diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 03fd4eb5b5..6ab8ab64d0 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -243,35 +243,35 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, 
uint32_t fid)
  */
 switch ( fid )
 {
-case PSCI_0_2_FN32(PSCI_VERSION):
+case PSCI_0_2_FN32_PSCI_VERSION:
 perfc_incr(vpsci_version);
 PSCI_SET_RESULT(regs, do_psci_0_2_version());
 return true;
 
-case PSCI_0_2_FN32(CPU_OFF):
+case PSCI_0_2_FN32_CPU_OFF:
 perfc_incr(vpsci_cpu_off);
 PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
 return true;
 
-case PSCI_0_2_FN32(MIGRATE_INFO_TYPE):
+case PSCI_0_2_FN32_MIGRATE_INFO_TYPE:
 perfc_incr(vpsci_migrate_info_type);
 PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
 return true;
 
-case PSCI_0_2_FN32(SYSTEM_OFF):
+case PSCI_0_2_FN32_SYSTEM_OFF:
 perfc_incr(vpsci_system_off);
 do_psci_0_2_system_off();
 PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 return true;
 
-case PSCI_0_2_FN32(SYSTEM_RESET):
+case PSCI_0_2_FN32_SYSTEM_RESET:
 perfc_incr(vpsci_system_reset);
 do_psci_0_2_system_reset();
 PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 return true;
 
-case PSCI_0_2_FN32(CPU_ON):
-case PSCI_0_2_FN64(CPU_ON):
+case PSCI_0_2_FN32_CPU_ON:
+case PSCI_0_2_FN64_CPU_ON:
 {
 register_t vcpuid = PSCI_ARG(regs, 1);
 register_t epoint = PSCI_ARG(regs, 2);
@@ -282,8 +282,8 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t 
fid)
 return true;
 }
 
-case PSCI_0_2_FN32(CPU_SUSPEND):
-case PSCI_0_2_FN64(CPU_SUSPEND):
+case PSCI_0_2_FN32_CPU_SUSPEND:
+case PSCI_0_2_FN64_CPU_SUSPEND:
 {
 uint32_t pstate = PSCI_ARG32(regs, 1);
 register_t epoint = PSCI_ARG(regs, 2);
@@ -294,8 +294,8 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t 
fid)
 return true;
 }
 
-case PSCI_0_2_FN32(AFFINITY_INFO):
-case PSCI_0_2_FN64(AFFINITY_INFO):
+case

[Xen-devel] [PATCH v2 06/15] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for
hardening the branch predictor. So we want the handling to be as fast as
possible.

As the mitigation is applied on every guest exit, we can check for the
call before saving all the context and return very early.

For now, only provide a fast path for HVC64 call. Because the code rely
on 2 registers, x0 and x1 are saved in advance.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
guest_sync only handle 64-bit guest, so I have only implemented the
64-bit side for now. We can discuss whether it is useful to
implement it for 32-bit guests.

We could also consider to implement the fast path for SMC64,
althought a guest should always use HVC.

Changes in v2:
- Add Volodymyr's reviewed-by
---
 xen/arch/arm/arm64/entry.S  | 56 +++--
 xen/include/asm-arm/processor.h |  2 ++
 2 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index 6d99e46f0f..67f96d518f 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -90,8 +91,12 @@ lr  .reqx30 /* link register */
 .endm
 /*
  * Save state on entry to hypervisor, restore on exit
+ *
+ * save_x0_x1: Does the macro needs to save x0/x1 (default 1). If 0,
+ * we rely on the on x0/x1 to have been saved at the correct position on
+ * the stack before.
  */
-.macro  entry, hyp, compat
+.macro  entry, hyp, compat, save_x0_x1=1
 sub sp, sp, #(UREGS_SPSR_el1 - UREGS_LR) /* CPSR, PC, SP, LR */
 pushx28, x29
 pushx26, x27
@@ -107,7 +112,16 @@ lr  .reqx30 /* link register */
 pushx6, x7
 pushx4, x5
 pushx2, x3
+/*
+ * The caller may already have saved x0/x1 on the stack at the
+ * correct address and corrupt them with another value. Only
+ * save them if save_x0_x1 == 1.
+ */
+.if \save_x0_x1 == 1
 pushx0, x1
+.else
+sub sp, sp, #16
+.endif
 
 .if \hyp == 1/* Hypervisor mode */
 
@@ -200,7 +214,45 @@ hyp_irq:
 exithyp=1
 
 guest_sync:
-entry   hyp=0, compat=0
+/*
+ * Save x0, x1 in advance
+ */
+stp x0, x1, [sp, #-(UREGS_kernel_sizeof - UREGS_X0)]
+
+/*
+ * x1 is used because x0 may contain the function identifier.
+ * This avoids to restore x0 from the stack.
+ */
+mrs x1, esr_el2
+lsr x1, x1, #HSR_EC_SHIFT   /* x1 = ESR_EL2.EC */
+cmp x1, #HSR_EC_HVC64
+b.ne1f  /* Not a HVC skip fastpath. */
+
+mrs x1, esr_el2
+and x1, x1, #0x /* Check the immediate [0:16] 
*/
+cbnzx1, 1f  /* should be 0 for HVC #0 */
+
+/*
+ * Fastest path possible for ARM_SMCCC_ARCH_WORKAROUND_1.
+ * The workaround has already been applied on the exception
+ * entry from the guest, so let's quickly get back to the guest.
+ */
+eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+cbnzw0, 1f
+
+/*
+ * Clobber both x0 and x1 to prevent leakage. Note that thanks
+ * the eor, x0 = 0.
+ */
+mov x1, x0
+eret
+
+1:
+/*
+ * x0/x1 may have been scratch by the fast path above, so avoid
+ * to save them.
+ */
+entry   hyp=0, compat=0, save_x0_x1=0
 /*
  * The vSError will be checked while SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT
  * is not set. If a vSError took place, the initial exception will be
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index c0f79d0093..222a02dd99 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -306,6 +306,8 @@
 #define HDCR_TPM(_AC(1,U)<<6)   /* Trap Performance Monitors 
accesses */
 #define HDCR_TPMCR  (_AC(1,U)<<5)   /* Trap PMCR accesses */
 
+#define HSR_EC_SHIFT26
+
 #define HSR_EC_UNKNOWN  0x00
 #define HSR_EC_WFI_WFE  0x01
 #define HSR_EC_CP15_32  0x03
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 07/15] xen/arm64: Print a per-CPU message with the BP hardening method used

This will make easier to know whether BP hardening has been enabled for
a CPU and which method is used.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Patch added
---
 xen/arch/arm/cpuerrata.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 9c7458ef06..6704648b26 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -79,7 +79,8 @@ static bool copy_hyp_vect_bpi(unsigned int slot, const char 
*hyp_vec_start,
 static bool __maybe_unused
 install_bp_hardening_vec(const struct arm_cpu_capabilities *entry,
  const char *hyp_vec_start,
- const char *hyp_vec_end)
+ const char *hyp_vec_end,
+ const char *desc)
 {
 static int last_slot = -1;
 static DEFINE_SPINLOCK(bp_lock);
@@ -94,6 +95,9 @@ install_bp_hardening_vec(const struct arm_cpu_capabilities 
*entry,
 if ( !entry->matches(entry) )
 return true;
 
+printk(XENLOG_INFO "CPU%u will %s on exception entry\n",
+   smp_processor_id(), desc);
+
 /*
  * No need to install hardened vector when the processor has
  * ID_AA64PRF0_EL1.CSV2 set.
@@ -157,7 +161,8 @@ static int enable_psci_bp_hardening(void *data)
  */
 if ( psci_ver >= PSCI_VERSION(0, 2) )
 ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
-   __psci_hyp_bp_inval_end);
+   __psci_hyp_bp_inval_end,
+   "call PSCI get version");
 else if ( !warned )
 {
 ASSERT(system_state < SYS_STATE_active);
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 00/15] xen/arm: PSCI 1.1 and SMCCC-1.1 support and XSA-254 variant 2 update

Hi all,

Arm has recently published a SMC Calling Convention (SMCCC)
specification update [1] that provides an optimised calling convention
and optional, discoverable support for mitigating CVE-2017-5715 (XSA-254
variant 2). ARM Trusted Firmware (ATF) has already gained such an
implementation[2].

This series addresses a few things:

- It provides a Xen implementation of PSCI v1.0, which is a
prerequisite for being able to discover SMCCC v1.1.
- It allows Xen to advertise SMCCC v1.1
- It implements guest support for the ARM_WORKAROUND_1 function that is used
to mitigate CVE-2017-5715 (if such mitigation is available on the
hypervisor).
- It adds Xen support for branch predictor hardening via
ARM_WORKAROUND_1 if the firmware supports it.

This method is intended to fully replace the initial PSCI_GET_VERSION
approach. Although PSCI_GET_VERSION still works, it has an obvious
overhead and is called on some of the hottest paths. We expect
ARCH_WORKAROUND_1 to be much faster.

This series is based on the "xen/arm: SMCCC fixes and PSCI clean-up" one [3].

Cheers,

[1] https://developer.arm.com/support/security-update/downloads

[2] https://github.com/ARM-software/arm-trusted-firmware/pull/1240

[3] https://lists.xen.org/archives/html/xen-devel/2018-02/msg00447.html

Julien Grall (15):
  xen/arm: psci: Rework the PSCI definitions
  xen/arm: vpsci: Add support for PSCI 1.1
  xen/arm: vsmc: Implement SMCCC 1.1
  xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support
  xen/arm: Adapt smccc.h to be able to use it in assembly code
  xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1
  xen/arm64: Print a per-CPU message with the BP hardening method used
  xen/arm: smccc: Add macros SMCCC_VERSION, SMCCC_VERSION_{MINOR, MAJOR}
  xen/arm: psci: Detect SMCCC version
  xen/arm: smccc: Implement SMCCC v1.1 inline primitive
  xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support
  xen/arm64: Kill PSCI_GET_VERSION as a variant-2 workaround
  xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu
  xen/arm: psci: Consolidate PSCI version print
  xen/arm: psci: Prefix with static any functions not exported

 tools/libxl/libxl_arm.c  |   3 +-
 xen/arch/arm/arm64/bpi.S |  35 +++-
 xen/arch/arm/arm64/entry.S   |  56 -
 xen/arch/arm/cpuerrata.c |  55 +
 xen/arch/arm/domain_build.c  |   1 +
 xen/arch/arm/platforms/seattle.c |   4 +-
 xen/arch/arm/psci.c  |  58 +
 xen/arch/arm/vpsci.c |  90 +++-
 xen/arch/arm/vsmc.c  |  41 +
 xen/include/asm-arm/perfc_defn.h |   1 +
 xen/include/asm-arm/processor.h  |   2 +
 xen/include/asm-arm/psci.h   |  38 +
 xen/include/asm-arm/smccc.h  | 174 +--
 xen/include/asm-arm/vpsci.h  |   2 +-
 14 files changed, 453 insertions(+), 107 deletions(-)

-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 03/15] xen/arm: vsmc: Implement SMCCC 1.1

The new SMC Calling Convention (v1.1) allows for a reduced overhead when
calling into the firmware, and provides a new feature discovery
mechanism. See "Firmware interfaces for mitigating CVE-2017-5715"
ARM DEN 00070A.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Add a humand readable name for the specification
---
 xen/arch/arm/vpsci.c|  1 +
 xen/arch/arm/vsmc.c | 23 +++
 xen/include/asm-arm/smccc.h | 15 +++
 3 files changed, 39 insertions(+)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index e82b62db1a..19ee7caeb4 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -212,6 +212,7 @@ static int32_t do_psci_1_0_features(uint32_t psci_func_id)
 case PSCI_0_2_FN32_SYSTEM_OFF:
 case PSCI_0_2_FN32_SYSTEM_RESET:
 case PSCI_1_0_FN32_PSCI_FEATURES:
+case ARM_SMCCC_VERSION_FID:
 return 0;
 default:
 return PSCI_NOT_SUPPORTED;
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 3d3bd95fee..a708aa5e81 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -81,6 +81,26 @@ static bool fill_function_call_count(struct cpu_user_regs 
*regs, uint32_t cnt)
 return true;
 }
 
+/* SMCCC interface for ARM Architecture */
+static bool handle_arch(struct cpu_user_regs *regs)
+{
+uint32_t fid = (uint32_t)get_user_reg(regs, 0);
+
+switch ( fid )
+{
+case ARM_SMCCC_VERSION_FID:
+set_user_reg(regs, 0, ARM_SMCCC_VERSION_1_1);
+return true;
+
+case ARM_SMCCC_ARCH_FEATURES_FID:
+/* Nothing supported yet */
+set_user_reg(regs, 0, -1);
+return true;
+}
+
+return false;
+}
+
 /* SMCCC interface for hypervisor. Tell about itself. */
 static bool handle_hypervisor(struct cpu_user_regs *regs)
 {
@@ -188,6 +208,9 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
 {
 switch ( smccc_get_owner(funcid) )
 {
+case ARM_SMCCC_OWNER_ARCH:
+handled = handle_arch(regs);
+break;
 case ARM_SMCCC_OWNER_HYPERVISOR:
 handled = handle_hypervisor(regs);
 break;
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 62b3a8cdf5..431389c118 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -16,6 +16,9 @@
 #ifndef __ASM_ARM_SMCCC_H__
 #define __ASM_ARM_SMCCC_H__
 
+#define ARM_SMCCC_VERSION_1_0   0x1
+#define ARM_SMCCC_VERSION_1_1   0x10001
+
 /*
  * This file provides common defines for ARM SMC Calling Convention as
  * specified in
@@ -100,6 +103,18 @@ static inline uint32_t smccc_get_owner(register_t funcid)
ARM_SMCCC_OWNER_##owner, \
0xFF03)
 
+#define ARM_SMCCC_VERSION_FID   \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x0) \
+
+#define ARM_SMCCC_ARCH_FEATURES_FID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x1)
+
 /* Only one error code defined in SMCCC */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
 
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 09/15] xen/arm: psci: Detect SMCCC version

PSCI 1.0 and later allows the SMCCC version to be (indirectly) probed
via PSCI_FEATURES. If the PSCI_FEATURES does not exist (PSCI 0.2 or
earlier) and the function return an error, then we considered SMCCC 1.0
is implemented.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Patch added
---
 xen/arch/arm/psci.c | 34 +-
 xen/include/asm-arm/smccc.h |  5 -
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 5dda35cd7c..bc7b2260e8 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -37,6 +37,7 @@
 #endif
 
 uint32_t psci_ver;
+uint32_t smccc_ver;
 
 static uint32_t psci_cpu_on_nr;
 
@@ -57,6 +58,14 @@ void call_psci_system_reset(void)
 call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0);
 }
 
+static int __init psci_features(uint32_t psci_func_id)
+{
+if ( psci_ver < PSCI_VERSION(1, 0) )
+return PSCI_NOT_SUPPORTED;
+
+return call_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id, 0, 0);
+}
+
 int __init psci_is_smc_method(const struct dt_device_node *psci)
 {
 int ret;
@@ -82,6 +91,24 @@ int __init psci_is_smc_method(const struct dt_device_node 
*psci)
 return 0;
 }
 
+static void __init psci_init_smccc(void)
+{
+/* PSCI is using at least SMCC 1.0 calling convention. */
+smccc_ver = ARM_SMCCC_VERSION_1_0;
+
+if ( psci_features(ARM_SMCCC_VERSION_FID) != PSCI_NOT_SUPPORTED )
+{
+uint32_t ret;
+
+ret = call_smc(ARM_SMCCC_VERSION_FID, 0, 0, 0);
+if ( ret != ARM_SMCCC_NOT_SUPPORTED )
+smccc_ver = ret;
+}
+
+printk(XENLOG_INFO "Using SMC Calling Convention v%u.%u\n",
+   SMCCC_VERSION_MAJOR(smccc_ver), SMCCC_VERSION_MINOR(smccc_ver));
+}
+
 int __init psci_init_0_1(void)
 {
 int ret;
@@ -173,7 +200,12 @@ int __init psci_init(void)
 if ( ret )
 ret = psci_init_0_1();
 
-return ret;
+if ( ret )
+return ret;
+
+psci_init_smccc();
+
+return 0;
 }
 
 /*
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index caa2c9cc1b..bc067892c7 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -52,6 +52,8 @@
 
 #ifndef __ASSEMBLY__
 
+extern uint32_t smccc_ver;
+
 /* Check if this is fast call. */
 static inline bool smccc_is_fast_call(register_t funcid)
 {
@@ -137,8 +139,9 @@ static inline uint32_t smccc_get_owner(register_t funcid)
   ARM_SMCCC_OWNER_ARCH, \
   0x8000)
 
-/* Only one error code defined in SMCCC */
+/* SMCCC error codes */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
+#define ARM_SMCCC_NOT_SUPPORTED (-1)
 
 /* SMCCC function identifier range which is reserved for existing APIs */
 #define ARM_SMCCC_RESERVED_RANGE_START  0x0
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 13/15] xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu

Currently, the behavior of do_common_cpu will slightly change depending
on the PSCI version passed in parameter. Looking at the code, more the
specific 0.2 behavior could move out of the function or adapted for 0.1:

- x0/r0 can be updated on PSCI 0.1 because general purpose registers
are undefined upon CPU on.
- PSCI 0.1 does not defined PSCI_ALREADY_ON. However, it would be
safer to bail out if the CPU is already on.

Based on this, the parameter 'ver' is removed and do_psci_cpu_on
(implementation for PSCI 0.1) is adapted to avoid returning
PSCI_ALREADY_ON.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
The reviewed-by was kept despite move this patch towards the end
of the series because there was no clash with the rest of the series.

Changes in v2:
- Move the patch towards the end of the series as not strictly
necessary for SP2.
- Add Volodymyr's reviewed-by
---
 xen/arch/arm/vpsci.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 19ee7caeb4..7ea3ea58e3 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -22,7 +22,7 @@
 #include 
 
 static int do_common_cpu_on(register_t target_cpu, register_t entry_point,
-   register_t context_id,int ver)
+register_t context_id)
 {
 struct vcpu *v;
 struct domain *d = current->domain;
@@ -40,8 +40,7 @@ static int do_common_cpu_on(register_t target_cpu, register_t 
entry_point,
 if ( is_64bit_domain(d) && is_thumb )
 return PSCI_INVALID_PARAMETERS;
 
-if ( (ver == PSCI_VERSION(0, 2)) &&
-!test_bit(_VPF_down, >pause_flags) )
+if ( !test_bit(_VPF_down, >pause_flags) )
 return PSCI_ALREADY_ON;
 
 if ( (ctxt = alloc_vcpu_guest_context()) == NULL )
@@ -55,18 +54,21 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
 ctxt->ttbr0 = 0;
 ctxt->ttbr1 = 0;
 ctxt->ttbcr = 0; /* Defined Reset Value */
+
+/*
+ * x0/r0_usr are always updated because for PSCI 0.1 the general
+ * purpose registers are undefined upon CPU_on.
+ */
 if ( is_32bit_domain(d) )
 {
 ctxt->user_regs.cpsr = PSR_GUEST32_INIT;
-if ( ver == PSCI_VERSION(0, 2) )
-ctxt->user_regs.r0_usr = context_id;
+ctxt->user_regs.r0_usr = context_id;
 }
 #ifdef CONFIG_ARM_64
 else
 {
 ctxt->user_regs.cpsr = PSR_GUEST64_INIT;
-if ( ver == PSCI_VERSION(0, 2) )
-ctxt->user_regs.x0 = context_id;
+ctxt->user_regs.x0 = context_id;
 }
 #endif
 
@@ -93,7 +95,14 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
 
 static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
 {
-return do_common_cpu_on(vcpuid, entry_point, 0 , PSCI_VERSION(0, 1));
+int32_t ret;
+
+ret = do_common_cpu_on(vcpuid, entry_point, 0);
+/*
+ * PSCI 0.1 does not define the return code PSCI_ALREADY_ON.
+ * Instead, return PSCI_INVALID_PARAMETERS.
+ */
+return (ret == PSCI_ALREADY_ON) ? PSCI_INVALID_PARAMETERS : ret;
 }
 
 static int32_t do_psci_cpu_off(uint32_t power_state)
@@ -137,8 +146,7 @@ static int32_t do_psci_0_2_cpu_on(register_t target_cpu,
   register_t entry_point,
   register_t context_id)
 {
-return do_common_cpu_on(target_cpu, entry_point, context_id,
-PSCI_VERSION(0, 2));
+return do_common_cpu_on(target_cpu, entry_point, context_id);
 }
 
 static const unsigned long target_affinity_mask[] = {
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 14/15] xen/arm: psci: Consolidate PSCI version print

Xen is printing the same way the PSCI version for 0.1, 0.2 and later.
The only different is the former is hardcoded.

Furthermore PSCI is now used for other things than SMP bring up. So only
print the PSCI version in psci_init.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Patch added
---
 xen/arch/arm/psci.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index bc7b2260e8..7a8cf54e6d 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -136,8 +136,6 @@ int __init psci_init_0_1(void)
 
 psci_ver = PSCI_VERSION(0, 1);
 
-printk(XENLOG_INFO "Using PSCI-0.1 for SMP bringup\n");
-
 return 0;
 }
 
@@ -183,9 +181,6 @@ int __init psci_init_0_2(void)
 
 psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(CPU_ON);
 
-printk(XENLOG_INFO "Using PSCI-%u.%u for SMP bringup\n",
-   PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
-
 return 0;
 }
 
@@ -205,6 +200,9 @@ int __init psci_init(void)
 
 psci_init_smccc();
 
+printk(XENLOG_INFO "Using PSCI v%u.%u\n",
+   PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
+
 return 0;
 }
 
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 08/15] xen/arm: smccc: Add macros SMCCC_VERSION, SMCCC_VERSION_{MINOR, MAJOR}

Add macros SMCCC_VERSION, SMCCC_VERSION_{MINOR, MAJOR} to easily convert
between a 32-bit value and a version number. The encoding is based on
2.2.2 in "Firmware interfaces for mitigation CVE-2017-5715" (ARM DEN 0070A).

Also re-use them to define ARM_SMCCC_VERSION_1_0 and ARM_SMCCC_VERSION_1_1.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Patch added
---
 xen/include/asm-arm/smccc.h | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index d24ccb51d8..caa2c9cc1b 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -16,8 +16,20 @@
 #ifndef __ASM_ARM_SMCCC_H__
 #define __ASM_ARM_SMCCC_H__
 
-#define ARM_SMCCC_VERSION_1_0   0x1
-#define ARM_SMCCC_VERSION_1_1   0x10001
+#define SMCCC_VERSION_MAJOR_SHIFT16
+#define SMCCC_VERSION_MINOR_MASK \
+((1U << SMCCC_VERSION_MAJOR_SHIFT) - 1)
+#define SMCCC_VERSION_MAJOR_MASK ~SMCCC_VERSION_MINOR_MASK
+#define SMCCC_VERSION_MAJOR(ver) \
+(((ver) & SMCCC_VERSION_MAJOR_MASK) >> SMCCC_VERSION_MAJOR_SHIFT)
+#define SMCCC_VERSION_MINOR(ver) \
+((ver) & SMCCC_VERSION_MINOR_MASK)
+
+#define SMCCC_VERSION(major, minor)  \
+(((major) << SMCCC_VERSION_MAJOR_SHIFT) | (minor))
+
+#define ARM_SMCCC_VERSION_1_0   SMCCC_VERSION(1, 0)
+#define ARM_SMCCC_VERSION_1_1   SMCCC_VERSION(1, 1)
 
 /*
  * This file provides common defines for ARM SMC Calling Convention as
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 12/15] xen/arm64: Kill PSCI_GET_VERSION as a variant-2 workaround

Now that we've standardised on SMCCC v1.1 to perform the branch
prediction invalidation, let's drop the previous band-aid. If vendors
haven't updated their firmware to do SMCCC 1.1, they haven't updated
PSCI either, so we don't loose anything.

This is aligned with the Linux commit 3a0a397ff5ff.

Signed-off-by: Julien Grall 

---
Note that the patch is in arm64/for-next/core and should be merged
in master soon.

Changes in v2:
- Patch added
---
 xen/arch/arm/arm64/bpi.S | 25 --
 xen/arch/arm/cpuerrata.c | 54 +---
 2 files changed, 19 insertions(+), 60 deletions(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index ef237de7bd..6270b10c4f 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -58,31 +58,6 @@ ENTRY(__bp_harden_hyp_vecs_start)
 .endr
 ENTRY(__bp_harden_hyp_vecs_end)
 
-ENTRY(__psci_hyp_bp_inval_start)
-sub sp, sp, #(8 * 18)
-stp x16, x17, [sp, #(16 * 0)]
-stp x14, x15, [sp, #(16 * 1)]
-stp x12, x13, [sp, #(16 * 2)]
-stp x10, x11, [sp, #(16 * 3)]
-stp x8, x9, [sp, #(16 * 4)]
-stp x6, x7, [sp, #(16 * 5)]
-stp x4, x5, [sp, #(16 * 6)]
-stp x2, x3, [sp, #(16 * 7)]
-stp x0, x1, [sp, #(16 * 8)]
-mov x0, #0x8400
-smc #0
-ldp x16, x17, [sp, #(16 * 0)]
-ldp x14, x15, [sp, #(16 * 1)]
-ldp x12, x13, [sp, #(16 * 2)]
-ldp x10, x11, [sp, #(16 * 3)]
-ldp x8, x9, [sp, #(16 * 4)]
-ldp x6, x7, [sp, #(16 * 5)]
-ldp x4, x5, [sp, #(16 * 6)]
-ldp x2, x3, [sp, #(16 * 7)]
-ldp x0, x1, [sp, #(16 * 8)]
-add sp, sp, #(8 * 18)
-ENTRY(__psci_hyp_bp_inval_end)
-
 ENTRY(__smccc_workaround_1_smc_start)
 sub sp, sp, #(8 * 4)
 stp x2, x3, [sp, #(8 * 0)]
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 6557577bcb..af453710e4 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -149,10 +149,11 @@ install_bp_hardening_vec(const struct 
arm_cpu_capabilities *entry,
 
 extern char __smccc_workaround_1_smc_start[], __smccc_workaround_1_smc_end[];
 
-static bool
-check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
+static int enable_smccc_arch_workaround_1(void *data)
 {
 struct arm_smccc_res res;
+static bool warned = false;
+const struct arm_cpu_capabilities *entry = data;
 
 /*
  * Enable callbacks are called on every CPU based on the
@@ -160,47 +161,30 @@ check_smccc_arch_workaround_1(const struct 
arm_cpu_capabilities *entry)
  * entry.
  */
 if ( !entry->matches(entry) )
-return false;
+return 0;
 
 if ( smccc_ver < SMCCC_VERSION(1, 1) )
-return false;
+goto warn;
 
 arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
   ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
 if ( res.a0 != ARM_SMCCC_SUCCESS )
-return false;
-
-return install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
-__smccc_workaround_1_smc_end,
-"call ARM_SMCCC_ARCH_WORKAROUND_1");
-}
+goto warn;
 
-extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
+return !install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
+ __smccc_workaround_1_smc_end,
+ "call ARM_SMCCC_ARCH_WORKAROUND_1");
 
-static int enable_psci_bp_hardening(void *data)
-{
-bool ret = true;
-static bool warned = false;
-
-if ( check_smccc_arch_workaround_1(data) )
-return 0;
-/*
- * The mitigation is using PSCI version function to invalidate the
- * branch predictor. This function is only available with PSCI 0.2
- * and later.
- */
-else if ( psci_ver >= PSCI_VERSION(0, 2) )
-ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
-   __psci_hyp_bp_inval_end,
-   "call PSCI get version");
-else if ( !warned )
+warn:
+if ( !warned )
 {
 ASSERT(system_state < SYS_STATE_active);
-warning_add("PSCI 0.2 or later is required for the branch predictor 
hardening.\n");
-warned = true;
+warning_add("No support for ARM_SMCCC_ARCH_WORKAROUND_1.\n"
+"Please update your firmware.\n");
+warned = false;
 }
 
-return !ret;
+return 0;
 }
 
 #endif /* CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR */
@@ -316,22 +300,22 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 {
 .capability = ARM_HARDEN_BRANCH_PREDICTOR,
 MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
-.enable = enable_psci_bp_hardening,
+.enable = enable_smccc_arch_workaround_1,
 },
 {
 .capability = ARM_HARDEN_BRANCH_PREDICTOR,

[Xen-devel] [PATCH v2 11/15] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Patch added
---
 xen/arch/arm/arm64/bpi.S| 12 
 xen/arch/arm/cpuerrata.c| 32 +++-
 xen/include/asm-arm/smccc.h |  1 +
 3 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index 4b7f1dc21f..ef237de7bd 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -16,6 +16,8 @@
  * along with this program.  If not, see .
  */
 
+#include 
+
 .macro ventry target
 .rept 31
 nop
@@ -81,6 +83,16 @@ ENTRY(__psci_hyp_bp_inval_start)
 add sp, sp, #(8 * 18)
 ENTRY(__psci_hyp_bp_inval_end)
 
+ENTRY(__smccc_workaround_1_smc_start)
+sub sp, sp, #(8 * 4)
+stp x2, x3, [sp, #(8 * 0)]
+stp x0, x1, [sp, #(8 * 2)]
+mov w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+ldp x2, x3, [sp, #(8 * 0)]
+ldp x0, x1, [sp, #(8 * 2)]
+add sp, sp, #(8 * 4)
+ENTRY(__smccc_workaround_1_smc_end)
+
 /*
  * Local variables:
  * mode: ASM
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 6704648b26..6557577bcb 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -147,6 +147,34 @@ install_bp_hardening_vec(const struct arm_cpu_capabilities 
*entry,
 return ret;
 }
 
+extern char __smccc_workaround_1_smc_start[], __smccc_workaround_1_smc_end[];
+
+static bool
+check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
+{
+struct arm_smccc_res res;
+
+/*
+ * Enable callbacks are called on every CPU based on the
+ * capabilities. So double-check whether the CPU matches the
+ * entry.
+ */
+if ( !entry->matches(entry) )
+return false;
+
+if ( smccc_ver < SMCCC_VERSION(1, 1) )
+return false;
+
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+  ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
+if ( res.a0 != ARM_SMCCC_SUCCESS )
+return false;
+
+return install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
+__smccc_workaround_1_smc_end,
+"call ARM_SMCCC_ARCH_WORKAROUND_1");
+}
+
 extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
 
 static int enable_psci_bp_hardening(void *data)
@@ -154,12 +182,14 @@ static int enable_psci_bp_hardening(void *data)
 bool ret = true;
 static bool warned = false;
 
+if ( check_smccc_arch_workaround_1(data) )
+return 0;
 /*
  * The mitigation is using PSCI version function to invalidate the
  * branch predictor. This function is only available with PSCI 0.2
  * and later.
  */
-if ( psci_ver >= PSCI_VERSION(0, 2) )
+else if ( psci_ver >= PSCI_VERSION(0, 2) )
 ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
__psci_hyp_bp_inval_end,
"call PSCI get version");
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 154772b728..8342cc33fe 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -261,6 +261,7 @@ struct arm_smccc_res {
 /* SMCCC error codes */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
 #define ARM_SMCCC_NOT_SUPPORTED (-1)
+#define ARM_SMCCC_SUCCESS   (0)
 
 /* SMCCC function identifier range which is reserved for existing APIs */
 #define ARM_SMCCC_RESERVED_RANGE_START  0x0
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 15/15] xen/arm: psci: Prefix with static any functions not exported

A bunch of PSCI functions are not prefixed with static despite no one is
using them outside the file and the prototype is not available in
psci.h.

Signed-off-by: Julien Grall 

---

Changes in v2:
- Patch added
---
 xen/arch/arm/psci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 7a8cf54e6d..5d94a9a9ae 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -66,7 +66,7 @@ static int __init psci_features(uint32_t psci_func_id)
 return call_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id, 0, 0);
 }
 
-int __init psci_is_smc_method(const struct dt_device_node *psci)
+static int __init psci_is_smc_method(const struct dt_device_node *psci)
 {
 int ret;
 const char *prop_str;
@@ -109,7 +109,7 @@ static void __init psci_init_smccc(void)
SMCCC_VERSION_MAJOR(smccc_ver), SMCCC_VERSION_MINOR(smccc_ver));
 }
 
-int __init psci_init_0_1(void)
+static int __init psci_init_0_1(void)
 {
 int ret;
 const struct dt_device_node *psci;
@@ -139,7 +139,7 @@ int __init psci_init_0_1(void)
 return 0;
 }
 
-int __init psci_init_0_2(void)
+static int __init psci_init_0_2(void)
 {
 static const struct dt_device_match psci_ids[] __initconst =
 {
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

At the moment, Xen provides virtual PSCI interface compliant with 0.1
and 0.2. Since them, the specification has been updated and the latest
version is 1.1 (see ARM DEN 0022D).

From an implementation point of view, only PSCI_FEATURES is mandatory.
The rest is optional and can be left unimplemented for now.

At the same time, the compatible for PSCI node have been updated to
expose "arm,psci-1.0".

Signed-off-by: Julien Grall 
Cc: Wei Liu 
Cc: Ian Jackson 
Cc: mirela.simono...@aggios.com

---
We may want to provide a way for the toolstack to specify a PSCI
version. This could be useful if a guest is expecting a given
version.

Changes in v2:
- Return v1.1 on GET_VERSION call as claimed by this patch
- Order by function ID the calls in FEATURES call
---
 tools/libxl/libxl_arm.c  |  3 ++-
 xen/arch/arm/domain_build.c  |  1 +
 xen/arch/arm/vpsci.c | 39 ++-
 xen/include/asm-arm/perfc_defn.h |  1 +
 xen/include/asm-arm/psci.h   |  1 +
 xen/include/asm-arm/vpsci.h  |  2 +-
 6 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 3e46554301..86f59c0d80 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -410,7 +410,8 @@ static int make_psci_node(libxl__gc *gc, void *fdt)
 res = fdt_begin_node(fdt, "psci");
 if (res) return res;
 
-res = fdt_property_compat(gc, fdt, 2, "arm,psci-0.2","arm,psci");
+res = fdt_property_compat(gc, fdt, 3, "arm,psci-1.0",
+  "arm,psci-0.2", "arm,psci");
 if (res) return res;
 
 res = fdt_property_string(fdt, "method", "hvc");
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 155c952349..941688a2ce 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -637,6 +637,7 @@ static int make_psci_node(void *fdt, const struct 
dt_device_node *parent)
 {
 int res;
 const char compat[] =
+"arm,psci-1.0""\0"
 "arm,psci-0.2""\0"
 "arm,psci";
 
diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 6ab8ab64d0..e82b62db1a 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -106,7 +106,11 @@ static int32_t do_psci_cpu_off(uint32_t power_state)
 
 static uint32_t do_psci_0_2_version(void)
 {
-return PSCI_VERSION(0, 2);
+/*
+ * PSCI is backward compatible from 0.2. So we can bump the version
+ * without any issue.
+ */
+return PSCI_VERSION(1, 1);
 }
 
 static register_t do_psci_0_2_cpu_suspend(uint32_t power_state,
@@ -191,6 +195,29 @@ static void do_psci_0_2_system_reset(void)
 domain_shutdown(d,SHUTDOWN_reboot);
 }
 
+static int32_t do_psci_1_0_features(uint32_t psci_func_id)
+{
+/* /!\ Ordered by function ID and not name */
+switch ( psci_func_id )
+{
+case PSCI_0_2_FN32_PSCI_VERSION:
+case PSCI_0_2_FN32_CPU_SUSPEND:
+case PSCI_0_2_FN64_CPU_SUSPEND:
+case PSCI_0_2_FN32_CPU_OFF:
+case PSCI_0_2_FN32_CPU_ON:
+case PSCI_0_2_FN64_CPU_ON:
+case PSCI_0_2_FN32_AFFINITY_INFO:
+case PSCI_0_2_FN64_AFFINITY_INFO:
+case PSCI_0_2_FN32_MIGRATE_INFO_TYPE:
+case PSCI_0_2_FN32_SYSTEM_OFF:
+case PSCI_0_2_FN32_SYSTEM_RESET:
+case PSCI_1_0_FN32_PSCI_FEATURES:
+return 0;
+default:
+return PSCI_NOT_SUPPORTED;
+}
+}
+
 #define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
 #define PSCI_ARG(reg, n) get_user_reg(reg, n)
 
@@ -304,6 +331,16 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, 
uint32_t fid)
 PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
 return true;
 }
+
+case PSCI_1_0_FN32_PSCI_FEATURES:
+{
+uint32_t psci_func_id = PSCI_ARG32(regs, 1);
+
+perfc_incr(vpsci_features);
+PSCI_SET_RESULT(regs, do_psci_1_0_features(psci_func_id));
+return true;
+}
+
 default:
 return false;
 }
diff --git a/xen/include/asm-arm/perfc_defn.h b/xen/include/asm-arm/perfc_defn.h
index a7acb7d21c..87866264ca 100644
--- a/xen/include/asm-arm/perfc_defn.h
+++ b/xen/include/asm-arm/perfc_defn.h
@@ -31,6 +31,7 @@ PERFCOUNTER(vpsci_system_off,  "vpsci: system_off")
 PERFCOUNTER(vpsci_system_reset,"vpsci: system_reset")
 PERFCOUNTER(vpsci_cpu_suspend, "vpsci: cpu_suspend")
 PERFCOUNTER(vpsci_cpu_affinity_info,   "vpsci: cpu_affinity_info")
+PERFCOUNTER(vpsci_features,"vpsci: features")
 
 PERFCOUNTER(vgicd_reads,"vgicd: read")
 PERFCOUNTER(vgicd_writes,   "vgicd: write")
diff --git a/xen/include/asm-arm/psci.h b/xen/include/asm-arm/psci.h
index becc9f9ded..e2629eed01 100644
--- a/xen/include/asm-arm/psci.h
+++ b/xen/include/asm-arm/psci.h
@@ -40,6 +40,7 @@ void call_psci_system_reset(void);
 #define PSCI_0_2_FN32_MIGRATE_INFO_TYPE   PSCI_0_2_FN32(6)
 #define

[Xen-devel] [PATCH v2 04/15] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

SMCCC 1.1 offers firmware-based CPU workarounds. In particular,
SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254
(CVE-2017-5715).

If the hypervisor has some mitigation for this issue, report that we
deal with it using SMCCC_ARCH_WORKAROUND_1, as we apply the hypervisor
workaround on every guest exit.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
Changes in v2:
- Add Volodymyr's reviewed-by
---
 xen/arch/arm/vsmc.c | 22 --
 xen/include/asm-arm/smccc.h |  6 ++
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index a708aa5e81..144a1cd761 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -93,8 +94,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
 return true;
 
 case ARM_SMCCC_ARCH_FEATURES_FID:
-/* Nothing supported yet */
-set_user_reg(regs, 0, -1);
+{
+uint32_t arch_func_id = get_user_reg(regs, 1);
+int ret = -1;
+
+switch ( arch_func_id )
+{
+case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
+if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
+ret = 0;
+break;
+}
+
+set_user_reg(regs, 0, ret);
+
+return true;
+}
+
+case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
+/* No return value */
 return true;
 }
 
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 431389c118..b790fac17c 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -115,6 +115,12 @@ static inline uint32_t smccc_get_owner(register_t funcid)
ARM_SMCCC_OWNER_ARCH,\
0x1)
 
+#define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+  ARM_SMCCC_CONV_32,\
+  ARM_SMCCC_OWNER_ARCH, \
+  0x8000)
+
 /* Only one error code defined in SMCCC */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
 
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 05/15] xen/arm: Adapt smccc.h to be able to use it in assembly code

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
Changes in v2:
- Add Volodymyr's reviewed-by
---
 xen/include/asm-arm/smccc.h | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index b790fac17c..d24ccb51d8 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -25,18 +25,20 @@
  * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
  */
 
-#define ARM_SMCCC_STD_CALL  0U
-#define ARM_SMCCC_FAST_CALL 1U
+#define ARM_SMCCC_STD_CALL  _AC(0,U)
+#define ARM_SMCCC_FAST_CALL _AC(1,U)
 #define ARM_SMCCC_TYPE_SHIFT31
 
-#define ARM_SMCCC_CONV_32   0U
-#define ARM_SMCCC_CONV_64   1U
+#define ARM_SMCCC_CONV_32   _AC(0,U)
+#define ARM_SMCCC_CONV_64   _AC(1,U)
 #define ARM_SMCCC_CONV_SHIFT30
 
-#define ARM_SMCCC_OWNER_MASK0x3FU
+#define ARM_SMCCC_OWNER_MASK_AC(0x3F,U)
 #define ARM_SMCCC_OWNER_SHIFT   24
 
-#define ARM_SMCCC_FUNC_MASK 0xU
+#define ARM_SMCCC_FUNC_MASK _AC(0x,U)
+
+#ifndef __ASSEMBLY__
 
 /* Check if this is fast call. */
 static inline bool smccc_is_fast_call(register_t funcid)
@@ -62,6 +64,8 @@ static inline uint32_t smccc_get_owner(register_t funcid)
 return (funcid >> ARM_SMCCC_OWNER_SHIFT) & ARM_SMCCC_OWNER_MASK;
 }
 
+#endif
+
 /*
  * Construct function identifier from call type (fast or standard),
  * calling convention (32 or 64 bit), service owner and function number.
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

flight 118690 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118690/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  2f92a0b22e3aa46b2785342d0aa5d54bc30d3be2
baseline version:
 xen  c93014ad3aa6aa88dfa5e96f66e8adb561483b8d

Last test of basis   118665  2018-02-07 21:01:07 Z0 days
Testing same since   118690  2018-02-08 17:01:12 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  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 :

To xenbits.xen.org:/home/xen/git/xen.git
   c93014ad3a..2f92a0b22e  2f92a0b22e3aa46b2785342d0aa5d54bc30d3be2 -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PULL 14/26] pci: removed the is_express field since a uniform interface was inserted

2018-02-08 Thread Michael S. Tsirkin

From: Yoni Bettan 

according to Eduardo Habkost's commit fd3b02c889 all PCIEs now implement
INTERFACE_PCIE_DEVICE so we don't need is_express field anymore.

Devices that implements only INTERFACE_PCIE_DEVICE (is_express == 1)
or
devices that implements only INTERFACE_CONVENTIONAL_PCI_DEVICE (is_express == 0)
where not affected by the change.

The only devices that were affected are those that are hybrid and also
had (is_express == 1) - therefor only:
  - hw/vfio/pci.c
  - hw/usb/hcd-xhci.c
  - hw/xen/xen_pt.c

For those 3 I made sure that QEMU_PCI_CAP_EXPRESS is on in instance_init()

Reviewed-by: Marcel Apfelbaum 
Reviewed-by: Eduardo Habkost 
Signed-off-by: Yoni Bettan 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 docs/pcie_pci_bridge.txt   | 2 +-
 include/hw/pci/pci.h   | 3 ---
 hw/block/nvme.c| 1 -
 hw/net/e1000e.c| 1 -
 hw/pci-bridge/pcie_pci_bridge.c| 1 -
 hw/pci-bridge/pcie_root_port.c | 1 -
 hw/pci-bridge/xio3130_downstream.c | 1 -
 hw/pci-bridge/xio3130_upstream.c   | 1 -
 hw/pci-host/xilinx-pcie.c  | 1 -
 hw/pci/pci.c   | 8 ++--
 hw/scsi/megasas.c  | 4 
 hw/usb/hcd-xhci.c  | 9 -
 hw/vfio/pci.c  | 5 -
 hw/xen/xen_pt.c| 9 -
 14 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/docs/pcie_pci_bridge.txt b/docs/pcie_pci_bridge.txt
index 5a4203f..ab35ebf 100644
--- a/docs/pcie_pci_bridge.txt
+++ b/docs/pcie_pci_bridge.txt
@@ -110,5 +110,5 @@ To enable device hot-plug into the bridge on Linux there're 
3 ways:
 Implementation
 ==
 The PCIE-PCI bridge is based on PCI-PCI bridge, but also accumulates PCI 
Express
-features as a PCI Express device (is_express=1).
+features as a PCI Express device.
 
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 15ced96..d8c18c7 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -236,9 +236,6 @@ typedef struct PCIDeviceClass {
  */
 int is_bridge;
 
-/* pcie stuff */
-int is_express;   /* is this device pci express? */
-
 /* rom bar */
 const char *romfile;
 } PCIDeviceClass;
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 51a58fe..85d2406 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1360,7 +1360,6 @@ static void nvme_class_init(ObjectClass *oc, void *data)
 pc->vendor_id = PCI_VENDOR_ID_INTEL;
 pc->device_id = 0x5845;
 pc->revision = 2;
-pc->is_express = 1;
 
 set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
 dc->desc = "Non-Volatile Memory Express";
diff --git a/hw/net/e1000e.c b/hw/net/e1000e.c
index 191398a..16a9417 100644
--- a/hw/net/e1000e.c
+++ b/hw/net/e1000e.c
@@ -675,7 +675,6 @@ static void e1000e_class_init(ObjectClass *class, void 
*data)
 c->revision = 0;
 c->romfile = "efi-e1000e.rom";
 c->class_id = PCI_CLASS_NETWORK_ETHERNET;
-c->is_express = 1;
 
 dc->desc = "Intel 82574L GbE Controller";
 dc->reset = e1000e_qdev_reset;
diff --git a/hw/pci-bridge/pcie_pci_bridge.c b/hw/pci-bridge/pcie_pci_bridge.c
index e5ac797..04cf5a6 100644
--- a/hw/pci-bridge/pcie_pci_bridge.c
+++ b/hw/pci-bridge/pcie_pci_bridge.c
@@ -170,7 +170,6 @@ static void pcie_pci_bridge_class_init(ObjectClass *klass, 
void *data)
 DeviceClass *dc = DEVICE_CLASS(klass);
 HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
 
-k->is_express = 1;
 k->is_bridge = 1;
 k->vendor_id = PCI_VENDOR_ID_REDHAT;
 k->device_id = PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE;
diff --git a/hw/pci-bridge/pcie_root_port.c b/hw/pci-bridge/pcie_root_port.c
index 9b6e4ce..45f9e8c 100644
--- a/hw/pci-bridge/pcie_root_port.c
+++ b/hw/pci-bridge/pcie_root_port.c
@@ -145,7 +145,6 @@ static void rp_class_init(ObjectClass *klass, void *data)
 DeviceClass *dc = DEVICE_CLASS(klass);
 PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
 
-k->is_express = 1;
 k->is_bridge = 1;
 k->config_write = rp_write_config;
 k->realize = rp_realize;
diff --git a/hw/pci-bridge/xio3130_downstream.c 
b/hw/pci-bridge/xio3130_downstream.c
index 4dd2e65..b202657 100644
--- a/hw/pci-bridge/xio3130_downstream.c
+++ b/hw/pci-bridge/xio3130_downstream.c
@@ -178,7 +178,6 @@ static void xio3130_downstream_class_init(ObjectClass 
*klass, void *data)
 DeviceClass *dc = DEVICE_CLASS(klass);
 PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
 
-k->is_express = 1;
 k->is_bridge = 1;
 k->config_write = xio3130_downstream_write_config;
 k->realize = xio3130_downstream_realize;
diff --git a/hw/pci-bridge/xio3130_upstream.c b/hw/pci-bridge/xio3130_upstream.c
index c5f02a6..556f471 100644
--- a/hw/pci-bridge/xio3130_upstream.c
+++ b/hw/pci-bridge/xio3130_upstream.c
@@ -149,7 +149,6 @@ static void

[Xen-devel] [xen-unstable test] 118661: regressions - FAIL

flight 118661 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118661/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm  7 xen-boot fail REGR. vs. 118607

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 118607

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118607
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118607
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118607
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118607
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118607
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118607
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 118607
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118607
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118607
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  66c4f0c47fd80d1133c24865f95d4f0c59ef9bce
baseline version:
 xen  1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0

Last test of basis   118607  2018-02-06 05:47:11 Z2 days
Failing since118622  2018-02-06 19:15:37 Z1 days3 attempts
Testing same since   118661  2018-02-07 19:45:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  George Dunlap 
  Jan Beulich

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

On Thu, Feb 08, 2018 at 06:03:48PM +, Wei Liu wrote:
> On Thu, Feb 08, 2018 at 06:49:58PM +0100, Dario Faggioli wrote:
> > On Tue, 2018-01-30 at 22:55 +, Michael Young wrote:
> > > Xen built with ocaml 4.06 gives errors such as
> > > Error: This expression has type bytes but an expression was
> > >   expected of type string
> > > as Byte and safe-strings which were introduced in 4.02 are the
> > > default in 4.06.
> > > This patch which is partly by Richard W.M. Jones of Red Hat
> > > from https://bugzilla.redhat.com/show_bug.cgi?id=1526703
> > > fixes these issues.
> > > 
> > > Signed-off-by: Michael Young 
> > > Reviewed-by: Christian Lindig 
> > >
> > So, with this patch, oxenstord does not start for me.
> > 
> > Systemd says this (sorry, it's not the full output.. I don't have it
> > right now, but can produce it):
> > 
> > systemctl status xenstored
> >  ...
> >  Active: failed (Result: protocol) since Thu 2018-02-08 17:47:56 CET; 12min 
> > ago
> >  ...
> >  Feb 08 17:47:56 Zhaman systemd[1]: xenstored.service: Failed with result 
> > 'protocol'.
> > 
> > Just running oxenstored from command line seems to exits with 0, but
> > there's not an oxenstored process running.
> > 
> > Getting rid of what is now commit "make xen ocaml safe-strings
> > compliant" (df1e4c6e7f8892e950433ff33c215df0cd7b30f7), things work
> > again for me.
> > 
> 
> OK. I will revert the relevant commits in staging. I'm sure this will
> block osstest flights.
> 

Correction: osstest currently still runs Debian jessie, which has ocaml
4.01, which means the bump to 4.02 in staging is likely cause oxenstored
to be disabled. New flights could still pass but that's due to
oxenstored not getting tested. It is convoluted, I know. :-/

I need to at least revert the safe-string patches in staging. As for the
version bump, I'm not so sure. On one hand it is useless in its own and
leaving the bump in tree actually stops the testing of oxenstored, on
the other hand it is a must-have for safe-string patch, assuming we will
have a proper safe-string fix soon-ish we can leave them in staging.

Christian, do you have any idea when you can look into fixing the
safe-string patch?

And osstest should really be upgraded to strech (which has 4.02).

Wei.


> Wei.
> 
> > Regards,
> > Dario
> > 
> > PS. There has been a v2 of this patch, I think, but I don't have in my
> > emails any longer, so I'm replying to this one.
> > 
> > -- 
> > <> (Raistlin Majere)
> > -
> > Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> > Software Engineer @ SUSE https://www.suse.com/
> 
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/7] xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu




On 06/02/18 15:42, Volodymyr Babchuk wrote:

Hi Julien,


Hi Volodymyr,


On 5 February 2018 at 15:20, Julien Grall  wrote:

Currently, the behavior of do_common_cpu will slightly change depending
on the PSCI version passed in parameter. Looking at the code, more the
specific 0.2 behavior could move out of the function or adapted for 0.1:

 - x0/r0 can be updated on PSCI 0.1 because general purpose registers
 are undefined upon CPU on.
 - PSCI 0.1 does not defined PSCI_ALREADY_ON. However, it would be
 safer to bail out if the CPU is already on.

Based on this, the parameter 'ver' is removed and do_psci_cpu_on
(implementation for PSCI 0.1) is adapted to avoid returning
PSCI_ALREADY_ON.

Signed-off-by: Julien Grall 

Reviewed-by: Volodymyr Babchuk 


Thank you for the reviewed. FIY, I moved that patch towards the end of 
the series as it is not necessary for backporting. I kept your 
reviewed-by because there are no clash.


I hope that is fine for you.

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 4/4] hvm/svm: Enable CR events

2018-02-08 Thread Tamas K Lengyel

On Thu, Feb 8, 2018 at 8:25 AM, Alexandru Isaila
 wrote:
> This commit enables controlregister events for svm.

So this patch enables the event to trigger but where is it being
handled and forwarded to the monitor ring?

>
> Signed-off-by: Alexandru Isaila 
> ---
>  xen/arch/x86/hvm/svm/svm.c| 11 +++
>  xen/include/asm-x86/monitor.h |  6 +++---
>  2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 1eadab4..311902f 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -60,6 +60,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  void svm_asm_do_resume(void);
> @@ -560,6 +561,16 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int cr)
>  svm_fpu_enter(v);
>  }
>
> +if ( paging_mode_hap(v->domain) )
> +{
> +uint32_t intercepts = vmcb_get_cr_intercepts(vmcb);
> +
> +/* Trap CR3 updates if CR3 memory events are enabled. */
> +if ( v->domain->arch.monitor.write_ctrlreg_enabled &
> + monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
> +   vmcb_set_cr_intercepts(vmcb, intercepts | 
> CR_INTERCEPT_CR3_WRITE);
> +}
> +
>  value = v->arch.hvm_vcpu.guest_cr[0] | hw_cr0_mask;
>  if ( !paging_mode_hap(v->domain) )
>  value |= X86_CR0_PG | X86_CR0_WP;
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index 138c463..b80d217 100644
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -79,8 +79,7 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
> domain *d)
>
>  if( cpu_has_vmx )
>  {
> -capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
> +capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
> (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
> (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
> (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
> @@ -92,7 +91,8 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
> domain *d)
>
>  capabilities |= ((1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
>  (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
> -(1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR));
> +(1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
> +(1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG));
>
>  if ( hvm_funcs.set_descriptor_access_exiting )
>  capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS);
> --
> 2.7.4

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 3/4] hvm/svm: Enable MSR events

2018-02-08 Thread Tamas K Lengyel

On Thu, Feb 8, 2018 at 8:25 AM, Alexandru Isaila
 wrote:
> This commit enables MSR events for svm.
>
> Signed-off-by: Alexandru Isaila 

Acked-by: Tamas K Lengyel 

> ---
>  xen/arch/x86/hvm/svm/svm.c| 9 +
>  xen/include/asm-x86/monitor.h | 4 ++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index a14caab..1eadab4 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -163,6 +163,14 @@ void svm_intercept_msr(struct vcpu *v, uint32_t msr, int 
> flags)
>  __clear_bit(msr * 2 + 1, msr_bit);
>  }
>
> +static void svm_enable_msr_interception(struct domain *d, uint32_t msr)
> +{
> +struct vcpu *v;
> +
> +for_each_vcpu ( d, v )
> +svm_intercept_msr(v, msr, MSR_INTERCEPT_WRITE);
> +}
> +
>  static void svm_save_dr(struct vcpu *v)
>  {
>  struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> @@ -2460,6 +2468,7 @@ static struct hvm_function_table __initdata 
> svm_function_table = {
>  .fpu_dirty_intercept  = svm_fpu_dirty_intercept,
>  .msr_read_intercept   = svm_msr_read_intercept,
>  .msr_write_intercept  = svm_msr_write_intercept,
> +.enable_msr_interception = svm_enable_msr_interception,
>  .set_rdtsc_exiting= svm_set_rdtsc_exiting,
>  .set_descriptor_access_exiting = svm_set_descriptor_access_exiting,
>  .get_insn_bytes   = svm_get_insn_bytes,
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index 68e62bd..138c463 100644
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -80,7 +80,6 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
> domain *d)
>  if( cpu_has_vmx )
>  {
>  capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
> (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
> (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
> (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
> @@ -92,7 +91,8 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
> domain *d)
>  }
>
>  capabilities |= ((1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
> -(1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT));
> +(1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
> +(1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR));
>
>  if ( hvm_funcs.set_descriptor_access_exiting )
>  capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS);
> --
> 2.7.4

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/4] hvm/svm: Enable Breakpoint events

2018-02-08 Thread Tamas K Lengyel

On Thu, Feb 8, 2018 at 8:25 AM, Alexandru Isaila
 wrote:
> This commit enables the breakpoint events for svm.
>
> Signed-off-by: Alexandru Isaila 
>
> ---
> Changes since V1:
> - Clean up bool_t
> - Removed event.insn_len = 0
> - Switched the v->domain->debugger_attached if
> - Add a extra pair of brachets for the capab var.
> ---
>  xen/arch/x86/hvm/svm/svm.c| 48 
> +++
>  xen/include/asm-x86/monitor.h |  4 ++--
>  2 files changed, 42 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index dcbd550..a14caab 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -59,6 +59,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  void svm_asm_do_resume(void);
> @@ -1079,7 +1080,8 @@ static void svm_ctxt_switch_to(struct vcpu *v)
>  static void noreturn svm_do_resume(struct vcpu *v)
>  {
>  struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> -bool_t debug_state = v->domain->debugger_attached;
> +bool debug_state = v->domain->debugger_attached
> +|| v->domain->arch.monitor.software_breakpoint_enabled;
>  bool_t vcpu_guestmode = 0;
>  struct vlapic *vlapic = vcpu_vlapic(v);
>
> @@ -2407,6 +2409,19 @@ static bool svm_get_pending_event(struct vcpu *v, 
> struct x86_event *info)
>  return true;
>  }
>
> +static void svm_propagate_intr(struct vcpu *v, unsigned long insn_len)
> +{
> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> +struct x86_event event = {
> +.vector = vmcb->eventinj.fields.type,
> +.type = vmcb->eventinj.fields.type,
> +.error_code = vmcb->exitinfo1,
> +};
> +
> +event.insn_len = insn_len;
> +hvm_inject_event();
> +}
> +
>  static struct hvm_function_table __initdata svm_function_table = {
>  .name = "SVM",
>  .cpu_up_prepare   = svm_cpu_up_prepare,
> @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>  break;
>
>  case VMEXIT_EXCEPTION_BP:
> -if ( !v->domain->debugger_attached )
> -goto unexpected_exit_type;
> -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. 
> */
> -if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
> +inst_len = __get_instruction_length(v, INSTR_INT3);
> +
> +if ( inst_len == 0 )
>  break;
> -__update_guest_eip(regs, inst_len);
> -current->arch.gdbsx_vcpu_event = TRAP_int3;
> -domain_pause_for_debugger();
> +
> +if ( v->domain->debugger_attached )
> +{
> +__update_guest_eip(regs, inst_len);
> +current->arch.gdbsx_vcpu_event = TRAP_int3;
> +domain_pause_for_debugger();
> +}
> +else
> +{
> +/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. 
> */

This comment here looks like to belong to the code above that manually
increases the IP.

> +   int rc;
> +
> +   rc = hvm_monitor_debug(regs->rip,
> +  HVM_MONITOR_SOFTWARE_BREAKPOINT,
> +  X86_EVENTTYPE_SW_EXCEPTION,
> +  inst_len);
> +   if ( rc < 0 )
> +   goto unexpected_exit_type;
> +   if ( !rc )
> +   svm_propagate_intr(v, inst_len);
> +}
>  break;
>
>  case VMEXIT_EXCEPTION_NM:
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index b2b4e6a..68e62bd 100644
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -81,7 +81,6 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
> domain *d)
>  {
>  capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
> (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
> (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
> (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
> (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
> @@ -92,7 +91,8 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
> domain *d)
>  capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
>  }
>
> -capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
> +capabilities |= ((1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
> +(1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT));
>
>  if ( hvm_funcs.set_descriptor_access_exiting )
>  capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS);
> --
> 2.7.4

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

On Thu, Feb 08, 2018 at 06:49:58PM +0100, Dario Faggioli wrote:
> On Tue, 2018-01-30 at 22:55 +, Michael Young wrote:
> > Xen built with ocaml 4.06 gives errors such as
> > Error: This expression has type bytes but an expression was
> > expected of type string
> > as Byte and safe-strings which were introduced in 4.02 are the
> > default in 4.06.
> > This patch which is partly by Richard W.M. Jones of Red Hat
> > from https://bugzilla.redhat.com/show_bug.cgi?id=1526703
> > fixes these issues.
> > 
> > Signed-off-by: Michael Young 
> > Reviewed-by: Christian Lindig 
> >
> So, with this patch, oxenstord does not start for me.
> 
> Systemd says this (sorry, it's not the full output.. I don't have it
> right now, but can produce it):
> 
> systemctl status xenstored
>  ...
>  Active: failed (Result: protocol) since Thu 2018-02-08 17:47:56 CET; 12min 
> ago
>  ...
>  Feb 08 17:47:56 Zhaman systemd[1]: xenstored.service: Failed with result 
> 'protocol'.
> 
> Just running oxenstored from command line seems to exits with 0, but
> there's not an oxenstored process running.
> 
> Getting rid of what is now commit "make xen ocaml safe-strings
> compliant" (df1e4c6e7f8892e950433ff33c215df0cd7b30f7), things work
> again for me.
> 

OK. I will revert the relevant commits in staging. I'm sure this will
block osstest flights.

Wei.

> Regards,
> Dario
> 
> PS. There has been a v2 of this patch, I think, but I don't have in my
> emails any longer, so I'm replying to this one.
> 
> -- 
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Software Engineer @ SUSE https://www.suse.com/



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

2018-02-08 Thread Dario Faggioli

On Tue, 2018-01-30 at 22:55 +, Michael Young wrote:
> Xen built with ocaml 4.06 gives errors such as
> Error: This expression has type bytes but an expression was
>   expected of type string
> as Byte and safe-strings which were introduced in 4.02 are the
> default in 4.06.
> This patch which is partly by Richard W.M. Jones of Red Hat
> from https://bugzilla.redhat.com/show_bug.cgi?id=1526703
> fixes these issues.
> 
> Signed-off-by: Michael Young 
> Reviewed-by: Christian Lindig 
>
So, with this patch, oxenstord does not start for me.

Systemd says this (sorry, it's not the full output.. I don't have it
right now, but can produce it):

systemctl status xenstored
 ...
 Active: failed (Result: protocol) since Thu 2018-02-08 17:47:56 CET; 12min ago
 ...
 Feb 08 17:47:56 Zhaman systemd[1]: xenstored.service: Failed with result 
'protocol'.

Just running oxenstored from command line seems to exits with 0, but
there's not an oxenstored process running.

Getting rid of what is now commit "make xen ocaml safe-strings
compliant" (df1e4c6e7f8892e950433ff33c215df0cd7b30f7), things work
again for me.

Regards,
Dario

PS. There has been a v2 of this patch, I think, but I don't have in my
emails any longer, so I'm replying to this one.

-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Slow HVM boot time, was "HVM boot time optimization"

On Thu, Feb 08, 2018 at 04:56:00PM +, Anthony PERARD wrote:
> On Thu, Feb 08, 2018 at 04:48:10PM +, Wei Liu wrote:
> > On Thu, Feb 08, 2018 at 08:31:40AM -0800, Stefano Stabellini wrote:
> > > CC'ing xen-devel and a few relevant people
> > > 
> > > On Thu, 8 Feb 2018, Yessine Daoud wrote:
> > > > Dear Sir,
> > > > I need your help please.
> > > > 
> > > > I am using a direct kernel boot (HVM guest) with kernel + ramdisk.
> > > > At boot, seabios is bloqued about 20 seconds (or more) at the following 
> > > > state:
> > > > 
> > 
> > The manual seems a bit confusing to me but maybe I misremember how it
> > works. My understanding is direct kernel boot jumps straight to kernel
> > entry point without going through firmware.
> > 
> > If this is direct kernel boot why is seabios involved?
> 
> seabios is the one to load the kernel into memory and start it.
> 

I see. Thank for explaining.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

2018-02-08 Thread Brian Woods

Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.

Reported-by: Andrew Cooper 
Signed-off-by: Brian Woods 
---
 xen/arch/x86/hvm/svm/nestedsvm.c| 66 +
 xen/arch/x86/hvm/svm/svm.c  |  6 +++
 xen/arch/x86/hvm/svm/vmcb.c | 17 -
 xen/include/asm-x86/hvm/svm/nestedsvm.h |  1 +
 4 files changed, 73 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 1f7b0d3e88..9295e583d7 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -1659,3 +1659,69 @@ void svm_vmexit_do_clgi(struct cpu_user_regs *regs, 
struct vcpu *v)
 
 __update_guest_eip(regs, inst_len);
 }
+
+/*
+ * This runs on EFER change to see if nested features need to either be
+ * turned off or on.
+ */
+void svm_nested_features_on_efer_update(struct vcpu *v)
+{
+struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+struct nestedsvm *svm = _nestedsvm(v);
+u32 general2_intercepts;
+vintr_t vintr;
+
+/*
+ * Need state for transfering the nested gif status so only write on
+ * the hvm_vcpu EFER.SVME changing.
+ */
+if ( v->arch.hvm_vcpu.guest_efer & EFER_SVME )
+{
+if ( !vmcb->virt_ext.fields.vloadsave_enable &&
+ paging_mode_hap(v->domain) &&
+ cpu_has_svm_vloadsave )
+{
+vmcb->virt_ext.fields.vloadsave_enable = 1;
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts &= ~(GENERAL2_INTERCEPT_VMLOAD |
+ GENERAL2_INTERCEPT_VMSAVE);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+
+if ( !vmcb->_vintr.fields.vgif_enable &&
+ cpu_has_svm_vgif )
+{
+vintr = vmcb_get_vintr(vmcb);
+vintr.fields.vgif = svm->ns_gif;
+vintr.fields.vgif_enable = 1;
+vmcb_set_vintr(vmcb, vintr);
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts &= ~(GENERAL2_INTERCEPT_STGI |
+ GENERAL2_INTERCEPT_CLGI);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+}
+else
+{
+if ( vmcb->virt_ext.fields.vloadsave_enable )
+{
+vmcb->virt_ext.fields.vloadsave_enable = 0;
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts |= (GENERAL2_INTERCEPT_VMLOAD |
+GENERAL2_INTERCEPT_VMSAVE);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+
+if ( vmcb->_vintr.fields.vgif_enable )
+{
+vintr = vmcb_get_vintr(vmcb);
+svm->ns_gif = vintr.fields.vgif;
+vintr.fields.vgif_enable = 0;
+vmcb_set_vintr(vmcb, vintr);
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts |= (GENERAL2_INTERCEPT_STGI |
+GENERAL2_INTERCEPT_CLGI);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+}
+}
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index c48fdfaa5d..be08a5aa5e 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -611,6 +611,12 @@ static void svm_update_guest_efer(struct vcpu *v)
 if ( lma )
 new_efer |= EFER_LME;
 vmcb_set_efer(vmcb, new_efer);
+
+if ( !nestedhvm_enabled(v->domain) )
+ASSERT(!(v->arch.hvm_vcpu.guest_efer & EFER_SVME));
+
+if ( nestedhvm_enabled(v->domain) )
+svm_nested_features_on_efer_update(v);
 }
 
 static void svm_cpuid_policy_changed(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 0e6cba5b7b..997e7597e0 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -200,29 +200,12 @@ static int construct_vmcb(struct vcpu *v)
 
 /* PAT is under complete control of SVM when using nested paging. */
 svm_disable_intercept_for_msr(v, MSR_IA32_CR_PAT);
-
-/* Use virtual VMLOAD/VMSAVE if available. */
-if ( cpu_has_svm_vloadsave )
-{
-vmcb->virt_ext.fields.vloadsave_enable = 1;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMLOAD;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMSAVE;
-}
 }
 else
 {
 vmcb->_exception_intercepts |= (1U << TRAP_page_fault);
 }
 
-/* if available, enable and configure virtual gif */
-if ( cpu_has_svm_vgif )
-{
-vmcb->_vintr.fields.vgif = 1;
-vmcb->_vintr.fields.vgif_enable = 1;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_STGI;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_CLGI;
-}
-

Re: [Xen-devel] Slow HVM boot time, was "HVM boot time optimization"

2018-02-08 Thread Anthony PERARD

On Thu, Feb 08, 2018 at 04:48:10PM +, Wei Liu wrote:
> On Thu, Feb 08, 2018 at 08:31:40AM -0800, Stefano Stabellini wrote:
> > CC'ing xen-devel and a few relevant people
> > 
> > On Thu, 8 Feb 2018, Yessine Daoud wrote:
> > > Dear Sir,
> > > I need your help please.
> > > 
> > > I am using a direct kernel boot (HVM guest) with kernel + ramdisk.
> > > At boot, seabios is bloqued about 20 seconds (or more) at the following 
> > > state:
> > > 
> 
> The manual seems a bit confusing to me but maybe I misremember how it
> works. My understanding is direct kernel boot jumps straight to kernel
> entry point without going through firmware.
> 
> If this is direct kernel boot why is seabios involved?

seabios is the one to load the kernel into memory and start it.

-- 
Anthony PERARD

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Slow HVM boot time, was "HVM boot time optimization"

On Thu, Feb 08, 2018 at 08:31:40AM -0800, Stefano Stabellini wrote:
> CC'ing xen-devel and a few relevant people
> 
> On Thu, 8 Feb 2018, Yessine Daoud wrote:
> > Dear Sir,
> > I need your help please.
> > 
> > I am using a direct kernel boot (HVM guest) with kernel + ramdisk.
> > At boot, seabios is bloqued about 20 seconds (or more) at the following 
> > state:
> > 

The manual seems a bit confusing to me but maybe I misremember how it
works. My understanding is direct kernel boot jumps straight to kernel
entry point without going through firmware.

If this is direct kernel boot why is seabios involved?

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Slow HVM boot time, was "HVM boot time optimization"

On Thu, Feb 8, 2018 at 4:31 PM, Stefano Stabellini
 wrote:
> CC'ing xen-devel and a few relevant people
>
> On Thu, 8 Feb 2018, Yessine Daoud wrote:
>> Dear Sir,
>> I need your help please.
>>
>> I am using a direct kernel boot (HVM guest) with kernel + ramdisk.
>> At boot, seabios is bloqued about 20 seconds (or more) at the following 
>> state:
>>
>> (d4) RamSizeOver4G: 0x [cmos]
>> (d4) boot order:
>> (d4) 1: /rom@genroms/linuxboot.bin
>> (d4) Found 4 PCI devices (max PCI bus is 00)
>> (d4) Allocated Xen hypercall page at 000
>> (d4) Detected Xen v4.9-unstable
>> (d4) xen: copy BIOS tables...
>> (d4) Copying SMBIOS entry point from 0x00010020 to 0x000f69b0
>> (d4) Copying MPTABLE from 0xfc001170/fc001180 to 0x000f68b0
>> (d4) Copying PIR from 0x00010040 to 0x000f6830
>> (d4) CPU Mhz=1335
>> (d4) Scan for VGA option rom
>> (d4) ATA controller 1 at 1f0/3f4/c100 (irq 14 dev 9)
>> (d4) ATA controller 2 at 170/374/c108 (irq 15 dev 9)
>> (d4) Found 0 lpt ports
>> (d4) Found 1 serial ports
>> (d4) PS2 keyboard initialized
>> (d4) All threads complete.
>> (d4) Scan for option roms
>> (d4) Running option rom at c000:0003
>> (d4) Searching bootorder for: /rom@genroms/linuxboot.bin
>> (d4) Searching bootorder for: HALT
>> (d4) Space available for UMB: c0800-ec800, f61d0-f67f0
>> (d4) Returned 258048 bytes of ZoneHigh
>> (d4) e820 map has 6 items:
>> (d4)   0:  - 0009fc00 = 1 RAM
>> (d4)   1: 0009fc00 - 000a = 2 RESERVED
>> (d4)   2: 000f - 0010 = 2 RESERVED
>> (d4)   3: 0010 - 0000 = 1 RAM
>> (d4)   4: 0000 - 1000 = 2 RESERVED
>> (d4)   5: fc00 - 0001 = 2 RESERVED
>> (d4) enter handle_19:
>> (d4)   NULL
>> (d4) Booting from ROM...
>> (d4) Booting from c000:00
>>
>>
>> Then (after 20 seconds) the kernel starts booting.
>> Any idea about this behavior?
>
> I am guessing one of the ROMs take a long time to run. It might be
> waiting for a timeout, like ipxe. Does anybody know about this issue?

The ipxe roms should only be loaded if specified in the VM config
file, right?  Why would you specify ipxe if you're going to be
direct-booting anyway?

 -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Slow HVM boot time, was "HVM boot time optimization"

CC'ing xen-devel and a few relevant people

On Thu, 8 Feb 2018, Yessine Daoud wrote:
> Dear Sir,
> I need your help please.
> 
> I am using a direct kernel boot (HVM guest) with kernel + ramdisk.
> At boot, seabios is bloqued about 20 seconds (or more) at the following state:
> 
> (d4) RamSizeOver4G: 0x [cmos]
> (d4) boot order:
> (d4) 1: /rom@genroms/linuxboot.bin
> (d4) Found 4 PCI devices (max PCI bus is 00)
> (d4) Allocated Xen hypercall page at 000
> (d4) Detected Xen v4.9-unstable
> (d4) xen: copy BIOS tables...
> (d4) Copying SMBIOS entry point from 0x00010020 to 0x000f69b0
> (d4) Copying MPTABLE from 0xfc001170/fc001180 to 0x000f68b0
> (d4) Copying PIR from 0x00010040 to 0x000f6830
> (d4) CPU Mhz=1335
> (d4) Scan for VGA option rom
> (d4) ATA controller 1 at 1f0/3f4/c100 (irq 14 dev 9)
> (d4) ATA controller 2 at 170/374/c108 (irq 15 dev 9)
> (d4) Found 0 lpt ports
> (d4) Found 1 serial ports
> (d4) PS2 keyboard initialized
> (d4) All threads complete.
> (d4) Scan for option roms
> (d4) Running option rom at c000:0003
> (d4) Searching bootorder for: /rom@genroms/linuxboot.bin
> (d4) Searching bootorder for: HALT
> (d4) Space available for UMB: c0800-ec800, f61d0-f67f0
> (d4) Returned 258048 bytes of ZoneHigh
> (d4) e820 map has 6 items:
> (d4)   0:  - 0009fc00 = 1 RAM
> (d4)   1: 0009fc00 - 000a = 2 RESERVED
> (d4)   2: 000f - 0010 = 2 RESERVED
> (d4)   3: 0010 - 0000 = 1 RAM
> (d4)   4: 0000 - 1000 = 2 RESERVED
> (d4)   5: fc00 - 0001 = 2 RESERVED
> (d4) enter handle_19:
> (d4)   NULL
> (d4) Booting from ROM...
> (d4) Booting from c000:00
> 
> 
> Then (after 20 seconds) the kernel starts booting.
> Any idea about this behavior?

I am guessing one of the ROMs take a long time to run. It might be
waiting for a timeout, like ipxe. Does anybody know about this issue?___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 0/7] xen/arm: PSCI 1.1 and SMCCC-1.1 support and XSA-254 variant 2 update

On 08/02/18 16:26, Manish Jaggi wrote:

On 02/05/2018 06:50 PM, Julien Grall wrote:

Hi all,

Arm has recently published a SMC Calling Convention (SMCCC)
specification update [1] that provides an optimised calling convention
and optional, discoverable support for mitigating CVE-2017-5715 (XSA-254
variant 2). ARM Trusted Firmware (ATF) has already gained such an
implementation[2].

This series addresses a few things:

- It provides a Xen implementation of PSCI v1.0, which is a
prerequisite

for being able to discover SMCCC v1.1.
- It allows Xen to advertise SMCCC v1.1
- It implements Xen support for the ARM_WORKAROUND_1 function
that is used

to mitigate CVE-2017-5715 (if such mitigation is available on the
hypervisor).

This method is intended to fully replace the initial PSCI_GET_VERSION
approach. Although PSCI_GET_VERSION still works, it has an obvious
overhead and is called on some of the hottest paths. We expect
ARCH_WORKAROUND_1 to be much faster.

Another series will be sent to allow the hypervisor discovering SMCCC
1.1 and

use it for the mitigation.

This series is based on the "xen/arm: SMCCC fixes and PSCI clean-up"
one [3].

Cheers,

[1]:
https://developer.arm.com/-/media/developer/pdf/ARM%20DEN%200070A%20Firmware%20interfaces%20for%20mitigating%20CVE-2017-5715_V1.0.pdf

This link is not working.

Because the link has been relocated since then. You can find it at:

https://developer.arm.com/support/security-update/downloads

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 0/7] xen/arm: PSCI 1.1 and SMCCC-1.1 support and XSA-254 variant 2 update

2018-02-08 Thread Manish Jaggi


Hi Julien,


On 02/05/2018 06:50 PM, Julien Grall wrote:

Hi all,

Arm has recently published a SMC Calling Convention (SMCCC)
specification update [1] that provides an optimised calling convention
and optional, discoverable support for mitigating CVE-2017-5715 (XSA-254
variant 2). ARM Trusted Firmware (ATF) has already gained such an
implementation[2].

This series addresses a few things:

 - It provides a Xen implementation of PSCI v1.0, which is a prerequisite
   for being able to discover SMCCC v1.1.
 - It allows Xen to advertise SMCCC v1.1
 - It implements Xen support for the ARM_WORKAROUND_1 function that is used
   to mitigate CVE-2017-5715 (if such mitigation is available on the
   hypervisor).

This method is intended to fully replace the initial PSCI_GET_VERSION
approach. Although PSCI_GET_VERSION still works, it has an obvious
overhead and is called on some of the hottest paths. We expect
ARCH_WORKAROUND_1 to be much faster.

Another series will be sent to allow the hypervisor discovering SMCCC 1.1 and
use it for the mitigation.

This series is based on the "xen/arm: SMCCC fixes and PSCI clean-up" one [3].

Cheers,

[1]: 
https://developer.arm.com/-/media/developer/pdf/ARM%20DEN%200070A%20Firmware%20interfaces%20for%20mitigating%20CVE-2017-5715_V1.0.pdf

This link is not working.


[2]: https://github.com/ARM-software/arm-trusted-firmware/pull/1240

[3] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00117.html

Julien Grall (7):
   xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu
   xen/arm: psci: Rework the PSCI definitions
   xen/arm: vpsci: Add support for PSCI 1.1
   xen/arm: vsmc: Implement SMCCC 1.1
   xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support
   xen/arm: Adapt smccc.h to be able to use it in assembly code
   xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

  tools/libxl/libxl_arm.c  |  3 +-
  xen/arch/arm/arm64/entry.S   | 56 +-
  xen/arch/arm/domain_build.c  |  1 +
  xen/arch/arm/platforms/seattle.c |  4 +-
  xen/arch/arm/psci.c  | 10 ++---
  xen/arch/arm/vpsci.c | 85 +---
  xen/arch/arm/vsmc.c  | 41 +++
  xen/include/asm-arm/perfc_defn.h |  1 +
  xen/include/asm-arm/processor.h  |  2 +
  xen/include/asm-arm/psci.h   | 38 ++
  xen/include/asm-arm/smccc.h  | 37 ++---
  xen/include/asm-arm/vpsci.h  |  2 +-
  12 files changed, 225 insertions(+), 55 deletions(-)




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GSOC] Xen on ARM: create multiple guests from device tree

On Thu, 8 Feb 2018, Denis Obrezkov wrote:
> > Good! Please compile Xen for ARM64 and try to boot Xen and Dom0 with it.
> > Once you have Xen and Dom0 up and running, you can try to create a small
> > guest and start that as well. It will help you setup your build and test
> > environments.
> >
> > To build Xen for ARM64, you can use native compilation inside the
> > qemu-system-aarch64 emulation, but it is slow. Otherwise you can use
> > chroot and qemu-aarch64-static (the qemu-user aarch64 target, statically
> > compiled). For example give a look at:
> >
> > https://wiki.debian.org/Arm64Qemu
> >
> >
> > The end goal of the project is to be able to boot two domains directly
> > from Xen. Typically, Xen boots Dom0, then only once Dom0 is fully up and
> > running, a second domain can be created and that is done via the Xen
> > tools (xl). However, it is not always necessary to wait until Dom0 is
> > fully booted before starting a second guest. In many embedded
> > environments, you only have two or three guests in total to deal with.
> > It would be better to create them all in parallel directly from Xen. It
> > would drastically shorten the boot time.
> >
> > Device tree is used to describe the hardware available on the platform.
> > It comes into play in this project because it is the best way to pass
> > the required information to Xen, so that Xen knows it needs to boot a
> > second guest in addition to Dom0.
> >
> > Before we start the main project though, we usually ask candidates to
> > send a patch to fix a small issue just to show that they managed to
> > setup a dev and test environment correctly. We'll come back with a list
> > of potential small issues to fix shortly.
> >
> >
> >> I have also proposed to make a port of xen for qemu-system-riscv (it
> >> should be ready in Q2.2018) to people from riscv but I haven't
> >> received any answer.Anyway, I would like to work with xen on embedded
> >> platforms.
> >
> > That would be awesome, but I don't think that a project like porting Xen
> > to riscv would fit in a GSoC project :-)
> Thanks, I will try to do it this weekend.
> 
> Though, I want to note, that I probably won't participate in GSoC if
> Google continue their discrimination payment policy. For example, last
> year I've made a port of RTEMS for RISC-V and received $3600. At the
> same time one of the RTEMS project participants did almost nothing and
> was expelled from the program before the final evaluation and
> received...$3600. That was unfair! Could you imagine what my fellow
> from India felt who made an excellent project and received only $2400.
> 
> P.S. Is xen-project going to participate in Outreachy?

Yes, Xen Project is participating in Outreachy, and this specific Xen on
ARM project will also be available there.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

2018-02-08 Thread Brian Woods

On Thu, Feb 08, 2018 at 02:45:31AM -0700, Jan Beulich wrote:
> I'm afraid I continue to be confused: A function with this name should
> imo, as said earlier, live in nestedsvm.c. However ...

I'll move it to nestedsvm.c then. 

> ... this indicates that the function does something even for the
> non-nested case. In particular ...

It makes sure that SVME isn't set when nested isn't enabled.  

If SVME is set it does certain checks to enable features if enabled.
Else it makes sure nested features are turned off.

The reason for this is that, with VGIF/VVMLOAD, they can still work even
with SVME not being set.  This sets it where they get intercepted to Xen
so that Xen can correctly emulate what should be happening.  If SVME
isn't set then nested guest shouldn't be able to do VGIF/VVMLOAD. 

> ... this entire else block. Is it necessary to do this in the non-nested
> case? IOW - do these settings ever change there (I would have
> thought that the two *_enable fields checked by the two if()s should
> never be true for nested-disabled guests)? Otherwise, as also said
> before, the caller should call here only when
> nestedhvm_enabled(v->domain), and the function would better
> move.
> 
> Jan

It only checks two things (two if statements) in the VMCB per EFER
update.  Suppose you add an if to check if it's a nested guest and then
run the nested_features func.  You're only saving a total of one if and
going in and out a function but you add a small divergence in the
codepath.  If this was a long computer/IO intense function, I'd
completely agree but this is two very simple checks.

I'll change it though, since it'll be easier than going back and forth
about a minor detail.

-- 
Brian Woods

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

2018-02-08 Thread Alexey G

On Thu, 8 Feb 2018 15:00:33 +
Andrew Cooper  wrote:

>On 08/02/18 14:37, Alexey G wrote:
>> On Thu, 8 Feb 2018 12:40:41 +
>> Andrew Cooper  wrote:  
>>> - Perf/Oprofile.  This is currently mutually exclusive with Xen
>>> using the watchdog, but needn't be and hopefully won't be in the
>>> future. 
 Most of the time we deal with watchdog NMIs, while all others
 should be somewhat rare. The thing is, we actually need to read
 I/O port 61h on system NMIs only. 

 If the main problem lies in a flow of SMIs due to reading port 61h
 on every NMI watchdog tick -- why not to avoid reading it?

 There are at least 2 ways to check if the NMI was due to a watchdog
 tick:
 - LAPIC (SDM states that "When a performance monitoring counters
 interrupt is generated, the mask bit for its associated LVT entry
 is set")
 - perf MSR overflow bit

 So, if we detect it was a NMI due to a watchdog using these
 methods (early in the NMI handler), we can avoid touching the port
 61h and thus triggering SMI I/O trap on it.
>>> The problem is having multiple NMIs arriving.  Like all other edge
>>> triggered interrupts, extra arrivals get dropped.  By skipping the
>>> 0x61 read if we believe it was a watchdog NMI, we've opened a race
>>> condition where we will completely miss the system NMI.  
>> There shouldn't be any problem I think. NMIs don't need to be cleared
>> with EOI and it's a common practice to handle NMIs one-by-one (as a
>> NMI handler is not reentrant in a typical scenario).
>>
>> Execution of SMI doesn't cause a pending (blocked) NMI to get
>> dropped, similar mechanisms might be employed for a single NMI which
>> arrived in blocked-by-NMI state. Otherwise the whole thing will
>> break -- merely handling arbitrary NMI will be enough to miss any
>> other NMIs. This is a too obvious flaw. So normally it should be
>> just a matter which NMI of two will be serviced first.
>> This assumption can be verified empirically by requesting the chipset
>> to send an external NMI while serving a watchdog NMI and checking if
>> it arrive later on.  

>NMI handling works just like other interrupts, except that its
>equivalent of the ISR/IRR state is hidden.
>
>One new NMI will become pending while an NMI is in progress (because
>there is an IRR bit to be set), but any further will be dropped.
>
>You can demonstrate this easily by having CPUs or the chipset send
>NMIs.

One in service with one pending is enough for our scenario. It covers
the situation when either watchdog or external NMI being serviced and
another (single) NMI arrived. As long as two of these are serviced one
after another, there shouldn't be trouble in missing NMIs due to NMI
status misunderstanding -- all related status bits are sticky (incl.
Mask bit in LAPIC) and and won't go away if two NMIs executed in either
order, provided they both executed.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 1/4] asm-x86/monitor: Enable svm monitor events

This commit separates the svm caps from the vmx caps.

Signed-off-by: Alexandru Isaila 

---
Changes since V1:
- Removed the if ( cpu_has_svm )
---
 xen/include/asm-x86/monitor.h | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index a0444d1..b2b4e6a 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -71,24 +71,28 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 uint32_t capabilities = 0;
 
 /*
- * At the moment only Intel HVM domains are supported. However, event
- * delivery could be extended to AMD and PV domains.
+ * At the moment only Intel and AMD HVM domains are supported. However, 
event
+ * delivery could be extended to and PV domains.
  */
-if ( !is_hvm_domain(d) || !cpu_has_vmx )
+if ( !is_hvm_domain(d) )
 return capabilities;
 
-capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
-
-/* Since we know this is on VMX, we can just call the hvm func */
-if ( hvm_is_singlestep_supported() )
-capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
+if( cpu_has_vmx )
+{
+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
+
+/* Since we know this is on VMX, we can just call the hvm func */
+if ( hvm_is_singlestep_supported() )
+capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
+}
+
+capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
 
 if ( hvm_funcs.set_descriptor_access_exiting )
 capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS);
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 4/4] hvm/svm: Enable CR events

This commit enables controlregister events for svm.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/svm/svm.c| 11 +++
 xen/include/asm-x86/monitor.h |  6 +++---
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 1eadab4..311902f 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -60,6 +60,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 void svm_asm_do_resume(void);
@@ -560,6 +561,16 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int cr)
 svm_fpu_enter(v);
 }
 
+if ( paging_mode_hap(v->domain) )
+{
+uint32_t intercepts = vmcb_get_cr_intercepts(vmcb);
+
+/* Trap CR3 updates if CR3 memory events are enabled. */
+if ( v->domain->arch.monitor.write_ctrlreg_enabled &
+ monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
+   vmcb_set_cr_intercepts(vmcb, intercepts | 
CR_INTERCEPT_CR3_WRITE);
+}
+
 value = v->arch.hvm_vcpu.guest_cr[0] | hw_cr0_mask;
 if ( !paging_mode_hap(v->domain) )
 value |= X86_CR0_PG | X86_CR0_WP;
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 138c463..b80d217 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -79,8 +79,7 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 
 if( cpu_has_vmx )
 {
-capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
(1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
(1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
(1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
@@ -92,7 +91,8 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 
 capabilities |= ((1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
 (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
-(1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR));
+(1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
+(1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG));
 
 if ( hvm_funcs.set_descriptor_access_exiting )
 capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS);
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 2/4] hvm/svm: Enable Breakpoint events

This commit enables the breakpoint events for svm.

Signed-off-by: Alexandru Isaila 

---
Changes since V1:
- Clean up bool_t
- Removed event.insn_len = 0
- Switched the v->domain->debugger_attached if
- Add a extra pair of brachets for the capab var.
---
 xen/arch/x86/hvm/svm/svm.c| 48 +++
 xen/include/asm-x86/monitor.h |  4 ++--
 2 files changed, 42 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index dcbd550..a14caab 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 void svm_asm_do_resume(void);
@@ -1079,7 +1080,8 @@ static void svm_ctxt_switch_to(struct vcpu *v)
 static void noreturn svm_do_resume(struct vcpu *v)
 {
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
-bool_t debug_state = v->domain->debugger_attached;
+bool debug_state = v->domain->debugger_attached
+|| v->domain->arch.monitor.software_breakpoint_enabled;
 bool_t vcpu_guestmode = 0;
 struct vlapic *vlapic = vcpu_vlapic(v);
 
@@ -2407,6 +2409,19 @@ static bool svm_get_pending_event(struct vcpu *v, struct 
x86_event *info)
 return true;
 }
 
+static void svm_propagate_intr(struct vcpu *v, unsigned long insn_len)
+{
+struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+struct x86_event event = {
+.vector = vmcb->eventinj.fields.type,
+.type = vmcb->eventinj.fields.type,
+.error_code = vmcb->exitinfo1,
+};
+
+event.insn_len = insn_len;
+hvm_inject_event();
+}
+
 static struct hvm_function_table __initdata svm_function_table = {
 .name = "SVM",
 .cpu_up_prepare   = svm_cpu_up_prepare,
@@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 break;
 
 case VMEXIT_EXCEPTION_BP:
-if ( !v->domain->debugger_attached )
-goto unexpected_exit_type;
-/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. */
-if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
+inst_len = __get_instruction_length(v, INSTR_INT3);
+
+if ( inst_len == 0 )
 break;
-__update_guest_eip(regs, inst_len);
-current->arch.gdbsx_vcpu_event = TRAP_int3;
-domain_pause_for_debugger();
+
+if ( v->domain->debugger_attached )
+{
+__update_guest_eip(regs, inst_len);
+current->arch.gdbsx_vcpu_event = TRAP_int3;
+domain_pause_for_debugger();
+}
+else
+{
+/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. */
+   int rc;
+
+   rc = hvm_monitor_debug(regs->rip,
+  HVM_MONITOR_SOFTWARE_BREAKPOINT,
+  X86_EVENTTYPE_SW_EXCEPTION,
+  inst_len);
+   if ( rc < 0 )
+   goto unexpected_exit_type;
+   if ( !rc )
+   svm_propagate_intr(v, inst_len);
+}
 break;
 
 case VMEXIT_EXCEPTION_NM:
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index b2b4e6a..68e62bd 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -81,7 +81,6 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 {
 capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
(1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
(1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
(1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
(1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
@@ -92,7 +91,8 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
 }
 
-capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
+capabilities |= ((1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
+(1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT));
 
 if ( hvm_funcs.set_descriptor_access_exiting )
 capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS);
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 0/4] hvm/svm: Enable vm events for SVM

Hi all,

This series provides a skeleton for enabling vm_events on SVM. For the
first step, the MSR, CR, Breakpoint and GuestRequest have been tested
and added to the capabilities list.

Cheers,

Alexandru Isaila

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 3/4] hvm/svm: Enable MSR events

This commit enables MSR events for svm.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/svm/svm.c| 9 +
 xen/include/asm-x86/monitor.h | 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index a14caab..1eadab4 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -163,6 +163,14 @@ void svm_intercept_msr(struct vcpu *v, uint32_t msr, int 
flags)
 __clear_bit(msr * 2 + 1, msr_bit);
 }
 
+static void svm_enable_msr_interception(struct domain *d, uint32_t msr)
+{
+struct vcpu *v;
+
+for_each_vcpu ( d, v )
+svm_intercept_msr(v, msr, MSR_INTERCEPT_WRITE);
+}
+
 static void svm_save_dr(struct vcpu *v)
 {
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
@@ -2460,6 +2468,7 @@ static struct hvm_function_table __initdata 
svm_function_table = {
 .fpu_dirty_intercept  = svm_fpu_dirty_intercept,
 .msr_read_intercept   = svm_msr_read_intercept,
 .msr_write_intercept  = svm_msr_write_intercept,
+.enable_msr_interception = svm_enable_msr_interception,
 .set_rdtsc_exiting= svm_set_rdtsc_exiting,
 .set_descriptor_access_exiting = svm_set_descriptor_access_exiting,
 .get_insn_bytes   = svm_get_insn_bytes,
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 68e62bd..138c463 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -80,7 +80,6 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 if( cpu_has_vmx )
 {
 capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
(1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
(1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
(1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
@@ -92,7 +91,8 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 }
 
 capabilities |= ((1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
-(1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT));
+(1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
+(1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR));
 
 if ( hvm_funcs.set_descriptor_access_exiting )
 capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS);
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 08/02/18 14:37, Alexey G wrote:
> On Thu, 8 Feb 2018 12:40:41 +
> Andrew Cooper  wrote:
>> - Perf/Oprofile.  This is currently mutually exclusive with Xen using
>> the watchdog, but needn't be and hopefully won't be in the future.
>>
>>> Most of the time we deal with watchdog NMIs, while all others should
>>> be somewhat rare. The thing is, we actually need to read I/O port
>>> 61h on system NMIs only. 
>>>
>>> If the main problem lies in a flow of SMIs due to reading port 61h on
>>> every NMI watchdog tick -- why not to avoid reading it?
>>>
>>> There are at least 2 ways to check if the NMI was due to a watchdog
>>> tick:
>>> - LAPIC (SDM states that "When a performance monitoring counters
>>> interrupt is generated, the mask bit for its associated LVT entry is
>>> set")
>>> - perf MSR overflow bit
>>>
>>> So, if we detect it was a NMI due to a watchdog using these
>>> methods (early in the NMI handler), we can avoid touching the port
>>> 61h and thus triggering SMI I/O trap on it.  
>> The problem is having multiple NMIs arriving.  Like all other edge
>> triggered interrupts, extra arrivals get dropped.  By skipping the 0x61
>> read if we believe it was a watchdog NMI, we've opened a race condition
>> where we will completely miss the system NMI.
> There shouldn't be any problem I think. NMIs don't need to be cleared
> with EOI and it's a common practice to handle NMIs one-by-one (as a NMI
> handler is not reentrant in a typical scenario).
>
> Execution of SMI doesn't cause a pending (blocked) NMI to get dropped,
> similar mechanisms might be employed for a single NMI which arrived in
> blocked-by-NMI state. Otherwise the whole thing will break -- merely
> handling arbitrary NMI will be enough to miss any other NMIs. This is a
> too obvious flaw. So normally it should be just a matter which NMI of
> two will be serviced first.
> This assumption can be verified empirically by requesting the chipset
> to send an external NMI while serving a watchdog NMI and checking if it
> arrive later on.

NMI handling works just like other interrupts, except that its
equivalent of the ISR/IRR state is hidden.

One new NMI will become pending while an NMI is in progress (because
there is an IRR bit to be set), but any further will be dropped.

You can demonstrate this easily by having CPUs or the chipset send NMIs.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v1 2/5] libxl: add vsnd list and info

On Thu, Feb 08, 2018 at 04:40:31PM +0200, Oleksandr Grytsov wrote:
> freed with appropriate API. Using libxl__realloc will cause double free
> issue.

Use libxl__realloc(NOGC, ...) to avoid that issue.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v1 2/5] libxl: add vsnd list and info

2018-02-08 Thread Oleksandr Grytsov

On Tue, Feb 6, 2018 at 4:43 PM, Wei Liu  wrote:

> On Wed, Nov 01, 2017 at 05:04:44PM +0200, Oleksandr Grytsov wrote:
> > From: Oleksandr Grytsov 
> >
> > Add getting vsnd list amd info API
> >
> > Signed-off-by: Oleksandr Grytsov 
> > ---
> >  tools/libxl/libxl.h |  10 ++
> >  tools/libxl/libxl_types.idl |  19 +++
> >  tools/libxl/libxl_utils.h   |   3 +
> >  tools/libxl/libxl_vsnd.c| 375 ++
> +-
> >  4 files changed, 404 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index 7200d49..acb73ce 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -1927,6 +1927,16 @@ int libxl_device_vsnd_destroy(libxl_ctx *ctx,
> uint32_t domid,
> >const libxl_asyncop_how *ao_how)
> >LIBXL_EXTERNAL_CALLERS_ONLY;
> >
> > +libxl_device_vsnd *libxl_device_vsnd_list(libxl_ctx *ctx,
> > +  uint32_t domid, int *num)
> > +  LIBXL_EXTERNAL_CALLERS_ONLY;
> > +void libxl_device_vsnd_list_free(libxl_device_vsnd* list, int num)
> > + LIBXL_EXTERNAL_CALLERS_ONLY;
> > +int libxl_device_vsnd_getinfo(libxl_ctx *ctx, uint32_t domid,
> > +  libxl_device_vsnd *vsnd,
> > +  libxl_vsndinfo *vsndlinfo)
> > +  LIBXL_EXTERNAL_CALLERS_ONLY;
> > +
> >  /* Keyboard */
> >  int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid,
> libxl_device_vkb *vkb,
> >   const libxl_asyncop_how *ao_how)
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index aa30196..553e724 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -988,6 +988,25 @@ libxl_vdisplinfo = Struct("vdisplinfo", [
> >  ("connectors", Array(libxl_connectorinfo, "num_connectors"))
> >  ], dir=DIR_OUT)
> >
> > +libxl_streaminfo = Struct("streaminfo", [
> > +("req_evtch", integer),
> > +("req_rref", integer)
> > +])
> > +
> > +libxl_pcminfo = Struct("pcminfo", [
> > +("streams", Array(libxl_streaminfo, "num_vsnd_streams"))
> > +])
> > +
> > +libxl_vsndinfo = Struct("vsndinfo", [
> > +("backend", string),
> > +("backend_id", uint32),
> > +("frontend", string),
> > +("frontend_id", uint32),
> > +("devid", libxl_devid),
> > +("state", integer),
> > +("pcms", Array(libxl_pcminfo, "num_vsnd_pcms"))
> > +])
> > +
> >  # NUMA node characteristics: size and free are how much memory it has,
> and how
> >  # much of it is free, respectively. dists is an array of distances from
> this
> >  # node to each other node.
> > diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> > index 9e743dc..5455752 100644
> > --- a/tools/libxl/libxl_utils.h
> > +++ b/tools/libxl/libxl_utils.h
> > @@ -82,6 +82,9 @@ int libxl_devid_to_device_usbctrl(libxl_ctx *ctx,
> uint32_t domid,
> >  int libxl_devid_to_device_vdispl(libxl_ctx *ctx, uint32_t domid,
> >   int devid, libxl_device_vdispl
> *vdispl);
> >
> > +int libxl_devid_to_device_vsnd(libxl_ctx *ctx, uint32_t domid,
> > +   int devid, libxl_device_vsnd *vsnd);
> > +
> >  int libxl_ctrlport_to_device_usbdev(libxl_ctx *ctx, uint32_t domid,
> >  int ctrl, int port,
> >  libxl_device_usbdev *usbdev);
> > diff --git a/tools/libxl/libxl_vsnd.c b/tools/libxl/libxl_vsnd.c
> > index 99e4be3..35f1aed 100644
> > --- a/tools/libxl/libxl_vsnd.c
> > +++ b/tools/libxl/libxl_vsnd.c
> > @@ -37,22 +37,247 @@ static int libxl__device_from_vsnd(libxl__gc *gc,
> uint32_t domid,
> > return 0;
> >  }
> >
> > +static int libxl__sample_rates_from_string(libxl__gc *gc, const char
> *str,
> > +   libxl_vsnd_params *params)
> > +{
> > +char *tmp = libxl__strdup(gc, str);
> > +
> > +params->num_sample_rates = 0;
> > +params->sample_rates = NULL;
> > +
> > +char *p = strtok(tmp, " ,");
> > +
> > +while (p != NULL) {
> > +params->sample_rates = realloc(params->sample_rates,
> > +   sizeof(*params->sample_rates) *
> > +   (params->num_sample_rates + 1));
>
> This is problematic. You need to check if realloc returns NULL before
> overwriting sample_rates.
>
> It is also a bit expensive to realloc 1 element at a time. Is is
> possible to know the size before hand? If not, then fine.
>
> Please use libxl__realloc instead. We have quite a few wrappers in
> libxl. In general please use them unless you have very compelling reason
> not to.
>
> There could be other places in your two series that I missed, please fix
> them.
>

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

2018-02-08 Thread Alexey G

On Thu, 8 Feb 2018 12:40:41 +
Andrew Cooper  wrote:
>- Perf/Oprofile.  This is currently mutually exclusive with Xen using
>the watchdog, but needn't be and hopefully won't be in the future.
>
>>
>> Most of the time we deal with watchdog NMIs, while all others should
>> be somewhat rare. The thing is, we actually need to read I/O port
>> 61h on system NMIs only. 
>>
>> If the main problem lies in a flow of SMIs due to reading port 61h on
>> every NMI watchdog tick -- why not to avoid reading it?
>>
>> There are at least 2 ways to check if the NMI was due to a watchdog
>> tick:
>> - LAPIC (SDM states that "When a performance monitoring counters
>> interrupt is generated, the mask bit for its associated LVT entry is
>> set")
>> - perf MSR overflow bit
>>
>> So, if we detect it was a NMI due to a watchdog using these
>> methods (early in the NMI handler), we can avoid touching the port
>> 61h and thus triggering SMI I/O trap on it.  
>
>The problem is having multiple NMIs arriving.  Like all other edge
>triggered interrupts, extra arrivals get dropped.  By skipping the 0x61
>read if we believe it was a watchdog NMI, we've opened a race condition
>where we will completely miss the system NMI.

There shouldn't be any problem I think. NMIs don't need to be cleared
with EOI and it's a common practice to handle NMIs one-by-one (as a NMI
handler is not reentrant in a typical scenario).

Execution of SMI doesn't cause a pending (blocked) NMI to get dropped,
similar mechanisms might be employed for a single NMI which arrived in
blocked-by-NMI state. Otherwise the whole thing will break -- merely
handling arbitrary NMI will be enough to miss any other NMIs. This is a
too obvious flaw. So normally it should be just a matter which NMI of
two will be serviced first.
This assumption can be verified empirically by requesting the chipset
to send an external NMI while serving a watchdog NMI and checking if it
arrive later on.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC 2/8] public/io/netif: add directory for backend parameters

2018-02-08 Thread Joao Martins

On 02/08/2018 11:13 AM, Wei Liu wrote:
> On Wed, Feb 07, 2018 at 12:10:37PM +, Joao Martins wrote:
>> On 02/06/2018 05:12 PM, Wei Liu wrote:
>>> (Three months after you sent this, sorry...)
>>>
>>> On Mon, Nov 06, 2017 at 12:33:06PM +, Joao Martins wrote:
 On Mon, Nov 06, 2017 at 10:33:59AM +, Paul Durrant wrote:
>> -Original Message-
>> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
>> Sent: 02 November 2017 18:06
>> To: Xen Development List 
>> Cc: Joao Martins ; Konrad Rzeszutek Wilk
>> ; Paul Durrant ; Wei Liu
>> 
>> Subject: [PATCH RFC 2/8] public/io/netif: add directory for backend
>> parameters
>>
>> The proposed directory provides a mechanism for tools to control the
>> maximum feature set of the device being provisioned by backend.
>> The parameters/features include offloading features, number of
>> queues etc.
>>
>> Signed-off-by: Joao Martins 
>> ---
>>  xen/include/public/io/netif.h | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/xen/include/public/io/netif.h 
>> b/xen/include/public/io/netif.h
>> index 2454448baa..a412e4771d 100644
>> --- a/xen/include/public/io/netif.h
>> +++ b/xen/include/public/io/netif.h
>> @@ -161,6 +161,22 @@
>>   */
>>
>>  /*
>> + * The directory "require" maybe be created in backend path by tools
>> + * domain to override the maximum feature set that backend provides to
>> the
>> + * frontend. The children entries within this directory are features 
>> names
>> + * and the correspondent values that should be used backend as defaults
>> e.g.:
>> + *
>> + * /local/domain/X/backend///require
>> + * /local/domain/X/backend///require/multi-queue-
>> max-queues = "2"
>> + * /local/domain/X/backend///require/feature-no-csum-
>> offload = "1"
>> + *
>> + * In the example above, network backend will negotiate up to a maximum
>> of
>> + * two queues with frontend plus disabling IPv4 checksum offloading.
>> + *
>> + * This directory and its children entries shall only be visible to the 
>> backend.
>> + */
>> +
>
> What should happen if the toolstack sets something in 'require' that
> the backend cannot provide? I don't see anything in your RFC patches
> to check that the backend has responded appropriately to the keys.

 Hmm, you're right that this RFC doesn't handle that properly - but for the
 ones the backend provide I had suggested (albeit not implemented here)
 back in the other thread that we could compare the values of feature in
 "require" with the one announced to the frontend. But well this wouldn't
 cover the non-provided ones, and possibly would fall a bit as a hack.

 I could change the format of the entries within "require"
 directory to be e.g. "- = " and the
 acknowledgement entry would come in the form "-status
 = ". Consequently the lack of a "-status" entry would
 have a stronger semantic i.e. unsupported and ignored. The toolstack then 
 would have
 means to check whether the feature was really succesfull set as desired
 or not. But then one question comes to mind: should the backend be
 prevented to init in the event that the features requested fail to be
 set? In which case uevent (on Linux) isn't triggered and xenbus state 
 doesn't
 get changed and toolstack would fail with timeout later on.

>>>
>>> I think the backend should not proceed if it can't meet the
>>> requirements. But to be clear I also don't think the timeout behaviour
>>> should be used to determine if the setting is successful because it is
>>> asking other part of the system to pick up the slack and system
>>> administrators would be left in the dark (unless there is easily
>>> accessible message that can be obtained by libxl to return to system
>>> administrators).
>>
>> That timeout behaviour is already there *I think* (or maybe I have the wrong
>> impression)? The alternative is to trigger the uevent and add more logic on 
>> the
> 
> Yes, it is already there. Libxl will wait for the backend to change its
> state for X seconds.
> 
> The difference now is the system administrators can potentially easily
> trigger a timeout due to misconfiguration, while previously it is mostly
> due to the module not getting loaded or some other failures that are not
> the system administrators' fault.
> 
/nods

>> hotplug script to check if the parameters were set according to config, but 
>> OTOH
>> you add more complexity there. Or perhaps we can check that the backend set 
>> to
>> its state to Unknown (or some other state) and that determines the failure - 
>> but
>> still no uevent should be

[Xen-devel] [PATCH v3] xenbus: track caller request id

2018-02-08 Thread Joao Martins

Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent
xenstore accesses") optimized xenbus concurrent accesses but in doing so
broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus applications are in
charge of xenbus message exchange with the correct header and body. Now,
after the mentioned commit the replies received by application will no
longer have the header req_id echoed back as it was on request (see
specification below for reference), because that particular field is being
overwritten by kernel.

struct xsd_sockmsg
{
  uint32_t type;  /* XS_??? */
  uint32_t req_id;/* Request identifier, echoed in daemon's response.  */
  uint32_t tx_id; /* Transaction id (0 if not related to a transaction). */
  uint32_t len;   /* Length of data following this. */

  /* Generally followed by nul-terminated string(s). */
};

Before there was only one request at a time so req_id could simply be
forwarded back and forth. To allow simultaneous requests we need a
different req_id for each message thus kernel keeps a monotonic increasing
counter for this field and is written on every request irrespective of
userspace value.

Forwarding again the req_id on userspace requests is not a solution because
we would open the possibility of userspace-generated req_id colliding with
kernel ones. So this patch instead takes another route which is to
artificially keep user req_id while keeping the xenbus logic as is. We do
that by saving the original req_id before xs_send(), use the private kernel
counter as req_id and then once reply comes and was validated, we restore
back the original req_id.

Cc:  # 4.11
Fixes: fd8aa9095a ("xen: optimize xenbus driver for multiple concurrent 
xenstore accesses")
Reported-by: Bhavesh Davda 
Signed-off-by: Joao Martins 
Reviewed-by: Juergen Gross 
---
Here's a link to a unit test (https://pastebin.com/N0kqNBnM) where req_id of
reply and response are being asserted each request. Without this patch
the assert will fail (e.g. try it with `./xswire_reqid_test name`). But
on <= v4.10 or >= v4.11 with the fix above, it will print domain name 10
times.

Changes since v2:
 * Add Juergen's Reviewed-by

Changes since v1:
 * Adjust commit message
 (Comments from Juergen on IRC)
 * Unilateraly save/restore req_id and remove xs_request_is_user()
 * Initialize req_id for kernel callers
---
 drivers/xen/xenbus/xenbus.h   | 1 +
 drivers/xen/xenbus/xenbus_comms.c | 1 +
 drivers/xen/xenbus/xenbus_xs.c| 3 +++
 3 files changed, 5 insertions(+)

diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
index 149c5e7efc89..092981171df1 100644
--- a/drivers/xen/xenbus/xenbus.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -76,6 +76,7 @@ struct xb_req_data {
struct list_head list;
wait_queue_head_t wq;
struct xsd_sockmsg msg;
+   uint32_t caller_req_id;
enum xsd_sockmsg_type type;
char *body;
const struct kvec *vec;
diff --git a/drivers/xen/xenbus/xenbus_comms.c 
b/drivers/xen/xenbus/xenbus_comms.c
index 5b081a01779d..d239fc3c5e3d 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -309,6 +309,7 @@ static int process_msg(void)
goto out;
 
if (req->state == xb_req_state_wait_reply) {
+   req->msg.req_id = req->caller_req_id;
req->msg.type = state.msg.type;
req->msg.len = state.msg.len;
req->body = state.body;
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 3e59590c7254..3f3b29398ab8 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -227,6 +227,8 @@ static void xs_send(struct xb_req_data *req, struct 
xsd_sockmsg *msg)
req->state = xb_req_state_queued;
init_waitqueue_head(>wq);
 
+   /* Save the caller req_id and restore it later in the reply */
+   req->caller_req_id = req->msg.req_id;
req->msg.req_id = xs_request_enter(req);
 
mutex_lock(_write_mutex);
@@ -310,6 +312,7 @@ static void *xs_talkv(struct xenbus_transaction t,
req->num_vecs = num_vecs;
req->cb = xs_wake_up;
 
+   msg.req_id = 0;
msg.tx_id = t.id;
msg.type = type;
msg.len = 0;
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.9-testing test] 118658: regressions - FAIL

flight 118658 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118658/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
118524
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 118524

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 118347
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 118416
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118487
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 118524
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118524
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118524
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 118524
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 118524
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  4d01dbc7133e0c55aecb31d95cd461580241c576
baseline version:
 xen  a2567d6b54b7b187ecc0165021b6dd07dafaf06a

Last test of basis   118524  2018-02-02 01:00:58 Z6 days
Testing same since   118658  2018-02-07 17:13:52 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Marc Zyngier 

jobs:
 build-amd64-xsm

Re: [Xen-devel] [PATCH v3 2/2] x86/setup: remap Xen image up to PFN_DOWN(__pa(_end))

2018-02-08 Thread Daniel Kiper

Sorry for late reply but I was busy with other stuff.

On Fri, Jan 19, 2018 at 08:27:46AM -0700, Jan Beulich wrote:
> >>> On 10.01.18 at 14:05,  wrote:
> > Current limit, PFN_DOWN(xen_phys_start), introduced by commit b280442
> > (x86: make Xen early boot code relocatable) is not reliable. Potentially
> > its value may fall below PFN_DOWN(__pa(_end)) and then part of Xen image
> > may not be mapped after relocation. This will not happen in current code
> > thanks to "x86/setup: do not relocate over current Xen image placement"
> > patch. Though this safety measure may save a lot of debugging time when
> > somebody decide to relax existing relocation restrictions one day.
>
> I've gone back through the v2 discussion, and I continue to fail to
> see what is being fixed here, even if just theoretically. It is bad

OK, let's give an example. I assume that there is no patch 1 and Xen can
relocate itself even it was initially relocated by the bootloader. So,
let's assume that the bootloader loaded Xen image at 0x8020
(xen_phys_start == 0x8000) and its size is 0x70 (7 MiB).
The RAM region ends at 0x80D0 and there is no RAM above that
address. At some point Xen realizes that it can relocate itself
to 0x8060 (xen_phys_start == 0x8040). So, it does and then
remaps itself. And here is the problem. Currently existing code
will remap only Xen image up to 0x803f. Everything above will
no be remapped. So, that is why I suggested this patch.

> enough that the description here isn't clarifying this and I need to
> go back to the earlier discussion, but it's even worse if even that
> earlier discussion didn't really help. My conclusion is that you're

Sorry about that.

> talking about a case where old and positions of Xen overlap, a
> case which I thought patch 1 eliminates.

It does not eliminate the issue described above. It just hides it.

> > Additionally, remapping will execute a bit faster due to this change.
>
> Besides it hardly mattering - how come?

The continue triggered by "l3e_get_pfn(*pl3e) > ..." check will fire
after going above xen_remap_end_pfn instead of PFN_DOWN(xen_phys_start).
And xen_remap_end_pfn is often much less than PFN_DOWN(xen_phys_start).
However, I agree that it hardly matters here. It is just side effect of
this patch. This is not main goal of it.

> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -973,6 +973,11 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >  l3_pgentry_t *pl3e;
> >  l2_pgentry_t *pl2e;
> >  int i, j, k;
> > +/*
> > + * We have to calculate xen_remap_end_pfn before
> > + * xen_phys_start change.
> > + */
> > +unsigned long xen_remap_end_pfn = PFN_DOWN(__pa(_end));
>
> In case you can provide a convincing reason for the patch to be
> needed (or at least wanted) - the xen_ prefix is pointless here,
> and you might help the compiler (and maybe also the reader) a
> little by declaring the whole thing const.

OK.

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 08/02/18 12:32, Alexey G wrote:
> On Thu, 8 Feb 2018 10:47:45 +
> Igor Druzhinin  wrote:
>> I've done this measurement before. So what we are seeing exactly is
>> that the time we are spending in SMI is spiking (sometimes up to
>> 200ms) at the moment we go through INIT-SIPI-SIPI sequence. Looks like
>> this is enough to push the system into a livelock spiral. So I agree
>> with Jan to some point that the proposed workaround might not be
>> working on some systems.
> According to the Xen code, NMI expected for 2 primary purposes:
> - watchdog NMI from LAPIC
> - "system" NMIs (like due to SERR)

- Perf/Oprofile.  This is currently mutually exclusive with Xen using
the watchdog, but needn't be and hopefully won't be in the future.

>
> Most of the time we deal with watchdog NMIs, while all others should be
> somewhat rare. The thing is, we actually need to read I/O port 61h on
> system NMIs only. 
>
> If the main problem lies in a flow of SMIs due to reading port 61h on
> every NMI watchdog tick -- why not to avoid reading it?
>
> There are at least 2 ways to check if the NMI was due to a watchdog
> tick:
> - LAPIC (SDM states that "When a performance monitoring counters
> interrupt is generated, the mask bit for its associated LVT entry is
> set")
> - perf MSR overflow bit
>
> So, if we detect it was a NMI due to a watchdog using these
> methods (early in the NMI handler), we can avoid touching the port 61h
> and thus triggering SMI I/O trap on it.

The problem is having multiple NMIs arriving.  Like all other edge
triggered interrupts, extra arrivals get dropped.  By skipping the 0x61
read if we believe it was a watchdog NMI, we've opened a race condition
where we will completely miss the system NMI.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Ping: [PATCH v2 0/3] XSA-248...251 follow-up

On 02/07/2018 03:27 PM, Jan Beulich wrote:
 On 20.12.17 at 10:37,  wrote:
>> The parts of this series aren't really dependent upon one another,
>> they belong together solely because of their origin.
>>
>> 1: x86/shadow: widen reference count
>> 2: x86/mm: clean up SHARED_M2P{,_ENTRY} uses
>> 3: x86: use paging_mark_pfn_dirty()
> 
> George,
> 
> any chance to get an ack or otherwise (or an indication that they
> can go in with just Andrew's ack, which was provided via IRC) for
> the latter two?

Due to some quirks in my mail setup right now I can't respond directly
(or rather, I have just done so but I know they'll never get to you), so:

#2: Reviewed-by: George Dunlap 
#3: Acked-by: George Dunalp 

Sorry for the delay.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 3/3] x86: use paging_mark_pfn_dirty()

On Wed, Dec 20, 2017 at 9:42 AM, Jan Beulich  wrote:
> ... in preference over paging_mark_dirty(), when the PFN is known
> anyway.
>
> Signed-off-by: Jan Beulich 
> Acked-by: Tim Deegan 

Acked-by: George Dunlap 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

2018-02-08 Thread Alexey G

On Thu, 8 Feb 2018 10:47:45 +
Igor Druzhinin  wrote:
>I've done this measurement before. So what we are seeing exactly is
>that the time we are spending in SMI is spiking (sometimes up to
>200ms) at the moment we go through INIT-SIPI-SIPI sequence. Looks like
>this is enough to push the system into a livelock spiral. So I agree
>with Jan to some point that the proposed workaround might not be
>working on some systems.

According to the Xen code, NMI expected for 2 primary purposes:
- watchdog NMI from LAPIC
- "system" NMIs (like due to SERR)

Most of the time we deal with watchdog NMIs, while all others should be
somewhat rare. The thing is, we actually need to read I/O port 61h on
system NMIs only. 

If the main problem lies in a flow of SMIs due to reading port 61h on
every NMI watchdog tick -- why not to avoid reading it?

There are at least 2 ways to check if the NMI was due to a watchdog
tick:
- LAPIC (SDM states that "When a performance monitoring counters
interrupt is generated, the mask bit for its associated LVT entry is
set")
- perf MSR overflow bit

So, if we detect it was a NMI due to a watchdog using these
methods (early in the NMI handler), we can avoid touching the port 61h
and thus triggering SMI I/O trap on it.

>> There might be a chance that perf counter frequency is calculated
>> wrong for some systems, resulting in a very high rate of NMI
>> watchdog ticks instead of long SMI handler execution time. >10ms
>> just looks... too extreme.
>>   
>
>We ruled that out.
>
>> Huawei Server 2488 V5 BIOS -- similar SMI I/O trap handler for the
>> port 61h found. Some differences with gigabyte H270 system though:
>> 
>> - no "allocated" I/O traps anymore, but one additional SMI I/O trap
>>   encountered: port 900h, dword size. Possibly related to PCIe PM
>>   facilities.
>> 
>> - port 61h SMI handler now has multiple calls to debug/assert stub
>>   functions -- there might be a chance that some of impacted systems
>>   had debug build on, resulting in those stubs expanded to some real
>>   debugging code with negative impact on SMI handling speed.
>> 
>> Few additional observations:
>> 
>> - port 61h I/O Trap SMI handler checks accessed I/O address/size to
>> be equal to 61h/1byte. There might be some difference when reading
>> port 61h via inw(0x60)/inl(0x60)/etc
>> 
>> - looks like there exist an alternative way to read NMI status
>> without triggering SMI -- via ports 63h/65h/67h, but this depends on
>>   undocumented bit in Generic Control and Status register
>>   


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/3] x86/mm: clean up SHARED_M2P{, _ENTRY} uses

On Wed, Dec 20, 2017 at 9:41 AM, Jan Beulich  wrote:
> Stop open-coding SHARED_M2P() and drop a pointless use of it from
> paging_mfn_is_dirty() (!VALID_M2P() is a superset of SHARED_M2P()) and
> another one from free_page_type() (prior assertions render this
> redundant).
>
> Signed-off-by: Jan Beulich 
> Acked-by: Tim Deegan 

Reviewed-by: George Dunlap 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 3/3] pvh/dom0: whitelist PVH Dom0 ACPI tables

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/hvm/dom0_build.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 830b4345cc..82ee3fe237 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -789,24 +789,29 @@ static bool __init pvh_acpi_table_allowed(const char *sig,
   unsigned long address,
   unsigned long size)
 {
-static const char __initconst banned_tables[][ACPI_NAME_SIZE] = {
-ACPI_SIG_HPET, ACPI_SIG_SLIT, ACPI_SIG_SRAT, ACPI_SIG_MPST,
-ACPI_SIG_PMTT, ACPI_SIG_MADT, ACPI_SIG_DMAR};
+static const char __initconst allowed_tables[][ACPI_NAME_SIZE] = {
+ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_FACS, ACPI_SIG_PSDT,
+ACPI_SIG_SSDT, ACPI_SIG_SBST, ACPI_SIG_MCFG, ACPI_SIG_SLIC,
+ACPI_SIG_MSDM, ACPI_SIG_WDAT, ACPI_SIG_FPDT, ACPI_SIG_S3PT,
+};
 unsigned int i;
 
-for ( i = 0 ; i < ARRAY_SIZE(banned_tables); i++ )
-if ( strncmp(sig, banned_tables[i], ACPI_NAME_SIZE) == 0 )
-return false;
-
-/* Make sure table doesn't reside in a RAM region. */
-if ( acpi_memory_banned(address, size) )
+for ( i = 0 ; i < ARRAY_SIZE(allowed_tables); i++ )
 {
-printk("Skipping table %.4s because resides in a non-ACPI, 
non-reserved region\n",
-   sig);
-return false;
+if ( strncmp(sig, allowed_tables[i], ACPI_NAME_SIZE) )
+continue;
+
+if ( !acpi_memory_banned(address, size) )
+return true;
+else
+{
+printk("Skipping table %.4s in non-ACPI non-reserved region\n",
+   sig);
+return false;
+}
 }
 
-return true;
+return false;
 }
 
 static bool __init pvh_acpi_xsdt_table_allowed(const char *sig,
-- 
2.15.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 2/3] pvh/dom0: pass address/length to pvh_acpi_table_allowed

The current usage of acpi_gbl_root_table_list inside the function is
wrong.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/dom0_build.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 1c83578c5e..830b4345cc 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -785,7 +785,9 @@ static bool __init acpi_memory_banned(unsigned long address,
 return false;
 }
 
-static bool __init pvh_acpi_table_allowed(const char *sig)
+static bool __init pvh_acpi_table_allowed(const char *sig,
+  unsigned long address,
+  unsigned long size)
 {
 static const char __initconst banned_tables[][ACPI_NAME_SIZE] = {
 ACPI_SIG_HPET, ACPI_SIG_SLIT, ACPI_SIG_SRAT, ACPI_SIG_MPST,
@@ -797,8 +799,7 @@ static bool __init pvh_acpi_table_allowed(const char *sig)
 return false;
 
 /* Make sure table doesn't reside in a RAM region. */
-if ( acpi_memory_banned(acpi_gbl_root_table_list.tables[i].address,
-acpi_gbl_root_table_list.tables[i].length) )
+if ( acpi_memory_banned(address, size) )
 {
 printk("Skipping table %.4s because resides in a non-ACPI, 
non-reserved region\n",
sig);
@@ -808,13 +809,15 @@ static bool __init pvh_acpi_table_allowed(const char *sig)
 return true;
 }
 
-static bool __init pvh_acpi_xsdt_table_allowed(const char *sig)
+static bool __init pvh_acpi_xsdt_table_allowed(const char *sig,
+   unsigned long address,
+   unsigned long size)
 {
 /*
  * DSDT and FACS are pointed to from FADT and thus don't belong
  * in XSDT.
  */
-return (pvh_acpi_table_allowed(sig) &&
+return (pvh_acpi_table_allowed(sig, address, size) &&
 strncmp(sig, ACPI_SIG_DSDT, ACPI_NAME_SIZE) &&
 strncmp(sig, ACPI_SIG_FACS, ACPI_NAME_SIZE));
 }
@@ -825,6 +828,7 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, 
paddr_t madt_addr,
 struct acpi_table_xsdt *xsdt;
 struct acpi_table_header *table;
 struct acpi_table_rsdp *rsdp;
+const struct acpi_table_desc *tables = acpi_gbl_root_table_list.tables;
 unsigned long size = sizeof(*xsdt);
 unsigned int i, j, num_tables = 0;
 paddr_t xsdt_paddr;
@@ -840,9 +844,8 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, 
paddr_t madt_addr,
 /* Count the number of tables that will be added to the XSDT. */
 for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
 {
-const char *sig = acpi_gbl_root_table_list.tables[i].signature.ascii;
-
-if ( pvh_acpi_xsdt_table_allowed(sig) )
+if ( pvh_acpi_xsdt_table_allowed(tables[i].signature.ascii,
+ tables[i].address, tables[i].length) )
 num_tables++;
 }
 
@@ -887,11 +890,9 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, 
paddr_t madt_addr,
 /* Copy the addresses of the rest of the allowed tables. */
 for( i = 0, j = 1; i < acpi_gbl_root_table_list.count; i++ )
 {
-const char *sig = acpi_gbl_root_table_list.tables[i].signature.ascii;
-
-if ( pvh_acpi_xsdt_table_allowed(sig) )
-xsdt->table_offset_entry[j++] =
-acpi_gbl_root_table_list.tables[i].address;
+if ( pvh_acpi_xsdt_table_allowed(tables[i].signature.ascii,
+ tables[i].address, tables[i].length) )
+xsdt->table_offset_entry[j++] = tables[i].address;
 }
 
 xsdt->header.revision = 1;
@@ -955,7 +956,7 @@ static int __init pvh_setup_acpi(struct domain *d, paddr_t 
start_info)
  * re-using MADT memory.
  */
 if ( strncmp(sig, ACPI_SIG_MADT, ACPI_NAME_SIZE)
- ? pvh_acpi_table_allowed(sig)
+ ? pvh_acpi_table_allowed(sig, addr, size)
  : !acpi_memory_banned(addr, size) )
  pvh_add_mem_range(d, addr, addr + size, E820_ACPI);
 }
-- 
2.15.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 1/3] pvh/dom0: init variables at declaration time

Also remove a couple of newlines at the start of function
declarations.

No functional change.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/dom0_build.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 5f4155b7ca..1c83578c5e 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -91,12 +91,11 @@ static int __init pvh_populate_memory_range(struct domain 
*d,
 unsigned long start,
 unsigned long nr_pages)
 {
-unsigned int order, i = 0;
+unsigned int order = MAX_ORDER, i = 0;
 struct page_info *page;
 int rc;
 #define MAP_MAX_ITER 64
 
-order = MAX_ORDER;
 while ( nr_pages != 0 )
 {
 unsigned int range_order = get_order_from_pages(nr_pages + 1);
@@ -376,14 +375,12 @@ static __init void pvh_setup_e820(struct domain *d, 
unsigned long nr_pages)
 static int __init pvh_setup_p2m(struct domain *d)
 {
 struct vcpu *v = d->vcpu[0];
-unsigned long nr_pages;
+unsigned long nr_pages = dom0_compute_nr_pages(d, NULL, 0);
 unsigned int i;
 int rc;
 bool preempted;
 #define MB1_PAGES PFN_DOWN(MB(1))
 
-nr_pages = dom0_compute_nr_pages(d, NULL, 0);
-
 pvh_setup_e820(d, nr_pages);
 do {
 preempted = false;
@@ -565,7 +562,7 @@ static int __init pvh_setup_cpus(struct domain *d, paddr_t 
entry,
  paddr_t start_info)
 {
 struct vcpu *v = d->vcpu[0];
-unsigned int cpu, i;
+unsigned int cpu = v->processor, i;
 int rc;
 /*
  * This sets the vCPU state according to the state described in
@@ -586,7 +583,6 @@ static int __init pvh_setup_cpus(struct domain *d, paddr_t 
entry,
 .cpu_regs.x86_32.tr_ar = 0x8b,
 };
 
-cpu = v->processor;
 for ( i = 1; i < d->max_vcpus; i++ )
 {
 const struct vcpu *p = dom0_setup_vcpu(d, i, cpu);
@@ -620,7 +616,6 @@ static int __init pvh_setup_cpus(struct domain *d, paddr_t 
entry,
 static int __init acpi_count_intr_ovr(struct acpi_subtable_header *header,
  const unsigned long end)
 {
-
 acpi_intr_overrides++;
 return 0;
 }
@@ -640,7 +635,6 @@ static int __init acpi_set_intr_ovr(struct 
acpi_subtable_header *header,
 static int __init acpi_count_nmi_src(struct acpi_subtable_header *header,
  const unsigned long end)
 {
-
 acpi_nmi_sources++;
 return 0;
 }
@@ -780,10 +774,9 @@ static int __init pvh_setup_acpi_madt(struct domain *d, 
paddr_t *addr)
 static bool __init acpi_memory_banned(unsigned long address,
   unsigned long size)
 {
-unsigned long mfn, nr_pages, i;
+unsigned long mfn = PFN_DOWN(address);
+unsigned long nr_pages = PFN_UP((address & ~PAGE_MASK) + size), i;
 
-mfn = PFN_DOWN(address);
-nr_pages = PFN_UP((address & ~PAGE_MASK) + size);
 for ( i = 0 ; i < nr_pages; i++ )
 if ( !page_is_ram_type(mfn + i, RAM_TYPE_RESERVED) &&
  !page_is_ram_type(mfn + i, RAM_TYPE_ACPI) )
-- 
2.15.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 0/3] pvh/dom0: switch to ACPI whitelisting

Hello,

The following small series contain one cleanup, one bugfix and finally
switches PVH Dom0 from whitelisting ACPI tables instead of blacklisting
them.

The number of allowed tables ATM is fairly limited, many more could be
added if the resources described in them are properly mapped to Dom0
physmap.

Thanks, Roger.

Roger Pau Monne (3):
  pvh/dom0: init variables at declaration time
  pvh/dom0: pass address/length to pvh_acpi_table_allowed
  pvh/dom0: whitelist PVH Dom0 ACPI tables

 xen/arch/x86/hvm/dom0_build.c | 75 +--
 1 file changed, 37 insertions(+), 38 deletions(-)

-- 
2.15.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 08/02/18 09:12, Jan Beulich wrote:
 On 07.02.18 at 18:08,  wrote:
>> On 07/02/18 15:06, Jan Beulich wrote:
>>> Also you completely ignore my argument against the seemingly
>>> random division by 10, including the resulting question of what you
>>> mean to do once 10Hz also turns out too high a frequency.
>> We've got to pick a frequency.  The current 100Hz is just as arbitrary
>> as the proposed new 10Hz.
> Not exactly - the 100Hz is simply the frequency we run the main tick
> at, so while random it is not as random as any further derived value
> which has no proper reason behind it.
>
> There's one more point wrt your argument of overhead: If servicing
> an NMI takes that long on those boxes, you're basically saying you
> are happy to waste at least 1% of a core's bandwidth on a
> debugging feature. Is that reasonable for a production setup? And
> considering that I'd expect the patch to have chosen e.g. HZ / 5,
> HZ / 4, or even HZ / 2 if that worked reliably, I could even conclude
> you're happy to spend somewhere between 5 and 10% of one
> core's bandwidth. (FAOD all this is based on the 1Hz frequency we
> - iirc - run the NMI at later on.) To me this is another clear argument
> to turn off the watchdog on those systems, rather than trying to
> "fix" its probing.

It is not a debugging feature; it's a reliability feature.  With
clustered storage in particular, it is absolutely paramount to guarantee
that a struggling host fences itself cleanly, or you lose the entire
cluster.

This particular issue is a failure to boot, but by far the most common
issue we see in the field is a fence when all-but-one CPU is waiting in
the calibration rendezvous, by which point the host has effectively been
dead for 5 seconds already.  Turning the watchdog off isn't a viable or
reasonable solution to the problem.

We switch the NMI frequency to ~2Hz after the calibration, but that is
after having run the BSP at 100Hz for a long period of time, and the APs
at this rate for a short while.  Irrespective of the exact fix here, it
is simply not a good idea to be running with this NMI frequency, other
than possibly during the immediate calibration logic.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/4] firmware/shim: correctly handle errors during Xen tree setup

On Wed, Feb 07, 2018 at 08:07:01AM -0700, Jan Beulich wrote:
> "set -e" on a separate Makefile line is meaningless. Glue together all
> the lines that this is supposed to cover.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] update on the status of SP2 mitigations for Xen on Arm




On 07/02/18 20:14, Stefano Stabellini wrote:

Hi all,


Hi,

I'd like to make some clarifications on what has been merged in Xen so 
far and the state of SP2.




This is the latest status of the SP2 mitigations for Xen on Arm. Please
note that arm32 and arm64 require different mitigations.

I have just backported the arm32 mitigation to 4.10, 4.9, 4.8 and 4.7:


What you backported is a framework to enable per processor mitigation. 
Mitigation for Cortex-A15 (providing a firmware upgraded), Cortex-A17 
and Cortex-A12 has been added which covered the Arm designed processor.


This does *not* cover any processor that have not been designed by Arm 
and potentially affected by SP2.


Furthermore, while the framework is able to deal with platform with 
heterogeneous processors (e.g big.LITTLE), Xen does not expose correctly 
that information to the guest. This means that guest (such as Linux) 
will still be vulnerable to SP2. I suggested a patch to disable 
big.LITTLE on Xen for the time being (see [1]).




- 4.10
bbd093c xen/arm32: entry: Document the purpose of r11 in the traps handler
a69a8b5 xen/arm32: Invalidate icache on guest exist for Cortex-A15
f167ebf xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
c4c0187 xen/arm32: Add skeleton to harden branch predictor aliasing attacks
19ad8a7 xen/arm32: entry: Add missing trap_reset entry
3caf32c xen/arm32: Add missing MIDR values for Cortex-A17 and A12
df7be94 xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros

- 4.9
4d01dbc xen/arm32: entry: Document the purpose of r11 in the traps handler
22379b6 xen/arm32: Invalidate icache on guest exist for Cortex-A15
6e13ad7 xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
0d32237 xen/arm32: Add skeleton to harden branch predictor aliasing attacks
4ba59bd xen/arm32: entry: Add missing trap_reset entry
2997c5e xen/arm32: Add missing MIDR values for Cortex-A17 and A12
751c879 xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros

- 4.8
11875b7 xen/arm32: entry: Document the purpose of r11 in the traps handler
1105f3a xen/arm32: Invalidate icache on guest exist for Cortex-A15
754345c xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
7336d0d xen/arm32: Add skeleton to harden branch predictor aliasing attacks
cf95bba xen/arm32: entry: Add missing trap_reset entry
a586cbd xen/arm32: Add missing MIDR values for Cortex-A17 and A12
6082e3b xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros

- 4.7
f50ea84 xen/arm32: entry: Document the purpose of r11 in the traps handler
de3bdaa xen/arm32: Invalidate icache on guest exist for Cortex-A15
766990b xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
4ac0229 xen/arm32: Add skeleton to harden branch predictor aliasing attacks
bafd63f xen/arm32: entry: Add missing trap_reset entry
d5bb425 xen/arm32: Add missing MIDR values for Cortex-A17 and A12
003ec3e xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros


The arm64 backports have been in the staging trees for a while, see:
https://marc.info/?l=xen-devel=151690105623579


See remark as for arm32 mitigation here.



Julien posted another series to improve the SP2 mitigation for arm64:
https://marc.info/?l=xen-devel=151783688420038
It is not yet reviewed. This second series is highly desirable, as it
uses better firmware interfaces for the mitigation.

At present, Xen is using a PSCI get_version call (it is a call to the
PSCI firmware) for the mitigation. It relies on the firmware cleaning
the branch predictor cache in the implementation of the get_version
call. However, it appers that get_version doesn't actually do the
expected task on most arm64 platforms. Hence, the need for a new series
and a better firmware call. Julien, feel free to add more details here.


PSCI get_version was the first band-aid suggested for a generic way to 
invalidate branch predictor on Arm64 platform. It *never* relied on 
current firmware implementation to invalidate the branch predictor. It 
was relying on affected vendor to update their firmware implementation 
to invalidate branch predictor on PSCI get_version call.


Arm has published a new version of SMCCC specification (1.1) that 
provides an optimised calling convention and optional, discoverable 
support for mitigating CVE-2017-5715 (XSA-254 SP2).


The series I posted covers the implementation of SMCCC 1.1 for the 
guests. I am still working on the host side (should be posted soon). For 
the host sides, the mitigation will only be applied on *known* affected 
processors. The vendors will have to send a patch if there processors 
and requires mitigation for SP2 (even if they are using SMCCC 1.1 .


None of the Linux release will contain the PSCI get_version call (see 
[2]) and it is in my plan to drop it from Xen as well.


Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2018-01/msg02756.html
[2] https://patchwork.kernel.org/patch/10203701/

--
Julien Grall

___
Xen-devel

Re: [Xen-devel] [PATCH 4/4] firmware/shim: avoid mkdir error during Xen tree setup

On Wed, Feb 07, 2018 at 08:08:47AM -0700, Jan Beulich wrote:
> "mkdir -p" reports a missing operand, as config/ has no subdirs. Oddly
> enough this doesn't cause the whole command (and hence the build to
> fail), despite the "set -e" now covering the entire set of commands -
> perhaps a quirk of the relatively old bash I've seen this with (a few
> simple experiments suggest that commands inside () producing a non-
> success status would exit the inner shell, but not the outer one).
> 
> Add a dummy . argument to the invocation.
> 
> Suggested-by: Wei Liu 
> Signed-off-by: Jan Beulich 

Reviewed-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/4] firmware/shim: better filtering of intermediate files during Xen tree setup

On Wed, Feb 07, 2018 at 08:08:15AM -0700, Jan Beulich wrote:
> I have no idea what *.1 is meant to cover. Instead also exclude
> preprocessed and non-source assembly files.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/4] firmware/shim: better filtering of dependency files during Xen tree setup

On Wed, Feb 07, 2018 at 09:27:49AM -0700, Jan Beulich wrote:
> >>> On 07.02.18 at 17:05,  wrote:
> > On Wed, Feb 07, 2018 at 08:07:40AM -0700, Jan Beulich wrote:
> >> I have no idea what *.d1 is supposed to refer to - we only have .*.d
> >> and .*.d2 files (note also the leading dot).
> >> 
> >> Signed-off-by: Jan Beulich 
> >> 
> >> --- a/tools/firmware/xen-dir/Makefile
> >> +++ b/tools/firmware/xen-dir/Makefile
> >> @@ -26,7 +26,7 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES)
> >>$(foreach d, $(LINK_DIRS), \
> >>(cd $(XEN_ROOT); \
> >> find $(d) ! -type l -type f \
> >> -   $(addprefix ! -path , '*.[oda1]' '*.d[12]')) \
> >> +   $(addprefix ! -path , '*.[oa1]' '.*.d' '.*.d2')) \
> > 
> > Don't you want -name here instead of -path?
> > 
> > AFAICT using '.*.d' is not going to work with path, because that's the
> > full path, not the name of the file. This used to work before because
> > the patterns started with '*'.
> 
> Oh, good point. Once again I have no idea why -path was used in
> the first place.
> 

'-name' is indeed better here.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v1] x86/msr: add Raw and Host domain policies

2018-02-08 Thread Sergey Dyasli

On Thu, 2018-02-08 at 11:21 +, Roger Pau Monné wrote:
> On Thu, Feb 08, 2018 at 10:23:21AM +, Sergey Dyasli wrote:
> > +static void __init calculate_host_policy(void)
> > +{
> > +struct msr_domain_policy *dp = _msr_domain_policy;
> > +
> > +*dp = raw_msr_domain_policy;
> 
> host_msr_domain_policy = raw_msr_domain_policy;
> 
> Should work AFAICT.

This is a template for the future. The code with *dp is much shorter
than with host_msr_domain_policy.

> 
> > diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
> > index 928f1cc454..8401d376c3 100644
> > --- a/xen/include/asm-x86/msr.h
> > +++ b/xen/include/asm-x86/msr.h
> > @@ -220,6 +220,14 @@ struct msr_domain_policy
> >  } plaform_info;
> >  };
> >  
> > +/* RAW msr domain policy: contains the actual values from H/W MSRs */
> > +extern msr_domain_policy raw_msr_domain_policy;
> > +/*
> > + * HOST msr domain policy: features that Xen actually decided to use,
> > + * a subset of RAW policy.
> > + */
> > +extern msr_domain_policy host_msr_domain_policy;
> 
> Aren't you missing a 'struct' here? I don't see any typedef for struct
> msr_domain_policy.

I don't know how I missed this. You are right, 'struct' is mandatory.

-- 
Thanks,
Sergey
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v1] x86/msr: add Raw and Host domain policies

2018-02-08 Thread Roger Pau Monné

On Thu, Feb 08, 2018 at 10:23:21AM +, Sergey Dyasli wrote:
> +static void __init calculate_host_policy(void)
> +{
> +struct msr_domain_policy *dp = _msr_domain_policy;
> +
> +*dp = raw_msr_domain_policy;

host_msr_domain_policy = raw_msr_domain_policy;

Should work AFAICT.

> diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
> index 928f1cc454..8401d376c3 100644
> --- a/xen/include/asm-x86/msr.h
> +++ b/xen/include/asm-x86/msr.h
> @@ -220,6 +220,14 @@ struct msr_domain_policy
>  } plaform_info;
>  };
>  
> +/* RAW msr domain policy: contains the actual values from H/W MSRs */
> +extern msr_domain_policy raw_msr_domain_policy;
> +/*
> + * HOST msr domain policy: features that Xen actually decided to use,
> + * a subset of RAW policy.
> + */
> +extern msr_domain_policy host_msr_domain_policy;

Aren't you missing a 'struct' here? I don't see any typedef for struct
msr_domain_policy.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC 2/8] public/io/netif: add directory for backend parameters

On Wed, Feb 07, 2018 at 12:10:37PM +, Joao Martins wrote:
> On 02/06/2018 05:12 PM, Wei Liu wrote:
> > (Three months after you sent this, sorry...)
> > 
> > On Mon, Nov 06, 2017 at 12:33:06PM +, Joao Martins wrote:
> >> On Mon, Nov 06, 2017 at 10:33:59AM +, Paul Durrant wrote:
>  -Original Message-
>  From: Joao Martins [mailto:joao.m.mart...@oracle.com]
>  Sent: 02 November 2017 18:06
>  To: Xen Development List 
>  Cc: Joao Martins ; Konrad Rzeszutek Wilk
>  ; Paul Durrant ; Wei Liu
>  
>  Subject: [PATCH RFC 2/8] public/io/netif: add directory for backend
>  parameters
> 
>  The proposed directory provides a mechanism for tools to control the
>  maximum feature set of the device being provisioned by backend.
>  The parameters/features include offloading features, number of
>  queues etc.
> 
>  Signed-off-by: Joao Martins 
>  ---
>   xen/include/public/io/netif.h | 16 
>   1 file changed, 16 insertions(+)
> 
>  diff --git a/xen/include/public/io/netif.h 
>  b/xen/include/public/io/netif.h
>  index 2454448baa..a412e4771d 100644
>  --- a/xen/include/public/io/netif.h
>  +++ b/xen/include/public/io/netif.h
>  @@ -161,6 +161,22 @@
>    */
> 
>   /*
>  + * The directory "require" maybe be created in backend path by tools
>  + * domain to override the maximum feature set that backend provides to
>  the
>  + * frontend. The children entries within this directory are features 
>  names
>  + * and the correspondent values that should be used backend as defaults
>  e.g.:
>  + *
>  + * /local/domain/X/backend///require
>  + * /local/domain/X/backend///require/multi-queue-
>  max-queues = "2"
>  + * /local/domain/X/backend///require/feature-no-csum-
>  offload = "1"
>  + *
>  + * In the example above, network backend will negotiate up to a maximum
>  of
>  + * two queues with frontend plus disabling IPv4 checksum offloading.
>  + *
>  + * This directory and its children entries shall only be visible to the 
>  backend.
>  + */
>  +
> >>>
> >>> What should happen if the toolstack sets something in 'require' that
> >>> the backend cannot provide? I don't see anything in your RFC patches
> >>> to check that the backend has responded appropriately to the keys.
> >>
> >> Hmm, you're right that this RFC doesn't handle that properly - but for the
> >> ones the backend provide I had suggested (albeit not implemented here)
> >> back in the other thread that we could compare the values of feature in
> >> "require" with the one announced to the frontend. But well this wouldn't
> >> cover the non-provided ones, and possibly would fall a bit as a hack.
> >>
> >> I could change the format of the entries within "require"
> >> directory to be e.g. "- = " and the
> >> acknowledgement entry would come in the form "-status
> >> = ". Consequently the lack of a "-status" entry would
> >> have a stronger semantic i.e. unsupported and ignored. The toolstack then 
> >> would have
> >> means to check whether the feature was really succesfull set as desired
> >> or not. But then one question comes to mind: should the backend be
> >> prevented to init in the event that the features requested fail to be
> >> set? In which case uevent (on Linux) isn't triggered and xenbus state 
> >> doesn't
> >> get changed and toolstack would fail with timeout later on.
> >>
> > 
> > I think the backend should not proceed if it can't meet the
> > requirements. But to be clear I also don't think the timeout behaviour
> > should be used to determine if the setting is successful because it is
> > asking other part of the system to pick up the slack and system
> > administrators would be left in the dark (unless there is easily
> > accessible message that can be obtained by libxl to return to system
> > administrators).
> 
> That timeout behaviour is already there *I think* (or maybe I have the wrong
> impression)? The alternative is to trigger the uevent and add more logic on 
> the

Yes, it is already there. Libxl will wait for the backend to change its
state for X seconds.

The difference now is the system administrators can potentially easily
trigger a timeout due to misconfiguration, while previously it is mostly
due to the module not getting loaded or some other failures that are not
the system administrators' fault.

> hotplug script to check if the parameters were set according to config, but 
> OTOH
> you add more complexity there. Or perhaps we can check that the backend set to
> its state to Unknown (or some other state) and that determines the failure - 
> but
> still no uevent should be triggered. Unless you had something else in your 
> mind?
> 

On the other hand, I

Re: [Xen-devel] [PATCH v1] x86/msr: add Raw and Host domain policies

On 08/02/18 10:23, Sergey Dyasli wrote:
> Raw policy contains the actual values from H/W MSRs. Add PLATFORM_INFO
> msr to the policy during probe_cpuid_faulting().
>
> Host policy might have certain features disabled if Xen decides not
> to use them. For now, make Host policy equal to Raw policy.
>
> Signed-off-by: Sergey Dyasli 

Ah thanks - I was about to ask you whether you had this patch to hand.

The deferral probe_cpuid_faulting() isn't great but I think is necessary
at the moment.  I've got some plans to reorder early startup somewhat,
but more infrastructure is required before that can work.

Reviewed-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

2018-02-08 Thread Igor Druzhinin

On 08/02/18 06:37, Alexey G wrote:
> On Wed, 7 Feb 2018 13:01:08 +
> Igor Druzhinin  wrote:
>> So far the issue confirmed:
>> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
>> that it was tested on), Intel S2600XX, etc.
>>
>> Also see:
>> https://bugs.xenserver.org/browse/XSO-774
>>
>> Well, no-watchdog is what we currently recommend in that case but we
>> hoped there is a general solution here from Xen side. You have your
>> point that they should fix this on their side because it's their fault
>> indeed. But the user experience is also important for us I think.
> 
> Igor,
> 
> It would be nice to measure the actual SMI handling time on affected
> systems (eg. via rdtsc before/after inb(0x61) + averaging for
> multiple reads perhaps), is it really 10+ ms.
> 

I've done this measurement before. So what we are seeing exactly is that
the time we are spending in SMI is spiking (sometimes up to 200ms) at
the moment we go through INIT-SIPI-SIPI sequence. Looks like this is
enough to push the system into a livelock spiral. So I agree with Jan to
some point that the proposed workaround might not be working on some
systems.

> There might be a chance that perf counter frequency is calculated wrong
> for some systems, resulting in a very high rate of NMI watchdog ticks
> instead of long SMI handler execution time. >10ms just looks... too
> extreme.
> 

We ruled that out.

> Huawei Server 2488 V5 BIOS -- similar SMI I/O trap handler for the port
> 61h found. Some differences with gigabyte H270 system though:
> 
> - no "allocated" I/O traps anymore, but one additional SMI I/O trap
>   encountered: port 900h, dword size. Possibly related to PCIe PM
>   facilities.
> 
> - port 61h SMI handler now has multiple calls to debug/assert stub
>   functions -- there might be a chance that some of impacted systems
>   had debug build on, resulting in those stubs expanded to some real
>   debugging code with negative impact on SMI handling speed.
> 
> Few additional observations:
> 
> - port 61h I/O Trap SMI handler checks accessed I/O address/size to be
>   equal to 61h/1byte. There might be some difference when reading port
>   61h via inw(0x60)/inl(0x60)/etc
> 
> - looks like there exist an alternative way to read NMI status without
>   triggering SMI -- via ports 63h/65h/67h, but this depends on
>   undocumented bit in Generic Control and Status register
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v1] x86/msr: add Raw and Host domain policies

2018-02-08 Thread Sergey Dyasli

Raw policy contains the actual values from H/W MSRs. Add PLATFORM_INFO
msr to the policy during probe_cpuid_faulting().

Host policy might have certain features disabled if Xen decides not
to use them. For now, make Host policy equal to Raw policy.

Signed-off-by: Sergey Dyasli 
---
v1: Decided to upstream this separately from VMX MSRs policy
---
 xen/arch/x86/cpu/common.c | 11 ++-
 xen/arch/x86/msr.c| 19 ++-
 xen/include/asm-x86/msr.h |  8 
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 4306e59650..0875b5478b 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -118,9 +118,18 @@ void (* __read_mostly ctxt_switch_masking)(const struct 
vcpu *next);
 
 bool __init probe_cpuid_faulting(void)
 {
+   struct msr_domain_policy *dp = _msr_domain_policy;
uint64_t val;
+   int rc;
 
-   if (rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val) ||
+   if ((rc = rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val)) == 0)
+   {
+   dp->plaform_info.available = true;
+   if (val & MSR_PLATFORM_INFO_CPUID_FAULTING)
+   dp->plaform_info.cpuid_faulting = true;
+   }
+
+   if (rc ||
!(val & MSR_PLATFORM_INFO_CPUID_FAULTING) ||
rdmsr_safe(MSR_INTEL_MISC_FEATURES_ENABLES,
   this_cpu(msr_misc_features)))
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 7875d9c1e0..fbc8cd47a7 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -24,12 +24,27 @@
 #include 
 #include 
 
-struct msr_domain_policy __read_mostly hvm_max_msr_domain_policy,
+struct msr_domain_policy __read_mostly raw_msr_domain_policy,
+ __read_mostlyhost_msr_domain_policy,
+ __read_mostly hvm_max_msr_domain_policy,
  __read_mostly  pv_max_msr_domain_policy;
 
 struct msr_vcpu_policy __read_mostly hvm_max_msr_vcpu_policy,
__read_mostly  pv_max_msr_vcpu_policy;
 
+static void __init calculate_raw_policy(void)
+{
+/* 0x00ce  MSR_INTEL_PLATFORM_INFO */
+/* Was already added by probe_cpuid_faulting() */
+}
+
+static void __init calculate_host_policy(void)
+{
+struct msr_domain_policy *dp = _msr_domain_policy;
+
+*dp = raw_msr_domain_policy;
+}
+
 static void __init calculate_hvm_max_policy(void)
 {
 struct msr_domain_policy *dp = _max_msr_domain_policy;
@@ -68,6 +83,8 @@ static void __init calculate_pv_max_policy(void)
 
 void __init init_guest_msr_policy(void)
 {
+calculate_raw_policy();
+calculate_host_policy();
 calculate_hvm_max_policy();
 calculate_pv_max_policy();
 }
diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
index 928f1cc454..8401d376c3 100644
--- a/xen/include/asm-x86/msr.h
+++ b/xen/include/asm-x86/msr.h
@@ -220,6 +220,14 @@ struct msr_domain_policy
 } plaform_info;
 };
 
+/* RAW msr domain policy: contains the actual values from H/W MSRs */
+extern msr_domain_policy raw_msr_domain_policy;
+/*
+ * HOST msr domain policy: features that Xen actually decided to use,
+ * a subset of RAW policy.
+ */
+extern msr_domain_policy host_msr_domain_policy;
+
 /* MSR policy object for per-vCPU MSRs */
 struct msr_vcpu_policy
 {
-- 
2.14.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.10-testing test] 118657: trouble: broken/fail/pass