[Xen-devel] [PATCH v2 2/2] xen/kbdif: add multi-touch support
From: Oleksandr Andrushchenko Signed-off-by: Oleksandr Andrushchenko --- xen/include/public/io/kbdif.h | 210 ++ 1 file changed, 210 insertions(+) diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h index 446aed2478b5..74883267d6e6 100644 --- a/xen/include/public/io/kbdif.h +++ b/xen/include/public/io/kbdif.h @@ -57,6 +57,12 @@ * Backends, which support reporting of absolute coordinates for pointer * device should set this to 1. * + * feature-multi-touch + * Values: + * + * Backends, which support reporting of multi-touch events + * should set this to 1. + * *- Pointer Device Parameters * * width @@ -87,6 +93,11 @@ * Request backend to report absolute pointer coordinates * (XENKBD_TYPE_POS) instead of relative ones (XENKBD_TYPE_MOTION). * + * request-multi-touch + * Values: + * + * Request backend to report multi-touch events. + * *--- Request Transport Parameters --- * * event-channel @@ -106,6 +117,25 @@ * * OBSOLETE, not recommended for use. * PFN of the shared page. + * + *--- Multi-touch Device Parameters --- + * + * mt-num-contacts + * Values: + * + * Number of simultaneous touches reported. + * + * mt-width + * Values: + * + * Width of the touch area to be used by the frontend + * while reporting input events, pixels, [0; UINT32_MAX]. + * + * mt-height + * Values: + * + * Height of the touch area to be used by the frontend + * while reporting input events, pixels, [0; UINT32_MAX]. */ /* @@ -116,6 +146,16 @@ #define XENKBD_TYPE_RESERVED 2 #define XENKBD_TYPE_KEY3 #define XENKBD_TYPE_POS4 +#define XENKBD_TYPE_MTOUCH 5 + +/* Multi-touch event sub-codes */ + +#define XENKBD_MT_EV_DOWN 0 +#define XENKBD_MT_EV_UP1 +#define XENKBD_MT_EV_MOTION2 +#define XENKBD_MT_EV_SYN 3 +#define XENKBD_MT_EV_SHAPE 4 +#define XENKBD_MT_EV_ORIENT5 /* * CONSTANTS, XENSTORE FIELD AND PATH NAME STRINGS, HELPERS. @@ -124,11 +164,16 @@ #define XENKBD_DRIVER_NAME "vkbd" #define XENKBD_FIELD_FEAT_ABS_POINTER "feature-abs-pointer" +#define XENKBD_FIELD_FEAT_MTOUCH "feature-multi-touch" #define XENKBD_FIELD_REQ_ABS_POINTER "request-abs-pointer" +#define XENKBD_FIELD_REQ_MTOUCH"request-multi-touch" #define XENKBD_FIELD_RING_GREF "page-gref" #define XENKBD_FIELD_EVT_CHANNEL "event-channel" #define XENKBD_FIELD_WIDTH "width" #define XENKBD_FIELD_HEIGHT"height" +#define XENKBD_FIELD_MT_WIDTH "mt-width" +#define XENKBD_FIELD_MT_HEIGHT "mt-height" +#define XENKBD_FIELD_MT_NUM_CONTACTS "mt-num-contacts" /* OBSOLETE, not recommended for use */ #define XENKBD_FIELD_RING_REF "page-ref" @@ -248,6 +293,170 @@ struct xenkbd_position int32_t rel_z; }; +/* + * Multi-touch event and its sub-types + * + * All multi-touch event packets have common header: + * + * 01 2 3octet + * +++++ + * | _TYPE_MTOUCH | event_type | contact_id |reserved| 4 + * +++++ + * | reserved | 8 + * +++++ + * + * event_type - unt8_t, multi-touch event sub-type, XENKBD_MT_EV_??? + * contact_id - unt8_t, ID of the contact + * + * Touch interactions can consist of one or more contacts. + * For each contact, a series of events is generated, starting + * with a down event, followed by zero or more motion events, + * and ending with an up event. Events relating to the same + * contact point can be identified by the ID of the sequence: contact ID. + * Contact ID may be reused after XENKBD_MT_EV_UP event and + * is in the [0; XENKBD_FIELD_NUM_CONTACTS - 1] range. + * + * For further information please refer to documentation on Wayland [1], + * Linux [2] and Windows [3] multi-touch support. + * + * [1] https://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml + * [2] https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt + * [3] https://msdn.microsoft.com/en-us/library/jj151564(v=vs.85).aspx + * + * + * Multi-touch down event - sent when a new touch is made: touch is assigned + * a unique contact ID, sent with this and consequent events related + * to this touch. + * 01 2 3octet + * +++++ +
[Xen-devel] [PATCH v2 0/2] xen/kbdif: add multi-touch support
From: Oleksandr Andrushchenko Hi, all! This series updates existing kbdif protocol documentation and adds multi-touch support Thank you, Oleksandr Andrushchenko Changes since v1: * removed mtouch folder * changed mtouch xenstore parameters' names * single multi-touch device per driver, if more needed multiple instances of the driver should be configured via xenstore entries Oleksandr Andrushchenko (2): xen/kbdif: update protocol documentation xen/kbdif: add multi-touch support xen/include/public/io/kbdif.h | 458 +++--- 1 file changed, 431 insertions(+), 27 deletions(-) -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/2] xen/kbdif: update protocol documentation
From: Oleksandr Andrushchenko Reviewed-by: Stefano Stabellini Signed-off-by: Oleksandr Andrushchenko --- xen/include/public/io/kbdif.h | 248 +- 1 file changed, 221 insertions(+), 27 deletions(-) diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h index 2d2aebdd3f28..446aed2478b5 100644 --- a/xen/include/public/io/kbdif.h +++ b/xen/include/public/io/kbdif.h @@ -26,46 +26,226 @@ #ifndef __XEN_PUBLIC_IO_KBDIF_H__ #define __XEN_PUBLIC_IO_KBDIF_H__ -/* In events (backend -> frontend) */ +/* + * + * Feature and Parameter Negotiation + * + * + * The two halves of a para-virtual driver utilize nodes within + * XenStore to communicate capabilities and to negotiate operating parameters. + * This section enumerates these nodes which reside in the respective front and + * backend portions of XenStore, following XenBus convention. + * + * All data in XenStore is stored as strings. Nodes specifying numeric + * values are encoded in decimal. Integer value ranges listed below are + * expressed as fixed sized integer types capable of storing the conversion + * of a properly formated node string, without loss of information. + * + * + *Backend XenBus Nodes + * + * + * Features supported + * + * Capable backend advertises supported features by publishing + * corresponding entries in XenStore and puts 1 as the value of the entry. + * If a feature is not supported then 0 must be set or feature entry omitted. + * + * feature-abs-pointer + * Values: + * + * Backends, which support reporting of absolute coordinates for pointer + * device should set this to 1. + * + *- Pointer Device Parameters + * + * width + * Values: + * + * Maximum X coordinate (width) to be used by the frontend + * while reporting input events, pixels, [0; UINT32_MAX]. + * + * height + * Values: + * + * Maximum Y coordinate (height) to be used by the frontend + * while reporting input events, pixels, [0; UINT32_MAX]. + * + * + *Frontend XenBus Nodes + * + * + *-- Feature request - + * + * Capable frontend requests features from backend via setting corresponding + * entries to 1 in XenStore. Requests for features not advertised as supported + * by the backend have no effect. + * + * request-abs-pointer + * Values: + * + * Request backend to report absolute pointer coordinates + * (XENKBD_TYPE_POS) instead of relative ones (XENKBD_TYPE_MOTION). + * + *--- Request Transport Parameters --- + * + * event-channel + * Values: + * + * The identifier of the Xen event channel used to signal activity + * in the ring buffer. + * + * page-gref + * Values: + * + * The Xen grant reference granting permission for the backend to map + * a sole page in a single page sized event ring buffer. + * + * page-ref + * Values: + * + * OBSOLETE, not recommended for use. + * PFN of the shared page. + */ /* - * Frontends should ignore unknown in events. + * EVENT CODES. */ -/* Pointer movement event */ -#define XENKBD_TYPE_MOTION 1 -/* Event type 2 currently not used */ -/* Key event (includes pointer buttons) */ -#define XENKBD_TYPE_KEY 3 +#define XENKBD_TYPE_MOTION 1 +#define XENKBD_TYPE_RESERVED 2 +#define XENKBD_TYPE_KEY3 +#define XENKBD_TYPE_POS4 + /* - * Pointer position event - * Capable backend sets feature-abs-pointer in xenstore. - * Frontend requests ot instead of XENKBD_TYPE_MOTION by setting - * request-abs-update in xenstore. + * CONSTANTS, XENSTORE FIELD AND PATH NAME STRINGS, HELPERS. + */ + +#define XENKBD_DRIVER_NAME "vkbd" + +#define XENKBD_FIELD_FEAT_ABS_POINTER "feature-abs-pointer" +#define XENKBD_FIELD_REQ_ABS_POINTER "request-abs-pointer" +#define XENKBD_FIELD_RING_GREF "page-gref" +#define XENKBD_FIELD_EVT_CHANNEL "event-channel" +#define XENKBD_FIELD_WIDTH "width" +#define XENKBD_FIELD_HEIGHT"height" + +/* OBSOLETE, not recommended for use */ +#define XENKBD_FIELD_RING_REF "page-ref" + +/* + * + * Descr
[Xen-devel] [xen-unstable-smoke test] 104690: regressions - trouble: blocked/broken/fail
flight 104690 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104690/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z1 days Failing since104642 2017-01-25 10:01:54 Z0 days 19 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days 16 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 4/6] COLO-Proxy: Add primary userspace colo proxy start args
Qemu need this args to start userspace colo-proxy.
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_dm.c | 104
tools/libxl/libxl_nic.c | 232
tools/libxl/libxl_types.idl | 31 +-
tools/libxl/xl_cmdimpl.c| 58 +++
4 files changed, 424 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 281058d..b3484df 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1244,6 +1244,110 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
nics[i].devid, ifname,
libxl_tapif_script(gc),
libxl_tapif_script(gc)));
+
+/* Userspace COLO Proxy need this */
+if (state->saved_state) {
+/* secondary colo run */
+} else {
+/* primary colo run */
+if (nics[i].sock_mirror_id &&
+nics[i].sock_mirror_ip &&
+nics[i].sock_mirror_port) {
+flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args,
+
GCSPRINTF("socket,id=%s,host=%s,port=%s,server,nowait",
+ nics[i].sock_mirror_id,
+ nics[i].sock_mirror_ip,
+ nics[i].sock_mirror_port));
+}
+if (nics[i].sock_compare_pri_in_id &&
+nics[i].sock_compare_pri_in_ip &&
+nics[i].sock_compare_pri_in_port) {
+flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args,
+
GCSPRINTF("socket,id=%s,host=%s,port=%s,server,nowait",
+ nics[i].sock_compare_pri_in_id,
+ nics[i].sock_compare_pri_in_ip,
+ nics[i].sock_compare_pri_in_port));
+}
+if (nics[i].sock_compare_sec_in_id &&
+nics[i].sock_compare_sec_in_ip &&
+nics[i].sock_compare_sec_in_port) {
+flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args,
+
GCSPRINTF("socket,id=%s,host=%s,port=%s,server,nowait",
+ nics[i].sock_compare_sec_in_id,
+ nics[i].sock_compare_sec_in_ip,
+ nics[i].sock_compare_sec_in_port));
+}
+if (nics[i].sock_redirector0_id &&
+nics[i].sock_redirector0_ip &&
+nics[i].sock_redirector0_port) {
+flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args,
+
GCSPRINTF("socket,id=%s,host=%s,port=%s,server,nowait",
+ nics[i].sock_redirector0_id,
+ nics[i].sock_redirector0_ip,
+ nics[i].sock_redirector0_port));
+}
+if (nics[i].sock_redirector1_id &&
+nics[i].sock_redirector1_ip &&
+nics[i].sock_redirector1_port) {
+flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args,
+ GCSPRINTF("socket,id=%s,host=%s,port=%s",
+ nics[i].sock_redirector1_id,
+ nics[i].sock_redirector1_ip,
+ nics[i].sock_redirector1_port));
+}
+if (nics[i].sock_redirector2_id &&
+nics[i].sock_redirector2_ip &&
+nics[i].sock_redirector2_port) {
+flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args,
+ GCSPRINTF("socket,id=%s,host=%s,port=%s",
+ nics[i].sock_redirector2_id,
+ nics[i].sock_redirector2_ip,
+ nics[i].sock_redirector2_port));
+}
+if (nics[i].filter_mirror_queue &&
+nics[i].filter_mirror_outdev) {
+flexarray_append(dm_args, "-object");
+flexarray_append(dm_args,
+
GCSPRINTF("filter-mirror,id=m1,netdev=net%d,queue=%s,outdev=%s",
+ nics[i].devid,
+ nics[i].
[Xen-devel] [PATCH RFC 0/6] COLO-Proxy: Make Xen COLO use userspace colo-proxy
Hi~ All~ Happy Chinese New Year~~ Because of some reason, We no longer support COLO kernel proxy. So we send this patch set to make Xen use userspace colo-proxy in qemu. Below is a COLO userspace proxy ascii figure: Primary qemu Secondary qemu +--+ ++ | +--+ | | +---+ | | | | | | | | | | |guest | | | | guest | | | | | | | | | | | +---^--+---+ | | +-+++ | | | | | | ^| | | | | | | || | | | +--+ | || | |netfilter| | | || | netfilter|| | | +--+ ++ || | +---+ | | | | | | |out || | | || filter excute order | | | | | | +-+|| | | || +---> | | | | | | || | ||| | | || TCP | | | | +-+--+-+ +-v+ +-v+ |pri +++sec|| | | ++ +---++---v+rewriter++ ++ | | | | | | | | | | |in | |in || | | | | || | || | | | | | filter | | filter | | filter +--> colo <--+ +> filter +--> adjust | adjust +--> filter | | | | | | mirror | |redirector| |redirector| || compare | | || | | redirector | | ack| seq| | redirector | | | | | | | | | | | || | | || | | | || | || | | | | +^-+ ++-+ +--+ |+-+ | || | ++ ++--+ +---++ | | | | | tx| rx rx | | || | txall | rx | | | | | || | || +---+ | | | | +--+ | | || || | | | filter excute order | | | || || | | | +>| | | ++| | +-+ | | | |||| | | +--+ ++ |guest receive | guest send || ++v+ | | NOTE: filter direction is rx/tx/all | tap | rx:receive packets sent to the netdev | | tx:receive packets sent by the netdev +--+ You can know the detail from here: http://wiki.qemu.org/Features/COLO https://github.com/qemu/qemu/blob/master/docs/colo-proxy.txt Zhang Chen (6): COLO-Proxy: Add remus command to open use
[Xen-devel] [PATCH RFC 1/6] COLO-Proxy: Add remus command to open userspace proxy
Add remus '-p' to enable userspace colo proxy(in qemu).
Signed-off-by: Zhang Chen
---
docs/man/xl.pod.1.in | 4
tools/libxl/libxl_colo.h | 5 +
tools/libxl/libxl_colo_save.c | 2 ++
tools/libxl/libxl_types.idl | 17 +
tools/libxl/xl_cmdimpl.c | 13 -
tools/libxl/xl_cmdtable.c | 3 ++-
6 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index 09c1faa..b5fb7c1 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -553,6 +553,10 @@ Disable disk replication. Requires enabling unsafe mode.
Enable COLO HA. This conflicts with B<-i> and B<-b>, and memory
checkpoint compression must be disabled.
+=item B<-p>
+
+Enable userspace COLO Proxy. Must open with B<-c>.
+
=back
=item B I
diff --git a/tools/libxl/libxl_colo.h b/tools/libxl/libxl_colo.h
index 682275c..4746d8c 100644
--- a/tools/libxl/libxl_colo.h
+++ b/tools/libxl/libxl_colo.h
@@ -64,6 +64,11 @@ struct libxl__colo_proxy_state {
int sock_fd;
int index;
+/*
+ * Private, True means use userspace colo proxy
+ * False means use kernel colo proxy.
+ */
+bool is_userspace_proxy;
};
struct libxl__colo_save_state {
diff --git a/tools/libxl/libxl_colo_save.c b/tools/libxl/libxl_colo_save.c
index 620..eb8336c 100644
--- a/tools/libxl/libxl_colo_save.c
+++ b/tools/libxl/libxl_colo_save.c
@@ -101,6 +101,8 @@ void libxl__colo_save_setup(libxl__egc *egc,
libxl__colo_save_state *css)
css->qdisk_setuped = false;
css->qdisk_used = false;
libxl__ev_child_init(&css->child);
+css->cps.is_userspace_proxy =
+libxl_defbool_val(dss->remus->userspace_colo_proxy);
if (dss->remus->netbufscript)
css->colo_proxy_script = libxl__strdup(gc, dss->remus->netbufscript);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index a612d1f..1bd2057 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -844,14 +844,15 @@ libxl_sched_credit2_params =
Struct("sched_credit2_params", [
], dispose_fn=None)
libxl_domain_remus_info = Struct("domain_remus_info",[
-("interval", integer),
-("allow_unsafe", libxl_defbool),
-("blackhole",libxl_defbool),
-("compression", libxl_defbool),
-("netbuf", libxl_defbool),
-("netbufscript", string),
-("diskbuf", libxl_defbool),
-("colo", libxl_defbool)
+("interval", integer),
+("allow_unsafe", libxl_defbool),
+("blackhole",libxl_defbool),
+("compression", libxl_defbool),
+("netbuf", libxl_defbool),
+("netbufscript", string),
+("diskbuf", libxl_defbool),
+("colo", libxl_defbool),
+("userspace_colo_proxy", libxl_defbool)
])
libxl_event_type = Enumeration("event_type", [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 7e8a8ae..905c5f6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -8893,7 +8893,7 @@ int main_remus(int argc, char **argv)
memset(&r_info, 0, sizeof(libxl_domain_remus_info));
-SWITCH_FOREACH_OPT(opt, "Fbundi:s:N:ec", NULL, "remus", 2) {
+SWITCH_FOREACH_OPT(opt, "Fbundi:s:N:ecp", NULL, "remus", 2) {
case 'i':
r_info.interval = atoi(optarg);
break;
@@ -8923,6 +8923,9 @@ int main_remus(int argc, char **argv)
break;
case 'c':
libxl_defbool_set(&r_info.colo, true);
+break;
+case 'p':
+libxl_defbool_set(&r_info.userspace_colo_proxy, true);
}
domid = find_domain(argv[optind]);
@@ -8931,9 +8934,17 @@ int main_remus(int argc, char **argv)
/* Defaults */
libxl_defbool_setdefault(&r_info.blackhole, false);
libxl_defbool_setdefault(&r_info.colo, false);
+libxl_defbool_setdefault(&r_info.userspace_colo_proxy, false);
+
if (!libxl_defbool_val(r_info.colo) && !r_info.interval)
r_info.interval = 200;
+if (libxl_defbool_val(r_info.userspace_colo_proxy) &&
+!libxl_defbool_val(r_info.colo)) {
+perror("option -p must open with -c");
+exit(-1);
+}
+
if (libxl_defbool_val(r_info.colo)) {
if (r_info.interval || libxl_defbool_val(r_info.blackhole) ||
!libxl_defbool_is_default(r_info.netbuf) ||
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 588d5d9..a124059 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -506,7 +506,8 @@ struct cmd_spec cmd_table[] = {
"-n Disable network output buffering. Works only in
unsafe mode.\n"
"-d Disable disk replication. Works only in unsafe
mode.\n"
"-c Enable COLO HA. It is conflict with -i and -b,
and memory\n"
- "checkpoint must be disabled"
+ "checkpo
[Xen-devel] [PATCH RFC 2/6] COLO-Proxy: Setup userspace colo-proxy on primary side
In this patch we close kernel COLO-Proxy on primary side.
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_colo_proxy.c | 30 ++
tools/libxl/libxl_colo_save.c | 9 +++--
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_colo_proxy.c b/tools/libxl/libxl_colo_proxy.c
index 0983f42..348484d 100644
--- a/tools/libxl/libxl_colo_proxy.c
+++ b/tools/libxl/libxl_colo_proxy.c
@@ -152,6 +152,11 @@ int colo_proxy_setup(libxl__colo_proxy_state *cps)
STATE_AO_GC(cps->ao);
+if (cps->is_userspace_proxy) {
+/* If enable userspace proxy mode, we don't need setup kernel proxy */
+return 0;
+}
+
skfd = socket(PF_NETLINK, SOCK_RAW, NETLINK_COLO);
if (skfd < 0) {
LOGD(ERROR, ao->domid, "can not create a netlink socket: %s",
strerror(errno));
@@ -222,6 +227,14 @@ out:
void colo_proxy_teardown(libxl__colo_proxy_state *cps)
{
+if (cps->is_userspace_proxy) {
+/*
+ * If enable userspace proxy mode,
+ * we don't need teardown kernel proxy
+ */
+return;
+}
+
if (cps->sock_fd >= 0) {
close(cps->sock_fd);
cps->sock_fd = -1;
@@ -232,6 +245,14 @@ void colo_proxy_teardown(libxl__colo_proxy_state *cps)
void colo_proxy_preresume(libxl__colo_proxy_state *cps)
{
+if (cps->is_userspace_proxy) {
+/*
+ * If enable userspace proxy mode,
+ * we don't need preresume kernel proxy
+ */
+return;
+}
+
colo_proxy_send(cps, NULL, 0, COLO_CHECKPOINT);
/* TODO: need to handle if the call fails... */
}
@@ -260,6 +281,15 @@ int colo_proxy_checkpoint(libxl__colo_proxy_state *cps,
struct colo_msg *m;
int ret = -1;
+/*
+ * enable userspace proxy mode, tmp sleep.
+ * then we will add qemu API support this func.
+ */
+if (cps->is_userspace_proxy) {
+sleep(timeout_us / 100);
+return 0;
+}
+
STATE_AO_GC(cps->ao);
size = colo_proxy_recv(cps, &buff, timeout_us);
diff --git a/tools/libxl/libxl_colo_save.c b/tools/libxl/libxl_colo_save.c
index eb8336c..7b6e38f 100644
--- a/tools/libxl/libxl_colo_save.c
+++ b/tools/libxl/libxl_colo_save.c
@@ -110,8 +110,13 @@ void libxl__colo_save_setup(libxl__egc *egc,
libxl__colo_save_state *css)
css->colo_proxy_script = GCSPRINTF("%s/colo-proxy-setup",
libxl__xen_script_dir_path());
-cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VIF) |
- (1 << LIBXL__DEVICE_KIND_VBD);
+/* If enable userspace proxy mode, we don't need VIF */
+if (css->cps.is_userspace_proxy) {
+cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VBD);
+} else {
+cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VIF) |
+ (1 << LIBXL__DEVICE_KIND_VBD);
+}
cds->ops = colo_ops;
cds->callback = colo_save_setup_done;
cds->ao = ao;
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 3/6] COLO-Proxy: Setup userspace colo-proxy on secondary side
In this patch we add a function to close
kernel COLO-Proxy on secondary side.
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_colo_restore.c | 9 +++--
tools/libxl/libxl_create.c | 9 +++--
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 18 +++---
4 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/tools/libxl/libxl_colo_restore.c b/tools/libxl/libxl_colo_restore.c
index 6a96328..1d42539 100644
--- a/tools/libxl/libxl_colo_restore.c
+++ b/tools/libxl/libxl_colo_restore.c
@@ -774,8 +774,13 @@ static void colo_setup_checkpoint_devices(libxl__egc *egc,
STATE_AO_GC(crs->ao);
-cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VIF) |
- (1 << LIBXL__DEVICE_KIND_VBD);
+if (crs->cps.is_userspace_proxy) {
+cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VBD);
+} else {
+cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VIF) |
+ (1 << LIBXL__DEVICE_KIND_VBD);
+}
+
cds->callback = colo_restore_setup_cds_done;
cds->ao = ao;
cds->domid = crs->domid;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e3bc257..d230ecd 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1609,6 +1609,7 @@ static int do_domain_create(libxl_ctx *ctx,
libxl_domain_config *d_config,
uint32_t *domid, int restore_fd, int send_back_fd,
const libxl_domain_restore_params *params,
const char *colo_proxy_script,
+const bool userspace_colo_proxy,
const libxl_asyncop_how *ao_how,
const libxl_asyncprogress_how *aop_console_how)
{
@@ -1633,6 +1634,7 @@ static int do_domain_create(libxl_ctx *ctx,
libxl_domain_config *d_config,
cdcs->dcs.callback = domain_create_cb;
cdcs->dcs.domid_soft_reset = INVALID_DOMID;
cdcs->dcs.colo_proxy_script = colo_proxy_script;
+cdcs->dcs.crs.cps.is_userspace_proxy = userspace_colo_proxy;
libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
cdcs->domid_out = domid;
@@ -1821,7 +1823,7 @@ int libxl_domain_create_new(libxl_ctx *ctx,
libxl_domain_config *d_config,
{
unset_disk_colo_restore(d_config);
return do_domain_create(ctx, d_config, domid, -1, -1, NULL, NULL,
-ao_how, aop_console_how);
+false, ao_how, aop_console_how);
}
int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
@@ -1832,16 +1834,19 @@ int libxl_domain_create_restore(libxl_ctx *ctx,
libxl_domain_config *d_config,
const libxl_asyncprogress_how *aop_console_how)
{
char *colo_proxy_script = NULL;
+bool userspace_colo_proxy = false;
if (params->checkpointed_stream == LIBXL_CHECKPOINTED_STREAM_COLO) {
colo_proxy_script = params->colo_proxy_script;
+userspace_colo_proxy = libxl_defbool_val(params->userspace_colo_proxy);
set_disk_colo_restore(d_config);
} else {
unset_disk_colo_restore(d_config);
}
return do_domain_create(ctx, d_config, domid, restore_fd, send_back_fd,
-params, colo_proxy_script, ao_how,
aop_console_how);
+params, colo_proxy_script, userspace_colo_proxy,
+ao_how, aop_console_how);
}
int libxl_domain_soft_reset(libxl_ctx *ctx,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 1bd2057..89c2c9d 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -390,6 +390,7 @@ libxl_domain_restore_params =
Struct("domain_restore_params", [
("checkpointed_stream", integer),
("stream_version", uint32, {'init_val': '1'}),
("colo_proxy_script", string),
+("userspace_colo_proxy", libxl_defbool),
])
libxl_sched_params = Struct("sched_params",[
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 905c5f6..1620bd7 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -162,6 +162,7 @@ struct domain_create {
char *extra_config; /* extra config string */
const char *restore_file;
char *colo_proxy_script;
+bool userspace_colo_proxy;
int migrate_fd; /* -1 means none */
int send_back_fd; /* -1 means none */
char **migration_domname_r; /* from malloc */
@@ -3024,6 +3025,8 @@ start:
params.stream_version =
(hdr.mandatory_flags & XL_MANDATORY_FLAG_STREAMv2) ? 2 : 1;
params.colo_proxy_script = dom_info->colo_proxy_script;
+libxl_defbool_set(¶ms.userspace_colo_proxy,
+ dom_info->userspace_colo_proxy);
ret = libxl_domain_create_restore(ctx, &d_config,
&domid, restore_fd,
@@ -4824,7 +4827,
[Xen-devel] [PATCH RFC 6/6] COLO-Proxy: Use socket to get checkpoint event.
We use old kernel colo proxy way to get the checkpoint event from qemu.
This patch have some TODO job.
Qemu compare need add a API to support this(I will add this in qemu).
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_colo.h | 2 ++
tools/libxl/libxl_colo_proxy.c | 12
tools/libxl/libxl_nic.c| 8
tools/libxl/libxl_types.idl| 4 +++-
tools/libxl/xl_cmdimpl.c | 4
5 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_colo.h b/tools/libxl/libxl_colo.h
index 4746d8c..6c01b55 100644
--- a/tools/libxl/libxl_colo.h
+++ b/tools/libxl/libxl_colo.h
@@ -69,6 +69,8 @@ struct libxl__colo_proxy_state {
* False means use kernel colo proxy.
*/
bool is_userspace_proxy;
+const char *checkpoint_host;
+const char *checkpoint_port;
};
struct libxl__colo_save_state {
diff --git a/tools/libxl/libxl_colo_proxy.c b/tools/libxl/libxl_colo_proxy.c
index 348484d..a3c05f7 100644
--- a/tools/libxl/libxl_colo_proxy.c
+++ b/tools/libxl/libxl_colo_proxy.c
@@ -153,6 +153,11 @@ int colo_proxy_setup(libxl__colo_proxy_state *cps)
STATE_AO_GC(cps->ao);
if (cps->is_userspace_proxy) {
+/*
+ * TODO: Get userspace colo proxy checkpoint socket fd.
+ * use cps->checkpoint_host and cps->checkpoint_host.
+ */
+
/* If enable userspace proxy mode, we don't need setup kernel proxy */
return 0;
}
@@ -231,6 +236,8 @@ void colo_proxy_teardown(libxl__colo_proxy_state *cps)
/*
* If enable userspace proxy mode,
* we don't need teardown kernel proxy
+ *
+ * TODO: close userspace colo proxy sock fd.
*/
return;
}
@@ -286,6 +293,11 @@ int colo_proxy_checkpoint(libxl__colo_proxy_state *cps,
* then we will add qemu API support this func.
*/
if (cps->is_userspace_proxy) {
+/*
+ * TODO:
+ * colo_userspace_proxy_recv(cps, &buff, timeout_us);
+ * to get checkpoint event.
+ */
sleep(timeout_us / 100);
return 0;
}
diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
index 08e749f..fb5dfdb 100644
--- a/tools/libxl/libxl_nic.c
+++ b/tools/libxl/libxl_nic.c
@@ -646,6 +646,14 @@ static int libxl__device_nic_from_xenstore(libxl__gc *gc,
GCSPRINTF("%s/filter_sec_rewriter0_queue",
libxl_path),
(const char
**)(&nic->filter_sec_rewriter0_queue));
if (rc) goto out;
+rc = libxl__xs_read_checked(NOGC, XBT_NULL,
+GCSPRINTF("%s/colo_checkpoint_host",
libxl_path),
+(const char **)(&nic->colo_checkpoint_host));
+if (rc) goto out;
+rc = libxl__xs_read_checked(NOGC, XBT_NULL,
+GCSPRINTF("%s/colo_checkpoint_port",
libxl_path),
+(const char **)(&nic->colo_checkpoint_port));
+if (rc) goto out;
/* vif_ioemu nics use the same xenstore entries as vif interfaces */
rc = libxl__xs_read_checked(gc, XBT_NULL,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 9063ca9..41e7d38 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -671,7 +671,9 @@ libxl_device_nic = Struct("device_nic", [
("filter_sec_redirector1_queue", string),
("filter_sec_redirector1_indev", string),
("filter_sec_redirector1_outdev", string),
-("filter_sec_rewriter0_queue", string)
+("filter_sec_rewriter0_queue", string),
+("colo_checkpoint_host", string),
+("colo_checkpoint_port", string)
])
libxl_device_pci = Struct("device_pci", [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index e587ab3..53ab561 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1144,6 +1144,10 @@ static int parse_nic_config(libxl_device_nic *nic,
XLU_Config **config, char *to
replace_string(&nic->filter_sec_redirector1_outdev, oparg);
} else if (MATCH_OPTION("filter_sec_rewriter0_queue", token, oparg)) {
replace_string(&nic->filter_sec_rewriter0_queue, oparg);
+} else if (MATCH_OPTION("colo_checkpoint_host", token, oparg)) {
+replace_string(&nic->colo_checkpoint_host, oparg);
+} else if (MATCH_OPTION("colo_checkpoint_port", token, oparg)) {
+replace_string(&nic->colo_checkpoint_port, oparg);
} else if (MATCH_OPTION("accel", token, oparg)) {
fprintf(stderr, "the accel parameter for vifs is currently not
supported\n");
} else {
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 5/6] COLO-Proxy: Add secondary userspace colo-proxy start args
Qemu need this args to start userspace colo-proxy.
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_dm.c | 45 +++
tools/libxl/libxl_nic.c | 66 +
tools/libxl/libxl_types.idl | 15 ++-
tools/libxl/xl_cmdimpl.c| 26 ++
4 files changed, 151 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index b3484df..3641044 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1248,6 +1248,51 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
/* Userspace COLO Proxy need this */
if (state->saved_state) {
/* secondary colo run */
+if (nics[i].sock_sec_redirector0_id &&
+nics[i].sock_sec_redirector0_ip &&
+nics[i].sock_sec_redirector0_port) {
+flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args,
+
GCSPRINTF("socket,id=%s,host=%s,port=%s,reconnect=1",
+ nics[i].sock_sec_redirector0_id,
+ nics[i].sock_sec_redirector0_ip,
+ nics[i].sock_sec_redirector0_port));
+}
+if (nics[i].sock_sec_redirector1_id &&
+nics[i].sock_sec_redirector1_ip &&
+nics[i].sock_sec_redirector1_port) {
+flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args,
+
GCSPRINTF("socket,id=%s,host=%s,port=%s,reconnect=1",
+ nics[i].sock_sec_redirector1_id,
+ nics[i].sock_sec_redirector1_ip,
+ nics[i].sock_sec_redirector1_port));
+}
+if (nics[i].filter_sec_redirector0_queue &&
+nics[i].filter_sec_redirector0_indev) {
+flexarray_append(dm_args, "-object");
+flexarray_append(dm_args,
+
GCSPRINTF("filter-redirector,id=rs1,netdev=net%d,queue=%s,indev=%s",
+ nics[i].devid,
+ nics[i].filter_sec_redirector0_queue,
+ nics[i].filter_sec_redirector0_indev));
+}
+if (nics[i].filter_sec_redirector1_queue &&
+nics[i].filter_sec_redirector1_indev) {
+flexarray_append(dm_args, "-object");
+flexarray_append(dm_args,
+
GCSPRINTF("filter-redirector,id=rs2,netdev=net%d,queue=%s,outdev=%s",
+ nics[i].devid,
+ nics[i].filter_sec_redirector1_queue,
+ nics[i].filter_sec_redirector1_outdev));
+}
+if (nics[i].filter_sec_rewriter0_queue) {
+flexarray_append(dm_args, "-object");
+flexarray_append(dm_args,
+
GCSPRINTF("filter-rewriter,id=rs3,netdev=net%d,queue=%s",
+ nics[i].devid,
+ nics[i].filter_sec_rewriter0_queue));
+}
} else {
/* primary colo run */
if (nics[i].sock_mirror_id &&
diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
index b7a3596..08e749f 100644
--- a/tools/libxl/libxl_nic.c
+++ b/tools/libxl/libxl_nic.c
@@ -313,6 +313,19 @@ static void libxl__device_nic_add(libxl__egc *egc,
uint32_t domid,
flexarray_append(back, nic->colo_compare_out);
}
+if (nic->sock_sec_redirector0_id) {
+flexarray_append(back, "sock_redirector0_id");
+flexarray_append(back, nic->sock_redirector0_id);
+}
+if (nic->sock_sec_redirector0_ip) {
+flexarray_append(back, "sock_redirector0_ip");
+flexarray_append(back, nic->sock_redirector0_ip);
+}
+if (nic->sock_sec_redirector0_port) {
+flexarray_append(back, "sock_redirector0_port");
+flexarray_append(back, nic->sock_redirector0_port);
+}
+
flexarray_append(back, "mac");
flexarray_append(back,GCSPRINTF(LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
if (nic->ip) {
@@ -580,6 +593,59 @@ static int libxl__device_nic_from_xenstore(libxl__gc *gc,
rc = libxl__xs_read_checked(NOGC, XBT_NULL,
GCSPRINTF("%s/colo_compare_out", libxl_path),
(const char **)(&nic->colo_compare_out));
+if (rc) goto out;
+rc = libxl__xs_read_checked(NOGC, XBT_NULL,
+
[Xen-devel] [qemu-upstream-4.3-testing baseline-only test] 68460: tolerable FAIL
This run is configured for baseline tests only. flight 68460 qemu-upstream-4.3-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68460/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail baseline untested test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: qemuu22f4cb04e3660b6be75ee9b6a4a8f8cfe8f8070f jobs: 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 pass test-amd64-i386-xl pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpupass test-amd64-amd64-pairpass test-amd64-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-amd64-pvgrubpass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2pass test-amd64-i386-xl-raw pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-libvirt-vhd pass test-amd64-amd64-xl-qemuu-winxpsp3 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 broken-step build-amd64-pvops host-install(3) broken-step build-amd64 host-install(3) Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 104688: regressions - trouble: blocked/broken/fail
flight 104688 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104688/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z1 days Failing since104642 2017-01-25 10:01:54 Z0 days 18 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days 15 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 104662: tolerable FAIL - PUSHED
flight 104662 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104662/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104643 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104643 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104643 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104643 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 104643 test-amd64-amd64-xl-rtds 9 debian-install fail like 104643 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass version targeted for testing: qemuuc7f1cf01b8245762ca5864e835d84f6677ae8b1f baseline version: qemuud264871209400fa22796d403c9e1ab288d4a5c6b Last test of basis 104643 2017-01-25 11:15:48 Z0 days Testing same since 104662 2017-01-25 20:13:58 Z0 days1 attempts People who touched revisions under test: Alistair Francis Cao jin Chris Wulff Frediano Ziglio Gerd Hoffmann Greg Kurz Jan Kiszka Marc-André Lureau Marek Vasut Max Filippov Michael Tokarev Michael Walle Paolo Bonzini Peter Maydell Po-Hsu Lin Richard Henderson Samuel Thibault Samuel Thibault Stefan Weil Thomas Huth Ziyue Yang Ziyue Yang jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-
[Xen-devel] [xen-unstable-smoke test] 104682: regressions - trouble: blocked/broken/fail
flight 104682 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104682/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z1 days Failing since104642 2017-01-25 10:01:54 Z0 days 17 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days 14 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 104654: regressions - FAIL
flight 104654 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104654/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm 4 host-build-prep fail in 104638 REGR. vs. 104614 Tests which are failing intermittently (not blocking): test-amd64-amd64-rumprun-amd64 3 host-install(3) broken in 104632 pass in 104654 test-amd64-amd64-i386-pvgrub 3 host-install(3) broken in 104632 pass in 104654 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 104632 pass in 104654 test-amd64-amd64-xl-qcow29 debian-di-install fail in 104632 pass in 104654 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail in 104638 pass in 104654 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail pass in 104632 test-armhf-armhf-libvirt 15 guest-start/debian.repeat fail pass in 104638 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104614 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104614 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104614 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104614 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 104614 test-amd64-amd64-xl-rtds 9 debian-install fail like 104614 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104614 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104614 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked in 104638 n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked in 104638 n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12
[Xen-devel] [xen-unstable-smoke test] 104679: regressions - trouble: blocked/broken/fail
flight 104679 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104679/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z1 days Failing since104642 2017-01-25 10:01:54 Z0 days 16 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days 13 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 68462: all pass
This run is configured for baseline tests only. flight 68462 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68462/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 5734d486b6aa0b69a39b2c8d52b355400bcf2551 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 broken-step build-i386 host-install(3) broken-step build-amd64 host-install(3) broken-step build-i386-pvops host-install(3) broken-step build-i386-xsm host-install(3) broken-step build-amd64-pvops host-install(3) broken-step build-amd64-xsm host-install(3) Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 104676: regressions - trouble: blocked/broken/fail
flight 104676 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104676/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z1 days Failing since104642 2017-01-25 10:01:54 Z0 days 15 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days 12 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 104673: regressions - trouble: blocked/broken/fail
flight 104673 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104673/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z1 days Failing since104642 2017-01-25 10:01:54 Z0 days 14 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days 11 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: credit2: clear bit instead of skip step in runq_tickle()
On Wed, 2017-01-18 at 03:30 -0700, Jan Beulich wrote: > > > > On 18.01.17 at 11:21, wrote: > > On 18/01/17 00:30, Dario Faggioli wrote: > > > index ef8e0d8..d086264 100644 > > > --- a/xen/common/sched_credit2.c > > > +++ b/xen/common/sched_credit2.c > > > @@ -985,7 +985,7 @@ runq_tickle(const struct scheduler *ops, > > > struct csched2_vcpu *new, s_time_t now) > > > cpumask_andnot(&mask, &rqd->active, &rqd->idle); > > > cpumask_andnot(&mask, &mask, &rqd->tickled); > > > cpumask_and(&mask, &mask, new->vcpu->cpu_hard_affinity); > > > -if ( cpumask_test_cpu(cpu, &mask) ) > > > +if ( __cpumask_test_and_clear_cpu(cpu, &mask) ) > > > > Since we're micro-optimizing -- isn't test-and-clear a locked > > operation? > > Would that be more expensive than the if() statement below? > > cpumask_test_and_clear_cpu() is, but __cpumask_test_and_clear_cpu() > isn't. > George, ping? Thanks and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 9/9] xen/tools: tracing: always report how long next slice will be.
In fact, it is quite useful a pice of information,
to know how long it is the "next time slice" a vCPU
has been granted. It allows one to assume (and then
check) when the scheduler is supposed to run next,
and other things.
While this information is indeed reported when a
context switch happens, it is not when the same vCPU
that is running, continues to run.
Fix that, with the following outcome.
Before this change:
csched2:schedule cpu 9, rq# 1, idle, SMT idle, tickled
csched2:runq_candidate d0v3, 0 vcpus skipped, cpu 9 was tickled
sched_switch prev d32767v9, run for 991.186us
sched_switch next d0v3, was runnable for 2.515us, next slice 1.0us
sched_switch prev d32767v9 next d0v3
runstate_change d32767v9 running->runnable
...
csched2:schedule cpu 2, rq# 0, busy, not tickled
csched2:burn_credits d1v5, credit = 9996950, delta = 502913
csched2:runq_candidate d1v5, 0 vcpus skipped, no cpu was tickled
runstate_continue d1v5 running->running
?
That is, in the second block, it is shown that d1v5
was already running and will continue to do so,
but we have no idea for how long.
OTOH, after the change:
csched2:schedule cpu 1, rq# 0, busy, not tickled
csched2:burn_credits d0v8, credit = 9998645, delta = 12104
csched2:runq_candidate d0v8, credit = 9998645, 0 vcpus skipped, no cpu was
tickled
sched_switch continue d0v8, run for 1125.820us, next slice 9998.645us
runstate_continue d0v8 running->running ^
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
tools/xentrace/formats |1 +
tools/xentrace/xenalyze.c | 17 +
xen/common/schedule.c |4
xen/include/public/trace.h |1 +
4 files changed, 23 insertions(+)
diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 72c0b24..a055231 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -35,6 +35,7 @@
0x0002800e CPU%(cpu)d %(tsc)d (+%(reltsc)8d) switch_infprev[ dom:vcpu =
0x%(1)04x%(2)04x, runtime = %(3)d ]
0x0002800f CPU%(cpu)d %(tsc)d (+%(reltsc)8d) switch_infnext[
new_dom:vcpu = 0x%(1)04x%(2)04x, time = %(3)d, r_time = %(4)d ]
0x00028010 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) domain_shutdown_code [
dom:vcpu = 0x%(1)04x%(2)04x, reason = 0x%(3)08x ]
+0x00028011 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) switch_infcont[ dom:vcpu =
0x%(1)04x%(2)04x, runtime = %(3)d, r_time = %(4)d ]
0x00022001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) csched:sched_tasklet
0x00022002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) csched:account_start [
dom:vcpu = 0x%(1)04x%(2)04x, active = %(3)d ]
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 2678e2a..68ffcc2 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7528,6 +7528,23 @@ void sched_process(struct pcpu_info *p)
printf("\n");
}
break;
+case TRC_SCHED_SWITCH_INFCONT:
+if(opt.dump_all)
+{
+struct {
+unsigned int domid, vcpuid, rsince;
+int slice;
+} *r = (typeof(r))ri->d;
+
+printf(" %s sched_switch continue d%uv%u, run for %u.%uus",
+ ri->dump_header, r->domid, r->vcpuid,
+ r->rsince / 1000, r->rsince % 1000);
+if ( r->slice > 0 )
+printf(", next slice %u.%uus", r->slice / 1000,
+ r->slice % 1000);
+printf("\n");
+}
+break;
case TRC_SCHED_CTL:
case TRC_SCHED_S_TIMER_FN:
case TRC_SCHED_T_TIMER_FN:
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 43b5b99..3947f6c 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1398,6 +1398,10 @@ static void schedule(void)
if ( unlikely(prev == next) )
{
pcpu_schedule_unlock_irq(lock, cpu);
+TRACE_4D(TRC_SCHED_SWITCH_INFCONT,
+ next->domain->domain_id, next->vcpu_id,
+ now - prev->runstate.state_entry_time,
+ next_slice.time);
trace_continue_running(next);
return continue_running(prev);
}
diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h
index 5ef9c37..7f2e891 100644
--- a/xen/include/public/trace.h
+++ b/xen/include/public/trace.h
@@ -115,6 +115,7 @@
#define TRC_SCHED_SWITCH_INFPREV (TRC_SCHED_VERBOSE + 14)
#define TRC_SCHED_SWITCH_INFNEXT (TRC_SCHED_VERBOSE + 15)
#define TRC_SCHED_SHUTDOWN_CODE (TRC_SCHED_VERBOSE + 16)
+#define TRC_SCHED_SWITCH_INFCONT (TRC_SCHED_VERBOSE + 17)
#define TRC_DOM0_DOM_ADD (TRC_DOM0_DOMOPS + 1)
#define TRC_DOM0_DOM_REM (TRC_DOM0_DOMOPS + 2)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 8/9] xen/tools: tracing: trace (Credit2) runq traversal.
When traversing a Credit2 runqueue to select the
best candidate vCPU to be run next, show in the
trace which vCPUs we consider.
A bit verbose, but quite useful, considering that
we may end up looking at, but then discarding, one
of more vCPU. This will help understand which ones
are skipped and why.
Also, add how much credits the chosen vCPU has
(in the TRC_CSCHED2_RUNQ_CANDIDATE record). And,
while there, fix a bug in tools/xentrace/formats
(still in the output of TRC_CSCHED2_RUNQ_CANDIDATE).
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
tools/xentrace/formats |3 ++-
tools/xentrace/xenalyze.c | 15 +--
xen/common/sched_credit2.c | 15 +++
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index db89f92..72c0b24 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -65,9 +65,10 @@
0x00022210 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) csched2:load_check [
lrq_id[16]:orq_id[16] = 0x%(1)08x, delta = %(2)d ]
0x00022211 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) csched2:load_balance [
l_bavgload = 0x%(2)08x%(1)08x, o_bavgload = 0x%(4)08x%(3)08x,
lrq_id[16]:orq_id[16] = 0x%(5)08x ]
0x00022212 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) csched2:pick_cpu [
b_avgload = 0x%(2)08x%(1)08x, dom:vcpu = 0x%(3)08x, rq_id[16]:new_cpu[16] =
%(4)d ]
-0x00022213 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) csched2:runq_candidate [
dom:vcpu = 0x%(1)08x, skipped_vcpus = %(2)d tickled_cpu = %(3)d ]
+0x00022213 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) csched2:runq_candidate [
dom:vcpu = 0x%(1)08x, credit = %(4)d, skipped_vcpus = %(3)d, tickled_cpu =
%(2)d ]
0x00022214 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) csched2:schedule [
rq:cpu = 0x%(1)08x, tasklet[8]:idle[8]:smt_idle[8]:tickled[8] = %(2)08x ]
0x00022215 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) csched2:ratelimit [
dom:vcpu = 0x%(1)08x, runtime = %(2)d ]
+0x00022216 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) csched2:runq_cand_chk [
dom:vcpu = 0x%(1)08x ]
0x00022801 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) rtds:tickle[ cpu =
%(1)d ]
0x00022802 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) rtds:runq_pick [ dom:vcpu
= 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 0x%(5)08x%(4)08x ]
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index a90da20..2678e2a 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7825,12 +7825,13 @@ void sched_process(struct pcpu_info *p)
struct {
unsigned vcpuid:16, domid:16;
unsigned tickled_cpu, skipped;
+int credit;
} *r = (typeof(r))ri->d;
-printf(" %s csched2:runq_candidate d%uv%u, "
+printf(" %s csched2:runq_candidate d%uv%u, credit = %d, "
"%u vcpus skipped, ",
ri->dump_header, r->domid, r->vcpuid,
- r->skipped);
+ r->credit, r->skipped);
if (r->tickled_cpu == (unsigned)-1)
printf("no cpu was tickled\n");
else
@@ -7864,6 +7865,16 @@ void sched_process(struct pcpu_info *p)
r->runtime / 1000, r->runtime % 1000);
}
break;
+case TRC_SCHED_CLASS_EVT(CSCHED2, 23): /* RUNQ_CAND_CHECK */
+if(opt.dump_all) {
+struct {
+unsigned int vcpuid:16, domid:16;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched2:runq_cand_check d%uv%u\n",
+ ri->dump_header, r->domid, r->vcpuid);
+}
+break;
/* RTDS (TRC_RTDS_xxx) */
case TRC_SCHED_CLASS_EVT(RTDS, 1): /* TICKLE */
if(opt.dump_all) {
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 43db669..81149cf 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -57,6 +57,7 @@
#define TRC_CSCHED2_RUNQ_CANDIDATE TRC_SCHED_CLASS_EVT(CSCHED2, 20)
#define TRC_CSCHED2_SCHEDULE TRC_SCHED_CLASS_EVT(CSCHED2, 21)
#define TRC_CSCHED2_RATELIMITTRC_SCHED_CLASS_EVT(CSCHED2, 22)
+#define TRC_CSCHED2_RUNQ_CAND_CHECK TRC_SCHED_CLASS_EVT(CSCHED2, 23)
/*
* WARNING: This is still in an experimental phase. Status and work can be
found at the
@@ -2497,6 +2498,18 @@ runq_candidate(struct csched2_runqueue_data *rqd,
{
struct csched2_vcpu * svc = list_entry(iter, struct csched2_vcpu,
runq_elem);
+if ( unlikely(tb_init_done) )
+{
+struct {
+unsigned vcpu:16, dom:16;
+} d;
+d.dom = svc->vcpu->domain->domain_id;
+d.vcpu = svc->vcpu->vcpu_id;
+__trace_var(TRC_CSCHED2_RUNQ_CAND_CHECK, 1,
+sizeof(d),
+(unsigned char *)&d);
+}
+
/* Only conside
[Xen-devel] [PATCH 6/9] xen: credit2: don't miss accounting while doing a credit reset.
A credit reset basically means going through all the
vCPUs of a runqueue and altering their credits, as a
consequence of a 'scheduling epoch' having come to an
end.
Blocked or runnable vCPUs are fine, all the credits
they've spent running so far have been accounted to
them when they were scheduled out.
But if a vCPU is running on a pCPU, when a reset event
occurs (on another pCPU), that does not get properly
accounted. Let's therefore begin to do so, for better
accuracy and fairness.
In fact, after this patch, we see this in a trace:
csched2:schedule cpu 10, rq# 1, busy, not tickled
csched2:burn_credits d1v5, credit = 9998353, delta = 202996
runstate_continue d1v5 running->running
...
csched2:schedule cpu 12, rq# 1, busy, not tickled
csched2:burn_credits d1v6, credit = -1327, delta = 544
csched2:reset_credits d0v13, credit_start = 1050, credit_end = 1050,
mult = 1
csched2:reset_credits d0v14, credit_start = 1050, credit_end = 1050,
mult = 1
csched2:reset_credits d0v7, credit_start = 1050, credit_end = 1050,
mult = 1
csched2:burn_credits d1v5, credit = 201805, delta = 9796548
csched2:reset_credits d1v5, credit_start = 201805, credit_end = 10201805, mult
= 1
csched2:burn_credits d1v6, credit = -1327, delta = 0
csched2:reset_credits d1v6, credit_start = -1327, credit_end = 9998673, mult =
1
Which shows how d1v5 actually executed for ~9.796 ms,
on pCPU 10, when reset_credit() is executed, on pCPU
12, because of d1v6's credits going below 0.
Without this patch, this 9.796ms are not accounted
to anyone. With this patch, d1v5 is charged for that,
and its credits drop down from 9796548 to 201805.
And this is important, as it means that it will
begin the new epoch with 10201805 credits, instead
of 1050 (which he would have, before this patch).
Basically, we were forgetting one round of accounting
in epoch x, for the vCPUs that are running at the time
the epoch ends. And this meant favouring a little bit
these same vCPUs, in epoch x+1, providing them with
the chance of execute longer than their fair share.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
---
xen/common/sched_credit2.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index bab9667..07e0a6d 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1341,18 +1341,28 @@ static void reset_credit(const struct scheduler *ops,
int cpu, s_time_t now,
list_for_each( iter, &rqd->svc )
{
+unsigned int svc_cpu;
struct csched2_vcpu * svc;
int start_credit;
svc = list_entry(iter, struct csched2_vcpu, rqd_elem);
+svc_cpu = svc->vcpu->processor;
ASSERT(!is_idle_vcpu(svc->vcpu));
ASSERT(svc->rqd == rqd);
+/*
+ * If svc is running, it is our responsibility to make sure, here,
+ * that the credit it has spent so far get accounted.
+ */
+if ( svc->vcpu == curr_on_cpu(svc_cpu) )
+burn_credits(rqd, svc, now);
+
start_credit = svc->credit;
-/* And add INIT * m, avoiding integer multiplication in the
- * common case. */
+/*
+ * Add INIT * m, avoiding integer multiplication in the common case.
+ */
if ( likely(m==1) )
svc->credit += CSCHED2_CREDIT_INIT;
else
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/9] xen: credit2: group the runq manipulating functions.
So that they're all close among each other, and
also near to the comment describind the runqueue
organization (which is also moved).
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
---
xen/common/sched_credit2.c | 572 ++--
1 file changed, 286 insertions(+), 286 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index b764cf9..f4c0ae4 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -295,63 +295,6 @@ static int __read_mostly opt_overload_balance_tolerance =
-3;
integer_param("credit2_balance_over", opt_overload_balance_tolerance);
/*
- * Runqueue organization.
- *
- * The various cpus are to be assigned each one to a runqueue, and we
- * want that to happen basing on topology. At the moment, it is possible
- * to choose to arrange runqueues to be:
- *
- * - per-core: meaning that there will be one runqueue per each physical
- * core of the host. This will happen if the opt_runqueue
- * parameter is set to 'core';
- *
- * - per-socket: meaning that there will be one runqueue per each physical
- * socket (AKA package, which often, but not always, also
- * matches a NUMA node) of the host; This will happen if
- * the opt_runqueue parameter is set to 'socket';
- *
- * - per-node: meaning that there will be one runqueue per each physical
- * NUMA node of the host. This will happen if the opt_runqueue
- * parameter is set to 'node';
- *
- * - global: meaning that there will be only one runqueue to which all the
- * (logical) processors of the host belong. This will happen if
- * the opt_runqueue parameter is set to 'all'.
- *
- * Depending on the value of opt_runqueue, therefore, cpus that are part of
- * either the same physical core, the same physical socket, the same NUMA
- * node, or just all of them, will be put together to form runqueues.
- */
-#define OPT_RUNQUEUE_CORE 0
-#define OPT_RUNQUEUE_SOCKET 1
-#define OPT_RUNQUEUE_NODE 2
-#define OPT_RUNQUEUE_ALL3
-static const char *const opt_runqueue_str[] = {
-[OPT_RUNQUEUE_CORE] = "core",
-[OPT_RUNQUEUE_SOCKET] = "socket",
-[OPT_RUNQUEUE_NODE] = "node",
-[OPT_RUNQUEUE_ALL] = "all"
-};
-static int __read_mostly opt_runqueue = OPT_RUNQUEUE_SOCKET;
-
-static void parse_credit2_runqueue(const char *s)
-{
-unsigned int i;
-
-for ( i = 0; i < ARRAY_SIZE(opt_runqueue_str); i++ )
-{
-if ( !strcmp(s, opt_runqueue_str[i]) )
-{
-opt_runqueue = i;
-return;
-}
-}
-
-printk("WARNING, unrecognized value of credit2_runqueue option!\n");
-}
-custom_param("credit2_runqueue", parse_credit2_runqueue);
-
-/*
* Per-runqueue data
*/
struct csched2_runqueue_data {
@@ -563,45 +506,304 @@ static int get_fallback_cpu(struct csched2_vcpu *svc)
return cpumask_first(cpumask_scratch_cpu(cpu));
}
-ASSERT(!cpumask_empty(cpumask_scratch_cpu(cpu)));
-
-return cpumask_first(cpumask_scratch_cpu(cpu));
+ASSERT(!cpumask_empty(cpumask_scratch_cpu(cpu)));
+
+return cpumask_first(cpumask_scratch_cpu(cpu));
+}
+
+/*
+ * Time-to-credit, credit-to-time.
+ *
+ * We keep track of the "residual" time to make sure that frequent short
+ * schedules still get accounted for in the end.
+ *
+ * FIXME: Do pre-calculated division?
+ */
+static void t2c_update(struct csched2_runqueue_data *rqd, s_time_t time,
+ struct csched2_vcpu *svc)
+{
+uint64_t val = time * rqd->max_weight + svc->residual;
+
+svc->residual = do_div(val, svc->weight);
+svc->credit -= val;
+}
+
+static s_time_t c2t(struct csched2_runqueue_data *rqd, s_time_t credit, struct
csched2_vcpu *svc)
+{
+return credit * svc->weight / rqd->max_weight;
+}
+
+/*
+ * Runqueue related code.
+ */
+
+/*
+ * Runqueue organization.
+ *
+ * The various cpus are to be assigned each one to a runqueue, and we
+ * want that to happen basing on topology. At the moment, it is possible
+ * to choose to arrange runqueues to be:
+ *
+ * - per-core: meaning that there will be one runqueue per each physical
+ * core of the host. This will happen if the opt_runqueue
+ * parameter is set to 'core';
+ *
+ * - per-socket: meaning that there will be one runqueue per each physical
+ * socket (AKA package, which often, but not always, also
+ * matches a NUMA node) of the host; This will happen if
+ * the opt_runqueue parameter is set to 'socket';
+ *
+ * - per-node: meaning that there will be one runqueue per each physical
+ * NUMA node of the host. This will happen if the opt_runqueue
+ * parameter is set to 'node';
+ *
+ * - global: meaning that there will be only one runqueue to which all the
+ * (logical) processors of the host belong. This w
[Xen-devel] [PATCH 7/9] xen/tools: tracing: credits can go negative, so use int.
For Credit2, in both the trace records, inside Xen,
and in their parsing, in xenalyze.
In fact, it is a lot easier to figure out how much
negative credits have gone for a certain vCPU by
looking at a negative integer, rather than to an
overflowed unsigned.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
tools/xentrace/xenalyze.c | 20 ++--
xen/common/sched_credit2.c | 10 +-
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index f006804..a90da20 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7651,11 +7651,11 @@ void sched_process(struct pcpu_info *p)
case TRC_SCHED_CLASS_EVT(CSCHED2, 3): /* CREDIT_BURN */
if(opt.dump_all) {
struct {
-unsigned int vcpuid:16, domid:16, credit;
-int delta;
+unsigned int vcpuid:16, domid:16;
+int credit, delta;
} *r = (typeof(r))ri->d;
-printf(" %s csched2:burn_credits d%uv%u, credit = %u, delta =
%d\n",
+printf(" %s csched2:burn_credits d%uv%u, credit = %d, delta =
%d\n",
ri->dump_header, r->domid, r->vcpuid,
r->credit, r->delta);
}
@@ -7664,10 +7664,10 @@ void sched_process(struct pcpu_info *p)
if(opt.dump_all) {
struct {
unsigned int vcpuid:16, domid:16;
-unsigned int credit;
+int credit;
} *r = (typeof(r))ri->d;
-printf(" %s csched2:tickle_check d%uv%u, credit = %u\n",
+printf(" %s csched2:tickle_check d%uv%u, credit = %d\n",
ri->dump_header, r->domid, r->vcpuid, r->credit);
}
break;
@@ -7685,12 +7685,12 @@ void sched_process(struct pcpu_info *p)
if(opt.dump_all) {
struct {
unsigned int vcpuid:16, domid:16;
-unsigned int credit_start, credit_end;
+int credit_start, credit_end;
unsigned int multiplier;
} *r = (typeof(r))ri->d;
printf(" %s csched2:reset_credits d%uv%u, "
- "credit_start = %u, credit_end = %u, mult = %u\n",
+ "credit_start = %d, credit_end = %d, mult = %u\n",
ri->dump_header, r->domid, r->vcpuid,
r->credit_start, r->credit_end, r->multiplier);
}
@@ -7752,12 +7752,12 @@ void sched_process(struct pcpu_info *p)
case TRC_SCHED_CLASS_EVT(CSCHED2, 13): /* TICKLE_NEW */
if (opt.dump_all) {
struct {
-unsigned vcpuid:16, domid:16;
-unsigned processor, credit;
+unsigned int vcpuid:16, domid:16, processor;
+int credit;
} *r = (typeof(r))ri->d;
printf(" %s csched2:runq_tickle_new d%uv%u, "
- "processor = %u, credit = %u\n",
+ "processor = %u, credit = %d\n",
ri->dump_header, r->domid, r->vcpuid,
r->processor, r->credit);
}
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 07e0a6d..43db669 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1165,7 +1165,8 @@ runq_tickle(const struct scheduler *ops, struct
csched2_vcpu *new, s_time_t now)
{
struct {
unsigned vcpu:16, dom:16;
-unsigned processor, credit;
+unsigned processor;
+int credit;
} d;
d.dom = new->vcpu->domain->domain_id;
d.vcpu = new->vcpu->vcpu_id;
@@ -1264,7 +1265,7 @@ runq_tickle(const struct scheduler *ops, struct
csched2_vcpu *new, s_time_t now)
{
struct {
unsigned vcpu:16, dom:16;
-unsigned credit;
+int credit;
} d;
d.dom = cur->vcpu->domain->domain_id;
d.vcpu = cur->vcpu->vcpu_id;
@@ -1378,7 +1379,7 @@ static void reset_credit(const struct scheduler *ops, int
cpu, s_time_t now,
{
struct {
unsigned vcpu:16, dom:16;
-unsigned credit_start, credit_end;
+int credit_start, credit_end;
unsigned multiplier;
} d;
d.dom = svc->vcpu->domain->domain_id;
@@ -1428,8 +1429,7 @@ void burn_credits(struct csched2_runqueue_data *rqd,
{
struct {
unsigned vcpu:16, dom:16;
-unsigned credit;
-int delta;
+int credit, delta;
} d;
d.dom = svc->vcpu->domain->domain_id;
d.vcpu = svc->vcpu->vcpu_id;
_
[Xen-devel] [PATCH 5/9] xen: credit2: always mark a tickled pCPU as... tickled!
In fact, whether or not a pCPU has been tickled, and is
therefore about to re-schedule, is something we look at
and base decisions on in various places.
So, let's make sure that we do that basing on accurate
information.
While there, also tweak a little bit smt_idle_mask_clear()
(used for implementing SMT support), so that it only alter
the relevant cpumask when there is the actual need for this.
(This is only for reduced overhead, behavior remains the
same).
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
---
xen/common/sched_credit2.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index f4c0ae4..bab9667 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -470,12 +470,15 @@ void smt_idle_mask_set(unsigned int cpu, const cpumask_t
*idlers,
}
/*
- * Clear the bits of all the siblings of cpu from mask.
+ * Clear the bits of all the siblings of cpu from mask (if necessary).
*/
static inline
void smt_idle_mask_clear(unsigned int cpu, cpumask_t *mask)
{
-cpumask_andnot(mask, mask, per_cpu(cpu_sibling_mask, cpu));
+const cpumask_t *cpu_siblings = per_cpu(cpu_sibling_mask, cpu);
+
+if ( cpumask_subset(cpu_siblings, mask) )
+cpumask_andnot(mask, mask, per_cpu(cpu_sibling_mask, cpu));
}
/*
@@ -1122,6 +1125,14 @@ static inline void runq_remove(struct csched2_vcpu *svc)
void burn_credits(struct csched2_runqueue_data *rqd, struct csched2_vcpu *,
s_time_t);
+static inline void
+tickle_cpu(unsigned int cpu, struct csched2_runqueue_data *rqd)
+{
+__cpumask_set_cpu(cpu, &rqd->tickled);
+smt_idle_mask_clear(cpu, &rqd->smt_idle);
+cpu_raise_softirq(cpu, SCHEDULE_SOFTIRQ);
+}
+
/*
* Check what processor it is best to 'wake', for picking up a vcpu that has
* just been put (back) in the runqueue. Logic is as follows:
@@ -1289,9 +1300,8 @@ runq_tickle(const struct scheduler *ops, struct
csched2_vcpu *new, s_time_t now)
sizeof(d),
(unsigned char *)&d);
}
-__cpumask_set_cpu(ipid, &rqd->tickled);
-smt_idle_mask_clear(ipid, &rqd->smt_idle);
-cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ);
+
+tickle_cpu(cpu, rqd);
if ( unlikely(new->tickled_cpu != -1) )
SCHED_STAT_CRANK(tickled_cpu_overwritten);
@@ -1494,7 +1504,9 @@ csched2_vcpu_sleep(const struct scheduler *ops, struct
vcpu *vc)
SCHED_STAT_CRANK(vcpu_sleep);
if ( curr_on_cpu(vc->processor) == vc )
-cpu_raise_softirq(vc->processor, SCHEDULE_SOFTIRQ);
+{
+tickle_cpu(vc->processor, svc->rqd);
+}
else if ( vcpu_on_runq(svc) )
{
ASSERT(svc->rqd == c2rqd(ops, vc->processor));
@@ -1817,8 +1829,8 @@ static void migrate(const struct scheduler *ops,
svc->migrate_rqd = trqd;
__set_bit(_VPF_migrating, &svc->vcpu->pause_flags);
__set_bit(__CSFLAG_runq_migrate_request, &svc->flags);
-cpu_raise_softirq(cpu, SCHEDULE_SOFTIRQ);
SCHED_STAT_CRANK(migrate_requested);
+tickle_cpu(cpu, svc->rqd);
}
else
{
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/9] xen: credit2: improve style, and tracing; fix two bugs
Hello, This series contains mostly style or cosmetic fixes for Credit2, with the following two exceptions: - 2 actual fixes for (not so severe) behavioral bugs (patches 5 and 6); - some tracing improvements (last 3 patches). More info on the specific changelogs. The series is also available as a git tree here: git://xenbits.xen.org/people/dariof/xen.git rel/sched/credit2-style-tracing-accounting https://travis-ci.org/fdario/xen/builds/195387018 Thanks and Regards, Dario --- Dario Faggioli (9): xen: credit2: improve comments' style and definition of CSFLAG-s xen: credit2: make accessor helpers inline functions instead of macros xen: credit2: tidy up functions names by removing leading '__'. xen: credit2: group the runq manipulating functions. xen: credit2: always mark a tickled pCPU as... tickled! xen: credit2: don't miss accounting while doing a credit reset. xen/tools: tracing: credits can go negative, so use int. xen/tools: tracing: trace (Credit2) runq traversal. xen/tools: tracing: always report how long next slice will be. tools/xentrace/formats |4 tools/xentrace/xenalyze.c | 52 ++- xen/common/sched_credit2.c | 903 +++- xen/common/schedule.c |4 xen/include/public/trace.h |1 5 files changed, 528 insertions(+), 436 deletions(-) -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/9] xen: credit2: make accessor helpers inline functions instead of macros
There isn't any particular reason for the accessor helpers
to be macro, so turn them into 'static inline'-s, which are
better.
Note that it is necessary to move the function definitions
below the structure declarations.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
---
xen/common/sched_credit2.c | 158 +---
1 file changed, 90 insertions(+), 68 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 322cf6b..29973cf 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -209,18 +209,6 @@ static unsigned int __read_mostly opt_migrate_resist = 500;
integer_param("sched_credit2_migrate_resist", opt_migrate_resist);
/*
- * Useful macros
- */
-#define CSCHED2_PRIV(_ops) \
-((struct csched2_private *)((_ops)->sched_data))
-#define CSCHED2_VCPU(_vcpu) ((struct csched2_vcpu *) (_vcpu)->sched_priv)
-#define CSCHED2_DOM(_dom)((struct csched2_dom *) (_dom)->sched_priv)
-/* CPU to runq_id macro */
-#define c2r(_ops, _cpu) (CSCHED2_PRIV(_ops)->runq_map[(_cpu)])
-/* CPU to runqueue struct macro */
-#define RQD(_ops, _cpu) (&CSCHED2_PRIV(_ops)->rqd[c2r(_ops, _cpu)])
-
-/*
* Load tracking and load balancing
*
* Load history of runqueues and vcpus is accounted for by using an
@@ -441,6 +429,40 @@ struct csched2_dom {
};
/*
+ * Accessor helpers functions.
+ */
+static always_inline
+struct csched2_private *csched2_priv(const struct scheduler *ops)
+{
+return ops->sched_data;
+}
+
+static always_inline
+struct csched2_vcpu *csched2_vcpu(struct vcpu *v)
+{
+return v->sched_priv;
+}
+
+static always_inline
+struct csched2_dom *csched2_dom(struct domain *d)
+{
+return d->sched_priv;
+}
+
+/* CPU to runq_id macro */
+static always_inline int c2r(const struct scheduler *ops, unsigned cpu)
+{
+return (csched2_priv(ops))->runq_map[(cpu)];
+}
+
+/* CPU to runqueue struct macro */
+static always_inline
+struct csched2_runqueue_data *c2rqd(const struct scheduler *ops, unsigned cpu)
+{
+return &csched2_priv(ops)->rqd[c2r(ops, cpu)];
+}
+
+/*
* Hyperthreading (SMT) support.
*
* We use a special per-runq mask (smt_idle) and update it according to the
@@ -694,7 +716,7 @@ static void
__update_runq_load(const struct scheduler *ops,
struct csched2_runqueue_data *rqd, int change, s_time_t now)
{
-struct csched2_private *prv = CSCHED2_PRIV(ops);
+struct csched2_private *prv = csched2_priv(ops);
s_time_t delta, load = rqd->load;
unsigned int P, W;
@@ -781,7 +803,7 @@ static void
__update_svc_load(const struct scheduler *ops,
struct csched2_vcpu *svc, int change, s_time_t now)
{
-struct csched2_private *prv = CSCHED2_PRIV(ops);
+struct csched2_private *prv = csched2_priv(ops);
s_time_t delta, vcpu_load;
unsigned int P, W;
@@ -878,7 +900,7 @@ static void
runq_insert(const struct scheduler *ops, struct csched2_vcpu *svc)
{
unsigned int cpu = svc->vcpu->processor;
-struct list_head * runq = &RQD(ops, cpu)->runq;
+struct list_head * runq = &c2rqd(ops, cpu)->runq;
int pos = 0;
ASSERT(spin_is_locked(per_cpu(schedule_data, cpu).schedule_lock));
@@ -936,7 +958,7 @@ runq_tickle(const struct scheduler *ops, struct
csched2_vcpu *new, s_time_t now)
int i, ipid = -1;
s_time_t lowest = (1<<30);
unsigned int cpu = new->vcpu->processor;
-struct csched2_runqueue_data *rqd = RQD(ops, cpu);
+struct csched2_runqueue_data *rqd = c2rqd(ops, cpu);
cpumask_t mask;
struct csched2_vcpu * cur;
@@ -1006,7 +1028,7 @@ runq_tickle(const struct scheduler *ops, struct
csched2_vcpu *new, s_time_t now)
cpumask_and(&mask, &mask, cpumask_scratch_cpu(cpu));
if ( cpumask_test_cpu(cpu, &mask) )
{
-cur = CSCHED2_VCPU(curr_on_cpu(cpu));
+cur = csched2_vcpu(curr_on_cpu(cpu));
burn_credits(rqd, cur, now);
if ( cur->credit < new->credit )
@@ -1023,7 +1045,7 @@ runq_tickle(const struct scheduler *ops, struct
csched2_vcpu *new, s_time_t now)
if ( i == cpu )
continue;
-cur = CSCHED2_VCPU(curr_on_cpu(i));
+cur = csched2_vcpu(curr_on_cpu(i));
/*
* Even if the cpu is not in rqd->idle, it may be running the
@@ -1096,7 +1118,7 @@ runq_tickle(const struct scheduler *ops, struct
csched2_vcpu *new, s_time_t now)
static void reset_credit(const struct scheduler *ops, int cpu, s_time_t now,
struct csched2_vcpu *snext)
{
-struct csched2_runqueue_data *rqd = RQD(ops, cpu);
+struct csched2_runqueue_data *rqd = c2rqd(ops, cpu);
struct list_head *iter;
int m;
@@ -1174,7 +1196,7 @@ void burn_credits(struct csched2_runqueue_data *rqd,
{
s_time_t delta;
-ASSERT(svc == CSCHED2_VCPU(curr_on_cpu(svc->vcpu->processor)));
+ASSERT(svc == csched2_vcpu(curr_on_cpu(svc->vcpu->processor)));
[Xen-devel] [PATCH 3/9] xen: credit2: tidy up functions names by removing leading '__'.
There is no reason for having pretty much all of the
functions whose names begin with double underscores
('__') to actually look like that.
In fact, that is misleading and makes the code hard
to read and understand. So, remove the '__'-s.
The only two that we keep are __runq_insert() and
__runq_assign() (althought they're converted to
single underscore). In fact, in those cases, it is
indeed useful to have those sort of a "raw" variants.
In case of __runq_insert(), which is only called
once, by runq_insert(), merge the two functions.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
---
xen/common/sched_credit2.c | 114 +++-
1 file changed, 49 insertions(+), 65 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 29973cf..b764cf9 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -221,7 +221,7 @@ integer_param("sched_credit2_migrate_resist",
opt_migrate_resist);
* shift all time samples to the right.
*
* The details of the formulas used for load tracking are explained close to
- * __update_runq_load(). Let's just say here that, with full nanosecond time
+ * update_runq_load(). Let's just say here that, with full nanosecond time
* granularity, a 30 bits wide 'decaying window' is ~1 second long.
*
* We want to consider the following equations:
@@ -233,7 +233,7 @@ integer_param("sched_credit2_migrate_resist",
opt_migrate_resist);
* Q-format fixed point arithmetic and load is the instantaneous load of a
* runqueue, which basically is the number of runnable vcpus there are on the
* runqueue (for the meaning of the other terms, look at the doc comment to
- * __update_runq_load()).
+ * update_runq_load()).
*
* So, again, with full nanosecond granularity, and 1 second window, we have:
*
@@ -594,14 +594,12 @@ static s_time_t c2t(struct csched2_runqueue_data *rqd,
s_time_t credit, struct c
* Runqueue related code
*/
-static /*inline*/ int
-__vcpu_on_runq(struct csched2_vcpu *svc)
+static inline int vcpu_on_runq(struct csched2_vcpu *svc)
{
return !list_empty(&svc->runq_elem);
}
-static /*inline*/ struct csched2_vcpu *
-__runq_elem(struct list_head *elem)
+static struct csched2_vcpu * runq_elem(struct list_head *elem)
{
return list_entry(elem, struct csched2_vcpu, runq_elem);
}
@@ -713,8 +711,8 @@ __runq_elem(struct list_head *elem)
* Which, in both cases, is what we expect.
*/
static void
-__update_runq_load(const struct scheduler *ops,
- struct csched2_runqueue_data *rqd, int change, s_time_t now)
+update_runq_load(const struct scheduler *ops,
+ struct csched2_runqueue_data *rqd, int change, s_time_t now)
{
struct csched2_private *prv = csched2_priv(ops);
s_time_t delta, load = rqd->load;
@@ -800,8 +798,8 @@ __update_runq_load(const struct scheduler *ops,
}
static void
-__update_svc_load(const struct scheduler *ops,
- struct csched2_vcpu *svc, int change, s_time_t now)
+update_svc_load(const struct scheduler *ops,
+struct csched2_vcpu *svc, int change, s_time_t now)
{
struct csched2_private *prv = csched2_priv(ops);
s_time_t delta, vcpu_load;
@@ -865,17 +863,24 @@ update_load(const struct scheduler *ops,
{
trace_var(TRC_CSCHED2_UPDATE_LOAD, 1, 0, NULL);
-__update_runq_load(ops, rqd, change, now);
+update_runq_load(ops, rqd, change, now);
if ( svc )
-__update_svc_load(ops, svc, change, now);
+update_svc_load(ops, svc, change, now);
}
-static int
-__runq_insert(struct list_head *runq, struct csched2_vcpu *svc)
+static void
+runq_insert(const struct scheduler *ops, struct csched2_vcpu *svc)
{
struct list_head *iter;
+unsigned int cpu = svc->vcpu->processor;
+struct list_head * runq = &c2rqd(ops, cpu)->runq;
int pos = 0;
+ASSERT(spin_is_locked(per_cpu(schedule_data, cpu).schedule_lock));
+
+ASSERT(!vcpu_on_runq(svc));
+ASSERT(c2r(ops, cpu) == c2r(ops, svc->vcpu->processor));
+
ASSERT(&svc->rqd->runq == runq);
ASSERT(!is_idle_vcpu(svc->vcpu));
ASSERT(!svc->vcpu->is_running);
@@ -883,33 +888,15 @@ __runq_insert(struct list_head *runq, struct csched2_vcpu
*svc)
list_for_each( iter, runq )
{
-struct csched2_vcpu * iter_svc = __runq_elem(iter);
+struct csched2_vcpu * iter_svc = runq_elem(iter);
if ( svc->credit > iter_svc->credit )
break;
pos++;
}
-
list_add_tail(&svc->runq_elem, iter);
-return pos;
-}
-
-static void
-runq_insert(const struct scheduler *ops, struct csched2_vcpu *svc)
-{
-unsigned int cpu = svc->vcpu->processor;
-struct list_head * runq = &c2rqd(ops, cpu)->runq;
-int pos = 0;
-
-ASSERT(spin_is_locked(per_cpu(schedule_data, cpu).schedule_lock));
-
-ASSERT(!__vcpu_on_runq(svc));
-ASSERT(c2r(ops, cpu) == c2r(ops, svc-
[Xen-devel] [PATCH 1/9] xen: credit2: improve comments' style and definition of CSFLAG-s
Most of the comments describing the meaning of the
vCPU flags used by the scheduler miss the 'wings' (or
have other minor style issues).
Also, use 1U (instead of 1) as the base of shiftings.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
---
xen/common/sched_credit2.c | 54
1 file changed, 34 insertions(+), 20 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 2ce738d..322cf6b 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -129,35 +129,47 @@
/*
* Basic constants
*/
-/* Default weight: How much a new domain starts with */
+/* Default weight: How much a new domain starts with. */
#define CSCHED2_DEFAULT_WEIGHT 256
-/* Min timer: Minimum length a timer will be set, to
- * achieve efficiency */
+/*
+ * Min timer: Minimum length a timer will be set, to
+ * achieve efficiency.
+ */
#define CSCHED2_MIN_TIMERMICROSECS(500)
-/* Amount of credit VMs begin with, and are reset to.
+/*
+ * Amount of credit VMs begin with, and are reset to.
* ATM, set so that highest-weight VMs can only run for 10ms
- * before a reset event. */
+ * before a reset event.
+ */
#define CSCHED2_CREDIT_INIT MILLISECS(10)
-/* Carryover: How much "extra" credit may be carried over after
- * a reset. */
+/*
+ * Amount of credit the idle vcpus have. It never changes, as idle
+ * vcpus does not consume credits, and it must be lower than whatever
+ * amount of credit 'regular' vcpu would end up with.
+ */
+#define CSCHED2_IDLE_CREDIT (-(1U<<30))
+/*
+ * Carryover: How much "extra" credit may be carried over after
+ * a reset.
+ */
#define CSCHED2_CARRYOVER_MAXCSCHED2_MIN_TIMER
-/* Stickiness: Cross-L2 migration resistance. Should be less than
- * MIN_TIMER. */
+/*
+ * Stickiness: Cross-L2 migration resistance. Should be less than
+ * MIN_TIMER.
+ */
#define CSCHED2_MIGRATE_RESIST ((opt_migrate_resist)*MICROSECS(1))
-/* How much to "compensate" a vcpu for L2 migration */
+/* How much to "compensate" a vcpu for L2 migration. */
#define CSCHED2_MIGRATE_COMPENSATION MICROSECS(50)
/* Reset: Value below which credit will be reset. */
#define CSCHED2_CREDIT_RESET 0
/* Max timer: Maximum time a guest can be run for. */
#define CSCHED2_MAX_TIMERCSCHED2_CREDIT_INIT
-
-#define CSCHED2_IDLE_CREDIT (-(1<<30))
-
/*
* Flags
*/
-/* CSFLAG_scheduled: Is this vcpu either running on, or context-switching off,
+/*
+ * CSFLAG_scheduled: Is this vcpu either running on, or context-switching off,
* a physical cpu?
* + Accessed only with runqueue lock held
* + Set when chosen as next in csched2_schedule().
@@ -167,8 +179,9 @@
* + Checked to be false in runq_insert.
*/
#define __CSFLAG_scheduled 1
-#define CSFLAG_scheduled (1<<__CSFLAG_scheduled)
-/* CSFLAG_delayed_runq_add: Do we need to add this to the runqueue once it'd
done
+#define CSFLAG_scheduled (1U<<__CSFLAG_scheduled)
+/*
+ * CSFLAG_delayed_runq_add: Do we need to add this to the runqueue once it'd
done
* being context switched out?
* + Set when scheduling out in csched2_schedule() if prev is runnable
* + Set in csched2_vcpu_wake if it finds CSFLAG_scheduled set
@@ -176,20 +189,21 @@
* clears the bit.
*/
#define __CSFLAG_delayed_runq_add 2
-#define CSFLAG_delayed_runq_add (1<<__CSFLAG_delayed_runq_add)
-/* CSFLAG_runq_migrate_request: This vcpu is being migrated as a result of a
+#define CSFLAG_delayed_runq_add (1U<<__CSFLAG_delayed_runq_add)
+/*
+ * CSFLAG_runq_migrate_request: This vcpu is being migrated as a result of a
* credit2-initiated runq migrate request; migrate it to the runqueue indicated
* in the svc struct.
*/
#define __CSFLAG_runq_migrate_request 3
-#define CSFLAG_runq_migrate_request (1<<__CSFLAG_runq_migrate_request)
+#define CSFLAG_runq_migrate_request (1U<<__CSFLAG_runq_migrate_request)
/*
* CSFLAG_vcpu_yield: this vcpu was running, and has called vcpu_yield(). The
* scheduler is invoked to see if we can give the cpu to someone else, and
* get back to the yielding vcpu in a while.
*/
#define __CSFLAG_vcpu_yield 4
-#define CSFLAG_vcpu_yield (1<<__CSFLAG_vcpu_yield)
+#define CSFLAG_vcpu_yield (1U<<__CSFLAG_vcpu_yield)
static unsigned int __read_mostly opt_migrate_resist = 500;
integer_param("sched_credit2_migrate_resist", opt_migrate_resist);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 104668: all pass - PUSHED
flight 104668 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104668/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8b17ad862c235b3226c3d118e5b2f929860ef7ec
baseline version:
ovmf 2bdfb11df9ca0ea0a136e39baac3548b295732b9
Last test of basis 104646 2017-01-25 13:45:30 Z0 days
Testing same since 104668 2017-01-25 22:44:51 Z0 days1 attempts
People who touched revisions under test:
Michael Kinney
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 :
+ branch=ovmf
+ revision=8b17ad862c235b3226c3d118e5b2f929860ef7ec
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
8b17ad862c235b3226c3d118e5b2f929860ef7ec
+ branch=ovmf
+ revision=8b17ad862c235b3226c3d118e5b2f929860ef7ec
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x8b17ad862c235b3226c3d118e5b2f929860ef7ec = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvo
[Xen-devel] [xen-unstable-smoke test] 104671: regressions - trouble: blocked/broken/fail
flight 104671 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104671/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z1 days Failing since104642 2017-01-25 10:01:54 Z0 days 13 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days 10 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 104669: regressions - trouble: blocked/broken/fail
flight 104669 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104669/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z1 days Failing since104642 2017-01-25 10:01:54 Z0 days 12 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days9 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.2-testing baseline-only test] 68459: tolerable FAIL
This run is configured for baseline tests only. flight 68459 qemu-upstream-4.2-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68459/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail baseline untested test-i386-i386-xl-qemuu-winxpsp3 20 leak-check/checkfail baseline untested test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xend-qemuu-winxpsp3 20 leak-check/checkfail never pass test-amd64-amd64-xl-qemuu-winxpsp3 20 leak-check/check fail never pass version targeted for testing: qemuu5081fc1c773d2a83ec7a867f030323b8b6956cd1 jobs: build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-i386-xend-qemuu-winxpsp3 fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail 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.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] kexec: implemented XEN KEXEC STATUS to determine if an image is loaded
On Wed, Jan 25, 2017 at 09:31:15AM -0600, Eric DeVolder wrote:
[...]
> diff --git a/kexec/kexec.c b/kexec/kexec.c
> index 500e5a9..ec16247 100644
> --- a/kexec/kexec.c
> +++ b/kexec/kexec.c
> @@ -51,6 +51,9 @@
> #include "kexec-lzma.h"
> #include
>
> +#define KEXEC_LOADED_PATH "/sys/kernel/kexec_loaded"
> +#define KEXEC_CRASH_LOADED_PATH "/sys/kernel/kexec_crash_loaded"
> +
> unsigned long long mem_min = 0;
> unsigned long long mem_max = ULONG_MAX;
> static unsigned long kexec_flags = 0;
> @@ -890,8 +893,6 @@ static int my_exec(void)
> return -1;
> }
>
> -static int kexec_loaded(void);
> -
> static int load_jump_back_helper_image(unsigned long kexec_flags, void
> *entry)
> {
> int result;
> @@ -902,6 +903,40 @@ static int load_jump_back_helper_image(unsigned long
> kexec_flags, void *entry)
> return result;
> }
>
> +static int kexec_loaded(const char *file)
> +{
> + long ret = -1;
> + FILE *fp;
> + char *p;
> + char line[3];
> +
> + /* No way to tell if an image is loaded under Xen, assume it is. */
> + if (xen_present())
> + return 1;
> +
> + fp = fopen(file, "r");
> + if (fp == NULL)
> + return -1;
> +
> + p = fgets(line, sizeof(line), fp);
> + fclose(fp);
> +
> + if (p == NULL)
> + return -1;
> +
> + ret = strtol(line, &p, 10);
> +
> + /* Too long */
> + if (ret > INT_MAX)
> + return -1;
> +
> + /* No digits were found */
> + if (p == line)
> + return -1;
> +
> + return (int)ret;
> +}
> +
> /*
> * Jump back to the original kernel
> */
> @@ -909,7 +944,7 @@ static int my_load_jump_back_helper(unsigned long
> kexec_flags, void *entry)
> {
> int result;
>
> - if (kexec_loaded()) {
> + if (kexec_loaded(KEXEC_LOADED_PATH)) {
> fprintf(stderr, "There is kexec kernel loaded, make sure "
> "you are in kexeced kernel.\n");
> return -1;
> @@ -970,6 +1005,7 @@ void usage(void)
> " to original kernel.\n"
> " -s, --kexec-file-syscall Use file based syscall for kexec
> operation\n"
> " -d, --debug Enable debugging to help spot a
> failure.\n"
> +" -S, --status Return 0 if the type (by default crash)
> is loaded.\n"
> "\n"
> "Supported kernel file types and options: \n");
> for (i = 0; i < file_types; i++) {
> @@ -981,40 +1017,30 @@ void usage(void)
> printf("\n");
> }
>
> -static int kexec_loaded(void)
> +static int k_status(unsigned long kexec_flags)
> {
> - long ret = -1;
> - FILE *fp;
> - char *p;
> - char line[3];
> + int result;
> + long native_arch;
> +
> + /* set the arch */
> + native_arch = physical_arch();
> + if (native_arch < 0) {
> + return -1;
> + }
> + kexec_flags |= native_arch;
>
> - /* No way to tell if an image is loaded under Xen, assume it is. */
> if (xen_present())
> - return 1;
> -
> - fp = fopen("/sys/kernel/kexec_loaded", "r");
> - if (fp == NULL)
> - return -1;
> -
> - p = fgets(line, sizeof(line), fp);
> - fclose(fp);
> -
> - if (p == NULL)
> - return -1;
> -
> - ret = strtol(line, &p, 10);
> -
> - /* Too long */
> - if (ret > INT_MAX)
> - return -1;
> -
> - /* No digits were found */
> - if (p == line)
> - return -1;
> -
> - return (int)ret;
> + result = xen_kexec_status(kexec_flags);
> + else {
> + if (kexec_flags & KEXEC_ON_CRASH)
> + result = kexec_loaded(KEXEC_CRASH_LOADED_PATH);
> + else
> + result = kexec_loaded(KEXEC_LOADED_PATH);
> + }
> + return result;
> }
Ohhh... This is awful. Have you tried --patience option for "git format-patch"?
Does it help? If yes please repost. If it does not let's wait for maintainers
opinion about that. Maybe we should leave forward declaration in first patch
as is and then move kexec_loaded() in second (as a cleanup).
Though otherwise LGTM.
Daniel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13 4/9] x86: add multiboot2 protocol support for EFI platforms
On Wed, Jan 25, 2017 at 04:20:30PM -0600, Doug Goldstein wrote: > On 1/25/17 4:11 PM, Daniel Kiper wrote: > > This way Xen can be loaded on EFI platforms using GRUB2 and > > other boot loaders which support multiboot2 protocol. > > > > Signed-off-by: Daniel Kiper > > --- > > v13 - suggestions/fixes: > > - move vga_text_buffer and efi_platform to .init.data section > > (suggested by Jan Beulich), > > - reduce number of error branches in EFI code in > > xen/arch/x86/boot/head.S > > (suggested by Jan Beulich), > > - rename run_bs label to .Lrun_bs > > (suggested by Jan Beulich), > > - align the stack as UEFI spec requires > > (suggested by Jan Beulich), > > - change trampoline region memory layout > > (suggested by Jan Beulich), > > - revert changes in efi_arch_pre_exit_boot() > > (suggested by Jan Beulich), > > - relocate_trampoline() must set trampoline_phys for all bootloaders; > > otherwise fallback allocator is always used if Xen was loaded with > > Multiboot2 protocol, > > - change err type in efi_multiboot2() to "static const CHAR16 > > __initconst" > > (suggested by Jan Beulich), > > - change asm "g" constraint to "rm" in efi_multiboot2() > > (suggested by Jan Beulich), > > - improve comments > > (suggested by Jan Beulich and Doug Goldstein). > > This is a huge change and would really be helpful to have the diff of > what's changed to work from. Please look below... Daniel diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index b8f727a..2ecdcb3 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -109,13 +109,6 @@ gdt_boot_descr: .long sym_phys(trampoline_gdt) .long 0 /* Needed for 64-bit lgdt */ -.align 4 -vga_text_buffer: -.long 0xb8000 - -efi_platform: -.byte 0 - .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!" .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!" .Lbad_ldr_nbs: .asciz "ERR: Bootloader shutdown EFI x64 boot services!" @@ -123,6 +116,15 @@ efi_platform: .Lbad_ldr_nih: .asciz "ERR: EFI ImageHandle is not provided by bootloader!" .Lbad_efi_msg: .asciz "ERR: EFI IA-32 platforms are not supported!" +.section .init.data, "a", @progbits +.align 4 + +vga_text_buffer: +.long 0xb8000 + +efi_platform: +.byte 0 + .section .init.text, "ax", @progbits bad_cpu: @@ -170,6 +172,12 @@ not_multiboot: .code64 __efi64_mb2_start: +/* + * Multiboot2 spec says that here CPU is in 64-bit mode. However, there + * is also guarantee that all code and data is always put by the bootloader + * below 4 GiB. Hence, we can safely use in most cases 32-bit addressing. + */ + cld /* VGA is not available on EFI platforms. */ @@ -180,7 +188,7 @@ __efi64_mb2_start: je .Lefi_multiboot2_proto /* Jump to not_multiboot after switching CPU to x86_32 mode. */ -lea not_multiboot(%rip),%edi +lea not_multiboot(%rip),%r15d jmp x86_32_switch .Lefi_multiboot2_proto: @@ -197,7 +205,7 @@ __efi64_mb2_start: mov %ecx,%r8d sub %ebx,%r8d cmp %r8d,MB2_fixed_total_size(%rbx) -jbe run_bs +jbe .Lrun_bs /* Are EFI boot services available? */ cmpl$MULTIBOOT2_TAG_TYPE_EFI_BS,MB2_tag_type(%rcx) @@ -226,7 +234,7 @@ __efi64_mb2_start: /* Is it the end of Multiboot2 information? */ cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%rcx) -je run_bs +je .Lrun_bs .Lefi_mb2_next_tag: /* Go to next Multiboot2 information tag. */ @@ -235,34 +243,32 @@ __efi64_mb2_start: and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx jmp .Lefi_mb2_tsize -run_bs: +.Lrun_bs: /* Are EFI boot services available? */ cmpb$0,efi_platform(%rip) -jnz 0f /* Jump to .Lmb2_no_bs after switching CPU to x86_32 mode. */ -lea .Lmb2_no_bs(%rip),%edi -jmp x86_32_switch +lea .Lmb2_no_bs(%rip),%r15d +jz x86_32_switch -0: /* Is EFI SystemTable address provided by boot loader? */ test%rsi,%rsi -jnz 1f /* Jump to .Lmb2_no_st after switching CPU to x86_32 mode. */ -lea .Lmb2_no_st(%rip),%edi -jmp x86_32_switch +lea .Lmb2_no_st(%rip),%r15d +jz x86_32_switch -1: /* Is EFI ImageHandle address provided by boot loader? */ test%rdi,%rdi -jnz 2f /* Jump to .Lmb2_no_ih after switching CPU to x86_32 mode. */ -lea .Lmb2_no_ih(%rip),%edi -jmp x86_32_switch +lea .Lmb2_no_ih(%rip),%r15d +jz x86_32_switch + +/* Align the stack as UEFI spec requires. */ +add $15,%rsp +
Re: [Xen-devel] [PATCH] arm/monitor: flush the icache during SMC traps
Hi Tamas, On 25/01/2017 20:02, Tamas K Lengyel wrote: During an SMC trap it is possible that the user may change the memory By user, do you mean the monitor application? from where the SMC was fetched. However, without flushing the icache the SMC may still trigger if the pCPU was idle during the trap. Flush the icache to ensure consistency. invalidate_icache will invalidate the cache to PoU on all the pCPUs. But here you only mention a problem on the current pCPU. So which behavior do you want to achieve? Signed-off-by: Tamas K Lengyel --- Cc: Razvan Cojocaru Cc: Stefano Stabellini Cc: Julien Grall --- xen/arch/arm/monitor.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/arm/monitor.c b/xen/arch/arm/monitor.c index 59ce8f635f..ae1b97993f 100644 --- a/xen/arch/arm/monitor.c +++ b/xen/arch/arm/monitor.c @@ -63,6 +63,9 @@ int monitor_smc(void) .reason = VM_EVENT_REASON_PRIVILEGED_CALL }; +/* Nuke the icache as the memory may get changed underneath us. */ +invalidate_icache(); + Can you explain why you put this call before the monitor trap and not after? From my understanding the monitoring application may change the memory. But by the time you modify the instruction, the instruction cache may have prefetched the previous instruction. So the problem is still there. Furthermore, the instruction cache may not snoop the data cache. So you have to ensure the data written reached the memory. Otherwise you may read the previous instruction. Where is it done? If you expect the monitor app to flush the data cache, then please comment it. Lastly, this looks like to me that all the traps will have this issue. So maybe this should go in monitor_traps instead? return monitor_traps(current, 1, &req); } Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] arm/p2m: Fix regression during domain shutdown with active mem_access
Hi Tamas, On 25/01/2017 16:12, Tamas K Lengyel wrote: The change in commit 438c5fe4f0c introduced a regression for domains where mem_acces is or was active. When relinquish_p2m_mapping attempts to clear a page where the order is not 0 the following ASSERT is triggered: ASSERT(!p2m->mem_access_enabled || page_order == 0); This regression was unfortunately not caught during testing in preparation for the 4.8 release. In this patch we adjust the ASSERT to not trip when the domain is being shutdown. Ideally this fix would be part of Xen 4.8.1. +1 for the backport. Signed-off-by: Tamas K Lengyel Acked-by: Julien Grall Cheers, --- Cc: Stefano Stabellini Cc: Julien Grall v3: Minor adjustments --- xen/arch/arm/p2m.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 09ceb378a5..7762f453f5 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -991,9 +991,10 @@ static int __p2m_set_entry(struct p2m_domain *p2m, /* * The radix-tree can only work on 4KB. This is only used when - * memaccess is enabled. + * memaccess is enabled and during shutdown. */ -ASSERT(!p2m->mem_access_enabled || page_order == 0); +ASSERT(!p2m->mem_access_enabled || page_order == 0 || + p2m->domain->is_dying); /* * The access type should always be p2m_access_rwx when the mapping * is removed. -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 104666: regressions - trouble: blocked/broken/fail
flight 104666 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104666/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z1 days Failing since104642 2017-01-25 10:01:54 Z0 days 11 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days8 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13 4/9] x86: add multiboot2 protocol support for EFI platforms
On 1/25/17 4:11 PM, Daniel Kiper wrote: > This way Xen can be loaded on EFI platforms using GRUB2 and > other boot loaders which support multiboot2 protocol. > > Signed-off-by: Daniel Kiper > --- > v13 - suggestions/fixes: > - move vga_text_buffer and efi_platform to .init.data section > (suggested by Jan Beulich), > - reduce number of error branches in EFI code in xen/arch/x86/boot/head.S > (suggested by Jan Beulich), > - rename run_bs label to .Lrun_bs > (suggested by Jan Beulich), > - align the stack as UEFI spec requires > (suggested by Jan Beulich), > - change trampoline region memory layout > (suggested by Jan Beulich), > - revert changes in efi_arch_pre_exit_boot() > (suggested by Jan Beulich), > - relocate_trampoline() must set trampoline_phys for all bootloaders; > otherwise fallback allocator is always used if Xen was loaded with > Multiboot2 protocol, > - change err type in efi_multiboot2() to "static const CHAR16 __initconst" > (suggested by Jan Beulich), > - change asm "g" constraint to "rm" in efi_multiboot2() > (suggested by Jan Beulich), > - improve comments > (suggested by Jan Beulich and Doug Goldstein). This is a huge change and would really be helpful to have the diff of what's changed to work from. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v13 8/9] x86/boot: rename sym_phys() to sym_offs()
This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.
There is no functional change.
Suggested-by: Jan Beulich
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
v8 - suggestions/fixes:
- improve commit message
(suggested by Jan Beulich).
---
xen/arch/x86/boot/head.S | 38 +++---
xen/arch/x86/boot/trampoline.S |2 +-
xen/arch/x86/boot/wakeup.S |4 ++--
xen/arch/x86/boot/x86_64.S | 18 +-
4 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index c1414cf..2d010fc 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -12,9 +12,9 @@
.text
.code32
-#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
-#define sym_esi(sym) sym_phys(sym)(%esi)
-#define sym_fs(sym) %fs:sym_phys(sym)
+#define sym_offs(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym) sym_offs(sym)(%esi)
+#define sym_fs(sym) %fs:sym_offs(sym)
#define BOOT_CS320x0008
#define BOOT_CS640x0010
@@ -97,7 +97,7 @@ multiboot2_header_start:
/* EFI64 Multiboot2 entry point. */
mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
- sym_phys(__efi64_mb2_start)
+ sym_offs(__efi64_mb2_start)
/* Multiboot2 header end tag. */
mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
@@ -119,7 +119,7 @@ multiboot2_header_start:
gdt_boot_descr:
.word 7*8-1
gdt_boot_base:
-.long sym_phys(trampoline_gdt)
+.long sym_offs(trampoline_gdt)
.long 0 /* Needed for 64-bit lgdt */
vga_text_buffer:
@@ -131,23 +131,23 @@ efi_platform:
.section .init.text, "ax", @progbits
bad_cpu:
-add $sym_phys(.Lbad_cpu_msg),%esi # Error message
+add $sym_offs(.Lbad_cpu_msg),%esi # Error message
jmp .Lget_vtb
not_multiboot:
-add $sym_phys(.Lbad_ldr_msg),%esi # Error message
+add $sym_offs(.Lbad_ldr_msg),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_st:
-add $sym_phys(.Lbad_ldr_nst),%esi # Error message
+add $sym_offs(.Lbad_ldr_nst),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_ih:
-add $sym_phys(.Lbad_ldr_nih),%esi # Error message
+add $sym_offs(.Lbad_ldr_nih),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_bs:
-add $sym_phys(.Lbad_ldr_nbs),%esi # Error message
+add $sym_offs(.Lbad_ldr_nbs),%esi # Error message
xor %edi,%edi # No VGA text buffer
jmp .Lsend_chr
.Lmb2_efi_ia_32:
-add $sym_phys(.Lbad_efi_msg),%esi # Error message
+add $sym_offs(.Lbad_efi_msg),%esi # Error message
xor %edi,%edi # No VGA text buffer
jmp .Lsend_chr
.Lget_vtb:
@@ -359,7 +359,7 @@ __start:
cli
/* Load default Xen image load base address. */
-mov $sym_phys(__image_base__),%esi
+mov $sym_offs(__image_base__),%esi
/* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
xor %edx,%edx
@@ -528,8 +528,8 @@ trampoline_setup:
jnz 1f
/* Initialize BSS (no nasty surprises!). */
-mov $sym_phys(__bss_start),%edi
-mov $sym_phys(__bss_end),%ecx
+mov $sym_offs(__bss_start),%edi
+mov $sym_offs(__bss_end),%ecx
push%fs
pop %es
sub %edi,%ecx
@@ -602,22 +602,22 @@ trampoline_setup:
/* Apply relocations to bootstrap trampoline. */
mov sym_fs(trampoline_phys),%edx
-mov $sym_phys(__trampoline_rel_start),%edi
+mov $sym_offs(__trampoline_rel_start),%edi
1:
mov %fs:(%edi),%eax
add %edx,%fs:(%edi,%eax)
add $4,%edi
-cmp $sym_phys(__trampoline_rel_stop),%edi
+cmp $sym_offs(__trampoline_rel_stop),%edi
jb 1b
/* Patch in the trampoline segment. */
shr $4,%edx
-mov $sym_phys(__trampoline_seg_start),%edi
+mov $sym_offs(__trampoline_seg_start),%edi
1:
mov %fs:(%edi),%eax
mov %dx,%fs:(%edi,%eax)
add $4,%edi
-cmp $sym_phys(__trampoline_seg_stop),%edi
+cmp $sym_offs(__trampoline_seg_stop),%edi
jb 1b
/* Do not parse command line on EFI platform here. */
@@ -643,7 +643,7 @@ trampoline_setup:
push%eax
/* Copy bootstrap trampoline to low memory, below 1MB. */
-mov $sym_phys(trampoline_star
[Xen-devel] [PATCH v13 7/9] x86: make Xen early boot code relocatable
Every multiboot protocol (regardless of version) compatible image must specify its load address (in ELF or multiboot header). Multiboot protocol compatible loader have to load image at specified address. However, there is no guarantee that the requested memory region (in case of Xen it starts at 2 MiB and ends at ~5 MiB) where image should be loaded initially is a RAM and it is free (legacy BIOS platforms are merciful for Xen but I found at least one EFI platform on which Xen load address conflicts with EFI boot services; it is Dell PowerEdge R820 with latest firmware). To cope with that problem we must make Xen early boot code relocatable and help boot loader to relocate image in proper way by suggesting, not requesting specific load addresses as it is right now, allowed address ranges. This patch does former. It does not add multiboot2 protocol interface which is done in "x86: add multiboot2 protocol support for relocatable images" patch. This patch changes following things: - %esi register is used as a storage for Xen image load base address; it is mostly unused in early boot code and preserved during C functions calls in 32-bit mode, - %fs is used as base for Xen data relative addressing in 32-bit code if it is possible; %esi is used for that thing during error printing because it is not always possible to properly and efficiently initialize %fs. Signed-off-by: Daniel Kiper --- v13 - suggestions/fixes: - move gdt_boot_descr to .init.data section (suggested by Jan Beulich). v12 - suggestions/fixes: - store Xen image load base address directly into %esi, - store Xen image load base address after x86_32_switch (suggested by Doug Goldstein), - improve commit message. v8 - suggestions/fixes: - use shld instead of mov and shr in BOOT_FS segment descriptor base address initialization (suggested by Jan Beulich), - simplify code updating frame addresses in page tables (suggested by Jan Beulich), - print Xen image base addresses using "%#lx" format (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v6 - suggestions/fixes: - leave static mapping of first 16 MiB in l2_identmap as is (suggested by Jan Beulich), - use xen_phys_start instead of xen_img_load_base_addr (suggested by Daniel Kiper and Jan Beulich), - simplify BOOT_FS segment descriptor base address initialization (suggested by Jan Beulich), - fix BOOT_FS segment limit (suggested by Jan Beulich), - do not rename sym_phys in this patch (suggested by Jan Beulich), - rename esi_offset/fs_offset to sym_esi/sym_fs respectively (suggested by Jan Beulich), - use add instead of lea in assembly error printing code (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - improve commit message (suggested by Jan Beulich), - various minor cleanups and fixes (suggested by Jan Beulich). v4 - suggestions/fixes: - do not relocate Xen image if boot loader did work for us (suggested by Andrew Cooper and Jan Beulich), - initialize xen_img_load_base_addr in EFI boot code too, - properly initialize trampoline_xen_phys_start, - calculate Xen image load base address in x86_64 code ourselves, (suggested by Jan Beulich), - change how and when Xen image base address is printed, - use %fs instead of %esi for relative addressing (suggested by Andrew Cooper and Jan Beulich), - create esi_offset and fs_offset() macros in assembly, - calculate mkelf32 argument automatically, - optimize and cleanup code, - improve comments, - improve commit message. v3 - suggestions/fixes: - improve segment registers initialization (suggested by Jan Beulich), - simplify Xen image load base address calculation (suggested by Jan Beulich), - use %esi and %r15d instead of %ebp to store Xen image load base address, - use %esi instead of %fs for relative addressing; this way we get shorter and simpler code, - rename some variables and constants (suggested by Jan Beulich), - improve comments (suggested by Konrad Rzeszutek Wilk), - improve commit message (suggested by Jan Beulich). --- xen/arch/x86/boot/head.S | 168 - xen/arch/x86/boot/trampoline.S|5 ++ xen/arch/x86/boot/x86_64.S| 21 +++-- xen/arch/x86/setup.c | 14 ++-- xen/arch/x86/x86_64/asm-offsets.c |3 + xen/include/asm-x86/page.h|2 +- 6 files changed, 157 insertions(+), 56 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index acd47d5..c1414cf 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -13,12 +13,15 @@ .code32 #define sym_phys(sym) ((sym) - __XEN_VIRT_START) +#define sym_esi(sym) sym_phys(sym)(%esi) +#define sym_fs(sym) %fs:sym
[Xen-devel] [PATCH v13 3/9] efi: create new early memory allocator
There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB address and we should not allocate a memory from below of it. So, I tried to use mem_lower address calculated by GRUB2. However, this solution works only on some machines. There are machines in the wild (e.g. Dell PowerEdge R820) which uses first ~640 KiB for boot services code or data... :-((( Hence, we need new memory allocator for Xen EFI boot code which is quite simple and generic and could be used by place_string() and efi_arch_allocate_mmap_buffer(). I think about following solutions: 1) We could use native EFI allocation functions (e.g. AllocatePool() or AllocatePages()) to get memory chunk. However, later (somewhere in __start_xen()) we must copy its contents to safe place or reserve it in e820 memory map and map it in Xen virtual address space. This means that the code referring to Xen command line, loaded modules and EFI memory map, mostly in __start_xen(), will be further complicated and diverge from legacy BIOS cases. Additionally, both former things have to be placed below 4 GiB because their addresses are stored in multiboot_info_t structure which has 32-bit relevant members. 2) We may allocate memory area statically somewhere in Xen code which could be used as memory pool for early dynamic allocations. Looks quite simple. Additionally, it would not depend on EFI at all and could be used on legacy BIOS platforms if we need it. However, we must carefully choose size of this pool. We do not want increase Xen binary size too much and waste too much memory but also we must fit at least memory map on x86 EFI platforms. As I saw on small machine, e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more than 200 entries. Every entry on x86-64 platform is 40 bytes in size. So, it means that we need more than 8 KiB for EFI memory map only. Additionally, if we use this memory pool for Xen and modules command line storage (it would be used when xen.efi is executed as EFI application) then we should add, I think, about 1 KiB. In this case, to be on safe side, we should assume at least 64 KiB pool for early memory allocations. Which is about 4 times of our earlier calculations. However, during discussion on Xen-devel Jan Beulich suggested that just in case we should use 1 MiB memory pool like it is in original place_string() implementation. So, let's use 1 MiB as it was proposed. If we think that we should not waste unallocated memory in the pool on running system then we can mark this region as __initdata and move all required data to dynamically allocated places somewhere in __start_xen(). 2a) We could put memory pool into .bss.page_aligned section. Then allocate memory chunks starting from the lowest address. After init phase we can free unused portion of the memory pool as in case of .init.text or .init.data sections. This way we do not need to allocate any space in image file and freeing of unused area in the memory pool is very simple. Now #2a solution is implemented because it is quite simple and requires limited number of changes, especially in __start_xen(). New allocator is quite generic and can be used on ARM platforms too. Though it is not enabled on ARM yet due to lack of some prereq. List of them is placed before ebmalloc code. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich Acked-by: Julien Grall Reviewed-by: Doug Goldstein Tested-by: Doug Goldstein --- v11 - suggestions/fixes: - #ifdef only EBMALLOC_SIZE from ebmalloc machinery (suggested by Jan Beulich). v10 - suggestions/fixes: - remove unneeded ARM free_ebmalloc_unused_mem() stub. v9 - suggestions/fixes: - call free_ebmalloc_unused_mem() from efi_init_memory() instead of xen/arch/arm/setup.c:init_done() (suggested by Jan Beulich), - improve comments. v8 - suggestions/fixes: - disable whole ebmalloc machinery on ARM platforms, - add comment saying what should be done before enabling ebmalloc on ARM, (suggested by Julien Grall), - move ebmalloc code before efi-boot.h inclusion and remove unneeded forward declaration (suggested by Jan Beulich), - remove free_ebmalloc_unused_mem() call from xen/arch/arm/setup.c:init_done() (suggested by Julien Grall), - improve commit message. v7 - suggestions/fixes: - enable most of ebmalloc machinery on ARM platforms (suggested by Jan Beulich), - remove unneeded cast (suggested by Jan Beulich), - wrap long line (suggested by Jan Beulich), - improve commit message. v6 - suggestions/fixes: - optimize ebmalloc allocator, - move ebmalloc machinery to xen/common/efi/boot.c (suggested by Jan Beulich), - enforce PAGE_SIZE
[Xen-devel] [PATCH v13 9/9] x86: add multiboot2 protocol support for relocatable images
Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
v12 - suggestions/fixes:
- replace TABs with spaces in xen/include/xen/multiboot2.h
(suggested by Doug Goldstein).
v9 - suggestions/fixes:
- use .L labels instead of numeric ones in multiboot2 data scanning loop
(suggested by Jan Beulich).
v4 - suggestions/fixes:
- do not get Xen image load base address from
multiboot2 information in x86_64 code
(suggested by Jan Beulich),
- improve label names
(suggested by Jan Beulich),
- improve comments,
(suggested by Jan Beulich).
v3 - suggestions/fixes:
- use %esi and %r15d instead of %ebp to store
Xen image load base address,
- rename some types and constants,
- reformat xen/include/xen/multiboot2.h
(suggested by Konrad Rzeszutek Wilk),
- improve comments,
- improve commit message
(suggested by Konrad Rzeszutek Wilk).
---
xen/arch/x86/boot/head.S | 16
xen/arch/x86/x86_64/asm-offsets.c |1 +
xen/include/xen/multiboot2.h | 13 +
3 files changed, 30 insertions(+)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 2d010fc..ab0a9d9 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -82,6 +82,13 @@ multiboot2_header_start:
/* Align modules at page boundry. */
mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
+/* Load address preference. */
+mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \
+ sym_offs(start), /* Min load address. */ \
+ 0x, /* The end of image max load address (4 GiB -
1). */ \
+ 0x20, /* Load address alignment (2 MiB). */ \
+ MULTIBOOT2_LOAD_PREFERENCE_HIGH
+
/* Console flags tag. */
mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
@@ -391,6 +398,15 @@ __start:
cmp %edi,MB2_fixed_total_size(%ebx)
jbe trampoline_bios_setup
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
+jne .Lmb2_mem_lower
+
+mov MB2_load_base_addr(%ecx),%esi
+sub $XEN_IMG_OFFSET,%esi
+jmp .Lmb2_next_tag
+
+.Lmb2_mem_lower:
/* Get mem_lower from Multiboot2 information. */
cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
cmove MB2_mem_lower(%ecx),%edx
diff --git a/xen/arch/x86/x86_64/asm-offsets.c
b/xen/arch/x86/x86_64/asm-offsets.c
index 87e573a..85639e4 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -174,6 +174,7 @@ void __dummy__(void)
OFFSET(MB2_fixed_total_size, multiboot2_fixed_t, total_size);
OFFSET(MB2_tag_type, multiboot2_tag_t, type);
OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+OFFSET(MB2_load_base_addr, multiboot2_tag_load_base_addr_t,
load_base_addr);
OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index a3e3119..5acd225 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -59,11 +59,17 @@
#define MULTIBOOT2_HEADER_TAG_EFI_BS7
#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32 8
#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64 9
+#define MULTIBOOT2_HEADER_TAG_RELOCATABLE 10
/* Header tag flags. */
#define MULTIBOOT2_HEADER_TAG_REQUIRED 0
#define MULTIBOOT2_HEADER_TAG_OPTIONAL 1
+/* Where image should be loaded (suggestion not requirement). */
+#define MULTIBOOT2_LOAD_PREFERENCE_NONE 0
+#define MULTIBOOT2_LOAD_PREFERENCE_LOW 1
+#define MULTIBOOT2_LOAD_PREFERENCE_HIGH 2
+
/* Header console tag console_flags. */
#define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED 1
#define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED 2
@@ -90,6 +96,7 @@
#define MULTIBOOT2_TAG_TYPE_EFI_BS 18
#define MULTIBOOT2_TAG_TYPE_EFI32_IH19
#define MULTIBOOT2_TAG_TYPE_EFI64_IH20
+#define MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR 21
/* Multiboot 2 tag alignment. */
#define MULTIBOOT2_TAG_ALIGN8
@@ -120,6 +127,12 @@ typedef struct {
typedef struct {
u32 type;
u32 size;
+u32 load_base_addr;
+} multiboot2_tag_loa
[Xen-devel] [PATCH v13 6/9] x86/setup: use XEN_IMG_OFFSET instead of...
..calculating its value during runtime. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich Reviewed-by: Doug Goldstein --- xen/arch/x86/setup.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index e6f6ef1..24b4b23 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -943,7 +943,6 @@ void __init noreturn __start_xen(unsigned long mbi_p) l4_pgentry_t *pl4e; l3_pgentry_t *pl3e; l2_pgentry_t *pl2e; -uint64_t load_start; int i, j, k; /* Select relocation address. */ @@ -957,9 +956,8 @@ void __init noreturn __start_xen(unsigned long mbi_p) * with a barrier(). After this we must *not* modify static/global * data until after we have switched to the relocated pagetables! */ -load_start = (unsigned long)_start - XEN_VIRT_START; barrier(); -move_memory(e + load_start, load_start, _end - _start, 1); +move_memory(e + XEN_IMG_OFFSET, XEN_IMG_OFFSET, _end - _start, 1); /* Walk initial pagetables, relocating page directory entries. */ pl4e = __va(__pa(idle_pg_table)); -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v13 2/9] efi: build xen.gz with EFI code
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
Tested-by: Doug Goldstein
---
v6 - suggestions/fixes:
- improve efi_enabled() checks in efi_runtime_call()
(suggested by Jan Beulich).
v5 - suggestions/fixes:
- properly calculate efi symbol address in
xen/arch/x86/xen.lds.S (I hope that this
change does not invalidate Jan's ACK).
v4 - suggestions/fixes:
- functions should return -ENOSYS instead
of -EOPNOTSUPP if EFI runtime services
are not available
(suggested by Jan Beulich),
- remove stale bits from xen/arch/x86/Makefile
(suggested by Jan Beulich).
v3 - suggestions/fixes:
- check for EFI platform in EFI code
(suggested by Jan Beulich),
- fix Makefiles
(suggested by Jan Beulich),
- improve commit message
(suggested by Jan Beulich).
v2 - suggestions/fixes:
- build EFI code only if it is supported in a given build environment
(suggested by Jan Beulich).
---
xen/arch/x86/Makefile |2 +-
xen/arch/x86/efi/Makefile | 12
xen/arch/x86/xen.lds.S|4 ++--
xen/common/efi/boot.c |3 +++
xen/common/efi/runtime.c |9 +
5 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 007dced..08e9f7b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -219,6 +219,6 @@ efi/mkreloc: efi/mkreloc.c
clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
- rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi
efi/disabled efi/mkreloc
+ rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index ad3fdf7..442f3fc 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,18 +1,14 @@
CFLAGS += -fshort-wchar
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
efi := y$(shell rm -f disabled)
efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c
check.c 2>disabled && echo y))
efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o);
$(call create,runtime.o)))
-
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o buildid.o
+efi := $(if $(efi),$(shell rm disabled)y)
%.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
-stub.o: $(extra-y)
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
+extra-$(efi) += buildid.o
nogcov-$(efi) += stub.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 7676de9..b0b1c9b 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -270,10 +270,10 @@ SECTIONS
.pad : {
. = ALIGN(MB(16));
} :text
-#else
- efi = .;
#endif
+ efi = DEFINED(efi) ? efi : .;
+
/* Sections to be discarded */
/DISCARD/ : {
*(.exit.text)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 3e5e4ab..df8c702 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1251,6 +1251,9 @@ void __init efi_init_memory(void)
} *extra, *extra_head = NULL;
#endif
+if ( !efi_enabled(EFI_BOOT) )
+return;
+
printk(XENLOG_INFO "EFI memory map:%s\n",
map_bs ? " (mapping BootServices)" : "");
for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 8c44835..25323de
[Xen-devel] [PATCH v13 1/9] x86: add multiboot2 protocol support
Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper Reviewed-by: Jan Beulich Reviewed-by: Doug Goldstein Reviewed-by: Andrew Cooper Tested-by: Doug Goldstein --- v13 - suggestions/fixes: - add Emacs file-local variables (suggested by Andrew Cooper). v12 - suggestions/fixes: - replace TABs with spaces in xen/include/xen/multiboot2.h (suggested by Doug Goldstein). v9 - suggestions/fixes: - use .L label instead of numeric one in multiboot2 data scanning loop; I hope that this change does not invalidate Jan's Reviewed-by (suggested by Jan Beulich). v8 - suggestions/fixes: - use sizeof(/) instead of sizeof() if it is possible (suggested by Jan Beulich). v7 - suggestions/fixes: - rename mbi_mbi/mbi2_mbi to mbi_reloc/mbi2_reloc respectively (suggested by Jan Beulich), - initialize mbi_out->flags using "|=" instead of "=" (suggested by Jan Beulich), - use sizeof(*mmap_dst) instead of sizeof(memory_map_t) if it makes sense (suggested by Jan Beulich). v6 - suggestions/fixes: - properly index multiboot2_tag_mmap_t.entries[] (suggested by Jan Beulich), - do not index mbi_out_mods[] beyond its end (suggested by Andrew Cooper), - reduce number of casts (suggested by Andrew Cooper and Jan Beulich), - add braces to increase code readability (suggested by Andrew Cooper). v5 - suggestions/fixes: - check multiboot2_tag_mmap_t.entry_size before multiboot2_tag_mmap_t.entries[] use (suggested by Jan Beulich), - properly index multiboot2_tag_mmap_t.entries[] (suggested by Jan Beulich), - use "type name[]" instad of "type name[0]" in xen/include/xen/multiboot2.h (suggested by Jan Beulich), - remove unneeded comment (suggested by Jan Beulich). v4 - suggestions/fixes: - avoid assembly usage in xen/arch/x86/boot/reloc.c, - fix boundary check issue and optimize for() loops in mbi2_mbi(), - move to stdcall calling convention, - remove unneeded typeof() from ALIGN_UP() macro (suggested by Jan Beulich), - add and use NULL definition in xen/arch/x86/boot/reloc.c (suggested by Jan Beulich), - do not read data beyond the end of multiboot2 information in xen/arch/x86/boot/head.S (suggested by Jan Beulich), - add :req to some .macro arguments (suggested by Jan Beulich), - use cmovcc if possible, - add .L to multiboot2_header_end label (suggested by Jan Beulich), - add .L to multiboot2_proto label (suggested by Jan Beulich), - improve label names (suggested by Jan Beulich). v3 - suggestions/fixes: - reorder reloc() arguments (suggested by Jan Beulich), - remove .L from multiboot2 header labels (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk), - take into account alignment when skipping multiboot2 fixed part (suggested by Konrad Rzeszutek Wilk), - create modules data if modules count != 0 (suggested by Jan Beulich), - improve macros (suggested by Jan Beulich), - reduce number of casts (suggested by Jan Beulich), - use const if possible (suggested by Jan Beulich), - drop static and __used__ attribute from reloc() (suggested by Jan Beulich), - remove isolated/stray __packed attribute from multiboot2_memory_map_t type definition (suggested by Jan Beulich), - reformat xen/include/xen/multiboot2.h (suggested by Konrad Rzeszutek Wilk), - improve comments (suggested by Konrad Rzeszutek Wilk), - remove hard tabs (suggested by Jan Beulich and Konrad Rzeszutek Wilk). v2 - suggestions/fixes: - generate multiboot2 header using macros (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - simplify assembly in xen/arch/x86/boot/head.S (suggested by Jan Beulich), - do not include include/xen/compiler.h in xen/arch/x86/boot/reloc.c (suggested by Jan Beulich), - do not read data beyond the end of multiboot2 information (suggested by Jan Beulich). v2 - not fixed yet: - dynamic dependency generation for xen/arch/x86/boot/reloc.S; this requires more work; I am not sure that it pays because potential patch requires more changes than addition of just multiboot2.h to Makefile (suggested by Jan Beulich), - isolated/stray __packed attribute usage for multiboot2_memory_map_t (suggested by Jan Beulich). --- xen/arch/x86/boot/Makefile|3 +- xen/arch/x86/boot/head.S | 107 ++- xen/arch/x86/boot/reloc.c | 154 +++-- xen/arch/x86/x86_64/asm-offsets.c |9 ++ xen/include/xen/multiboot2.h | 169 + 5 files changed, 432 ins
[Xen-devel] [PATCH v13 0/9] x86: multiboot2 protocol support
Hi, I am sending thirteenth version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known/confirmed issues. The final goal is xen.efi binary file which could be loaded by EFI loader, multiboot (v1) protocol (only on legacy BIOS platforms) and multiboot2 protocol. This way we will have: - smaller Xen code base, - one code base for xen.gz and xen.efi, - one build method for xen.gz and xen.efi; xen.efi will be extracted from xen(-syms) file using objcopy or special custom tool, - xen.efi build will not so strongly depend on a given GCC and binutils version. Here is short list of changes since v12: - changed patches: 1, 4, 7. If you are not interested in this patch series at all please drop me a line and I will remove you from distribution list. Daniel xen/arch/x86/Makefile |4 +- xen/arch/x86/Rules.mk |3 + xen/arch/x86/boot/Makefile|3 +- xen/arch/x86/boot/head.S | 570 ++ xen/arch/x86/boot/reloc.c | 154 +- xen/arch/x86/boot/trampoline.S|7 +- xen/arch/x86/boot/wakeup.S|4 +- xen/arch/x86/boot/x86_64.S| 44 +++ xen/arch/x86/efi/Makefile | 12 +- xen/arch/x86/efi/efi-boot.h | 63 +++-- xen/arch/x86/efi/stub.c | 39 ++ xen/arch/x86/setup.c | 24 ++-- xen/arch/x86/x86_64/asm-offsets.c | 15 +++ xen/arch/x86/xen.lds.S| 13 +- xen/common/efi/boot.c | 64 ++ xen/common/efi/runtime.c |9 ++ xen/include/asm-x86/config.h |3 + xen/include/asm-x86/page.h|2 +- xen/include/xen/config.h |1 + xen/include/xen/multiboot2.h | 182 ++ 20 files changed, 1092 insertions(+), 124 deletions(-) Daniel Kiper (9): x86: add multiboot2 protocol support efi: build xen.gz with EFI code efi: create new early memory allocator x86: add multiboot2 protocol support for EFI platforms x86: change default load address from 1 MiB to 2 MiB x86/setup: use XEN_IMG_OFFSET instead of... x86: make Xen early boot code relocatable x86/boot: rename sym_phys() to sym_offs() x86: add multiboot2 protocol support for relocatable images ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v13 4/9] x86: add multiboot2 protocol support for EFI platforms
This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v13 - suggestions/fixes: - move vga_text_buffer and efi_platform to .init.data section (suggested by Jan Beulich), - reduce number of error branches in EFI code in xen/arch/x86/boot/head.S (suggested by Jan Beulich), - rename run_bs label to .Lrun_bs (suggested by Jan Beulich), - align the stack as UEFI spec requires (suggested by Jan Beulich), - change trampoline region memory layout (suggested by Jan Beulich), - revert changes in efi_arch_pre_exit_boot() (suggested by Jan Beulich), - relocate_trampoline() must set trampoline_phys for all bootloaders; otherwise fallback allocator is always used if Xen was loaded with Multiboot2 protocol, - change err type in efi_multiboot2() to "static const CHAR16 __initconst" (suggested by Jan Beulich), - change asm "g" constraint to "rm" in efi_multiboot2() (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich and Doug Goldstein). v12 - suggestions/fixes: - rename __efi64_start to __efi64_mb2_start (suggested by Andrew Cooper), - use efi_arch_memory_setup() machinery as trampoline et consortes main memory allocator (suggested by Doug Goldstein), - allocate space for mbi struct in efi_arch_memory_setup() too; this thing was not taken into account in earlier releases, - revert trampoline et consortes fallback memory allocator code in efi_arch_process_memory_map() to current upstream state (suggested by Doug Goldstein), - further simplify efi_arch_pre_exit_boot() code, - call efi_arch_memory_setup() from efi_multiboot2() (suggested by Doug Goldstein), - fix asembly call argument in xen/arch/x86/efi/stub.c (suggested by Andrew Cooper), - add ASSERT() for trampoline size (suggested by Doug Goldstein), - add KB() macro (suggested by Doug Goldstein), - improve comments (suggested by Andrew Cooper and Doug Goldstein). v10 - suggestions/fixes: - replace ljmpl with lretq (suggested by Andrew Cooper), - introduce efi_platform to increase code readability (suggested by Andrew Cooper). v9 - suggestions/fixes: - use .L labels instead of numeric ones in multiboot2 data scanning loops (suggested by Jan Beulich). v8 - suggestions/fixes: - use __bss_start(%rip)/__bss_end(%rip) instead of of .startof.(.bss)(%rip)/$.sizeof.(.bss) because latter is not tested extensively in different built environments yet (suggested by Andrew Cooper), - fix multiboot2 data scanning loop in x86_32 code (suggested by Jan Beulich), - add check for extra mem for mbi data if Xen is loaded via multiboot2 protocol on EFI platform (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v7 - suggestions/fixes: - do not allocate twice memory for trampoline if we were loaded via multiboot2 protocol on EFI platform, - wrap long line (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v6 - suggestions/fixes: - improve label names in assembly error printing code (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - various minor cleanups and fixes (suggested by Jan Beulich). v4 - suggestions/fixes: - remove redundant BSS alignment, - update BSS alignment check, - use __set_bit() instead of set_bit() if possible (suggested by Jan Beulich), - call efi_arch_cpu() from efi_multiboot2() even if the same work is done later in other place right now (suggested by Jan Beulich), - xen/arch/x86/efi/stub.c:efi_multiboot2() fail properly on EFI platforms, - do not read data beyond the end of multiboot2 information in xen/arch/x86/boot/head.S (suggested by Jan Beulich), - use 32-bit registers in x86_64 code if possible (suggested by Jan Beulich), - multiboot2 information address is 64-bit in x86_64 code, so, treat it is as is (suggested by Jan Beulich), - use cmovcc if possible, - leave only one space between rep and stosq (suggested by Jan Beulich), - improve error handling, - improve early error messages, (suggested by Jan Beulich), - improve early error messages printing code, - improve label names (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - various minor cleanups. v3 - suggestions/fixes: - take into account alignment when skipping multiboot2 fixed part (suggested by Konrad Rzeszutek Wilk), - improve segment registers initialization (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich and Konrad Rzeszutek Wilk), - improve commit message (suggested by Jan Be
[Xen-devel] [PATCH v13 5/9] x86: change default load address from 1 MiB to 2 MiB
Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load address from 1 MiB to 2 MiB. This way page table
code will be nice and easy. Hence, there is a chance that it will be
less error prone too... :-)))
Additionally, drop first 2 MiB mapping from Xen image mapping.
It is no longer needed.
Signed-off-by: Daniel Kiper
Reviewed-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
v8 - suggestions/fixes:
- drop first 2 MiB mapping from Xen image mapping
(suggested by Jan Beulich),
- improve commit message.
v7 - suggestions/fixes:
- minor cleanups
(suggested by Jan Beulich).
---
xen/arch/x86/Makefile |2 +-
xen/arch/x86/Rules.mk |3 +++
xen/arch/x86/boot/head.S |8
xen/arch/x86/boot/x86_64.S |5 +++--
xen/arch/x86/setup.c |3 ++-
xen/arch/x86/xen.lds.S |2 +-
6 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 08e9f7b..e5b840e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -90,7 +90,7 @@ all_symbols =
endif
$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
- ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x10 \
+ ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET)
$(XEN_IMG_OFFSET) \
`$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) .
__2M_rwdata_end$$/0x\1/p'`
ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o
$(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 72be8b2..568657e 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,9 +1,12 @@
# x86-specific definitions
+XEN_IMG_OFFSET := 0x20
+
CFLAGS += -I$(BASEDIR)/include
CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
+CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst
$(BASEDIR)/,,$(CURDIR))/$@))'
# Prevent floating-point variables from creeping into Xen.
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 2ecdcb3..acd47d5 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -509,14 +509,6 @@ trampoline_setup:
mov %eax,sym_phys(boot_tsc_stamp)
mov %edx,sym_phys(boot_tsc_stamp+4)
-/*
- * During boot, hook 4kB mappings of first 2MB of memory into L2.
- * This avoids mixing cachability for the legacy VGA region, and is
- * corrected when Xen relocates itself.
- */
-mov $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
-mov %edi,sym_phys(l2_xenmap)
-
/* Apply relocations to bootstrap trampoline. */
mov sym_phys(trampoline_phys),%edx
mov $sym_phys(__trampoline_rel_start),%edi
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 139b2ca..7890374 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -121,8 +121,9 @@ GLOBAL(l2_identmap)
* page.
*/
GLOBAL(l2_xenmap)
-idx = 0
-.rept 8
+.quad 0
+idx = 1
+.rept 7
.quad sym_phys(__image_base__) + (idx << L2_PAGETABLE_SHIFT) +
(PAGE_HYPERVISOR | _PAGE_PSE)
idx = idx + 1
.endr
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index d4b7d25..e6f6ef1 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -999,7 +999,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
* Undo the temporary-hooking of the l1_identmap. __2M_text_start
* is contained in this PTE.
*/
-BUG_ON(l2_table_offset((unsigned long)_erodata) ==
+BUG_ON(using_2M_mapping() &&
+ l2_table_offset((unsigned long)_erodata) ==
l2_table_offset((unsigned long)_stext));
*pl2e++ = l2e_from_pfn(xen_phys_start >> PAGE_SHIFT,
PAGE_HYPERVISOR_RX | _PAGE_PSE);
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index addf2ef..632a387 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -55,7 +55,7 @@ SECTIONS
__2M_text_start = .; /* Start of 2M superpages, mapped RX. */
#endif
- . = __XEN_VIRT_START + MB(1);
+ . = __XEN_VIRT_START + XEN_IMG_OFFSET;
_start = .;
.text : {
_stext = .;/* Text and read-only data */
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [seabios baseline-only test] 68458: tolerable FAIL
This run is configured for baseline tests only. flight 68458 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68458/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail baseline untested test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail baseline untested test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail baseline untested test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail baseline untested test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass version targeted for testing: seabios 106543deb447c4005f9a9845f1f43a72547f6209 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3pass 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 broken-step build-i386-xsm host-install(3) broken-step build-amd64-xsm host-install(3) broken-step build-i386-pvops host-install(3) broken-step build-i386 host-install(3) broken-step build-amd64-pvops host-install(3) broken-step build-amd64 host-install(3) Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 104664: regressions - trouble: blocked/broken/fail
flight 104664 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104664/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z1 days Failing since104642 2017-01-25 10:01:54 Z0 days 10 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days7 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.16 baseline-only test] 68457: tolerable trouble: blocked/broken/fail/pass
This run is configured for baseline tests only. flight 68457 linux-3.16 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68457/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 2 hosts-allocate broken never pass build-arm64-pvops 2 hosts-allocate broken never pass build-arm64-xsm 2 hosts-allocate broken never pass build-arm64 3 capture-logs broken never pass build-arm64-xsm 3 capture-logs broken never pass build-arm64-pvops 3 capture-logs broken never pass test-armhf-armhf-libvirt 13 saverestore-support-check fail baseline untested test-armhf-armhf-xl-xsm 11 guest-start fail baseline untested test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail baseline untested test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail baseline untested test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail baseline untested test-amd64-amd64-xl-qemuu-debianhvm-amd64 14 guest-saverestore.2 fail baseline untested test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail baseline untested test-amd64-i386-libvirt17 guest-start/debian.repeat fail baseline untested test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10 fail never pass test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: linuxc66d7e6c732db87a18d1530ea120763a666113aa jobs: build-amd64-xsm pass build-arm64-xsm broken build-armhf-xsm pass build-i386-xsm pass build-amd64
[Xen-devel] [xen-unstable-smoke test] 104661: regressions - trouble: blocked/broken/fail
flight 104661 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104661/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z1 days Failing since104642 2017-01-25 10:01:54 Z0 days9 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days6 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm/monitor: flush the icache during SMC traps
On 01/25/2017 10:02 PM, Tamas K Lengyel wrote: > During an SMC trap it is possible that the user may change the memory > from where the SMC was fetched. However, without flushing the icache > the SMC may still trigger if the pCPU was idle during the trap. Flush > the icache to ensure consistency. > > Signed-off-by: Tamas K Lengyel Fair enough, assuming the ARM maintainers have no objections: Acked-by: Razvan Cojocaru Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] arm/monitor: flush the icache during SMC traps
During an SMC trap it is possible that the user may change the memory from where the SMC was fetched. However, without flushing the icache the SMC may still trigger if the pCPU was idle during the trap. Flush the icache to ensure consistency. Signed-off-by: Tamas K Lengyel --- Cc: Razvan Cojocaru Cc: Stefano Stabellini Cc: Julien Grall --- xen/arch/arm/monitor.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/arm/monitor.c b/xen/arch/arm/monitor.c index 59ce8f635f..ae1b97993f 100644 --- a/xen/arch/arm/monitor.c +++ b/xen/arch/arm/monitor.c @@ -63,6 +63,9 @@ int monitor_smc(void) .reason = VM_EVENT_REASON_PRIVILEGED_CALL }; +/* Nuke the icache as the memory may get changed underneath us. */ +invalidate_icache(); + return monitor_traps(current, 1, &req); } -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 104643: tolerable FAIL - PUSHED
flight 104643 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104643/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104633 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104633 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104633 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104633 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 104633 test-amd64-amd64-xl-rtds 9 debian-install fail like 104633 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass version targeted for testing: qemuud264871209400fa22796d403c9e1ab288d4a5c6b baseline version: qemuua9e404600a9bd1e6a26431fc89e5069092e67f14 Last test of basis 104633 2017-01-24 23:44:04 Z0 days Testing same since 104643 2017-01-25 11:15:48 Z0 days1 attempts People who touched revisions under test: Ashijeet Acharya Dr. David Alan Gilbert Greg Kurz Jianjun Duan John Snow Juan Quintela Pankaj Gupta Peter Maydell zhanghailiang jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-
[Xen-devel] [xen-unstable-smoke test] 104658: regressions - trouble: blocked/broken/fail
flight 104658 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104658/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z1 days Failing since104642 2017-01-25 10:01:54 Z0 days8 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days5 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 2/3] x86/xen/time: setup vcpu 0 time info page
On 01/25/2017 12:33 PM, Joao Martins wrote:
> In order to support pvclock vdso on xen we need to setup the time
> info page for vcpu 0 and register the page with Xen using the
> VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall
> will also forcefully update the pvti which will set some of the
> necessary flags for vdso. Afterwards we check if it supports the
> PVCLOCK_TSC_STABLE_BIT flag which is mandatory for having
> vdso/vsyscall support. And if so, it will set the cpu 0 pvti that
> will be later on used when mapping the vdso image.
>
> The xen headers are also updated to include the new hypercall for
> registering the secondary vcpu_time_info struct.
>
> Signed-off-by: Joao Martins
> ---
> Changes since RFC:
> (Comments from Boris and David)
> * Remove Kconfig option
> * Use get_zeroed_page/free/page
> * Remove the hypercall availability check
> * Unregister pvti with arg.addr.v = NULL if stable bit isn't supported.
> (New)
> * Set secondary copy on restore such that it works on migration.
> * Drop global xen_clock variable and stash it locally on
> xen_setup_vsyscall_time_info.
> * WARN_ON(ret) if we fail to unregister the pvti.
> ---
> arch/x86/xen/enlighten.c | 2 ++
> arch/x86/xen/time.c | 51
>
> arch/x86/xen/xen-ops.h | 1 +
> include/xen/interface/vcpu.h | 28
> 4 files changed, 82 insertions(+)
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 51ef952..15d271d 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -270,6 +270,8 @@ void xen_vcpu_restore(void)
This is called for PV only. What about HVM?
> HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL))
> BUG();
> }
> +
> + xen_setup_vsyscall_time_info(0);
Do we need to tear down time memory area on VCPU suspend?
> }
>
> static void __init xen_banner(void)
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 1e69956..e90f703 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -367,6 +367,56 @@ static const struct pv_time_ops xen_time_ops __initconst
> = {
> .steal_clock = xen_steal_clock,
> };
>
> +int xen_setup_vsyscall_time_info(int cpu)
> +{
> + struct pvclock_vsyscall_time_info *xen_clock;
> + struct vcpu_register_time_memory_area t;
> + struct pvclock_vcpu_time_info *pvti;
> + unsigned long addr;
> + u8 flags;
> + int ret;
> +
> + addr = get_zeroed_page(GFP_KERNEL);
> + if (!addr)
> + return -ENOMEM;
> +
> + xen_clock = (struct pvclock_vsyscall_time_info *) addr;
> + memset(xen_clock, 0, PAGE_SIZE);
You don't really need addr and there is no reason to memset the page to
zero, given that you got it with get_zeroed_page().
> +
> + t.addr.v = &xen_clock->pvti;
> +
> + ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area,
> + cpu, &t);
> +
> + if (ret) {
> + pr_debug("xen: cannot register vcpu_time_info err %d\n", ret);
pr_warn() would be more appropriate I think. You also have blank line
before 'if'.
> + free_page(addr);
> + return ret;
> + }
> +
> + pvti = &xen_clock->pvti;
> + flags = pvti->flags;
I don't think you need these, given that you only reference flags once
below.
> +
> + if (!(flags & PVCLOCK_TSC_STABLE_BIT)) {
> + t.addr.v = NULL;
> + ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area,
> + cpu, &t);
> + if (!ret)
> + free_page(addr);
> +
> + WARN_ON(ret);
Did someone ask for WARN_ON()? (from your changelog it looks like it
could have been either David or me). I think pr_warn() is sufficient,
just like above.
> + pr_debug("xen: VCLOCK_PVCLOCK not supported\n");
pr_notice()
-boris
> + return -ENOTSUPP;
> + }
> +
> + pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT);
> + pvclock_set_pvti_cpu0_va(xen_clock);
> +
> + xen_clocksource.archdata.vclock_mode = VCLOCK_PVCLOCK;
> +
> + return 0;
> +}
> +
> static void __init xen_time_init(void)
> {
> int cpu = smp_processor_id();
> @@ -393,6 +443,7 @@ static void __init xen_time_init(void)
> setup_force_cpu_cap(X86_FEATURE_TSC);
>
> xen_setup_runstate_info(cpu);
> + xen_setup_vsyscall_time_info(cpu);
> xen_setup_timer(cpu);
> xen_setup_cpu_clockevents();
>
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index ac0a2b0..4036d15 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -66,6 +66,7 @@ void __init xen_vmalloc_p2m_tree(void);
> void xen_init_irq_ops(void);
> void xen_setup_timer(int cpu);
> void xen_setup_runstate_info(int cpu);
> +int xen_setup_vsyscall_time_info(int cpu);
> void xen_teardown_timer(int cpu);
> u64 xen_clockso
[Xen-devel] [linux-next test] 104640: tolerable FAIL
flight 104640 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/104640/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail baseline untested test-amd64-amd64-xl-credit2 15 guest-localmigrate fail baseline untested test-amd64-amd64-xl 17 guest-localmigrate/x10 fail baseline untested test-amd64-i386-xl 17 guest-localmigrate/x10 fail baseline untested test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline untested test-amd64-amd64-xl-rtds 14 guest-saverestore fail baseline untested test-amd64-i386-xl-xsm 17 guest-localmigrate/x10 fail baseline untested test-armhf-armhf-libvirt 13 saverestore-support-check fail baseline untested test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail baseline untested test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail baseline untested test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail baseline untested test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail baseline untested test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail baseline untested build-arm64-xsm 5 xen-buildfail never pass build-arm64 5 xen-buildfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: linuxf37208bc3c9c2f811460ef264909dfbc7f605a60 jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf
Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document
Hi Stefano, On 24/01/17 20:07, Stefano Stabellini wrote: On Tue, 24 Jan 2017, Julien Grall wrote: ## Discovering and register hostbridge Both ACPI and Device Tree do not provide enough information to fully instantiate an host bridge driver. In the case of ACPI, some data may come from ASL, The data available from ASL is just to initialize quirks and non-ECAM controllers, right? Given that SBSA mandates ECAM, and we assume that ACPI is mostly (if not only) for servers, then I think it is safe to say that in the case of ACPI we should have all the info to fully instantiate an host bridge driver. From the spec, the MCFG will only describe host bridge available at boot (see 4.2 in "PCI firmware specification, rev 3.2"). All the other host bridges will be described in ASL. So we need DOM0 to feed Xen about the latter host bridges. Unfortunately PCI specs are only accessible by PCI SIG members organizations. In other words, I cannot read the doc. Could you please explain what kind of host bridges are not expected to be available at boot? Do you know of any examples? Roger answered to this answer in on a reply to this e-mail. So I will skip it. Let me know if you need for details. whilst for Device Tree the segment number is not available. So Xen needs to rely on DOM0 to discover the host bridges and notify Xen with all the relevant informations. This will be done via a new hypercall PHYSDEVOP_pci_host_bridge_add. The layout of the structure will be: I understand that the main purpose of this hypercall is to get Xen and Dom0 to agree on the segment numbers, but why is it necessary? If Dom0 has an emulated contoller like any other guest, do we care what segment numbers Dom0 will use? I was not planning to have a emulated controller for DOM0. The physical one is not necessarily ECAM compliant so we would have to either emulate the physical one (meaning multiple different emulation) or an ECAM compliant. The latter is not possible because you don't know if there is enough free MMIO space for the emulation. In the case on ARM, I don't see much the point to emulate the host bridge for DOM0. The only thing we need in Xen is to access the configuration space, we don't have about driving the host bridge. So I would let DOM0 dealing with that. Also, I don't see any reason for ARM to trap DOM0 configuration space access. The MSI will be configured using the interrupt controller and it is a trusted Domain. These last you sentences raise a lot of questions. Maybe I am missing something. You might want to clarify the strategy for Dom0 and DomUs, and how they differ, in the next version of the doc. At some point you wrote "Instantiation of a specific driver for the host controller can be easily done if Xen has the information to detect it. However, those drivers may require resources described in ASL." Does it mean you plan to drive the physical host bridge from Xen and Dom0 simultaneously? I may miss some bits, so feel free to correct me if I am wrong. My understanding is host bridge can be divided in 2 parts: - Initialization of the host bridge - Access the configuration space For generic host bridge, the initialization is inexistent. However some host bridge (e.g xgene, xilinx) may require some specific setup and also configuring clocks. Given that Xen only requires to access the configuration space, I was thinking to let DOM0 initialization the host bridge. This would avoid to import a lot of code in Xen, however this means that we need to know when the host bridge has been initialized before accessing the configuration space. Now regarding the configuration space, I think we can divide in 2 category: - indirect access, the configuration space are multiplexed. An example would be the legacy method on x86 (e.g 0xcf8 and 0xcfc). A similar method is used for x-gene PCI driver ([1]). - ECAM like access, where each PCI configuration space will have it is own address space. I said "ECAM like" because some host bridge will require some bits fiddling when accessing register (see thunder-ecam [2]) There are also host bridges that mix both indirect access and ECAM like access depending on the device configuration space accessed (see thunder-pem [3]). When using ECAM like host bridge, I don't think it will be an issue to have both DOM0 and Xen accessing configuration space at the same time. Although, we need to define who is doing what. In general case, DOM0 should not touched an assigned PCI device. The only possible interaction would be resetting a device (see my answer below). When using indirect access, we cannot let DOM0 and Xen accessing any PCI configuration space at the same time. So I think we would have to emulate the physical host controller. Unless we have a big requirement to trap DOM0 access to the configuration space, I would only keep the emulation to the strict minimum (e.g for indirect access) to avoid ending-up handling all the qu
Re: [Xen-devel] [PATCH v2 2/3] xen-platform: add support for unplugging NVMe disks...
On Wed, 25 Jan 2017, Paul Durrant wrote: > On 25 January 2017, at 17:54, Stefano Stabellini > wrote: > > > > > > >On Wed, 25 Jan 2017, Paul Durrant wrote: > >> > -Original Message- > >> > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > >> > Sent: 24 January 2017 23:49 > >> > To: Paul Durrant > >> > Cc: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org; Stefano > >> > Stabellini ; Anthony Perard > >> > ; Michael S. Tsirkin ; Paolo > >> > Bonzini ; Richard Henderson ; > >> > Eduardo Habkost ; o...@aepfle.de > >> > Subject: Re: [PATCH v2 2/3] xen-platform: add support for unplugging NVMe > >> > disks... > >> > > >> > On Tue, 24 Jan 2017, Paul Durrant wrote: > >> > > ...not just IDE and SCSI. > >> > > > >> > > This patch allows the Xen tool-stack to fully support of NVMe as an > >> > > emulated disk type. > >> > > > >> > > Signed-off-by: Paul Durrant > >> > > >> > Please update docs/misc/hvm-emulated-unplug.markdown in the Xen > >> > repository first. It might be also worth clarifying that `1` actually > >> > means all disks, not just IDE disks. Then, please add a reference to > >> > that commit in the description of this patch. > >> > > >> > >> Patch posted to remove 'IDE' from the documentation for value '1'. > >> Awaiting ack. > >Done. > >When you repost this patch, could you also add to the description a > >reference to the commit that enables NVMe in QEMU with Xen? I guess it > >is a libxl commit? > > I think there is a chicken and egg issue here. Wei wanted to ensure that QEMU > is able to unplug > NVMe drives before accepting my patch to libxl. No problems. In that case, please add a link to the xen-devel email thread. > >> > > --- > >> > > Cc: Stefano Stabellini > >> > > Cc: Anthony Perard > >> > > Cc: "Michael S. Tsirkin" > >> > > Cc: Paolo Bonzini > >> > > Cc: Richard Henderson > >> > > Cc: Eduardo Habkost > >> > > --- > >> > > hw/i386/xen/xen_platform.c | 1 + > >> > > 1 file changed, 1 insertion(+) > >> > > > >> > > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c > >> > > index f50915f..7d41ebb 100644 > >> > > --- a/hw/i386/xen/xen_platform.c > >> > > +++ b/hw/i386/xen/xen_platform.c > >> > > @@ -120,6 +120,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, > >> > void *o) > >> > > break; > >> > > > >> > > case PCI_CLASS_STORAGE_SCSI: > >> > > + case PCI_CLASS_STORAGE_EXPRESS: > >> > > object_unparent(OBJECT(d)); > >> > > break; > >> > > > >> > > -- > >> > > 2.1.4 > >> > > > >> > > > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] xen-platform: add support for unplugging NVMe disks...
On 25 January 2017, at 17:54, Stefano Stabellini wrote: > > >On Wed, 25 Jan 2017, Paul Durrant wrote: >> > -Original Message- >> > From: Stefano Stabellini [mailto:sstabell...@kernel.org] >> > Sent: 24 January 2017 23:49 >> > To: Paul Durrant >> > Cc: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org; Stefano >> > Stabellini ; Anthony Perard >> > ; Michael S. Tsirkin ; Paolo >> > Bonzini ; Richard Henderson ; >> > Eduardo Habkost ; o...@aepfle.de >> > Subject: Re: [PATCH v2 2/3] xen-platform: add support for unplugging NVMe >> > disks... >> > >> > On Tue, 24 Jan 2017, Paul Durrant wrote: >> > > ...not just IDE and SCSI. >> > > >> > > This patch allows the Xen tool-stack to fully support of NVMe as an >> > > emulated disk type. >> > > >> > > Signed-off-by: Paul Durrant >> > >> > Please update docs/misc/hvm-emulated-unplug.markdown in the Xen >> > repository first. It might be also worth clarifying that `1` actually >> > means all disks, not just IDE disks. Then, please add a reference to >> > that commit in the description of this patch. >> > >> >> Patch posted to remove 'IDE' from the documentation for value '1'. Awaiting >> ack. >Done. >When you repost this patch, could you also add to the description a >reference to the commit that enables NVMe in QEMU with Xen? I guess it >is a libxl commit? I think there is a chicken and egg issue here. Wei wanted to ensure that QEMU is able to unplug NVMe drives before accepting my patch to libxl. Paul >> > > --- >> > > Cc: Stefano Stabellini >> > > Cc: Anthony Perard >> > > Cc: "Michael S. Tsirkin" >> > > Cc: Paolo Bonzini >> > > Cc: Richard Henderson >> > > Cc: Eduardo Habkost >> > > --- >> > > hw/i386/xen/xen_platform.c | 1 + >> > > 1 file changed, 1 insertion(+) >> > > >> > > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c >> > > index f50915f..7d41ebb 100644 >> > > --- a/hw/i386/xen/xen_platform.c >> > > +++ b/hw/i386/xen/xen_platform.c >> > > @@ -120,6 +120,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, >> > void *o) >> > > break; >> > > >> > > case PCI_CLASS_STORAGE_SCSI: >> > > +case PCI_CLASS_STORAGE_EXPRESS: >> > > object_unparent(OBJECT(d)); >> > > break; >> > > >> > > -- >> > > 2.1.4 >> > > >> > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 104655: regressions - trouble: blocked/broken/fail
flight 104655 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104655/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z0 days Failing since104642 2017-01-25 10:01:54 Z0 days7 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days4 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] xen-platform: add support for unplugging NVMe disks...
On Wed, 25 Jan 2017, Paul Durrant wrote: > > -Original Message- > > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > > Sent: 24 January 2017 23:49 > > To: Paul Durrant > > Cc: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org; Stefano > > Stabellini ; Anthony Perard > > ; Michael S. Tsirkin ; Paolo > > Bonzini ; Richard Henderson ; > > Eduardo Habkost ; o...@aepfle.de > > Subject: Re: [PATCH v2 2/3] xen-platform: add support for unplugging NVMe > > disks... > > > > On Tue, 24 Jan 2017, Paul Durrant wrote: > > > ...not just IDE and SCSI. > > > > > > This patch allows the Xen tool-stack to fully support of NVMe as an > > > emulated disk type. > > > > > > Signed-off-by: Paul Durrant > > > > Please update docs/misc/hvm-emulated-unplug.markdown in the Xen > > repository first. It might be also worth clarifying that `1` actually > > means all disks, not just IDE disks. Then, please add a reference to > > that commit in the description of this patch. > > > > Patch posted to remove 'IDE' from the documentation for value '1'. Awaiting > ack. Done. When you repost this patch, could you also add to the description a reference to the commit that enables NVMe in QEMU with Xen? I guess it is a libxl commit? > > > --- > > > Cc: Stefano Stabellini > > > Cc: Anthony Perard > > > Cc: "Michael S. Tsirkin" > > > Cc: Paolo Bonzini > > > Cc: Richard Henderson > > > Cc: Eduardo Habkost > > > --- > > > hw/i386/xen/xen_platform.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c > > > index f50915f..7d41ebb 100644 > > > --- a/hw/i386/xen/xen_platform.c > > > +++ b/hw/i386/xen/xen_platform.c > > > @@ -120,6 +120,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, > > void *o) > > > break; > > > > > > case PCI_CLASS_STORAGE_SCSI: > > > +case PCI_CLASS_STORAGE_EXPRESS: > > > object_unparent(OBJECT(d)); > > > break; > > > > > > -- > > > 2.1.4 > > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/7] x86emul/test: remove extraneous commas in debug messages
On 25/01/17 16:36, Wei Liu wrote:
> On Wed, Jan 25, 2017 at 09:33:05AM -0700, Jan Beulich wrote:
> On 25.01.17 at 16:44, wrote:
>>> --- a/tools/tests/x86_emulator/test_x86_emulator.c
>>> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
>>> @@ -42,7 +42,7 @@ static int read(
>>> struct x86_emulate_ctxt *ctxt)
>>> {
>>> if ( verbose )
>>> -printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset,
>>> bytes);
>>> +printf("** %s(%u, %p, %u)\n", __func__, seg, (void *)offset,
>>> bytes);
>> Back when these got added, Andrew did explain why he put them
>> there.
>>
> Eh, OK. If there is a reason for this, I will just drop this patch. It's
> not essential anyway.
>
> It just looks rather odd to me to have so many extraneous commas. ;-)
This is my debugging shorthand, which associates values with the
positional parameters.
In this case it is quite trivial to read, but debugging elsewhere in the
hypervisor is rather more complicated (some of the pagetable code
particular takes large numbers of parameters).
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] docs/misc: update the meaning of the 'disk unplug' flag
On Wed, 25 Jan 2017, Paul Durrant wrote: > The documentation states that a value of '1' will cause unplug of > emulated IDE disks. This is not quite correct, as QEMU will also unplug > emulated SCSI disks at the same time. > > Signed-off-by: Paul Durrant Reviewed-by: Stefano Stabellini > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Konrad Rzeszutek Wilk > Cc: Stefano Stabellini > Cc: Tim Deegan > Cc: Wei Liu > --- > docs/misc/hvm-emulated-unplug.markdown | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/docs/misc/hvm-emulated-unplug.markdown > b/docs/misc/hvm-emulated-unplug.markdown > index 256cea2..8ead0c5 100644 > --- a/docs/misc/hvm-emulated-unplug.markdown > +++ b/docs/misc/hvm-emulated-unplug.markdown > @@ -34,7 +34,7 @@ drivers): > 6. The drivers write a two-byte bitmask of devices to unplug to IO > port `0x10`. The defined fields are: > > - * `1` -- All IDE disks (not including CD drives) > + * `1` -- All emulated disks (not including CD drives) >* `2` -- All emulated NICs >* `4` -- All IDE disks except for the primary master (not including CD > drives) > -- > 2.1.4 > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 2/3] x86/xen/time: setup vcpu 0 time info page
In order to support pvclock vdso on xen we need to setup the time
info page for vcpu 0 and register the page with Xen using the
VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall
will also forcefully update the pvti which will set some of the
necessary flags for vdso. Afterwards we check if it supports the
PVCLOCK_TSC_STABLE_BIT flag which is mandatory for having
vdso/vsyscall support. And if so, it will set the cpu 0 pvti that
will be later on used when mapping the vdso image.
The xen headers are also updated to include the new hypercall for
registering the secondary vcpu_time_info struct.
Signed-off-by: Joao Martins
---
Changes since RFC:
(Comments from Boris and David)
* Remove Kconfig option
* Use get_zeroed_page/free/page
* Remove the hypercall availability check
* Unregister pvti with arg.addr.v = NULL if stable bit isn't supported.
(New)
* Set secondary copy on restore such that it works on migration.
* Drop global xen_clock variable and stash it locally on
xen_setup_vsyscall_time_info.
* WARN_ON(ret) if we fail to unregister the pvti.
---
arch/x86/xen/enlighten.c | 2 ++
arch/x86/xen/time.c | 51
arch/x86/xen/xen-ops.h | 1 +
include/xen/interface/vcpu.h | 28
4 files changed, 82 insertions(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 51ef952..15d271d 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -270,6 +270,8 @@ void xen_vcpu_restore(void)
HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL))
BUG();
}
+
+ xen_setup_vsyscall_time_info(0);
}
static void __init xen_banner(void)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 1e69956..e90f703 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -367,6 +367,56 @@ static const struct pv_time_ops xen_time_ops __initconst =
{
.steal_clock = xen_steal_clock,
};
+int xen_setup_vsyscall_time_info(int cpu)
+{
+ struct pvclock_vsyscall_time_info *xen_clock;
+ struct vcpu_register_time_memory_area t;
+ struct pvclock_vcpu_time_info *pvti;
+ unsigned long addr;
+ u8 flags;
+ int ret;
+
+ addr = get_zeroed_page(GFP_KERNEL);
+ if (!addr)
+ return -ENOMEM;
+
+ xen_clock = (struct pvclock_vsyscall_time_info *) addr;
+ memset(xen_clock, 0, PAGE_SIZE);
+
+ t.addr.v = &xen_clock->pvti;
+
+ ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area,
+cpu, &t);
+
+ if (ret) {
+ pr_debug("xen: cannot register vcpu_time_info err %d\n", ret);
+ free_page(addr);
+ return ret;
+ }
+
+ pvti = &xen_clock->pvti;
+ flags = pvti->flags;
+
+ if (!(flags & PVCLOCK_TSC_STABLE_BIT)) {
+ t.addr.v = NULL;
+ ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area,
+cpu, &t);
+ if (!ret)
+ free_page(addr);
+
+ WARN_ON(ret);
+ pr_debug("xen: VCLOCK_PVCLOCK not supported\n");
+ return -ENOTSUPP;
+ }
+
+ pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT);
+ pvclock_set_pvti_cpu0_va(xen_clock);
+
+ xen_clocksource.archdata.vclock_mode = VCLOCK_PVCLOCK;
+
+ return 0;
+}
+
static void __init xen_time_init(void)
{
int cpu = smp_processor_id();
@@ -393,6 +443,7 @@ static void __init xen_time_init(void)
setup_force_cpu_cap(X86_FEATURE_TSC);
xen_setup_runstate_info(cpu);
+ xen_setup_vsyscall_time_info(cpu);
xen_setup_timer(cpu);
xen_setup_cpu_clockevents();
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index ac0a2b0..4036d15 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -66,6 +66,7 @@ void __init xen_vmalloc_p2m_tree(void);
void xen_init_irq_ops(void);
void xen_setup_timer(int cpu);
void xen_setup_runstate_info(int cpu);
+int xen_setup_vsyscall_time_info(int cpu);
void xen_teardown_timer(int cpu);
u64 xen_clocksource_read(void);
void xen_setup_cpu_clockevents(void);
diff --git a/include/xen/interface/vcpu.h b/include/xen/interface/vcpu.h
index 98188c8..8da788c 100644
--- a/include/xen/interface/vcpu.h
+++ b/include/xen/interface/vcpu.h
@@ -178,4 +178,32 @@ DEFINE_GUEST_HANDLE_STRUCT(vcpu_register_vcpu_info);
/* Send an NMI to the specified VCPU. @extra_arg == NULL. */
#define VCPUOP_send_nmi 11
+
+/*
+ * Register a memory location to get a secondary copy of the vcpu time
+ * parameters. The master copy still exists as part of the vcpu shared
+ * memory area, and this secondary copy is updated whenever the master copy
+ * is updated (and using the same versioning scheme for synchronisation).
+ *
+ * The intent is that this copy may be mapped (RO) into userspace s
[Xen-devel] [PATCH v1 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va
Right now there is only a pvclock_pvti_cpu0_va() which is defined
on kvmclock since:
commit dac16fba6fc5
("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")
The only user of this interface was kvm. This commit moves
pvclock_pvti_cpu0_va to pvclock which is a more generic place to have it
and adds the correspondent setter routine for it. This allows other
pvclock-based clocksources to use it, such as Xen.
Signed-off-by: Joao Martins
---
Changes since RFC:
(Comments from Andy Lutomirski)
* Add WARN_ON(vclock_was_used(VCLOCK_PVCLOCK)) to
pvclock_set_pvti_cpu0_va
---
arch/x86/include/asm/pvclock.h | 22 +-
arch/x86/kernel/kvmclock.c | 6 +-
arch/x86/kernel/pvclock.c | 13 +
3 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 448cfe1..58399e1 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -4,15 +4,6 @@
#include
#include
-#ifdef CONFIG_KVM_GUEST
-extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
-#else
-static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
-{
- return NULL;
-}
-#endif
-
/* some helper functions for xen and kvm pv clock sources */
u64 pvclock_clocksource_read(struct pvclock_vcpu_time_info *src);
u8 pvclock_read_flags(struct pvclock_vcpu_time_info *src);
@@ -101,4 +92,17 @@ struct pvclock_vsyscall_time_info {
#define PVTI_SIZE sizeof(struct pvclock_vsyscall_time_info)
+#ifdef CONFIG_PARAVIRT_CLOCK
+void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti);
+struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
+#else
+static inline void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info
*pvti)
+{
+}
+static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
+{
+ return NULL;
+}
+#endif
+
#endif /* _ASM_X86_PVCLOCK_H */
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 2a5cafd..9dfbb79 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -45,11 +45,6 @@ early_param("no-kvmclock", parse_no_kvmclock);
static struct pvclock_vsyscall_time_info *hv_clock;
static struct pvclock_wall_clock wall_clock;
-struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
-{
- return hv_clock;
-}
-
/*
* The wallclock is the time of day when we booted. Since then, some time may
* have elapsed since the hypervisor wrote the data. So we try to account for
@@ -330,6 +325,7 @@ int __init kvm_setup_vsyscall_timeinfo(void)
return 1;
}
+ pvclock_set_pvti_cpu0_va(hv_clock);
put_cpu();
kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 9e93fe5..b281060 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -23,8 +23,10 @@
#include
#include
#include
+#include
static u8 valid_flags __read_mostly = 0;
+static struct pvclock_vsyscall_time_info *pvti_cpu0_va __read_mostly = NULL;
void pvclock_set_flags(u8 flags)
{
@@ -142,3 +144,14 @@ void pvclock_read_wallclock(struct pvclock_wall_clock
*wall_clock,
set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
}
+
+void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti)
+{
+ WARN_ON(vclock_was_used(VCLOCK_PVCLOCK));
+ pvti_cpu0_va = pvti;
+}
+
+struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
+{
+ return pvti_cpu0_va;
+}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 0/3] x86/xen: pvclock vdso support
Hey, This small series presents support for vDSO for Xen domains. PVCLOCK_TSC_STABLE_BIT can be set starting Xen 4.8 which is required for vdso time related calls. In order to have it on, you need to have the hypervisor clocksource be TSC e.g. with the following boot params "clocksource=tsc tsc=stable:socket". Series is structured as following: Patch 1 streamlines pvti page get/set in pvclock for both of its users Patch 2 registers the pvti page on Xen and sets it in pvclock accordingly and Patch 3 (new in this version) adds an entry to maintainers for tracking pvclock ABI changes. Changelog since RFC is included in individual patches. Any comments/suggestions are welcome. Thanks, Joao Joao Martins (3): x86/pvclock: add setter for pvclock_pvti_cpu0_va x86/xen/time: setup vcpu 0 time info page MAINTAINERS: xen, kvm: track pvclock-abi.h changes MAINTAINERS| 2 ++ arch/x86/include/asm/pvclock.h | 22 ++ arch/x86/kernel/kvmclock.c | 6 + arch/x86/kernel/pvclock.c | 13 +++ arch/x86/xen/enlighten.c | 2 ++ arch/x86/xen/time.c| 51 ++ arch/x86/xen/xen-ops.h | 1 + include/xen/interface/vcpu.h | 28 +++ 8 files changed, 111 insertions(+), 14 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes
This file defines an ABI shared between guest and hypervisor(s) (KVM, Xen) and as such there should be an correspondent entry in MAINTAINERS file. Notice that there's already a text notice at the top of the header file, hence this commit simply enforces it more explicitly and have both peers noticed when such changes happen. Signed-off-by: Joao Martins --- This was suggested by folks at xen-devel as we missed some of the ABI additions (e.g. flags field in pvti, TSC stable bit) - so this patch is to help preventing that from happening. Alternatively I could instead add a "PVCLOCK ABI" section in this file with the two mailing lists. --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 26edd83..c4315d1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7041,6 +7041,7 @@ F:Documentation/virtual/kvm/ F: arch/*/kvm/ F: arch/x86/kernel/kvm.c F: arch/x86/kernel/kvmclock.c +F: arch/x86/include/asm/pvclock-abi.h F: arch/*/include/asm/kvm* F: include/linux/kvm* F: include/uapi/linux/kvm* @@ -13483,6 +13484,7 @@ M: Juergen Gross L: xen-de...@lists.xenproject.org (moderated for non-subscribers) T: git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git S: Supported +F: arch/x86/include/asm/pvclock-abi.h F: arch/x86/xen/ F: drivers/*/xen-*front.c F: drivers/xen/ -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/VMX: fix vmentry failure with TSX bits in LBR
During VM entry, H/W will automatically load guest's MSRs from MSR-load
area in the same way as they would be written by WRMSR.
However, under the following conditions:
1. LBR (Last Branch Record) MSRs were placed in the MSR-load area
2. Address format of LBR includes TSX bits 61:62
3. CPU has TSX support disabled
VM entry will fail with a message in the log similar to:
(XEN) [ 97.239514] d1v0 vmentry failure (reason 0x8022): MSR loading
(entry 3)
(XEN) [ 97.239516] msr 0680 val 1fff80102e60 (mbz 0)
This happens because of the following behaviour:
- When capturing branches, LBR H/W will always clear bits 61:62
regardless of the sign extension
- For WRMSR, bits 61:62 are considered the part of the sign extension
This bug affects only certain pCPUs (e.g. Haswell) with vCPUs that
use LBR. Fix it by sign-extending TSX bits in all LBR entries during
VM entry in affected cases.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vmx.c | 68 ++
xen/include/asm-x86/cpufeature.h | 3 ++
xen/include/asm-x86/hvm/vmx/vmcs.h | 2 ++
3 files changed, 73 insertions(+)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index a5e5ffd..586aaca 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2241,6 +2241,25 @@ static void pi_notification_interrupt(struct
cpu_user_regs *regs)
raise_softirq(VCPU_KICK_SOFTIRQ);
}
+static bool __read_mostly vmx_lbr_tsx_fixup_needed;
+
+static void __init vmx_lbr_tsx_fixup_check(void)
+{
+bool tsx_support = cpu_has_hle || cpu_has_rtm;
+u64 caps;
+u32 lbr_format;
+
+if ( !cpu_has_pdcm )
+return;
+
+rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
+/* Lower 6 bits define the format of the address in the LBR stack */
+lbr_format = caps & 0x3f;
+
+/* 000100B -- TSX info is reported in the upper bits of 'FROM' registers */
+vmx_lbr_tsx_fixup_needed = !tsx_support && lbr_format == 0x4;
+}
+
const struct hvm_function_table * __init start_vmx(void)
{
set_in_cr4(X86_CR4_VMXE);
@@ -2310,6 +2329,8 @@ const struct hvm_function_table * __init start_vmx(void)
setup_vmcs_dump();
+vmx_lbr_tsx_fixup_check();
+
return &vmx_function_table;
}
@@ -2833,7 +2854,11 @@ static int vmx_msr_write_intercept(unsigned int msr,
uint64_t msr_content)
for ( ; (rc == 0) && lbr->count; lbr++ )
for ( i = 0; (rc == 0) && (i < lbr->count); i++ )
if ( (rc = vmx_add_guest_msr(lbr->base + i)) == 0 )
+{
vmx_disable_intercept_for_msr(v, lbr->base + i,
MSR_TYPE_R | MSR_TYPE_W);
+if ( vmx_lbr_tsx_fixup_needed )
+v->arch.hvm_vmx.lbr_tsx_fixup_enabled = true;
+}
}
if ( (rc < 0) ||
@@ -3854,6 +3879,46 @@ out:
}
}
+static void vmx_lbr_tsx_fixup(void)
+{
+static const u64 LBR_FROM_SIGNEXT_2MSB = (1ULL << 59) | (1ULL << 60);
+static u32 lbr_from_start = 0, lbr_from_end = 0, last_in_from_ip = 0;
+
+const struct lbr_info *lbr;
+const struct vcpu *curr = current;
+const unsigned int msr_count = curr->arch.hvm_vmx.msr_count;
+const const struct vmx_msr_entry *msr_area = curr->arch.hvm_vmx.msr_area;
+struct vmx_msr_entry *msr;
+
+if ( lbr_from_start == ~0U )
+return;
+
+if ( unlikely(lbr_from_start == 0) )
+{
+lbr = last_branch_msr_get();
+if ( lbr == NULL )
+{
+lbr_from_start = ~0U;
+return;
+}
+
+/* Warning: this depends on struct lbr_info[] layout! */
+last_in_from_ip = lbr[0].base;
+lbr_from_start = lbr[3].base;
+lbr_from_end = lbr_from_start + lbr[3].count;
+}
+
+if ( (msr = vmx_find_guest_msr(lbr_from_start)) != NULL )
+{
+/* Sign extend into bits 61:62 while preserving bit 63 */
+for ( ; msr < msr_area + msr_count && msr->index < lbr_from_end; msr++
)
+msr->data |= ((LBR_FROM_SIGNEXT_2MSB & msr->data) << 2);
+}
+
+if ( (msr = vmx_find_guest_msr(last_in_from_ip)) != NULL )
+msr->data |= ((LBR_FROM_SIGNEXT_2MSB & msr->data) << 2);
+}
+
void vmx_vmenter_helper(const struct cpu_user_regs *regs)
{
struct vcpu *curr = current;
@@ -3910,6 +3975,9 @@ void vmx_vmenter_helper(const struct cpu_user_regs *regs)
}
out:
+if ( unlikely(curr->arch.hvm_vmx.lbr_tsx_fixup_enabled) )
+vmx_lbr_tsx_fixup();
+
HVMTRACE_ND(VMENTRY, 0, 1/*cycles*/, 0, 0, 0, 0, 0, 0, 0);
__vmwrite(GUEST_RIP,regs->rip);
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index 39ad582..8e14728 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -78,6 +78,9 @@
#define cpu_has_cmp_legacy boot_cpu_has(X86_FEATURE_CMP_LEGACY)
#define cpu_has_tbmboot_cp
[Xen-devel] [PATCH 1/2] x86/VMX: introduce vmx_find_guest_msr()
Currently there can be up to 256 entries in a guest's MSR array and all
entries are stored in the order they were added. Such design requires
to perform a linear scan of the whole array in order to find the MSR
with required index which can be a costly operation.
To avoid that, reuse the existing code for heap sort and binary search
and optimize existing functions which deal with guest's MSR arrays.
This way the time complexity of searching for required MSR reduces from
linear to logarithmic.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vmcs.c| 80 +-
xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
2 files changed, 63 insertions(+), 18 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 59ef199..d04de8d 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1283,19 +1284,36 @@ static int construct_vmcs(struct vcpu *v)
return 0;
}
-int vmx_read_guest_msr(u32 msr, u64 *val)
+static int vmx_msr_entry_key_cmp(const void *key, const void *elt)
{
-struct vcpu *curr = current;
-unsigned int i, msr_count = curr->arch.hvm_vmx.msr_count;
+const u32 *msr = key;
+const struct vmx_msr_entry *entry = elt;
+
+if ( *msr > entry->index )
+return 1;
+if ( *msr < entry->index )
+return -1;
+return 0;
+}
+
+struct vmx_msr_entry *vmx_find_guest_msr(const u32 msr)
+{
+const struct vcpu *curr = current;
+const unsigned int msr_count = curr->arch.hvm_vmx.msr_count;
const struct vmx_msr_entry *msr_area = curr->arch.hvm_vmx.msr_area;
-for ( i = 0; i < msr_count; i++ )
+return bsearch(&msr, msr_area, msr_count, sizeof(struct vmx_msr_entry),
+ vmx_msr_entry_key_cmp);
+}
+
+int vmx_read_guest_msr(u32 msr, u64 *val)
+{
+const struct vmx_msr_entry *ent;
+
+if ( (ent = vmx_find_guest_msr(msr)) != NULL )
{
-if ( msr_area[i].index == msr )
-{
-*val = msr_area[i].data;
+*val = ent->data;
return 0;
-}
}
return -ESRCH;
@@ -1303,22 +1321,37 @@ int vmx_read_guest_msr(u32 msr, u64 *val)
int vmx_write_guest_msr(u32 msr, u64 val)
{
-struct vcpu *curr = current;
-unsigned int i, msr_count = curr->arch.hvm_vmx.msr_count;
-struct vmx_msr_entry *msr_area = curr->arch.hvm_vmx.msr_area;
+struct vmx_msr_entry *ent;
-for ( i = 0; i < msr_count; i++ )
+if ( (ent = vmx_find_guest_msr(msr)) != NULL )
{
-if ( msr_area[i].index == msr )
-{
-msr_area[i].data = val;
+ent->data = val;
return 0;
-}
}
return -ESRCH;
}
+static void vmx_msr_entry_swap(void *a, void *b, int size)
+{
+struct vmx_msr_entry *l = a, *r = b, tmp;
+
+tmp = *l;
+*l = *r;
+*r = tmp;
+}
+
+static int vmx_msr_entry_cmp(const void *a, const void *b)
+{
+const struct vmx_msr_entry *l = a, *r = b;
+
+if ( l->index > r->index )
+return 1;
+if ( l->index < r->index )
+return -1;
+return 0;
+}
+
int vmx_add_msr(u32 msr, int type)
{
struct vcpu *curr = current;
@@ -1351,9 +1384,17 @@ int vmx_add_msr(u32 msr, int type)
__vmwrite(VM_EXIT_MSR_LOAD_ADDR, virt_to_maddr(*msr_area));
}
-for ( idx = 0; idx < *msr_count; idx++ )
-if ( (*msr_area)[idx].index == msr )
+if ( type == VMX_GUEST_MSR )
+{
+if ( vmx_find_guest_msr(msr) != NULL )
return 0;
+}
+else
+{
+for ( idx = 0; idx < *msr_count; idx++ )
+if ( (*msr_area)[idx].index == msr )
+return 0;
+}
if ( *msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
return -ENOSPC;
@@ -1369,6 +1410,9 @@ int vmx_add_msr(u32 msr, int type)
msr_area_elem->data = 0;
__vmwrite(VM_EXIT_MSR_STORE_COUNT, *msr_count);
__vmwrite(VM_ENTRY_MSR_LOAD_COUNT, *msr_count);
+
+sort(*msr_area, *msr_count, sizeof(struct vmx_msr_entry),
+ vmx_msr_entry_cmp, vmx_msr_entry_swap);
}
else
{
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 6c3d7ba..d01099e 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -589,6 +589,7 @@ enum vmx_insn_errno
void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
void vmx_enable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
+struct vmx_msr_entry *vmx_find_guest_msr(const u32 msr);
int vmx_read_guest_msr(u32 msr, u64 *val);
int vmx_write_guest_msr(u32 msr, u64 val);
int vmx_add_msr(u32 msr, int type);
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] x86/VMX: fix for vmentry failure with TSX bits in LBR
The first patch is a general optimization which is nice to have prior
to the second patch which contains the real fix.
A similar bug was fixed in Linux's perf subsystem in Jun 2016:
commit 19fc9ddd61e059cc45464bdf6e8fa304bb94080f
("perf/x86/intel: Fix MSR_LAST_BRANCH_FROM_x bug when no TSX")
But the issue affects virtualized systems in a more severe way since
all LBR entries have to be fixed during vmentry.
Sergey Dyasli (2):
x86/VMX: introduce vmx_find_guest_msr()
x86/VMX: fix vmentry failure with TSX bits in LBR
xen/arch/x86/hvm/vmx/vmcs.c| 80 +-
xen/arch/x86/hvm/vmx/vmx.c | 68
xen/include/asm-x86/cpufeature.h | 3 ++
xen/include/asm-x86/hvm/vmx/vmcs.h | 3 ++
4 files changed, 136 insertions(+), 18 deletions(-)
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 1/8] golang/xenlight: Create stub package
On Mon, Jan 23, 2017 at 4:43 PM, Ronald Rojas wrote:
> +func (Ctx *Context) Open() (err error) {
> + if Ctx.ctx != nil {
> + return
> + }
> +
> + ret := C.libxl_ctx_alloc(unsafe.Pointer(&Ctx.ctx), C.LIBXL_VERSION,
> 0, nil)
Just discovered there's a bug here (in code that I wrote obviously) --
you can't pass the last argument as nil; you have to include a logger.
Otherwise if you ever get an error you'll get a NULL dereference. :-)
I think the fastest thing to do to begin with would be to create a
"null" logger that just throws away all the data. Then at some point
(possibly not in your internship) someone can think about what a
proper logging interface looks like.
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 104651: regressions - trouble: blocked/broken/fail
flight 104651 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104651/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z0 days Failing since104642 2017-01-25 10:01:54 Z0 days6 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days3 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 104638: regressions - trouble: blocked/broken/fail/pass
flight 104638 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104638/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm 4 host-build-prep fail REGR. vs. 104614 Tests which are failing intermittently (not blocking): test-amd64-amd64-rumprun-amd64 3 host-install(3) broken in 104632 pass in 104638 test-amd64-amd64-i386-pvgrub 3 host-install(3) broken in 104632 pass in 104638 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 104632 pass in 104638 test-amd64-amd64-xl-qcow29 debian-di-install fail in 104632 pass in 104638 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail pass in 104632 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail in 104632 like 104614 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104614 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104614 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104614 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104614 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 104614 test-amd64-amd64-xl-rtds 9 debian-install fail like 104614 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104614 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 12 migrate-support-check fail in 104632 never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 104632 never pass test-armhf-armhf-xl-xsm 13 saverestore-support-check fail in 104632 never pass build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen
Re: [Xen-devel] [DOC v3] Xen transport for 9pfs
On Thu, Jan 05, 2017 at 04:54:37PM -0800, Stefano Stabellini wrote:
> Changes in v3:
> - clarify a few statements
> - rename port- to event-channel-
> - use grant_ref_t ref[1] instead of ref[]
>
> Changes in v2:
> - fix copy/paste error
> - rename ring-ref- to ring-ref
> - fix memory barriers
> - add "verify prod/cons against local copy"
> - add a paragraph on high level design
> - add a note on the maximum possible max-ring-page-order value
> - add mechanisms to avoid unnecessary evtchn notifications
>
> ---
>
> # Xen transport for 9pfs version 1
>
> ## Background
>
> 9pfs is a network filesystem protocol developed for Plan 9. 9pfs is very
> simple and describes a series of commands and responses. It is
> completely independent from the communication channels, in fact many
> clients and servers support multiple channels, usually called
> "transports". For example the Linux client supports tcp and unix
> sockets, fds, virtio and rdma.
>
>
> ### 9pfs protocol
>
> This document won't cover the full 9pfs specification. Please refer to
> this [paper] and this [website] for a detailed description of it.
> However it is useful to know that each 9pfs request and response has the
> following header:
>
> struct header {
> uint32_t size;
> uint8_t id;
> uint16_t tag;
> } __attribute__((packed));
>
> 0 4 57
> +-+--++
> | size |id|tag |
> +-+--++
>
> - *size*
> The size of the request or response.
>
> - *id*
> The 9pfs request or response operation.
>
> - *tag*
> Unique id that identifies a specific request/response pair. It is used
> to multiplex operations on a single channel.
>
> It is possible to have multiple requests in-flight at any given time.
>
>
> ## Rationale
>
> This document describes a Xen based transport for 9pfs, in the
> traditional PV frontend and backend format. The PV frontend is used by
> the client to send commands to the server. The PV backend is used by the
> 9pfs server to receive commands from clients and send back responses.
>
> The transport protocol supports multiple rings up to the maximum
> supported by the backend. The size of every ring is also configurable
> and can span multiple pages, up to the maximum supported by the backend
> (although it cannot be more than 2MB). The design is to exploit
> parallelism at the vCPU level and support multiple outstanding requests
> simultaneously.
>
> This document does not cover the 9pfs client/server design or
> implementation, only the transport for it.
What about the Paul's binary protocol..
https://patchwork.kernel.org/patch/7968201/ ?
He was using it as a side-channel for hash functions for the network
stack (Windows -> Linux)? Could that be used?
Or I suppose vice-versa - could Paul use your work here
instead of this network specific netif_ctrl?
>
>
> ## Xenstore
>
> The frontend and the backend connect via xenstore to exchange
> information. The toolstack creates front and back nodes with state
> [XenbusStateInitialising]. The protocol node name is **9pfs**.
Since this an opaque protocol to just push data back and forth
could it be more generic?
[edit: I see now the 9pfs specific entries so nevermind]
>
> Multiple rings are supported for each frontend and backend connection.
>
> The following are mandatory xenstore nodes for this protocol.
>
>
> ### Frontend XenBus Nodes
Could I convience you to have Backend XenBus Nodes first?
>
> num-rings
> Values:
>
> Number of rings. It needs to be lower or equal to max-rings.
>
> event-channel- (event-channel-0, event-channel-1, etc)
> Values:
>
> The identifier of the Xen event channel used to signal activity
> in the ring buffer. One for each ring.
>
> ring-ref (ring-ref0, ring-ref1, etc)
> Values:
>
> The Xen grant reference granting permission for the backend to
> map a page with information to setup a share ring. One for each
> ring.
>
> ### Backend XenBus Nodes
>
> Backend specific properties, written by the backend, read by the
> frontend:
>
> version
> Values:
>
> Protocol version supported by the backend. Currently the value is
> 1.
That is good. But there needs to be an negotiation with frontend where
the frontend says "well, I want version 2" and we exchange back and forth
on this.
>
> max-rings
> Values:
>
> The maximum supported number of rings per frontend.
>
> max-ring-page-order
> Values:
>
> The maximum supported size of a memory allocation in units of
> lb(machine pages), e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
s/lb/log/ ?
> etc.
>
> Backend configuration nodes, written by the toolstack, read by the
> backend:
>
> path
> Values:
>
>
Re: [Xen-devel] [PATCH 3/5] hotplug/linux: Improve iptables logic
Sylvain Munaut writes ("Re: [PATCH 3/5] hotplug/linux: Improve iptables logic"):
> And just moving the 'out' rule outside of frob_iptables alltogether
> seems hackish to me, especially when you add IPv6 later on because you
> have iptables manipulations spread around.
Sorry for the terseness of my previous mail. I should say that I
appreciate your efforts to tidy this up and to support v6.
I think it's probably better to show you what I mean in code. So I am
going to send two patches (from git-format-patch/git-send-email) to
show what I mean. They come instead of this patch, and the rest of
the series would need rework.
You can find them here too:
git://xenbits.xen.org/people/iwj/xen.git#for.sylvain-munaut
http://xenbits.xen.org/gitweb/?p=people/iwj/xen.git;a=shortlog;h=refs/heads/for.sylvain-munaut
> > I'm not sure I like the change in the handling of any.
>
> What change exactly ?
I meant that rather than having a subroutine which adds a wildcard
rule, you have an explicit "any" address, and tracking if it's been
added, etc.
Please take a look and see if you prefer my approach.
Regards,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 1/8] golang/xenlight: Create stub package
On Mon, Jan 23, 2017 at 11:43:30AM -0500, Ronald Rojas wrote: [...] > + > +subdir-distclean-firmware: .phony > + $(MAKE) -C firmware distclean > + This looks unrelated. > subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony > $(MAKE) -C debugger/gdbsx clean > > diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile > new file mode 100644 > index 000..1c2a2b7 > --- /dev/null > +++ b/tools/golang/xenlight/Makefile > @@ -0,0 +1,31 @@ > +XEN_ROOT=$(CURDIR)/../../.. > +GOLANG_SRC=$(GOPATH)/src/xenproject.org/xenlight > +CGO_CFLAGS = -I$(DESTDIR)$(includedir) > +CGO_LDFLAGS = -L$(DESTDIR)$(libdir) -Wl,-rpath-link=$(DESTDIR)$(libdir) > +include $(XEN_ROOT)/tools/Rules.mk > + > +BINARY = xenlight.a > +GO ?= go > + > +.PHONY: all > +all: build > + > +.PHONY: build > +build: xenlight.a > + > +.PHONY: install > +install: build > + $(INSTALL_DIR) $(DESTDIR)$(GOLANG_SRC) > + $(INSTALL_DATA) xenlight.go $(DESTDIR)$(GOLANG_SRC) > + > +.PHONY: clean > +clean: > + $(RM) $(BINARY) > + > +.PHONY: distclean > +distclean: clean > + > +xenlight.a: xenlight.go > + CGO_CFLAGS="$(CGO_CFLAGS)" CGO_LDFLAGS="$(CGO_LDFLAGS)" $(GO) build -o > $@ $< > + > +-include $(DEPS) > diff --git a/tools/golang/xenlight/xenlight.go > b/tools/golang/xenlight/xenlight.go > new file mode 100644 > index 000..f82e14e > --- /dev/null > +++ b/tools/golang/xenlight/xenlight.go > @@ -0,0 +1,86 @@ > +/* > + * Copyright (C) 2016 George W. Dunlap, Citrix Systems UK Ltd > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; version 2 of the > + * License only. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > + * 02110-1301, USA. > + */ My impression is that we prefer LGPL for libraries -- but of course it is up to the author to decide what license to use. :-) Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 1/2] hotplug/linux: Break out frob_iptable_command, and improve logging
Move the actual execution of `iptable' into a new function which
captures the stderr, and logs it. The actual `iptables' command is a
parameter to `frob_iptable_command' so that in future we can reuse
this subroutine for `ip6tables'.
No functional change other than to log messages.
Signed-off-by: Ian Jackson
---
tools/hotplug/Linux/vif-common.sh | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/tools/hotplug/Linux/vif-common.sh
b/tools/hotplug/Linux/vif-common.sh
index 77d139d..20cb6a7 100644
--- a/tools/hotplug/Linux/vif-common.sh
+++ b/tools/hotplug/Linux/vif-common.sh
@@ -120,8 +120,10 @@ fi
ip=${ip:-}
ip=$(xenstore_read_default "$XENBUS_PATH/ip" "$ip")
-frob_iptable()
+frob_iptable_command()
{
+ local iptables=$1; shift
+
if [ "$command" == "online" -o "$command" == "add" ]
then
local c="-I"
@@ -129,17 +131,21 @@ frob_iptable()
local c="-D"
fi
- iptables "$c" FORWARD -w $dev_in_match "$dev" \
-"$@" -j ACCEPT 2>/dev/null &&
- iptables "$c" FORWARD -w $dev_out_match "$dev" \
--j ACCEPT 2>/dev/null
-
+ local errormsg=$("$iptables" "$c" "$@" 2>&1)
if [ \( "$command" == "online" -o "$command" == "add" \) -a $? -ne 0 ]
then
-log err "iptables setup failed. This may affect guest networking."
+log err "iptables setup failed. This may affect guest networking.
($iptables $c $*: $errormsg)"
fi
}
+frob_iptable()
+{
+ frob_iptable_command iptables FORWARD -w $dev_in_match "$dev" \
+"$@" -j ACCEPT 2>/dev/null
+ frob_iptable_command iptables FORWARD -w $dev_out_match "$dev" \
+-j ACCEPT 2>/dev/null
+}
+
##
# Add or remove the appropriate entries in the iptables. With antispoofing
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 2/2] tools/hotplug: Insert output filter only once
Break frob_iptable into two subroutines frob_iptable_in and
frob_iptable_out_all.
frob_iptable_in must be called with the iptables command name and
appropriate parameters (for each source address or condition, as
necessary).
frob_iptable_out_all must be called exactly once.
Signed-off-by: Ian Jackson
---
tools/hotplug/Linux/vif-common.sh | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/hotplug/Linux/vif-common.sh
b/tools/hotplug/Linux/vif-common.sh
index 20cb6a7..b7b3e32 100644
--- a/tools/hotplug/Linux/vif-common.sh
+++ b/tools/hotplug/Linux/vif-common.sh
@@ -138,10 +138,15 @@ frob_iptable_command()
fi
}
-frob_iptable()
+frob_iptable_in()
{
- frob_iptable_command iptables FORWARD -w $dev_in_match "$dev" \
+ local iptables=$1; shift
+ frob_iptable_command $iptables FORWARD -w $dev_in_match "$dev" \
"$@" -j ACCEPT 2>/dev/null
+}
+
+frob_iptable_out_all()
+{
frob_iptable_command iptables FORWARD -w $dev_out_match "$dev" \
-j ACCEPT 2>/dev/null
}
@@ -186,10 +191,12 @@ handle_iptable()
done
# Always allow the domain to talk to a DHCP server.
- frob_iptable -p udp --sport 68 --dport 67
+ frob_iptable_in iptables -p udp --sport 68 --dport 67
+ frob_iptable_out_all
else
# No IP addresses have been specified, so allow anything.
- frob_iptable
+ frob_iptable_in iptables
+ frob_iptable_out_all
fi
release_lock "iptables"
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 104649: regressions - trouble: blocked/broken/fail
flight 104649 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104649/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104630 build-armhf 5 xen-buildfail REGR. vs. 104630 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass version targeted for testing: xen 91f59d2041b0f2760da082827bcea57648845cc1 baseline version: xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc Last test of basis 104630 2017-01-24 19:01:56 Z0 days Failing since104642 2017-01-25 10:01:54 Z0 days5 attempts Testing same since 104648 2017-01-25 15:01:38 Z0 days2 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Dario Faggioli Elena Ufimtseva George Dunlap George Dunlap Ian Jackson Jan Beulich Kevin Tian Paul Durrant Praveen Kumar Roger Pau Monné Tim Deegan Venu Busireddy Wei Liu jobs: build-amd64 fail build-arm64 fail build-armhf fail build-amd64-libvirt blocked build-arm64-pvopsfail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 586 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH net-next] xen-netfront: reject short packets and handle non-linear packets
On Wed, 2017-01-25 at 16:26 +, Paul Durrant wrote:
> Sowmini points out two vulnerabilities in xen-netfront:
>
> a) The code assumes that skb->len is at least ETH_HLEN.
> b) The code assumes that at least ETH_HLEN octets are in the linear
>port of the socket buffer.
>
> This patch adds tests for both of these, and in the case of the latter
> pulls sufficient bytes into the linear area.
>
> Signed-off-by: Paul Durrant
> Reported-by: Sowmini Varadhan
> Tested-by: Sowmini Varadhan
> ---
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> ---
> drivers/net/xen-netfront.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 40f26b6..0478809 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -567,6 +567,10 @@ static int xennet_start_xmit(struct sk_buff *skb, struct
> net_device *dev)
> u16 queue_index;
> struct sk_buff *nskb;
>
> + /* Basic sanity check */
> + if (unlikely(skb->len < ETH_HLEN))
> + goto drop;
> +
> /* Drop the packet if no queues are set up */
> if (num_queues < 1)
> goto drop;
> @@ -609,6 +613,11 @@ static int xennet_start_xmit(struct sk_buff *skb, struct
> net_device *dev)
> }
>
> len = skb_headlen(skb);
> + if (unlikely(len < ETH_HLEN)) {
> + if (!__pskb_pull_tail(skb, ETH_HLEN - len))
> + goto drop;
> + len = ETH_HLEN;
> + }
Looks like duplicated code, and buggy, considering the code above
page = virt_to_page(skb->data);
offset = offset_in_page(skb->data);
Your patch might end up with skb->data/head being reallocated, and use
after free would happen.
What about something like that ?
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index
40f26b69beb11459f0566fc1d1d739aa75e643bf..99a67fe4de86d3141169143b0820d00968cb09f2
100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -583,6 +583,8 @@ static int xennet_start_xmit(struct sk_buff *skb, struct
net_device *dev)
skb->len);
goto drop;
}
+ if (!pskb_may_pull(skb, ETH_HLEN))
+ goto drop;
slots = xennet_count_skb_slots(skb);
if (unlikely(slots > MAX_XEN_SKB_FRAGS + 1)) {
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/7] x86emul/test: remove extraneous commas in debug messages
On Wed, Jan 25, 2017 at 09:33:05AM -0700, Jan Beulich wrote:
> >>> On 25.01.17 at 16:44, wrote:
> > --- a/tools/tests/x86_emulator/test_x86_emulator.c
> > +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> > @@ -42,7 +42,7 @@ static int read(
> > struct x86_emulate_ctxt *ctxt)
> > {
> > if ( verbose )
> > -printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset,
> > bytes);
> > +printf("** %s(%u, %p, %u)\n", __func__, seg, (void *)offset,
> > bytes);
>
> Back when these got added, Andrew did explain why he put them
> there.
>
Eh, OK. If there is a reason for this, I will just drop this patch. It's
not essential anyway.
It just looks rather odd to me to have so many extraneous commas. ;-)
Wei.
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/7] x86emul/test: remove extraneous commas in debug messages
>>> On 25.01.17 at 16:44, wrote:
> --- a/tools/tests/x86_emulator/test_x86_emulator.c
> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> @@ -42,7 +42,7 @@ static int read(
> struct x86_emulate_ctxt *ctxt)
> {
> if ( verbose )
> -printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset,
> bytes);
> +printf("** %s(%u, %p, %u)\n", __func__, seg, (void *)offset, bytes);
Back when these got added, Andrew did explain why he put them
there.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH net-next] xen-netfront: reject short packets and handle non-linear packets
Sowmini points out two vulnerabilities in xen-netfront:
a) The code assumes that skb->len is at least ETH_HLEN.
b) The code assumes that at least ETH_HLEN octets are in the linear
port of the socket buffer.
This patch adds tests for both of these, and in the case of the latter
pulls sufficient bytes into the linear area.
Signed-off-by: Paul Durrant
Reported-by: Sowmini Varadhan
Tested-by: Sowmini Varadhan
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
---
drivers/net/xen-netfront.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 40f26b6..0478809 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -567,6 +567,10 @@ static int xennet_start_xmit(struct sk_buff *skb, struct
net_device *dev)
u16 queue_index;
struct sk_buff *nskb;
+ /* Basic sanity check */
+ if (unlikely(skb->len < ETH_HLEN))
+ goto drop;
+
/* Drop the packet if no queues are set up */
if (num_queues < 1)
goto drop;
@@ -609,6 +613,11 @@ static int xennet_start_xmit(struct sk_buff *skb, struct
net_device *dev)
}
len = skb_headlen(skb);
+ if (unlikely(len < ETH_HLEN)) {
+ if (!__pskb_pull_tail(skb, ETH_HLEN - len))
+ goto drop;
+ len = ETH_HLEN;
+ }
spin_lock_irqsave(&queue->tx_lock, flags);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3] arm/p2m: Fix regression during domain shutdown with active mem_access
The change in commit 438c5fe4f0c introduced a regression for domains where mem_acces is or was active. When relinquish_p2m_mapping attempts to clear a page where the order is not 0 the following ASSERT is triggered: ASSERT(!p2m->mem_access_enabled || page_order == 0); This regression was unfortunately not caught during testing in preparation for the 4.8 release. In this patch we adjust the ASSERT to not trip when the domain is being shutdown. Ideally this fix would be part of Xen 4.8.1. Signed-off-by: Tamas K Lengyel --- Cc: Stefano Stabellini Cc: Julien Grall v3: Minor adjustments --- xen/arch/arm/p2m.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 09ceb378a5..7762f453f5 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -991,9 +991,10 @@ static int __p2m_set_entry(struct p2m_domain *p2m, /* * The radix-tree can only work on 4KB. This is only used when - * memaccess is enabled. + * memaccess is enabled and during shutdown. */ -ASSERT(!p2m->mem_access_enabled || page_order == 0); +ASSERT(!p2m->mem_access_enabled || page_order == 0 || + p2m->domain->is_dying); /* * The access type should always be p2m_access_rwx when the mapping * is removed. -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen Security Advisory 154 (CVE-2016-2270) - x86: inconsistent cachability flags on guest mappings
On Wed, 2017-01-25 at 07:21 -0700, Jan Beulich wrote:
>
> If there wasn't INVALID_MFN to be taken care of, the !mfn_valid()
> check could simply move down, and be combined with the
> direct_mmio one.
As discussed on IRC, once we fix the overflow with order > 0, I think
INVALID_MFN is OK. Not that it should ever really happen, AFAICT.
This seems to do the right thing for my MMIO WC test. I haven't
actually combined the !mfn_valid() check with the direct_mmio one.
Under what circumstances does that make sense anyway? For now in the
patch below I've left it *forcing* UC, unlike the direct_mmio path
which lets the guest use WC. But really, shouldn't the '!direct_mmio &&
!mfn_valid()' case just return an error?
Note that as well as using a mask for 'order' I've attempted to
consolidate the unlikely rangeset_overlaps_range() and
rangeset_contains_range() calls, on the assumption that the former will
*always* be true if the latter is, so we only need one of them in the
fast path through the function.
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 709759c..09c2f5c 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -773,20 +773,24 @@ int epte_get_entry_emt(struct domain *d, unsigned long
gfn, mfn_t mfn,
if ( v->domain != d )
v = d->vcpu ? d->vcpu[0] : NULL;
-if ( !mfn_valid(mfn_x(mfn)) ||
- rangeset_contains_range(mmio_ro_ranges, mfn_x(mfn),
- mfn_x(mfn) + (1UL << order) - 1) )
+/* INVALID_MFN should never happen here, but if it does then this
+ * should do the right thing instead of exploding */
+if ( unlikely(rangeset_overlaps_range(mmio_ro_ranges, mfn_x(mfn),
+ mfn_x(mfn) | ((1UL << order) - 1))) )
{
-*ipat = 1;
-return MTRR_TYPE_UNCACHABLE;
+ if ( rangeset_contains_range(mmio_ro_ranges, mfn_x(mfn),
+ mfn_x(mfn) | ((1UL << order) - 1)) )
+ {
+ *ipat = 1;
+ return MTRR_TYPE_UNCACHABLE;
+ }
+ /* Overlaps mmio_ro_ranges but is not entirely contained. No. */
+ return -1;
}
-if ( rangeset_overlaps_range(mmio_ro_ranges, mfn_x(mfn),
- mfn_x(mfn) + (1UL << order) - 1) )
-return -1;
-
if ( direct_mmio )
{
+ /* Again, INVALID_MFN should do the right thing here. */
if ( (mfn_x(mfn) ^ d->arch.hvm_domain.vmx.apic_access_mfn) >> order )
return MTRR_TYPE_UNCACHABLE;
if ( order )
@@ -795,6 +799,12 @@ int epte_get_entry_emt(struct domain *d, unsigned long
gfn, mfn_t mfn,
return MTRR_TYPE_WRBACK;
}
+if ( unlikely(!mfn_valid(mfn_x(mfn))) )
+{
+ *ipat = 1;
+ return MTRR_TYPE_UNCACHABLE;
+}
+
if ( !need_iommu(d) && !cache_flush_permitted(d) )
{
*ipat = 1;
smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2
On Wed, 2017-01-25 at 12:38 +, Julien Grall wrote: > Hi Dario, > Hey, > On 25/01/17 11:10, Dario Faggioli wrote: > > My point was that, still from scheduling perspective, neither > > Credit1 > > nor Credit2 sets a wakeup timer for idle pCPUs. > > > > Well, in Credit1, the master_ticker timer is never stopped (while, > > e.g., the per-pCPU tick is stopped before entering deep sleep, > > via sched_tick_suspend(), see commit 964fae8ac), but that's only 1 > > pCPU. > > The function sched_tick_suspend is never called on ARM. The power > saving > in Xen ARM is still very limited and this would need to be updated > in > the future. > > So I guess that's why I still see interrupt coming on the idle pCPU > when > credit1 is used. > Yes. If you don't suspend the tick before going to wfi/hlt/whatever, there will be a timer firing --and AFAICT waking you up from the low power state-- every 10ms (with default Credit1 timeslice), even for idle pCPUs. > Looking at credit2, the callback tick_suspend is not > called. Does it mean there is no per-pCPU timer? > Exactly, we (happily) don't need that in Credit2. :-) > Now, from my understanding, if we decide to call sched_tick_suspend > on > ARM before idling. We will likely have the same problem with credit1 > because there is no more interrupt to wake-up the pCPU. > Basing on what you've said so far in this thread, I tend to think that, yes, that would be the case. > But I don't think this is an issue in the scheduler. > Agreed. > IHMO, the problem > is in the RCU. Indeed a CPU in lower power mode (i.e wfi on ARM or > pm_idle on x86 is been executed) will never get out to tell to the > RCU : > "I am quiet, go ahead". So the RCU will never be able to reclaim the > memory and will result on a memory exhaustion if the pCPU never > receive > an interrupt (this could happen if pCPU has never ran a guest). > > The question now, is how to fix it? > And a good one. I may be wrong (I certainly wasn't around at the time), but ISTR out RCU code is imported/inspired by Linux... Looking there again may help, but, nowadays, Linux RCU subsystem is a Lernaean Hydra monster, with 100 heads and sharpen claws! :-O And, while, in there, it has to be like that, I don't think we need all such complexity, and hence we can't just re-sync. :-/ Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] [incremental] xsm/build: Further build fixes following the DMop series
On Wed, Jan 25, 2017 at 02:24:28PM +, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Daniel De Graaf > CC: Paul Durrant > CC: Ian Jackson > > Might be better to merge into one single patch when committed? Yes, we should squash the two patches (the other one being mine posted earlier this morning). ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] xennet_start_xmit assumptions
On (01/25/17 15:06), Paul Durrant wrote: > > Making netfront cope with a fully non-linear skb looks like it would > be quite intrusive and probably not worth it so I opted for just doing > the ETH_HLEN pull-tail if necessary. Can you check it works for you? I tested it, and it works fine, but note that DaveM's comments in this thread: the DKI is that we *must* provide at least the hard_header_len in the non-paged part of the skb. So might not even be necessary to handle the fully non-linear skb (though it's probably prudent to check and bail for this, as your patch does) I just posted an RFC patch for fixing the pf_packet layer, just in case other drivers like xen_netfront dont explicitly check for this http://patchwork.ozlabs.org/patch/719236/ ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/7] x86_emulate: lift a bunch of macros to header file
Some of them can be shared between hypervisor and userspace fuzzing /
test code. Instead of lifting the ones as we need, lift them all.
And then remove the ones in test program.
Signed-off-by: Wei Liu
---
tools/tests/x86_emulator/test_x86_emulator.c | 9 ---
xen/arch/x86/x86_emulate/x86_emulate.c | 85 ---
xen/arch/x86/x86_emulate/x86_emulate.h | 86
3 files changed, 86 insertions(+), 94 deletions(-)
diff --git a/tools/tests/x86_emulator/test_x86_emulator.c
b/tools/tests/x86_emulator/test_x86_emulator.c
index e86369ffe7..579b28c687 100644
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -23,15 +23,6 @@ static const struct {
#endif
};
-/* EFLAGS bit definitions. */
-#define EFLG_OF (1<<11)
-#define EFLG_DF (1<<10)
-#define EFLG_SF (1<<7)
-#define EFLG_ZF (1<<6)
-#define EFLG_AF (1<<4)
-#define EFLG_PF (1<<2)
-#define EFLG_CF (1<<0)
-
static unsigned int bytes_read;
static int read(
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 21dd98cebc..fd61dd8384 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -415,91 +415,6 @@ typedef union {
# define ASM_FLAG_OUT(yes, no) no
#endif
-/* MSRs. */
-#define MSR_TSC 0x0010
-#define MSR_SYSENTER_CS 0x0174
-#define MSR_SYSENTER_ESP 0x0175
-#define MSR_SYSENTER_EIP 0x0176
-#define MSR_DEBUGCTL 0x01d9
-#define DEBUGCTL_BTF (1 << 1)
-#define MSR_BNDCFGS 0x0d90
-#define BNDCFG_ENABLE(1 << 0)
-#define BNDCFG_PRESERVE (1 << 1)
-#define MSR_EFER 0xc080
-#define MSR_STAR 0xc081
-#define MSR_LSTAR0xc082
-#define MSR_CSTAR0xc083
-#define MSR_FMASK0xc084
-#define MSR_TSC_AUX 0xc103
-
-/* Control register flags. */
-#define CR0_PE(1<<0)
-#define CR0_MP(1<<1)
-#define CR0_EM(1<<2)
-#define CR0_TS(1<<3)
-
-#define CR4_VME(1<<0)
-#define CR4_PVI(1<<1)
-#define CR4_TSD(1<<2)
-#define CR4_OSFXSR (1<<9)
-#define CR4_OSXMMEXCPT (1<<10)
-#define CR4_UMIP (1<<11)
-#define CR4_FSGSBASE (1<<16)
-#define CR4_OSXSAVE(1<<18)
-
-/* EFLAGS bit definitions. */
-#define EFLG_ID (1<<21)
-#define EFLG_VIP (1<<20)
-#define EFLG_VIF (1<<19)
-#define EFLG_AC (1<<18)
-#define EFLG_VM (1<<17)
-#define EFLG_RF (1<<16)
-#define EFLG_NT (1<<14)
-#define EFLG_IOPL (3<<12)
-#define EFLG_OF (1<<11)
-#define EFLG_DF (1<<10)
-#define EFLG_IF (1<<9)
-#define EFLG_TF (1<<8)
-#define EFLG_SF (1<<7)
-#define EFLG_ZF (1<<6)
-#define EFLG_AF (1<<4)
-#define EFLG_PF (1<<2)
-#define EFLG_MBS (1<<1)
-#define EFLG_CF (1<<0)
-
-/* Floating point status word definitions. */
-#define FSW_ES(1U << 7)
-
-/* MXCSR bit definitions. */
-#define MXCSR_MM (1U << 17)
-
-/* Exception definitions. */
-#define EXC_DE 0
-#define EXC_DB 1
-#define EXC_BP 3
-#define EXC_OF 4
-#define EXC_BR 5
-#define EXC_UD 6
-#define EXC_NM 7
-#define EXC_DF 8
-#define EXC_TS 10
-#define EXC_NP 11
-#define EXC_SS 12
-#define EXC_GP 13
-#define EXC_PF 14
-#define EXC_MF 16
-#define EXC_AC 17
-#define EXC_XM 19
-
-#define EXC_HAS_EC \
-((1u << EXC_DF) | (1u << EXC_TS) | (1u << EXC_NP) | \
- (1u << EXC_SS) | (1u << EXC_GP) | (1u << EXC_PF) | (1u << EXC_AC))
-
-/* Segment selector error code bits. */
-#define ECODE_EXT (1 << 0)
-#define ECODE_IDT (1 << 1)
-#define ECODE_TI (1 << 2)
-
/*
* Instruction emulation:
* Most instructions are emulated directly via a fragment of inline assembly
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h
b/xen/arch/x86/x86_emulate/x86_emulate.h
index 071668d8b1..df8d0e5ecc 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -23,6 +23,92 @@
#ifndef __X86_EMULATE_H__
#define __X86_EMULATE_H__
+/* MSRs. */
+#define MSR_TSC 0x0010
+#define MSR_SYSENTER_CS 0x0174
+#define MSR_SYSENTER_ESP 0x0175
+#define MSR_SYSENTER_EIP 0x0176
+#define MSR_DEBUGCTL 0x01d9
+#define DEBUGCTL_BTF (1 << 1)
+#define MSR_BNDCFGS 0x0d90
+#define BNDCFG_ENABLE(1 << 0)
+#define BNDCFG_PRESERVE (1 << 1)
+#define MSR_EFER 0xc080
+#define MSR_STAR 0xc081
+#define MSR_LSTAR0xc082
+#define MSR_CSTAR0xc083
+#define MSR_FMASK0xc084
+#define MSR_TSC_AUX 0xc103
+
+/* Control register flags. */
+#define CR0_PE(1<<0)
+#define CR0_MP(1<<1)
+#define CR0_EM(1<<2)
+#define CR0_TS(1<<3)
+
+#define CR4_VME(1<<0)
+#define CR4_PVI(1<<1)
+#define CR4_TSD(1<<2)
+#define CR4_OSFXSR (1<<9)
+#define CR4_OSXMMEXCPT (1<<10)
+#define CR4_UMIP (1<<11)
+#define CR4_FSGSBASE (1<<16)
+#define CR4_OSXSAVE(1<<18)
+
+
+/* EFLAGS b
[Xen-devel] [PATCH 4/7] x86emul/test: use x86-defns.h
Signed-off-by: Wei Liu --- tools/tests/x86_emulator/x86_emulate.h | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/tools/tests/x86_emulator/x86_emulate.h b/tools/tests/x86_emulator/x86_emulate.h index 3a6badee46..3a1d8ccad2 100644 --- a/tools/tests/x86_emulator/x86_emulate.h +++ b/tools/tests/x86_emulator/x86_emulate.h @@ -6,6 +6,8 @@ #include #include +#include "../../../xen/include/asm-x86/x86-defns.h" + #define BUG() abort() #define ASSERT assert #define ASSERT_UNREACHABLE() assert(!__LINE__) @@ -38,11 +40,6 @@ #define is_canonical_address(x) (((int64_t)(x) >> 47) == ((int64_t)(x) >> 63)) -/* There's no strict need for these to be in sync with processor.h. */ -#define X86_VENDOR_INTEL 0 -#define X86_VENDOR_AMD 2 -#define X86_VENDOR_UNKNOWN 0xff - #define MMAP_SZ 16384 bool emul_test_make_stack_executable(void); -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 6/7] fuzz/x86emul: print out minimal input size
... so that users can know how big the initial input should be.
Signed-off-by: Wei Liu
---
.../fuzz/x86_instruction_emulator/afl-x86-insn-emulator-fuzzer.c | 8
tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c| 5 +
2 files changed, 13 insertions(+)
diff --git a/tools/fuzz/x86_instruction_emulator/afl-x86-insn-emulator-fuzzer.c
b/tools/fuzz/x86_instruction_emulator/afl-x86-insn-emulator-fuzzer.c
index b5668c11e7..655315f9c1 100644
--- a/tools/fuzz/x86_instruction_emulator/afl-x86-insn-emulator-fuzzer.c
+++ b/tools/fuzz/x86_instruction_emulator/afl-x86-insn-emulator-fuzzer.c
@@ -2,8 +2,10 @@
#include
#include
#include
+#include
extern int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t size);
+extern unsigned int fuzz_minimal_input_size(void);
#define INPUT_SIZE 4096
static uint8_t input[INPUT_SIZE];
@@ -19,6 +21,12 @@ int main(int argc, char **argv)
exit(-1);
}
+if ( !strcmp(argv[1], "--min-input-size") )
+{
+printf("%u\n", fuzz_minimal_input_size());
+exit(0);
+}
+
fp = fopen(argv[1], "rb");
if ( fp == NULL )
{
diff --git a/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
b/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
index 8ca0421f60..3a731b28f2 100644
--- a/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
+++ b/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
@@ -717,6 +717,11 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t
size)
return 0;
}
+unsigned int fuzz_minimal_input_size(void)
+{
+return DATA_OFFSET + 1;
+}
+
/*
* Local variables:
* mode: C
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/7] x86: extract macros to x86-defns.h
... so that they can be used by userspace x86 instruction emulator test
program and fuzzer as well.
No functional change.
Signed-off-by: Wei Liu
---
xen/include/asm-x86/processor.h | 121 +-
xen/include/asm-x86/x86-defns.h | 125
2 files changed, 126 insertions(+), 120 deletions(-)
create mode 100644 xen/include/asm-x86/x86-defns.h
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index 4da9c193e0..c86044f5f8 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -16,126 +16,7 @@
#include
#endif
-/*
- * CPU vendor IDs
- */
-#define X86_VENDOR_INTEL 0
-#define X86_VENDOR_AMD 1
-#define X86_VENDOR_CENTAUR 2
-#define X86_VENDOR_NUM 3
-#define X86_VENDOR_UNKNOWN 0xff
-
-/*
- * EFLAGS bits
- */
-#define X86_EFLAGS_CF 0x0001 /* Carry Flag */
-#define X86_EFLAGS_MBS 0x0002 /* Resvd bit */
-#define X86_EFLAGS_PF 0x0004 /* Parity Flag */
-#define X86_EFLAGS_AF 0x0010 /* Auxillary carry Flag */
-#define X86_EFLAGS_ZF 0x0040 /* Zero Flag */
-#define X86_EFLAGS_SF 0x0080 /* Sign Flag */
-#define X86_EFLAGS_TF 0x0100 /* Trap Flag */
-#define X86_EFLAGS_IF 0x0200 /* Interrupt Flag */
-#define X86_EFLAGS_DF 0x0400 /* Direction Flag */
-#define X86_EFLAGS_OF 0x0800 /* Overflow Flag */
-#define X86_EFLAGS_IOPL0x3000 /* IOPL mask */
-#define X86_EFLAGS_NT 0x4000 /* Nested Task */
-#define X86_EFLAGS_RF 0x0001 /* Resume Flag */
-#define X86_EFLAGS_VM 0x0002 /* Virtual Mode */
-#define X86_EFLAGS_AC 0x0004 /* Alignment Check */
-#define X86_EFLAGS_VIF 0x0008 /* Virtual Interrupt Flag */
-#define X86_EFLAGS_VIP 0x0010 /* Virtual Interrupt Pending */
-#define X86_EFLAGS_ID 0x0020 /* CPUID detection flag */
-
-#define X86_EFLAGS_ARITH_MASK \
-(X86_EFLAGS_CF | X86_EFLAGS_PF | X86_EFLAGS_AF | \
- X86_EFLAGS_ZF | X86_EFLAGS_SF | X86_EFLAGS_OF)
-
-/*
- * Intel CPU flags in CR0
- */
-#define X86_CR0_PE 0x0001 /* Enable Protected Mode(RW) */
-#define X86_CR0_MP 0x0002 /* Monitor Coprocessor (RW) */
-#define X86_CR0_EM 0x0004 /* Require FPU Emulation(RO) */
-#define X86_CR0_TS 0x0008 /* Task Switched(RW) */
-#define X86_CR0_ET 0x0010 /* Extension type (RO) */
-#define X86_CR0_NE 0x0020 /* Numeric Error Reporting (RW) */
-#define X86_CR0_WP 0x0001 /* Supervisor Write Protect (RW) */
-#define X86_CR0_AM 0x0004 /* Alignment Checking (RW) */
-#define X86_CR0_NW 0x2000 /* Not Write-Through(RW) */
-#define X86_CR0_CD 0x4000 /* Cache Disable(RW) */
-#define X86_CR0_PG 0x8000 /* Paging (RW) */
-
-/*
- * Intel CPU features in CR4
- */
-#define X86_CR4_VME0x0001 /* enable vm86 extensions */
-#define X86_CR4_PVI0x0002 /* virtual interrupts flag enable */
-#define X86_CR4_TSD0x0004 /* disable time stamp at ipl 3 */
-#define X86_CR4_DE 0x0008 /* enable debugging extensions */
-#define X86_CR4_PSE0x0010 /* enable page size extensions */
-#define X86_CR4_PAE0x0020 /* enable physical address extensions */
-#define X86_CR4_MCE0x0040 /* Machine check enable */
-#define X86_CR4_PGE0x0080 /* enable global pages */
-#define X86_CR4_PCE0x0100 /* enable performance counters at ipl 3
*/
-#define X86_CR4_OSFXSR 0x0200 /* enable fast FPU save and restore */
-#define X86_CR4_OSXMMEXCPT 0x0400 /* enable unmasked SSE exceptions */
-#define X86_CR4_VMXE 0x2000 /* enable VMX */
-#define X86_CR4_SMXE 0x4000 /* enable SMX */
-#define X86_CR4_FSGSBASE 0x0001 /* enable {rd,wr}{fs,gs}base */
-#define X86_CR4_PCIDE 0x0002 /* enable PCID */
-#define X86_CR4_OSXSAVE0x0004 /* enable XSAVE/XRSTOR */
-#define X86_CR4_SMEP 0x0010 /* enable SMEP */
-#define X86_CR4_SMAP 0x0020 /* enable SMAP */
-#define X86_CR4_PKE0x0040 /* enable PKE */
-
-/*
- * Trap/fault mnemonics.
- */
-#define TRAP_divide_error 0
-#define TRAP_debug 1
-#define TRAP_nmi 2
-#define TRAP_int3 3
-#define TRAP_overflow 4
-#define TRAP_bounds5
-#define TRAP_invalid_op6
-#define TRAP_no_device 7
-#define TRAP_double_fault 8
-#define TRAP_copro_seg 9
-#define TRAP_invalid_tss 10
-#define TRAP_no_segment 11
-#define TRAP_stack_error 12
-#define TRAP_gp_fault 13
-#define TRAP_page_fault 14
-#define TRAP_spurious_int 15
-#define TRAP_copro_error 16
-#define TRAP_alignment_check 17
-#define TRAP_machine_check18
-#define TRAP_simd_error 19
-#define TRA
[Xen-devel] [PATCH 0/7] fuzz: update x86emul fuzzer
Wei Liu (7): x86emul/test: remove extraneous commas in debug messages x86_emulate: lift a bunch of macros to header file x86: extract macros to x86-defns.h x86emul/test: use x86-defns.h fuzz/x86emul: update fuzzer fuzz/x86emul: print out minimal input size fuzz: update README.afl example tools/fuzz/README.afl | 5 +- .../afl-x86-insn-emulator-fuzzer.c | 8 + .../x86-insn-emulator-fuzzer.c | 658 +++-- tools/tests/x86_emulator/test_x86_emulator.c | 17 +- tools/tests/x86_emulator/x86_emulate.h | 7 +- xen/arch/x86/x86_emulate/x86_emulate.c | 85 --- xen/arch/x86/x86_emulate/x86_emulate.h | 86 +++ xen/include/asm-x86/processor.h| 121 +--- xen/include/asm-x86/x86-defns.h| 125 9 files changed, 829 insertions(+), 283 deletions(-) create mode 100644 xen/include/asm-x86/x86-defns.h -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 5/7] fuzz/x86emul: update fuzzer
Provide the fuzzer with more ops, and more sophisticated input
structure.
Based on a patch originally written by Andrew and George.
Signed-off-by: Andrew Cooper
Signed-off-by: George Dunlap
Signed-off-by: Wei Liu
---
.../x86-insn-emulator-fuzzer.c | 653 +++--
1 file changed, 595 insertions(+), 58 deletions(-)
diff --git a/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
b/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
index 7d7f731677..8ca0421f60 100644
--- a/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
+++ b/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
@@ -16,26 +16,75 @@
#include "x86_emulate.h"
-static unsigned char data[4096];
+#include "../../../xen/include/asm-x86/msr-index.h"
+
+#ifndef offsetof
+#define offsetof(t,m) ((size_t)&(((t *)0)->m))
+#endif
+
+#define MSR_INDEX_MAX 16
+
+#define SEG_MAX x86_seg_none
+
+struct input_struct {
+unsigned cr[5];
+uint64_t msr[MSR_INDEX_MAX];
+struct cpu_user_regs regs;
+struct segment_register segments[SEG_MAX+1];
+unsigned long options;
+unsigned char data[4096];
+} input;
+#define DATA_OFFSET offsetof(struct input_struct, data)
static unsigned int data_index;
static unsigned int data_max;
+int maybe_fail(const char *why, bool exception)
+{
+int rc;
+
+if ( data_index + 1 > data_max )
+return X86EMUL_EXCEPTION;
+else
+{
+if ( input.data[data_index] > 0xc )
+rc = X86EMUL_EXCEPTION;
+else if ( input.data[data_index] > 0x8 )
+rc = X86EMUL_UNHANDLEABLE;
+else
+rc = X86EMUL_OKAY;
+data_index++;
+}
+
+if ( rc == X86EMUL_EXCEPTION && !exception )
+rc = X86EMUL_OKAY;
+
+printf("maybe_fail %s: %d\n", why, rc);
+
+return rc;
+}
+
static int data_read(const char *why, void *dst, unsigned int bytes)
{
unsigned int i;
+int rc;
if ( data_index + bytes > data_max )
return X86EMUL_EXCEPTION;
+else
+rc = maybe_fail(why, true);
-memcpy(dst, data + data_index, bytes);
-data_index += bytes;
+if ( rc == X86EMUL_OKAY )
+{
+memcpy(dst, input.data + data_index, bytes);
+data_index += bytes;
-printf("%s: ", why);
-for ( i = 0; i < bytes; i++ )
-printf(" %02x", *(unsigned char *)(dst + i));
-printf("\n");
+printf("%s: ", why);
+for ( i = 0; i < bytes; i++ )
+printf(" %02x", *(unsigned char *)(dst + i));
+printf("\n");
+}
-return X86EMUL_OKAY;
+return rc;
}
static int fuzz_read(
@@ -48,14 +97,71 @@ static int fuzz_read(
return data_read("read", p_data, bytes);
}
-static int fuzz_fetch(
+static int fuzz_read_io(
+unsigned int port,
+unsigned int bytes,
+unsigned long *val,
+struct x86_emulate_ctxt *ctxt)
+{
+return data_read("read_io", val, bytes);
+}
+
+static int fuzz_insn_fetch(
unsigned int seg,
unsigned long offset,
void *p_data,
unsigned int bytes,
struct x86_emulate_ctxt *ctxt)
{
-return data_read("fetch", p_data, bytes);
+return data_read("insn_fetch", p_data, bytes);
+}
+
+static int fuzz_rep_ins(
+uint16_t src_port,
+enum x86_segment dst_seg,
+unsigned long dst_offset,
+unsigned int bytes_per_rep,
+unsigned long *reps,
+struct x86_emulate_ctxt *ctxt)
+{
+int rc;
+unsigned long bytes_read;
+
+rc = data_read("rep_ins", &bytes_read, sizeof(bytes_read));
+
+if ( rc != X86EMUL_OKAY )
+return rc;
+
+if ( bytes_read < *reps )
+*reps -= bytes_read;
+else
+*reps = 0;
+
+return rc;
+}
+
+static int fuzz_rep_movs(
+enum x86_segment src_seg,
+unsigned long src_offset,
+enum x86_segment dst_seg,
+unsigned long dst_offset,
+unsigned int bytes_per_rep,
+unsigned long *reps,
+struct x86_emulate_ctxt *ctxt)
+{
+int rc;
+unsigned long bytes_read;
+rc = data_read("rep_ins", &bytes_read, sizeof(bytes_read));
+
+if ( rc != X86EMUL_OKAY )
+return rc;
+
+if ( bytes_read < *reps )
+*reps -= bytes_read;
+else
+*reps = 0;
+
+return rc;
}
static int fuzz_write(
@@ -65,7 +171,7 @@ static int fuzz_write(
unsigned int bytes,
struct x86_emulate_ctxt *ctxt)
{
-return X86EMUL_OKAY;
+return maybe_fail("write", true);
}
static int fuzz_cmpxchg(
@@ -76,18 +182,323 @@ static int fuzz_cmpxchg(
unsigned int bytes,
struct x86_emulate_ctxt *ctxt)
{
-return X86EMUL_OKAY;
+return maybe_fail("cmpxchg", true);
+}
+
+static int fuzz_invlpg(
+enum x86_segment seg,
+unsigned long offset,
+struct x86_emulate_ctxt *ctxt)
+{
+return maybe_fail("invlpg", false);
+}
+
+static int fuzz_wbinvd(
+struct x86_emulate_ctxt *ctxt)
+{
+return maybe_fail("wbinvd", true);
+}
+
+static int fuzz_write_io(
+unsigned int port,
+unsigned int bytes,
+
[Xen-devel] [PATCH 7/7] fuzz: update README.afl example
Signed-off-by: Wei Liu --- tools/fuzz/README.afl | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/fuzz/README.afl b/tools/fuzz/README.afl index 431b4a8cbf..68e0fa396f 100644 --- a/tools/fuzz/README.afl +++ b/tools/fuzz/README.afl @@ -20,9 +20,10 @@ Use the x86 instruction emulator fuzzer as an example. $ make distclean $ make CC=$AFLPATH/afl-gcc afl # produces afl-x86-insn-emulator-fuzzer -3. provide initial test case: +3. provide initial test case (fuzzer dependent, see afl-*.c): $ mkdir testcase_dir - $ echo -n -e '\xc3' > testcase_dir/ret.bin + $ dd if=/dev/urandom of=testcase_dir/rand.bin \ + bs=`./afl-x86-insn-emulator-fuzzer --min-input-size` count=1 4. run the fuzzer with AFL: $ $AFLPATH/afl-fuzz -m none -t 1000 -i testcase_dir -o findings_dir -- \ -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
