Re: [Xen-devel] [PATCH v2] drm/xen-front: fix pointer casts

[Oleksandr Andrushchenko]

On 05/23/2018 02:46 PM, Juergen Gross wrote:

On 23/05/18 13:36, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Building for a 32-bit target results in warnings from casting
between a 32-bit pointer and a 64-bit integer. Fix the warnings
by casting those pointers to uintptr_t first.

Signed-off-by: Oleksandr Andrushchenko 

Reviewed-by: Juergen Gross 

Thank you, applied to drm-misc-next


Juergen



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

Re: [Xen-devel] [PATCH for-4.11] x86/traps: Dump the instruction stream even for double faults

[Juergen Gross]

On 24/05/18 16:07, Andrew Cooper wrote:
> This helps debug #DF's which occur in alternative patches
> 
> Reported-by: George Dunlap 
> Signed-off-by: Andrew Cooper 

Release-acked-by: Juergen Gross 


Juergen

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

[Xen-devel] [xen-4.10-testing test] 123086: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 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-i386-libvirt-xsm  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-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-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-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail 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-multivcpu 14 saverestore-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-libvirt-xsm 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-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-amd64-i386-xl-qemut-win7-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-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail 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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 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-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-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-qemuu-ws16-amd64 17 guest-stop  fail 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-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  a0355180b660b149f8054b9facdd9cac8ec86a95
baseline version:
 xen  25e0657ed49e4febfb6fce729adb00a8d7b87042

Last test of basis   122837  2018-05-15 09:00:44 Z9 days
Testing same since   122915  2018-05-18 10:08:14 Z6 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  David Wang 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Olaf Hering 

[Xen-devel] [PATCH v5 2/6] libxl: introduce a new structure to represent static shared memory regions

[Stefano Stabellini]

From: Zhongze Liu 

Author: Zhongze Liu 

Add a new structure to the IDL family to represent static shared memory regions
as proposed in the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

And deleted some trailing white spaces.

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 
Reviewed-by: Stefano Stabellini 
Acked-by: Wei Liu 
Signed-off-by: Stefano Stabellini 

Cc: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org
---
Changes in v5:
- fix typos
- add LIBXL_HAVE_SSHM
- replace end with size
---
 tools/libxl/libxl.h |  6 ++
 tools/libxl/libxl_types.idl | 32 ++--
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index a09d069..d25de5d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2405,6 +2405,12 @@ int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int 
nonblock);
 int libxl_qemu_monitor_command(libxl_ctx *ctx, uint32_t domid,
const char *command_line, char **output);
 
+#define LIBXL_HAVE_SSHM 1
+
+/* Constants for libxl_static_shm */
+#define LIBXL_SSHM_RANGE_UNKNOWN UINT64_MAX
+#define LIBXL_SSHM_ID_MAXLEN128
+
 #include 
 
 #endif /* LIBXL_H */
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 01ec1d1..2cf06b4 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -559,10 +559,10 @@ libxl_domain_build_info = Struct("domain_build_info",[
("keymap",   string),
("sdl",  libxl_sdl_info),
("spice",libxl_spice_info),
-   
+
("gfx_passthru", libxl_defbool),
("gfx_passthru_kind", 
libxl_gfx_passthru_kind),
-   
+
("serial",   string),
("boot", string),
("usb",  libxl_defbool),
@@ -822,6 +822,33 @@ libxl_device_vdispl = Struct("device_vdispl", [
 ("connectors", Array(libxl_connector_param, "num_connectors"))
 ])
 
+libxl_sshm_cachepolicy = Enumeration("sshm_cachepolicy", [
+(-1, "UNKNOWN"),
+(0,  "ARM_NORMAL"),  # ARM policies should be < 32
+(32,  "X86_NORMAL"), # X86 policies should be >= 32
+], init_val = "LIBXL_SSHM_CHCHE_POLICY_UNKNOWN")
+
+libxl_sshm_prot = Enumeration("sshm_prot", [
+(-1, "UNKNOWN"),
+(3,  "RW"),
+], init_val = "LIBXL_SSHM_PROT_UNKNOWN")
+
+libxl_sshm_role = Enumeration("sshm_role", [
+(-1, "UNKNOWN"),
+(0,  "MASTER"),
+(1,  "SLAVE"),
+], init_val = "LIBXL_SSHM_ROLE_UNKNOWN")
+
+libxl_static_shm = Struct("static_shm", [
+("id", string),
+("offset", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("begin", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("size", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("prot", libxl_sshm_prot, {'init_val': 'LIBXL_SSHM_PROT_UNKNOWN'}),
+("cache_policy", libxl_sshm_cachepolicy, {'init_val': 
'LIBXL_SSHM_CACHEPOLICY_UNKNOWN'}),
+("role", libxl_sshm_role, {'init_val': 'LIBXL_SSHM_ROLE_UNKNOWN'}),
+])
+
 libxl_domain_config = Struct("domain_config", [
 ("c_info", libxl_domain_create_info),
 ("b_info", libxl_domain_build_info),
@@ -842,6 +869,7 @@ libxl_domain_config = Struct("domain_config", [
 ("channels", Array(libxl_device_channel, "num_channels")),
 ("usbctrls", Array(libxl_device_usbctrl, "num_usbctrls")),
 ("usbdevs", Array(libxl_device_usbdev, "num_usbdevs")),
+("sshms", Array(libxl_static_shm, "num_sshms")),
 
 ("on_poweroff", libxl_action_on_shutdown),
 ("on_reboot", libxl_action_on_shutdown),
-- 
1.9.1


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

[Xen-devel] [PATCH v5 5/6] libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config files

[Stefano Stabellini]

From: Zhongze Liu 

Author: Zhongze Liu 

Add the parsing utils for the newly introduced libxl_static_sshm struct
to the libxl/libxlu_* family. And add realated parsing code in xl to
parse the struct from xl config files. This is for the proposal "Allow
setting up shared memory areas between VMs from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 
Signed-off-by: Stefano Stabellini 

Cc: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org
---
Changes in v5:
- remove alignment checks, they were moved to libxl
---
 tools/libxl/Makefile  |   2 +-
 tools/libxl/libxlu_sshm.c | 207 ++
 tools/libxl/libxlutil.h   |   6 ++
 tools/xl/xl_parse.c   |  25 +-
 4 files changed, 238 insertions(+), 2 deletions(-)
 create mode 100644 tools/libxl/libxlu_sshm.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 3b762c5..2920f7e 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -176,7 +176,7 @@ AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h 
_paths.h \
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
-   libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
+   libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o libxlu_sshm.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
 $(TEST_PROG_OBJS) _libxl.api-for-check: CFLAGS += $(CFLAGS_libxentoollog) 
$(CFLAGS_libxentoolcore)
diff --git a/tools/libxl/libxlu_sshm.c b/tools/libxl/libxlu_sshm.c
new file mode 100644
index 000..cc709a7
--- /dev/null
+++ b/tools/libxl/libxlu_sshm.c
@@ -0,0 +1,207 @@
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxlu_internal.h"
+#include "xenctrl.h"
+
+#include 
+
+#define PARAM_RE(EXPR) "^\\s*" EXPR "\\s*(,|$)"
+#define WORD_RE "([_a-zA-Z0-9]+)"
+#define EQU_RE PARAM_RE(WORD_RE "\\s*=\\s*" WORD_RE)
+
+#define RET_INVAL(msg, curr_str)  do {  \
+xlu__sshm_err(cfg, msg, curr_str);  \
+rc = EINVAL;\
+goto out;   \
+} while(0)
+
+/* set a member in libxl_static_shm and report an error if it's respecified,
+ * @curr_str indicates the head of the remaining string. */
+#define SET_VAL(var, name, type, value, curr_str)  do { \
+if ((var) != LIBXL_SSHM_##type##_UNKNOWN && (var) != value) {   \
+RET_INVAL("\"" name "\" respecified", curr_str);\
+}   \
+(var) = value;  \
+} while(0)
+
+
+static void xlu__sshm_err(XLU_Config *cfg, const char *msg,
+  const char *curr_str) {
+fprintf(cfg->report,
+"%s: config parsing error in shared_memory: %s at '%s'\n",
+cfg->config_source, msg, curr_str);
+}
+
+static int parse_prot(XLU_Config *cfg, char *str, libxl_sshm_prot *prot)
+{
+int rc;
+libxl_sshm_prot new_prot;
+
+if (!strcmp(str, "rw")) {
+new_prot = LIBXL_SSHM_PROT_RW;
+} else {
+RET_INVAL("invalid permission flags", str);
+}
+
+SET_VAL(*prot, "permission flags", PROT, new_prot, str);
+
+rc = 0;
+
+ out:
+return rc;
+}
+
+static int parse_cachepolicy(XLU_Config *cfg, char *str,
+ libxl_sshm_cachepolicy *policy)
+{
+int rc;
+libxl_sshm_cachepolicy new_policy;
+
+if (!strcmp(str, "ARM_normal")) {
+new_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
+} else if (!strcmp(str, "x86_normal")) {
+new_policy = LIBXL_SSHM_CACHEPOLICY_X86_NORMAL;
+} else {
+RET_INVAL("invalid cache policy", str);
+}
+
+SET_VAL(*policy, "cache policy", CACHEPOLICY, new_policy, str);
+rc = 0;
+
+ out:
+return rc;
+}
+
+/* handle key = value pairs */
+static int handle_equ(XLU_Config *cfg, char *key, char *val,
+  libxl_static_shm *sshm)
+{
+int rc;
+
+if (!strcmp(key, "id")) {
+if (strlen(val) > LIBXL_SSHM_ID_MAXLEN) { RET_INVAL("id too long", 
val); }
+if (sshm->id && !strcmp(sshm->id, val)) {
+RET_INVAL("id respecified", val);
+}
+
+sshm->id = strdup(val);
+if (!sshm->id) {
+fprintf(stderr, "sshm parser out of memory\n");
+rc = ENOMEM;
+goto out;
+}
+} else if (!strcmp(key, "role")) {
+libxl_sshm_role new_role;
+
+if (!strcmp("master", val)) {
+new_role = LIBXL_SSHM_ROLE_MASTER;
+

[Xen-devel] [PATCH v5 6/6] docs: documentation about static shared memory regions

[Stefano Stabellini]

From: Zhongze Liu 

Author: Zhongze Liu 

Add docs to document the motivation, usage, use cases and other
relevant information about the static shared memory feature.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:

  https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 
Signed-off-by: Stefano Stabellini 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org

---
Changes in v5:
- fix typos
---
 docs/man/xl-static-shm-configuration.pod.5 | 257 +
 docs/man/xl.cfg.pod.5.in   |   8 +
 docs/misc/xenstore-paths.markdown  |  47 ++
 3 files changed, 312 insertions(+)
 create mode 100644 docs/man/xl-static-shm-configuration.pod.5

diff --git a/docs/man/xl-static-shm-configuration.pod.5 
b/docs/man/xl-static-shm-configuration.pod.5
new file mode 100644
index 000..0865835
--- /dev/null
+++ b/docs/man/xl-static-shm-configuration.pod.5
@@ -0,0 +1,257 @@
+=head1 NAME
+
+xl-static-shm-configuration - XL Static Shared Memory Configuration Syntax
+
+
+(B: This is currently only available to ARM guests.)
+
+=head1 DESCRIPTION
+
+The static_shm option allows users to statically setup shared memory regions
+among a group of VMs, enabling guests without grant table support to do
+shm-based communication.
+
+Every shared region is:
+
+=over 4
+
+* Uniquely identified by a string that is no longer than 128 characters, which
+is called an B in this document.
+
+* Backed by exactly one domain, which is called a B domain, and all
+the other domains who are also sharing this region are called Bs.
+
+=back
+
+=head1 SYNTAX
+
+This document specifies syntax of the static shared memory configuration in
+the xl config file. It has the following form:
+
+static_shm = [ "SSHM_SPEC", "SSHM_SPEC", ... ]
+
+where each C is in this form:
+
+[=,]*
+
+Valid examples of C are:
+
+id=ID1, begin=0x10, size=0x10, role=master, cache_policy=x86_normal
+id=ID1, offset = 0, begin=0x50, size=0x10, role=slave, prot=rw
+id=ID2, begin=0x30, size=0x10, role=master
+id=ID2, offset = 0x1, begin=0x69, size=0x11, role=slave
+id=ID2, offset = 0x1, begin=0x69, size=0x11, role=slave
+
+These might be specified in the domain config file like this:
+
+static_shm = ["id=ID2, offset = 0x1, begin=0x69, size=0x11,
+role=slave"]
+
+
+More formally, the string is a series of comma-separated keyword/value
+pairs. Each parameter may be specified at most once. Default values apply if
+the parameter is not specified.
+
+=head1 Parameters
+
+=over 4
+
+=item B
+
+=over 4
+
+=item Description
+
+The unique identifier of the shared memory region.
+
+Every identifier could appear only once in each xl config file.
+
+=item Supported values
+
+A string that contains alphanumerics and "_"s, and is no longer than 128
+characters.
+
+=item Default value
+
+None, this parameter is mandatory.
+
+=back
+
+=item B/B
+
+=over 4
+
+=item Description
+
+The boundaries of the shared memory area.
+
+=item Supported values
+
+Same with B.
+
+=item Default Value
+
+None, this parameter is mandatory.
+
+=back
+
+=item B
+
+=over 4
+
+=item Description
+
+Can only appear when B = slave. If set, the address mapping will not
+start from the beginning the backing memory region, but from the middle
+(B bytes away from the beginning) of it. See the graph below:
+
+With B = 0, the mapping will look like:
+
+  backing memory region:  #
+  |   |
+  |   |
+  |   |
+  V   V
+  slave's shared region:  #
+
+With B > 0:
+
+  backing memory region:   #
+   |<-- offset -->||   |
+   |   |
+   |   |
+   V   V
+  slave's memory region:   #
+
+=item Supported values
+
+Decimals or hexadecimals with a prefix "0x", and should be the multiple of the
+hypervisor page granularity (currently 4K on both ARM and x86).
+
+=item Default value
+
+0x0
+
+=back
+
+=item B
+
+=over 4
+
+=item Description
+
+The backing area would be taken from one domain, which we will mark
+as the "master domain", and this domain should be created prior to any
+other slave domains that depend on it.
+
+This argument specifies the role of 

[Xen-devel] [PATCH v5 3/6] libxl: support mapping static shared memory areas during domain creation

[Stefano Stabellini]

From: Zhongze Liu 

Author: Zhongze Liu 

Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
process involves the following steps:

  * Set defaults and check for further errors in the static_shm configs:
overlapping areas, invalid ranges, duplicated master domain,
not page aligned, no master domain etc.
  * Use xc_domain_add_to_physmap_batch to do the page sharing.
  * When some of the pages can't be successfully mapped, roll back any
successfully mapped pages so that the system stays in a consistent state.
  * Write information about static shared memory areas into the appropriate
xenstore paths and set the refcount of the shared region accordingly.

Temporarily mark this as unsupported on x86 because calling p2m_add_foreign on
two domU's is currently not allowd on x86 (see the comments in
x86/mm/p2m.c:p2m_add_foreign for more details).

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 
Signed-off-by: Stefano Stabellini 

Cc: Wei Liu 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org
---
Changes in v5:
- fix typos
- add comments
- add value checks (including alignment checks) in sshm_setdefaults
---
 tools/libxl/Makefile |   2 +-
 tools/libxl/libxl_arch.h |   6 +
 tools/libxl/libxl_arm.c  |  15 ++
 tools/libxl/libxl_create.c   |  27 +++
 tools/libxl/libxl_internal.h |  14 ++
 tools/libxl/libxl_sshm.c | 405 +++
 tools/libxl/libxl_x86.c  |  19 ++
 7 files changed, 487 insertions(+), 1 deletion(-)
 create mode 100644 tools/libxl/libxl_sshm.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 035e66e..3b762c5 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -140,7 +140,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
libxl_cpupool.o libxl_mem.o libxl_sched.o libxl_tmem.o \
libxl_9pfs.o libxl_domain.o libxl_vdispl.o \
-libxl_pvcalls.o $(LIBXL_OBJS-y)
+libxl_pvcalls.o libxl_sshm.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 74a5af3..6a07ccf 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -73,6 +73,12 @@ int libxl__arch_extra_memory(libxl__gc *gc,
  const libxl_domain_build_info *info,
  uint64_t *out);
 
+_hidden
+bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info);
+
+_hidden
+int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm);
+
 #if defined(__i386__) || defined(__x86_64__)
 
 #define LAPIC_BASE_ADDRESS  0xfee0
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 8af9f6f..5f62e78 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1141,6 +1141,21 @@ void libxl__arch_domain_build_info_acpi_setdefault(
 libxl_defbool_setdefault(_info->acpi, false);
 }
 
+bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info)
+{
+return true;
+}
+
+int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm)
+{
+if (sshm->cache_policy == LIBXL_SSHM_CACHEPOLICY_UNKNOWN)
+sshm->cache_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
+if (sshm->cache_policy >= LIBXL_SSHM_CACHEPOLICY_X86_NORMAL)
+return ERROR_INVAL;
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b5e27a7..62b0679 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -532,6 +532,14 @@ int libxl__domain_build(libxl__gc *gc,
 ret = ERROR_INVAL;
 goto out;
 }
+
+/* The p2m has been setup, we could map the static shared memory now. */
+ret = libxl__sshm_add(gc, domid, d_config->sshms, d_config->num_sshms);
+if (ret != 0) {
+LOG(ERROR, "failed to map static shared memory");
+goto out;
+}
+
 ret = libxl__build_post(gc, domid, info, state, vments, localents);
 out:
 return ret;
@@ -959,6 +967,25 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
+if (d_config->num_sshms != 0 &&
+!libxl__arch_domain_support_sshm(_config->b_info)) {
+LOGD(ERROR, domid, "static_shm is not supported by this domain type.");
+ret = ERROR_INVAL;
+goto error_out;
+}
+
+for (i = 0; i < 

[Xen-devel] [PATCH v5 4/6] libxl: support unmapping static shared memory areas during domain destruction

[Stefano Stabellini]

From: Zhongze Liu 

Author: Zhongze Liu 

Add libxl__sshm_del to unmap static shared memory areas mapped by
libxl__sshm_add during domain creation. The unmapping process is:

* For a master: decrease the refcount of the sshm region, if the refcount
  reaches 0, cleanup the whole sshm path.

* For a slave:
  1) unmap the shared pages, and cleanup related xs entries. If the
 system works normally, all the shared pages will be unmapped, so there
 won't be page leaks. In case of errors, the unmapping process will go
 on and unmap all the other pages that can be unmapped, so the other
 pages won't be leaked, either.
  2) Decrease the refcount of the sshm region, if the refcount reaches
 0, cleanup the whole sshm path.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 
Signed-off-by: Stefano Stabellini 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org

---
Changes in v5:
- fix typos
- add comments
- cannot move unmap before xenstore transaction because it needs to
  retrieve begin/size values from xenstore
---
 tools/libxl/libxl_domain.c   |   5 ++
 tools/libxl/libxl_internal.h |   2 +
 tools/libxl/libxl_sshm.c | 107 +++
 3 files changed, 114 insertions(+)

diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 533bcdf..053bbe2 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1060,6 +1060,11 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
 goto out;
 }
 
+rc = libxl__sshm_del(gc, domid);
+if (rc) {
+LOGD(ERROR, domid, "Deleting static shm failed.");
+}
+
 if (libxl__device_pci_destroy_all(gc, domid) < 0)
 LOGD(ERROR, domid, "Pci shutdown failed");
 rc = xc_domain_pause(ctx->xch, domid);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 076c30f..a2b81bf 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4429,6 +4429,8 @@ static inline bool libxl__string_is_default(char **s)
 _hidden int libxl__sshm_add(libxl__gc *gc, uint32_t domid,
 libxl_static_shm *sshm, int len);
 
+_hidden int libxl__sshm_del(libxl__gc *gc, uint32_t domid);
+
 _hidden int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
   libxl_static_shm *sshms, int len);
 _hidden int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
diff --git a/tools/libxl/libxl_sshm.c b/tools/libxl/libxl_sshm.c
index f61b80c..9672056 100644
--- a/tools/libxl/libxl_sshm.c
+++ b/tools/libxl/libxl_sshm.c
@@ -94,6 +94,113 @@ int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
 return 0;
 }
 
+/*
+ * Decrease the refcount of an sshm. When refcount reaches 0,
+ * clean up the whole sshm path.
+ * Xenstore operations are done within the same transaction.
+ */
+static void libxl__sshm_decref(libxl__gc *gc, xs_transaction_t xt,
+   const char *sshm_path)
+{
+int count;
+const char *count_path, *count_string;
+
+count_path = GCSPRINTF("%s/usercnt", sshm_path);
+if (libxl__xs_read_checked(gc, xt, count_path, _string))
+return;
+count = atoi(count_string);
+
+if (--count == 0) {
+libxl__xs_path_cleanup(gc, xt, sshm_path);
+return;
+}
+
+count_string = GCSPRINTF("%d", count);
+libxl__xs_write_checked(gc, xt, count_path, count_string);
+
+return;
+}
+
+static void libxl__sshm_do_unmap(libxl__gc *gc, uint32_t domid, const char *id,
+ uint64_t begin, uint64_t size)
+{
+uint64_t end;
+begin >>= XC_PAGE_SHIFT;
+size >>= XC_PAGE_SHIFT;
+end = begin + size;
+for (; begin < end; ++begin) {
+if (xc_domain_remove_from_physmap(CTX->xch, domid, begin)) {
+SSHM_ERROR(domid, id,
+   "unable to unmap shared page at 0x%"PRIx64".",
+   begin);
+}
+}
+}
+
+static void libxl__sshm_del_slave(libxl__gc *gc, xs_transaction_t xt,
+  uint32_t domid, const char *id, bool isretry)
+{
+const char *slave_path, *begin_str, *size_str;
+uint64_t begin, size;
+
+slave_path = GCSPRINTF("%s/slaves/%"PRIu32, SSHM_PATH(id), domid);
+
+begin_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/begin", slave_path));
+size_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/size", slave_path));
+begin = strtoull(begin_str, NULL, 16);
+size = strtoull(size_str, NULL, 16);
+
+libxl__sshm_do_unmap(gc, domid, id, begin, size);
+

[Xen-devel] [PATCH v5 0/6] Allow setting up shared memory areas between VMs from xl config files

[Stefano Stabellini]

Hi,

This series implements a new xl config entry. Users can use the new
config entry to statically setup shared memory areas among VMs that
don't have grant table support so that they could communicate with each
other through the static shared memory areas.

It was originally developed by Zhongze, I am just updating the last few
issued that were address during the last round of reviews in January. I
tested the feature on ARM and works fine.

Cheers,

Stefano


Zhongze Liu (6):
  xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing
  libxl: introduce a new structure to represent static shared memory regions
  libxl: support mapping static shared memory areas during domain creation
  libxl: support unmapping static shared memory areas during domain 
destruction
  libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config 
files
  docs: documentation about static shared memory regions

 docs/man/xl-static-shm-configuration.pod.5 | 257 +++
 docs/man/xl.cfg.pod.5.in   |   8 +
 docs/misc/xenstore-paths.markdown  |  47 +++
 tools/flask/policy/modules/xen.if  |   2 +
 tools/libxl/Makefile   |   4 +-
 tools/libxl/libxl.h|   6 +
 tools/libxl/libxl_arch.h   |   6 +
 tools/libxl/libxl_arm.c|  15 +
 tools/libxl/libxl_create.c |  27 ++
 tools/libxl/libxl_domain.c |   5 +
 tools/libxl/libxl_internal.h   |  16 +
 tools/libxl/libxl_sshm.c   | 512 +
 tools/libxl/libxl_types.idl|  32 +-
 tools/libxl/libxl_x86.c|  19 ++
 tools/libxl/libxlu_sshm.c  | 207 
 tools/libxl/libxlutil.h|   6 +
 tools/xl/xl_parse.c|  25 +-
 xen/arch/arm/mm.c  |   7 +-
 xen/include/public/memory.h|   8 +
 xen/include/xsm/dummy.h|  15 +
 xen/include/xsm/xsm.h  |   6 +
 xen/xsm/dummy.c|   1 +
 xen/xsm/flask/hooks.c  |  12 +
 xen/xsm/flask/policy/access_vectors|   5 +
 24 files changed, 1242 insertions(+), 6 deletions(-)
 create mode 100644 docs/man/xl-static-shm-configuration.pod.5
 create mode 100644 tools/libxl/libxl_sshm.c
 create mode 100644 tools/libxl/libxlu_sshm.c

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

[Xen-devel] [PATCH v5 1/6] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

[Stefano Stabellini]

From: Zhongze Liu 

Author: Zhongze Liu 

The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids
a Dom0 to map memory pages from one DomU to another, which restricts some useful
yet not dangerous use cases -- such as sharing pages among DomU's so that they
can do shm-based communication.

This patch introduces XENMAPSPACE_gmfn_share to address this inconvenience,
which is mostly the same as XENMAPSPACE_gmfn_foreign but has its own xsm check.

Specifically, the patch:

* Introduces a new av permission MMU__SHARE_MEM to denote if two domains can
  share memory by using the new subop;
* Introduces xsm_map_gmfn_share() to check if (current) has proper permission
  over (t) AND MMU__SHARE_MEM is allowed between (d) and (t);
* Modify the default xen.te to allow MMU__SHARE_MEM for normal domains that
  allow grant mapping/event channels.

The new subop is marked unsupported for x86 because calling p2m_add_foregin
on two DomU's is currently not supported on x86.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 
Signed-off-by: Stefano Stabellini 

Cc: Daniel De Graaf 
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org
---
Changes in v5:
- fix coding style
- remove useless x86 hypervisor message for the unimplemented op
- code style
- improve/add comments
---
 tools/flask/policy/modules/xen.if   |  2 ++
 xen/arch/arm/mm.c   |  7 ++-
 xen/include/public/memory.h |  8 
 xen/include/xsm/dummy.h | 15 +++
 xen/include/xsm/xsm.h   |  6 ++
 xen/xsm/dummy.c |  1 +
 xen/xsm/flask/hooks.c   | 12 
 xen/xsm/flask/policy/access_vectors |  5 +
 8 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index 7aefd00..f841125 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -128,6 +128,8 @@ define(`domain_comms', `
domain_event_comms($1, $2)
allow $1 $2:grant { map_read map_write copy unmap };
allow $2 $1:grant { map_read map_write copy unmap };
+   allow $1 $2:mmu share_mem;
+   allow $2 $1:mmu share_mem;
 ')
 
 # domain_self_comms(domain)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a6de77c..e5eb222 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1245,6 +1245,7 @@ int xenmem_add_to_physmap_one(
 
 break;
 case XENMAPSPACE_gmfn_foreign:
+case XENMAPSPACE_gmfn_share:
 {
 struct domain *od;
 p2m_type_t p2mt;
@@ -1259,7 +1260,11 @@ int xenmem_add_to_physmap_one(
 return -EINVAL;
 }
 
-rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
+if ( space == XENMAPSPACE_gmfn_foreign )
+rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
+else
+rc = xsm_map_gmfn_share(XSM_TARGET, d, od);
+
 if ( rc )
 {
 rcu_unlock_domain(od);
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index bf2f81f..a706e3c 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -227,6 +227,14 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
   Stage-2 using the Normal Memory
   Inner/Outer Write-Back Cacheable
   memory attribute. */
+#define XENMAPSPACE_gmfn_share   6 /* GMFN from another dom,
+  XENMEM_add_to_physmap_batch (and
+  currently ARM) only. Unlike
+  XENMAPSPACE_gmfn_foreign, it
+  requires current to have mapping
+  privileges instead of the
+  destination domain. */
+
 /* ` } */
 
 /*
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index ff6b2db..5064fce 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -535,6 +535,21 @@ static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG 
struct domain *d, str
 return xsm_default_action(action, d, t);
 }
 
+/*
+ * This action also requires that @current targets @d, but it has already been
+ * checked somewhere higher in the call stack.
+ *
+ * Be aware that this is not an exact default equivalence of its flask variant
+ * which also checks if @d and @t "are allowed to share memory pages", for we
+ * don't have a proper default equivalence of such a check.
+ */
+static 

[Xen-devel] xsa263 wont apply

[Glenn Enright]

Hi there

I'm trying to apply xsa263 patches, specifically for 4.10. However they 
dont seem to on top of 4.10.1 release.


I see they do apply cleanly to current 4.10 staging branch. Are staging 
trees for stable branches like 4.10 considered suitable/safe to rebase 
to for packaging purposes? ie basically ignore the point releases?


Regards, Glenn
http://rimuhosting.com
See more on our other services at http://ri.mu

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

[Xen-devel] [ovmf baseline-only test] 74741: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74741 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74741/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 77ca824c652443bdf3edaa0bb109fd8225a71cd3
baseline version:
 ovmf 1e35fcc9ee8b6b991535d9d6731d0e04169b99c0

Last test of basis74738  2018-05-23 13:49:23 Z1 days
Testing same since74741  2018-05-24 21:52:05 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Dandan Bi 
  Hao Wu 
  Laszlo Ersek 
  Liming Gao 
  Marc-André Lureau 
  Marvin Haeuser 
  Steven Shi 
  Yonghong Zhu 
  Yunhua Feng 
  Zhang, Chao B 

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



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.

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

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

[Xen-devel] [linux-3.18 baseline-only test] 74739: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74739 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74739/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-examine 11 examine-serial/bootloader fail REGR. vs. 74667
 test-armhf-armhf-examine 12 examine-serial/kernel fail REGR. vs. 74667
 test-amd64-amd64-xl-pvshim   12 guest-start   fail REGR. vs. 74667
 test-armhf-armhf-xl-xsm  16 guest-start/debian.repeat fail REGR. vs. 74667
 test-amd64-amd64-xl-qemuu-ws16-amd64 12 saverestore-support-check fail REGR. 
vs. 74667
 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigrate/x10 fail REGR. vs. 
74667

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 74667
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   like 74667
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   like 74667
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   like 74667
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74667
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 74667
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 74667
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 74667
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 74667
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail 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-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 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-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 linux7eac0d47b74e08e7060e293527524986554b
baseline version:
 linux6d05aadb69916b7e6595658fd57821219d16f2e6

Last test of basis74667  2018-05-03 10:50:12 Z   21 days
Testing same since74739  2018-05-23 22:27:22 Z1 days1 attempts


People who touched revisions under test:
  Arnaldo Carvalho de Melo 
  Bin Liu 
  Bjørn Mork 
  David S. Miller 
  Doug Ledford 
  Eric Dumazet 
  Greg Kroah-Hartman 
  Hans de Goede 
  Ingo Molnar 

[Xen-devel] [linux-linus test] 123079: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  broken
 test-armhf-armhf-xl-credit2   4 host-install(4)broken REGR. vs. 118324
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324
 test-armhf-armhf-libvirt-xsm 10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-libvirt 10 debian-install   fail REGR. vs. 118324

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 10 debian-install   fail REGR. vs. 118324

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118324
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 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-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-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-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-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-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-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  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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail 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:
 linuxa048a07d7f4535baa4cbad6bc024f175317ab938
baseline version:
 linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5

Last test of basis   118324  2018-01-25 07:31:24 Z  119 days
Failing since118362  2018-01-26 16:56:17 Z  118 days   88 attempts
Testing same since   123079  2018-05-22 20:41:58 Z2 days1 attempts


3514 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64 

[Xen-devel] [distros-debian-wheezy test] 74740: all pass

[Platform Team regression test user]

flight 74740 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74740/

Perfect :-)
All tests in this flight passed as required
baseline version:
 flight   74722

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

Re: [Xen-devel] Likely build race, "/usr/bin/ld: cannot find -lvirt"

[Jim Fehlig]

On 05/24/2018 04:27 AM, Ian Jackson wrote:

Ian Jackson writes ("Likely build race, "/usr/bin/ld: cannot find -lvirt""):

tl;dr:

I think there is a bug in libvirt's build system which, with
low probability, causes a build failure containing this message:
   /usr/bin/ld: cannot find -lvirt

Complete build logs of two attempts:

   
http://logs.test-lab.xenproject.org/osstest/logs/123046/build-i386-libvirt/6.ts-libvirt-build.log

   
http://logs.test-lab.xenproject.org/osstest/logs/123096/build-i386-libvirt/6.ts-libvirt-build.log


I have run a number of attempts.  Out of 5 more, 1 succeeded.  So out
of a total of 7 attempts, 1 succeeded.  This repro rate is an IMO
excellent opportunity to debug this race :-).


There appears to be a missing dependency between the lockd library and libvirt 
library, but my autotools skills lack the savvy to find it. Here we see the 
install command and relinking of lockd.la


 /bin/bash ../libtool   --mode=install /usr/bin/install -c   lockd.la 
'/home/osstest/build.123096.build-i386-libvirt/dist/usr/local/lib/libvirt/lock-driver'

libtool: install: warning: relinking `lockd.la'
libtool: install: (cd /home/osstest/build.123096.build-i386-libvirt/libvirt/src; 
/bin/bash /home/osstest/build.123096.build-i386-libvirt/libvirt/libtool 
--silent --tag CC --mode=relink gcc -std=gnu99 -I./conf -I/usr/include/libxml2 
-fno-common -W -Waddress -Waggressive-loop-optimizations -Wall -Wattributes 
-Wbad-function-cast -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts 
-Wclobbered -Wcomment -Wcomments -Wcoverage-mismatch -Wcpp -Wdate-time 
-Wdeprecated-declarations -Wdiv-by-zero -Wdouble-promotion -Wempty-body 
-Wendif-labels -Wextra -Wformat-contains-nul -Wformat-extra-args 
-Wformat-security -Wformat-y2k -Wformat-zero-length -Wfree-nonheap-object 
-Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int 
-Winit-self -Winline -Wint-to-pointer-cast -Winvalid-memory-model -Winvalid-pch 
-Wjump-misses-init -Wlogical-op -Wmain -Wmaybe-uninitialized 
-Wmemset-transposed-args -Wmissing-braces -Wmissing-declarations 
-Wmissing-field-initializers -Wmissing-include-dirs -Wmissing-parameter-type 
-Wmissing-prototypes -Wmultichar -Wnarrowing -Wnested-externs -Wnonnull 
-Wold-style-declaration -Wold-style-definition -Wopenmp-simd -Woverflow 
-Woverride-init -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith 
-Wpointer-sign -Wpointer-to-int-cast -Wpragmas -Wpsabi -Wreturn-local-addr 
-Wreturn-type -Wsequence-point -Wshadow -Wsizeof-pointer-memaccess 
-Wstrict-aliasing -Wstrict-prototypes -Wsuggest-attribute=const 
-Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure 
-Wswitch -Wsync-nand -Wtrampolines -Wtrigraphs -Wtype-limits -Wuninitialized 
-Wunknown-pragmas -Wunused -Wunused-but-set-parameter -Wunused-but-set-variable 
-Wunused-function -Wunused-label -Wunused-local-typedefs -Wunused-parameter 
-Wunused-result -Wunused-value -Wunused-variable -Wvarargs -Wvariadic-macros 
-Wvector-operation-performance -Wvolatile-register-var -Wwrite-strings 
-Wnormalized=nfc -Wno-sign-compare -Wjump-misses-init -Wswitch-enum 
-Wno-format-nonliteral -fstack-protector-strong -fexceptions 
-fasynchronous-unwind-tables -fipa-pure-const -Wno-suggest-attribute=pure 
-Wno-suggest-attribute=const -Werror -Wframe-larger-than=4096 -g 
-I/home/osstest/build.123096.build-i386-libvirt/xendist/usr/local/include/ 
-DLIBXL_API_VERSION=0x040400 -module -avoid-version -Wl,-z -Wl,nodelete 
-export-dynamic -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--no-copy-dt-needed-entries 
-Wl,-z -Wl,defs -g 
-L/home/osstest/build.123096.build-i386-libvirt/xendist/usr/local/lib/ 
-Wl,-rpath-link=/home/osstest/build.123096.build-i386-libvirt/xendist/usr/local/lib/ 
-o lockd.la -rpath /usr/local/lib/libvirt/lock-driver 
locking/lockd_la-lock_driver_lockd.lo locking/lockd_la-lock_protocol.lo 
libvirt.la ../gnulib/lib/libgnu.la -ldl -inst-prefix-dir 
/home/osstest/build.123096.build-i386-libvirt/dist)

/usr/bin/ld: cannot find -lvirt
collect2: error: ld returned 1 exit status
libtool: install: error: relink `lockd.la' with the above command before 
installing it

Makefile:6410: recipe for target 'install-lockdriverLTLIBRARIES' failed

and several lines later it seems another thread finally finishes libvirt.la

libtool: install: /usr/bin/install -c .libs/libvirt.lai 
/home/osstest/build.123096.build-i386-libvirt/dist/usr/local/lib/libvirt.la


I've stared at the various Makefile.{,inc.}am files but can't spot the problem. 
Perhaps other libvirt maintainers with better autotools skills can give some hints.


Regards,
Jim


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

[Xen-devel] [GIT PULL] (swiotlb) stable/for-linus-4.17

[Konrad Rzeszutek Wilk]

Hey Linus,

Please git pull the following branch in your tree:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git 
stable/for-linus-4.17

There is one single fix in there - that is under Xen the DMA32 heap
(in the hypervisor) would end up looking like swiss cheese. The reason
being that for every coherent DMA allocation we didn't do the proper
hypercall to tell Xen to return the page back to the DMA32 heap.
End result was (eventually) no DMA32 space if say you say continously
unloaded and loaded modules.

Thank you.

 drivers/xen/swiotlb-xen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Joe Jin (1):
  xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent



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

[Xen-devel] [ovmf test] 123101: all pass - PUSHED

[osstest service owner]

flight 123101 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123101/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 77ca824c652443bdf3edaa0bb109fd8225a71cd3
baseline version:
 ovmf 1e35fcc9ee8b6b991535d9d6731d0e04169b99c0

Last test of basis   123003  2018-05-21 06:56:45 Z3 days
Testing same since   123101  2018-05-23 13:36:05 Z1 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Dandan Bi 
  Hao Wu 
  Laszlo Ersek 
  Liming Gao 
  Marc-André Lureau 
  Marvin Haeuser 
  Steven Shi 
  Yonghong Zhu 
  Yunhua Feng 
  Zhang, Chao B 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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/osstest/ovmf.git
   1e35fcc9ee..77ca824c65  77ca824c652443bdf3edaa0bb109fd8225a71cd3 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

[Thomas Garnier]

On Thu, May 24, 2018 at 1:16 PM Steven Rostedt  wrote:

> On Thu, 24 May 2018 13:40:24 +0200
> Petr Mladek  wrote:

> > On Wed 2018-05-23 12:54:15, Thomas Garnier wrote:
> > > When using -fPIE/PIC with function tracing, the compiler generates a
> > > call through the GOT (call *__fentry__@GOTPCREL). This instruction
> > > takes 6 bytes instead of 5 on the usual relative call.
> > >
> > > If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte
nop
> > > so ftrace can handle the previous 5-bytes as before.
> > >
> > > Position Independent Executable (PIE) support will allow to extended
the
> > > KASLR randomization range below the -2G memory limit.
> > >
> > > Signed-off-by: Thomas Garnier 
> > > ---
> > >  arch/x86/include/asm/ftrace.h   |  6 +++--
> > >  arch/x86/include/asm/sections.h |  4 
> > >  arch/x86/kernel/ftrace.c| 42
+++--
> > >  3 files changed, 48 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/x86/include/asm/ftrace.h
b/arch/x86/include/asm/ftrace.h
> > > index c18ed65287d5..8f2decce38d8 100644
> > > --- a/arch/x86/include/asm/ftrace.h
> > > +++ b/arch/x86/include/asm/ftrace.h
> > > @@ -25,9 +25,11 @@ extern void __fentry__(void);
> > >  static inline unsigned long ftrace_call_adjust(unsigned long addr)
> > >  {
> > > /*
> > > -* addr is the address of the mcount call instruction.
> > > -* recordmcount does the necessary offset calculation.
> > > +* addr is the address of the mcount call instruction. PIE has
always a
> > > +* byte added to the start of the function.
> > >  */
> > > +   if (IS_ENABLED(CONFIG_X86_PIE))
> > > +   addr -= 1;
> >
> > This seems to modify the address even for modules that are _not_
compiled with
> > PIE, see below.

> Can one load a module not compiled for PIE in a kernel with PIE?

> >
> > > return addr;
> > >  }
> > >
> > > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> > > index 01ebcb6f263e..73b3c30cb7a3 100644
> > > --- a/arch/x86/kernel/ftrace.c
> > > +++ b/arch/x86/kernel/ftrace.c
> > > @@ -135,6 +135,44 @@ ftrace_modify_code_direct(unsigned long ip,
unsigned const char *old_code,
> > > return 0;
> > >  }
> > >
> > > +/* Bytes before call GOT offset */
> > > +const unsigned char got_call_preinsn[] = { 0xff, 0x15 };
> > > +
> > > +static int
> > > +ftrace_modify_initial_code(unsigned long ip, unsigned const char
*old_code,
> > > +  unsigned const char *new_code)
> > > +{
> > > +   unsigned char replaced[MCOUNT_INSN_SIZE + 1];
> > > +
> > > +   ftrace_expected = old_code;
> > > +
> > > +   /*
> > > +* If PIE is not enabled or no GOT call was found, default to the
> > > +* original approach to code modification.
> > > +*/
> > > +   if (!IS_ENABLED(CONFIG_X86_PIE) ||
> > > +   probe_kernel_read(replaced, (void *)ip, sizeof(replaced)) ||
> > > +   memcmp(replaced, got_call_preinsn, sizeof(got_call_preinsn)))
> > > +   return ftrace_modify_code_direct(ip, old_code, new_code);
> >
> > And this looks like an attempt to handle modules compiled without
> > PIE. Does it works with the right ip in that case?

> I'm guessing the || is for the "or no GOT call was found", but it
> doesn't explain why no GOT would be found.

Yes, maybe I could have made it work by using text_ip_addr earlier.


> >
> > I wonder if a better solution would be to update
> > scripts/recordmcount.c to store the incremented location into the
module.

I will look into it.


> If recordmcount.c can handle this, then I think that's the preferred
> approach. Thanks!

> -- Steve

> >
> > IMPORTANT: I have only vague picture about how this all works. It is
> > possible that I am completely wrong. The code might be correct,
> > especially if you tested this situation.
> >
> > Best Regards,
> > Petr



-- 
Thomas

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

[Xen-devel] [qemu-mainline test] 123075: regressions - FAIL

[osstest service owner]

flight 123075 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123075/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386 14 guest-saverestore  fail REGR. vs. 122357
 test-amd64-i386-freebsd10-amd64 14 guest-saverestore fail REGR. vs. 122357
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail 
REGR. vs. 122357
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 13 guest-saverestore fail 
REGR. vs. 122357
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. 
vs. 122357
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-saverestore fail REGR. vs. 122357
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-saverestore fail REGR. vs. 
122357
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. 
vs. 122357
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-saverestore fail REGR. vs. 122357
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-saverestore fail REGR. vs. 122357
 test-amd64-i386-xl-qemuu-debianhvm-amd64 13 guest-saverestore fail REGR. vs. 
122357
 test-amd64-i386-xl-qemuu-ovmf-amd64 13 guest-saverestore fail REGR. vs. 122357
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail 
REGR. vs. 122357
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 13 guest-saverestore fail 
REGR. vs. 122357
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail REGR. vs. 122357
 test-amd64-amd64-xl-qemuu-ws16-amd64 13 guest-saverestore fail REGR. vs. 122357

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122357
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122357
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122357
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 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-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-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-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install

Re: [Xen-devel] [v2 5/6] drivers/passthrough/arm: Refactor code for arm smmu drivers

[Sameer Goel]

On 05/24/2018 01:58 AM, Jan Beulich wrote:

On 24.05.18 at 02:46,  wrote:

Pull common defines for SMMU drives in a local header.

Signed-off-by: Sameer Goel 
---
  xen/drivers/passthrough/arm/arm_smmu.h | 125 +

This being a local header - why the arm_ prefix?

I'll fix this.


Jan





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

Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Sameer Goel]

On 05/23/2018 10:48 PM, Manish Jaggi wrote:

Hi Sameer,

General Comment, please use appropriate variable names for XXX_domain 
structures in code which is xen specific.
I thought that we had discussed this before on one of the RFCs. At this 
point we are just using the format used for smmu-v2. I don't think that 
the variable names are inappropriate. Unless there is a very specific 
issue with the variable names, I think we should stick with the current 
version.





On 05/24/2018 06:16 AM, Sameer Goel wrote:

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 | 934 +-
  xen/include/xen/linux_compat.h    |  84 +++
  6 files changed, 1001 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 d43c3aa896..38aa9f00c1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1454,6 +1454,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 db94393f47..59ca00f850 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -15,4 +15,6 @@ source "drivers/video/Kconfig"
  config HAS_VPCI
  bool
  +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..df81626785 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 "io-pgtable.h"
+#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
+ * 

Re: [Xen-devel] [v2 1/6] Port WARN_ON_ONCE() from Linux

[Sameer Goel]

On 05/24/2018 01:53 AM, Jan Beulich wrote:

On 24.05.18 at 02:46,  wrote:

Port WARN_ON_ONCE macro from Linux.

In such a case you should justify adjustments you've made:
I can add more details, but have mostly just changed variable names. The 
macro is self explanatory.


Should I just change this to: "Define WARN_ON_ONCE macro to mirror LInux 
functionality"



--- 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;   \

Linux uses .data.once. That or .data.cold would seem better to me than
.data.unlikely.
I guess there is not reason to keep this in a specific section. I'll 
just go ahead and remove the section here?




Jan





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

Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Sameer Goel]

Can you please point out the specific instances? This patch is no 
different than the last v1 patch. I have just added tasklets to it.



On 05/23/2018 10:48 PM, Manish Jaggi wrote:

Hi Sameer,

General Comment, please use appropriate variable names for XXX_domain 
structures in code which is xen specific.



On 05/24/2018 06:16 AM, Sameer Goel wrote:

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 | 934 +-
  xen/include/xen/linux_compat.h    |  84 +++
  6 files changed, 1001 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 d43c3aa896..38aa9f00c1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1454,6 +1454,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 db94393f47..59ca00f850 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -15,4 +15,6 @@ source "drivers/video/Kconfig"
  config HAS_VPCI
  bool
  +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..df81626785 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 "io-pgtable.h"
+#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;
+
+    

Re: [Xen-devel] [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

[Steven Rostedt]

On Thu, 24 May 2018 13:40:24 +0200
Petr Mladek  wrote:

> On Wed 2018-05-23 12:54:15, Thomas Garnier wrote:
> > When using -fPIE/PIC with function tracing, the compiler generates a
> > call through the GOT (call *__fentry__@GOTPCREL). This instruction
> > takes 6 bytes instead of 5 on the usual relative call.
> > 
> > If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop
> > so ftrace can handle the previous 5-bytes as before.
> > 
> > Position Independent Executable (PIE) support will allow to extended the
> > KASLR randomization range below the -2G memory limit.
> > 
> > Signed-off-by: Thomas Garnier 
> > ---
> >  arch/x86/include/asm/ftrace.h   |  6 +++--
> >  arch/x86/include/asm/sections.h |  4 
> >  arch/x86/kernel/ftrace.c| 42 +++--
> >  3 files changed, 48 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> > index c18ed65287d5..8f2decce38d8 100644
> > --- a/arch/x86/include/asm/ftrace.h
> > +++ b/arch/x86/include/asm/ftrace.h
> > @@ -25,9 +25,11 @@ extern void __fentry__(void);
> >  static inline unsigned long ftrace_call_adjust(unsigned long addr)
> >  {
> > /*
> > -* addr is the address of the mcount call instruction.
> > -* recordmcount does the necessary offset calculation.
> > +* addr is the address of the mcount call instruction. PIE has always a
> > +* byte added to the start of the function.
> >  */
> > +   if (IS_ENABLED(CONFIG_X86_PIE))
> > +   addr -= 1;  
> 
> This seems to modify the address even for modules that are _not_ compiled with
> PIE, see below.

Can one load a module not compiled for PIE in a kernel with PIE?

> 
> > return addr;
> >  }
> >  
> > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> > index 01ebcb6f263e..73b3c30cb7a3 100644
> > --- a/arch/x86/kernel/ftrace.c
> > +++ b/arch/x86/kernel/ftrace.c
> > @@ -135,6 +135,44 @@ ftrace_modify_code_direct(unsigned long ip, unsigned 
> > const char *old_code,
> > return 0;
> >  }
> >  
> > +/* Bytes before call GOT offset */
> > +const unsigned char got_call_preinsn[] = { 0xff, 0x15 };
> > +
> > +static int
> > +ftrace_modify_initial_code(unsigned long ip, unsigned const char *old_code,
> > +  unsigned const char *new_code)
> > +{
> > +   unsigned char replaced[MCOUNT_INSN_SIZE + 1];
> > +
> > +   ftrace_expected = old_code;
> > +
> > +   /*
> > +* If PIE is not enabled or no GOT call was found, default to the
> > +* original approach to code modification.
> > +*/
> > +   if (!IS_ENABLED(CONFIG_X86_PIE) ||
> > +   probe_kernel_read(replaced, (void *)ip, sizeof(replaced)) ||
> > +   memcmp(replaced, got_call_preinsn, sizeof(got_call_preinsn)))
> > +   return ftrace_modify_code_direct(ip, old_code, new_code);  
> 
> And this looks like an attempt to handle modules compiled without
> PIE. Does it works with the right ip in that case?

I'm guessing the || is for the "or no GOT call was found", but it
doesn't explain why no GOT would be found.

> 
> I wonder if a better solution would be to update
> scripts/recordmcount.c to store the incremented location into the module.

If recordmcount.c can handle this, then I think that's the preferred
approach. Thanks!

-- Steve

> 
> IMPORTANT: I have only vague picture about how this all works. It is
> possible that I am completely wrong. The code might be correct,
> especially if you tested this situation.
> 
> Best Regards,
> Petr


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

Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions

[Jens Axboe]

On 5/24/18 7:01 AM, Joe Perches wrote:
> On Thu, 2018-05-24 at 06:47 -0600, Jens Axboe wrote:
>> On 5/23/18 4:35 PM, Joe Perches wrote:
>>> On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote:
 On 5/23/18 2:05 PM, Joe Perches wrote:
> Convert the S_ symbolic permissions to their octal equivalents as
> using octal and not symbolic permissions is preferred by many as more
> readable.
>
> see: https://lkml.org/lkml/2016/8/2/1945
>
> Done with automated conversion via:
> $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 
> 
>
> Miscellanea:
>
> o Wrapped modified multi-line calls to a single line where appropriate
> o Realign modified multi-line calls to open parenthesis

 Honestly, I see this as pretty needless churn.
>>>
>>> btw:
>>>
>>> There is currently a mixture of symbolic and octal
>>> permissions uses in block and drivers/block
>>>
>>> ie: 94 octal and 146 symbolic uses.
>>>
>>> If this is applied, all would become octal.
>>
>> That does help justify the change. My main worry here is creating
>> unnecessary conflicts, which is always annoying. But it's even more
>> annoying when the change creating the conflict isn't really that
>> important at all. Case in point, the patch doesn't apply to the
>> for-4.18/block branch that it should go into...
> 
> Done against most recent -next as it's basically impossible
> to do anything against multiple private trees.
> 
> Also, the script that generated the patch is in the changelog
> so it's simple to rerun.

Alright, applied, thanks.

-- 
Jens Axboe


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

Re: [Xen-devel] [PATCH v2] arm: clean-up: correct find_*_bit() functions use

[Stefano Stabellini]

On Thu, 24 May 2018, Julien Grall wrote:
> Hi Artem,
> 
> Title: It would be good to specify the subsystem you modify.
> 
> arm: vgic: ...
> 
> On 24/05/18 16:24, Artem Mygaiev wrote:
> > vgic_vcpu_pending_irq() uses find_next_bit() library function with single
> > 'unsigned long' variable, while it is designed to work with memory regions
> > and offsets. It would be more correct to use the find_first_bit() function
> > instead.
> 
> The commit message sounds like it is wrong to use find_next_bit(). However, as
> I mentioned earlier, find_first_bit() is just a wrapper of find_next_bit() on
> Arm64.
> 
> So I would reword the commit message as:
> 
> "arm: vgic: Use find_first_bit instead of find_next_bit when possible
> 
> find_next_bit(foo, sz, 0) is equivalent to find_first_bit(foo, sz). The latter
> is easier to understand. Some architecture may also have a optimized version
> of find_first_bit(...). So replace the occurrence of find_next_bit in
> vgic_vcpu_pending_irq()."

I was going to fix the commit message while committing the patch, using
Julien's wording, but we have a commit moratorium at the moment. I'll
commit when the tree reopens.


> 
> > 
> > Signed-off-by: Artem Mygaiev 
> > 
> > diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
> > index d831b35525..fd63906e9b 100644
> > --- a/xen/arch/arm/gic-vgic.c
> > +++ b/xen/arch/arm/gic-vgic.c
> > @@ -362,7 +362,7 @@ int vgic_vcpu_pending_irq(struct vcpu *v)
> >   ASSERT(v == current);
> > 
> >   mask_priority = gic_hw_ops->read_vmcr_priority();
> > -    active_priority = find_next_bit(, 32, 0);
> > +    active_priority = find_first_bit(, 32);
> > 
> >   spin_lock_irqsave(>arch.vgic.lock, flags);
> > 
> 
> -- 
> Julien Grall
> ___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head

[Stefano Stabellini]

On Thu, 24 May 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 24/05/18 00:47, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > Using current is fairly expensive, so save up into a variable.
> > > 
> > > Signed-off-by: Julien Grall 
> > 
> > Good idea. I am curious to know actually how much this patch would save
> > but I am not going to ask you run the tests.
> 
> I haven't benchmark it but looked at the resulting assembly code. This reduces
> by about ~20% the number of instructions in the function.
> 
> AFAIU, this is because of the way per-cpu access have been implemented. The
> per-cpu offset is stored in a system register (TPIDR_EL2), all the read to it
> cannot be optimized (access using volatile).
> 
> So every direct use of "current" will require at least a system register
> access and then a load from memory.

Very nice, thank you!


> 
> > 
> > Reviewed-by: Stefano Stabellini 
> > 
> > > ---
> > >   xen/arch/arm/traps.c | 14 --
> > >   1 file changed, 8 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > index 020b0b8eef..b1546f6907 100644
> > > --- a/xen/arch/arm/traps.c
> > > +++ b/xen/arch/arm/traps.c
> > > @@ -2024,8 +2024,10 @@ static void enter_hypervisor_head(struct
> > > cpu_user_regs *regs)
> > >   {
> > >   if ( guest_mode(regs) )
> > >   {
> > > +struct vcpu *v = current;
> > > +
> > >   /* If the guest has disabled the workaround, bring it back on.
> > > */
> > > -if ( needs_ssbd_flip(current) )
> > > +if ( needs_ssbd_flip(v) )
> > >   arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> > > /*
> > > @@ -2034,8 +2036,8 @@ static void enter_hypervisor_head(struct
> > > cpu_user_regs *regs)
> > >* but the crucial bit is "On taking a vSError interrupt,
> > > HCR_EL2.VSE
> > >* (alias of HCR.VA) is cleared to 0."
> > >*/
> > > -if ( current->arch.hcr_el2 & HCR_VA )
> > > -current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
> > > +if ( v->arch.hcr_el2 & HCR_VA )
> > > +v->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
> > > #ifdef CONFIG_NEW_VGIC
> > >   /*
> > > @@ -2045,11 +2047,11 @@ static void enter_hypervisor_head(struct
> > > cpu_user_regs *regs)
> > >* TODO: Investigate whether this is necessary to do on every
> > >* trap and how it can be optimised.
> > >*/
> > > -vtimer_update_irqs(current);
> > > -vcpu_update_evtchn_irq(current);
> > > +vtimer_update_irqs(v);
> > > +vcpu_update_evtchn_irq(v);
> > >   #endif
> > >   -vgic_sync_from_lrs(current);
> > > +vgic_sync_from_lrs(v);
> > >   }
> > >   }
> > >   
> > > -- 
> > > 2.11.0
> > > 
> 
> -- 
> Julien Grall
> 

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

Re: [Xen-devel] [PATCH v2 10/10] xen: add cloc target

[Stefano Stabellini]

On Thu, 24 May 2018, Jan Beulich wrote:
> >>> On 23.05.18 at 20:21,  wrote:
> > On Wed, 23 May 2018, Jan Beulich wrote:
> >> >>> On 22.05.18 at 22:08,  wrote:
> >> > On Tue, 22 May 2018, Jan Beulich wrote:
> >> >> >>> On 22.05.18 at 02:53,  wrote:
> >> >> > + $(eval tmpfile := $(shell mktemp))
> >> >> > + $(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
> >> >> > + $(eval path := $(dir $(f))) \
> >> >> > + $(eval name := $(shell cat $(f) | head -1 | cut -d " " 
> >> >> > -f 2)) \
> >> >> > + $(shell if test -f $(path)/$(name) ; then echo 
> >> >> > $(path)/$(name) >> $(tmpfile); fi;))
> >> >> > + cloc --list-file=$(tmpfile)
> >> >> > + rm $(tmpfile)
> >> >> 
> >> >> I think you also want to "rm -f $(tmpfile)" first thing in case a prior 
> >> >> "make cloc"
> >> >> was interrupted.
> >> > 
> >> > The issue is that tmpfile will be different the second time around
> >> > (mktemp returning a new name) so it is not quite possible to remove the
> >> > old tmpfile.
> >> 
> >> Oh, I'm sorry for the noise - I should have paid attention to the very
> >> first line of what is still quoted of your patch above.
> >> 
> >> Instead you then have the problem of the temporary file not being cleaned
> >> up when interrupting "make cloc". Granted there are many other cases
> >> where such files don't get cleaned up (judging from a look at my one /tmp),
> >> but it'd be nice if we didn't contribute to the problem.
> > 
> > Given that tmpfile will be quite small, I think it is best to keep using
> > mktemp and risk leaking it. However, if you prefer, I can switch to
> > using a well-known filename, such as "sourcelist" to avoid leaks in case
> > of Ctrl-C during make.
> 
> I'll leave that decision to you; I don't expect to be affected by this myself.

All right. In that case I'll keep mktemp as I did in v3. Thanks for the
review.

- Stefano

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

[Xen-devel] [linux-4.9 test] 123074: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvhv2-amd  7 xen-bootfail REGR. vs. 122969
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-qemuu-nested-amd  7 xen-bootfail REGR. vs. 122969
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 122969
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
122969
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 122969
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 122969

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  7 xen-boot fail REGR. vs. 122969

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122969
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122969
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122969
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122969
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122969
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   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-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-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-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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail 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
 

[Xen-devel] [PATCH] x86/CPUID: don't override tool stack decision to hide STIBP

[Andrew Cooper]

On 22/05/18 11:33, Jan Beulich wrote:
> Other than in the feature sets, where we indeed want to offer the
> feature even if not enumerated on hardware, we shouldn't dictate the
> feature being available if tool stack or host admin have decided not
> to expose it (for whatever [questionable?] reason).
>
> Signed-off-by: Jan Beulich 
> ---
> This is effectively accompanying the discussion rooted at the 4.8/4.7
> patch at
> https://lists.xenproject.org/archives/html/xen-devel/2018-05/msg01028.html 
> dealing with a feature leveling issue.
>
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -642,14 +642,6 @@ void recalculate_cpuid_policy(struct dom
>  recalculate_xstate(p);
>  recalculate_misc(p);
>  
> -/*
> - * Override STIBP to match IBRS.  Guests can safely use STIBP
> - * functionality on non-HT hardware, but can't necesserily protect
> - * themselves from SP2/Spectre/Branch Target Injection if STIBP is hidden
> - * on HT-capable hardware.
> - */
> -p->feat.stibp = p->feat.ibrsb;

You've deleted a comment explaining why this is needed for safety
reasons, without addressing the safety argument.  Simply "because we
shouldn't override the toolstack" isn't a reasonable argument.

With the SP2 microcode, we have the following situations which can occur:
 * No mitigations
 * IBRSB visible
 * IBRSB and STIBP visible

IBSRB enumerates MSR_SPEC_CTRL, MSR_SPEC_CTRL.IBRS, and MSR_PRED_CMD.
STIBP enumerates MSR_SPEC_CTRL.STIBP

SPEC_CTRL.STIBP is specified as usable (albeit, as a nop) even if STIBP
isn't enumerated.  This is deliberately and explicitly for heterogeneous
migration scenarios, as it won't be a nop on other processors.  In
practice, this is so hypervisors can offer the feature unilaterally, and
have it usable on non-HT hardware.

However, to safely level it, dom0 needs to see it set in the information
used to construct the guest policies.  In principle, this should just be
in the guest policy which needs adjusting.

However, due to still not having got the CPUID policy improvements
finished, dom0 is still excluded from cpuid faulting for the exclusive
benefit of the CPUID logic in the domain builder, because it uses native
CPUID to construct the guests CPUID policy.  Therefore, dom0 is unable
to create a safe CPUID policy for the guest, and Xen must override the
setting.

If you try and make this change, you will introduce a guest security
issue on some hardware by hiding STIBP which is necessary for safety.

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

Re: [Xen-devel] [PATCH v3 11/27] x86/power/64: Adapt assembly for PIE support

[Thomas Garnier]

On Thu, May 24, 2018 at 4:04 AM Pavel Machek  wrote:

> On Wed 2018-05-23 12:54:05, Thomas Garnier wrote:
> > Change the assembly code to use only relative references of symbols for
the
> > kernel to be PIE compatible.
> >
> > Position Independent Executable (PIE) support will allow to extended the
> > KASLR randomization range below the -2G memory limit.
> >
> > Signed-off-by: Thomas Garnier 

> Again, was this tested?

Hibernation was tested as much as I can with qemu and my dedicated machine.
Any specific test you think I should use?


> > diff --git a/arch/x86/power/hibernate_asm_64.S
b/arch/x86/power/hibernate_asm_64.S
> > index ce8da3a0412c..6fdd7bbc3c33 100644
> > --- a/arch/x86/power/hibernate_asm_64.S
> > +++ b/arch/x86/power/hibernate_asm_64.S
> > @@ -24,7 +24,7 @@
> >  #include 
> >
> >  ENTRY(swsusp_arch_suspend)
> > - movq$saved_context, %rax
> > + leaqsaved_context(%rip), %rax
> >   movq%rsp, pt_regs_sp(%rax)
> >   movq%rbp, pt_regs_bp(%rax)
> >   movq%rsi, pt_regs_si(%rax)
> > @@ -115,7 +115,7 @@ ENTRY(restore_registers)
> >   movq%rax, %cr4;  # turn PGE back on
> >
> >   /* We don't restore %rax, it must be 0 anyway */
> > - movq$saved_context, %rax
> > + leaqsaved_context(%rip), %rax
> >   movqpt_regs_sp(%rax), %rsp
> >   movqpt_regs_bp(%rax), %rbp
> >   movqpt_regs_si(%rax), %rsi

> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



-- 
Thomas

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

Re: [Xen-devel] [PATCH v3 09/27] x86/acpi: Adapt assembly for PIE support

[Thomas Garnier]

On Thu, May 24, 2018 at 4:03 AM Pavel Machek  wrote:

> On Wed 2018-05-23 12:54:03, Thomas Garnier wrote:
> > Change the assembly code to use only relative references of symbols for
the
> > kernel to be PIE compatible.
> >
> > Position Independent Executable (PIE) support will allow to extended the
> > KASLR randomization range below the -2G memory limit.

> What testing did this get?

Tested boot, hibernation and performance on qemu and dedicated machine.


> > diff --git a/arch/x86/kernel/acpi/wakeup_64.S
b/arch/x86/kernel/acpi/wakeup_64.S
> > index 50b8ed0317a3..472659c0f811 100644
> > --- a/arch/x86/kernel/acpi/wakeup_64.S
> > +++ b/arch/x86/kernel/acpi/wakeup_64.S
> > @@ -14,7 +14,7 @@
> >* Hooray, we are in Long 64-bit mode (but still running in low
memory)
> >*/
> >  ENTRY(wakeup_long64)
> > - movqsaved_magic, %rax
> > + movqsaved_magic(%rip), %rax
> >   movq$0x123456789abcdef0, %rdx
> >   cmpq%rdx, %rax
> >   jne bogus_64_magic

> Because, as comment says, this is rather tricky code.

I agree, I think maintainers feedback is very important for this patchset.


Pavel

> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



-- 
Thomas

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

Re: [Xen-devel] [PATCH 7/9] x86/vmx: Support load-only guest MSR list entries

[Jan Beulich]

>>> On 22.05.18 at 13:20,  wrote:
> Currently, the VMX_MSR_GUEST type maintains completely symmetric guest load
> and save lists, by pointing VM_EXIT_MSR_STORE_ADDR and 
> VM_ENTRY_MSR_LOAD_ADDR
> at the same page, and setting VM_EXIT_MSR_STORE_COUNT and
> VM_ENTRY_MSR_LOAD_COUNT to the same value.
> 
> However, for MSRs which we won't let the guest have direct access to, having
> hardware save the current value on VMExit is unnecessary overhead.
> 
> To avoid this overhead, we must make the load and save lists asymmetric.  By
> making the entry load count greater than the exit store count, we can maintain
> two adjacent lists of MSRs, the first of which is saved and restored, and the
> second of which is only restored on VMEntry.
> 
> For simplicity:
>  * Both adjacent lists are still sorted by MSR index.
>  * It undefined behaviour to insert the same MSR into both lists.

I guess for now that's good enough. Ideally, inserting a load/save entry
would purge a possible load-only entry, and inserting a load-only entry
would be a no-op when a load/save one already exists. Otherwise
different pieces of code dealing with different parts of an MSR (if we
ever gain such) would need to be tightly aware of one another (and in
particular conditionals around the insertions would need to be kept in
sync).

>  * The total size of both lists is still limited at 256 entries (one 4k page).
> 
> Split the current msr_count field into msr_{load,save}_count, and introduce a
> new VMX_MSR_GUEST_LOADONLY type, and update vmx_{add,find}_msr() to calculate
> which sublist to search, based on type.  VMX_MSR_HOST has no logical sublist,
> whereas VMX_MSR_GUEST has a sublist between 0 and the save count, while
> VMX_MSR_GUEST_LOADONLY has a sublist between the save count and the load
> count.
> 
> One subtle point is that inserting an MSR into the load-save list involves
> moving the entire load-only list, and updating both counts.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Simon Gaiser]

Jan Beulich:
 On 24.05.18 at 17:10,  wrote:
>> Jan Beulich:
>> On 24.05.18 at 16:14,  wrote:
 Jan Beulich:
 On 24.05.18 at 16:00,  wrote:
>> Jan Beulich:
>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>>> I've failed to remember the fact that multiple CPUs share a stub
>>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>>> when bringing down a CPU; it may only be unmapped when no other online
>>> CPU uses that same page.
>>>
>>> Reported-by: Simon Gaiser 
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>>>  
>>>  free_xen_pagetable(rpt);
>>>  
>>> -/* Also zap the stub mapping for this CPU. */
>>> +/*
>>> + * Also zap the stub mapping for this CPU, if no other online one 
>>> uses
>>> + * the same page.
>>> + */
>>> +if ( stub_linear )
>>> +{
>>> +unsigned int other;
>>> +
>>> +for_each_online_cpu(other)
>>> +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> 
>>> PAGE_SHIFT) 
>> )
>>> +{
>>> +stub_linear = 0;
>>> +break;
>>> +}
>>> +}
>>>  if ( stub_linear )
>>>  {
>>>  l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
>>
>> Tried this on-top of staging (fc5805daef) and I still get the same
>> double fault.
>
> Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. 
> What
> size a system are you testing on? Mine has got only 12 CPUs, i.e. all 
> stubs
> are in the same page (and I'd never unmap anything here at all).

 4 cores + HT, so 8 CPUs from Xen's PoV.
>>>
>>> May I ask you to do two things:
>>> 1) confirm that you can offline CPUs successfully using xen-hptool,
>>> 2) add a printk() to the code above making clear whether/when any
>>> of the mappings actually get zapped?
>>
>> There seem to be two failure modes now. It seems that both can be
>> triggered either by offlining a cpu or by suspend. Using cpu offlining
>> below since during suspend I often loose part of the serial output.
>>
>> Failure mode 1, the double fault as before:
>>
>> root@localhost:~# xen-hptool cpu-offline 3
>> Prepare to offline CPU 3
>> (XEN) Broke affinity for irq 9
>> (XEN) Broke affinity for irq 29
>> (XEN) dbg: stub_linear't1 = 18446606431818858880
>> (XEN) dbg: first stub_linear if
>> (XEN) dbg: stub_linear't2 = 18446606431818858880
>> (XEN) dbg: second stub_linear if
>> CPU 3 offlined successfully
>> root@localhost:~# (XEN) *** DOUBLE FAULT ***
>> (XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
>> (XEN) CPU:0
>> (XEN) RIP:e008:[] handle_exception+0x9c/0xff
>> (XEN) RFLAGS: 00010006   CONTEXT: hypervisor
>> (XEN) rax: c90040cdc0a8   rbx:    rcx: 0006
>> (XEN) rdx:    rsi:    rdi: 
>> (XEN) rbp: 36ffbf323f37   rsp: c90040cdc000   r8:  
>> (XEN) r9:     r10:    r11: 
>> (XEN) r12:    r13:    r14: c90040cd
>> (XEN) r15:    cr0: 8005003b   cr4: 00042660
>> (XEN) cr3: 000128109000   cr2: c90040cdbff8
>> (XEN) fsb: 7fc01c3c6dc0   gsb: 88021e70   gss: 
>> (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
>> (XEN) Xen code around  (handle_exception+0x9c/0xff):
>> (XEN)  00 f3 90 0f ae e8 eb f9  07 00 00 00 f3 90 0f ae e8 eb f9 83 e9 
>> 01 
>> 75
>> (XEN) Current stack base c90040cd8000 differs from expected 
>> 8300cec88000
>> (XEN) Valid stack range: c90040cde000-c90040ce, 
>> sp=c90040cdc000, tss.rsp0=8300cec8ffa0
>> (XEN) No stack overflow detected. Skipping stack trace.
>> (XEN) 
>> (XEN) 
>> (XEN) Panic on CPU 0:
>> (XEN) DOUBLE FAULT -- system shutdown
>> (XEN) 
>> (XEN) 
>> (XEN) Reboot in five seconds...
> 
> Oh, so CPU 0 gets screwed by offlining CPU 3. How about this alternative
> (but so far untested) patch:
> 
> --- unstable.orig/xen/arch/x86/smpboot.c
> +++ unstable/xen/arch/x86/smpboot.c
> @@ -874,7 +874,7 @@ static void cleanup_cpu_root_pgt(unsigne
>  l2_pgentry_t *l2t = l3e_to_l2e(l3t[l3_table_offset(stub_linear)]);
>  l1_pgentry_t *l1t = l2e_to_l1e(l2t[l2_table_offset(stub_linear)]);
>  
> -l1t[l2_table_offset(stub_linear)] = l1e_empty();
> +l1t[l1_table_offset(stub_linear)] = l1e_empty();
>  }
>  }
>  

[Xen-devel] [PATCH 3/5] tools: link arch-shared directory

[Wei Liu]

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 .gitignore | 1 +
 tools/include/Makefile | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index 7004349d5a..808f4f5497 100644
--- a/.gitignore
+++ b/.gitignore
@@ -198,6 +198,7 @@ tools/hotplug/Linux/xendomains
 tools/hotplug/NetBSD/rc.d/xencommons
 tools/hotplug/NetBSD/rc.d/xendriverdomain
 tools/include/acpi
+tools/include/arch-shared
 tools/include/xen/*
 tools/include/xen-xsm/*
 tools/include/xen-foreign/*.(c|h|size)
diff --git a/tools/include/Makefile b/tools/include/Makefile
index 666510530e..2c0a7f6e3c 100644
--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -21,6 +21,9 @@ xen/.dir:
ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) 
xen/libelf/
ln -s ../xen-foreign xen/foreign
ln -sf $(XEN_ROOT)/xen/include/acpi acpi
+ifeq ($(CONFIG_X86),y)
+   ln -sf $(XEN_ROOT)/xen/include/asm-x86/arch-shared arch-shared
+endif
touch $@
 
 # Not xen/xsm as that clashes with link to
@@ -65,7 +68,7 @@ uninstall:
 
 .PHONY: clean
 clean:
-   rm -rf xen xen-xsm acpi
+   rm -rf xen xen-xsm acpi arch-shared
$(MAKE) -C xen-foreign clean
 
 .PHONY: dist
-- 
2.11.0


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

[Xen-devel] [PATCH 4/5] libxc: introduce xc_cpuid_x86.h

[Wei Liu]

Collect cpuid related things into a header file. Provide the necessary
macros to make it work.

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
---
 tools/libxc/xc_cpuid_x86.c |  6 +-
 tools/libxc/xc_cpuid_x86.h | 16 
 2 files changed, 17 insertions(+), 5 deletions(-)
 create mode 100644 tools/libxc/xc_cpuid_x86.h

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 9fa2f7c360..89ded718bc 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -27,11 +27,7 @@
 #include 
 #include 
 
-enum {
-#define XEN_CPUFEATURE(name, value) X86_FEATURE_##name = value,
-#include 
-};
-#include "_xc_cpuid_autogen.h"
+#include "xc_cpuid_x86.h"
 
 #define bitmaskof(idx)  (1u << ((idx) & 31))
 #define featureword_of(idx) ((idx) >> 5)
diff --git a/tools/libxc/xc_cpuid_x86.h b/tools/libxc/xc_cpuid_x86.h
new file mode 100644
index 00..1ac12f0e30
--- /dev/null
+++ b/tools/libxc/xc_cpuid_x86.h
@@ -0,0 +1,16 @@
+#ifndef XC_X86_CPUID_H
+#define XC_X86_CPUID_H
+
+enum {
+#define XEN_CPUFEATURE(name, value) X86_FEATURE_##name = value,
+#include 
+};
+#include "_xc_cpuid_autogen.h"
+
+#define MAX(x,y) ((x) > (y) ? (x) : (y))
+
+#define FSCAPINTS FEATURESET_NR_ENTRIES
+
+#include 
+
+#endif
-- 
2.11.0


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

[Xen-devel] [PATCH 2/5] x86: split out cpuid objects and helpers

[Wei Liu]

They are moved to a new header which is going to be consumed by both
the hypervisor and toolstack.

Create a new directory for this kind of headers in anticipation of
more will come.

No functional change.

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

Any suggestion on the directory name?
---
 xen/include/asm-x86/arch-shared/cpuid.h | 213 
 xen/include/asm-x86/cpuid.h | 210 +--
 2 files changed, 215 insertions(+), 208 deletions(-)
 create mode 100644 xen/include/asm-x86/arch-shared/cpuid.h

diff --git a/xen/include/asm-x86/arch-shared/cpuid.h 
b/xen/include/asm-x86/arch-shared/cpuid.h
new file mode 100644
index 00..5c049e11a6
--- /dev/null
+++ b/xen/include/asm-x86/arch-shared/cpuid.h
@@ -0,0 +1,213 @@
+/* Common data structures and functions consumed by hypervisor and toolstack */
+#ifndef __X86_CPUID_SHARED_H__
+#define __X86_CPUID_SHARED_H__
+
+#define FEATURESET_1d 0 /* 0x0001.edx  */
+#define FEATURESET_1c 1 /* 0x0001.ecx  */
+#define FEATURESET_e1d2 /* 0x8001.edx  */
+#define FEATURESET_e1c3 /* 0x8001.ecx  */
+#define FEATURESET_Da14 /* 0x000d:1.eax*/
+#define FEATURESET_7b05 /* 0x0007:0.ebx*/
+#define FEATURESET_7c06 /* 0x0007:0.ecx*/
+#define FEATURESET_e7d7 /* 0x8007.edx  */
+#define FEATURESET_e8b8 /* 0x8008.ebx  */
+#define FEATURESET_7d09 /* 0x0007:0.edx*/
+
+
+#define CPUID_GUEST_NR_BASIC  (0xdu + 1)
+#define CPUID_GUEST_NR_FEAT   (0u + 1)
+#define CPUID_GUEST_NR_CACHE  (5u + 1)
+#define CPUID_GUEST_NR_XSTATE (62u + 1)
+#define CPUID_GUEST_NR_EXTD_INTEL (0x8u + 1)
+#define CPUID_GUEST_NR_EXTD_AMD   (0x1cu + 1)
+#define CPUID_GUEST_NR_EXTD   MAX(CPUID_GUEST_NR_EXTD_INTEL, \
+  CPUID_GUEST_NR_EXTD_AMD)
+struct cpuid_leaf
+{
+uint32_t a, b, c, d;
+};
+
+struct cpuid_policy
+{
+#define DECL_BITFIELD(word) _DECL_BITFIELD(FEATURESET_ ## word)
+#define _DECL_BITFIELD(x)   __DECL_BITFIELD(x)
+#define __DECL_BITFIELD(x)  CPUID_BITFIELD_ ## x
+
+/* Basic leaves: 0x00xx */
+union {
+struct cpuid_leaf raw[CPUID_GUEST_NR_BASIC];
+struct {
+/* Leaf 0x0 - Max and vendor. */
+uint32_t max_leaf, vendor_ebx, vendor_ecx, vendor_edx;
+
+/* Leaf 0x1 - Family/model/stepping and features. */
+uint32_t raw_fms;
+uint8_t :8,   /* Brand ID. */
+clflush_size, /* Number of 8-byte blocks per cache line. */
+lppp, /* Logical processors per package. */
+apic_id;  /* Initial APIC ID. */
+union {
+uint32_t _1c;
+struct { DECL_BITFIELD(1c); };
+};
+union {
+uint32_t _1d;
+struct { DECL_BITFIELD(1d); };
+};
+
+/* Leaf 0x2 - TLB/Cache/Prefetch. */
+uint8_t l2_nr_queries; /* Documented as fixed to 1. */
+uint8_t l2_desc[15];
+
+uint64_t :64, :64; /* Leaf 0x3 - PSN. */
+uint64_t :64, :64; /* Leaf 0x4 - Structured Cache. */
+uint64_t :64, :64; /* Leaf 0x5 - MONITOR. */
+uint64_t :64, :64; /* Leaf 0x6 - Therm/Perf. */
+uint64_t :64, :64; /* Leaf 0x7 - Structured Features. */
+uint64_t :64, :64; /* Leaf 0x8 - rsvd */
+uint64_t :64, :64; /* Leaf 0x9 - DCA */
+
+/* Leaf 0xa - Intel PMU. */
+uint8_t pmu_version;
+};
+} basic;
+
+/* Structured cache leaf: 0x0004[xx] */
+union {
+struct cpuid_leaf raw[CPUID_GUEST_NR_CACHE];
+struct cpuid_cache_leaf {
+uint32_t type:5,
+:27, :32, :32, :32;
+} subleaf[CPUID_GUEST_NR_CACHE];
+} cache;
+
+/* Structured feature leaf: 0x0007[xx] */
+union {
+struct cpuid_leaf raw[CPUID_GUEST_NR_FEAT];
+struct {
+/* Subleaf 0. */
+uint32_t max_subleaf;
+union {
+uint32_t _7b0;
+struct { DECL_BITFIELD(7b0); };
+};
+union {
+uint32_t _7c0;
+struct { DECL_BITFIELD(7c0); };
+};
+union {
+uint32_t _7d0;
+struct { DECL_BITFIELD(7d0); };
+};
+};
+} feat;
+
+/* Xstate feature leaf: 0x000D[xx] */
+union {
+struct cpuid_leaf raw[CPUID_GUEST_NR_XSTATE];
+
+struct {
+/* Subleaf 0. */
+uint32_t xcr0_low, /* b */:32, max_size, xcr0_high;
+
+/* Subleaf 1. */
+union {
+uint32_t Da1;
+struct { DECL_BITFIELD(Da1); };
+};
+uint32_t /* b */:32, xss_low, 

[Xen-devel] [PATCH 1/5] x86: move definition of struct cpuid_leaf to cpuid.h

[Wei Liu]

This is a step towards consolidating relevant data structures and
defines to one location.

It then requires defining cpuid_leaf in user space harness headers to
make them continue to compile.

No functional change.

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/tests/x86_emulator/x86-emulate.h | 6 ++
 xen/arch/x86/x86_emulate/x86_emulate.h | 6 +-
 xen/include/asm-x86/cpuid.h| 4 
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/tools/tests/x86_emulator/x86-emulate.h 
b/tools/tests/x86_emulator/x86-emulate.h
index c5e85de3a2..8ae31a2f9a 100644
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -79,6 +79,12 @@ WRAP(puts);
 
 #undef WRAP
 
+#ifndef cpuid_leaf
+struct cpuid_leaf {
+uint32_t a, b, c, d;
+};
+#endif
+
 #include "x86_emulate/x86_emulate.h"
 
 static inline uint64_t xgetbv(uint32_t xcr)
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h 
b/xen/arch/x86/x86_emulate/x86_emulate.h
index c22e7745ad..cc2cf54141 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -172,11 +172,7 @@ enum x86_emulate_fpu_type {
 X86EMUL_FPU_none
 };
 
-struct cpuid_leaf
-{
-uint32_t a, b, c, d;
-};
-
+struct cpuid_leaf;
 struct x86_emulate_state;
 
 /*
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 4cce2686cb..ca664d50e2 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -66,6 +66,10 @@ extern struct cpuidmasks cpuidmask_defaults;
 #define CPUID_GUEST_NR_EXTD_AMD   (0x1cu + 1)
 #define CPUID_GUEST_NR_EXTD   MAX(CPUID_GUEST_NR_EXTD_INTEL, \
   CPUID_GUEST_NR_EXTD_AMD)
+struct cpuid_leaf
+{
+uint32_t a, b, c, d;
+};
 
 struct cpuid_policy
 {
-- 
2.11.0


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

[Xen-devel] [PATCH 5/5] XXX DO NOT APPLY: compilation test

[Wei Liu]

---
 tools/libxc/xc_cpuid_x86.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 89ded718bc..0af04a4e5a 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -869,3 +869,20 @@ int xc_cpuid_set(
 free_cpuid_domain_info();
 return rc;
 }
+
+static void __attribute__((__unused__)) test_func(void)
+{
+struct cpuid_leaf leaf;
+struct cpuid_policy policy;
+struct cpuid_cache_leaf cache_leaf;
+uint32_t fs[FSCAPINTS] = { 0, };
+
+memset(, 0, sizeof(leaf));
+memset(, 0, sizeof(policy));
+memset(_leaf, 0, sizeof(cache_leaf));
+
+cpuid_policy_to_featureset(, fs);
+cpuid_featureset_to_policy(fs, );
+
+return;
+}
-- 
2.11.0


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

[Xen-devel] [PATCH 0/5] Share CPUID stuff between hypervisor and toolstack

[Wei Liu]

The hypervisor has some nice objects and definitions that toolstack can use,
too. Make that happen.

The anticipation is in the future MSR objects and definitions should be shared,
too.

Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Andrew Cooper 

Wei Liu (5):
  x86: move definition of struct cpuid_leaf to cpuid.h
  x86: split out cpuid objects and helpers
  tools: link arch-shared directory
  libxc: introduce xc_cpuid_x86.h
  XXX DO NOT APPLY: compilation test

 .gitignore  |   1 +
 tools/include/Makefile  |   5 +-
 tools/libxc/xc_cpuid_x86.c  |  23 +++-
 tools/libxc/xc_cpuid_x86.h  |  16 +++
 tools/tests/x86_emulator/x86-emulate.h  |   6 +
 xen/arch/x86/x86_emulate/x86_emulate.h  |   6 +-
 xen/include/asm-x86/arch-shared/cpuid.h | 213 
 xen/include/asm-x86/cpuid.h | 206 +-
 8 files changed, 261 insertions(+), 215 deletions(-)
 create mode 100644 tools/libxc/xc_cpuid_x86.h
 create mode 100644 xen/include/asm-x86/arch-shared/cpuid.h

-- 
2.11.0


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

Re: [Xen-devel] [PATCH 9/9] x86/vmx: Don't leak EFER.NXE into guest context

[Roger Pau Monné]

On Tue, May 22, 2018 at 12:20:46PM +0100, Andrew Cooper wrote:
> Intel hardware only uses 4 bits in MSR_EFER.  Changes to LME and LMA are
> handled automatically via the VMENTRY_CTLS.IA32E_MODE bit.
> 
> SCE is handled by ad-hoc logic in context_switch(), vmx_restore_guest_msrs()
> and vmx_update_guest_efer(), and works by altering the host SCE value to match
> the setting the guest wants.  This works because, in HVM vcpu context, Xen
> never needs to execute a SYSCALL or SYSRET instruction.
> 
> However, NXE has never been context switched.  Unlike SCE, NXE cannot be
> context switched at vcpu boundaries because disabling NXE makes PTE.NX bits
> reserved and cause a pagefault when encountered.  This means that the guest
> always has Xen's setting in effect, irrespective of the bit it can see and
> modify in its virtualised view of MSR_EFER.
> 
> This isn't a major problem for production operating systems because they, like
> Xen, always turn the NXE on when it is available.  However, it does have an
> observable effect on which guest PTE bits are valid, and whether
> PFEC_insn_fetch is visible in a #PF error code.
> 
> Second generation VT-x hardware has host and guest EFER fields in the VMCS,
> and support for loading and saving them automatically.  First generation VT-x
> hardware needs to use MSR load/save lists to cause an atomic switch of
> MSR_EFER on vmentry/exit.
> 
> Therefore we update vmx_init_vmcs_config() to find and use guest/host EFER
> support when available (and MSR load/save lists on older hardware) and drop
> all ad-hoc alteration of SCE.
> 
> There are two complications for shadow guests.  NXE, being a paging setting
> needs to remain under host control, but that is fine as it is also Xen which
> handles the pagefaults.  Also, it turns out that without EPT enabled, hardware
> won't tolerate LME and LMA being different via either the GUEST_EFER VMCS
> setting, or via the guest load list.  This doesn't matter in practice as we
> intercept all writes to CR0 and reads from MSR_EFER, so can provide
> architecturally consistent behaviour from the guests point of view.
> 
> As a result of fixing EFER context switching, we can remove the Intel-special
> case from hvm_nx_enabled() and let guest_walk_tables() work with the real
> guest paging settings.
> 
> Signed-off-by: Andrew Cooper 

LGTM:

Reviewed-by: Roger Pau Monné 

One question below though.

> diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
> b/xen/include/asm-x86/hvm/vmx/vmcs.h
> index cfd174c..6c6897c 100644
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -306,6 +306,8 @@ extern u64 vmx_ept_vpid_cap;
>  (vmx_cpu_based_exec_control & CPU_BASED_MONITOR_TRAP_FLAG)
>  #define cpu_has_vmx_pat \
>  (vmx_vmentry_control & VM_ENTRY_LOAD_GUEST_PAT)
> +#define cpu_has_vmx_efer \
> +(vmx_vmentry_control & VM_ENTRY_LOAD_GUEST_EFER)

Don't you also need a vmx_vmexit_control & VM_EXIT_SAVE_GUEST_EFER and
vmx_vmexit_control & VM_EXIT_LOAD_HOST_EFER?

Or can the presence of those two be inferred from
VM_ENTRY_LOAD_GUEST_EFER?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

[Andrew Cooper]

On 24/05/18 16:08, Jan Beulich wrote:
 On 22.05.18 at 13:20,  wrote:
>> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
>> updates a host MSR load list entry with the current hardware value of
>> MSR_DEBUGCTL.  This is wrong.
>>
>> On VMExit, hardware automatically resets MSR_DEBUGCTL to 0.
> I'm pretty certain that back when I write this, the SDM didn't spell this out.

I wondered as much.  Gen-1 VT-x is well documented as forcing the
VM_EXIT_SAVE_DEBUG_CTLS control to be set in non-root operation, which
clearly suggests that it has always had this behaviour.

>
>>  The only case
>> where different behaviour is needed is if Xen is debugging itself, and this
>> needs setting up unconditionally for the lifetime of the VM.
>>
>> The `ler` command line boolean is the only way to configure any use of
>> MSR_DEBUGCTL for Xen, so tie the host load list entry to this setting in
>> construct_vmcs().  Any runtime update of Xen's MSR_DEBUGCTL setting requires
>> more complicated synchronisation across all the running VMs.
>>
>> In the exceedingly common case, this avoids the unnecessary overhead of 
>> having
>> a host load entry performing the same zeroing operation that hardware has
>> already performed as part of the VMExit.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
>
>> Notes for backporting: This change probably does want backporting, but 
>> depends
>> on the previous patch "Support remote access to the MSR lists", and adds an
>> extra rdmsr to the vcpu construction path (resolved in a later patch).
> I wonder if for backporting purposes we couldn't stick this function
> invocation somewhere else, like vmx_ctxt_switch_to() or
> vmx_do_resume(). I realize the potential allocation failure is a problem here,
> but for that we could either allocate the memory at the place you now
> invoke vmx_add_host_load_msr(), or take the brute force approach and
> crash the domain upon failure (the net effect won't be much different to
> allocation failing during domain destruction - the domain won't start in 
> either
> case).
>
> I mention this because it seems to me that pulling in the previous patch
> would in turn require pulling in earlier ones.

Yeah - to backport this change, you need 6 patches from the series.

That said, I think I've come up with a much safer, faster, alternative
which I can disentangle completely from this series.

I was already planning to clean up the host debugctl handling to have a
single read_mostly value.  With a trivial alternative block in the vmx
vmexit handler, we can do away with the host load entry entirely (and,
as I've been reliably informed, doing things this way is faster than
having microcode walk the host/guest load/save lists).

~Andrew

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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Jan Beulich]

>>> On 24.05.18 at 17:10,  wrote:
> Jan Beulich:
> On 24.05.18 at 16:14,  wrote:
>>> Jan Beulich:
>>> On 24.05.18 at 16:00,  wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs share a stub
>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>> when bringing down a CPU; it may only be unmapped when no other online
>> CPU uses that same page.
>>
>> Reported-by: Simon Gaiser 
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>>  
>>  free_xen_pagetable(rpt);
>>  
>> -/* Also zap the stub mapping for this CPU. */
>> +/*
>> + * Also zap the stub mapping for this CPU, if no other online one 
>> uses
>> + * the same page.
>> + */
>> +if ( stub_linear )
>> +{
>> +unsigned int other;
>> +
>> +for_each_online_cpu(other)
>> +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> 
>> PAGE_SHIFT) 
> )
>> +{
>> +stub_linear = 0;
>> +break;
>> +}
>> +}
>>  if ( stub_linear )
>>  {
>>  l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
>
> Tried this on-top of staging (fc5805daef) and I still get the same
> double fault.

 Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. 
 What
 size a system are you testing on? Mine has got only 12 CPUs, i.e. all stubs
 are in the same page (and I'd never unmap anything here at all).
>>>
>>> 4 cores + HT, so 8 CPUs from Xen's PoV.
>> 
>> May I ask you to do two things:
>> 1) confirm that you can offline CPUs successfully using xen-hptool,
>> 2) add a printk() to the code above making clear whether/when any
>> of the mappings actually get zapped?
> 
> There seem to be two failure modes now. It seems that both can be
> triggered either by offlining a cpu or by suspend. Using cpu offlining
> below since during suspend I often loose part of the serial output.
> 
> Failure mode 1, the double fault as before:
> 
> root@localhost:~# xen-hptool cpu-offline 3
> Prepare to offline CPU 3
> (XEN) Broke affinity for irq 9
> (XEN) Broke affinity for irq 29
> (XEN) dbg: stub_linear't1 = 18446606431818858880
> (XEN) dbg: first stub_linear if
> (XEN) dbg: stub_linear't2 = 18446606431818858880
> (XEN) dbg: second stub_linear if
> CPU 3 offlined successfully
> root@localhost:~# (XEN) *** DOUBLE FAULT ***
> (XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] handle_exception+0x9c/0xff
> (XEN) RFLAGS: 00010006   CONTEXT: hypervisor
> (XEN) rax: c90040cdc0a8   rbx:    rcx: 0006
> (XEN) rdx:    rsi:    rdi: 
> (XEN) rbp: 36ffbf323f37   rsp: c90040cdc000   r8:  
> (XEN) r9:     r10:    r11: 
> (XEN) r12:    r13:    r14: c90040cd
> (XEN) r15:    cr0: 8005003b   cr4: 00042660
> (XEN) cr3: 000128109000   cr2: c90040cdbff8
> (XEN) fsb: 7fc01c3c6dc0   gsb: 88021e70   gss: 
> (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
> (XEN) Xen code around  (handle_exception+0x9c/0xff):
> (XEN)  00 f3 90 0f ae e8 eb f9  07 00 00 00 f3 90 0f ae e8 eb f9 83 e9 01 
> 75
> (XEN) Current stack base c90040cd8000 differs from expected 
> 8300cec88000
> (XEN) Valid stack range: c90040cde000-c90040ce, 
> sp=c90040cdc000, tss.rsp0=8300cec8ffa0
> (XEN) No stack overflow detected. Skipping stack trace.
> (XEN) 
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) DOUBLE FAULT -- system shutdown
> (XEN) 
> (XEN) 
> (XEN) Reboot in five seconds...

Oh, so CPU 0 gets screwed by offlining CPU 3. How about this alternative
(but so far untested) patch:

--- unstable.orig/xen/arch/x86/smpboot.c
+++ unstable/xen/arch/x86/smpboot.c
@@ -874,7 +874,7 @@ static void cleanup_cpu_root_pgt(unsigne
 l2_pgentry_t *l2t = l3e_to_l2e(l3t[l3_table_offset(stub_linear)]);
 l1_pgentry_t *l1t = l2e_to_l1e(l2t[l2_table_offset(stub_linear)]);
 
-l1t[l2_table_offset(stub_linear)] = l1e_empty();
+l1t[l1_table_offset(stub_linear)] = l1e_empty();
 }
 }
 

Jan


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

Re: [Xen-devel] [PATCH 8/9] x86/vmx: Support removing MSRs from the host/guest load/save lists

[Andrew Cooper]

On 24/05/18 16:42, Roger Pau Monné wrote:
> On Tue, May 22, 2018 at 12:20:45PM +0100, Andrew Cooper wrote:
>> Up until this point, the MSR load/save lists have only ever accumulated
>> content.  Introduce vmx_del_msr() as a companion to vmx_add_msr().
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Jun Nakajima 
>> CC: Kevin Tian 
>> CC: Wei Liu 
>> CC: Roger Pau Monné 
>> ---
>>  xen/arch/x86/hvm/vmx/vmcs.c| 68 
>> ++
>>  xen/include/asm-x86/hvm/vmx/vmcs.h |  1 +
>>  2 files changed, 69 insertions(+)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
>> index 7bf19a0..e1a8f95 100644
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -1465,6 +1465,74 @@ int vmx_add_msr(struct vcpu *v, uint32_t msr, 
>> uint64_t val,
>>  return rc;
>>  }
>>  
>> +int vmx_del_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type)
>> +{
>> +struct arch_vmx_struct *arch_vmx = >arch.hvm_vmx;
>> +struct vmx_msr_entry *start = NULL, *ent, *end;
>> +unsigned int substart, subend, total;
>> +
>> +ASSERT(v == current || !vcpu_runnable(v));
>> +
>> +switch ( type )
>> +{
>> +case VMX_MSR_HOST:
>> +start= arch_vmx->host_msr_area;
>> +substart = 0;
>> +subend   = arch_vmx->host_msr_count;
>> +total= subend;
>> +break;
>> +
>> +case VMX_MSR_GUEST:
>> +start= arch_vmx->msr_area;
>> +substart = 0;
>> +subend   = arch_vmx->msr_save_count;
>> +total= arch_vmx->msr_load_count;
>> +break;
>> +
>> +case VMX_MSR_GUEST_LOADONLY:
>> +start= arch_vmx->msr_area;
>> +substart = arch_vmx->msr_save_count;
>> +subend   = arch_vmx->msr_load_count;
>> +total= subend;
>> +break;
>> +
>> +default:
>> +ASSERT_UNREACHABLE();
>> +}
> The above chunk is already in vmx_find_msr and vmx_add_msr, maybe a
> static helper that sets start/substart/subend/total would be helpful
> here?

Its actually more than that.  They are identical identical until after
the locate_msr_entry() call.  The problem is that I can't find a clean
way of collecting the logic which is also readable.

I'd also like to fold together the add side, but that is further
complicated by the memory allocation logic.

~Andrew

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

Re: [Xen-devel] [PATCH 8/9] x86/vmx: Support removing MSRs from the host/guest load/save lists

[Roger Pau Monné]

On Tue, May 22, 2018 at 12:20:45PM +0100, Andrew Cooper wrote:
> Up until this point, the MSR load/save lists have only ever accumulated
> content.  Introduce vmx_del_msr() as a companion to vmx_add_msr().
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> ---
>  xen/arch/x86/hvm/vmx/vmcs.c| 68 
> ++
>  xen/include/asm-x86/hvm/vmx/vmcs.h |  1 +
>  2 files changed, 69 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index 7bf19a0..e1a8f95 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -1465,6 +1465,74 @@ int vmx_add_msr(struct vcpu *v, uint32_t msr, uint64_t 
> val,
>  return rc;
>  }
>  
> +int vmx_del_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type)
> +{
> +struct arch_vmx_struct *arch_vmx = >arch.hvm_vmx;
> +struct vmx_msr_entry *start = NULL, *ent, *end;
> +unsigned int substart, subend, total;
> +
> +ASSERT(v == current || !vcpu_runnable(v));
> +
> +switch ( type )
> +{
> +case VMX_MSR_HOST:
> +start= arch_vmx->host_msr_area;
> +substart = 0;
> +subend   = arch_vmx->host_msr_count;
> +total= subend;
> +break;
> +
> +case VMX_MSR_GUEST:
> +start= arch_vmx->msr_area;
> +substart = 0;
> +subend   = arch_vmx->msr_save_count;
> +total= arch_vmx->msr_load_count;
> +break;
> +
> +case VMX_MSR_GUEST_LOADONLY:
> +start= arch_vmx->msr_area;
> +substart = arch_vmx->msr_save_count;
> +subend   = arch_vmx->msr_load_count;
> +total= subend;
> +break;
> +
> +default:
> +ASSERT_UNREACHABLE();
> +}

The above chunk is already in vmx_find_msr and vmx_add_msr, maybe a
static helper that sets start/substart/subend/total would be helpful
here?

Roger.

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

Re: [Xen-devel] [PATCH 7/9] x86/vmx: Support load-only guest MSR list entries

[Roger Pau Monné]

On Tue, May 22, 2018 at 12:20:44PM +0100, Andrew Cooper wrote:
> Currently, the VMX_MSR_GUEST type maintains completely symmetric guest load
> and save lists, by pointing VM_EXIT_MSR_STORE_ADDR and VM_ENTRY_MSR_LOAD_ADDR
> at the same page, and setting VM_EXIT_MSR_STORE_COUNT and
> VM_ENTRY_MSR_LOAD_COUNT to the same value.
> 
> However, for MSRs which we won't let the guest have direct access to, having
> hardware save the current value on VMExit is unnecessary overhead.
> 
> To avoid this overhead, we must make the load and save lists asymmetric.  By
> making the entry load count greater than the exit store count, we can maintain
> two adjacent lists of MSRs, the first of which is saved and restored, and the
> second of which is only restored on VMEntry.
> 
> For simplicity:
>  * Both adjacent lists are still sorted by MSR index.
>  * It undefined behaviour to insert the same MSR into both lists.
>  * The total size of both lists is still limited at 256 entries (one 4k page).
> 
> Split the current msr_count field into msr_{load,save}_count, and introduce a
> new VMX_MSR_GUEST_LOADONLY type, and update vmx_{add,find}_msr() to calculate
> which sublist to search, based on type.  VMX_MSR_HOST has no logical sublist,
> whereas VMX_MSR_GUEST has a sublist between 0 and the save count, while
> VMX_MSR_GUEST_LOADONLY has a sublist between the save count and the load
> count.
> 
> One subtle point is that inserting an MSR into the load-save list involves
> moving the entire load-only list, and updating both counts.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

Just one nit below.

> @@ -1423,8 +1446,11 @@ int vmx_add_msr(struct vcpu *v, uint32_t msr, uint64_t 
> val,
>  break;
>  
>  case VMX_MSR_GUEST:
> -__vmwrite(VM_EXIT_MSR_STORE_COUNT, ++arch_vmx->msr_count);
> -__vmwrite(VM_ENTRY_MSR_LOAD_COUNT, arch_vmx->msr_count);
> +__vmwrite(VM_EXIT_MSR_STORE_COUNT, ++arch_vmx->msr_save_count);
> +
> +/* Fallthrough */
> +case VMX_MSR_GUEST_LOADONLY:
> +__vmwrite(VM_ENTRY_MSR_LOAD_COUNT, ++arch_vmx->msr_load_count);
>  break;
>  }

Would it make sense to add something like:

ASSERT(arch_vmx->msr_save_count <= arch_vmx->msr_load_count);

Thanks.

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

Re: [Xen-devel] [PATCH v2] arm: clean-up: correct find_*_bit() functions use

[Julien Grall]

Hi Artem,

Title: It would be good to specify the subsystem you modify.

arm: vgic: ...

On 24/05/18 16:24, Artem Mygaiev wrote:
vgic_vcpu_pending_irq() uses find_next_bit() library function with 
single 'unsigned long' variable, while it is designed to work with 
memory regions and offsets. It would be more correct to use the 
find_first_bit() function instead.


The commit message sounds like it is wrong to use find_next_bit(). 
However, as I mentioned earlier, find_first_bit() is just a wrapper of 
find_next_bit() on Arm64.


So I would reword the commit message as:

"arm: vgic: Use find_first_bit instead of find_next_bit when possible

find_next_bit(foo, sz, 0) is equivalent to find_first_bit(foo, sz). The 
latter is easier to understand. Some architecture may also have a 
optimized version of find_first_bit(...). So replace the occurrence of 
find_next_bit in vgic_vcpu_pending_irq()."


Cheers,



Signed-off-by: Artem Mygaiev 

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index d831b35525..fd63906e9b 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -362,7 +362,7 @@ int vgic_vcpu_pending_irq(struct vcpu *v)
  ASSERT(v == current);

  mask_priority = gic_hw_ops->read_vmcr_priority();
-    active_priority = find_next_bit(, 32, 0);
+    active_priority = find_first_bit(, 32);

  spin_lock_irqsave(>arch.vgic.lock, flags);



--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Jan Beulich]

>>> On 24.05.18 at 17:10,  wrote:
> Jan Beulich:
> On 24.05.18 at 16:14,  wrote:
>>> Jan Beulich:
>>> On 24.05.18 at 16:00,  wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs share a stub
>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>> when bringing down a CPU; it may only be unmapped when no other online
>> CPU uses that same page.
>>
>> Reported-by: Simon Gaiser 
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>>  
>>  free_xen_pagetable(rpt);
>>  
>> -/* Also zap the stub mapping for this CPU. */
>> +/*
>> + * Also zap the stub mapping for this CPU, if no other online one 
>> uses
>> + * the same page.
>> + */
>> +if ( stub_linear )
>> +{
>> +unsigned int other;
>> +
>> +for_each_online_cpu(other)
>> +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> 
>> PAGE_SHIFT) 
> )
>> +{
>> +stub_linear = 0;
>> +break;
>> +}
>> +}
>>  if ( stub_linear )
>>  {
>>  l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
>
> Tried this on-top of staging (fc5805daef) and I still get the same
> double fault.

 Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. 
 What
 size a system are you testing on? Mine has got only 12 CPUs, i.e. all stubs
 are in the same page (and I'd never unmap anything here at all).
>>>
>>> 4 cores + HT, so 8 CPUs from Xen's PoV.
>> 
>> May I ask you to do two things:
>> 1) confirm that you can offline CPUs successfully using xen-hptool,
>> 2) add a printk() to the code above making clear whether/when any
>> of the mappings actually get zapped?
> 
> There seem to be two failure modes now. It seems that both can be
> triggered either by offlining a cpu or by suspend. Using cpu offlining
> below since during suspend I often loose part of the serial output.
> 
> Failure mode 1, the double fault as before:
> 
> root@localhost:~# xen-hptool cpu-offline 3
> Prepare to offline CPU 3
> (XEN) Broke affinity for irq 9
> (XEN) Broke affinity for irq 29
> (XEN) dbg: stub_linear't1 = 18446606431818858880
> (XEN) dbg: first stub_linear if
> (XEN) dbg: stub_linear't2 = 18446606431818858880
> (XEN) dbg: second stub_linear if
> CPU 3 offlined successfully
> root@localhost:~# (XEN) *** DOUBLE FAULT ***
> (XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] handle_exception+0x9c/0xff
> (XEN) RFLAGS: 00010006   CONTEXT: hypervisor
> (XEN) rax: c90040cdc0a8   rbx:    rcx: 0006
> (XEN) rdx:    rsi:    rdi: 
> (XEN) rbp: 36ffbf323f37   rsp: c90040cdc000   r8:  
> (XEN) r9:     r10:    r11: 
> (XEN) r12:    r13:    r14: c90040cd
> (XEN) r15:    cr0: 8005003b   cr4: 00042660
> (XEN) cr3: 000128109000   cr2: c90040cdbff8
> (XEN) fsb: 7fc01c3c6dc0   gsb: 88021e70   gss: 
> (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
> (XEN) Xen code around  (handle_exception+0x9c/0xff):
> (XEN)  00 f3 90 0f ae e8 eb f9  07 00 00 00 f3 90 0f ae e8 eb f9 83 e9 01 
> 75
> (XEN) Current stack base c90040cd8000 differs from expected 
> 8300cec88000
> (XEN) Valid stack range: c90040cde000-c90040ce, 
> sp=c90040cdc000, tss.rsp0=8300cec8ffa0
> (XEN) No stack overflow detected. Skipping stack trace.
> (XEN) 
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) DOUBLE FAULT -- system shutdown
> (XEN) 
> (XEN) 
> (XEN) Reboot in five seconds...

And I see now why I thought the patch works - I should have removed
"xpti=no" from the command line. The diagnosis was wrong altogether:
While we share physical pages for stubs, we don#t share virtual space.
See alloc_stub_page().

But I'm pretty sure it has something to do with setting up stub space.
Looking around again ...

Jan


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

Re: [Xen-devel] [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

[Michal Hocko]

On Thu 24-05-18 08:18:18, Matthew Wilcox wrote:
> On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote:
> > > If we had eight ZONEs, we could offer:
> > 
> > No, please no more zones. What we have is quite a maint. burden on its
> > own. Ideally we should only have lowmem, highmem and special/device
> > zones for directly kernel accessible memory, the one that the kernel
> > cannot or must not use and completely special memory managed out of
> > the page allocator. All the remaining constrains should better be
> > implemented on top.
> 
> I believe you when you say that they're a maintenance pain.  Is that
> maintenance pain because they're so specialised?

Well, it used to be LRU balancing which is gone with the node reclaim
but that brings new challenges. Now as you say their meaning is not
really clear to users and that leads to bugs left and right.

> ie if we had more,
> could we solve our pain by making them more generic?

Well, if you have more you will consume more bits in the struct pages,
right?

[...]

> > But those already do have aproper API, IIUC. So do we really need to
> > make our GFP_*/Zone API more complicated than it already is?
> 
> I don't want to change the driver API (setting the DMA mask, etc),
> but we don't actually have a good API to the page allocator for the
> implementation of dma_alloc_foo() to request pages.  More or less,
> architectures do:
> 
>   if (mask < 4GB)
>   alloc_page(GFP_DMA)
>   else if (mask < 64EB)
>   alloc_page(GFP_DMA32)
>   else
>   alloc_page(GFP_HIGHMEM)
> 
> it more-or-less sucks that the devices with 28-bit DMA limits are forced
> to allocate from the low 16MB when they're perfectly capable of using the
> low 256MB.

Do we actually care all that much about those? If yes then we should
probably follow the ZONE_DMA (x86) path and use a CMA region for them.
I mean most devices should be good with very limited addressability or
below 4G, no?
-- 
Michal Hocko
SUSE Labs

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

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

[Jan Beulich]

>>> On 22.05.18 at 13:20,  wrote:
> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
> updates a host MSR load list entry with the current hardware value of
> MSR_DEBUGCTL.  This is wrong.
> 
> On VMExit, hardware automatically resets MSR_DEBUGCTL to 0.

I'm pretty certain that back when I write this, the SDM didn't spell this out.

>  The only case
> where different behaviour is needed is if Xen is debugging itself, and this
> needs setting up unconditionally for the lifetime of the VM.
> 
> The `ler` command line boolean is the only way to configure any use of
> MSR_DEBUGCTL for Xen, so tie the host load list entry to this setting in
> construct_vmcs().  Any runtime update of Xen's MSR_DEBUGCTL setting requires
> more complicated synchronisation across all the running VMs.
> 
> In the exceedingly common case, this avoids the unnecessary overhead of having
> a host load entry performing the same zeroing operation that hardware has
> already performed as part of the VMExit.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

> Notes for backporting: This change probably does want backporting, but depends
> on the previous patch "Support remote access to the MSR lists", and adds an
> extra rdmsr to the vcpu construction path (resolved in a later patch).

I wonder if for backporting purposes we couldn't stick this function
invocation somewhere else, like vmx_ctxt_switch_to() or
vmx_do_resume(). I realize the potential allocation failure is a problem here,
but for that we could either allocate the memory at the place you now
invoke vmx_add_host_load_msr(), or take the brute force approach and
crash the domain upon failure (the net effect won't be much different to
allocation failing during domain destruction - the domain won't start in either
case).

I mention this because it seems to me that pulling in the previous patch
would in turn require pulling in earlier ones.

Jan



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

[Xen-devel] [PATCH v2] arm: clean-up: correct find_*_bit() functions use

[Artem Mygaiev]

vgic_vcpu_pending_irq() uses find_next_bit() library function with 
single 'unsigned long' variable, while it is designed to work with 
memory regions and offsets. It would be more correct to use the 
find_first_bit() function instead.


Signed-off-by: Artem Mygaiev 

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index d831b35525..fd63906e9b 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -362,7 +362,7 @@ int vgic_vcpu_pending_irq(struct vcpu *v)
 ASSERT(v == current);

 mask_priority = gic_hw_ops->read_vmcr_priority();
-active_priority = find_next_bit(, 32, 0);
+active_priority = find_first_bit(, 32);

 spin_lock_irqsave(>arch.vgic.lock, flags);


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

Re: [Xen-devel] [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

[Matthew Wilcox]

On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote:
> > If we had eight ZONEs, we could offer:
> 
> No, please no more zones. What we have is quite a maint. burden on its
> own. Ideally we should only have lowmem, highmem and special/device
> zones for directly kernel accessible memory, the one that the kernel
> cannot or must not use and completely special memory managed out of
> the page allocator. All the remaining constrains should better be
> implemented on top.

I believe you when you say that they're a maintenance pain.  Is that
maintenance pain because they're so specialised?  ie if we had more,
could we solve our pain by making them more generic?

> > ZONE_16M// 24 bit
> > ZONE_256M   // 28 bit
> > ZONE_LOWMEM // CONFIG_32BIT only
> > ZONE_4G // 32 bit
> > ZONE_64G// 36 bit
> > ZONE_1T // 40 bit
> > ZONE_ALL// everything larger
> > ZONE_MOVABLE// movable allocations; no physical address guarantees
> > 
> > #ifdef CONFIG_64BIT
> > #define ZONE_NORMAL ZONE_ALL
> > #else
> > #define ZONE_NORMAL ZONE_LOWMEM
> > #endif
> > 
> > This would cover most driver DMA mask allocations; we could tweak the
> > offered zones based on analysis of what people need.
> 
> But those already do have aproper API, IIUC. So do we really need to
> make our GFP_*/Zone API more complicated than it already is?

I don't want to change the driver API (setting the DMA mask, etc),
but we don't actually have a good API to the page allocator for the
implementation of dma_alloc_foo() to request pages.  More or less,
architectures do:

if (mask < 4GB)
alloc_page(GFP_DMA)
else if (mask < 64EB)
alloc_page(GFP_DMA32)
else
alloc_page(GFP_HIGHMEM)

it more-or-less sucks that the devices with 28-bit DMA limits are forced
to allocate from the low 16MB when they're perfectly capable of using the
low 256MB.  Sure, my proposal doesn't help 27 or 26 bit DMA mask devices,
but those are pretty rare.

I'm sure you don't need reminding what a mess vmalloc_32 is, and the
implementation of saa7146_vmalloc_build_pgtable() just hurts.

> > #define GFP_HIGHUSER(GFP_USER | ZONE_ALL)
> > #define GFP_HIGHUSER_MOVABLE(GFP_USER | ZONE_MOVABLE)
> > 
> > One other thing I want to see is that fallback from zones happens from
> > highest to lowest normally (ie if you fail to allocate in 1T, then you
> > try to allocate from 64G), but movable allocations hapen from lowest
> > to highest.  So ZONE_16M ends up full of page cache pages which are
> > readily evictable for the rare occasions when we need to allocate memory
> > below 16MB.
> > 
> > I'm sure there are lots of good reasons why this won't work, which is
> > why I've been hesitant to propose it before now.
> 
> I am worried you are playing with a can of worms...

Yes.  Me too.

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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Simon Gaiser]

Andrew Cooper:
> On 24/05/18 15:35, Simon Gaiser wrote:
>> Andrew Cooper:
>>> On 24/05/18 15:14, Simon Gaiser wrote:
 Jan Beulich:
 On 24.05.18 at 16:00,  wrote:
>> Jan Beulich:
>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>>> I've failed to remember the fact that multiple CPUs share a stub
>>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>>> when bringing down a CPU; it may only be unmapped when no other online
>>> CPU uses that same page.
>>>
>>> Reported-by: Simon Gaiser 
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>>>  
>>>  free_xen_pagetable(rpt);
>>>  
>>> -/* Also zap the stub mapping for this CPU. */
>>> +/*
>>> + * Also zap the stub mapping for this CPU, if no other online one 
>>> uses
>>> + * the same page.
>>> + */
>>> +if ( stub_linear )
>>> +{
>>> +unsigned int other;
>>> +
>>> +for_each_online_cpu(other)
>>> +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> 
>>> PAGE_SHIFT) )
>>> +{
>>> +stub_linear = 0;
>>> +break;
>>> +}
>>> +}
>>>  if ( stub_linear )
>>>  {
>>>  l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
>> Tried this on-top of staging (fc5805daef) and I still get the same
>> double fault.
> Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. 
> What
> size a system are you testing on? Mine has got only 12 CPUs, i.e. all 
> stubs
> are in the same page (and I'd never unmap anything here at all).
 4 cores + HT, so 8 CPUs from Xen's PoV.
>>> Can you try with the "x86/traps: Dump the instruction stream even for
>>> double faults" patch I've just posted, and show the full #DF panic log
>>> please?  (Its conceivable that there are multiple different issues here.)
>> With Jan's and your patch:
>>
>> (XEN) mce_intel.c:782: MCA Capability: firstbank 0, extended MCE MSR 0, 
>> BCAST, CMCI
>> (XEN) CPU0 CMCI LVT vector (0xf2) already installed
>> (XEN) Finishing wakeup from ACPI S3 state.
>> (XEN) Enabling non-boot CPUs  ...
>> (XEN) emul-priv-op.c:1166:d0v1 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee0
>> (XEN) emul-priv-op.c:1166:d0v1 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee00800
>> (XEN) emul-priv-op.c:1166:d0v2 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee0
>> (XEN) emul-priv-op.c:1166:d0v2 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee00800
>> (XEN) emul-priv-op.c:1166:d0v3 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee0
>> (XEN) emul-priv-op.c:1166:d0v3 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee00800
>> (XEN) emul-priv-op.c:1166:d0v4 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee0
>> (XEN) emul-priv-op.c:1166:d0v4 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee00800
> 
> /sigh - Naughty Linux.  The PVOps really ought to know that they don't
> have an APIC to play with, not that this related to the crash.
> 
>> (XEN) *** DOUBLE FAULT ***
>> (XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
>> (XEN) CPU:0
>> (XEN) RIP:e008:[] handle_exception+0x9c/0xff
>> (XEN) RFLAGS: 00010006   CONTEXT: hypervisor
>> (XEN) rax: c90040ce40d8   rbx:    rcx: 0003
>> (XEN) rdx:    rsi:    rdi: 
>> (XEN) rbp: 36ffbf31bf07   rsp: c90040ce4000   r8:  
>> (XEN) r9:     r10:    r11: 
>> (XEN) r12:    r13:    r14: c90040ce7fff
>> (XEN) r15:    cr0: 8005003b   cr4: 00042660
>> (XEN) cr3: 00022200a000   cr2: c90040ce3ff8
>> (XEN) fsb: 7fa9e7909740   gsb: 88021e74   gss: 
>> (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
>> (XEN) Xen code around  (handle_exception+0x9c/0xff):
>> (XEN)  00 f3 90 0f ae e8 eb f9  07 00 00 00 f3 90 0f ae e8 eb f9 83 e9 
>> 01 75
>> (XEN) Current stack base c90040ce differs from expected 
>> 8300cec88000
>> (XEN) Valid stack range: c90040ce6000-c90040ce8000, 
>> sp=c90040ce4000, tss.rsp0=8300cec8ffa0
>> (XEN) No stack overflow detected. Skipping stack trace.
> 
> Ok - this is the same as George's crash, and yes - I did misdiagnose the
> stack we were on.  I presume this hardware doesn't have SMAP? (or 

Re: [Xen-devel] [PATCH 4/9] x86/vmx: Support remote access to the MSR lists

[Jan Beulich]

>>> On 22.05.18 at 13:20,  wrote:
> @@ -537,25 +544,27 @@ enum vmx_msr_list_type {
>  VMX_MSR_GUEST,
>  };
>  
> -int vmx_add_msr(uint32_t msr, enum vmx_msr_list_type type);
> +int vmx_add_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type);
>  
> -static inline int vmx_add_host_load_msr(uint32_t msr)
> +static inline int vmx_add_guest_msr(struct vcpu *v, uint32_t msr)
>  {
> -return vmx_add_msr(msr, VMX_MSR_HOST);
> +return vmx_add_msr(v, msr, VMX_MSR_GUEST);
>  }
>  
> -static inline int vmx_add_guest_msr(uint32_t msr)
> +static inline int vmx_add_host_load_msr(struct vcpu *v, uint32_t msr)
>  {
> -return vmx_add_msr(msr, VMX_MSR_GUEST);
> +return vmx_add_msr(v, msr, VMX_MSR_HOST);
>  }
>  
> -struct vmx_msr_entry *vmx_find_msr(uint32_t msr, enum vmx_msr_list_type 
> type);
> +struct vmx_msr_entry *vmx_find_msr(struct vcpu *v, uint32_t msr,
> +   enum vmx_msr_list_type type);
>  
> -static inline int vmx_read_guest_msr(uint32_t msr, uint64_t *val)
> +static inline int vmx_read_guest_msr(struct vcpu *v, uint32_t msr,
> + uint64_t *val)

It would seem logical for the new parameter to be constified for at least
these last two.

Jan



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

Re: [Xen-devel] [PATCH 6/9] x86/vmx: Pass an MSR value into vmx_msr_add()

[Jan Beulich]

>>> On 22.05.18 at 13:20,  wrote:
> The main purpose of this change is to allow us to set a specific MSR value,
> without needing to know whether there is already a load/save list slot for 
> it.
> Previously, callers wanting this property needed to call both vmx_add_*_msr()
> and vmx_write_*_msr() to cover both cases.
> 
> As a result of this API improvement, the default value for guest MSRs need not
> be 0, and the default for host MSRs need not be passed via hardware register.
> In practice, this cleans up the VPMU allocation logic, and avoids an MSR read
> as part of vcpu construction.

But this also means: If there already is such an entry, the previous value will
now be blindly overwritten. Are you sure this is always what is wanted?

Jan



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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Simon Gaiser]

Jan Beulich:
 On 24.05.18 at 16:14,  wrote:
>> Jan Beulich:
>> On 24.05.18 at 16:00,  wrote:
 Jan Beulich:
> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
> I've failed to remember the fact that multiple CPUs share a stub
> mapping page. Therefore it is wrong to unconditionally zap the mapping
> when bringing down a CPU; it may only be unmapped when no other online
> CPU uses that same page.
>
> Reported-by: Simon Gaiser 
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>  
>  free_xen_pagetable(rpt);
>  
> -/* Also zap the stub mapping for this CPU. */
> +/*
> + * Also zap the stub mapping for this CPU, if no other online one 
> uses
> + * the same page.
> + */
> +if ( stub_linear )
> +{
> +unsigned int other;
> +
> +for_each_online_cpu(other)
> +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> 
> PAGE_SHIFT) )
> +{
> +stub_linear = 0;
> +break;
> +}
> +}
>  if ( stub_linear )
>  {
>  l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);

 Tried this on-top of staging (fc5805daef) and I still get the same
 double fault.
>>>
>>> Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. What
>>> size a system are you testing on? Mine has got only 12 CPUs, i.e. all stubs
>>> are in the same page (and I'd never unmap anything here at all).
>>
>> 4 cores + HT, so 8 CPUs from Xen's PoV.
> 
> May I ask you to do two things:
> 1) confirm that you can offline CPUs successfully using xen-hptool,
> 2) add a printk() to the code above making clear whether/when any
> of the mappings actually get zapped?

There seem to be two failure modes now. It seems that both can be
triggered either by offlining a cpu or by suspend. Using cpu offlining
below since during suspend I often loose part of the serial output.

Failure mode 1, the double fault as before:

root@localhost:~# xen-hptool cpu-offline 3
Prepare to offline CPU 3
(XEN) Broke affinity for irq 9
(XEN) Broke affinity for irq 29
(XEN) dbg: stub_linear't1 = 18446606431818858880
(XEN) dbg: first stub_linear if
(XEN) dbg: stub_linear't2 = 18446606431818858880
(XEN) dbg: second stub_linear if
CPU 3 offlined successfully
root@localhost:~# (XEN) *** DOUBLE FAULT ***
(XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) RIP:e008:[] handle_exception+0x9c/0xff
(XEN) RFLAGS: 00010006   CONTEXT: hypervisor
(XEN) rax: c90040cdc0a8   rbx:    rcx: 0006
(XEN) rdx:    rsi:    rdi: 
(XEN) rbp: 36ffbf323f37   rsp: c90040cdc000   r8:  
(XEN) r9:     r10:    r11: 
(XEN) r12:    r13:    r14: c90040cd
(XEN) r15:    cr0: 8005003b   cr4: 00042660
(XEN) cr3: 000128109000   cr2: c90040cdbff8
(XEN) fsb: 7fc01c3c6dc0   gsb: 88021e70   gss: 
(XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
(XEN) Xen code around  (handle_exception+0x9c/0xff):
(XEN)  00 f3 90 0f ae e8 eb f9  07 00 00 00 f3 90 0f ae e8 eb f9 83 e9 01 75
(XEN) Current stack base c90040cd8000 differs from expected 8300cec88000
(XEN) Valid stack range: c90040cde000-c90040ce, 
sp=c90040cdc000, tss.rsp0=8300cec8ffa0
(XEN) No stack overflow detected. Skipping stack trace.
(XEN) 
(XEN) 
(XEN) Panic on CPU 0:
(XEN) DOUBLE FAULT -- system shutdown
(XEN) 
(XEN) 
(XEN) Reboot in five seconds...

Failure mode 2, dom0 kernel panic (Debian unstable default kernel):

root@localhost:~# xen-hptool cpu-offline 3
Prepare to offline CPU 3
(XEN) Broke affinity for irq 9
(XEN) Broke affinity for irq 26
(XEN) Broke affinity for irq 28
(XEN) dbg: stub_linear't1 = 18446606431818858880
(XEN) dbg: first stub_linear if
(XEN) dbg: stub_linear't2 = 18446606431818858880
(XEN) dbg: second stub_linear if
CPU 3 offlined successfully
root@localhost:~# [   42.976030] BUG: unable to handle kernel NULL pointer 
dereference at 
[   42.976178] IP: __evtchn_fifo_handle_events+0x43/0x1a0
[   42.976256] PGD 0 P4D 0 
[   42.976305] Oops: 0002 [#1] SMP NOPTI
[   42.976367] Modules linked in: ctr ccm bnep ip6t_REJECT nf_reject_ipv6 
ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp iptable_filter 
arc4 snd_hda_codec_hdmi dell_rbtn iwldvm nouveau intel_rapl intel_powerclamp 

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[George Dunlap]

> On May 24, 2018, at 3:53 PM, Andrew Cooper  wrote:
> 
> On 24/05/18 15:35, Simon Gaiser wrote:
>> Andrew Cooper:
>>> On 24/05/18 15:14, Simon Gaiser wrote:
 Jan Beulich:
 On 24.05.18 at 16:00,  wrote:
>> Jan Beulich:
>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>>> I've failed to remember the fact that multiple CPUs share a stub
>>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>>> when bringing down a CPU; it may only be unmapped when no other online
>>> CPU uses that same page.
>>> 
>>> Reported-by: Simon Gaiser 
>>> Signed-off-by: Jan Beulich 
>>> 
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>>> 
>>> free_xen_pagetable(rpt);
>>> 
>>> -/* Also zap the stub mapping for this CPU. */
>>> +/*
>>> + * Also zap the stub mapping for this CPU, if no other online one 
>>> uses
>>> + * the same page.
>>> + */
>>> +if ( stub_linear )
>>> +{
>>> +unsigned int other;
>>> +
>>> +for_each_online_cpu(other)
>>> +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> 
>>> PAGE_SHIFT) )
>>> +{
>>> +stub_linear = 0;
>>> +break;
>>> +}
>>> +}
>>> if ( stub_linear )
>>> {
>>> l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
>> Tried this on-top of staging (fc5805daef) and I still get the same
>> double fault.
> Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. 
> What
> size a system are you testing on? Mine has got only 12 CPUs, i.e. all 
> stubs
> are in the same page (and I'd never unmap anything here at all).
 4 cores + HT, so 8 CPUs from Xen's PoV.
>>> Can you try with the "x86/traps: Dump the instruction stream even for
>>> double faults" patch I've just posted, and show the full #DF panic log
>>> please?  (Its conceivable that there are multiple different issues here.)
>> With Jan's and your patch:
>> 
>> (XEN) mce_intel.c:782: MCA Capability: firstbank 0, extended MCE MSR 0, 
>> BCAST, CMCI
>> (XEN) CPU0 CMCI LVT vector (0xf2) already installed
>> (XEN) Finishing wakeup from ACPI S3 state.
>> (XEN) Enabling non-boot CPUs  ...
>> (XEN) emul-priv-op.c:1166:d0v1 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee0
>> (XEN) emul-priv-op.c:1166:d0v1 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee00800
>> (XEN) emul-priv-op.c:1166:d0v2 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee0
>> (XEN) emul-priv-op.c:1166:d0v2 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee00800
>> (XEN) emul-priv-op.c:1166:d0v3 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee0
>> (XEN) emul-priv-op.c:1166:d0v3 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee00800
>> (XEN) emul-priv-op.c:1166:d0v4 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee0
>> (XEN) emul-priv-op.c:1166:d0v4 Domain attempted WRMSR 001b from 
>> 0xfee00c00 to 0xfee00800
> 
> /sigh - Naughty Linux.  The PVOps really ought to know that they don't
> have an APIC to play with, not that this related to the crash.
> 
>> (XEN) *** DOUBLE FAULT ***
>> (XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
>> (XEN) CPU:0
>> (XEN) RIP:e008:[] handle_exception+0x9c/0xff
>> (XEN) RFLAGS: 00010006   CONTEXT: hypervisor
>> (XEN) rax: c90040ce40d8   rbx:    rcx: 0003
>> (XEN) rdx:    rsi:    rdi: 
>> (XEN) rbp: 36ffbf31bf07   rsp: c90040ce4000   r8:  
>> (XEN) r9:     r10:    r11: 
>> (XEN) r12:    r13:    r14: c90040ce7fff
>> (XEN) r15:    cr0: 8005003b   cr4: 00042660
>> (XEN) cr3: 00022200a000   cr2: c90040ce3ff8
>> (XEN) fsb: 7fa9e7909740   gsb: 88021e74   gss: 
>> (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
>> (XEN) Xen code around  (handle_exception+0x9c/0xff):
>> (XEN)  00 f3 90 0f ae e8 eb f9  07 00 00 00 f3 90 0f ae e8 eb f9 83 e9 
>> 01 75
>> (XEN) Current stack base c90040ce differs from expected 
>> 8300cec88000
>> (XEN) Valid stack range: c90040ce6000-c90040ce8000, 
>> sp=c90040ce4000, tss.rsp0=8300cec8ffa0
>> (XEN) No stack overflow detected. Skipping stack trace.
> 
> Ok - this is the same as George's crash, and yes - I did misdiagnose the

Re: [Xen-devel] [PATCH 2/9] x86/vmx: Internal cleanup for MSR load/save infrastructure

[Jan Beulich]

>>> On 22.05.18 at 13:20,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -1292,48 +1292,50 @@ static int vmx_msr_entry_key_cmp(const void *key, 
> const void *elt)
>  struct vmx_msr_entry *vmx_find_msr(uint32_t msr, enum vmx_msr_list_type type)
>  {
>  struct vcpu *curr = current;
> -unsigned int msr_count;
> -struct vmx_msr_entry *msr_area = NULL;
> +struct arch_vmx_struct *arch_vmx = >arch.hvm_vmx;

In the interest of code volume reduction - why the arch_ prefix? There's
no arch_-less vmx anywhere afaict.

> +struct vmx_msr_entry *start = NULL;
> +unsigned int total;
>  
>  switch ( type )
>  {
>  case VMX_MSR_HOST:
> -msr_count = curr->arch.hvm_vmx.host_msr_count;
> -msr_area = curr->arch.hvm_vmx.host_msr_area;
> +start= arch_vmx->host_msr_area;
> +total= arch_vmx->host_msr_count;
>  break;
>  
>  case VMX_MSR_GUEST:
> -msr_count = curr->arch.hvm_vmx.msr_count;
> -msr_area = curr->arch.hvm_vmx.msr_area;
> +start= arch_vmx->msr_area;
> +total= arch_vmx->msr_count;
>  break;
>  
>  default:
>  ASSERT_UNREACHABLE();
>  }
>  
> -if ( msr_area == NULL )
> +if ( !start )
>  return NULL;
>  
> -return bsearch(, msr_area, msr_count, sizeof(struct vmx_msr_entry),
> +return bsearch(, start, total, sizeof(struct vmx_msr_entry),

sizeof(*start) ?

Jan



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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Andrew Cooper]

On 24/05/18 15:35, Simon Gaiser wrote:
> Andrew Cooper:
>> On 24/05/18 15:14, Simon Gaiser wrote:
>>> Jan Beulich:
>>> On 24.05.18 at 16:00,  wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs share a stub
>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>> when bringing down a CPU; it may only be unmapped when no other online
>> CPU uses that same page.
>>
>> Reported-by: Simon Gaiser 
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>>  
>>  free_xen_pagetable(rpt);
>>  
>> -/* Also zap the stub mapping for this CPU. */
>> +/*
>> + * Also zap the stub mapping for this CPU, if no other online one 
>> uses
>> + * the same page.
>> + */
>> +if ( stub_linear )
>> +{
>> +unsigned int other;
>> +
>> +for_each_online_cpu(other)
>> +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> 
>> PAGE_SHIFT) )
>> +{
>> +stub_linear = 0;
>> +break;
>> +}
>> +}
>>  if ( stub_linear )
>>  {
>>  l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
> Tried this on-top of staging (fc5805daef) and I still get the same
> double fault.
 Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. 
 What
 size a system are you testing on? Mine has got only 12 CPUs, i.e. all stubs
 are in the same page (and I'd never unmap anything here at all).
>>> 4 cores + HT, so 8 CPUs from Xen's PoV.
>> Can you try with the "x86/traps: Dump the instruction stream even for
>> double faults" patch I've just posted, and show the full #DF panic log
>> please?  (Its conceivable that there are multiple different issues here.)
> With Jan's and your patch:
>
> (XEN) mce_intel.c:782: MCA Capability: firstbank 0, extended MCE MSR 0, 
> BCAST, CMCI
> (XEN) CPU0 CMCI LVT vector (0xf2) already installed
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs  ...
> (XEN) emul-priv-op.c:1166:d0v1 Domain attempted WRMSR 001b from 
> 0xfee00c00 to 0xfee0
> (XEN) emul-priv-op.c:1166:d0v1 Domain attempted WRMSR 001b from 
> 0xfee00c00 to 0xfee00800
> (XEN) emul-priv-op.c:1166:d0v2 Domain attempted WRMSR 001b from 
> 0xfee00c00 to 0xfee0
> (XEN) emul-priv-op.c:1166:d0v2 Domain attempted WRMSR 001b from 
> 0xfee00c00 to 0xfee00800
> (XEN) emul-priv-op.c:1166:d0v3 Domain attempted WRMSR 001b from 
> 0xfee00c00 to 0xfee0
> (XEN) emul-priv-op.c:1166:d0v3 Domain attempted WRMSR 001b from 
> 0xfee00c00 to 0xfee00800
> (XEN) emul-priv-op.c:1166:d0v4 Domain attempted WRMSR 001b from 
> 0xfee00c00 to 0xfee0
> (XEN) emul-priv-op.c:1166:d0v4 Domain attempted WRMSR 001b from 
> 0xfee00c00 to 0xfee00800

/sigh - Naughty Linux.  The PVOps really ought to know that they don't
have an APIC to play with, not that this related to the crash.

> (XEN) *** DOUBLE FAULT ***
> (XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] handle_exception+0x9c/0xff
> (XEN) RFLAGS: 00010006   CONTEXT: hypervisor
> (XEN) rax: c90040ce40d8   rbx:    rcx: 0003
> (XEN) rdx:    rsi:    rdi: 
> (XEN) rbp: 36ffbf31bf07   rsp: c90040ce4000   r8:  
> (XEN) r9:     r10:    r11: 
> (XEN) r12:    r13:    r14: c90040ce7fff
> (XEN) r15:    cr0: 8005003b   cr4: 00042660
> (XEN) cr3: 00022200a000   cr2: c90040ce3ff8
> (XEN) fsb: 7fa9e7909740   gsb: 88021e74   gss: 
> (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
> (XEN) Xen code around  (handle_exception+0x9c/0xff):
> (XEN)  00 f3 90 0f ae e8 eb f9  07 00 00 00 f3 90 0f ae e8 eb f9 83 e9 01 
> 75
> (XEN) Current stack base c90040ce differs from expected 
> 8300cec88000
> (XEN) Valid stack range: c90040ce6000-c90040ce8000, 
> sp=c90040ce4000, tss.rsp0=8300cec8ffa0
> (XEN) No stack overflow detected. Skipping stack trace.

Ok - this is the same as George's crash, and yes - I did misdiagnose the
stack we were on.  I presume this hardware doesn't have SMAP? (or we've
expected to take a #DF immediately at the head of the syscall hander.)

~Andrew

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Simon Gaiser]

Andrew Cooper:
> On 24/05/18 15:14, Simon Gaiser wrote:
>> Jan Beulich:
>> On 24.05.18 at 16:00,  wrote:
 Jan Beulich:
> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
> I've failed to remember the fact that multiple CPUs share a stub
> mapping page. Therefore it is wrong to unconditionally zap the mapping
> when bringing down a CPU; it may only be unmapped when no other online
> CPU uses that same page.
>
> Reported-by: Simon Gaiser 
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>  
>  free_xen_pagetable(rpt);
>  
> -/* Also zap the stub mapping for this CPU. */
> +/*
> + * Also zap the stub mapping for this CPU, if no other online one 
> uses
> + * the same page.
> + */
> +if ( stub_linear )
> +{
> +unsigned int other;
> +
> +for_each_online_cpu(other)
> +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> 
> PAGE_SHIFT) )
> +{
> +stub_linear = 0;
> +break;
> +}
> +}
>  if ( stub_linear )
>  {
>  l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
 Tried this on-top of staging (fc5805daef) and I still get the same
 double fault.
>>> Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. What
>>> size a system are you testing on? Mine has got only 12 CPUs, i.e. all stubs
>>> are in the same page (and I'd never unmap anything here at all).
>> 4 cores + HT, so 8 CPUs from Xen's PoV.
> 
> Can you try with the "x86/traps: Dump the instruction stream even for
> double faults" patch I've just posted, and show the full #DF panic log
> please?  (Its conceivable that there are multiple different issues here.)

With Jan's and your patch:

(XEN) mce_intel.c:782: MCA Capability: firstbank 0, extended MCE MSR 0, BCAST, 
CMCI
(XEN) CPU0 CMCI LVT vector (0xf2) already installed
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) emul-priv-op.c:1166:d0v1 Domain attempted WRMSR 001b from 
0xfee00c00 to 0xfee0
(XEN) emul-priv-op.c:1166:d0v1 Domain attempted WRMSR 001b from 
0xfee00c00 to 0xfee00800
(XEN) emul-priv-op.c:1166:d0v2 Domain attempted WRMSR 001b from 
0xfee00c00 to 0xfee0
(XEN) emul-priv-op.c:1166:d0v2 Domain attempted WRMSR 001b from 
0xfee00c00 to 0xfee00800
(XEN) emul-priv-op.c:1166:d0v3 Domain attempted WRMSR 001b from 
0xfee00c00 to 0xfee0
(XEN) emul-priv-op.c:1166:d0v3 Domain attempted WRMSR 001b from 
0xfee00c00 to 0xfee00800
(XEN) emul-priv-op.c:1166:d0v4 Domain attempted WRMSR 001b from 
0xfee00c00 to 0xfee0
(XEN) emul-priv-op.c:1166:d0v4 Domain attempted WRMSR 001b from 
0xfee00c00 to 0xfee00800
(XEN) *** DOUBLE FAULT ***
(XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) RIP:e008:[] handle_exception+0x9c/0xff
(XEN) RFLAGS: 00010006   CONTEXT: hypervisor
(XEN) rax: c90040ce40d8   rbx:    rcx: 0003
(XEN) rdx:    rsi:    rdi: 
(XEN) rbp: 36ffbf31bf07   rsp: c90040ce4000   r8:  
(XEN) r9:     r10:    r11: 
(XEN) r12:    r13:    r14: c90040ce7fff
(XEN) r15:    cr0: 8005003b   cr4: 00042660
(XEN) cr3: 00022200a000   cr2: c90040ce3ff8
(XEN) fsb: 7fa9e7909740   gsb: 88021e74   gss: 
(XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
(XEN) Xen code around  (handle_exception+0x9c/0xff):
(XEN)  00 f3 90 0f ae e8 eb f9  07 00 00 00 f3 90 0f ae e8 eb f9 83 e9 01 75
(XEN) Current stack base c90040ce differs from expected 8300cec88000
(XEN) Valid stack range: c90040ce6000-c90040ce8000, 
sp=c90040ce4000, tss.rsp0=8300cec8ffa0
(XEN) No stack overflow detected. Skipping stack trace.
(XEN) 
(XEN) 
(XEN) Panic on CPU 0:
(XEN) DOUBLE FAULT -- system shutdown
(XEN) 
(XEN) 
(XEN) Reboot in five seconds...



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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Jan Beulich]

>>> On 24.05.18 at 16:24,  wrote:
> On 24/05/18 15:22, Jan Beulich wrote:
> On 24.05.18 at 16:18,  wrote:
>>> Can you try with the "x86/traps: Dump the instruction stream even for
>>> double faults" patch I've just posted, and show the full #DF panic log
>>> please?  (Its conceivable that there are multiple different issues here.)
>> Well, as long as we're on a guest kernel stack rather than our own, I
>> don't think the exact insn causing the #DF really matters. See earlier
>> mails I have sent in this regard.
> 
> In George's crash, we were in a weird place on the hypervisor stack, not
> a guest stack...

Go look again - %rsp pointed outside of hypervisor space in all cases that
I had looked at. And that's explained by the unmapping of the stubs: We'd
#PF right after first SYSCALL, and the handler would then run on the stack
that's still active from guest context.

Jan



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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Jan Beulich]

>>> On 24.05.18 at 16:14,  wrote:
> Jan Beulich:
> On 24.05.18 at 16:00,  wrote:
>>> Jan Beulich:
 In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
 I've failed to remember the fact that multiple CPUs share a stub
 mapping page. Therefore it is wrong to unconditionally zap the mapping
 when bringing down a CPU; it may only be unmapped when no other online
 CPU uses that same page.

 Reported-by: Simon Gaiser 
 Signed-off-by: Jan Beulich 

 --- a/xen/arch/x86/smpboot.c
 +++ b/xen/arch/x86/smpboot.c
 @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
  
  free_xen_pagetable(rpt);
  
 -/* Also zap the stub mapping for this CPU. */
 +/*
 + * Also zap the stub mapping for this CPU, if no other online one uses
 + * the same page.
 + */
 +if ( stub_linear )
 +{
 +unsigned int other;
 +
 +for_each_online_cpu(other)
 +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> 
 PAGE_SHIFT) )
 +{
 +stub_linear = 0;
 +break;
 +}
 +}
  if ( stub_linear )
  {
  l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
>>>
>>> Tried this on-top of staging (fc5805daef) and I still get the same
>>> double fault.
>> 
>> Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. What
>> size a system are you testing on? Mine has got only 12 CPUs, i.e. all stubs
>> are in the same page (and I'd never unmap anything here at all).
> 
> 4 cores + HT, so 8 CPUs from Xen's PoV.

May I ask you to do two things:
1) confirm that you can offline CPUs successfully using xen-hptool,
2) add a printk() to the code above making clear whether/when any
of the mappings actually get zapped?

Thanks, Jan



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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Andrew Cooper]

On 24/05/18 15:22, Jan Beulich wrote:
 On 24.05.18 at 16:18,  wrote:
>> Can you try with the "x86/traps: Dump the instruction stream even for
>> double faults" patch I've just posted, and show the full #DF panic log
>> please?  (Its conceivable that there are multiple different issues here.)
> Well, as long as we're on a guest kernel stack rather than our own, I
> don't think the exact insn causing the #DF really matters. See earlier
> mails I have sent in this regard.

In George's crash, we were in a weird place on the hypervisor stack, not
a guest stack...

~Andrew

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

Re: [Xen-devel] [PATCH] arm: Coverity 1469342 correct find_*_bit() functions use

[Julien Grall]

On 24/05/18 15:07, Artem Mygaiev wrote:

Hi Julien


Hi Artem,



On 24.05.18 16:49, Julien Grall wrote:

Hi Artem,

Thank you for the report.

On 24/05/18 14:20, Artem Mygaiev wrote:
vgic_vcpu_pending_irq() uses find_next_bit() library function with 
single 'unsigned long' variable, while it is designed to work with 
memory regions. Nothing wrong is happening since 'offset' is set to 0 
(other values could lead to memory corruption), but it would be more 
correct to use the find_first_bit() function instead.


I don't understand the commit message. It is fine to use other offset 
than 0 in find_next_bit as long as it is smaller than 32. There would 
be no corruption happening.


Furthermore, find_first_bit(, 32, 0) and find_next_bit(, 32) 
are equivalent because the former is just a macro using the latter 
(see include/asm-arm/arm64/bitops.h).


So as it is the patch is not solving anything. However, I think this 
is just a false positive. Coverity should be able to guess that it 
will not go past the array (BITOP_WORD will turned into 0).


Absolutely agree with you. Probably my message was not clear enough - 
with this particular patch I am not trying to fix a memory corruption, 
there is no memory corruption in the code now. It is just the use of 
functions: find_first_bit() is a better fit since the 
vgic_vcpu_pending_irq() function does not need to go over memory region 
and checks only one 32-bit variable. I have mentioned Coverity issue 
here because this was a false positive detected after today's test run.


Feel free to resend this patch as a clean-up. I always found the use of 
find_next_bit confusing over find_first_bit.


However, I don't think coverity should be mention in the commit message 
or title. This is making thing very confusing as, IHMO, this is a false 
positive. We tend to only mention coverity when this is either going to 
silent coverity or fix the defect.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

[Jan Beulich]

>>> On 24.05.18 at 16:14,  wrote:
> How many bug-fixes vs. XSAs are typically in a stable branch? I was under 
> the impression that historically, the vast majority used to be XSAs with very 
> few backports.
> However, this year this has really changed because Spectre and Meltdown 
> related fixes were developed in public and they look like feature backports
> Which is why we see more of these issues

The ratio may vary, but I think it has always been more non-security than
security fixes, at least for as long as I've been stable branch maintainer.
It otherwise also wouldn't make much sense to distinguish between fully
maintained branches and ones in security-only maintenance mode.

Jan



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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Andrew Cooper]

On 24/05/18 15:14, Simon Gaiser wrote:
> Jan Beulich:
> On 24.05.18 at 16:00,  wrote:
>>> Jan Beulich:
 In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
 I've failed to remember the fact that multiple CPUs share a stub
 mapping page. Therefore it is wrong to unconditionally zap the mapping
 when bringing down a CPU; it may only be unmapped when no other online
 CPU uses that same page.

 Reported-by: Simon Gaiser 
 Signed-off-by: Jan Beulich 

 --- a/xen/arch/x86/smpboot.c
 +++ b/xen/arch/x86/smpboot.c
 @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
  
  free_xen_pagetable(rpt);
  
 -/* Also zap the stub mapping for this CPU. */
 +/*
 + * Also zap the stub mapping for this CPU, if no other online one uses
 + * the same page.
 + */
 +if ( stub_linear )
 +{
 +unsigned int other;
 +
 +for_each_online_cpu(other)
 +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> 
 PAGE_SHIFT) )
 +{
 +stub_linear = 0;
 +break;
 +}
 +}
  if ( stub_linear )
  {
  l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
>>> Tried this on-top of staging (fc5805daef) and I still get the same
>>> double fault.
>> Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. What
>> size a system are you testing on? Mine has got only 12 CPUs, i.e. all stubs
>> are in the same page (and I'd never unmap anything here at all).
> 4 cores + HT, so 8 CPUs from Xen's PoV.

Can you try with the "x86/traps: Dump the instruction stream even for
double faults" patch I've just posted, and show the full #DF panic log
please?  (Its conceivable that there are multiple different issues here.)

~Andrew

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

Re: [Xen-devel] [PATCH for-4.11] x86/traps: Dump the instruction stream even for double faults

[Jan Beulich]

>>> On 24.05.18 at 16:07,  wrote:
> This helps debug #DF's which occur in alternative patches
> 
> Reported-by: George Dunlap 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

[Lars Kurth]

On 24/05/2018, 10:00, "Jan Beulich"  wrote:

>>> On 24.05.18 at 15:50,  wrote:

> 
> On 24/05/2018, 01:48, "Steven Haigh"  wrote:
> 
> On 2018-05-22 20:52, Steven Haigh wrote:
> > On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote:
> >> >>> On 18.05.18 at 19:53,  wrote:
> >> > Alternative workaround for this would be more frequent point 
releases 
> by
> >> > default (maybe with ability to delay it very few commits are 
queued).
> >> > For example every 3 months. It wouldn't solve all the cases, but 
I 
> think
> >> > will make it easier most of the time.
> >> 
> >> Is every 3 months so much better than every 4 months? Granted we
> >> basically never manage to make it exactly 4 months, but on the 
average
> >> I think we're not too far off.
> > 
> > I think the big thing is reducing the delta between the staging 
branch 
> > and the
> > release. I can only assume that would reduce the number of issues 
that 
> > occur
> > with patching vs release tarballs - hopefully making the security 
teams 
> 
> > job a
> > little easier.
> > 
> > That being said, if an approach of releasing a new build when we 
come 
> > across
> > broken patch sets for XSAs (like the current 4.9.1 vs XSAs, and 
prior 
> > 4.10.0
> > vs XSAs), then I think this part becomes irrelevant.
> 
> As another example for this, the patches for XSA263 do not apply to 
> *any* released tarball version of Xen.
> 
> So far, the patches included with the announcement fail on 4.6, 4.7, 
4.9 
> 
> and 4.10.
> 
> I can only assume that this means all the XSA patches require commits 
> that are currently in various staging git trees that have not been 
> released in any formal manner via a point release.
> 
> Thinking about this, we are essentially exposing ourselves to this, 
because 
> of backports of issues which happen at any random point in time during a 
> point release cycle, e.g. 4.8.2. => 4.8.3
> 
> In other words, we may get a sequence of backport, XSA, XSA, backport, ...
> 
> I am wondering whether time-sequencing may be the answer here. In other 
> words, let's assume we have a 4-month window: for the first 3 months, we 
> don't allow bug-fix backports into in this case stable-4.8, we only allow 
> XSAs. Then we have a 2-week merge window where we handle all backports 
and 
> prepare the release and cut the release. This means that for most of the 
> time, XSAs would apply cleanly onto staging and the released tarball.

I'm sincerely against such a model: The larger a batch of commits, the more
likely that some then-no-longer-easy-to-spot regression may creep in, and
the less time there is for osstest and people to test. I do appreciate some
batching, but just like with XSAs I think the batch size should remain 
sensible
also for commits to stable trees.

How many bug-fixes vs. XSAs are typically in a stable branch? I was under the 
impression that historically, the vast majority used to be XSAs with very few 
backports.
However, this year this has really changed because Spectre and Meltdown related 
fixes were developed in public and they look like feature backports
Which is why we see more of these issues

Lars


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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Simon Gaiser]

Jan Beulich:
 On 24.05.18 at 16:00,  wrote:
>> Jan Beulich:
>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>>> I've failed to remember the fact that multiple CPUs share a stub
>>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>>> when bringing down a CPU; it may only be unmapped when no other online
>>> CPU uses that same page.
>>>
>>> Reported-by: Simon Gaiser 
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>>>  
>>>  free_xen_pagetable(rpt);
>>>  
>>> -/* Also zap the stub mapping for this CPU. */
>>> +/*
>>> + * Also zap the stub mapping for this CPU, if no other online one uses
>>> + * the same page.
>>> + */
>>> +if ( stub_linear )
>>> +{
>>> +unsigned int other;
>>> +
>>> +for_each_online_cpu(other)
>>> +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> 
>>> PAGE_SHIFT) )
>>> +{
>>> +stub_linear = 0;
>>> +break;
>>> +}
>>> +}
>>>  if ( stub_linear )
>>>  {
>>>  l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
>>
>> Tried this on-top of staging (fc5805daef) and I still get the same
>> double fault.
> 
> Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. What
> size a system are you testing on? Mine has got only 12 CPUs, i.e. all stubs
> are in the same page (and I'd never unmap anything here at all).

4 cores + HT, so 8 CPUs from Xen's PoV.



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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Jan Beulich]

>>> On 24.05.18 at 16:00,  wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs share a stub
>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>> when bringing down a CPU; it may only be unmapped when no other online
>> CPU uses that same page.
>> 
>> Reported-by: Simon Gaiser 
>> Signed-off-by: Jan Beulich 
>> 
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>>  
>>  free_xen_pagetable(rpt);
>>  
>> -/* Also zap the stub mapping for this CPU. */
>> +/*
>> + * Also zap the stub mapping for this CPU, if no other online one uses
>> + * the same page.
>> + */
>> +if ( stub_linear )
>> +{
>> +unsigned int other;
>> +
>> +for_each_online_cpu(other)
>> +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> 
>> PAGE_SHIFT) )
>> +{
>> +stub_linear = 0;
>> +break;
>> +}
>> +}
>>  if ( stub_linear )
>>  {
>>  l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
> 
> Tried this on-top of staging (fc5805daef) and I still get the same
> double fault.

Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. What
size a system are you testing on? Mine has got only 12 CPUs, i.e. all stubs
are in the same page (and I'd never unmap anything here at all).

Jan



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

Re: [Xen-devel] [PATCH] arm: Coverity 1469342 correct find_*_bit() functions use

[Artem Mygaiev]

Hi Julien

On 24.05.18 16:49, Julien Grall wrote:

Hi Artem,

Thank you for the report.

On 24/05/18 14:20, Artem Mygaiev wrote:
vgic_vcpu_pending_irq() uses find_next_bit() library function with 
single 'unsigned long' variable, while it is designed to work with 
memory regions. Nothing wrong is happening since 'offset' is set to 0 
(other values could lead to memory corruption), but it would be more 
correct to use the find_first_bit() function instead.


I don't understand the commit message. It is fine to use other offset 
than 0 in find_next_bit as long as it is smaller than 32. There would be 
no corruption happening.


Furthermore, find_first_bit(, 32, 0) and find_next_bit(, 32) are 
equivalent because the former is just a macro using the latter (see 
include/asm-arm/arm64/bitops.h).


So as it is the patch is not solving anything. However, I think this is 
just a false positive. Coverity should be able to guess that it will not 
go past the array (BITOP_WORD will turned into 0).


Absolutely agree with you. Probably my message was not clear enough - 
with this particular patch I am not trying to fix a memory corruption, 
there is no memory corruption in the code now. It is just the use of 
functions: find_first_bit() is a better fit since the 
vgic_vcpu_pending_irq() function does not need to go over memory region 
and checks only one 32-bit variable. I have mentioned Coverity issue 
here because this was a false positive detected after today's test run.




Coverity Scan issue 1469342


For future reference, please use the tag: "Coverity-ID: 1469342".


Thanks, will do.



Signed-off-by: Artem Mygaiev 

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index d831b35525..fd63906e9b 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -362,7 +362,7 @@ int vgic_vcpu_pending_irq(struct vcpu *v)
  ASSERT(v == current);

  mask_priority = gic_hw_ops->read_vmcr_priority();
-    active_priority = find_next_bit(, 32, 0);
+    active_priority = find_first_bit(, 32);

  spin_lock_irqsave(>arch.vgic.lock, flags);



Cheers,



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

[Xen-devel] [PATCH for-4.11] x86/traps: Dump the instruction stream even for double faults

[Andrew Cooper]

This helps debug #DF's which occur in alternative patches

Reported-by: George Dunlap 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Juergen Gross 
---
 xen/arch/x86/traps.c| 2 +-
 xen/arch/x86/x86_64/traps.c | 1 +
 xen/include/asm-x86/processor.h | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 824647d..8a99174 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -148,7 +148,7 @@ void (* const exception_table[TRAP_nr])(struct 
cpu_user_regs *regs) = {
  (ARRAY_SIZE(exception_table) - 1)] = do_reserved_trap,
 };
 
-static void show_code(const struct cpu_user_regs *regs)
+void show_code(const struct cpu_user_regs *regs)
 {
 unsigned char insns_before[8] = {}, insns_after[16] = {};
 unsigned int i, tmp, missing_before, missing_after;
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index 4f85c32..f7f6928 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -255,6 +255,7 @@ void do_double_fault(struct cpu_user_regs *regs)
 
 printk("CPU:%d\n", cpu);
 _show_registers(regs, crs, CTXT_hypervisor, NULL);
+show_code(regs);
 show_stack_overflow(cpu, regs);
 
 panic("DOUBLE FAULT -- system shutdown");
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index 0c69a52..9924cdf 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -468,6 +468,7 @@ static always_inline void rep_nop(void)
 
 #define cpu_relax() rep_nop()
 
+void show_code(const struct cpu_user_regs *regs);
 void show_stack(const struct cpu_user_regs *regs);
 void show_stack_overflow(unsigned int cpu, const struct cpu_user_regs *regs);
 void show_registers(const struct cpu_user_regs *regs);
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Jan Beulich]

>>> On 24.05.18 at 15:48,  wrote:
> On 24/05/18 14:41, Jan Beulich wrote:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs share a stub
>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>> when bringing down a CPU; it may only be unmapped when no other online
>> CPU uses that same page.
>>
>> Reported-by: Simon Gaiser 
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>>  
>>  free_xen_pagetable(rpt);
>>  
>> -/* Also zap the stub mapping for this CPU. */
>> +/*
>> + * Also zap the stub mapping for this CPU, if no other online one uses
>> + * the same page.
>> + */
>> +if ( stub_linear )
>> +{
>> +unsigned int other;
>> +
>> +for_each_online_cpu(other)
> 
> Look over the code, it seems that with spaces is the more common style,
> but it is admittedly fairly mixed.

I'd prefer to leave it as is - personally I don't consider "for_each_online_cpu"
and alike keywords, which is what ./CODING_STYLE talks about. I accept
others taking a different position, i.e. I don't normally demand a particular
style to be used there, but in code I write I prefer to only apply spaces to
real keywords.

> Either way (as that's trivial to fix), Acked-by: Andrew Cooper
> 

Thanks, Jan



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

Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

[Jan Beulich]

>>> On 24.05.18 at 15:50,  wrote:

> 
> On 24/05/2018, 01:48, "Steven Haigh"  wrote:
> 
> On 2018-05-22 20:52, Steven Haigh wrote:
> > On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote:
> >> >>> On 18.05.18 at 19:53,  wrote:
> >> > Alternative workaround for this would be more frequent point 
> releases 
> by
> >> > default (maybe with ability to delay it very few commits are queued).
> >> > For example every 3 months. It wouldn't solve all the cases, but I 
> think
> >> > will make it easier most of the time.
> >> 
> >> Is every 3 months so much better than every 4 months? Granted we
> >> basically never manage to make it exactly 4 months, but on the average
> >> I think we're not too far off.
> > 
> > I think the big thing is reducing the delta between the staging branch 
> > and the
> > release. I can only assume that would reduce the number of issues that 
> > occur
> > with patching vs release tarballs - hopefully making the security teams 
> 
> > job a
> > little easier.
> > 
> > That being said, if an approach of releasing a new build when we come 
> > across
> > broken patch sets for XSAs (like the current 4.9.1 vs XSAs, and prior 
> > 4.10.0
> > vs XSAs), then I think this part becomes irrelevant.
> 
> As another example for this, the patches for XSA263 do not apply to 
> *any* released tarball version of Xen.
> 
> So far, the patches included with the announcement fail on 4.6, 4.7, 4.9 
> 
> and 4.10.
> 
> I can only assume that this means all the XSA patches require commits 
> that are currently in various staging git trees that have not been 
> released in any formal manner via a point release.
> 
> Thinking about this, we are essentially exposing ourselves to this, because 
> of backports of issues which happen at any random point in time during a 
> point release cycle, e.g. 4.8.2. => 4.8.3
> 
> In other words, we may get a sequence of backport, XSA, XSA, backport, ...
> 
> I am wondering whether time-sequencing may be the answer here. In other 
> words, let's assume we have a 4-month window: for the first 3 months, we 
> don't allow bug-fix backports into in this case stable-4.8, we only allow 
> XSAs. Then we have a 2-week merge window where we handle all backports and 
> prepare the release and cut the release. This means that for most of the 
> time, XSAs would apply cleanly onto staging and the released tarball.

I'm sincerely against such a model: The larger a batch of commits, the more
likely that some then-no-longer-easy-to-spot regression may creep in, and
the less time there is for osstest and people to test. I do appreciate some
batching, but just like with XSAs I think the batch size should remain sensible
also for commits to stable trees.

I can see that in particular for XSA-263 it would have been useful if we had
enumerated the prereqs (it was in fact intentional that we had decided to
commit some of them ahead of time, so that the advisory itself would be
more manageable in size and otherwise). But face it - compiling such a list
does add non-negligible extra work on the security team's part.

Jan


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

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

[Jan Beulich]

>>> On 24.05.18 at 14:39,  wrote:
> On 24/05/18 13:14, Roger Pau Monné wrote:
>> On Tue, May 22, 2018 at 12:20:42PM +0100, Andrew Cooper wrote:
>>> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
>>> updates a host MSR load list entry with the current hardware value of
>>> MSR_DEBUGCTL.  This is wrong.
>>>
>>> On VMExit, hardware automatically resets MSR_DEBUGCTL to 0.  The only case
>>> where different behaviour is needed is if Xen is debugging itself, and this
>>> needs setting up unconditionally for the lifetime of the VM.
>>>
>>> The `ler` command line boolean is the only way to configure any use of
>>> MSR_DEBUGCTL for Xen,
>> Hm, there's no documentation at all for the 'ler' option.
> 
> :(  ISTR Jan introducing it for debugging purposes, but I've never used
> it myself.

Indeed I've been using this a couple of times to have an idea how execution
lead to the point where an exception was raised. The option pre-dates the
existence of xen-command-line.markdown by several releases.

Jan


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

Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

[Lars Kurth]

On 24/05/2018, 01:48, "Steven Haigh"  wrote:

On 2018-05-22 20:52, Steven Haigh wrote:
> On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote:
>> >>> On 18.05.18 at 19:53,  wrote:
>> > Alternative workaround for this would be more frequent point releases 
by
>> > default (maybe with ability to delay it very few commits are queued).
>> > For example every 3 months. It wouldn't solve all the cases, but I 
think
>> > will make it easier most of the time.
>> 
>> Is every 3 months so much better than every 4 months? Granted we
>> basically never manage to make it exactly 4 months, but on the average
>> I think we're not too far off.
> 
> I think the big thing is reducing the delta between the staging branch 
> and the
> release. I can only assume that would reduce the number of issues that 
> occur
> with patching vs release tarballs - hopefully making the security teams 
> job a
> little easier.
> 
> That being said, if an approach of releasing a new build when we come 
> across
> broken patch sets for XSAs (like the current 4.9.1 vs XSAs, and prior 
> 4.10.0
> vs XSAs), then I think this part becomes irrelevant.

As another example for this, the patches for XSA263 do not apply to 
*any* released tarball version of Xen.

So far, the patches included with the announcement fail on 4.6, 4.7, 4.9 
and 4.10.

I can only assume that this means all the XSA patches require commits 
that are currently in various staging git trees that have not been 
released in any formal manner via a point release.

Thinking about this, we are essentially exposing ourselves to this, because of 
backports of issues which happen at any random point in time during a point 
release cycle, e.g. 4.8.2. => 4.8.3

In other words, we may get a sequence of backport, XSA, XSA, backport, ...

I am wondering whether time-sequencing may be the answer here. In other words, 
let's assume we have a 4-month window: for the first 3 months, we don't allow 
bug-fix backports into in this case stable-4.8, we only allow XSAs. Then we 
have a 2-week merge window where we handle all backports and prepare the 
release and cut the release. This means that for most of the time, XSAs would 
apply cleanly onto staging and the released tarball. If XSAs happen while we 
prepare the next week merge window for backports for a release (in this example 
4.8). There may be some pain, if XSAs turn up during the merge window but we 
would release the next point release shortly afterwards, which means that users 
have the choice of
a) go through the pain of cherry-picking (or applying all of the patches that 
come through in the 2 week merge window) - that should be easier as than now, 
because they would be more easily identifiable
b) can just wait for the release and then apply XSAs again
 
That shouldn't really create any extra work for point release maintainers, 
while reducing issues with patches not applying onto released tarballs

I may have missed something here, and have not fully thought this through, but 
it may be worthwhile discussing further along those lines

Cheers
Lars 


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

Re: [Xen-devel] [PATCH] arm: Coverity 1469342 correct find_*_bit() functions use

[Julien Grall]

Hi Artem,

Thank you for the report.

On 24/05/18 14:20, Artem Mygaiev wrote:
vgic_vcpu_pending_irq() uses find_next_bit() library function with 
single 'unsigned long' variable, while it is designed to work with 
memory regions. Nothing wrong is happening since 'offset' is set to 0 
(other values could lead to memory corruption), but it would be more 
correct to use the find_first_bit() function instead.


I don't understand the commit message. It is fine to use other offset 
than 0 in find_next_bit as long as it is smaller than 32. There would be 
no corruption happening.


Furthermore, find_first_bit(, 32, 0) and find_next_bit(, 32) are 
equivalent because the former is just a macro using the latter (see 
include/asm-arm/arm64/bitops.h).


So as it is the patch is not solving anything. However, I think this is 
just a false positive. Coverity should be able to guess that it will not 
go past the array (BITOP_WORD will turned into 0).




Coverity Scan issue 1469342


For future reference, please use the tag: "Coverity-ID: 1469342".



Signed-off-by: Artem Mygaiev 

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index d831b35525..fd63906e9b 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -362,7 +362,7 @@ int vgic_vcpu_pending_irq(struct vcpu *v)
  ASSERT(v == current);

  mask_priority = gic_hw_ops->read_vmcr_priority();
-    active_priority = find_next_bit(, 32, 0);
+    active_priority = find_first_bit(, 32);

  spin_lock_irqsave(>arch.vgic.lock, flags);



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Andrew Cooper]

On 24/05/18 14:41, Jan Beulich wrote:
> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
> I've failed to remember the fact that multiple CPUs share a stub
> mapping page. Therefore it is wrong to unconditionally zap the mapping
> when bringing down a CPU; it may only be unmapped when no other online
> CPU uses that same page.
>
> Reported-by: Simon Gaiser 
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>  
>  free_xen_pagetable(rpt);
>  
> -/* Also zap the stub mapping for this CPU. */
> +/*
> + * Also zap the stub mapping for this CPU, if no other online one uses
> + * the same page.
> + */
> +if ( stub_linear )
> +{
> +unsigned int other;
> +
> +for_each_online_cpu(other)

Look over the code, it seems that with spaces is the more common style,
but it is admittedly fairly mixed.

Either way (as that's trivial to fix), Acked-by: Andrew Cooper


> +if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> PAGE_SHIFT) 
> )
> +{
> +stub_linear = 0;
> +break;
> +}
> +}
>  if ( stub_linear )
>  {
>  l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
>
>
>
>


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

[Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

[Jan Beulich]

In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
I've failed to remember the fact that multiple CPUs share a stub
mapping page. Therefore it is wrong to unconditionally zap the mapping
when bringing down a CPU; it may only be unmapped when no other online
CPU uses that same page.

Reported-by: Simon Gaiser 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
 
 free_xen_pagetable(rpt);
 
-/* Also zap the stub mapping for this CPU. */
+/*
+ * Also zap the stub mapping for this CPU, if no other online one uses
+ * the same page.
+ */
+if ( stub_linear )
+{
+unsigned int other;
+
+for_each_online_cpu(other)
+if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >> PAGE_SHIFT) )
+{
+stub_linear = 0;
+break;
+}
+}
 if ( stub_linear )
 {
 l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);





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

Re: [Xen-devel] Test for osstest, features used in Qubes OS

[Simon Gaiser]

Jan Beulich:
 On 23.05.18 at 00:21,  wrote:
>> I have done some more testing in the meantime. The issue also affect
>> 4.10.1, but not 4.10.0. That's useful since it makes the bisect shorter.
>> A bisect identifies 8462c575d9 "x86/xpti: Hide almost all of .text and
>> all .data/.rodata/.bss mappings" as the commit which breaks suspend.
>>
>> 8462c575d9 is a squashed backport of:
>>
>>   422588e885 x86/xpti: Hide almost all of .text and all .data/.rodata/.bss 
>> mappings
>>   d1d6fc97d6 x86/xpti: really hide almost all of Xen image
>>   044fedfaa2 x86/traps: Put idt_table[] back into .bss
>>
>> And indeed, reverting those on staging fixes suspend. (This also matches
>> the behavior that xpti=off fixes suspend as George already reported
>> earlier today).
> 
> Okay, that was quite helpful - I think I see now where I screwed up (i.e.
> the issue is in the middle of the three commits). Could you confirm that a
> Xen booted with "nosmp" suspends and resumes fine?

Yes, with nosmp suspend works.



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

[Xen-devel] [linux-4.14 test] 123073: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  6 xen-install  fail REGR. vs. 122974

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail 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-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-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-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-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-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-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-qemut-ws16-amd64 17 guest-stop  fail 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-i386-xl-qemut-win10-i386 10 windows-install fail 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

version targeted for testing:
 linux1dff08485b9e835d00bfb34a435bc6f07dadb6fd
baseline version:
 linuxd88700f79448fc8f03617d4f1929c39676f8d1e4

Last test of basis   122974  2018-05-20 01:24:58 Z4 days
Testing same since   123073  2018-05-22 17:09:56 Z1 days1 attempts


People who touched revisions under test:
  Alexander Monakov 
  Anand Jain 
  Andre Przywara 
  Andrew Morton 
  Andy Shevchenko 
  Ard Biesheuvel 
  Ben Gardner 
  

Re: [Xen-devel] Test for osstest, features used in Qubes OS

[Jan Beulich]

>>> On 23.05.18 at 00:21,  wrote:
> I have done some more testing in the meantime. The issue also affect
> 4.10.1, but not 4.10.0. That's useful since it makes the bisect shorter.
> A bisect identifies 8462c575d9 "x86/xpti: Hide almost all of .text and
> all .data/.rodata/.bss mappings" as the commit which breaks suspend.
> 
> 8462c575d9 is a squashed backport of:
> 
>   422588e885 x86/xpti: Hide almost all of .text and all .data/.rodata/.bss 
> mappings
>   d1d6fc97d6 x86/xpti: really hide almost all of Xen image
>   044fedfaa2 x86/traps: Put idt_table[] back into .bss
> 
> And indeed, reverting those on staging fixes suspend. (This also matches
> the behavior that xpti=off fixes suspend as George already reported
> earlier today).

Okay, that was quite helpful - I think I see now where I screwed up (i.e.
the issue is in the middle of the three commits). Could you confirm that a
Xen booted with "nosmp" suspends and resumes fine?

Jan



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

Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions

[Joe Perches]

On Thu, 2018-05-24 at 06:47 -0600, Jens Axboe wrote:
> On 5/23/18 4:35 PM, Joe Perches wrote:
> > On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote:
> > > On 5/23/18 2:05 PM, Joe Perches wrote:
> > > > Convert the S_ symbolic permissions to their octal equivalents as
> > > > using octal and not symbolic permissions is preferred by many as more
> > > > readable.
> > > > 
> > > > see: https://lkml.org/lkml/2016/8/2/1945
> > > > 
> > > > Done with automated conversion via:
> > > > $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 
> > > > 
> > > > 
> > > > Miscellanea:
> > > > 
> > > > o Wrapped modified multi-line calls to a single line where appropriate
> > > > o Realign modified multi-line calls to open parenthesis
> > > 
> > > Honestly, I see this as pretty needless churn.
> > 
> > btw:
> > 
> > There is currently a mixture of symbolic and octal
> > permissions uses in block and drivers/block
> > 
> > ie: 94 octal and 146 symbolic uses.
> > 
> > If this is applied, all would become octal.
> 
> That does help justify the change. My main worry here is creating
> unnecessary conflicts, which is always annoying. But it's even more
> annoying when the change creating the conflict isn't really that
> important at all. Case in point, the patch doesn't apply to the
> for-4.18/block branch that it should go into...

Done against most recent -next as it's basically impossible
to do anything against multiple private trees.

Also, the script that generated the patch is in the changelog
so it's simple to rerun.



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

Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions

[Jens Axboe]

On 5/23/18 4:35 PM, Joe Perches wrote:
> On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote:
>> On 5/23/18 2:05 PM, Joe Perches wrote:
>>> Convert the S_ symbolic permissions to their octal equivalents as
>>> using octal and not symbolic permissions is preferred by many as more
>>> readable.
>>>
>>> see: https://lkml.org/lkml/2016/8/2/1945
>>>
>>> Done with automated conversion via:
>>> $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 
>>>
>>> Miscellanea:
>>>
>>> o Wrapped modified multi-line calls to a single line where appropriate
>>> o Realign modified multi-line calls to open parenthesis
>>
>> Honestly, I see this as pretty needless churn.
> 
> btw:
> 
> There is currently a mixture of symbolic and octal
> permissions uses in block and drivers/block
> 
> ie: 94 octal and 146 symbolic uses.
> 
> If this is applied, all would become octal.

That does help justify the change. My main worry here is creating
unnecessary conflicts, which is always annoying. But it's even more
annoying when the change creating the conflict isn't really that
important at all. Case in point, the patch doesn't apply to the
for-4.18/block branch that it should go into...

-- 
Jens Axboe


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

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

[Andrew Cooper]

On 24/05/18 13:14, Roger Pau Monné wrote:
> On Tue, May 22, 2018 at 12:20:42PM +0100, Andrew Cooper wrote:
>> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
>> updates a host MSR load list entry with the current hardware value of
>> MSR_DEBUGCTL.  This is wrong.
>>
>> On VMExit, hardware automatically resets MSR_DEBUGCTL to 0.  The only case
>> where different behaviour is needed is if Xen is debugging itself, and this
>> needs setting up unconditionally for the lifetime of the VM.
>>
>> The `ler` command line boolean is the only way to configure any use of
>> MSR_DEBUGCTL for Xen,
> Hm, there's no documentation at all for the 'ler' option.

:(  ISTR Jan introducing it for debugging purposes, but I've never used
it myself.

>
>> so tie the host load list entry to this setting in
>> construct_vmcs().  Any runtime update of Xen's MSR_DEBUGCTL setting requires
>> more complicated synchronisation across all the running VMs.
>>
>> In the exceedingly common case, this avoids the unnecessary overhead of 
>> having
>> a host load entry performing the same zeroing operation that hardware has
>> already performed as part of the VMExit.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Jun Nakajima 
>> CC: Kevin Tian 
>> CC: Wei Liu 
>> CC: Roger Pau Monné 
>>
>> Notes for backporting: This change probably does want backporting, but 
>> depends
>> on the previous patch "Support remote access to the MSR lists", and adds an
>> extra rdmsr to the vcpu construction path (resolved in a later patch).
>> ---
>>  xen/arch/x86/hvm/vmx/vmcs.c | 6 ++
>>  xen/arch/x86/hvm/vmx/vmx.c  | 3 +--
>>  2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
>> index 8bf54c4..2035a6d 100644
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -996,6 +996,7 @@ static int construct_vmcs(struct vcpu *v)
>>  struct domain *d = v->domain;
>>  u32 vmexit_ctl = vmx_vmexit_control;
>>  u32 vmentry_ctl = vmx_vmentry_control;
>> +int rc;
>>  
>>  vmx_vmcs_enter(v);
>>  
>> @@ -1266,6 +1267,11 @@ static int construct_vmcs(struct vcpu *v)
>>  if ( cpu_has_vmx_tsc_scaling )
>>  __vmwrite(TSC_MULTIPLIER, d->arch.hvm_domain.tsc_scaling_ratio);
>>  
>> +/* If using host debugging, restore Xen's setting on vmexit. */
>> +if ( this_cpu(ler_msr) &&
>> + (rc = vmx_add_host_load_msr(v, MSR_IA32_DEBUGCTLMSR))  )
>> +return rc;
> Isn't this missing a vmx_vmcs_exit on error?

It is indeed.  Will fix.

~Andrew

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

Re: [Xen-devel] [PULL v2 00/15] xen-20180522-tag

[Peter Maydell]

On 22 May 2018 at 19:46, Stefano Stabellini  wrote:
> The following changes since commit d32e41a1188e929cc0fb16829ce3736046951e39:
>
>   Merge remote-tracking branch 
> 'remotes/famz/tags/docker-and-block-pull-request' into staging (2018-05-18 
> 14:11:52 +0100)
>
> are available in the git repository at:
>
>
>   http://xenbits.xenproject.org/git-http/people/sstabellini/qemu-dm.git 
> tags/xen-20180522-tag
>
> for you to fetch changes up to 443c3c9cf1a18afcc705745d18101a4ea4de5b26:
>
>   xen_disk: be consistent with use of xendev and blkdev->xendev (2018-05-22 
> 11:43:22 -0700)
>
> 
> Xen 2018/05/22
>

Applied, thanks.

-- PMM

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

Re: [Xen-devel] [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

[Michal Hocko]

On Wed 23-05-18 22:19:19, Matthew Wilcox wrote:
> On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote:
> > So why is this any better than the current code. Sure I am not a great
> > fan of GFP_ZONE_TABLE because of how it is incomprehensible but this
> > doesn't look too much better, yet we are losing a check for incompatible
> > gfp flags. The diffstat looks really sound but then you just look and
> > see that the large part is the comment that at least explained the gfp
> > zone modifiers somehow and the debugging code. So what is the selling
> > point?
> 
> I have a plan, but it's not exactly fully-formed yet.
> 
> One of the big problems we have today is that we have a lot of users
> who have constraints on the physical memory they want to allocate,
> but we have very limited abilities to provide them with what they're
> asking for.  The various different ZONEs have different meanings on
> different architectures and are generally a mess.

Agreed.

> If we had eight ZONEs, we could offer:

No, please no more zones. What we have is quite a maint. burden on its
own. Ideally we should only have lowmem, highmem and special/device
zones for directly kernel accessible memory, the one that the kernel
cannot or must not use and completely special memory managed out of
the page allocator. All the remaining constrains should better be
implemented on top.

> ZONE_16M  // 24 bit
> ZONE_256M // 28 bit
> ZONE_LOWMEM   // CONFIG_32BIT only
> ZONE_4G   // 32 bit
> ZONE_64G  // 36 bit
> ZONE_1T   // 40 bit
> ZONE_ALL  // everything larger
> ZONE_MOVABLE  // movable allocations; no physical address guarantees
> 
> #ifdef CONFIG_64BIT
> #define ZONE_NORMAL   ZONE_ALL
> #else
> #define ZONE_NORMAL   ZONE_LOWMEM
> #endif
> 
> This would cover most driver DMA mask allocations; we could tweak the
> offered zones based on analysis of what people need.

But those already do have aproper API, IIUC. So do we really need to
make our GFP_*/Zone API more complicated than it already is?

> #define GFP_HIGHUSER  (GFP_USER | ZONE_ALL)
> #define GFP_HIGHUSER_MOVABLE  (GFP_USER | ZONE_MOVABLE)
> 
> One other thing I want to see is that fallback from zones happens from
> highest to lowest normally (ie if you fail to allocate in 1T, then you
> try to allocate from 64G), but movable allocations hapen from lowest
> to highest.  So ZONE_16M ends up full of page cache pages which are
> readily evictable for the rare occasions when we need to allocate memory
> below 16MB.
> 
> I'm sure there are lots of good reasons why this won't work, which is
> why I've been hesitant to propose it before now.

I am worried you are playing with a can of worms...
-- 
Michal Hocko
SUSE Labs

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

Re: [Xen-devel] [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

[Michal Hocko]

On Wed 23-05-18 16:07:16, Huaisheng HS1 Ye wrote:
> From: Michal Hocko [mailto:mho...@kernel.org]
> Sent: Wednesday, May 23, 2018 2:37 AM
> > 
> > On Mon 21-05-18 23:20:21, Huaisheng Ye wrote:
> > > From: Huaisheng Ye 
> > >
> > > Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number.
> > >
> > > Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks,
> > > the bottom three bits of GFP mask is reserved for storing encoded
> > > zone number.
> > >
> > > The encoding method is XOR. Get zone number from enum zone_type,
> > > then encode the number with ZONE_NORMAL by XOR operation.
> > > The goal is to make sure ZONE_NORMAL can be encoded to zero. So,
> > > the compatibility can be guaranteed, such as GFP_KERNEL and GFP_ATOMIC
> > > can be used as before.
> > >
> > > Reserve __GFP_MOVABLE in bit 3, so that it can continue to be used as
> > > a flag. Same as before, __GFP_MOVABLE respresents movable migrate type
> > > for ZONE_DMA, ZONE_DMA32, and ZONE_NORMAL. But when it is enabled with
> > > __GFP_HIGHMEM, ZONE_MOVABLE shall be returned instead of ZONE_HIGHMEM.
> > > __GFP_ZONE_MOVABLE is created to realize it.
> > >
> > > With this patch, just enabling __GFP_MOVABLE and __GFP_HIGHMEM is not
> > > enough to get ZONE_MOVABLE from gfp_zone. All callers should use
> > > GFP_HIGHUSER_MOVABLE or __GFP_ZONE_MOVABLE directly to achieve that.
> > >
> > > Decode zone number directly from bottom three bits of flags in gfp_zone.
> > > The theory of encoding and decoding is,
> > > A ^ B ^ B = A
> > 
> > So why is this any better than the current code. Sure I am not a great
> > fan of GFP_ZONE_TABLE because of how it is incomprehensible but this
> > doesn't look too much better, yet we are losing a check for incompatible
> > gfp flags. The diffstat looks really sound but then you just look and
> > see that the large part is the comment that at least explained the gfp
> > zone modifiers somehow and the debugging code. So what is the selling
> > point?
> 
> Dear Michal,
> 
> Let me try to reply your questions.
> Exactly, GFP_ZONE_TABLE is too complicated. I think there are two advantages
> from the series of patches.
> 
> 1. XOR operation is simple and efficient, GFP_ZONE_TABLE/BAD need to do twice
> shift operations, the first is for getting a zone_type and the second is for
> checking the to be returned type is a correct or not. But with these patch XOR
> operation just needs to use once. Because the bottom 3 bits of GFP bitmask 
> have
> been used to represent the encoded zone number, we can say there is no bad 
> zone
> number if all callers could use it without buggy way. Of course, the returned
> zone type in gfp_zone needs to be no more than ZONE_MOVABLE.

But you are losing the ability to check for wrong usage. And it seems
that the sad reality is that the existing code do screw up.

> 2. GFP_ZONE_TABLE has limit with the amount of zone types. Current 
> GFP_ZONE_TABLE
> is 32 bits, in general, there are 4 zone types for most ofX86_64 platform, 
> they
> are ZONE_DMA, ZONE_DMA32, ZONE_NORMAL and ZONE_MOVABLE. If we want to expand 
> the
> amount of zone types to larger than 4, the zone shift should be 3.

But we do not want to expand the number of zones IMHO. The existing zoo
is quite a maint. pain.
 
That being said. I am not saying that I am in love with GFP_ZONE_TABLE.
It always makes my head explode when I look there but it seems to work
with the current code and it is optimized for it. If you want to change
this then you should make sure you describe reasons _why_ this is an
improvement. And I would argue that "we can have more zones" is a
relevant one.
-- 
Michal Hocko
SUSE Labs

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

Re: [Xen-devel] [PATCH 3/9] x86/vmx: Factor locate_msr_entry() out of vmx_find_msr() and vmx_add_msr()

[Roger Pau Monné]

On Thu, May 24, 2018 at 11:59:07AM +0100, Andrew Cooper wrote:
> On 24/05/18 11:53, Roger Pau Monné wrote:
> > On Wed, May 23, 2018 at 05:55:50PM +0100, Andrew Cooper wrote:
> >> On 23/05/18 17:39, Roger Pau Monné wrote:
> >>> On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote:
>  Instead of having multiple algorithms searching the MSR lists, implement 
>  a
>  single one.  It has the semantics required by vmx_add_msr(), to identify 
>  the
>  position in which an MSR should live, if it isn't already present.
> 
>  There will be a marginal improvement for vmx_find_msr() by avoiding the
>  function pointer calls to vmx_msr_entry_key_cmp(), and a major 
>  improvement for
>  vmx_add_msr() by using a binary search instead of a linear search.
> 
>  Signed-off-by: Andrew Cooper 
>  ---
>  CC: Jan Beulich 
>  CC: Jun Nakajima 
>  CC: Kevin Tian 
>  CC: Wei Liu 
>  CC: Roger Pau Monné 
>  ---
>   xen/arch/x86/hvm/vmx/vmcs.c | 42 
>  --
>   1 file changed, 28 insertions(+), 14 deletions(-)
> 
>  diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
>  index f557857..e4acdc1 100644
>  --- a/xen/arch/x86/hvm/vmx/vmcs.c
>  +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>  @@ -1276,24 +1276,36 @@ static int construct_vmcs(struct vcpu *v)
>   return 0;
>   }
>   
>  -static int vmx_msr_entry_key_cmp(const void *key, const void *elt)
>  +/*
>  + * Search an MSR list looking for an MSR entry, or the slot in which it 
>  should
>  + * live (to keep the data sorted) if an entry is not found.
>  + *
>  + * The return pointer is guarenteed to be bounded by start and end.  
>  However,
>  + * it may point at end, and may be invalid for the caller to 
>  dereference.
>  + */
>  +static struct vmx_msr_entry *locate_msr_entry(
>  +struct vmx_msr_entry *start, struct vmx_msr_entry *end, uint32_t 
>  msr)
>   {
>  -const u32 *msr = key;
>  -const struct vmx_msr_entry *entry = elt;
>  +while ( start < end )
>  +{
>  +struct vmx_msr_entry *mid = start + (end - start) / 2;
>   
>  -if ( *msr > entry->index )
>  -return 1;
>  -if ( *msr < entry->index )
>  -return -1;
>  +if ( msr < mid->index )
>  +end = mid;
>  +else if ( msr > mid->index )
>  +start = mid + 1;
>  +else
>  +return mid;
>  +}
> >>> This is basically an open coded version of bsearch, isn't there anyway
> >>> to adapt the current bsearch so that it could be used for both
> >>> vmx_find_msr and vmx_add_msr?
> >>>
> >>> I know there will be a performance penalty for using a function
> >>> pointer for the comparator function, but this looks like code
> >>> duplication to me.
> >> A third use appears in a later patch.  bsearch() doesn't have the
> >> described property on a miss, which is necessary to maintain the lists.
> > I would consider adding a flag to the list of parameters so that
> > bsearch returned the position where the item should be added in case
> > of a miss. You could then wrap it inside of locate_msr_entry, or get
> > rid of this helper altogether.
> 
> bsearch() is specified by POSIX, and C89/99, amongst other standards. 
> Changing its API is not something I'm going to do.

Oh, didn't know that. In which case I agree. AFAICT there's no POSIX
specification for a function that could be used to add new entries
into a sorted array, so:

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

[Roger Pau Monné]

On Tue, May 22, 2018 at 12:20:42PM +0100, Andrew Cooper wrote:
> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen
> updates a host MSR load list entry with the current hardware value of
> MSR_DEBUGCTL.  This is wrong.
> 
> On VMExit, hardware automatically resets MSR_DEBUGCTL to 0.  The only case
> where different behaviour is needed is if Xen is debugging itself, and this
> needs setting up unconditionally for the lifetime of the VM.
> 
> The `ler` command line boolean is the only way to configure any use of
> MSR_DEBUGCTL for Xen,

Hm, there's no documentation at all for the 'ler' option.

> so tie the host load list entry to this setting in
> construct_vmcs().  Any runtime update of Xen's MSR_DEBUGCTL setting requires
> more complicated synchronisation across all the running VMs.
> 
> In the exceedingly common case, this avoids the unnecessary overhead of having
> a host load entry performing the same zeroing operation that hardware has
> already performed as part of the VMExit.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> 
> Notes for backporting: This change probably does want backporting, but depends
> on the previous patch "Support remote access to the MSR lists", and adds an
> extra rdmsr to the vcpu construction path (resolved in a later patch).
> ---
>  xen/arch/x86/hvm/vmx/vmcs.c | 6 ++
>  xen/arch/x86/hvm/vmx/vmx.c  | 3 +--
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index 8bf54c4..2035a6d 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -996,6 +996,7 @@ static int construct_vmcs(struct vcpu *v)
>  struct domain *d = v->domain;
>  u32 vmexit_ctl = vmx_vmexit_control;
>  u32 vmentry_ctl = vmx_vmentry_control;
> +int rc;
>  
>  vmx_vmcs_enter(v);
>  
> @@ -1266,6 +1267,11 @@ static int construct_vmcs(struct vcpu *v)
>  if ( cpu_has_vmx_tsc_scaling )
>  __vmwrite(TSC_MULTIPLIER, d->arch.hvm_domain.tsc_scaling_ratio);
>  
> +/* If using host debugging, restore Xen's setting on vmexit. */
> +if ( this_cpu(ler_msr) &&
> + (rc = vmx_add_host_load_msr(v, MSR_IA32_DEBUGCTLMSR))  )
> +return rc;

Isn't this missing a vmx_vmcs_exit on error?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 4/9] x86/vmx: Support remote access to the MSR lists

[Andrew Cooper]

On 24/05/18 12:50, Roger Pau Monné wrote:
> On Tue, May 22, 2018 at 12:20:41PM +0100, Andrew Cooper wrote:
>> At the moment, all modifications of the MSR lists are in current context.
>> However, future changes may need to put MSR_EFER into the lists from domctl
>> hypercall context.
>>
>> Plumb a struct vcpu parameter down through the infrastructure, and use
>> vmx_vmcs_{enter,exit}() for safe access to the VMCS in vmx_add_msr().  Use
>> assertions to ensure that access is either in current context, or while the
>> vcpu is paused.
>>
>> For now it is safe to require that remote accesses are under the domctl lock.
>> This will remain safe if/when the global domctl lock becomes per-domain.
> I'm not sure I see the point of this sentence. From my reading of the
> above test accesses will always be safe regardless of whether the
> domctl lock is global or per-domain?

Its attempting to justify why the domctl lock is ok to use here, but I
can drop the paragraph if people think it isn't helpful.

>
>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
>> index e4acdc1..8bf54c4 100644
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -1301,13 +1301,15 @@ static struct vmx_msr_entry *locate_msr_entry(
>>  return start;
>>  }
>>  
>> -struct vmx_msr_entry *vmx_find_msr(uint32_t msr, enum vmx_msr_list_type 
>> type)
>> +struct vmx_msr_entry *vmx_find_msr(struct vcpu *v, uint32_t msr,
>> +   enum vmx_msr_list_type type)
>>  {
>> -struct vcpu *curr = current;
>> -struct arch_vmx_struct *arch_vmx = >arch.hvm_vmx;
>> +struct arch_vmx_struct *arch_vmx = >arch.hvm_vmx;
>>  struct vmx_msr_entry *start = NULL, *ent, *end;
>>  unsigned int total;
>>  
>> +ASSERT(v == current || !vcpu_runnable(v));
> I would rather do:
>
> if ( v != current && vcpu_runnable(v) )
> {
> ASSERT_UNREACHABLE();
> return NULL;
> }

I'm not so certain.  Failing the assertion doesn't make the later code
unsafe to execute.

Even for the mutable operations, all that would happen if the assertion
failed would be corruption to the guest's view of its MSR state.

~Andrew

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

Re: [Xen-devel] [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

[Petr Mladek]

On Wed 2018-05-23 12:54:15, Thomas Garnier wrote:
> When using -fPIE/PIC with function tracing, the compiler generates a
> call through the GOT (call *__fentry__@GOTPCREL). This instruction
> takes 6 bytes instead of 5 on the usual relative call.
> 
> If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop
> so ftrace can handle the previous 5-bytes as before.
> 
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.
> 
> Signed-off-by: Thomas Garnier 
> ---
>  arch/x86/include/asm/ftrace.h   |  6 +++--
>  arch/x86/include/asm/sections.h |  4 
>  arch/x86/kernel/ftrace.c| 42 +++--
>  3 files changed, 48 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> index c18ed65287d5..8f2decce38d8 100644
> --- a/arch/x86/include/asm/ftrace.h
> +++ b/arch/x86/include/asm/ftrace.h
> @@ -25,9 +25,11 @@ extern void __fentry__(void);
>  static inline unsigned long ftrace_call_adjust(unsigned long addr)
>  {
>   /*
> -  * addr is the address of the mcount call instruction.
> -  * recordmcount does the necessary offset calculation.
> +  * addr is the address of the mcount call instruction. PIE has always a
> +  * byte added to the start of the function.
>*/
> + if (IS_ENABLED(CONFIG_X86_PIE))
> + addr -= 1;

This seems to modify the address even for modules that are _not_ compiled with
PIE, see below.

>   return addr;
>  }
>  
> diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> index 01ebcb6f263e..73b3c30cb7a3 100644
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -135,6 +135,44 @@ ftrace_modify_code_direct(unsigned long ip, unsigned 
> const char *old_code,
>   return 0;
>  }
>  
> +/* Bytes before call GOT offset */
> +const unsigned char got_call_preinsn[] = { 0xff, 0x15 };
> +
> +static int
> +ftrace_modify_initial_code(unsigned long ip, unsigned const char *old_code,
> +unsigned const char *new_code)
> +{
> + unsigned char replaced[MCOUNT_INSN_SIZE + 1];
> +
> + ftrace_expected = old_code;
> +
> + /*
> +  * If PIE is not enabled or no GOT call was found, default to the
> +  * original approach to code modification.
> +  */
> + if (!IS_ENABLED(CONFIG_X86_PIE) ||
> + probe_kernel_read(replaced, (void *)ip, sizeof(replaced)) ||
> + memcmp(replaced, got_call_preinsn, sizeof(got_call_preinsn)))
> + return ftrace_modify_code_direct(ip, old_code, new_code);

And this looks like an attempt to handle modules compiled without
PIE. Does it works with the right ip in that case?

I wonder if a better solution would be to update
scripts/recordmcount.c to store the incremented location into the module.

IMPORTANT: I have only vague picture about how this all works. It is
possible that I am completely wrong. The code might be correct,
especially if you tested this situation.

Best Regards,
Petr

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

Re: [Xen-devel] [PATCH v3 11/27] x86/power/64: Adapt assembly for PIE support

[Pavel Machek]

On Wed 2018-05-23 12:54:05, Thomas Garnier wrote:
> Change the assembly code to use only relative references of symbols for the
> kernel to be PIE compatible.
> 
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.
> 
> Signed-off-by: Thomas Garnier 

Again, was this tested?

> diff --git a/arch/x86/power/hibernate_asm_64.S 
> b/arch/x86/power/hibernate_asm_64.S
> index ce8da3a0412c..6fdd7bbc3c33 100644
> --- a/arch/x86/power/hibernate_asm_64.S
> +++ b/arch/x86/power/hibernate_asm_64.S
> @@ -24,7 +24,7 @@
>  #include 
>  
>  ENTRY(swsusp_arch_suspend)
> - movq$saved_context, %rax
> + leaqsaved_context(%rip), %rax
>   movq%rsp, pt_regs_sp(%rax)
>   movq%rbp, pt_regs_bp(%rax)
>   movq%rsi, pt_regs_si(%rax)
> @@ -115,7 +115,7 @@ ENTRY(restore_registers)
>   movq%rax, %cr4;  # turn PGE back on
>  
>   /* We don't restore %rax, it must be 0 anyway */
> - movq$saved_context, %rax
> + leaqsaved_context(%rip), %rax
>   movqpt_regs_sp(%rax), %rsp
>   movqpt_regs_bp(%rax), %rbp
>   movqpt_regs_si(%rax), %rsi

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

Re: [Xen-devel] [PATCH v3 09/27] x86/acpi: Adapt assembly for PIE support

[Pavel Machek]

On Wed 2018-05-23 12:54:03, Thomas Garnier wrote:
> Change the assembly code to use only relative references of symbols for the
> kernel to be PIE compatible.
> 
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.

What testing did this get?

> diff --git a/arch/x86/kernel/acpi/wakeup_64.S 
> b/arch/x86/kernel/acpi/wakeup_64.S
> index 50b8ed0317a3..472659c0f811 100644
> --- a/arch/x86/kernel/acpi/wakeup_64.S
> +++ b/arch/x86/kernel/acpi/wakeup_64.S
> @@ -14,7 +14,7 @@
>* Hooray, we are in Long 64-bit mode (but still running in low memory)
>*/
>  ENTRY(wakeup_long64)
> - movqsaved_magic, %rax
> + movqsaved_magic(%rip), %rax
>   movq$0x123456789abcdef0, %rdx
>   cmpq%rdx, %rax
>   jne bogus_64_magic

Because, as comment says, this is rather tricky code.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

[Xen-devel] Developmentstatus for Xen with Ceph as replicated storage

[thg]

Hi everybody,

in 2013 there was an announcment, that XenServer will fully support the
RBDs from Ceph, to use them as blockdevice for VMs (see
)

What is about Xen itself, how it is supported? I know that you can map
an RBD as device and use it for putting a VM-image on it. But this is a
"manual" process and thus not usable for cloud-servers with many VMs.

Anybody who has experiences with this or an other (working) option?

Using libvirt should work, but I don't get it running and a solution for
the XL-stack would be even better.


Thanks a lot,
-- 

kind regards,

thg

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail REGR. vs. 122131

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt  6 xen-install  fail in 122971 pass in 123066
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail 
in 122971 pass in 123066
 test-xtf-amd64-amd64-2   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 122971
 test-amd64-amd64-xl-rtds 10 debian-install fail pass in 122971

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 122971 like 
122131
 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 122971 like 
122131
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122131
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122131
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122131
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122131
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 122131
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122131
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122131
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 122131
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122131
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122131
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122131
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122131
 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  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-libvirt-xsm 13 migrate-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-libvirt-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-amd64-i386-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-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-xsm 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-xsm  13 migrate-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-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-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 

Re: [Xen-devel] [PATCH 3/9] x86/vmx: Factor locate_msr_entry() out of vmx_find_msr() and vmx_add_msr()

[Andrew Cooper]

On 24/05/18 11:53, Roger Pau Monné wrote:
> On Wed, May 23, 2018 at 05:55:50PM +0100, Andrew Cooper wrote:
>> On 23/05/18 17:39, Roger Pau Monné wrote:
>>> On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote:
 Instead of having multiple algorithms searching the MSR lists, implement a
 single one.  It has the semantics required by vmx_add_msr(), to identify 
 the
 position in which an MSR should live, if it isn't already present.

 There will be a marginal improvement for vmx_find_msr() by avoiding the
 function pointer calls to vmx_msr_entry_key_cmp(), and a major improvement 
 for
 vmx_add_msr() by using a binary search instead of a linear search.

 Signed-off-by: Andrew Cooper 
 ---
 CC: Jan Beulich 
 CC: Jun Nakajima 
 CC: Kevin Tian 
 CC: Wei Liu 
 CC: Roger Pau Monné 
 ---
  xen/arch/x86/hvm/vmx/vmcs.c | 42 
 --
  1 file changed, 28 insertions(+), 14 deletions(-)

 diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
 index f557857..e4acdc1 100644
 --- a/xen/arch/x86/hvm/vmx/vmcs.c
 +++ b/xen/arch/x86/hvm/vmx/vmcs.c
 @@ -1276,24 +1276,36 @@ static int construct_vmcs(struct vcpu *v)
  return 0;
  }
  
 -static int vmx_msr_entry_key_cmp(const void *key, const void *elt)
 +/*
 + * Search an MSR list looking for an MSR entry, or the slot in which it 
 should
 + * live (to keep the data sorted) if an entry is not found.
 + *
 + * The return pointer is guarenteed to be bounded by start and end.  
 However,
 + * it may point at end, and may be invalid for the caller to dereference.
 + */
 +static struct vmx_msr_entry *locate_msr_entry(
 +struct vmx_msr_entry *start, struct vmx_msr_entry *end, uint32_t msr)
  {
 -const u32 *msr = key;
 -const struct vmx_msr_entry *entry = elt;
 +while ( start < end )
 +{
 +struct vmx_msr_entry *mid = start + (end - start) / 2;
  
 -if ( *msr > entry->index )
 -return 1;
 -if ( *msr < entry->index )
 -return -1;
 +if ( msr < mid->index )
 +end = mid;
 +else if ( msr > mid->index )
 +start = mid + 1;
 +else
 +return mid;
 +}
>>> This is basically an open coded version of bsearch, isn't there anyway
>>> to adapt the current bsearch so that it could be used for both
>>> vmx_find_msr and vmx_add_msr?
>>>
>>> I know there will be a performance penalty for using a function
>>> pointer for the comparator function, but this looks like code
>>> duplication to me.
>> A third use appears in a later patch.  bsearch() doesn't have the
>> described property on a miss, which is necessary to maintain the lists.
> I would consider adding a flag to the list of parameters so that
> bsearch returned the position where the item should be added in case
> of a miss. You could then wrap it inside of locate_msr_entry, or get
> rid of this helper altogether.

bsearch() is specified by POSIX, and C89/99, amongst other standards. 
Changing its API is not something I'm going to do.

~Andrew

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

Re: [Xen-devel] [PATCH 3/9] x86/vmx: Factor locate_msr_entry() out of vmx_find_msr() and vmx_add_msr()

[Roger Pau Monné]

On Wed, May 23, 2018 at 05:55:50PM +0100, Andrew Cooper wrote:
> On 23/05/18 17:39, Roger Pau Monné wrote:
> > On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote:
> >> Instead of having multiple algorithms searching the MSR lists, implement a
> >> single one.  It has the semantics required by vmx_add_msr(), to identify 
> >> the
> >> position in which an MSR should live, if it isn't already present.
> >>
> >> There will be a marginal improvement for vmx_find_msr() by avoiding the
> >> function pointer calls to vmx_msr_entry_key_cmp(), and a major improvement 
> >> for
> >> vmx_add_msr() by using a binary search instead of a linear search.
> >>
> >> Signed-off-by: Andrew Cooper 
> >> ---
> >> CC: Jan Beulich 
> >> CC: Jun Nakajima 
> >> CC: Kevin Tian 
> >> CC: Wei Liu 
> >> CC: Roger Pau Monné 
> >> ---
> >>  xen/arch/x86/hvm/vmx/vmcs.c | 42 
> >> --
> >>  1 file changed, 28 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> >> index f557857..e4acdc1 100644
> >> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> >> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> >> @@ -1276,24 +1276,36 @@ static int construct_vmcs(struct vcpu *v)
> >>  return 0;
> >>  }
> >>  
> >> -static int vmx_msr_entry_key_cmp(const void *key, const void *elt)
> >> +/*
> >> + * Search an MSR list looking for an MSR entry, or the slot in which it 
> >> should
> >> + * live (to keep the data sorted) if an entry is not found.
> >> + *
> >> + * The return pointer is guarenteed to be bounded by start and end.  
> >> However,
> >> + * it may point at end, and may be invalid for the caller to dereference.
> >> + */
> >> +static struct vmx_msr_entry *locate_msr_entry(
> >> +struct vmx_msr_entry *start, struct vmx_msr_entry *end, uint32_t msr)
> >>  {
> >> -const u32 *msr = key;
> >> -const struct vmx_msr_entry *entry = elt;
> >> +while ( start < end )
> >> +{
> >> +struct vmx_msr_entry *mid = start + (end - start) / 2;
> >>  
> >> -if ( *msr > entry->index )
> >> -return 1;
> >> -if ( *msr < entry->index )
> >> -return -1;
> >> +if ( msr < mid->index )
> >> +end = mid;
> >> +else if ( msr > mid->index )
> >> +start = mid + 1;
> >> +else
> >> +return mid;
> >> +}
> > This is basically an open coded version of bsearch, isn't there anyway
> > to adapt the current bsearch so that it could be used for both
> > vmx_find_msr and vmx_add_msr?
> >
> > I know there will be a performance penalty for using a function
> > pointer for the comparator function, but this looks like code
> > duplication to me.
> 
> A third use appears in a later patch.  bsearch() doesn't have the
> described property on a miss, which is necessary to maintain the lists.

I would consider adding a flag to the list of parameters so that
bsearch returned the position where the item should be added in case
of a miss. You could then wrap it inside of locate_msr_entry, or get
rid of this helper altogether.

Thanks, Roger.

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

Re: [Xen-devel] Likely build race, "/usr/bin/ld: cannot find -lvirt"

[Ian Jackson]

Ian Jackson writes ("Likely build race, "/usr/bin/ld: cannot find -lvirt""):
> tl;dr:
> 
> I think there is a bug in libvirt's build system which, with
> low probability, causes a build failure containing this message:
>   /usr/bin/ld: cannot find -lvirt
> 
> Complete build logs of two attempts:
> 
>   
> http://logs.test-lab.xenproject.org/osstest/logs/123046/build-i386-libvirt/6.ts-libvirt-build.log
> 
>   
> http://logs.test-lab.xenproject.org/osstest/logs/123096/build-i386-libvirt/6.ts-libvirt-build.log

I have run a number of attempts.  Out of 5 more, 1 succeeded.  So out
of a total of 7 attempts, 1 succeeded.  This repro rate is an IMO
excellent opportunity to debug this race :-).

Ian.

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