Re: [Xen-devel] [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb
>>> On 30.03.16 at 18:44, wrote: > On Wed, Mar 30, 2016 at 10:24:41AM -0600, Jan Beulich wrote: >> >>> On 24.03.16 at 21:00, wrote: >> > @@ -266,16 +275,15 @@ void *vzalloc(size_t size) >> > return p; >> > } >> > >> > -void vfree(void *va) >> > +void vfree_cb(void *va, unsigned int pages, vfree_cb_t *vfree_cb_fnc) >> >> Just to repeat: This "caller provides size" worries me, the more that >> this doesn't mirror anything the allocation side does. Would you mind >> providing a case where using vm_size() instead is not correct? > > When the virtual addresses (to which we will stitch the pages allocated > by vmalloc) are not allocated (provided?) by vmap. > > vm_size() will be very unhappy if that virtual address it is provided with > are not from the 'vmap' pool and will return 0. Hmm, okay, I now see that I got mislead by "This allows users (such as xSplice) to provide their own mechanism to set the page flags", which suggested to me that all you want is control over those flags. Now that I look again I realize that I could have easily spotted the actual intention right away. If all you really want to re-use from the existing vmalloc() is the allocation mechanism of the set of pages, then no, I don't think this should be done by playing with vmalloc(). Just have your caller do that allocation itself. If, otoh, you left that VA management to (an extended version of) vmap(), by e.g. allowing the caller to request allocation from a different VA range (much like iirc x86-64 Linux handles its modules address range allocation), things would be different. After all the VA management is the important part here, while the backing memory allocation is just a trivial auxiliary operation. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
>>> On 30.03.16 at 17:43, wrote: > Since they're all cosmetic, if you take care of all of them, feel free > to stick my ack on the result. Actually - no, please don't. While the patch is fine content wise then from my perspective, I'm still lacking a convincing argument of why this new hypercall is needed in the first place. If others are convinced by the argumentation between (mostly, iirc) you and Andrew, I'm not going to stand in the way, but I'm also not going to approve of the code addition without being myself convinced. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 3/6] libxl: add query function for backend support by device model
Add a function to query whether the device model is supporting a
specific backend type. The device model is writing the supported
backend types to Xenstore on startup. The new query function checks
for the appropriate entry to be present.
As not all versions of qemu are capable to indicate support of
specific backends the query function is to be called with an indicator
whether the default return value should be "supported" (in case qemu
doesn't know set any support information) or "not supported".
Signed-off-by: Juergen Gross
---
V6: add Xenstore path documentation as requested by Wei Liu
---
docs/misc/xenstore-paths.markdown | 7 +++
tools/libxl/libxl_dm.c| 19 +++
tools/libxl/libxl_internal.h | 5 +
3 files changed, 31 insertions(+)
diff --git a/docs/misc/xenstore-paths.markdown
b/docs/misc/xenstore-paths.markdown
index 76f67b1..890d261 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -472,6 +472,13 @@ in the value supplied by the guest in this case).
Contains the status of the device models running on the domain.
+ ~/device-model/$DOMID/backends/* [w]
+
+Backend types the device model is supporting. Each entry below backends
+is a directory which may contain further nodes specific to the backend
+type. The name of each backend directory is the same as the backend type
+(e.g. "qdisk").
+
~/libxl/$DOMID/qdisk-backend-pid [w]
Contains the PIDs of the device models running on the domain.
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 027d32b..1ade4e4 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1920,6 +1920,25 @@ out:
device_model_spawn_outcome(egc, dmss, rc);
}
+bool libxl__query_qemu_backend(libxl__gc *gc, uint32_t domid,
+ uint32_t backend_id, const char *type, bool def)
+{
+char *path;
+char **dir;
+unsigned int n;
+
+path = GCSPRINTF("%s/device-model/%u/backends",
+ libxl__xs_get_dompath(gc, backend_id), domid);
+dir = libxl__xs_directory(gc, XBT_NULL, path, &n);
+if (!dir)
+return def;
+
+path = GCSPRINTF("%s/device-model/%u/backends/%s",
+ libxl__xs_get_dompath(gc, backend_id), domid, type);
+dir = libxl__xs_directory(gc, XBT_NULL, path, &n);
+
+return !!dir;
+}
static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
const char *xsdata)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fc7bdab..c06ffc0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1617,6 +1617,11 @@ _hidden const char *libxl__domain_device_model(libxl__gc
*gc,
const libxl_domain_build_info *info);
_hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
libxl_domain_config *d_config);
+_hidden bool libxl__query_qemu_backend(libxl__gc *gc,
+ uint32_t domid,
+ uint32_t backend_id,
+ const char *type,
+ bool def);
/*
* This function will fix reserved device memory conflict
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 4/6] libxl: add new pvusb backend "qusb" provided by qemu
Add a new pvusb backend type "qusb" which is provided by qemu. It can
be selected either by specifying the type directly in the configuration
or it is selected automatically by libxl in case there is no "usbback"
driver loaded.
The "qusb" backend is a full replacement for the kernel based backend
"vusb". The interface to the frontend is the very same including all
Xenstore paths, while the backend paths in Xenstore differ ("qusb"
instead ov "vusb").
Signed-off-by: Juergen Gross
---
V6: add Xenstore path documentation
V4: bail out in case of usbback_is_loaded() error as requested by
Chun Yan Liu
---
docs/man/xl.cfg.pod.5| 11 +++-
docs/misc/xenstore-paths.markdown| 7 +++
tools/libxl/libxl_device.c | 3 +-
tools/libxl/libxl_dm.c | 8 +++
tools/libxl/libxl_internal.h | 1 +
tools/libxl/libxl_pvusb.c| 116 ---
tools/libxl/libxl_types.idl | 1 +
tools/libxl/libxl_types_internal.idl | 1 +
8 files changed, 122 insertions(+), 26 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index ec739cc..a4cc1b3 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -737,8 +737,15 @@ Possible Bs are:
=item B
-Specifies the usb controller type. Currently only 'pv' and 'auto'
-are supported.
+Specifies the usb controller type.
+
+"pv" denotes a kernel based pvusb backend.
+
+"qusb" specifies a qemu base backend for pvusb.
+
+"auto" (the default) determines whether a kernel based backend is installed.
+If this is the case, "pv" is selected, "qusb" will be selected if no kernel
+backend is currently available.
=item B
diff --git a/docs/misc/xenstore-paths.markdown
b/docs/misc/xenstore-paths.markdown
index 890d261..fa88ed5 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -348,6 +348,13 @@ A PV SCSI backend.
A PV console backend. Described in [console.txt](console.txt)
+ ~/backend/qusb/$DOMID/$DEVID/* []
+
+A PV USB device backend. Described by
+[xen/include/public/io/usbif.h][USBIF]
+
+Uses the qemu based USB backend.
+
~/device-model/$DOMID/* [INTERNAL]
Information relating to device models running in the domain. $DOMID is
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 4ced9b6..eba3087 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -680,7 +680,8 @@ void libxl__devices_destroy(libxl__egc *egc,
libxl__devices_remove_state *drs)
aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
aodev->dev = dev;
aodev->force = drs->force;
-if (dev->backend_kind == LIBXL__DEVICE_KIND_VUSB)
+if (dev->backend_kind == LIBXL__DEVICE_KIND_VUSB ||
+dev->backend_kind == LIBXL__DEVICE_KIND_QUSB)
libxl__initiate_device_usbctrl_remove(egc, aodev);
else
libxl__initiate_device_generic_remove(egc, aodev);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 1ade4e4..68ccbd1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2167,6 +2167,14 @@ int libxl__need_xenpv_qemu(libxl__gc *gc,
libxl_domain_config *d_config)
}
}
+for (i = 0; i < d_config->num_usbctrls; i++) {
+ if (d_config->usbctrls[i].type == LIBXL_USBCTRL_TYPE_QUSB &&
+ d_config->usbctrls[i].backend_domid == domid) {
+ret = 1;
+goto out;
+}
+}
+
out:
return ret;
}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c06ffc0..20b6122 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -487,6 +487,7 @@ typedef struct {
#define QEMU_BACKEND(dev) (\
(dev)->backend_kind == LIBXL__DEVICE_KIND_QDISK || \
(dev)->backend_kind == LIBXL__DEVICE_KIND_VFB || \
+(dev)->backend_kind == LIBXL__DEVICE_KIND_QUSB || \
(dev)->backend_kind == LIBXL__DEVICE_KIND_VKBD)
#define XC_PCI_BDF "0x%x, 0x%x, 0x%x, 0x%x"
diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
index 5f92628..68e5673 100644
--- a/tools/libxl/libxl_pvusb.c
+++ b/tools/libxl/libxl_pvusb.c
@@ -22,6 +22,21 @@
#define USBHUB_CLASS_CODE 9
+static int usbback_is_loaded(libxl__gc *gc)
+{
+int r;
+struct stat st;
+
+r = lstat(SYSFS_USBBACK_DRIVER, &st);
+
+if (r == 0)
+return 1;
+if (r < 0 && errno == ENOENT)
+return 0;
+LOGE(ERROR, "Accessing %s", SYSFS_USBBACK_DRIVER);
+return ERROR_FAIL;
+}
+
static int libxl__device_usbctrl_setdefault(libxl__gc *gc, uint32_t domid,
libxl_device_usbctrl *usbctrl)
{
@@ -36,7 +51,11 @@ static int libxl__device_usbctrl_setdefault(libxl__gc *gc,
uint32_t domid,
if (usbctrl->type == LIBXL_USBCTRL_TYPE_AUTO) {
if (domtype == LIBXL_DOMAIN_TYPE_PV) {
-usbctrl->typ
[Xen-devel] [PATCH v6 5/6] libxl: add service function to check whether device model is running
Add an internal service function to check for a running device model.
This can be used later when adding devices to a domain requiring a
device model for either printing an error message or starting the
device model in case it is not already running.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
tools/libxl/libxl.c | 4 +---
tools/libxl/libxl_dm.c | 10 ++
tools/libxl/libxl_internal.h | 1 +
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 20e0019..19a4b56 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1532,7 +1532,6 @@ void libxl__destroy_domid(libxl__egc *egc,
libxl__destroy_domid_state *dis)
libxl_ctx *ctx = CTX;
uint32_t domid = dis->domid;
char *dom_path;
-char *pid;
int rc, dm_present;
libxl__ev_child_init(&dis->destroyer);
@@ -1555,8 +1554,7 @@ void libxl__destroy_domid(libxl__egc *egc,
libxl__destroy_domid_state *dis)
}
/* fall through */
case LIBXL_DOMAIN_TYPE_PV:
-pid = libxl__xs_read(gc, XBT_NULL,
GCSPRINTF("/local/domain/%d/image/device-model-pid", domid));
-dm_present = (pid != NULL);
+dm_present = libxl__dm_active(gc, domid);
break;
case LIBXL_DOMAIN_TYPE_INVALID:
rc = ERROR_FAIL;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 68ccbd1..86fabd7 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2179,6 +2179,16 @@ out:
return ret;
}
+int libxl__dm_active(libxl__gc *gc, uint32_t domid)
+{
+char *pid, *path;
+
+path = GCSPRINTF("/local/domain/%d/image/device-model-pid", domid);
+pid = libxl__xs_read(gc, XBT_NULL, path);
+
+return pid != NULL;
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 20b6122..144c715 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1623,6 +1623,7 @@ _hidden bool libxl__query_qemu_backend(libxl__gc *gc,
uint32_t backend_id,
const char *type,
bool def);
+_hidden int libxl__dm_active(libxl__gc *gc, uint32_t domid);
/*
* This function will fix reserved device memory conflict
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 2/6] libxl: make libxl__need_xenpv_qemu() operate on domain config
libxl__need_xenpv_qemu() is called with configuration data for console,
vfbs, disks and channels today in order to evaluate the need for
starting a device model for a pv domain.
The console data is local to the caller and setup in a way to never
require a device model. All other data is taken from the domain config
structure.
In order to support other device backends via qemu change the interface
of libxl__need_xenpv_qemu() to take the domain config structure as
input instead of the single device arrays.
Signed-off-by: Juergen Gross
---
V6: Split patch into 2 as requested by Wei Liu
V4: Return (negative) error value in case of failure, 0 or 1 else
V2: Return false if libxl__get_domid() fails as requested by George Dunlap
---
tools/libxl/libxl_create.c | 13 +++---
tools/libxl/libxl_dm.c | 60 +---
tools/libxl/libxl_internal.h | 5 +---
3 files changed, 23 insertions(+), 55 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 763996c..0681103 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1313,18 +1313,13 @@ static void domcreate_launch_dm(libxl__egc *egc,
libxl__multidev *multidev,
}
init_console_info(gc, &console, 0);
+console.backend_domid = state->console_domid;
+libxl__device_console_add(gc, domid, &console, state, &device);
+libxl__device_console_dispose(&console);
-ret = libxl__need_xenpv_qemu(gc, 1, &console,
-d_config->num_vfbs, d_config->vfbs,
-d_config->num_disks, &d_config->disks[0],
-d_config->num_channels, &d_config->channels[0]);
+ret = libxl__need_xenpv_qemu(gc, d_config);
if (ret < 0)
goto error_out;
-
-console.backend_domid = state->console_domid;
-libxl__device_console_add(gc, domid, &console, state, &device);
-libxl__device_console_dispose(&console);
-
if (ret) {
dcs->dmss.dm.guest_domid = domid;
libxl__spawn_local_dm(egc, &dcs->dmss.dm);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index eb8961d..027d32b 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2114,61 +2114,37 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t
domid)
}
/* Return 0 if no dm needed, 1 if needed and <0 if error. */
-int libxl__need_xenpv_qemu(libxl__gc *gc,
-int nr_consoles, libxl__device_console *consoles,
-int nr_vfbs, libxl_device_vfb *vfbs,
-int nr_disks, libxl_device_disk *disks,
-int nr_channels, libxl_device_channel *channels)
+int libxl__need_xenpv_qemu(libxl__gc *gc, libxl_domain_config *d_config)
{
-int i, ret = 0;
+int i, ret;
uint32_t domid;
-/*
- * qemu is required in order to support 2 or more consoles. So switch all
- * backends to qemu if this is the case
- */
-if (nr_consoles > 1) {
-for (i = 0; i < nr_consoles; i++)
-consoles[i].consback = LIBXL__CONSOLE_BACKEND_IOEMU;
-ret = 1;
+ret = libxl__get_domid(gc, &domid);
+if (ret) {
+LOG(ERROR, "unable to get domain id");
goto out;
}
-for (i = 0; i < nr_consoles; i++) {
-if (consoles[i].consback == LIBXL__CONSOLE_BACKEND_IOEMU) {
-ret = 1;
-goto out;
-}
-}
-
-if (nr_vfbs > 0) {
+if (d_config->num_vfbs > 0) {
ret = 1;
goto out;
}
-if (nr_disks > 0) {
-ret = libxl__get_domid(gc, &domid);
-if (ret) goto out;
-for (i = 0; i < nr_disks; i++) {
-if (disks[i].backend == LIBXL_DISK_BACKEND_QDISK &&
-disks[i].backend_domid == domid) {
-ret = 1;
-goto out;
-}
+for (i = 0; i < d_config->num_disks; i++) {
+if (d_config->disks[i].backend == LIBXL_DISK_BACKEND_QDISK &&
+d_config->disks[i].backend_domid == domid) {
+ret = 1;
+goto out;
}
}
-if (nr_channels > 0) {
-ret = libxl__get_domid(gc, &domid);
-if (ret) goto out;
-for (i = 0; i < nr_channels; i++) {
-if (channels[i].backend_domid == domid) {
-/* xenconsoled is limited to the first console only.
- Until this restriction is removed we must use qemu for
- secondary consoles which includes all channels. */
-ret = 1;
-goto out;
-}
+for (i = 0; i < d_config->num_channels; i++) {
+if (d_config->channels[i].backend_domid == domid) {
+/* xenconsoled is limited to the first console only.
+ Until this restriction is removed we must use qemu for
+ secondary consoles which includes all channels. */
+ret = 1;
+goto out;
}
}
diff --git a/tools/libxl/libxl_internal.h b/tools/li
[Xen-devel] [PATCH v6 1/6] libxl: handle error from libxl__need_xenpv_qemu() correctly
In case libxl__need_xenpv_qemu() returns an error let domain creation
fail.
Signed-off-by: Juergen Gross
---
V6: Add comment regarding return values of libxl__need_xenpv_qemu()
as requested by Wei Liu
---
tools/libxl/libxl_create.c | 7 ---
tools/libxl/libxl_dm.c | 1 +
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 61b5c01..763996c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1304,7 +1304,6 @@ static void domcreate_launch_dm(libxl__egc *egc,
libxl__multidev *multidev,
}
case LIBXL_DOMAIN_TYPE_PV:
{
-int need_qemu = 0;
libxl__device_console console;
libxl__device device;
@@ -1315,16 +1314,18 @@ static void domcreate_launch_dm(libxl__egc *egc,
libxl__multidev *multidev,
init_console_info(gc, &console, 0);
-need_qemu = libxl__need_xenpv_qemu(gc, 1, &console,
+ret = libxl__need_xenpv_qemu(gc, 1, &console,
d_config->num_vfbs, d_config->vfbs,
d_config->num_disks, &d_config->disks[0],
d_config->num_channels, &d_config->channels[0]);
+if (ret < 0)
+goto error_out;
console.backend_domid = state->console_domid;
libxl__device_console_add(gc, domid, &console, state, &device);
libxl__device_console_dispose(&console);
-if (need_qemu) {
+if (ret) {
dcs->dmss.dm.guest_domid = domid;
libxl__spawn_local_dm(egc, &dcs->dmss.dm);
return;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index cfda24c..eb8961d 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2113,6 +2113,7 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t
domid)
GCSPRINTF("/local/domain/%d/image/device-model-pid", domid));
}
+/* Return 0 if no dm needed, 1 if needed and <0 if error. */
int libxl__need_xenpv_qemu(libxl__gc *gc,
int nr_consoles, libxl__device_console *consoles,
int nr_vfbs, libxl_device_vfb *vfbs,
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 0/6] libxl: add support for qemu base pvusb backend
This patch series is meant to be applied on top of Chunyan's series to support pvusb in libxl. It is adding support for an alternative pvusb backend "qusb" via qemu. Changes in V6: - split patch 1 into 2 patches as requested by Wei Liu - patch 1: Add comment regarding return values of libxl__need_xenpv_qemu() as requested by Wei Liu - patch 3 (was 2): add Xenstore path documentation as requested by Wei Liu - patch 4 (was 3): add Xenstore path documentation Changes in V5: - added new patch 2 as requested by George Dunlap Changes in V4: - dropped patch 5 - patch 1: Return (negative) error value in case of failure, 0 or 1 else - patch 2: Bail out in case of usbback_is_loaded() error as requested by Chun Yan Liu Changes in V3: - added new patches 3 and 4 to at least report failure in case no device model is running when adding devices to a domain requiring a dm. Changes in V2: - patch 1: Return false if libxl__get_domid() fails as requested by George Dunlap - Swapped patches 2 and 3 as former patch 2 has been questioned to make sense for 4.7. This will remove an obstacle for former patch 3 to go in. Juergen Gross (6): libxl: handle error from libxl__need_xenpv_qemu() correctly libxl: make libxl__need_xenpv_qemu() operate on domain config libxl: add query function for backend support by device model libxl: add new pvusb backend "qusb" provided by qemu libxl: add service function to check whether device model is running libxl: check for dynamic device model start required docs/man/xl.cfg.pod.5| 11 +++- docs/misc/xenstore-paths.markdown| 14 tools/libxl/libxl.c | 16 - tools/libxl/libxl_create.c | 12 ++-- tools/libxl/libxl_device.c | 3 +- tools/libxl/libxl_dm.c | 116 + tools/libxl/libxl_internal.h | 15 +++-- tools/libxl/libxl_pci.c | 3 + tools/libxl/libxl_pvusb.c| 122 --- tools/libxl/libxl_types.idl | 1 + tools/libxl/libxl_types_internal.idl | 1 + 11 files changed, 233 insertions(+), 81 deletions(-) -- 2.6.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 6/6] libxl: check for dynamic device model start required
Add a service routine checking whether a device model must be started
after adding a device to a domain.
Signed-off-by: Juergen Gross
Acked-by: Ian Jackson
---
tools/libxl/libxl.c | 12
tools/libxl/libxl_dm.c | 22 ++
tools/libxl/libxl_internal.h | 3 +++
tools/libxl/libxl_pci.c | 3 +++
tools/libxl/libxl_pvusb.c| 6 ++
5 files changed, 46 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 19a4b56..9057230 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2084,6 +2084,9 @@ void libxl__device_vtpm_add(libxl__egc *egc, uint32_t
domid,
if (rc) goto out;
DEVICE_ADD(vtpm, vtpms, domid, &vtpm_saved, COMPARE_DEVID, &d_config);
+
+rc = libxl__dm_check_start(gc, &d_config, domid);
+if (rc) goto out;
}
for (;;) {
@@ -2388,6 +2391,9 @@ static void device_disk_add(libxl__egc *egc, uint32_t
domid,
if (rc) goto out;
DEVICE_ADD(disk, disks, domid, &disk_saved, COMPARE_DISK, &d_config);
+
+rc = libxl__dm_check_start(gc, &d_config, domid);
+if (rc) goto out;
}
for (;;) {
@@ -2928,6 +2934,9 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *disk,
DEVICE_ADD(disk, disks, domid, &disk_saved, COMPARE_DISK, &d_config);
+rc = libxl__dm_check_start(gc, &d_config, domid);
+if (rc) goto out;
+
if (dm_ver == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
rc = libxl__qmp_insert_cdrom(gc, domid, disk);
if (rc) goto out;
@@ -3354,6 +3363,9 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t
domid,
if (rc) goto out;
DEVICE_ADD(nic, nics, domid, &nic_saved, COMPARE_DEVID, &d_config);
+
+rc = libxl__dm_check_start(gc, &d_config, domid);
+if (rc) goto out;
}
for (;;) {
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 86fabd7..8ef24a7 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2189,6 +2189,28 @@ int libxl__dm_active(libxl__gc *gc, uint32_t domid)
return pid != NULL;
}
+int libxl__dm_check_start(libxl__gc *gc, libxl_domain_config *d_config,
+ uint32_t domid)
+{
+int rc;
+
+if (libxl__dm_active(gc, domid))
+return 0;
+
+rc = libxl__need_xenpv_qemu(gc, d_config);
+if (rc < 0)
+goto out;
+
+if (!rc)
+return 0;
+
+LOG(ERROR, "device model required but not running");
+rc = ERROR_FAIL;
+
+out:
+return rc;
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 144c715..f61eaf0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1624,6 +1624,9 @@ _hidden bool libxl__query_qemu_backend(libxl__gc *gc,
const char *type,
bool def);
_hidden int libxl__dm_active(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__dm_check_start(libxl__gc *gc,
+ libxl_domain_config *d_config,
+ uint32_t domid);
/*
* This function will fix reserved device memory conflict
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index dc10cb7..300fd4d 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -169,6 +169,9 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc,
uint32_t domid, libxl_d
DEVICE_ADD(pci, pcidevs, domid, &pcidev_saved, COMPARE_PCI, &d_config);
+rc = libxl__dm_check_start(gc, &d_config, domid);
+if (rc) goto out;
+
for (;;) {
rc = libxl__xs_transaction_start(gc, &t);
if (rc) goto out;
diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
index 68e5673..c9b7c4a 100644
--- a/tools/libxl/libxl_pvusb.c
+++ b/tools/libxl/libxl_pvusb.c
@@ -145,6 +145,9 @@ static int libxl__device_usbctrl_add_xenstore(libxl__gc
*gc, uint32_t domid,
DEVICE_ADD(usbctrl, usbctrls, domid, &usbctrl_saved,
COMPARE_USBCTRL, &d_config);
+rc = libxl__dm_check_start(gc, &d_config, domid);
+if (rc) goto out;
+
if (usbctrl->type == LIBXL_USBCTRL_TYPE_QUSB) {
if (!libxl__query_qemu_backend(gc, domid, usbctrl->backend_domid,
"qusb", false)) {
@@ -969,6 +972,9 @@ static int libxl__device_usbdev_add_xenstore(libxl__gc *gc,
uint32_t domid,
DEVICE_ADD(usbdev, usbdevs, domid, &usbdev_saved,
COMPARE_USB, &d_config);
+
+rc = libxl__dm_check_start(gc, &d_config, domid);
+if (rc) goto out;
}
for (;;) {
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-mingo-tip-master test] 87975: regressions - FAIL
flight 87975 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/87975/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 60684 test-amd64-amd64-xl-xsm 14 guest-saverestore fail REGR. vs. 60684 test-amd64-amd64-libvirt 15 guest-saverestore.2 fail REGR. vs. 60684 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail REGR. vs. 60684 test-amd64-amd64-xl 15 guest-localmigratefail REGR. vs. 60684 test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 60684 test-amd64-amd64-libvirt-xsm 14 guest-saverestore fail REGR. vs. 60684 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 60684 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10fail REGR. vs. 60684 test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail blocked in 60684 test-amd64-i386-xl 15 guest-localmigrate fail blocked in 60684 test-amd64-i386-libvirt 15 guest-saverestore.2 fail blocked in 60684 test-amd64-i386-xl-xsm 15 guest-localmigrate fail blocked in 60684 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 60684 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 60684 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 60684 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail 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 version targeted for testing: linuxa317e8e232e8a2401e78542a11d6c8acf7c068f0 baseline version: linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0 Last test of basis60684 2015-08-13 04:21:46 Z 231 days Failing since 60712 2015-08-15 18:33:48 Z 228 days 173 attempts Testing same since87975 2016-03-30 04:44:35 Z0 days1 attempts 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 build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl fail test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 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-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm fail test-amd64-i386-libvirt-xsm
Re: [Xen-devel] [PATCH v13 00/26] COarse-grain LOck-stepping Virtual Machines for Non-stop Service
I've checked all patches in this thread after Ian's comments, it seems
we can give A-B to p12, p14, p20, p23, p25, p26 now.
All in all, *all patches are acked-by*.
Thanks
-Xie
On 03/25/2016 02:44 PM, Changlong Xie wrote:
This patchset implemented the COLO feature for Xen.
For detail/install/use of COLO feature, refer to:
http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
You can get the codes from here:
https://github.com/Pating/xen/tree/changlox/colo_v13
Changlog from v12 to v13
1. Rebase to the upstream xen
2. Address commnets from Ian and Liu Wei.
p7, Add A-B
p8, Add A-B
p10, Add A-B
p11, Add A-B
p12, Add LOG(ERROR, )
p13, Add A-B
p14, Remove libxl__ao_complete(xxx)
p15, Add A-B
p16, Add A-B
p17, Add A-B, replace "-c" with "--colo" for migrate-receive()
p19, Add A-B, introduce "switch ... case ..."
p21, Add A-B
p22, Add A-B
p23, replace "forwarddev" with "coloft_fowarddev"
p24, Add A-B
p25, Add A-B
p26, replace "--script" with "--coloft-script"
Changlog from v11 to v12
1. Rebase to the upstream xen
2. Address commnets from Ian, Liu Wei and Konard.
Removed old p12,p13; introduce a new p13 what is splited out from old p15,
introduce
a new p19 what is splited out from old p20.
p1, add A-B, and will update commit message when "xen-load-devices-state"
relevant
patch merged on qemu side
p3, update comments, add assert() in libxl_domain_create_restore()
p4, rename "dup_fd_helper" as "dup_cloexec", add missed newline
p5, add A-B
p7, remove repeated commit message, update the specification of libxl
p8, update the specification of libxc
p9, add A-B
p10, update commit message, fix blank line issue
p12, merged by old p12,p13(restore_callbacks wait_checkpoit/postcopy/suspend),
fix blank
line issues, update comments about why COLO only supports HVM
p13, move stream read manipulations to right place in libxl_internal.h
p14, merged by old p12(save_callbacks wait_checkpoint), fix blank line issues,
update Copyright(C)
p16, add "colo_" prefix for merge_secondary_dirty_bitmap()
p17, update COLO description part on man page
p18, fix long line issue
p19, just introduce colo mode and refactor relevant functions
p20, fix repetitive code in libxl__device_disk_from_xs_be(), make colo_port as
int,
remove unnecessary comments in libxl__build_device_model_args_new(), simplify
disk_try_backend() and move the main part to in colo_qdisk_setup() in p21
p21, fix blank line issue, update Copyright(C)
p22, merged by old p22,p23, update Copyright(C), add commets for NETLINK_COLO,
remove unnecessary
'{ }', update url in commit message
p23, fix blank line issue, add some comments for "forwarddev", update
Copyright(C)
p24, introduce COLO_PROXY_CHECKPOINT_TIMEOUT, ASYNC_CALL
p26, move colo_proxy_script setup codes to libxl__colo_restore_setup(),
introduce long options
for main_migrate_receive()
Changlog from v10 to v11
1. Rebased to then upstream xen
2. Address comments from Liu Wei
p1, update commit message and remove libxl__domain_restore_device_model
p4, add A-B
p5, update commit message
p6, add A-B
p7,p8 add email address and direction info
p10, merged by old p10,p11 and update comments
p11, merged by old p12,p13 and update comments
p14,p15 move colo structures and functions into libxl_colo.h, and list callbacks
in order, also update commit message
p16, merged by old p18,p19,p20 and remove TODOs
p17, use original code for checking postcopy return value
p18, simplify *if* logic, fix wrong comments, and unset dom_info.quiet in COLO
p19, add A-B
p20, fix code style, update comments and man page
p21,p22,p23,p24 move colo structures and functions into libxl_colo.h
Changlog from v9 to v10
1. Rebased to the upstream xen
2. Fix one bug found in the test
3. Merge some patches from prepare series
4. Split patch 5 to two patches(patch 4 and 5) according to the comments from
Wei Liu
Changlog from v8 to v9:
1. Rebased to the upstream xen
2. Fix some bugs found in the test
Changelog from v7 to v8:
1. Rebased to the latest libxl migration v2.
Changelog from v6 to v7:
1. Ported to Libxl migration v2
2. Send dirty bitmap from secondary to primary on libxc side
3. Address review comments
Changelog from v5 to v6:
1. based on migration v2(libxc)
2. split the patchset into prerequisite patchset and this main patchset.
Changelog from v4 to v5:
1. rebase to the latest xen upstream
2. disk replication: blktap2->qdisk
3. nic replication: colo-agent->colo-proxy
Changelog from v3 to v4:
1. rebase to newest xen
2. bug fix
Changlog from v2 to v3:
1. rebase to newest remus
2. add nic replication support
Changlog from v1 to v2:
1. rebase to newest remus
2. add disk replication support
Changlong Xie (2):
libxl_internal: move stream read manipulations to right place
Introduce COLO mode and refactor relevant function
Wen Congyang (24):
tools/libxl: introduction of libxl__qmp_restore to load qemu state
tools/libxl: introduce libxl__domain_common_switch_qemu_logdirty()
tools/libxl: Add back channel to allow migr
Re: [Xen-devel] [PATCH v13 25/26] setup and control colo proxy on secondary side
On 03/30/2016 10:24 PM, Ian Jackson wrote:
Changlong Xie writes ("[PATCH v13 25/26] setup and control colo proxy on secondary
side"):
From: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
I think I acked this in v12. I guess you probably overlooked that,
but your v13 00/25 says
p25, Add A-B
Can you please check that you didn't mistakenly add the acked-by to
the wrong patch ?
Hi Ian
I've checked all patches. It's my fault, i just forgot to add A-B in
this patch.
Thanks
-Xie
Thanks,
Ian.
.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13 00/26] COarse-grain LOck-stepping Virtual Machines for Non-stop Service
On 03/30/2016 10:50 PM, Ian Jackson wrote:
> Changlong Xie writes ("[PATCH v13 00/26] COarse-grain LOck-stepping Virtual
> Machines for Non-stop Service"):
>> This patchset implemented the COLO feature for Xen.
>> For detail/install/use of COLO feature, refer to:
>> http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
>>
>> You can get the codes from here:
>> https://github.com/Pating/xen/tree/changlox/colo_v13
>
> I fetched the branches `colo_v13' and `colo_v13_fixup' and it seems
> that I can get the proper versions of v13.1 from the latter. I have
> acked them accordingly.
>
> Can you confirm that that branch is what you intend for upstream ?
>
> If so, I have a question about it:
>
> There are two patches in it which have not been posted as part of your
> series and are marked as "[DO NOT MERGE]". (Thanks for your admirably
> clear marking, btw.)
>
> They are
> [DONT MERGE] don't create default ioreq server
> [DONT MERGE] tools/libxc: support to resume uncooperative HVM guests
>
>
> The latter patch "support to resume uncooperative HVM guests" seems to
> have been posted a number of times and AFAICT most recently as
> [PATCH v8 05/13] tools/libxc: support to resume uncooperative HVM guests
> on the 18th of February.
>
> Is that not required for COLO ? We need to sort this out, I think.
Yes, it is required for COLO.
>
>
> What is the status of the default ioreq server patch ? Why is it in
> your git branch ?
I have reported this bug last year:
http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02850.html
This patch is just a temporary patch.
Thanks
Wen Congyang
>
>
> Thanks,
> Ian.
>
>
> .
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 test] 87967: regressions - trouble: blocked/broken/fail/pass
flight 87967 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/87967/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken in 87395 REGR. vs. 66399 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-arndale 3 host-install(3) broken pass in 87856 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 86830 pass in 87967 test-armhf-armhf-xl-xsm 16 guest-start.2 fail in 87117 pass in 86830 test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 87204 pass in 87856 test-armhf-armhf-libvirt-qcow2 6 xen-boot fail in 87204 pass in 87967 test-armhf-armhf-xl-cubietruck 11 guest-start fail in 87204 pass in 87967 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 87295 pass in 87967 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 87295 pass in 87967 test-armhf-armhf-xl-credit2 16 guest-start.2 fail in 87395 pass in 87295 test-armhf-armhf-xl-credit2 11 guest-startfail in 87582 pass in 87967 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 87582 pass in 87967 test-armhf-armhf-xl-cubietruck 16 guest-start.2fail in 87856 pass in 87295 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail pass in 87117 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 87204 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail pass in 87395 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 87582 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 87765 test-armhf-armhf-xl 11 guest-start fail pass in 87856 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 87856 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 87582 like 66399 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 66399 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 66399 test-armhf-armhf-xl-vhd 9 debian-di-installfail like 66399 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1)blocked in 87395 n/a build-amd64-rumpuserxen 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-xl 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-libvirt 1 build-check(1)blocked in 87395 n/a test-amd64-i386-xl1 build-check(1)blocked in 87395 n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-pygrub 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-xl-credit2 1 build-check(1)blocked in 87395 n/a test-amd64-i386-libvirt 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-libvirt-xsm 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-i386-pvgrub 1 build-check(1)blocked in 87395 n/a test-amd64-i386-pair 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-pair 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked in 87395 n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-xl-rtds 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 87395 n/a test-amd64-i386-libvirt-pair 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-xl-qcow2 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked in 87395 n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 87395 n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked in 87395 n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked in 87395 n/a test-am
[Xen-devel] [libvirt test] 87976: tolerable FAIL - PUSHED
flight 87976 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87976/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail 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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass
version targeted for testing:
libvirt e23a640c4215e358d80df675fc6040f8c04eaa84
baseline version:
libvirt 33a1a7c6f5cae8f7682af98722630b554771ae62
Last test of basis87831 2016-03-29 04:26:43 Z1 days
Testing same since87976 2016-03-30 04:32:45 Z0 days1 attempts
People who touched revisions under test:
Chunyan Liu
Jim Fehlig
Jiri Denemark
Maxim Nestratov
Michal Privoznik
Nitesh Konkar
Peter Krempa
Qiaowei Ren
Roman Bogorodskiy
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-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-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pairpass
test-amd64-i386-libvirt-pair pass
test-armhf-armhf-libvirt-qcow2 fail
test-armhf-armhf-libvirt-raw fail
test-amd64-amd64-libvirt-vhd 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=libvirt
+ revision=e23a640c4215e358d80df675fc6040f8c04eaa84
+ . ./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/osst
[Xen-devel] [xen-unstable-smoke test] 88046: tolerable all pass - PUSHED
flight 88046 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/88046/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen d275ec9ca8a86f7c9c213f3551194d471ce90fbd
baseline version:
xen 72a91f67714638ea664155ee253bcb02b1c6ae54
Last test of basis88027 2016-03-30 18:03:25 Z0 days
Testing same since88046 2016-03-30 21:09:00 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper [for the Ocaml stubs]
Daniel De Graaf [XSM bits]
George Dunlap [xenctx bits]
Jan Beulich
Konrad Rzeszutek Wilk
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=d275ec9ca8a86f7c9c213f3551194d471ce90fbd
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
d275ec9ca8a86f7c9c213f3551194d471ce90fbd
+ branch=xen-unstable-smoke
+ revision=d275ec9ca8a86f7c9c213f3551194d471ce90fbd
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' xd275ec9ca8a86f7c9c213f3551194d471ce90fbd = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"}
[Xen-devel] [xen-unstable test] 87908: regressions - FAIL
flight 87908 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/87908/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 86491 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-localmigrate fail in 87625 REGR. vs. 86491 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-win7-amd64 12 guest-saverestore fail in 87820 pass in 87908 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 87551 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail pass in 87551 test-amd64-amd64-xl-qemut-win7-amd64 12 guest-saverestore fail pass in 87625 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-saverestorefail pass in 87820 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail in 87551 like 86491 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 87820 like 86491 test-armhf-armhf-xl-rtds 11 guest-start fail in 87820 like 86491 build-i386-rumpuserxen6 xen-buildfail like 86491 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86491 build-amd64-rumpuserxen 6 xen-buildfail like 86491 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 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-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail 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 version targeted for testing: xen 04119085f5a2a135e5161535b8821e1aa0d7db8a baseline version: xen a6f2cdb633bf519244a16674031b8034b581ba7f Last test of basis86491 2016-03-17 15:24:59 Z 13 days Failing since 86560 2016-03-18 10:56:34 Z 12 days 16 attempts Testing same since87461 2016-03-26 13:04:52 Z4 days6 attempts People who touched revisions under test: Andrew Cooper Chunyan Liu Dagaen Golomb Daniel De Graaf Dario Faggioli Dave Scott David Scott David Vrabel Doug Goldstein George Dunl
Re: [Xen-devel] [LKP] [PATCH v3 0/7] Enhance PAT init to fix Xorg crashes
On Wed, Mar 30, 2016 at 1:29 PM, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 30, 2016 at 01:10:29PM -0700, Luis R. Rodriguez wrote: > > Are you saying that you expect Xen maintainers to _NOT_ test Xen related > patches? Especially ones they have been involved with? Of course not, I'm saying we have a bottleneck on development if we need to wait for Xen patches to be tested, and we can do better if we had 0-day testing this for us. In this case it was *me* who brought up the issue of a Xen conflict early, and later through other iterations Toshi addressed this, given we have the technology and bandwidth to do more testing with 0-day we should not have to count on me or others to do the proactive review to ensure there is no Xen conflict, or on Boris for final confirmation. Its a nobrainer the value of integration of Xen with 0-day. >> If its really trivial then you give me the impression you can help >> with its integration. 0-day is open after all. > > I have no clue on how the 0-day works - hence my question. I would be more > than > happy to help once free time lines up. Great. Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [LKP] [PATCH v3 0/7] Enhance PAT init to fix Xorg crashes
On Wed, Mar 30, 2016 at 01:10:29PM -0700, Luis R. Rodriguez wrote: > On Wed, Mar 30, 2016 at 11:58 AM, Konrad Rzeszutek Wilk > wrote: > > On Wed, Mar 30, 2016 at 11:02:13AM -0700, Luis R. Rodriguez wrote: > >> On Tue, Mar 29, 2016 at 8:49 AM, Toshi Kani wrote: > >> > On Tue, 2016-03-29 at 10:46 -0400, Boris Ostrovsky wrote: > >> >> On 03/29/2016 10:19 AM, Toshi Kani wrote: > >> >> > On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote: > >> >> > > >> >> > > > I'd appreciate if someone can test this patch-set on Xen to verify > >> >> > > > that there is no change in "x86/PAT: Configuration [0-7] .." > >> >> > > > message in dmesg. > >> >> > > So I don't have a Xen setup, but hopefully such testing will happen > >> >> > > once these changes show up in linux-next, tomorrow or so. > >> >> > I will address if any issue is found in testing. > >> >> > >> >> I ran a subset of out nightly test. Nobody died. > >> >> > >> >> So this all looks good. (It actually may have also fixed another bug > >> >> that was reported recently by Olaf, copied here) > >> > > >> > Cool! Thanks Boris! > >> > >> Hoping Boris or someone on the Xen front would test this prior to > >> merging helps but it also slows us down, a while ago we discussed the > > > > Boris did test it _before_ it was merged. > > Yes, my point being that we should not need Boris to test collateral > Xen patches. /me scratches his head. Are you saying that you expect Xen maintainers to _NOT_ test Xen related patches? Especially ones they have been involved with? > > >> possibility of getting Linux Xen guests automatically tested as part > >> of 0-day, this way then when a developer (in this case Toshi) pushes > >> to his own tree, he'd be able to just sit and wait for the results, > >> without having to hope Boris or someone goes out and tests. > > > > In Fedora you just need to do: > > > > #yum install xen > > #reboot > > And pick the Xen option. > > > > Probably the same thing with Debian and Ubuntu - just 'apt-get install xen' > > We can't expect everyone to do that. > > >> Its a major undertaking to get Linux Xen guests boot strapped into 0-day, > > > > It is? > > If its really trivial then you give me the impression you can help > with its integration. 0-day is open after all. I have no clue on how the 0-day works - hence my question. I would be more than happy to help once free time lines up. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [LKP] [PATCH v3 0/7] Enhance PAT init to fix Xorg crashes
On Wed, Mar 30, 2016 at 11:58 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 30, 2016 at 11:02:13AM -0700, Luis R. Rodriguez wrote: >> On Tue, Mar 29, 2016 at 8:49 AM, Toshi Kani wrote: >> > On Tue, 2016-03-29 at 10:46 -0400, Boris Ostrovsky wrote: >> >> On 03/29/2016 10:19 AM, Toshi Kani wrote: >> >> > On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote: >> >> > >> >> > > > I'd appreciate if someone can test this patch-set on Xen to verify >> >> > > > that there is no change in "x86/PAT: Configuration [0-7] .." >> >> > > > message in dmesg. >> >> > > So I don't have a Xen setup, but hopefully such testing will happen >> >> > > once these changes show up in linux-next, tomorrow or so. >> >> > I will address if any issue is found in testing. >> >> >> >> I ran a subset of out nightly test. Nobody died. >> >> >> >> So this all looks good. (It actually may have also fixed another bug >> >> that was reported recently by Olaf, copied here) >> > >> > Cool! Thanks Boris! >> >> Hoping Boris or someone on the Xen front would test this prior to >> merging helps but it also slows us down, a while ago we discussed the > > Boris did test it _before_ it was merged. Yes, my point being that we should not need Boris to test collateral Xen patches. >> possibility of getting Linux Xen guests automatically tested as part >> of 0-day, this way then when a developer (in this case Toshi) pushes >> to his own tree, he'd be able to just sit and wait for the results, >> without having to hope Boris or someone goes out and tests. > > In Fedora you just need to do: > > #yum install xen > #reboot > And pick the Xen option. > > Probably the same thing with Debian and Ubuntu - just 'apt-get install xen' We can't expect everyone to do that. >> Its a major undertaking to get Linux Xen guests boot strapped into 0-day, > > It is? If its really trivial then you give me the impression you can help with its integration. 0-day is open after all. >> however such prospects were raised a while ago and it seems we >> may be able to get there. Just wanted to send a reminder about this >> possibility, and highlight this patch set as an ideal candidate where >> a proactive test could have helped as well. I proactively caught the >> original Xen issue, but git logs shows we are not doing so great in >> this area, so any help on the Xen side as well to help with 0-day >> integration would be appreciated. >> >> I'll follow up on another thread on that. > > Sure. It never hurts to have more coverage. Great. Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 88027: tolerable all pass - PUSHED
flight 88027 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/88027/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 72a91f67714638ea664155ee253bcb02b1c6ae54
baseline version:
xen d3ac192acc9ca5d48d97e98bb59c2c8e98ba0891
Last test of basis88009 2016-03-30 15:02:13 Z0 days
Testing same since88027 2016-03-30 18:03:25 Z0 days1 attempts
People who touched revisions under test:
Boris Ostrovsky
Jan Beulich
Jonathan Davies
Julien Grall
Naresh Bhat
Parth Dixit
Shannon Zhao
Stefano Stabellini
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=72a91f67714638ea664155ee253bcb02b1c6ae54
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
72a91f67714638ea664155ee253bcb02b1c6ae54
+ branch=xen-unstable-smoke
+ revision=72a91f67714638ea664155ee253bcb02b1c6ae54
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x72a91f67714638ea664155ee253bcb02b1c6ae54 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
[Xen-devel] [PATCH] Extending XL console command to take -e option.
By default, Character 0x1d i.e '^]' is used as escape character to terminate
logging.
Now,escape character can be passed with -escape option.
It can be any printable character.
As valid range for control character is first 32 characters(0-31d)
lower 5 bits of given character will be used as escape character.
Example: xl console -escape a testDomain
Signed-off-by: Sabiya Kazi
---
tools/console/client/main.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/tools/console/client/main.c b/tools/console/client/main.c
index d006fdc..6e303f5 100644
--- a/tools/console/client/main.c
+++ b/tools/console/client/main.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#ifdef __sun__
#include
#endif
@@ -42,13 +43,12 @@
#include
#include "xenctrl.h"
#include "_paths.h"
-
#define ESCAPE_CHARACTER 0x1d
static volatile sig_atomic_t received_signal = 0;
static char lockfile[sizeof (XEN_LOCK_DIR "/xenconsole.") + 8] = { 0 };
static int lockfd = -1;
-
+static char escapechar = ESCAPE_CHARACTER;
static void sighandler(int signum)
{
received_signal = 1;
@@ -214,7 +214,7 @@ static int console_loop(int fd, struct xs_handle *xs, char
*pty_path,
char msg[60];
len = read(STDIN_FILENO, msg, sizeof(msg));
- if (len == 1 && msg[0] == ESCAPE_CHARACTER) {
+ if (len == 1 && msg[0] == escapechar) {
return 0;
}
@@ -318,6 +318,14 @@ static void console_unlock(void)
}
}
+/*
+ *In ASCII, Valid range for control characters is 0-31
+ *Lower 5 bits of given char will be used as escape character.
+ */
+char getEscapeChar(const char *s) {
+return (*s ^ 0x40);
+}
+
int main(int argc, char **argv)
{
struct termios attr;
@@ -329,6 +337,7 @@ int main(int argc, char **argv)
struct option lopt[] = {
{ "type", 1, 0, 't' },
{ "num", 1, 0, 'n' },
+ { "escape", 1, 0, 'n' },
{ "help",0, 0, 'h' },
{ 0 },
@@ -363,6 +372,11 @@ int main(int argc, char **argv)
exit(EINVAL);
}
break;
+ case 'e' :
+ escapechar = getEscapeChar(optarg);
+break;
+
+
default:
fprintf(stderr, "Invalid argument\n");
fprintf(stderr, "Try `%s --help' for more
information.\n",
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 0/7] Enhance PAT init to fix Xorg crashes
On Wed, Mar 30, 2016 at 11:02:13AM -0700, Luis R. Rodriguez wrote: > On Tue, Mar 29, 2016 at 8:49 AM, Toshi Kani wrote: > > On Tue, 2016-03-29 at 10:46 -0400, Boris Ostrovsky wrote: > >> On 03/29/2016 10:19 AM, Toshi Kani wrote: > >> > On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote: > >> > > >> > > > I'd appreciate if someone can test this patch-set on Xen to verify > >> > > > that there is no change in "x86/PAT: Configuration [0-7] .." > >> > > > message in dmesg. > >> > > So I don't have a Xen setup, but hopefully such testing will happen > >> > > once these changes show up in linux-next, tomorrow or so. > >> > I will address if any issue is found in testing. > >> > >> I ran a subset of out nightly test. Nobody died. > >> > >> So this all looks good. (It actually may have also fixed another bug > >> that was reported recently by Olaf, copied here) > > > > Cool! Thanks Boris! > > Hoping Boris or someone on the Xen front would test this prior to > merging helps but it also slows us down, a while ago we discussed the Boris did test it _before_ it was merged. > possibility of getting Linux Xen guests automatically tested as part > of 0-day, this way then when a developer (in this case Toshi) pushes > to his own tree, he'd be able to just sit and wait for the results, > without having to hope Boris or someone goes out and tests. In Fedora you just need to do: #yum install xen #reboot And pick the Xen option. Probably the same thing with Debian and Ubuntu - just 'apt-get install xen' > > Its a major undertaking to get Linux Xen guests boot strapped into It is? > 0-day, however such prospects were raised a while ago and it seems we > may be able to get there. Just wanted to send a reminder about this > possibility, and highlight this patch set as an ideal candidate where > a proactive test could have helped as well. I proactively caught the > original Xen issue, but git logs shows we are not doing so great in > this area, so any help on the Xen side as well to help with 0-day > integration would be appreciated. > > I'll follow up on another thread on that. Sure. It never hurts to have more coverage. > > Luis > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 87936: regressions - FAIL
flight 87936 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/87936/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf ac14846aad016a1f88ebe4a09e00779dd03fcf88 baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 113 days Failing since 65593 2015-12-08 23:44:51 Z 112 days 130 attempts Testing same since87936 2016-03-29 20:44:41 Z0 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hess Chen Heyi Guo Jaben Carsey James Bottomley Jeff Fan Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com Jordan Justen Juliano Ciocari Karyne Mayer Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leo Duran Liming Gao Mark Rutland Marvin Haeuser Marvin Häuser Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qiu Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 15589 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.3-testing baseline-only test] 44285: regressions - trouble: blocked/broken/fail/pass
This run is configured for baseline tests only. flight 44285 xen-4.3-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44285/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 44266 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-credit2 3 host-install(3)broken blocked in 44266 test-armhf-armhf-xl-midway3 host-install(3)broken blocked in 44266 test-armhf-armhf-xl-multivcpu 3 host-install(3) broken blocked in 44266 test-armhf-armhf-xl-vhd 3 host-install(3)broken blocked in 44266 test-armhf-armhf-libvirt-raw 3 host-install(3)broken blocked in 44266 test-armhf-armhf-libvirt-qcow2 3 host-install(3) broken blocked in 44266 test-armhf-armhf-libvirt 3 host-install(3)broken blocked in 44266 test-armhf-armhf-xl 3 host-install(3)broken blocked in 44266 test-amd64-amd64-xl 19 guest-start/debian.repeatfail like 44266 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail like 44266 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail like 44266 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail like 44266 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail like 44266 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 44266 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-amd64-i386-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-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass version targeted for testing: xen 8fa31952e2d08ef63897c43b5e8b33475ebf5d93 baseline version: xen 4db81940ee9eb82b3b3895c449ccbbab4a7147a4 Last test of basis44266 2016-03-20 22:29:09 Z9 days Testing same since44285 2016-03-30 13:47:41 Z0 days1 attempts People who touched revisions under test: Jan Beulich jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl fail test-armhf-armhf-xl broken test-amd64-i386-xl pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64fail test-amd64-i386-xl-qemut-debianhvm-amd64 fail test-amd64-amd64-xl-qemuu-debianhvm-amd64fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail 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-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd6
Re: [Xen-devel] [PATCH 3/6] xentrace: P2M lookup suport for ARM platform
On 28/03/16 19:55, Ben Sanda wrote: Julien and George, Hi Ben, Sorry for the late answer. Thank you for the comments. I had one question I wanted to ask. A DOMID_XEN page could be read only too. For instance, the meta-data of the trace buffer is read-only (see t_info), we don't want a domain to be able to overwrite them. However, all the foreign page are mapped read-write. You will need to rework the code to map a foreign domain (see XENMAPSPACE_gmfn_foreign) to allow read-only foreign page (maybe by adding a new p2m_type_t?). I understand what you are saying in general, but I'm not familiar enough with the Xen memory mapping system to know how to actually implement this. The p2m_type_t p2m_ram_ro exists, which I could assign to read-only pages, but I'm unsure as to how to detect whether a request is to a read only mapping or a read-write. The normal (non DOMID_XEN) p2m_lookup function normally does this by reading the root- level page tables and somehow extracting the mapping type from the lpae_t structure. Given that we are not looking up the page tables for non-translated addresses, I'm not sure where/how to find the correct mapping type. Can I still lookup the page table entries for the MFN address and extract the p2m_type_t the same way? You can know if the page is writable by looking to the page field u.inuse.type_info (PGT_writable_page means the page is writable). Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 0/7] Enhance PAT init to fix Xorg crashes
On Tue, Mar 29, 2016 at 8:49 AM, Toshi Kani wrote: > On Tue, 2016-03-29 at 10:46 -0400, Boris Ostrovsky wrote: >> On 03/29/2016 10:19 AM, Toshi Kani wrote: >> > On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote: >> > >> > > > I'd appreciate if someone can test this patch-set on Xen to verify >> > > > that there is no change in "x86/PAT: Configuration [0-7] .." >> > > > message in dmesg. >> > > So I don't have a Xen setup, but hopefully such testing will happen >> > > once these changes show up in linux-next, tomorrow or so. >> > I will address if any issue is found in testing. >> >> I ran a subset of out nightly test. Nobody died. >> >> So this all looks good. (It actually may have also fixed another bug >> that was reported recently by Olaf, copied here) > > Cool! Thanks Boris! Hoping Boris or someone on the Xen front would test this prior to merging helps but it also slows us down, a while ago we discussed the possibility of getting Linux Xen guests automatically tested as part of 0-day, this way then when a developer (in this case Toshi) pushes to his own tree, he'd be able to just sit and wait for the results, without having to hope Boris or someone goes out and tests. Its a major undertaking to get Linux Xen guests boot strapped into 0-day, however such prospects were raised a while ago and it seems we may be able to get there. Just wanted to send a reminder about this possibility, and highlight this patch set as an ideal candidate where a proactive test could have helped as well. I proactively caught the original Xen issue, but git logs shows we are not doing so great in this area, so any help on the Xen side as well to help with 0-day integration would be appreciated. I'll follow up on another thread on that. Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 00/14] Load BIOS via toolstack instead of been embedded in hvmloader.
Anthony PERARD wrote: > Hi all, > > Few changes in V4: > I leave the ACPI alone and only load the BIOS via libxl now. > > Detail of changes in each patches. > > I've look at loading the BIOS via the toolstack instead of having them > embedded > in the hvmloader binary. After this patch series, hvmloader compilation would > be indenpendant from SeaBIOS and OVMF compilation. Hi Anthony, Wei, Any chance this series will make 4.7? AFAICT, there were no major issues in the reviews. I didn't review all the patches in detail, but have done quite a bit of testing with this series and haven't noticed any problems (beyond the current upstream ovmf breakage with Xen). Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 00/11] Return failure on failure for more xl commands
Yes, I was looking at wrong branch, I am sorry. The patches
* {01-04,08,11} were not attached in the previous patch [0].
* {05,06} are applied in the version made by George Dunlap.
I added the changes to return 0/1 in internal functions
and EXIT_{SUCCESS/FAILURE} according to [2]. It certainly should be
resend.
* 07 was attached in the previous patch but is not applied in staging.
It relates pci-* functions. I modified it as in the point higher.
* 09 is applied.
* 10 is not applied, I did not modified it. It brings coding style improvements.
Summing up the new changes
* 01-03 are the patches related to libxl_pci, the functions return error code
instead of always 0
* 04 modifies freemem from xl_cmdimpl to follow the pattern to return 0/1 for
not main functions
* 08 is a change to return error codes for main_tmem* related functions
* 11 is a change with improvement of coding style, change 'rc -> r'
Paulina
On 30 March 2016 at 17:14, Wei Liu wrote:
> On Wed, Mar 30, 2016 at 05:02:39PM +0200, Paulina Szubarczyk wrote:
>> This patch includes the changes from a patch prepared by George Dunlap
>> [0] and expands them to more xl commands.
>>
>
> Hello,
>
> Did you perhaps make a mistake? As far as I can tell some patches were
> already applied. Don't worry, we all make mistakes from time to time.
>
> I realise you might be looking at master branch. Please check staging
> branch to see if you should drop some of the already patches.
>
> And perhaps can you indicate which patches should we look at in case you
> don't want to resend just yet.
>
> Wei.
>
>> This is my bite-sized outreachy project [1][2].
>>
>> Return failure when the command failed for more xl commands:
>> - mem-set
>> - cd-insert
>> - pci-*
>> -- freemem
>> -- tmem-*
>>
>> This makes xl more useful for scripting.
>>
>> In the case of mem-set, it means first cleaning up
>> libxl_set_memory_target() to return useful error codes.
>>
>> For pci-* functions libxl__create_pci_backend(),
>> libxl__device_pci_destroy_all()
>> return error codes instead of always 0.
>>
>> Changes:
>> - Remove block-attach patch
>> - Split out removal of spurious getinfolist to a separate patch
>> - Try to follow CODING_STYLE more closely:
>> - In general, don't initialize rc / r, but use set-and-goto
>> - Use 'r' for non-libxl error codes
>> - Use EXIT_FAILURE and EXIT_SUCCESS rather than magic constants in
>> main_foo()
>> - Use 1 and 0 in internal functions of xl
>>
>> [0] http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02246.html
>> [1] http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03031.html
>> [2] https://www.mail-archive.com/xen-devel@lists.xen.org/msg62055.html
>>
>> CC: Wei Liu
>> CC: Ian Jackson
>> CC: Dario Faggioli
>> CC: Ian Campbell
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 88009: tolerable all pass - PUSHED
flight 88009 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/88009/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen d3ac192acc9ca5d48d97e98bb59c2c8e98ba0891
baseline version:
xen 3a80f43cdc9062754f41ca0b9c12dbaa1e3572da
Last test of basis87926 2016-03-29 19:01:57 Z0 days
Testing same since88009 2016-03-30 15:02:13 Z0 days1 attempts
People who touched revisions under test:
Juergen Gross
Konrad Rzeszutek Wilk
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=d3ac192acc9ca5d48d97e98bb59c2c8e98ba0891
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
d3ac192acc9ca5d48d97e98bb59c2c8e98ba0891
+ branch=xen-unstable-smoke
+ revision=d3ac192acc9ca5d48d97e98bb59c2c8e98ba0891
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' xd3ac192acc9ca5d48d97e98bb59c2c8e98ba0891 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ e
Re: [Xen-devel] [PATCH] arm64: xen_boot: Fix xen boot using Grub on AARCH64
Hi Julien, I have posted the v3 , please check http://lists.xen.org/archives/html/xen-devel/2016-03/msg03564.html And I hope GRUB patch can be merged :-) On 30 March 2016 at 23:52, Julien Grall wrote: > Hello, > > Ping? > > Regards, > > > On 19/02/16 16:28, Julien Grall wrote: >> >> Xen is currently crashing because of malformed compatible property for >> the boot module. This is because the property string is not >> null-terminated as requested by the ePAR spec. >> --- >> grub-core/loader/arm64/xen_boot.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/grub-core/loader/arm64/xen_boot.c >> b/grub-core/loader/arm64/xen_boot.c >> index a914eb8..8ae43d7 100644 >> --- a/grub-core/loader/arm64/xen_boot.c >> +++ b/grub-core/loader/arm64/xen_boot.c >> @@ -156,7 +156,7 @@ prepare_xen_module_params (struct xen_boot_binary >> *module, void *xen_boot_fdt) >> grub_fdt_add_subnode (xen_boot_fdt, chosen_node, module_name); >> >> retval = grub_fdt_set_prop (xen_boot_fdt, module_node, "compatible", >> - MODULE_CUSTOM_COMPATIBLE, >> sizeof(MODULE_CUSTOM_COMPATIBLE) - 1); >> + MODULE_CUSTOM_COMPATIBLE, >> sizeof(MODULE_CUSTOM_COMPATIBLE)); >> if (retval) >> return grub_error (GRUB_ERR_IO, "failed to update FDT"); >> >> > > -- > Julien Grall -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add new pvusb backend "qusb" provided by qemu
On 30/03/16 18:16, Wei Liu wrote:
> On Wed, Mar 30, 2016 at 04:34:20PM +0200, Juergen Gross wrote:
>> On 30/03/16 16:19, Wei Liu wrote:
>>> On Wed, Mar 30, 2016 at 02:05:56PM +0200, Juergen Gross wrote:
Add a new pvusb backend type "qusb" which is provided by qemu. It can
be selected either by specifying the type directly in the configuration
or it is selected automatically by libxl in case there is no "usbback"
driver loaded.
Signed-off-by: Juergen Gross
---
V4: bail out in case of usbback_is_loaded() error as requested by
Chun Yan Liu
---
>>> [...]
/* Add usbctrl information to xenstore.
*
- * Adding a usb controller will add a new 'vusb' device in xenstore, and
- * add corresponding frontend, backend information to it. According to
- * "update_json", decide wether to update json config file.
+ * Adding a usb controller will add a new 'qusb' or 'vusb' device in
xenstore,
+ * and add corresponding frontend, backend information to it. According to
+ * "update_json", decide whether to update json config file.
*/
static int libxl__device_usbctrl_add_xenstore(libxl__gc *gc, uint32_t
domid,
libxl_device_usbctrl
*usbctrl,
@@ -121,6 +144,15 @@ static int
libxl__device_usbctrl_add_xenstore(libxl__gc *gc, uint32_t domid,
DEVICE_ADD(usbctrl, usbctrls, domid, &usbctrl_saved,
COMPARE_USBCTRL, &d_config);
+
+if (usbctrl->type == LIBXL_USBCTRL_TYPE_QUSB) {
+if (!libxl__query_qemu_backend(gc, domid,
usbctrl->backend_domid,
+ "qusb", false)) {
>>>
>>> This needs to be sorted out.
>>
>> What do you mean?
>>
>>> And this is maybe a rather dumb question: the xenstore paths for qusb
>>> and kernel backend are the same? What is the likelihood that one
>>> deviates from the other? Note that this is not suggesting that you
>>> over-engineer current code, it's just something that needs clarifying.
>>
>> There is an existing pvusb kernel backend implementation in kernel-xen
>> of openSUSE and SLE. The port of that implementation hasn't been
>> accepted in Linux upstream as it was regarded to fit better in qemu.
>>
>> So the qemu base backend is designed in a way to be compatible to the
>> already existing kernel backend. Future enhancements will be made on the
>> qemu based backend only (as far as SUSE is involved).
>>
>> So the frontend related Xenstore paths are the same, while the backend
>> paths are different ("vusb" vs. "qusb"). And yes, I've tested the same
>> domU with both backends.
>>
>
> I forgot to ask -- When you repost, can you add such information to
> commit message? Thanks.
Sure.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 for Xen 4.7 3/4] libxl: enable per-VCPU parameter for RTDS
On Fri, 2016-03-18 at 16:26 -0500, Chong Li wrote: > Add libxl_vcpu_sched_params_get/set and sched_rtds_vcpu_get/set > functions to support per-VCPU settings. > > Signed-off-by: Chong Li > Signed-off-by: Meng Xu > Signed-off-by: Sisu Xi > > --- > Changes on PATCH v7: > 1) Fix a mistake in sched_rtds_domain_set() > You happen to have done more than "just" this. In fact, I made some comments unrelated to this issue, and you addressed them (which is a good thing :-)). It is ok for this to be a very very very quick summary, but it's only useful if it is also complete. In any case, this patch is: Reviewed-by: Dario Faggioli 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 http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 20/21] xen/arm: Add a hypercall for device mmio mapping
Hi,
On 30/03/16 17:11, Konrad Rzeszutek Wilk wrote:
On Wed, Mar 30, 2016 at 06:08:13PM +0800, Shannon Zhao wrote:
From: Shannon Zhao
It needs to map platform or amba device mmio to Dom0 on ARM. But when
booting with ACPI, it can't get the mmio region in Xen due to lack of
AML interpreter to parse DSDT table. Therefore, let Dom0 call a
hypercall to map mmio region when it adds the devices.
Here we add a new map space like the XEN_DOMCTL_memory_mapping to map
mmio region for Dom0. Also add a helper to combine the
xsm_add_to_physmap and XENMAPSPACE_dev_mmio space check together.
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Tim Deegan
Signed-off-by: Shannon Zhao
---
v8: add a helper to combine xsm_add_to_physmap and XENMAPSPACE_dev_mmio
space check together
I was by accident reviewing the earlier ersion. So let me give comments
here as well.
.. snipp.
Jan already applied the patch series to xengit/staging. Shannon, can you
send a follow-up patch to fix at least the printk?
+int map_dev_mmio_region(struct domain *d,
+unsigned long start_gfn,
+unsigned long nr,
+unsigned long mfn)
+{
+int res;
+
+if ( !(nr && iomem_access_permitted(d, start_gfn, start_gfn + nr - 1)) )
+return 0;
+
+res = map_mmio_regions(d, start_gfn, nr, mfn);
+if ( res < 0 )
+{
+printk(XENLOG_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
Should this be printk ratelimited?
I think so. Today the domain can only be the hardware domain but it may
change in the future.
+ start_gfn, start_gfn + nr - 1, d->domain_id);
+return res;
+}
+
+return 0;
+}
+
int guest_physmap_add_entry(struct domain *d,
unsigned long gpfn,
unsigned long mfn,
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb
On Wed, Mar 30, 2016 at 10:24:41AM -0600, Jan Beulich wrote: > >>> On 24.03.16 at 21:00, wrote: > > @@ -266,16 +275,15 @@ void *vzalloc(size_t size) > > return p; > > } > > > > -void vfree(void *va) > > +void vfree_cb(void *va, unsigned int pages, vfree_cb_t *vfree_cb_fnc) > > Just to repeat: This "caller provides size" worries me, the more that > this doesn't mirror anything the allocation side does. Would you mind > providing a case where using vm_size() instead is not correct? When the virtual addresses (to which we will stitch the pages allocated by vmalloc) are not allocated (provided?) by vmap. vm_size() will be very unhappy if that virtual address it is provided with are not from the 'vmap' pool and will return 0. > > > --- a/xen/include/xen/vmap.h > > +++ b/xen/include/xen/vmap.h > > @@ -12,9 +12,23 @@ void *__vmap(const mfn_t *mfn, unsigned int granularity, > > void *vmap(const mfn_t *mfn, unsigned int nr); > > void vunmap(const void *); > > void *vmalloc(size_t size); > > + > > +/* > > + * Callback for vmalloc_cb to use when vmap-ing. > > + */ > > Comment style. > > > +typedef void *(vmap_cb_t)(const mfn_t *mfn, unsigned int pages); > > Stray parentheses (again). I swore I fixed it and then did a pass through the rest to fix others! But a grep tells me: +typedef void *(vmap_cb_t)(const mfn_t *mfn, unsigned int pages); +typedef void (vfree_cb_t)(void *va, unsigned int pages); +typedef int (find_space_t)(size_t, unsigned long *, unsigned long *); +typedef void (*xsplice_loadcall_t)(void); +typedef void (*xsplice_unloadcall_t)(void); I need to fix those. Sorry about that - I really though I had them fixed. > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] different number of cpus
On Tue, 2016-03-29 at 22:14 +, tutu sky wrote:
> menuentry 'Ubuntu GNU/Linux, with Xen hypervisor' --class ubuntu --
> class gnu-linux --class gnu --class os --class xen
> $menuentry_id_option 'xen-gnulinux-simple-d9e946b3-a4cf-4a90-8cdf-
> 689d19a2b869' {
> insmod part_msdos
> insmod ext2
> set root='hd0,msdos1'
> if [ x$feature_platform_search_hint = xy ]; then
> search --no-floppy --fs-uuid --set=root --hint-
> bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-
> baremetal=ahci0,msdos1 d9e946b3-a4cf-4a90-8cdf-689d19a2b869
> else
> search --no-floppy --fs-uuid --set=root d9e946b3-a4cf-4a90-
> 8cdf-689d19a2b869
> fi
> echo'Loading Xen 4 ...'
> if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then
> xen_rm_opts=
> else
> xen_rm_opts="no-real-mode edd=off"
> fi
> multiboot/boot/xen-4.gz placeholder loglvl=all
> guest_loglvl=all com1=115200,8n1,0x3e8,5
> console=com1,vga ${xen_rm_opts}
>
This line here is the one.
It needs to contain dom0_max_vcpus=2.
> On Sat, Mar 12, 2016 at 10:18:15AM +, tutu sky wrote:
> >
> > Hi all,
> > i have installed Xen and while setting number of vcpus in Dom0 to
> > 2, then go to terminal and issue "top" command, it shows me 4 core!
> > these all happen while i have 2 cores available in
> > /sys/devices/system/cpu (just cpu0 and cpu1), so what does it mean?
> > I become totally confused, as i don't know what is the exact number
> > of cores which are assigned to Xen or Dom0.
> > in other words, when using "xl vcpu-set Domain-0 2" command, whys
> > this two vcpus are showed 4 in "top" command?
> >
> How does your xen.gz command line argument in bootloader look like?
>
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
http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.16 test] 87897: regressions - FAIL
flight 87897 linux-3.16 real [real] http://logs.test-lab.xenproject.org/osstest/logs/87897/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 7 host-ping-check-xen fail REGR. vs. 85048 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 85048 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 85048 build-i386-rumpuserxen6 xen-buildfail like 85048 test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail like 85048 build-amd64-rumpuserxen 6 xen-buildfail like 85048 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 85048 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 85048 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 85048 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10 fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10 fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-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-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-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-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-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass version targeted for testing: linux3a96c6601b6fc47baa6d296f9111ba7be4dad6fc baseline version: linux7f2a8840d127c8d5c59a5d79235e1205aba2e102 Last test of basis85048 2016-03-02 10:56:10 Z 28 days Testing same since87897 2016-03-29 14:28:05 Z1 days1 attempts People who touched revisions under test: Akshay Bhat Al Viro Alex Deucher Alex Williamson Alexander Deucher Amir Vadai Andreas Schwab Andrey Skvortsov Andy Lutomirski Andy Shevchenko Anton Protopopov Arnd Bergmann Avery Pennarun Ben Hutchings Benjamin Coddington Benjamin LaHaise Benjamin Poirier Bjørn Mork Chris Bainbridge Christian Borntraeger Christian König Christoffer Dall Christoph Hellwig Cong Wang CQ Tang Dan Carpenter Daniel Borkmann Daniele Palmas Dave Airlie David S. Miller David Vrabel Davi
Re: [Xen-devel] [PATCH v2 1/6] public/xen.h: add flags field to vcpu_time_info
On 03/30/2016 04:49 PM, Ian Jackson wrote:
> Joao Martins writes ("[PATCH v2 1/6] public/xen.h: add flags field to
> vcpu_time_info"):
>> This field has two possible flags (as of latest pvclock ABI
>> shared with KVM).
>>
>> flags: bits in this field indicate extended capabilities
>> coordinated between the guest and the hypervisor. Specifically
>> on KVM, availability of specific flags has to be checked in
>> 0x4001 cpuid leaf. On Xen, we don't have that but we can
>> still check some of the flags after registering the time info
>> page since a force_update_vcpu_system_time is performed.
>
> Earlier in the thread there was a Reviewed-by from Andrew Cooper.
> Shouldn't that have been preserved here ?
I dropped both of the Reviewed-by because I updated the patch with changes that
weren't noted in earlier reviews - I had in mind that is the protocol.
> Also, Andrew made some points about the linux.git MAINTAINERS file.
Yes, the MAINTAINERS file will be updated with the linux v2 series and the point
is to have xen-devel be notified whenever changes are made to the pvclock ABI
(that is shared with KVM).
Joao
> Ideally I would like to commit this patch ASAP.
>
> Thanks,
> Ian.
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxc: Document xc_domain_resume
On Wed, 2016-03-30 at 11:10 -0400, Konrad Rzeszutek Wilk wrote: > > --- a/tools/libxc/include/xenctrl.h > +++ b/tools/libxc/include/xenctrl.h > @@ -565,6 +565,58 @@ int xc_domain_destroy(xc_interface *xch, > > + * HVM guest are the simplest - they suspend via S3 and resume from > + * S3. Upon resume they have to re-negotiate with the emulated > devices. > + * > + * PV and PVHVM communicate via via hypercalls for suspend (and ^repeated "via" > resume). > + * For suspend the toolstack initiaties the process by writting an > value in > + * XenBus "control/shutdown" with the string "suspend". > + * > + * The PV guest stashes anything it deems neccessary in 'struct > start_info' > + * in case of failure (PVHVM may ignore this) and calls the > + * SCHEDOP_shutdown::SHUTDOWN_suspend hypercall (for PV as argument > it > + * passes the MFN to 'struct start_info'). > + * > + * And then the guest is suspended. > + * > + * At this point the guest may be resumed on the same host under the > same > + * domain (checkpointing or suspending failed), or on a different > host. > I think there's also the case of "same host, different domain", as it happens in local migrations, but maybe it's not that important to mention it here. > + * If the resume was not checkpointing (or if suspend was succesful) > we would > + * setup the PV timers and the different PV events. Lastly the PV > drivers > + * re-negotiate with the backend. ^backends ? 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 http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] tools: detect appropriate debug optimization level
Ian Jackson writes ("Re: [PATCH 2/2] tools: detect appropriate debug
optimization level"):
> My initial reaction is that I any actual problems are bugs either in
> the compiler or in Xen, which should be fixed.
>
> There should be nothing wrong with lack of inlining or dead code
> elimination. If you can give an example of structure padding going
> wrong, please do.
Having said that, the reason for specifying -O0 is the use case that
gcc now provides -Og for. So I see no harm and some benefit in using
-Og if it is supported.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb
>>> On 24.03.16 at 21:00, wrote: > @@ -266,16 +275,15 @@ void *vzalloc(size_t size) > return p; > } > > -void vfree(void *va) > +void vfree_cb(void *va, unsigned int pages, vfree_cb_t *vfree_cb_fnc) Just to repeat: This "caller provides size" worries me, the more that this doesn't mirror anything the allocation side does. Would you mind providing a case where using vm_size() instead is not correct? > --- a/xen/include/xen/vmap.h > +++ b/xen/include/xen/vmap.h > @@ -12,9 +12,23 @@ void *__vmap(const mfn_t *mfn, unsigned int granularity, > void *vmap(const mfn_t *mfn, unsigned int nr); > void vunmap(const void *); > void *vmalloc(size_t size); > + > +/* > + * Callback for vmalloc_cb to use when vmap-ing. > + */ Comment style. > +typedef void *(vmap_cb_t)(const mfn_t *mfn, unsigned int pages); Stray parentheses (again). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] tools: detect appropriate debug optimization level
On 3/30/16 11:00 AM, Ian Jackson wrote:
> Doug Goldstein writes ("Re: [PATCH 2/2] tools: detect appropriate debug
> optimization level"):
>> On 3/8/16 9:38 AM, Wei Liu wrote:
>>> On Mon, Mar 07, 2016 at 08:23:40PM -0600, Doug Goldstein wrote:
The build should not use -O0 as that results in miscompilations. There
>>>
>>> This needs some (concrete) references. Is that a known issue in gcc? If
>>> so can you reference the bug number?
>>
>> So its not really a bug in GCC but just the complete lack of
>> optimizations in play. inlines aren't inlined. dead code elimination
>> isn't run so things are much bigger. structures aren't padded the same way.
>
> My initial reaction is that I any actual problems are bugs either in
> the compiler or in Xen, which should be fixed.
>
> There should be nothing wrong with lack of inlining or dead code
> elimination. If you can give an example of structure padding going
> wrong, please do.
>
> Ian.
>
Ok fine, I'm just confused why we're insisting on using -O0 over -Og?
From the gcc manual:
-Og
Optimize debugging experience. -Og enables optimizations that do not
interfere with debugging. It should be the optimization level of choice
for the standard edit-compile-debug cycle, offering a reasonable level
of optimization while maintaining fast compilation and a good debugging
experience.
--
Doug Goldstein
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] oxenstored: allow compilation prior to OCaml 3.12.0
On Wed, Mar 30, 2016 at 04:06:39PM +, Jonathan Davies wrote:
> Commit 363ae55c8 used an OCaml feature called record field punning. This broke
> the build on compilers prior to OCaml 3.12.0.
>
> This patch makes no semantic change but now uses backwards-compatible syntax.
>
> Signed-off-by: Jonathan Davies
> Reported-by: Boris Ostrovsky
> Tested-by: Boris Ostrovsky
Applied.
>
> ---
> Changed since v1:
> * names listed in the preamble
> ---
> tools/ocaml/xenstored/process.ml |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/ocaml/xenstored/process.ml
> b/tools/ocaml/xenstored/process.ml
> index fb5fdaf..7b60376 100644
> --- a/tools/ocaml/xenstored/process.ml
> +++ b/tools/ocaml/xenstored/process.ml
> @@ -484,7 +484,7 @@ let do_input store cons doms con =
> if newpacket then (
> let packet = Connection.pop_in con in
> let tid, rid, ty, data = Xenbus.Xb.Packet.unpack packet in
> - let req = {Packet.tid; Packet.rid; Packet.ty; Packet.data} in
> + let req = {Packet.tid=tid; Packet.rid=rid; Packet.ty=ty;
> Packet.data=data} in
>
> (* As we don't log IO, do not call an unnecessary sanitize_data
> info "[%s] -> [%d] %s \"%s\""
> --
> 1.7.10.4
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/5] libxl: add new pvusb backend "qusb" provided by qemu
On Wed, Mar 30, 2016 at 04:34:20PM +0200, Juergen Gross wrote:
> On 30/03/16 16:19, Wei Liu wrote:
> > On Wed, Mar 30, 2016 at 02:05:56PM +0200, Juergen Gross wrote:
> >> Add a new pvusb backend type "qusb" which is provided by qemu. It can
> >> be selected either by specifying the type directly in the configuration
> >> or it is selected automatically by libxl in case there is no "usbback"
> >> driver loaded.
> >>
> >> Signed-off-by: Juergen Gross
> >> ---
> >> V4: bail out in case of usbback_is_loaded() error as requested by
> >> Chun Yan Liu
> >> ---
> > [...]
> >> /* Add usbctrl information to xenstore.
> >> *
> >> - * Adding a usb controller will add a new 'vusb' device in xenstore, and
> >> - * add corresponding frontend, backend information to it. According to
> >> - * "update_json", decide wether to update json config file.
> >> + * Adding a usb controller will add a new 'qusb' or 'vusb' device in
> >> xenstore,
> >> + * and add corresponding frontend, backend information to it. According to
> >> + * "update_json", decide whether to update json config file.
> >> */
> >> static int libxl__device_usbctrl_add_xenstore(libxl__gc *gc, uint32_t
> >> domid,
> >>libxl_device_usbctrl
> >> *usbctrl,
> >> @@ -121,6 +144,15 @@ static int
> >> libxl__device_usbctrl_add_xenstore(libxl__gc *gc, uint32_t domid,
> >>
> >> DEVICE_ADD(usbctrl, usbctrls, domid, &usbctrl_saved,
> >> COMPARE_USBCTRL, &d_config);
> >> +
> >> +if (usbctrl->type == LIBXL_USBCTRL_TYPE_QUSB) {
> >> +if (!libxl__query_qemu_backend(gc, domid,
> >> usbctrl->backend_domid,
> >> + "qusb", false)) {
> >
> > This needs to be sorted out.
>
> What do you mean?
>
> > And this is maybe a rather dumb question: the xenstore paths for qusb
> > and kernel backend are the same? What is the likelihood that one
> > deviates from the other? Note that this is not suggesting that you
> > over-engineer current code, it's just something that needs clarifying.
>
> There is an existing pvusb kernel backend implementation in kernel-xen
> of openSUSE and SLE. The port of that implementation hasn't been
> accepted in Linux upstream as it was regarded to fit better in qemu.
>
> So the qemu base backend is designed in a way to be compatible to the
> already existing kernel backend. Future enhancements will be made on the
> qemu based backend only (as far as SUSE is involved).
>
> So the frontend related Xenstore paths are the same, while the backend
> paths are different ("vusb" vs. "qusb"). And yes, I've tested the same
> domU with both backends.
>
I forgot to ask -- When you repost, can you add such information to
commit message? Thanks.
>
> Juergen
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4] x86/hvm/viridian: zero and check vcpu context __pad field
Commit 57844631 "save APIC assist vector" added an extra field to the
viridian vcpu context save record. This field was only a uint8_t and
so an extra __pad field was also added to pad up to the next 64-bit
boundary.
This patch makes sure that __pad field is zeroed on save and checked
for zero on restore. This prevents a potential leak of information
from the stack and a compatibility check against future use of the
space occupied by the __pad field.
The __pad field is zeroed as a side effect of making use of a C99 struct
initializer for the other fields. This patch also modifies the domain
context save code to use the same mechanism.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
v4:
- use c99 struct initializer
- re-work zero_page extern
v3:
- make zero_page accessible outside mm.c
v2:
- drop is_zero() helper an use memcmp against zero_page instead.
- add memset to viridian_save_domain_ctxt() to reduce potential
for information leakage in future.
---
xen/arch/x86/hvm/viridian.c | 23 +--
xen/arch/x86/mm.c | 2 +-
xen/include/asm-x86/mm.h| 2 ++
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 5c76c1a..8253fd0 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -780,16 +780,16 @@ out:
static int viridian_save_domain_ctxt(struct domain *d, hvm_domain_context_t *h)
{
-struct hvm_viridian_domain_context ctxt;
+struct hvm_viridian_domain_context ctxt = {
+.time_ref_count = d->arch.hvm_domain.viridian.time_ref_count.val,
+.hypercall_gpa = d->arch.hvm_domain.viridian.hypercall_gpa.raw,
+.guest_os_id= d->arch.hvm_domain.viridian.guest_os_id.raw,
+.reference_tsc = d->arch.hvm_domain.viridian.reference_tsc.raw,
+};
if ( !is_viridian_domain(d) )
return 0;
-ctxt.time_ref_count = d->arch.hvm_domain.viridian.time_ref_count.val;
-ctxt.hypercall_gpa = d->arch.hvm_domain.viridian.hypercall_gpa.raw;
-ctxt.guest_os_id= d->arch.hvm_domain.viridian.guest_os_id.raw;
-ctxt.reference_tsc = d->arch.hvm_domain.viridian.reference_tsc.raw;
-
return (hvm_save_entry(VIRIDIAN_DOMAIN, 0, h, &ctxt) != 0);
}
@@ -822,10 +822,10 @@ static int viridian_save_vcpu_ctxt(struct domain *d,
hvm_domain_context_t *h)
return 0;
for_each_vcpu( d, v ) {
-struct hvm_viridian_vcpu_context ctxt;
-
-ctxt.apic_assist_msr = v->arch.hvm_vcpu.viridian.apic_assist.msr.raw;
-ctxt.apic_assist_vector = v->arch.hvm_vcpu.viridian.apic_assist.vector;
+struct hvm_viridian_vcpu_context ctxt = {
+.apic_assist_msr = v->arch.hvm_vcpu.viridian.apic_assist.msr.raw,
+.apic_assist_vector = v->arch.hvm_vcpu.viridian.apic_assist.vector,
+};
if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, &ctxt) != 0 )
return 1;
@@ -851,6 +851,9 @@ static int viridian_load_vcpu_ctxt(struct domain *d,
hvm_domain_context_t *h)
if ( hvm_load_entry_zeroextend(VIRIDIAN_VCPU, h, &ctxt) != 0 )
return -EINVAL;
+if ( memcmp(&ctxt._pad, zero_page, sizeof(ctxt._pad)) )
+return -EINVAL;
+
v->arch.hvm_vcpu.viridian.apic_assist.msr.raw = ctxt.apic_assist_msr;
if ( v->arch.hvm_vcpu.viridian.apic_assist.msr.fields.enabled )
initialize_apic_assist(v);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c997b53..bca7532 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -589,7 +589,7 @@ static inline void guest_get_eff_kern_l1e(struct vcpu *v,
unsigned long addr,
TOGGLE_MODE();
}
-static const char __section(".bss.page_aligned.const") zero_page[PAGE_SIZE];
+const char __section(".bss.page_aligned.const") zero_page[PAGE_SIZE];
static void invalidate_shadow_ldt(struct vcpu *v, int flush)
{
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index b25942b..b781495 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -595,4 +595,6 @@ typedef struct mm_rwlock {
&(d)->xenpage_list : &(d)->page_list,\
&(d)->arch.relmem_list)
+extern const char zero_page[];
+
#endif /* __ASM_X86_MM_H__ */
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxc: Document xc_domain_resume
On Wed, Mar 30, 2016 at 05:01:34PM +0100, Wei Liu wrote: > On Wed, Mar 30, 2016 at 11:10:23AM -0400, Konrad Rzeszutek Wilk wrote: > > Document the save and suspend mechanism. > > > > Signed-off-by: Konrad Rzeszutek Wilk > > --- > > v2: Wei update on wording. > > I think you haven't addressed Andrew's comments. Maybe you missed it. I I must have missed it! > will take over this patch and address them if you don't mind. Go for it! > > Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 20/21] xen/arm: Add a hypercall for device mmio mapping
On Wed, Mar 30, 2016 at 06:08:13PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao
>
> It needs to map platform or amba device mmio to Dom0 on ARM. But when
> booting with ACPI, it can't get the mmio region in Xen due to lack of
> AML interpreter to parse DSDT table. Therefore, let Dom0 call a
> hypercall to map mmio region when it adds the devices.
>
> Here we add a new map space like the XEN_DOMCTL_memory_mapping to map
> mmio region for Dom0. Also add a helper to combine the
> xsm_add_to_physmap and XENMAPSPACE_dev_mmio space check together.
>
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Keir Fraser
> Cc: Tim Deegan
> Signed-off-by: Shannon Zhao
> ---
> v8: add a helper to combine xsm_add_to_physmap and XENMAPSPACE_dev_mmio
> space check together
I was by accident reviewing the earlier ersion. So let me give comments
here as well.
.. snipp.
> +int map_dev_mmio_region(struct domain *d,
> +unsigned long start_gfn,
> +unsigned long nr,
> +unsigned long mfn)
> +{
> +int res;
> +
> +if ( !(nr && iomem_access_permitted(d, start_gfn, start_gfn + nr - 1)) )
> +return 0;
> +
> +res = map_mmio_regions(d, start_gfn, nr, mfn);
> +if ( res < 0 )
> +{
> +printk(XENLOG_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
Should this be printk ratelimited?
> + start_gfn, start_gfn + nr - 1, d->domain_id);
> +return res;
> +}
> +
> +return 0;
> +}
> +
> int guest_physmap_add_entry(struct domain *d,
> unsigned long gpfn,
> unsigned long mfn,
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index c7fca96..644f81a 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -834,6 +834,19 @@ static int get_reserved_device_memory(xen_pfn_t start,
> xen_ulong_t nr,
> }
> #endif
>
> +static long xatp_permission_check(struct domain *d, unsigned int space)
> +{
> +/*
> + * XENMAPSPACE_dev_mmio mapping is only supported for hardware Domain
s/Domain/domain/
> + * to map this kind of space to itself.
> + */
> +if ( (space == XENMAPSPACE_dev_mmio) &&
> + (!is_hardware_domain(current->domain) || (d != current->domain)) )
> +return -EACCES;
Why not -EPERM?
> +
> +return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> +}
> +
> long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> struct domain *d;
> @@ -980,7 +993,7 @@ long do_memory_op(unsigned long cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> if ( d == NULL )
> return -ESRCH;
>
> -rc = xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> +rc = xatp_permission_check(d, xatp.space);
Ah, which nicely takes care of rcu_unlock_domain.
> if ( rc )
> {
> rcu_unlock_domain(d);
> @@ -1024,7 +1037,7 @@ long do_memory_op(unsigned long cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> if ( d == NULL )
> return -ESRCH;
>
> -rc = xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> +rc = xatp_permission_check(d, xatpb.space);
> if ( rc )
> {
> rcu_unlock_domain(d);
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index 55626b4..d240d1e 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -154,6 +154,11 @@ int unmap_regions_rw_cache(struct domain *d,
> unsigned long nr_mfns,
> unsigned long mfn);
>
> +int map_dev_mmio_region(struct domain *d,
> +unsigned long start_gfn,
> +unsigned long nr,
> +unsigned long mfn);
> +
> int guest_physmap_add_entry(struct domain *d,
> unsigned long gfn,
> unsigned long mfn,
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index f69e92f..fe52ee1 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -220,6 +220,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
> #define XENMAPSPACE_gmfn_range 3 /* GMFN range, XENMEM_add_to_physmap
> only. */
> #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
> * XENMEM_add_to_physmap_batch only. */
> +#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
s/device/Device/ And maybe an full stop at the end?
> /* ` } */
>
> /*
> --
> 2.0.4
>
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 2/5] libxl: add query function for backend support by device model
On Wed, Mar 30, 2016 at 03:26:23PM +0100, Wei Liu wrote: > On Wed, Mar 30, 2016 at 04:11:39PM +0200, Juergen Gross wrote: > > On 30/03/16 16:09, Wei Liu wrote: > > > On Wed, Mar 30, 2016 at 04:02:20PM +0200, Juergen Gross wrote: > > >> On 30/03/16 15:53, Wei Liu wrote: > > >>> On Wed, Mar 30, 2016 at 02:05:55PM +0200, Juergen Gross wrote: > > Add a function to query whether the device model is supporting a > > specific backend type. The device model is writing the supported > > backend types to Xenstore on startup. The new query function checks > > for the appropriate entry to be present. > > > > As not all versions of qemu are capable to indicate support of > > specific backends the query function is to be called with an indicator > > whether the default return value should be "supported" (in case qemu > > doesn't know set any support information) or "not supported". > > > > Signed-off-by: Juergen Gross > > >>> > > >>> The code itself looks straightforward enough. > > >>> > > >>> But note that this is a new protocol that needs to be supported > > >>> essentially forever. I've CC QEMU maintainers for their input. > > >> > > >> Okay, I'll send the qemu patch now. > > >> > > > > > > And also a patch to docs/misc/xenstore-paths.markdown please. > > > > Aah, sure. > > > > Actually wait, I think all QEMU nodes are either under documented or I > looked at the wrong place. I don't think there is anything missing, in term of PV protocol, which go through xenstore. Is there a node in particular that you are thinking of? > Anthony, how should we document the protocol between QEMU and toolstack? > Did I look at the wrong place? I think xenstore-paths.markdown would be a good place to document this protocol. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 03/28] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables lookup.
>>> On 24.03.16 at 21:00, wrote:
> @@ -1077,27 +1080,33 @@ void do_unexpected_trap(const char *msg, struct
> cpu_user_regs *regs)
>
> int do_bug_frame(struct cpu_user_regs *regs, vaddr_t pc)
> {
> -const struct bug_frame *bug;
> +const struct bug_frame *bug = NULL;
> const char *prefix = "", *filename, *predicate;
> unsigned long fixup;
> -int id, lineno;
> -static const struct bug_frame *const stop_frames[] = {
> -__stop_bug_frames_0,
> -__stop_bug_frames_1,
> -__stop_bug_frames_2,
> -NULL
> -};
> +int id = -1, lineno;
> +struct virtual_region *region;
>
> -for ( bug = __start_bug_frames, id = 0; stop_frames[id]; ++bug )
> +region = search_for_text(pc);
find_text_region() maybe? And "virtual_region" then perhaps could
also become "text_region"?
> --- /dev/null
> +++ b/xen/common/virtual_region.c
> @@ -0,0 +1,160 @@
> +/*
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#ifdef CONFIG_X86
> +#include
> +#endif
I can't spot what code below needs this.
> +static struct virtual_region core = {
> +.list = LIST_HEAD_INIT(core.list),
> +.start = (unsigned long)_stext,
> +.end = (unsigned long)_etext,
> +#ifdef CONFIG_X86
> +.ex = (struct exception_table_entry *)__start___ex_table,
> +.ex_end = (struct exception_table_entry *)__stop___ex_table,
> +#endif
And I continue to be unhappy about these #ifdef-s, the more that
I think that ARM is more the exception than the norm in not needing
these tables. Couldn't the arch pass the two pointers to
setup_virtual_regions() instead?
> +struct virtual_region* search_for_text(unsigned long addr)
I think I had said before that this should return a pointer to const.
And the * also is still misplaced.
> +{
> +struct virtual_region *region;
> +
> +rcu_read_lock(&rcu_virtual_region_lock);
> +
> +list_for_each_entry_rcu( region, &virtual_region_list, list )
Inconsistent style: Either you need another blank ahead of the
opening paren, or you don't need any immediately inside.
> +int register_virtual_region(struct virtual_region *r)
> +{
> +ASSERT(!local_irq_is_enabled());
> +
> +list_add_tail_rcu(&r->list, &virtual_region_list);
> +
> +return 0;
> +}
Is it really useful for this function to return non-void?
> --- /dev/null
> +++ b/xen/include/xen/virtual_region.h
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> + *
> + */
> +
> +#ifndef __XEN_VIRTUAL_REGION_LIST__
> +#define __XEN_VIRTUAL_REGION_LIST__
Still inconsistent with the header's name.
> +struct virtual_region
> +{
> +struct list_head list;
> +unsigned long start;/* Virtual address start. */
> +unsigned long end; /* Virtual address start. */
> +
> +/*
> + * If this is NULL the default lookup mechanism is used.
> + */
Still wrongly a multi line comment.
> +symbols_lookup_t *symbols_lookup;
> +
> +struct {
> +const struct bug_frame *bugs; /* The pointer to array of bug frames.
> */
> +ssize_t n_bugs; /* The number of them. */
> +} frame[BUGFRAME_NR];
> +
> +struct exception_table_entry *ex;
> +struct exception_table_entry *ex_end;
So you nicely constified "bugs", but what about these two?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] oxenstored: allow compilation prior to OCaml 3.12.0
On Wed, Mar 30, 2016 at 03:47:34PM +, Jonathan Davies wrote:
> Commit 363ae55c8 used an OCaml feature called record field punning. This broke
> the build on compilers prior to OCaml 3.12.0.
>
> This patch makes no semantic change but now uses backwards-compatible syntax.
>
> Signed-off-by: Jonathan Davies
> Reviewed-by: Boris Ostrovsky
This should be
Tested-by: Boris Ostrovsky
Other than that I don't really have comment on this patch. :-)
> ---
> tools/ocaml/xenstored/process.ml |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/ocaml/xenstored/process.ml
> b/tools/ocaml/xenstored/process.ml
> index fb5fdaf..7b60376 100644
> --- a/tools/ocaml/xenstored/process.ml
> +++ b/tools/ocaml/xenstored/process.ml
> @@ -484,7 +484,7 @@ let do_input store cons doms con =
> if newpacket then (
> let packet = Connection.pop_in con in
> let tid, rid, ty, data = Xenbus.Xb.Packet.unpack packet in
> - let req = {Packet.tid; Packet.rid; Packet.ty; Packet.data} in
> + let req = {Packet.tid=tid; Packet.rid=rid; Packet.ty=ty;
> Packet.data=data} in
>
> (* As we don't log IO, do not call an unnecessary sanitize_data
> info "[%s] -> [%d] %s \"%s\""
> --
> 1.7.10.4
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] tools: detect appropriate debug optimization level
Doug Goldstein writes ("Re: [PATCH 2/2] tools: detect appropriate debug
optimization level"):
> On 3/8/16 9:38 AM, Wei Liu wrote:
> > On Mon, Mar 07, 2016 at 08:23:40PM -0600, Doug Goldstein wrote:
> >> The build should not use -O0 as that results in miscompilations. There
> >
> > This needs some (concrete) references. Is that a known issue in gcc? If
> > so can you reference the bug number?
>
> So its not really a bug in GCC but just the complete lack of
> optimizations in play. inlines aren't inlined. dead code elimination
> isn't run so things are much bigger. structures aren't padded the same way.
My initial reaction is that I any actual problems are bugs either in
the compiler or in Xen, which should be fixed.
There should be nothing wrong with lack of inlining or dead code
elimination. If you can give an example of structure padding going
wrong, please do.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 2/5] libxl: add query function for backend support by device model
On Wed, Mar 30, 2016 at 04:59:22PM +0100, Wei Liu wrote: > On Wed, Mar 30, 2016 at 04:55:42PM +0100, Anthony PERARD wrote: > > On Wed, Mar 30, 2016 at 03:26:23PM +0100, Wei Liu wrote: > > > On Wed, Mar 30, 2016 at 04:11:39PM +0200, Juergen Gross wrote: > > > > On 30/03/16 16:09, Wei Liu wrote: > > > > > And also a patch to docs/misc/xenstore-paths.markdown please. > > > > > > > > Aah, sure. > > > > > > > > > > Actually wait, I think all QEMU nodes are either under documented or I > > > looked at the wrong place. > > > > I don't think there is anything missing, in term of PV protocol, which go > > through xenstore. Is there a node in particular that you are thinking of? > > > > The node for video ram? That's what I was looking for. Then I realised > it was probably not documented but I wasn't very sure. Yes, this seams to be missing from the documentation. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 21/22] xen/arm: Add a hypercall for device mmio mapping
> +int map_dev_mmio_region(struct domain *d,
> +unsigned long start_gfn,
> +unsigned long nr,
> +unsigned long mfn)
> +{
> +int res;
> +
> +if ( !(nr && iomem_access_permitted(d, start_gfn, start_gfn + nr - 1)) )
> +return 0;
> +
> +res = map_mmio_regions(d, start_gfn, nr, mfn);
> +if ( res < 0 )
> +{
> +printk(XENLOG_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
Perhaps we also want to rate limit this?
> + start_gfn, start_gfn + nr - 1, d->domain_id);
> +return res;
> +}
> +
> +return 0;
> +}
> +
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] oxenstored: allow compilation prior to OCaml 3.12.0
Commit 363ae55c8 used an OCaml feature called record field punning. This broke
the build on compilers prior to OCaml 3.12.0.
This patch makes no semantic change but now uses backwards-compatible syntax.
Signed-off-by: Jonathan Davies
Reported-by: Boris Ostrovsky
Tested-by: Boris Ostrovsky
---
Changed since v1:
* names listed in the preamble
---
tools/ocaml/xenstored/process.ml |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/ocaml/xenstored/process.ml b/tools/ocaml/xenstored/process.ml
index fb5fdaf..7b60376 100644
--- a/tools/ocaml/xenstored/process.ml
+++ b/tools/ocaml/xenstored/process.ml
@@ -484,7 +484,7 @@ let do_input store cons doms con =
if newpacket then (
let packet = Connection.pop_in con in
let tid, rid, ty, data = Xenbus.Xb.Packet.unpack packet in
- let req = {Packet.tid; Packet.rid; Packet.ty; Packet.data} in
+ let req = {Packet.tid=tid; Packet.rid=rid; Packet.ty=ty;
Packet.data=data} in
(* As we don't log IO, do not call an unnecessary sanitize_data
info "[%s] -> [%d] %s \"%s\""
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] oxenstored: allow compilation prior to OCaml 3.12.0
On 30/03/2016 4:54 PM, Boris Ostrovsky wrote:
> On 03/30/2016 11:47 AM, Jonathan Davies wrote:
> > Commit 363ae55c8 used an OCaml feature called record field punning.
> > This broke the build on compilers prior to OCaml 3.12.0.
> >
> > This patch makes no semantic change but now uses backwards-compatible
> syntax.
> >
> > Signed-off-by: Jonathan Davies
> > Reviewed-by: Boris Ostrovsky
>
> This should be Tested-by (and maybe Reported-by). Reviewed-by implies
> that I understood what you did. I make no such claim ;-)
>
> -boris
My apologies!
Corrected version coming up.
Jonathan
> > ---
> > tools/ocaml/xenstored/process.ml |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/ocaml/xenstored/process.ml
> > b/tools/ocaml/xenstored/process.ml
> > index fb5fdaf..7b60376 100644
> > --- a/tools/ocaml/xenstored/process.ml
> > +++ b/tools/ocaml/xenstored/process.ml
> > @@ -484,7 +484,7 @@ let do_input store cons doms con =
> > if newpacket then (
> > let packet = Connection.pop_in con in
> > let tid, rid, ty, data = Xenbus.Xb.Packet.unpack packet in
> > - let req = {Packet.tid; Packet.rid; Packet.ty; Packet.data} in
> > + let req = {Packet.tid=tid; Packet.rid=rid; Packet.ty=ty;
> > +Packet.data=data} in
> >
> > (* As we don't log IO, do not call an unnecessary
> sanitize_data
> >info "[%s] -> [%d] %s \"%s\""
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 21/22] xen/arm: Add a hypercall for device mmio mapping
On Fri, Mar 25, 2016 at 09:48:54PM +0800, Shannon Zhao wrote:
> It needs to map platform or amba device mmio to Dom0 on ARM. But when
> booting with ACPI, it can't get the mmio region in Xen due to lack of
> AML interpreter to parse DSDT table. Therefore, let Dom0 call a
> hypercall to map mmio region when it adds the devices.
>
> Here we add a new map space like the XEN_DOMCTL_memory_mapping to map
> mmio region for Dom0.
>
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Keir Fraser
> Cc: Tim Deegan
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/mm.c | 3 +++
> xen/arch/arm/p2m.c | 22 ++
> xen/common/memory.c | 16
> xen/include/asm-arm/p2m.h | 5 +
> xen/include/public/memory.h | 1 +
> 5 files changed, 47 insertions(+)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 81f9e2e..0aae6c5 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1138,6 +1138,9 @@ int xenmem_add_to_physmap_one(
> rcu_unlock_domain(od);
> break;
> }
> +case XENMAPSPACE_dev_mmio:
> +rc = map_dev_mmio_region(d, gpfn, 1, idx);
> +return rc;
>
> default:
> return -ENOSYS;
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 7e5f5d1..0011708 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1270,6 +1271,27 @@ int unmap_mmio_regions(struct domain *d,
> d->arch.p2m.default_access);
> }
>
> +int map_dev_mmio_region(struct domain *d,
> +unsigned long start_gfn,
> +unsigned long nr,
> +unsigned long mfn)
> +{
> +int res;
> +
> +if ( !(nr && iomem_access_permitted(d, start_gfn, start_gfn + nr - 1)) )
> +return 0;
> +
> +res = map_mmio_regions(d, start_gfn, nr, mfn);
> +if ( res < 0 )
> +{
> +printk(XENLOG_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
> + start_gfn, start_gfn + nr - 1, d->domain_id);
> +return res;
> +}
> +
> +return 0;
> +}
> +
> int guest_physmap_add_entry(struct domain *d,
> unsigned long gpfn,
> unsigned long mfn,
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index c7fca96..25ff86c 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -980,6 +980,14 @@ long do_memory_op(unsigned long cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> if ( d == NULL )
> return -ESRCH;
>
> +/*
> + * XENMAPSPACE_dev_mmio mapping is only supported for hardware Domain
Any reason to make Domain be uppercase?
> + * to map this kind of space to itself.
> + */
> +if ( (xatp.space == XENMAPSPACE_dev_mmio) &&
> + ((d != current->domain) || !is_hardware_domain(d)) )
> +return -EACCES;
Shouldnt' this be -EPERM?
Also you probably want to do 'rcu_unlock_domain(d)' before you return?
> +
> rc = xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> if ( rc )
> {
> @@ -1024,6 +1032,14 @@ long do_memory_op(unsigned long cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> if ( d == NULL )
> return -ESRCH;
>
> +/*
> + * XENMAPSPACE_dev_mmio mapping is only supported for hardware Domain
Any reason to make Domain be uppercase?
> + * to map this kind of space to itself.
> + */
> +if ( (xatpb.space == XENMAPSPACE_dev_mmio) &&
> + ((d != current->domain) || !is_hardware_domain(d)) )
> +return -EACCES;
> +
> rc = xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> if ( rc )
> {
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index 55626b4..d240d1e 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -154,6 +154,11 @@ int unmap_regions_rw_cache(struct domain *d,
> unsigned long nr_mfns,
> unsigned long mfn);
>
> +int map_dev_mmio_region(struct domain *d,
> +unsigned long start_gfn,
> +unsigned long nr,
> +unsigned long mfn);
> +
> int guest_physmap_add_entry(struct domain *d,
> unsigned long gfn,
> unsigned long mfn,
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index f69e92f..fe52ee1 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -220,6 +220,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
> #define XENMAPSPACE_gmfn_range 3 /* GMFN range, XENMEM_add_to_physmap
> only. */
> #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
> * XENMEM_add_to_ph
Re: [Xen-devel] [PATCH] libxc: Document xc_domain_resume
On Wed, Mar 30, 2016 at 11:10:23AM -0400, Konrad Rzeszutek Wilk wrote: > Document the save and suspend mechanism. > > Signed-off-by: Konrad Rzeszutek Wilk > --- > v2: Wei update on wording. I think you haven't addressed Andrew's comments. Maybe you missed it. I will take over this patch and address them if you don't mind. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/6] public/xen.h: add flags field to vcpu_time_info
Joao Martins writes ("[PATCH v2 1/6] public/xen.h: add flags field to
vcpu_time_info"):
> This field has two possible flags (as of latest pvclock ABI
> shared with KVM).
>
> flags: bits in this field indicate extended capabilities
> coordinated between the guest and the hypervisor. Specifically
> on KVM, availability of specific flags has to be checked in
> 0x4001 cpuid leaf. On Xen, we don't have that but we can
> still check some of the flags after registering the time info
> page since a force_update_vcpu_system_time is performed.
Earlier in the thread there was a Reviewed-by from Andrew Cooper.
Shouldn't that have been preserved here ?
Also, Andrew made some points about the linux.git MAINTAINERS file.
Ideally I would like to commit this patch ASAP.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 2/5] libxl: add query function for backend support by device model
On Wed, Mar 30, 2016 at 04:55:42PM +0100, Anthony PERARD wrote: > On Wed, Mar 30, 2016 at 03:26:23PM +0100, Wei Liu wrote: > > On Wed, Mar 30, 2016 at 04:11:39PM +0200, Juergen Gross wrote: > > > On 30/03/16 16:09, Wei Liu wrote: > > > > On Wed, Mar 30, 2016 at 04:02:20PM +0200, Juergen Gross wrote: > > > >> On 30/03/16 15:53, Wei Liu wrote: > > > >>> On Wed, Mar 30, 2016 at 02:05:55PM +0200, Juergen Gross wrote: > > > Add a function to query whether the device model is supporting a > > > specific backend type. The device model is writing the supported > > > backend types to Xenstore on startup. The new query function checks > > > for the appropriate entry to be present. > > > > > > As not all versions of qemu are capable to indicate support of > > > specific backends the query function is to be called with an > > > indicator > > > whether the default return value should be "supported" (in case qemu > > > doesn't know set any support information) or "not supported". > > > > > > Signed-off-by: Juergen Gross > > > >>> > > > >>> The code itself looks straightforward enough. > > > >>> > > > >>> But note that this is a new protocol that needs to be supported > > > >>> essentially forever. I've CC QEMU maintainers for their input. > > > >> > > > >> Okay, I'll send the qemu patch now. > > > >> > > > > > > > > And also a patch to docs/misc/xenstore-paths.markdown please. > > > > > > Aah, sure. > > > > > > > Actually wait, I think all QEMU nodes are either under documented or I > > looked at the wrong place. > > I don't think there is anything missing, in term of PV protocol, which go > through xenstore. Is there a node in particular that you are thinking of? > The node for video ram? That's what I was looking for. Then I realised it was probably not documented but I wasn't very sure. > > Anthony, how should we document the protocol between QEMU and toolstack? > > Did I look at the wrong place? > > I think xenstore-paths.markdown would be a good place to document this > protocol. > > -- > Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/7] oxenstored: refactor request processing
On Tue, Mar 29, 2016 at 08:41:54PM +0100, David Scott wrote:
>
> > On 29 Mar 2016, at 17:38, Wei Liu wrote:
> >
> > On Tue, Mar 29, 2016 at 10:08:30AM +0100, Jonathan Davies wrote:
> >> On Thu, Mar 24, 2016 at 07:57:30PM -0400, Boris Ostrovsky wrote:
> >>> On 03/24/2016 06:49 PM, Andrew Cooper wrote:
> On 24/03/2016 22:22, Boris Ostrovsky wrote:
> > On 03/17/2016 01:51 PM, Jonathan Davies wrote:
> >> Encapsulate the request in a record that is passed from do_input to
> >> process_packet and input_handle_error.
> >>
> >> This will be helpful when keeping track of the requests made as part
> >> of a
> >> transaction.
> >>
> >> Signed-off-by: Jonathan Davies
> >> Reviewed-by: Andrew Cooper
> >> Reviewed-by: Jon Ludlam
> >> Reviewed-by: Euan Harris
> >> ---
> >> tools/ocaml/xenstored/process.ml | 15 ++-
> >> 1 file changed, 10 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/tools/ocaml/xenstored/process.ml
> >> b/tools/ocaml/xenstored/process.ml
> >> index 7a73669..c92bec7 100644
> >> --- a/tools/ocaml/xenstored/process.ml
> >> +++ b/tools/ocaml/xenstored/process.ml
> >> @@ -344,11 +344,11 @@ let function_of_type ty =
> >> | Xenbus.Xb.Op.Invalid -> reply_ack do_error
> >> | _ -> reply_ack do_error
> >> -let input_handle_error ~cons ~doms ~fct ~ty ~con ~t ~rid ~data =
> >> +let input_handle_error ~cons ~doms ~fct ~con ~t ~req =
> >> let reply_error e =
> >> Packet.Error e in
> >> try
> >> -fct con t doms cons data
> >> +fct con t doms cons req.Packet.data
> >> with
> >> | Define.Invalid_path -> reply_error "EINVAL"
> >> | Define.Already_exist -> reply_error "EEXIST"
> >> @@ -370,7 +370,10 @@ let input_handle_error ~cons ~doms ~fct ~ty ~con
> >> ~t ~rid ~data =
> >> (**
> >> * Nothrow guarantee.
> >> *)
> >> -let process_packet ~store ~cons ~doms ~con ~tid ~rid ~ty ~data =
> >> +let process_packet ~store ~cons ~doms ~con ~req =
> >> +let ty = req.Packet.ty in
> >> +let tid = req.Packet.tid in
> >> +let rid = req.Packet.rid in
> >> try
> >> let fct = function_of_type ty in
> >> let t =
> >> @@ -379,7 +382,7 @@ let process_packet ~store ~cons ~doms ~con ~tid
> >> ~rid ~ty ~data =
> >> else
> >> Connection.get_transaction con tid
> >> in
> >> -let response = input_handle_error ~cons ~doms ~fct ~ty ~con
> >> ~t ~rid ~data in
> >> +let response = input_handle_error ~cons ~doms ~fct ~con ~t
> >> ~req in
> >>(* Put the response on the wire *)
> >> send_response ty con t rid response
> >> @@ -412,11 +415,13 @@ let do_input store cons doms con =
> >> if newpacket then (
> >> let packet = Connection.pop_in con in
> >> let tid, rid, ty, data = Xenbus.Xb.Packet.unpack packet in
> >> +let req = {Packet.tid; Packet.rid; Packet.ty; Packet.data} in
> >> +
> > I think this change breaks the build with older ocaml versions:
> >
> > root@haswell> ocamlopt -v
> > The OCaml native-code compiler, version 4.00.1
> > Standard library directory: /usr/lib64/ocaml
> > root@haswell> ocamlopt -g -ccopt "" -dtypes -I
> > /root/tmp/xen/tools/ocaml/xenstored/../libs/xb -I
> > /root/tmp/xen/tools/ocaml/xenstored/../libs/mmap -I
> > /root/tmp/xen/tools/ocaml/xenstored/../libs/xc -I
> > /root/tmp/xen/tools/ocaml/xenstored/../libs/eventchn -cc gcc -w F
> > -warn-error F -c -o process.cmx process.ml
> > root@haswell>
> >
> >
> > root@ovs104> ocamlopt -v
> > The Objective Caml native-code compiler, version 3.11.2
> > Standard library directory: /usr/lib64/ocaml
> > root@ovs104> ocamlopt -g -ccopt "" -dtypes -I
> > /root/tmp/xen/tools/ocaml/xenstored/../libs/xb -I
> > /root/tmp/xen/tools/ocaml/xenstored/../libs/mmap -I
> > /root/tmp/xen/tools/ocaml/xenstored/../libs/xc -I
> > /root/tmp/xen/tools/ocaml/xenstored/../libs/eventchn -cc gcc -w F
> > -warn-error F -c -o process.cmx process.ml
> > File "process.ml", line 487, characters 23-24:
> > Error: Syntax error
> > root@ovs104>
> >
> > I don't know much about ocaml (OK, I know *nothing* about ocaml) so I
> > can't say what exactly might be wrong.
> Could you perhaps try this instead?
>
> let req = {tid = Packet.tid; rid = Packet.rid; ty = Packet.ty; data =
> Packet.data} in
>
> It is most likely that the older version of Ocaml can't infer the order
> of fields.
>
> ~Andrew
> >>>
> >>>
> >>> No, it now gives me "Error: Unbound record field label tid"
> >>>
> >>> -boris
> >>
>
Re: [Xen-devel] [PATCH] arm64: xen_boot: Fix xen boot using Grub on AARCH64
Hello, Ping? Regards, On 19/02/16 16:28, Julien Grall wrote: Xen is currently crashing because of malformed compatible property for the boot module. This is because the property string is not null-terminated as requested by the ePAR spec. --- grub-core/loader/arm64/xen_boot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/grub-core/loader/arm64/xen_boot.c b/grub-core/loader/arm64/xen_boot.c index a914eb8..8ae43d7 100644 --- a/grub-core/loader/arm64/xen_boot.c +++ b/grub-core/loader/arm64/xen_boot.c @@ -156,7 +156,7 @@ prepare_xen_module_params (struct xen_boot_binary *module, void *xen_boot_fdt) grub_fdt_add_subnode (xen_boot_fdt, chosen_node, module_name); retval = grub_fdt_set_prop (xen_boot_fdt, module_node, "compatible", - MODULE_CUSTOM_COMPATIBLE, sizeof(MODULE_CUSTOM_COMPATIBLE) - 1); + MODULE_CUSTOM_COMPATIBLE, sizeof(MODULE_CUSTOM_COMPATIBLE)); if (retval) return grub_error (GRUB_ERR_IO, "failed to update FDT"); -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] oxenstored: allow compilation prior to OCaml 3.12.0
On 03/30/2016 11:47 AM, Jonathan Davies wrote:
Commit 363ae55c8 used an OCaml feature called record field punning. This broke
the build on compilers prior to OCaml 3.12.0.
This patch makes no semantic change but now uses backwards-compatible syntax.
Signed-off-by: Jonathan Davies
Reviewed-by: Boris Ostrovsky
This should be Tested-by (and maybe Reported-by). Reviewed-by implies
that I understood what you did. I make no such claim ;-)
-boris
---
tools/ocaml/xenstored/process.ml |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/ocaml/xenstored/process.ml b/tools/ocaml/xenstored/process.ml
index fb5fdaf..7b60376 100644
--- a/tools/ocaml/xenstored/process.ml
+++ b/tools/ocaml/xenstored/process.ml
@@ -484,7 +484,7 @@ let do_input store cons doms con =
if newpacket then (
let packet = Connection.pop_in con in
let tid, rid, ty, data = Xenbus.Xb.Packet.unpack packet in
- let req = {Packet.tid; Packet.rid; Packet.ty; Packet.data} in
+ let req = {Packet.tid=tid; Packet.rid=rid; Packet.ty=ty;
Packet.data=data} in
(* As we don't log IO, do not call an unnecessary sanitize_data
info "[%s] -> [%d] %s \"%s\""
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/7] oxenstored: refactor request processing
On Wed, Mar 30, 2016 at 04:46:58PM +0100, Jonathan Davies wrote:
[...]
> > >> Andrew's guess was close, but the wrong way around -- please could you
> > >> try the
> > >> following with the older compiler?
> > >>
> > >> let req = {Packet.tid=tid; Packet.rid=rid; Packet.ty=ty;
> > >> Packet.data=data} in
> > >>
> > >> I was using a syntactic feature of OCaml called 'field punning' which is
> > >> generally considered good practice and makes for more readable code. It
> > >> looks
> > >> like this feature was introduced in OCaml 3.12.0 (dating from 2010),
> > >> which is
> > >> consistent with Boris' findings.
> > >>
> > >> What's the policy here -- is there a defined version of the OCaml
> > >> compiler which
> > >> tools/ocaml needs to be able to compile with?
> > >
> > > It is not explicitly listed in README or INSTALL. The ocaml tools
> > > maintainer (Dave in this case) is welcome to provide the minimum version
> > > required.
> > >
> > > Meanwhile, I don't think we should break existing build without pinning
> > > down the minimum required version first, so we should fix Boris's
> > > breakage. The fix seems simple enough anyway.
> >
> > It looks like the fix is small and easy — I think this is good for now.
> >
> > Let’s postpone requiring a later OCaml version until we really need a
> > feature only present in a later version. I suspect this will happen
> > eventually, probably when we try to add a dependency (e.g. from the Mirage
> > world) which requires 4.02+.
>
> OK; sounds sensible.
>
> Since the original patch has already been committed to staging, I presume
> you'd
> like me to formally submit a standalone patch that fixes this issue. I will
> post
> it separately.
>
Yes, a standalone patch to fix the issue is fine.
Wei.
> If I'm wrong and you'd like me to post a v2 of the whole series, let me know.
>
> Thanks,
> Jonathan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] oxenstored: allow compilation prior to OCaml 3.12.0
Commit 363ae55c8 used an OCaml feature called record field punning. This broke
the build on compilers prior to OCaml 3.12.0.
This patch makes no semantic change but now uses backwards-compatible syntax.
Signed-off-by: Jonathan Davies
Reviewed-by: Boris Ostrovsky
---
tools/ocaml/xenstored/process.ml |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/ocaml/xenstored/process.ml b/tools/ocaml/xenstored/process.ml
index fb5fdaf..7b60376 100644
--- a/tools/ocaml/xenstored/process.ml
+++ b/tools/ocaml/xenstored/process.ml
@@ -484,7 +484,7 @@ let do_input store cons doms con =
if newpacket then (
let packet = Connection.pop_in con in
let tid, rid, ty, data = Xenbus.Xb.Packet.unpack packet in
- let req = {Packet.tid; Packet.rid; Packet.ty; Packet.data} in
+ let req = {Packet.tid=tid; Packet.rid=rid; Packet.ty=ty;
Packet.data=data} in
(* As we don't log IO, do not call an unnecessary sanitize_data
info "[%s] -> [%d] %s \"%s\""
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
>>> On 24.03.16 at 22:30, wrote:
> From: Konrad Rzeszutek Wilk
> Date: Tue, 22 Mar 2016 16:53:19 -0400
> Subject: [PATCH] HYPERCALL_version_op. New hypercall mirroring XENVER_ but
> sane.
>
> This hypercall mirrors the XENVER_ in that it has similar functionality.
> However it is designed differently:
> - No compat layer. The data structures are the same size on 32
>as on 64-bit.
> - The hypercall accepts three arguments - the command, pointer to
>an buffer, and the length of the buffer.
> - Each sub-ops can be "probed" for size by returning the size of
>buffer that will be needed - if the buffer is NULL.
> - Subops can complete even if the buffer is too small - truncated
>data will be filled and hypercall will return -ENOBUFS.
> - VERSION_commandline, VERSION_changeset are privileged.
> - There is no XENVER_compile_info equivalent.
> - The hypercall can return -EPERM and toolstack/OSes are expected
>to deal with. However there are three subops: XEN_VERSION_version,
>XEN_VERSION_platform_parameters and XEN_VERSION_get_features
>that will always return an value as guests cannot survive without them.
>
> While we combine some of the common code between XENVER_ and VERSION_
> take the liberty of moving pae_extended_cr3 in x86 area.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Konrad Rzeszutek Wilk
> Acked-by: Daniel De Graaf [XSM bits]
> Reviewed-by: Andrew Cooper
This last line doesn't seem to match up with ...
> v1-v3: Was not part of the series.
> v4: New posting.
> v5: Remove memset and use {}. Tweak copy_to_guest and capabilities_info,
> add ASSERT(sz) per Andrew's review. Add cached=1 back in.
> Per Jan, s/VERSION_OP/VERSION/, squash size check with do_version_op,
> update the comments. Dropped Andrew's Review-by. Ate newlines.
... the middle sentence here.
> +DO(version_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg,
> + unsigned int len)
> +{
> +union {
> +xen_version_op_val_t val;
> +xen_feature_info_t fi;
> +} u = {};
> +unsigned int sz = 0;
> +const void *ptr = NULL;
> +int rc = xsm_version_op(XSM_OTHER, cmd);
> +
> +/* We can safely return -EPERM! */
So what again was this comment supposed to tell us?
> +if ( rc )
> +return rc;
> +
> +/*
> + * The HYPERVISOR_xen_version differs in that some return the value,
I think there's a "subop" missing somewhere.
> +static int __init capabilities_cache_init(void)
> +{
> +/*
> + * Pre-allocate the cache so we do not have to worry about
"Pre-fill" or "Pre-populate"?
> --- a/xen/include/public/version.h
> +++ b/xen/include/public/version.h
> @@ -30,7 +30,14 @@
>
> #include "xen.h"
>
> -/* NB. All ops return zero on success, except XENVER_{version,pagesize} */
Perhaps this comment doesn't belong here anymore, but I don't think
it should be deleted altogether.
> +/*
> + * There are two hypercalls mentioned in here. The XENVER_ are for
> + * HYPERCALL_xen_version (17), while VERSION_ are for the
XEN_VERSION_
> @@ -87,6 +94,67 @@ typedef struct xen_feature_info xen_feature_info_t;
> #define XENVER_commandline 9
> typedef char xen_commandline_t[1024];
>
> +/*
> + * The HYPERCALL_version_op has a set of sub-ops which mirror the
> + * sub-ops of HYPERCALL_xen_version. However this hypercall differs
> + * radically from the former:
> + * - It returns the amount of bytes returned.
"returns ... returned" is a little strange. Perhaps "returns ... copied"?
> + * - It will return -XEN_EPERM if the guest is not permitted
> + *(Albeit XEN_VERSION_version, XEN_VERSION_platform_parameters, and
> + *XEN_VERSION_get_features will always return an value as guest cannot
> + *survive without this information).
Isn't there an object missing here, to say what is not permitted?
> + * - It will return the requested data in arg.
> + * - It requires an third argument (len) for the length of the
> + *arg. Naturally the arg has to fit the requested data otherwise
> + *-XEN_ENOBUFS is returned.
> + *
> + * It also offers an mechanism to probe for the amount of bytes an
... a mechanism ...
> + * sub-op will require. Having the arg have an NULL handle will
... a NULL ...
> + * return the number of bytes requested for the operation. Or an
> + * negative value if an error is encountered.
... a negative ...
Since they're all cosmetic, if you take care of all of them, feel free
to stick my ack on the result.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 2/2] build: convert crash_debug to Kconfig
On 3/29/16 3:50 AM, Jan Beulich wrote: On 25.03.16 at 22:02, wrote: >> On 3/25/16 2:49 PM, Konrad Rzeszutek Wilk wrote: >>> On Thu, Mar 24, 2016 at 11:48:19AM -0500, Doug Goldstein wrote: --- a/xen/Kconfig.debug +++ b/xen/Kconfig.debug @@ -4,3 +4,14 @@ menuconfig DEBUG ---help--- If you want to debug Xen say Y and select any additional debugging support options. + +if DEBUG >>> >>> Perhaps if !defined then atuomatically enable it? Looking at Config.mk >>> it seems you could do crash_debug without debug=y? >> >> debug=y unfortunately is more than just a "meta" option that selects >> verbose=y and frame_pointer=y. It also turns off NDEBUG so that debug >> messages appear. I'm not sure how that should be mapped in the context >> of this patch. Should the messages be enabled when DEBUG is enabled or >> should there be another option? > > Let's not make this too fine grained, at least for now. I.e. enabling > DEBUG should mean exactly what "debug=y" so far meant. > > Jan > That's what I was stating this patch does. The question revolved around the fact that you can do crash_debug=y debug=n right now and if that made sense. Should crash_debug=y imply debug=y as well. So things are more fine grained and I was proposing we make it less so if the fine grained choices didn't make sense. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] XEN 4.6.0 on arm64 Ubuntu Xenial 16.04: unable to start domU
Adding some ARM folks. Please, do not use HTML when posting to this mailing list. Regards, Dario On Mon, 2016-03-28 at 00:48 -0500, Jiandi An wrote: > Hi guys, > > I built xen 4.6.0 from source on an arm64 system with Ubuntu 16.04 as > rootfs. After booting to xen 4.6.0 dom0 with 4.2 kernel, when trying > to start domU with xl create, seems no error but domU does not go in > running state. In fact state is blank, not in any other state > either. Does anyone know if there is anything I’m missing in > creating domU using xl create looking at the following steps and > logs? Thanks. > > Here are the details. > > After compiling xen and tools on the system and make install, running > xl gives the following error. > > root@bandera:~# xl info > xc: error: Could not obtain handle on privileged command interface (2 > = No such file or directory): Internal error > libxl: error: libxl.c:116:libxl_ctx_alloc: cannot open libxc handle: > No such file or directory > cannot init xl context > > This is because /proc/xen is not mounted upon booting dom0. Had add > the following line in /etc/fstab > > none /proc/xen xenfs defaults 0 0 > > xencommons init script is not ran upon booting dom0 > Manually start xencommons gives an error. This is because in > xencommons script when starting QEMU as disk backend for dom0, the > QEMU it defaults to is qemu-system-i386 which does exist. And the > system is an arm64 system. But xencommons script went through > mounting /proc/xen, starting xenstored and xenconsoled, and setting > domain 0 name. So even xencommons script gives an error, xl tool is > working. > > root@bandera:~# /etc/init.d/xencommons start > Starting /usr/local/sbin/xenstored > Setting domain 0 name, domid and JSON config... > Done setting up Dom0 > Starting xenconsoled... > Starting QEMU as disk backend for dom0 > /etc/init.d/xencommons: line 102: /usr/local/lib/xen/bin/qemu-system- > i386: No such file or directory > > root@bandera:~# xl list > Name ID Mem VCPUs > State Time(s) > Domain-0 0 1024 1 r-- > --- 32.2 > root@bandera:~# > > Use xl to create dom1 with debug verbose option, it’ll create dom1, > but it’s not in running state. It’s not in any of the states. > > root@bandera:~# xl -vvv create /etc/xen/dom1.cfg > Parsing config from /etc/xen/dom1.cfg > libxl: debug: libxl_create.c:1557:do_domain_create: ao 0x1f67c9b0: > create: how=(nil) callback=(nil) poller=0x1f67ced0 > libxl: debug: libxl_arm.c:59:libxl__arch_domain_prepare_config: > Configure the domain > libxl: debug: libxl_arm.c:62:libxl__arch_domain_prepare_config: - > Allocate 0 SPIs > libxl: verbose: > libxl_create.c:101:libxl__domain_build_info_setdefault: qemu-xen is > unavailable, use qemu-xen-traditional instead: No such file or > directory > libxl: debug: libxl_create.c:945:initiate_domain_create: running > bootloader > libxl: debug: libxl_bootloader.c:330:libxl__bootloader_run: no > bootloader configured, using user supplied kernel > libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch > w=0x1f67d8a0: deregister unregistered > domainbuilder: detail: xc_dom_allocate: cmdline="earlycon=xenboot > root=/dev/ram console=hvc0", features="(null)" > libxl: debug: libxl_dom.c:624:libxl__build_pv: pv kernel mapped 0 > path /var/lib/xen/Image42.dom0 > domainbuilder: detail: xc_dom_kernel_file: > filename="/var/lib/xen/Image42.dom0" > domainbuilder: detail: xc_dom_malloc_filemap : 15478 kB > domainbuilder: detail: xc_dom_ramdisk_file: > filename="/var/lib/xen/buildroot64.cpio.gz" > domainbuilder: detail: xc_dom_malloc_filemap : 2632 kB > domainbuilder: detail: xc_dom_boot_xen_init: ver 4.6, caps xen-3.0- > aarch64 xen-3.0-armv7l > domainbuilder: detail: xc_dom_rambase_init: RAM starts at 4 > domainbuilder: detail: xc_dom_parse_image: called > domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary > loader ... > domainbuilder: detail: loader probe failed > domainbuilder: detail: xc_dom_find_loader: trying Linux zImage > (ARM64) loader ... > domainbuilder: detail: loader probe OK > domainbuilder: detail: xc_dom_parse_zimage64_kernel: called > domainbuilder: detail: xc_dom_parse_zimage64_kernel: xen-3.0-aarch64: > 0x4008 -> 0x40f9da00 > libxl: debug: libxl_arm.c:776:libxl__arch_domain_init_hw_description: > constructing DTB for Xen version 4.6 guest > libxl: debug: > libxl_arm.c:777:libxl__arch_domain_init_hw_description: - vGIC > version: V3 > libxl: debug: libxl_arm.c:273:make_chosen_node: /chosen/bootargs = > earlycon=xenboot root=/dev/ram console=hvc0 > libxl: debug: libxl_arm.c:280:make_chosen_node: /chosen adding > placeholder linux,initrd properties > libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder > node /memory@4000 > libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder > node /memory@2 > libxl: debug: libxl_arm.c:871:libxl__ar
[Xen-devel] [TESTDAY] Test report of ARM CubieTruck with Xen 4.7 (staging)
*Hardware: ARM CubieTruck A20 (2GB). *Software: Linaro 14.04 with - Xen 4.7 (829e03c acpi: drop CONFIG_ACPI_BOOT and use CONFIG_ACPI instead + xsplice.v5) - Linux v4.5 (with revert of 88f8b1bb41c6208f81b6a480244533ded7b59493 " stmmac: Fix 'eth0: No PHY found' regression") - Linux v4.4 - Linux v4.3 - Linux v4.2 *Guest operating systems: Ubuntu 14.04 *Functionality tested: ARM Manual Smoke Test *Comments: I get these: (XEN) Freed 260kB init memory. (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0 (XEN) d0v1: vGICD: unhandled word write 0x to ICACTIVER0 (XEN) d1v0: vGICD: unhandled word write 0x to ICACTIVER0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 1/2] build: add debug menu to Kconfig
On Fri, 2016-03-25 at 15:59 -0500, Doug Goldstein wrote: > On 3/25/16 2:42 PM, Konrad Rzeszutek Wilk wrote: > > > > > This is more of an RFC than a merge request. If this seems > > > reasonable I'll > > > add all the other debugging options under this menu as well. > > > Obviously if > > > this seems reasonable and the patch is fine we can merge it and > > > I'll submit > > > the others as a follow up. > > There would be more I presume - the lock profile, gcov, crash, > > etc.. > Yes. I just wanted to do one to get an idea of how people felt about > the > menu. > Cpupools have some kind of very verbose debugging that could fit in here, and scheduling too. So, FWIW, I indeed like this menu, and am up for plumbing the two components above under it. :-) 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 http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm/viridian: zero and check vcpu context __pad field
>>> On 30.03.16 at 17:16, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 30 March 2016 15:22
>> To: Paul Durrant
>> Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
>> Subject: RE: [PATCH] x86/hvm/viridian: zero and check vcpu context __pad
>> field
>>
>> >>> On 30.03.16 at 15:19, wrote:
>> >> -Original Message-
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 30 March 2016 14:17
>> >> To: Paul Durrant
>> >> Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
>> >> Subject: RE: [PATCH] x86/hvm/viridian: zero and check vcpu context
>> __pad
>> >> field
>> >>
>> >> >>> On 30.03.16 at 13:26, wrote:
>> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> >> Sent: 30 March 2016 12:23
>> >> >> >>> On 30.03.16 at 12:32, wrote:
>> >> >> > --- a/xen/arch/x86/hvm/viridian.c
>> >> >> > +++ b/xen/arch/x86/hvm/viridian.c
>> >> >> > @@ -824,6 +824,8 @@ static int viridian_save_vcpu_ctxt(struct
>> domain
>> >> *d,
>> >> >> hvm_domain_context_t *h)
>> >> >> > for_each_vcpu( d, v ) {
>> >> >> > struct hvm_viridian_vcpu_context ctxt;
>> >> >> >
>> >> >> > +memset(&ctxt, 0, sizeof(ctxt));
>> >> >>
>> >> >> How about just adding an empty initializer to the declaration?
>> >> >>
>> >> >
>> >> > I think having a 'zero the entire struct' call at the start is better
>> >> > as
> it
>> >> > will cover any additions made to the struct in future. It's what I had
>> >> > mistakenly assumed was already there. In fact I think adding a similar
> call
>> >> > into the domain context save function would probably be worthwhile.
>> >>
>> >> And how does the initializer approach not fulfill that intention?
>> >>
>> >
>> > Because any time anyone adds another field they have to remember to
>> add
>> > another initializer, which is what I forgot to do. This approach OTOH is
>> > failsafe.
>>
>> But note how I said "an empty initializer": When there is an
>> initializer at all, all fields not mentioned in the initializer will get
>> default initialized (i.e. zeroed). Hence an empty initializer
>> clears the entire structure.
>>
>
> Ah, you mean C99 initializer style. That would be neater.
Not really - "static struct s s = {};" was allowed in C89 too iirc.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] x86/hvm/viridian: zero and check vcpu context __pad field
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 30 March 2016 15:23
> To: Paul Durrant
> Cc: Andrew Cooper; Keir (Xen.org); xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v3] x86/hvm/viridian: zero and check vcpu
> context __pad field
>
> >>> On 30.03.16 at 15:18, wrote:
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 30 March 2016 14:15
> >> To: Paul Durrant
> >> Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
> >> Subject: Re: [PATCH v3] x86/hvm/viridian: zero and check vcpu context
> >> __pad field
> >>
> >> >>> On 30.03.16 at 13:34, wrote:
> >> > --- a/xen/arch/x86/mm.c
> >> > +++ b/xen/arch/x86/mm.c
> >> > @@ -589,7 +589,8 @@ static inline void guest_get_eff_kern_l1e(struct
> >> vcpu *v, unsigned long addr,
> >> > TOGGLE_MODE();
> >> > }
> >> >
> >> > -static const char __section(".bss.page_aligned.const")
> >> zero_page[PAGE_SIZE];
> >> > +static const char __section(".bss.page_aligned.const")
> >> __zero_page[PAGE_SIZE];
> >> > +const char *zero_page = __zero_page;
> >>
> >> Mind explaining why simply dropping the "static" doesn't do what we
> >> want?
> >>
> >
> > That's what I did first. I got:
> >
> > mm.c:592:56: error: conflicting types for âzero_pageâ
> > static const char __section(".bss.page_aligned.const")
> > zero_page[PAGE_SIZE];
> > ^
> > In file included from
> /local/scratch/pauldu/xen/xen/include/xen/mm.h:195:0,
> > from mm.c:90:
> > /local/scratch/pauldu/xen/xen/include/asm/mm.h:598:20: note: previous
> > declaration of âzero_pageâ was here
> > extern const char *zero_page;
> > ^
> > /local/scratch/pauldu/xen/xen/Rules.mk:166: recipe for target 'mm.o'
> failed
>
> Obviously this can't work: You meant
>
> extern const char zero_page[];
>
Yes, I guess I did.
Paul
> Jan
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm/viridian: zero and check vcpu context __pad field
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 30 March 2016 15:22
> To: Paul Durrant
> Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
> Subject: RE: [PATCH] x86/hvm/viridian: zero and check vcpu context __pad
> field
>
> >>> On 30.03.16 at 15:19, wrote:
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 30 March 2016 14:17
> >> To: Paul Durrant
> >> Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
> >> Subject: RE: [PATCH] x86/hvm/viridian: zero and check vcpu context
> __pad
> >> field
> >>
> >> >>> On 30.03.16 at 13:26, wrote:
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> Sent: 30 March 2016 12:23
> >> >> >>> On 30.03.16 at 12:32, wrote:
> >> >> > --- a/xen/arch/x86/hvm/viridian.c
> >> >> > +++ b/xen/arch/x86/hvm/viridian.c
> >> >> > @@ -824,6 +824,8 @@ static int viridian_save_vcpu_ctxt(struct
> domain
> >> *d,
> >> >> hvm_domain_context_t *h)
> >> >> > for_each_vcpu( d, v ) {
> >> >> > struct hvm_viridian_vcpu_context ctxt;
> >> >> >
> >> >> > +memset(&ctxt, 0, sizeof(ctxt));
> >> >>
> >> >> How about just adding an empty initializer to the declaration?
> >> >>
> >> >
> >> > I think having a 'zero the entire struct' call at the start is better as
> >> > it
> >> > will cover any additions made to the struct in future. It's what I had
> >> > mistakenly assumed was already there. In fact I think adding a similar
> >> > call
> >> > into the domain context save function would probably be worthwhile.
> >>
> >> And how does the initializer approach not fulfill that intention?
> >>
> >
> > Because any time anyone adds another field they have to remember to
> add
> > another initializer, which is what I forgot to do. This approach OTOH is
> > failsafe.
>
> But note how I said "an empty initializer": When there is an
> initializer at all, all fields not mentioned in the initializer will get
> default initialized (i.e. zeroed). Hence an empty initializer
> clears the entire structure.
>
Ah, you mean C99 initializer style. That would be neater.
Paul
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 00/11] Return failure on failure for more xl commands
On Wed, Mar 30, 2016 at 05:02:39PM +0200, Paulina Szubarczyk wrote: > This patch includes the changes from a patch prepared by George Dunlap > [0] and expands them to more xl commands. > Hello, Did you perhaps make a mistake? As far as I can tell some patches were already applied. Don't worry, we all make mistakes from time to time. I realise you might be looking at master branch. Please check staging branch to see if you should drop some of the already patches. And perhaps can you indicate which patches should we look at in case you don't want to resend just yet. Wei. > This is my bite-sized outreachy project [1][2]. > > Return failure when the command failed for more xl commands: > - mem-set > - cd-insert > - pci-* > -- freemem > -- tmem-* > > This makes xl more useful for scripting. > > In the case of mem-set, it means first cleaning up > libxl_set_memory_target() to return useful error codes. > > For pci-* functions libxl__create_pci_backend(), > libxl__device_pci_destroy_all() > return error codes instead of always 0. > > Changes: > - Remove block-attach patch > - Split out removal of spurious getinfolist to a separate patch > - Try to follow CODING_STYLE more closely: > - In general, don't initialize rc / r, but use set-and-goto > - Use 'r' for non-libxl error codes > - Use EXIT_FAILURE and EXIT_SUCCESS rather than magic constants in main_foo() > - Use 1 and 0 in internal functions of xl > > [0] http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02246.html > [1] http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03031.html > [2] https://www.mail-archive.com/xen-devel@lists.xen.org/msg62055.html > > CC: Wei Liu > CC: Ian Jackson > CC: Dario Faggioli > CC: Ian Campbell > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [GRUB2 PATCH v6 1/4] i386/relocator: Add grub_relocator64_efi relocator
Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
On the other hand processor mode, just before jumping into loaded image, will
be set accordingly to Unified Extensible Firmware Interface Specification,
Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
loaded image will be able to use EFI boot services without any issues.
Signed-off-by: Daniel Kiper
Reviewed-by: Konrad Rzeszutek Wilk
---
v6 - suggestions/fixes:
- allocate memory for grub_relocator64_efi
relocator between 0 and 4 GiB
(suggested by Konrad Rzeszutek Wilk).
v4 - suggestions/fixes:
- move EFI platform specific C code to separate file
(suggested by Vladimir 'phcoder' Serbinenko),
- add some comments
(suggested by Vladimir 'phcoder' Serbinenko).
v3 - suggestions/fixes:
- reuse grub-core/lib/i386/relocator64.S code
instead of creating separate assembly file
(suggested by Vladimir 'phcoder' Serbinenko),
- grub_multiboot_boot() cleanup
(suggested by Vladimir 'phcoder' Serbinenko),
- reuse multiboot_header_tag_entry_address struct instead
of creating new one for EFI 64-bit entry point
(suggested by Vladimir 'phcoder' Serbinenko).
---
grub-core/Makefile.core.def |1 +
grub-core/lib/i386/relocator64.S | 11 +
grub-core/lib/x86_64/efi/relocator.c | 80 ++
grub-core/loader/multiboot.c | 51 +++---
grub-core/loader/multiboot_mbi2.c| 19 ++--
include/grub/i386/multiboot.h| 11 +
include/grub/i386/relocator.h| 21 +
include/multiboot2.h |1 +
8 files changed, 186 insertions(+), 9 deletions(-)
create mode 100644 grub-core/lib/x86_64/efi/relocator.c
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 58b4208..21ad0dd 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1531,6 +1531,7 @@ module = {
i386_xen = lib/i386/xen/relocator.S;
x86_64_xen = lib/x86_64/xen/relocator.S;
xen = lib/i386/relocator_common_c.c;
+ x86_64_efi = lib/x86_64/efi/relocator.c;
extra_dist = lib/i386/relocator_common.S;
extra_dist = kern/powerpc/cache_flush.S;
diff --git a/grub-core/lib/i386/relocator64.S b/grub-core/lib/i386/relocator64.S
index e4648d8..75725cf 100644
--- a/grub-core/lib/i386/relocator64.S
+++ b/grub-core/lib/i386/relocator64.S
@@ -73,6 +73,14 @@ VARIABLE(grub_relocator64_rsp)
movq%rax, %rsp
+ /*
+* Here is grub_relocator64_efi_start() entry point.
+* Following code is shared between grub_relocator64_efi_start()
+* and grub_relocator64_start().
+*
+* Think twice before changing anything below!!!
+*/
+VARIABLE(grub_relocator64_efi_start)
/* mov imm64, %rax */
.byte 0x48
.byte 0xb8
@@ -120,6 +128,9 @@ LOCAL(jump_addr):
VARIABLE(grub_relocator64_rip)
.quad 0
+ /* Here grub_relocator64_efi_start() ends. Ufff... */
+VARIABLE(grub_relocator64_efi_end)
+
#ifndef __x86_64__
.p2align4
LOCAL(gdt):
diff --git a/grub-core/lib/x86_64/efi/relocator.c
b/grub-core/lib/x86_64/efi/relocator.c
new file mode 100644
index 000..3caef7a
--- /dev/null
+++ b/grub-core/lib/x86_64/efi/relocator.c
@@ -0,0 +1,80 @@
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2009 Free Software Foundation, Inc.
+ * Copyright (C) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB 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 GRUB. If not, see
[Xen-devel] [PATCH] libxc: Document xc_domain_resume
Document the save and suspend mechanism. Signed-off-by: Konrad Rzeszutek Wilk --- v2: Wei update on wording. --- tools/libxc/include/xenctrl.h | 52 +++ 1 file changed, 52 insertions(+) diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index 150d727..096ff5c 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -565,6 +565,58 @@ int xc_domain_destroy(xc_interface *xch, * This function resumes a suspended domain. The domain should have * been previously suspended. * + * Note that there are 'xc_domain_suspend' as suspending a domain + * is quite the endeavour. As such this long comment will describe the + * suspend and resume path. + * + * For the purpose of this explanation there are three guests: + * PV (using hypercalls for privilgied operations), HVM + * (fully hardware virtualized guests using emulated devices for everything), + * and PVHVM (hardware virtualized guest with PV drivers). + * + * HVM guest are the simplest - they suspend via S3 and resume from + * S3. Upon resume they have to re-negotiate with the emulated devices. + * + * PV and PVHVM communicate via via hypercalls for suspend (and resume). + * For suspend the toolstack initiaties the process by writting an value in + * XenBus "control/shutdown" with the string "suspend". + * + * The PV guest stashes anything it deems neccessary in 'struct start_info' + * in case of failure (PVHVM may ignore this) and calls the + * SCHEDOP_shutdown::SHUTDOWN_suspend hypercall (for PV as argument it + * passes the MFN to 'struct start_info'). + * + * And then the guest is suspended. + * + * At this point the guest may be resumed on the same host under the same + * domain (checkpointing or suspending failed), or on a different host. + * + * The checkpointing or notifying an guest that the suspend failed is by + * having the SCHEDOP_shutdown::SHUTDOWN_suspend hypercall return a non-zero + * value. + * + * The PV and PVHVM resume path are similar. For PV it would be similar to bootup + * - figure out where the 'struct start_info' is (or if the suspend was + * cancelled aka checkpointed - reuse the saved values). + * + * From here on they differ depending whether the guest is PV or PVHVM + * in specifics but follow overall the same path: + * - PV: Bringing up the vCPUS, + * - PVHVM: Setup vector callback, + * - Bring up vCPU runstates, + * - Remap the grant tables if checkpointing or setup from scratch, + * + * + * If the resume was not checkpointing (or if suspend was succesful) we would + * setup the PV timers and the different PV events. Lastly the PV drivers + * re-negotiate with the backend. + * + * This function would return before the guest started resuming. That is + * the guest would be in non-running state and its vCPU context would be + * in the the SCHEDOP_shutdown::SHUTDOWN_suspend hypercall return path + * (for PV and PVHVM). For HVM it would be in would be in QEMU emulated + * BIOS handling S3 suspend. + * * @parm xch a handle to an open hypervisor interface * @parm domid the domain id to resume * @parm fast use cooperative resume (guest must support this) -- 2.5.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 02/11] libxl_pci: clean an unused return variable
libxl_device_pci_assignable_list returns: - list of the libxl_device_pci - NULL in case of error or lack of devices the rc variable is unused as return code. Signed-off-by: Paulina Szubarczyk CC: Wei Liu CC: Ian Jackson CC: Dario Faggioli CC: Ian Campbell --- tools/libxl/libxl_pci.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index 3435ce2..6051ee4 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -397,12 +397,11 @@ libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num) libxl_device_pci *pcidevs = NULL, *new, *assigned; struct dirent *de; DIR *dir; -int rc, num_assigned; +int num_assigned; *num = 0; -rc = get_all_assigned_devices(gc, &assigned, &num_assigned); -if ( rc ) +if ( get_all_assigned_devices(gc, &assigned, &num_assigned) ) goto out; dir = opendir(SYSFS_PCIBACK_DRIVER); -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [GRUB2 PATCH v6 4/4] multiboot2: Add support for relocatable images
Currently multiboot2 protocol loads image exactly at address specified in
ELF or multiboot2 header. This solution works quite well on legacy BIOS
platforms. It is possible because memory regions are placed at predictable
addresses (though I was not able to find any spec which says that it is
strong requirement, so, it looks that it is just a goodwill of hardware
designers). However, EFI platforms are more volatile. Even if required
memory regions live at specific addresses then they are sometimes simply
not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
OVMF). This means that you are not able to just set up final image
destination on build time. You have to provide method to relocate image
contents to real load address which is usually different than load address
specified in ELF and multiboot2 headers.
This patch provides all needed machinery to do self relocation in image code.
First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
align (required image alignment), preference (it says which memory regions are
preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable
header tag contained in binary (at this stage load addresses from multiboot2
and/or ELF headers are ignored). Later loader tries to fulfill request (not only
that one) and if it succeeds then it informs image about real load address via
multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. Starting
from now executable must cope with relocations itself using whole static and
dynamic knowledge provided by boot loader.
This patch does not provide functionality which could do relocations using
ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir
'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery
could be added to existing code (including this patch) without huge effort.
Additionally, ELF relocation could live in parallel with self relocation
provided
by this patch. However, during research I realized that first of all we should
establish the details how ELF relocatable image should look like and how it
should
be build. At least to build proper test/example files.
So, this patch just provides support for self relocatable images. If ELF file
with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
such files will be added later.
This patch was tested with Xen image which uses that functionality. However,
this Xen
feature is still under development and new patchset will be released in about
2-3 weeks.
Signed-off-by: Daniel Kiper
---
v6 - suggestions/fixes:
- fix error message in grub_multiboot_load_elf()
(suggested by Konrad Rzeszutek Wilk),
- improve debug messages.
v5 - suggestions/fixes:
- fix support for multi segment ELF files
(suggested by Vladimir 'phcoder' Serbinenko),
- add some input data checks,
- add some comments.
v4 - suggestions/fixes:
- pack grub_multiboot_load_elf() arguments into struct
(suggested by Juergen Gross, Konrad Rzeszutek Wilk
and Vladimir 'phcoder' Serbinenko),
- fix entry point address calculation
(suggested by Vladimir 'phcoder' Serbinenko),
- fail if ELF file has relocs sections
(suggested by Vladimir 'phcoder' Serbinenko).
v3 - suggestions/fixes:
- reduce number of casts
(suggested by Konrad Rzeszutek Wilk),
- remove unneeded space at the end of line
(suggested by Konrad Rzeszutek Wilk),
- improve commit message
(suggested by Konrad Rzeszutek Wilk).
---
grub-core/loader/i386/multiboot_mbi.c | 13 +++-
grub-core/loader/multiboot.c | 11 ++-
grub-core/loader/multiboot_elfxx.c| 129 +
grub-core/loader/multiboot_mbi2.c | 122 ++-
include/grub/multiboot.h | 22 +-
include/multiboot2.h | 24 ++
6 files changed, 243 insertions(+), 78 deletions(-)
diff --git a/grub-core/loader/i386/multiboot_mbi.c
b/grub-core/loader/i386/multiboot_mbi.c
index f60b702..fd7b41b 100644
--- a/grub-core/loader/i386/multiboot_mbi.c
+++ b/grub-core/loader/i386/multiboot_mbi.c
@@ -70,9 +70,18 @@ load_kernel (grub_file_t file, const char *filename,
char *buffer, struct multiboot_header *header)
{
grub_err_t err;
+ mbi_load_data_t mld;
+
+ mld.file = file;
+ mld.filename = filename;
+ mld.buffer = buffer;
+ mld.mbi_ver = 1;
+ mld.relocatable = 0;
+ mld.avoid_efi_boot_services = 0;
+
if (grub_multiboot_quirks & GRUB_MULTIBOOT_QUIRK_BAD_KLUDGE)
{
- err = grub_multiboot_load_elf (file, filename, buffer);
+ err = grub_multiboot_load_elf (&mld);
if (err == GRUB_ERR_NONE) {
return GRUB_ERR_NONE;
}
@@ -121,7 +130,7 @@ load_kernel (grub_file_t file, const char *filename,
return GRUB_ERR_NONE;
}
- return grub_multiboot_load_elf (file, filename, buffer);
+ return grub_multiboot_load_elf (&mld);
}
static
[Xen-devel] [GRUB2 PATCH v6 3/4 - FOR COMMIT] multiboot2: Do not pass memory maps to image if EFI boot services are enabled
If image requested EFI boot services then skip multiboot2 memory maps.
Main reason for not providing maps is because they will likely be
invalid. We do a few allocations after filling them, e.g. for relocator
needs. Usually we do not care as we would have finished boot services.
If we keep boot services then it is easier/safer to not provide maps.
However, if image needs memory maps and they are not provided by bootloader
then it should get itself just before ExitBootServices() call.
Signed-off-by: Daniel Kiper
Reviewed-by: Konrad Rzeszutek Wilk
---
v5 - suggestions/fixes:
- improve commit message
(suggested by Konrad Rzeszutek Wilk).
v3 - suggestions/fixes:
- improve commit message
(suggested by Konrad Rzeszutek Wilk and Vladimir 'phcoder' Serbinenko).
---
grub-core/loader/multiboot_mbi2.c | 71 ++---
1 file changed, 35 insertions(+), 36 deletions(-)
diff --git a/grub-core/loader/multiboot_mbi2.c
b/grub-core/loader/multiboot_mbi2.c
index 6c04402..ad1553b 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -390,7 +390,7 @@ static grub_size_t
grub_multiboot_get_mbi_size (void)
{
#ifdef GRUB_MACHINE_EFI
- if (!efi_mmap_size)
+ if (!keep_bs && !efi_mmap_size)
find_efi_mmap_size ();
#endif
return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
@@ -755,12 +755,13 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
}
}
- {
-struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
-grub_fill_multiboot_mmap (tag);
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
- / sizeof (grub_properly_aligned_t);
- }
+ if (!keep_bs)
+{
+ struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
+ grub_fill_multiboot_mmap (tag);
+ ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+}
{
struct multiboot_tag_elf_sections *tag
@@ -776,18 +777,19 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
/ sizeof (grub_properly_aligned_t);
}
- {
-struct multiboot_tag_basic_meminfo *tag
- = (struct multiboot_tag_basic_meminfo *) ptrorig;
-tag->type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
-tag->size = sizeof (struct multiboot_tag_basic_meminfo);
+ if (!keep_bs)
+{
+ struct multiboot_tag_basic_meminfo *tag
+ = (struct multiboot_tag_basic_meminfo *) ptrorig;
+ tag->type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
+ tag->size = sizeof (struct multiboot_tag_basic_meminfo);
-/* Convert from bytes to kilobytes. */
-tag->mem_lower = grub_mmap_get_lower () / 1024;
-tag->mem_upper = grub_mmap_get_upper () / 1024;
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
- / sizeof (grub_properly_aligned_t);
- }
+ /* Convert from bytes to kilobytes. */
+ tag->mem_lower = grub_mmap_get_lower () / 1024;
+ tag->mem_upper = grub_mmap_get_upper () / 1024;
+ ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+}
{
struct grub_net_network_level_interface *net;
@@ -886,27 +888,24 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
grub_efi_uintn_t efi_desc_size;
grub_efi_uint32_t efi_desc_version;
-tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
-tag->size = sizeof (*tag) + efi_mmap_size;
-
if (!keep_bs)
- err = grub_efi_finish_boot_services (&efi_mmap_size, tag->efi_mmap, NULL,
- &efi_desc_size, &efi_desc_version);
-else
{
- if (grub_efi_get_memory_map (&efi_mmap_size, (void *) tag->efi_mmap,
-NULL,
-&efi_desc_size, &efi_desc_version) <= 0)
- err = grub_error (GRUB_ERR_IO, "couldn't retrieve memory map");
+ tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
+ tag->size = sizeof (*tag) + efi_mmap_size;
+
+ err = grub_efi_finish_boot_services (&efi_mmap_size, tag->efi_mmap,
NULL,
+&efi_desc_size, &efi_desc_version);
+
+ if (err)
+ return err;
+
+ tag->descr_size = efi_desc_size;
+ tag->descr_vers = efi_desc_version;
+ tag->size = sizeof (*tag) + efi_mmap_size;
+
+ ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
}
-if (err)
- return err;
-tag->descr_size = efi_desc_size;
-tag->descr_vers = efi_desc_version;
-tag->size = sizeof (*tag) + efi_mmap_size;
-
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
- / sizeof (grub_properly_aligned_t);
}
if (keep_bs)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [GRUB2 PATCH v6 2/4] multiboot2: Add tags used to pass ImageHandle to loaded image
Add tags used to pass ImageHandle to loaded image if requested.
It is used by at least ExitBootServices() function.
Signed-off-by: Daniel Kiper
Reviewed-by: Konrad Rzeszutek Wilk
---
v4 - suggestions/fixes:
- reduce number of #ifdefs in grub_multiboot_get_mbi_size()
(suggested by Vladimir 'phcoder' Serbinenko).
v3 - suggestions/fixes:
- mbi EFI related stuff size calculation
should depend on target architecture
(suggested by Konrad Rzeszutek Wilk),
- use plain type instead of pointer
dereference as sizeof() argument
(suggested by Konrad Rzeszutek Wilk),
- improve commit message
(suggested by Konrad Rzeszutek Wilk).
---
grub-core/loader/multiboot_mbi2.c | 42 ++---
include/multiboot2.h | 16 ++
2 files changed, 51 insertions(+), 7 deletions(-)
diff --git a/grub-core/loader/multiboot_mbi2.c
b/grub-core/loader/multiboot_mbi2.c
index a3dca90..6c04402 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -172,6 +172,8 @@ grub_multiboot_load (grub_file_t file, const char *filename)
case MULTIBOOT_TAG_TYPE_NETWORK:
case MULTIBOOT_TAG_TYPE_EFI_MMAP:
case MULTIBOOT_TAG_TYPE_EFI_BS:
+ case MULTIBOOT_TAG_TYPE_EFI32_IH:
+ case MULTIBOOT_TAG_TYPE_EFI64_IH:
break;
default:
@@ -407,13 +409,15 @@ grub_multiboot_get_mbi_size (void)
+ grub_get_multiboot_mmap_count ()
* sizeof (struct multiboot_mmap_entry)), MULTIBOOT_TAG_ALIGN)
+ ALIGN_UP (sizeof (struct multiboot_tag_framebuffer), MULTIBOOT_TAG_ALIGN)
-+ ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
-+ ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
+ ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
+ sizeof (struct grub_acpi_rsdp_v10), MULTIBOOT_TAG_ALIGN)
+ acpiv2_size ()
+ net_size ()
#ifdef GRUB_MACHINE_EFI
++ ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
++ ALIGN_UP (sizeof (struct multiboot_tag_efi32_ih), MULTIBOOT_TAG_ALIGN)
++ ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
++ ALIGN_UP (sizeof (struct multiboot_tag_efi64_ih), MULTIBOOT_TAG_ALIGN)
+ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
+ efi_mmap_size, MULTIBOOT_TAG_ALIGN)
#endif
@@ -907,11 +911,35 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
if (keep_bs)
{
- struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
- tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
- tag->size = sizeof (struct multiboot_tag);
- ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
- / sizeof (grub_properly_aligned_t);
+ {
+ struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
+ tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
+ tag->size = sizeof (struct multiboot_tag);
+ ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+ }
+
+#ifdef __i386__
+ {
+ struct multiboot_tag_efi32_ih *tag = (struct multiboot_tag_efi32_ih *)
ptrorig;
+ tag->type = MULTIBOOT_TAG_TYPE_EFI32_IH;
+ tag->size = sizeof (struct multiboot_tag_efi32_ih);
+ tag->pointer = (grub_addr_t) grub_efi_image_handle;
+ ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+ }
+#endif
+
+#ifdef __x86_64__
+ {
+ struct multiboot_tag_efi64_ih *tag = (struct multiboot_tag_efi64_ih *)
ptrorig;
+ tag->type = MULTIBOOT_TAG_TYPE_EFI64_IH;
+ tag->size = sizeof (struct multiboot_tag_efi64_ih);
+ tag->pointer = (grub_addr_t) grub_efi_image_handle;
+ ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+ }
+#endif
}
#endif
diff --git a/include/multiboot2.h b/include/multiboot2.h
index 46e7b71..f5bebe1 100644
--- a/include/multiboot2.h
+++ b/include/multiboot2.h
@@ -60,6 +60,8 @@
#define MULTIBOOT_TAG_TYPE_NETWORK 16
#define MULTIBOOT_TAG_TYPE_EFI_MMAP 17
#define MULTIBOOT_TAG_TYPE_EFI_BS18
+#define MULTIBOOT_TAG_TYPE_EFI32_IH 19
+#define MULTIBOOT_TAG_TYPE_EFI64_IH 20
#define MULTIBOOT_HEADER_TAG_END 0
#define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST 1
@@ -371,6 +373,20 @@ struct multiboot_tag_efi_mmap
multiboot_uint8_t efi_mmap[0];
};
+struct multiboot_tag_efi32_ih
+{
+ multiboot_uint32_t type;
+ multiboot_uint32_t size;
+ multiboot_uint32_t pointer;
+};
+
+struct multiboot_tag_efi64_ih
+{
+ multiboot_uint32_t type;
+ multiboot_uint32_t size;
+ multiboot_uint64_t pointer;
+};
+
#endif /* ! ASM_FILE */
#endif /* ! MULTIBOOT_HEADER */
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-deve
[Xen-devel] [GRUB2 PATCH v6 0/4] multiboot2: Add two extensions
Hi, This patch series: - enables EFI boot services usage in loaded images by multiboot2 protocol, - add support for multiboot2 protocol compatible relocatable images. Daniel grub-core/Makefile.core.def |1 + grub-core/lib/i386/relocator64.S | 11 grub-core/lib/x86_64/efi/relocator.c | 80 + grub-core/loader/i386/multiboot_mbi.c | 13 +++- grub-core/loader/multiboot.c | 62 +++ grub-core/loader/multiboot_elfxx.c| 131 +--- grub-core/loader/multiboot_mbi2.c | 256 +- include/grub/i386/multiboot.h | 11 include/grub/i386/relocator.h | 21 +++ include/grub/multiboot.h | 22 ++- include/multiboot2.h | 41 + 11 files changed, 517 insertions(+), 132 deletions(-) Daniel Kiper (4): i386/relocator: Add grub_relocator64_efi relocator multiboot2: Add tags used to pass ImageHandle to loaded image multiboot2: Do not pass memory maps to image if EFI boot services are enabled multiboot2: Add support for relocatable images ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [GRUB2 PATCH v6 3/4 - FOR REVIEW ONLY] multiboot2: Do not pass memory maps to image if EFI boot services are enabled
If image requested EFI boot services then skip multiboot2 memory maps.
Main reason for not providing maps is because they will likely be
invalid. We do a few allocations after filling them, e.g. for relocator
needs. Usually we do not care as we would have finished boot services.
If we keep boot services then it is easier/safer to not provide maps.
However, if image needs memory maps and they are not provided by bootloader
then it should get itself just before ExitBootServices() call.
Signed-off-by: Daniel Kiper
Reviewed-by: Konrad Rzeszutek Wilk
---
v5 - suggestions/fixes:
- improve commit message
(suggested by Konrad Rzeszutek Wilk).
v3 - suggestions/fixes:
- improve commit message
(suggested by Konrad Rzeszutek Wilk and Vladimir 'phcoder' Serbinenko).
---
grub-core/loader/multiboot_mbi2.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/grub-core/loader/multiboot_mbi2.c
b/grub-core/loader/multiboot_mbi2.c
index 6c04402..ad1553b 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -390,7 +390,7 @@ static grub_size_t
grub_multiboot_get_mbi_size (void)
{
#ifdef GRUB_MACHINE_EFI
- if (!efi_mmap_size)
+ if (!keep_bs && !efi_mmap_size)
find_efi_mmap_size ();
#endif
return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
@@ -755,6 +755,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
}
}
+ if (!keep_bs)
{
struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
grub_fill_multiboot_mmap (tag);
@@ -776,6 +777,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
/ sizeof (grub_properly_aligned_t);
}
+ if (!keep_bs)
{
struct multiboot_tag_basic_meminfo *tag
= (struct multiboot_tag_basic_meminfo *) ptrorig;
@@ -886,21 +888,17 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
grub_efi_uintn_t efi_desc_size;
grub_efi_uint32_t efi_desc_version;
+if (!keep_bs)
+ {
tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
tag->size = sizeof (*tag) + efi_mmap_size;
-if (!keep_bs)
err = grub_efi_finish_boot_services (&efi_mmap_size, tag->efi_mmap,
NULL,
&efi_desc_size, &efi_desc_version);
-else
- {
- if (grub_efi_get_memory_map (&efi_mmap_size, (void *) tag->efi_mmap,
-NULL,
-&efi_desc_size, &efi_desc_version) <= 0)
- err = grub_error (GRUB_ERR_IO, "couldn't retrieve memory map");
- }
+
if (err)
return err;
+
tag->descr_size = efi_desc_size;
tag->descr_vers = efi_desc_version;
tag->size = sizeof (*tag) + efi_mmap_size;
@@ -908,6 +906,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
/ sizeof (grub_properly_aligned_t);
}
+ }
if (keep_bs)
{
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 11/11] libxl: libxl_tmem functions improving coding style
In accordance with CODING_SYTLE:
- Use 'r' for return values to functions whose return values are a
different error space (like xc_tmem_control, xc_tmem_auth)
Signed-off-by: Paulina Szubarczyk
CC: Wei Liu
CC: Ian Jackson
CC: Dario Faggioli
CC: Ian Campbell
---
tools/libxl/libxl.c | 58 ++---
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6bdf3b1..eddd39b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -6046,14 +6046,14 @@ uint32_t libxl_vm_get_start_time(libxl_ctx *ctx,
uint32_t domid)
char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int use_long)
{
-int rc;
+int r;
char _buf[32768];
GC_INIT(ctx);
-rc = xc_tmem_control(ctx->xch, -1, XEN_SYSCTL_TMEM_OP_LIST, domid, 32768,
use_long,
+r = xc_tmem_control(ctx->xch, -1, XEN_SYSCTL_TMEM_OP_LIST, domid, 32768,
use_long,
_buf);
-if (rc < 0) {
-LOGEV(ERROR, rc, "Can not get tmem list");
+if (r < 0) {
+LOGEV(ERROR, r, "Can not get tmem list");
GC_FREE;
return NULL;
}
@@ -6064,36 +6064,36 @@ char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid,
int use_long)
int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid)
{
-int rc;
+int r;
GC_INIT(ctx);
-rc = xc_tmem_control(ctx->xch, -1, XEN_SYSCTL_TMEM_OP_FREEZE, domid, 0, 0,
+r = xc_tmem_control(ctx->xch, -1, XEN_SYSCTL_TMEM_OP_FREEZE, domid, 0, 0,
NULL);
-if (rc < 0) {
-LOGEV(ERROR, rc, "Can not freeze tmem pools");
+if (r < 0) {
+LOGEV(ERROR, r, "Can not freeze tmem pools");
GC_FREE;
return ERROR_FAIL;
}
GC_FREE;
-return rc;
+return r;
}
int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid)
{
-int rc;
+int r;
GC_INIT(ctx);
-rc = xc_tmem_control(ctx->xch, -1, XEN_SYSCTL_TMEM_OP_THAW, domid, 0, 0,
+r = xc_tmem_control(ctx->xch, -1, XEN_SYSCTL_TMEM_OP_THAW, domid, 0, 0,
NULL);
-if (rc < 0) {
-LOGEV(ERROR, rc, "Can not thaw tmem pools");
+if (r < 0) {
+LOGEV(ERROR, r, "Can not thaw tmem pools");
GC_FREE;
return ERROR_FAIL;
}
GC_FREE;
-return rc;
+return r;
}
static int32_t tmem_setop_from_string(char *set_name)
@@ -6110,7 +6110,7 @@ static int32_t tmem_setop_from_string(char *set_name)
int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name, uint32_t set)
{
-int rc;
+int r;
int32_t subop = tmem_setop_from_string(name);
GC_INIT(ctx);
@@ -6119,48 +6119,48 @@ int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid,
char* name, uint32_t set)
GC_FREE;
return ERROR_INVAL;
}
-rc = xc_tmem_control(ctx->xch, -1, subop, domid, set, 0, NULL);
-if (rc < 0) {
-LOGEV(ERROR, rc, "Can not set tmem %s", name);
+r = xc_tmem_control(ctx->xch, -1, subop, domid, set, 0, NULL);
+if (r < 0) {
+LOGEV(ERROR, r, "Can not set tmem %s", name);
GC_FREE;
return ERROR_FAIL;
}
GC_FREE;
-return rc;
+return r;
}
int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid,
char* uuid, int auth)
{
-int rc;
+int r;
GC_INIT(ctx);
-rc = xc_tmem_auth(ctx->xch, domid, uuid, auth);
-if (rc < 0) {
-LOGEV(ERROR, rc, "Can not set tmem shared auth");
+r = xc_tmem_auth(ctx->xch, domid, uuid, auth);
+if (r < 0) {
+LOGEV(ERROR, r, "Can not set tmem shared auth");
GC_FREE;
return ERROR_FAIL;
}
GC_FREE;
-return rc;
+return r;
}
int libxl_tmem_freeable(libxl_ctx *ctx)
{
-int rc;
+int r;
GC_INIT(ctx);
-rc = xc_tmem_control(ctx->xch, -1, XEN_SYSCTL_TMEM_OP_QUERY_FREEABLE_MB,
-1, 0, 0, 0);
-if (rc < 0) {
-LOGEV(ERROR, rc, "Can not get tmem freeable memory");
+r = xc_tmem_control(ctx->xch, -1, XEN_SYSCTL_TMEM_OP_QUERY_FREEABLE_MB,
-1, 0, 0, 0);
+if (r < 0) {
+LOGEV(ERROR, r, "Can not get tmem freeable memory");
GC_FREE;
return ERROR_FAIL;
}
GC_FREE;
-return rc;
+return r;
}
int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 09/11] libxl: Remove pointless hypercall from libxl_set_memory_target
There's no obvious reason for the call to
xc_domain_getinfolist -- all it seems to be doing is checking that the domain
exists; but if it doesn't exist, it will have already failed by this point.
NB that this will change the return value for libxl_set_memory_target:
now it will return 0 on success, rather than returning 1 (which was
the previous behavior). This is more in line with expected behavior,
and also allows the caller to distingiush between success and other
failure modes (some of which also return 1).
Signed-off-by: George Dunlap
CC: Wei Liu
CC: Ian Jackson
CC: Dario Faggioli
CC: Ian Campbell
---
tools/libxl/libxl.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 93e228d..4291b57 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4789,11 +4789,6 @@ retry_transaction:
libxl__xs_printf(gc, t, GCSPRINTF("%s/memory/target", dompath),
"%"PRIu32, new_target_memkb);
-rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
-if (rc != 1 || info.domain != domid) {
-abort_transaction = 1;
-goto out;
-}
libxl_dominfo_init(&ptr);
xcinfo2xlinfo(ctx, &info, &ptr);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 07/11] xl: Return error codes for pci* commands
Add return codes for pci-detach, pci-attach,
pci-asssignable-add, and pci-assignable-remove.
Returning error codes makes it easier for shell scripts to tell if a
command has failed or succeeded.
NB this violates the CODING_STYLE preference for not initializing the
return-value variable at declaration; but in these cases, having a
"goto out" that jumped over nothing but an "r = 0" seemed
a bit pointless.
Signed-off-by: George Dunlap
Signed-off-by: Paulina Szubarczyk
CC: Wei Liu
CC: Ian Jackson
CC: Dario Faggioli
CC: Ian Campbell
---
tools/libxl/xl_cmdimpl.c | 78 ++--
1 file changed, 56 insertions(+), 22 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index e93808e..c70fd70 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3514,10 +3514,11 @@ int main_pcilist(int argc, char **argv)
return 0;
}
-static void pcidetach(uint32_t domid, const char *bdf, int force)
+static int pcidetach(uint32_t domid, const char *bdf, int force)
{
libxl_device_pci pcidev;
XLU_Config *config;
+int r = 0;
libxl_device_pci_init(&pcidev);
@@ -3526,15 +3527,20 @@ static void pcidetach(uint32_t domid, const char *bdf,
int force)
if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
fprintf(stderr, "pci-detach: malformed BDF specification \"%s\"\n",
bdf);
-exit(2);
+exit(EXIT_FAILURE);
+}
+if (force) {
+if (libxl_device_pci_destroy(ctx, domid, &pcidev, 0))
+r = 1;
+} else {
+if (libxl_device_pci_remove(ctx, domid, &pcidev, 0))
+r = 1;
}
-if (force)
-libxl_device_pci_destroy(ctx, domid, &pcidev, 0);
-else
-libxl_device_pci_remove(ctx, domid, &pcidev, 0);
libxl_device_pci_dispose(&pcidev);
xlu_cfg_destroy(config);
+
+return r;
}
int main_pcidetach(int argc, char **argv)
@@ -3553,13 +3559,18 @@ int main_pcidetach(int argc, char **argv)
domid = find_domain(argv[optind]);
bdf = argv[optind + 1];
-pcidetach(domid, bdf, force);
-return 0;
+if (pcidetach(domid, bdf, force)) {
+return EXIT_FAILURE;
+}
+
+return EXIT_SUCCESS;
}
-static void pciattach(uint32_t domid, const char *bdf, const char *vs)
+
+static int pciattach(uint32_t domid, const char *bdf, const char *vs)
{
libxl_device_pci pcidev;
XLU_Config *config;
+int r = 0;
libxl_device_pci_init(&pcidev);
@@ -3568,12 +3579,16 @@ static void pciattach(uint32_t domid, const char *bdf,
const char *vs)
if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
fprintf(stderr, "pci-attach: malformed BDF specification \"%s\"\n",
bdf);
-exit(2);
+exit(EXIT_FAILURE);
}
-libxl_device_pci_add(ctx, domid, &pcidev, 0);
+
+if (libxl_device_pci_add(ctx, domid, &pcidev, 0))
+r = 1;
libxl_device_pci_dispose(&pcidev);
xlu_cfg_destroy(config);
+
+return 1;
}
int main_pciattach(int argc, char **argv)
@@ -3592,8 +3607,11 @@ int main_pciattach(int argc, char **argv)
if (optind + 1 < argc)
vs = argv[optind + 2];
-pciattach(domid, bdf, vs);
-return 0;
+if (pciattach(domid, bdf, vs)) {
+return EXIT_FAILURE;
+}
+
+return EXIT_SUCCESS;
}
static void pciassignable_list(void)
@@ -3625,10 +3643,11 @@ int main_pciassignable_list(int argc, char **argv)
return 0;
}
-static void pciassignable_add(const char *bdf, int rebind)
+static int pciassignable_add(const char *bdf, int rebind)
{
libxl_device_pci pcidev;
XLU_Config *config;
+int r = 0;
libxl_device_pci_init(&pcidev);
@@ -3637,12 +3656,16 @@ static void pciassignable_add(const char *bdf, int
rebind)
if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
fprintf(stderr, "pci-assignable-add: malformed BDF specification
\"%s\"\n", bdf);
-exit(2);
+exit(EXIT_FAILURE);
}
-libxl_device_pci_assignable_add(ctx, &pcidev, rebind);
+
+if (libxl_device_pci_assignable_add(ctx, &pcidev, rebind))
+r = 1;
libxl_device_pci_dispose(&pcidev);
xlu_cfg_destroy(config);
+
+return r;
}
int main_pciassignable_add(int argc, char **argv)
@@ -3656,14 +3679,18 @@ int main_pciassignable_add(int argc, char **argv)
bdf = argv[optind];
-pciassignable_add(bdf, 1);
-return 0;
+if (pciassignable_add(bdf, 1)) {
+return EXIT_FAILURE;
+}
+
+return EXIT_SUCCESS;
}
-static void pciassignable_remove(const char *bdf, int rebind)
+static int pciassignable_remove(const char *bdf, int rebind)
{
libxl_device_pci pcidev;
XLU_Config *config;
+int r = 0;
libxl_device_pci_init(&pcidev);
@@ -3674,10 +3701,14 @@ static void pciassignable_remove(const char *bdf, int
rebind)
fprintf(stderr, "pci-assignable-remove: malformed BDF specification
\"%s\"\n", bdf);
exit(2);
}
-libxl_device_pci_assignable_remove(ctx, &pcidev, rebi
[Xen-devel] [PATCH 08/11] xl: improve main_tmem_* return codes
Functions libxl_tmem_freeze(), libxl_tmem_thaw(), libxl_tmem_set() and
libxl_tmem_shared_auth() located in libxl.c file return
ERROR_FAIL/ERROR_INVAL or internal error codes from libxc library
* improve main_tmem_* return codes by returning EXIT_{SUCCESS/FAILURE}
accordingly to return codes of those functions.
Signed-off-by: Paulina Szubarczyk
CC: Wei Liu
CC: Ian Jackson
CC: Dario Faggioli
CC: Ian Campbell
---
tools/libxl/xl_cmdimpl.c | 51 ++--
1 file changed, 32 insertions(+), 19 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c70fd70..348391f 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7205,7 +7205,7 @@ int main_tmem_freeze(int argc, char **argv)
if (!dom && all == 0) {
fprintf(stderr, "You must specify -a or a domain id.\n\n");
help("tmem-freeze");
-return 1;
+return EXIT_FAILURE;
}
if (all)
@@ -7213,8 +7213,11 @@ int main_tmem_freeze(int argc, char **argv)
else
domid = find_domain(dom);
-libxl_tmem_freeze(ctx, domid);
-return 0;
+if (libxl_tmem_freeze(ctx, domid) < 0) {
+return EXIT_FAILURE;
+}
+
+return EXIT_SUCCESS;
}
int main_tmem_thaw(int argc, char **argv)
@@ -7234,7 +7237,7 @@ int main_tmem_thaw(int argc, char **argv)
if (!dom && all == 0) {
fprintf(stderr, "You must specify -a or a domain id.\n\n");
help("tmem-thaw");
-return 1;
+return EXIT_FAILURE;
}
if (all)
@@ -7242,8 +7245,11 @@ int main_tmem_thaw(int argc, char **argv)
else
domid = find_domain(dom);
-libxl_tmem_thaw(ctx, domid);
-return 0;
+if (libxl_tmem_thaw(ctx, domid) < 0) {
+return EXIT_FAILURE;
+}
+
+return EXIT_SUCCESS;
}
int main_tmem_set(int argc, char **argv)
@@ -7254,6 +7260,7 @@ int main_tmem_set(int argc, char **argv)
int opt_w = 0, opt_c = 0, opt_p = 0;
int all = 0;
int opt;
+int r = 0;
SWITCH_FOREACH_OPT(opt, "aw:c:p:", NULL, "tmem-set", 0) {
case 'a':
@@ -7277,7 +7284,7 @@ int main_tmem_set(int argc, char **argv)
if (!dom && all == 0) {
fprintf(stderr, "You must specify -a or a domain id.\n\n");
help("tmem-set");
-return 1;
+return EXIT_FAILURE;
}
if (all)
@@ -7288,17 +7295,21 @@ int main_tmem_set(int argc, char **argv)
if (!opt_w && !opt_c && !opt_p) {
fprintf(stderr, "No set value specified.\n\n");
help("tmem-set");
-return 1;
+return EXIT_FAILURE;
}
if (opt_w)
-libxl_tmem_set(ctx, domid, "weight", weight);
+r = libxl_tmem_set(ctx, domid, "weight", weight);
if (opt_c)
-libxl_tmem_set(ctx, domid, "cap", cap);
+r = libxl_tmem_set(ctx, domid, "cap", cap);
if (opt_p)
-libxl_tmem_set(ctx, domid, "compress", compress);
+r = libxl_tmem_set(ctx, domid, "compress", compress);
-return 0;
+if (r < 0) {
+return EXIT_FAILURE;
+}
+
+return EXIT_SUCCESS;
}
int main_tmem_shared_auth(int argc, char **argv)
@@ -7328,7 +7339,7 @@ int main_tmem_shared_auth(int argc, char **argv)
if (!dom && all == 0) {
fprintf(stderr, "You must specify -a or a domain id.\n\n");
help("tmem-shared-auth");
-return 1;
+return EXIT_FAILURE;
}
if (all)
@@ -7339,18 +7350,20 @@ int main_tmem_shared_auth(int argc, char **argv)
if (uuid == NULL || autharg == NULL) {
fprintf(stderr, "No uuid or auth specified.\n\n");
help("tmem-shared-auth");
-return 1;
+return EXIT_FAILURE;
}
auth = strtol(autharg, &endptr, 10);
if (*endptr != '\0') {
fprintf(stderr, "Invalid auth, valid auth are <0|1>.\n\n");
-return 1;
+return EXIT_FAILURE;
}
-libxl_tmem_shared_auth(ctx, domid, uuid, auth);
+if (libxl_tmem_shared_auth(ctx, domid, uuid, auth) < 0) {
+return EXIT_FAILURE;
+}
-return 0;
+return EXIT_SUCCESS;
}
int main_tmem_freeable(int argc, char **argv)
@@ -7364,10 +7377,10 @@ int main_tmem_freeable(int argc, char **argv)
mb = libxl_tmem_freeable(ctx);
if (mb == -1)
-return -1;
+return EXIT_FAILURE;
printf("%d\n", mb);
-return 0;
+return EXIT_SUCCESS;
}
int main_cpupoolcreate(int argc, char **argv)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 05/11] xl: Make set_memory_target return an error code on failure
Change a 'long long' to "int64_t" while we're at it.
Signed-off-by: George Dunlap
Signed-off-by: Paulina Szubarczyk
- Move rc -> shell return code translation into set_memory_{max,target}
- Use EXIT_{SUCCESS,FAILURE} for main_mem*() function
- Use 0/1 as return values of set_memory_{max,target}
- Use EXIT_{SUCCESS,FAILURE} as exit code for set_memory_{max,target}
- Note incidental type change in changelog
CC: Wei Liu
CC: Ian Jackson
CC: Dario Faggioli
CC: Ian Campbell
---
tools/libxl/xl_cmdimpl.c | 41 +
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 173cd28..a7f3956 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3271,17 +3271,20 @@ static int def_getopt(int argc, char * const argv[],
static int set_memory_max(uint32_t domid, const char *mem)
{
int64_t memorykb;
-int rc;
memorykb = parse_mem_size_kb(mem);
if (memorykb == -1) {
fprintf(stderr, "invalid memory size: %s\n", mem);
-exit(3);
+exit(EXIT_FAILURE);
}
-rc = libxl_domain_setmaxmem(ctx, domid, memorykb);
+if (libxl_domain_setmaxmem(ctx, domid, memorykb)) {
+fprintf(stderr, "cannot set domid %d static max memory to : %s\n",
+domid, mem);
+return 1;
+}
-return rc;
+return 0;
}
int main_memmax(int argc, char **argv)
@@ -3289,7 +3292,6 @@ int main_memmax(int argc, char **argv)
uint32_t domid;
int opt = 0;
char *mem;
-int rc;
SWITCH_FOREACH_OPT(opt, "", NULL, "mem-max", 2) {
/* No options */
@@ -3298,26 +3300,30 @@ int main_memmax(int argc, char **argv)
domid = find_domain(argv[optind]);
mem = argv[optind + 1];
-rc = set_memory_max(domid, mem);
-if (rc) {
-fprintf(stderr, "cannot set domid %d static max memory to : %s\n",
domid, mem);
-return 1;
+if (set_memory_max(domid, mem)) {
+return EXIT_FAILURE;
}
-return 0;
+return EXIT_SUCCESS;
}
-static void set_memory_target(uint32_t domid, const char *mem)
+static int set_memory_target(uint32_t domid, const char *mem)
{
-long long int memorykb;
+int64_t memorykb;
memorykb = parse_mem_size_kb(mem);
if (memorykb == -1) {
fprintf(stderr, "invalid memory size: %s\n", mem);
-exit(3);
+exit(EXIT_FAILURE);
+}
+
+if (libxl_set_memory_target(ctx, domid, memorykb, 0, /* enforce */ 1)) {
+fprintf(stderr, "cannot set domid %d dynamic max memory to : %s\n",
+domid, mem);
+return 1;
}
-libxl_set_memory_target(ctx, domid, memorykb, 0, /* enforce */ 1);
+return 0;
}
int main_memset(int argc, char **argv)
@@ -,8 +3339,11 @@ int main_memset(int argc, char **argv)
domid = find_domain(argv[optind]);
mem = argv[optind + 1];
-set_memory_target(domid, mem);
-return 0;
+if (set_memory_target(domid, mem)) {
+return EXIT_FAILURE;
+}
+
+return EXIT_SUCCESS;
}
static int cd_insert(uint32_t domid, const char *virtdev, char *phys)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 06/11] xl: Return an error on failed cd-insert
This makes xl more useful in scripts.
The strange thing about this is that the internal cd_insert function
*already* returned something appropriate, and cd-eject was using it,
but cd-insert wasn't.
Also:
* Rework cd_insert to return 0 or 1 as an internal function
* Use EXIT_{SUCCESS,FAILURE} for main_cd_*() functions
* Use 'r' for non-libxl return code, as specified in CODING_STYLE
Signed-off-by: George Dunlap
Signed-off-by: Paulina Szubarczyk
CC: Wei Liu
CC: Ian Jackson
CC: Dario Faggioli
CC: Ian Campbell
---
tools/libxl/xl_cmdimpl.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index a7f3956..e93808e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3352,7 +3352,7 @@ static int cd_insert(uint32_t domid, const char *virtdev,
char *phys)
char *buf = NULL;
XLU_Config *config = 0;
struct stat b;
-int rc = 0;
+int r;
xasprintf(&buf, "vdev=%s,access=r,devtype=cdrom,target=%s",
virtdev, phys ? phys : "");
@@ -3368,18 +3368,21 @@ static int cd_insert(uint32_t domid, const char
*virtdev, char *phys)
&& stat(disk.pdev_path, &b)) {
fprintf(stderr, "Cannot stat file: %s\n",
disk.pdev_path);
-rc = 1;
+r = 1;
goto out;
}
-if (libxl_cdrom_insert(ctx, domid, &disk, NULL))
-rc=1;
+if (libxl_cdrom_insert(ctx, domid, &disk, NULL)) {
+r = 1;
+goto out;
+}
+r = 0;
out:
libxl_device_disk_dispose(&disk);
free(buf);
-return rc;
+return r;
}
int main_cd_eject(int argc, char **argv)
@@ -3395,7 +3398,11 @@ int main_cd_eject(int argc, char **argv)
domid = find_domain(argv[optind]);
virtdev = argv[optind + 1];
-return cd_insert(domid, virtdev, NULL);
+if (cd_insert(domid, virtdev, NULL)) {
+return EXIT_FAILURE;
+}
+
+return EXIT_SUCCESS;
}
int main_cd_insert(int argc, char **argv)
@@ -3413,8 +3420,11 @@ int main_cd_insert(int argc, char **argv)
virtdev = argv[optind + 1];
file = argv[optind + 2];
-cd_insert(domid, virtdev, file);
-return 0;
+if (cd_insert(domid, virtdev, file)) {
+return EXIT_FAILURE;
+}
+
+return EXIT_SUCCESS;
}
int main_console(int argc, char **argv)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 10/11] libxl: Fix libxl_set_memory_target return value
libxl_set_memory_target seems to have the following return values:
* 1 on failure, if the failure happens because of a xenstore error *or*
* invalid
target
* -1 if the setmaxmem hypercall
* -errno if the set_pod_target hypercall target fails
* 0 on success
Make it consistently return ERROR_FAIL on failure, unless the
parameters were invalid, in which case return ERROR_INVAL.
In accordance with CODING_SYTLE:
1. Leave rc uninitialized, and set when an error is detected
2. Use 'r' for return values to functions whose return values are a
different error space (like xc_domain_setmaxmem and
xc_domain_set_pod_target), or where a failure means retry, rather than
fail the whole function (libxl__fill_dom0_memory_info), to reduce the
risk that
Signed-off-by: George Dunlap
CC: Wei Liu
CC: Ian Jackson
CC: Dario Faggioli
CC: Ian Campbell
---
tools/libxl/libxl.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 4291b57..6bdf3b1 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4672,7 +4672,7 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
domid,
int32_t target_memkb, int relative, int enforce)
{
GC_INIT(ctx);
-int rc = 1, abort_transaction = 0;
+int rc, r, abort_transaction = 0;
uint64_t memorykb;
uint32_t videoram = 0;
uint32_t current_target_memkb = 0, new_target_memkb = 0;
@@ -4700,15 +4700,15 @@ retry_transaction:
if (!target && !domid) {
if (!xs_transaction_end(ctx->xsh, t, 1))
goto out_no_transaction;
-rc = libxl__fill_dom0_memory_info(gc, ¤t_target_memkb,
+r = libxl__fill_dom0_memory_info(gc, ¤t_target_memkb,
¤t_max_memkb);
-if (rc < 0)
-goto out_no_transaction;
+if (r < 0) { rc = ERROR_FAIL; goto out_no_transaction; }
goto retry_transaction;
} else if (!target) {
LOGE(ERROR, "cannot get target memory info from %s/memory/target",
dompath);
abort_transaction = 1;
+rc = ERROR_FAIL;
goto out;
} else {
current_target_memkb = strtoul(target, &endptr, 10);
@@ -4716,6 +4716,7 @@ retry_transaction:
LOGE(ERROR, "invalid memory target %s from %s/memory/target\n",
target, dompath);
abort_transaction = 1;
+rc = ERROR_FAIL;
goto out;
}
}
@@ -4724,6 +4725,7 @@ retry_transaction:
LOGE(ERROR, "cannot get memory info from %s/memory/static-max",
dompath);
abort_transaction = 1;
+rc = ERROR_FAIL;
goto out;
}
memorykb = strtoul(memmax, &endptr, 10);
@@ -4731,6 +4733,7 @@ retry_transaction:
LOGE(ERROR, "invalid max memory %s from %s/memory/static-max\n",
memmax, dompath);
abort_transaction = 1;
+rc = ERROR_FAIL;
goto out;
}
@@ -4750,6 +4753,7 @@ retry_transaction:
"memory_dynamic_max must be less than or equal to"
" memory_static_max\n");
abort_transaction = 1;
+rc = ERROR_INVAL;
goto out;
}
@@ -4757,33 +4761,36 @@ retry_transaction:
LOG(ERROR, "new target %d for dom0 is below the minimum threshold",
new_target_memkb);
abort_transaction = 1;
+rc = ERROR_INVAL;
goto out;
}
if (enforce) {
memorykb = new_target_memkb + videoram;
-rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
+r = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
LIBXL_MAXMEM_CONSTANT);
-if (rc != 0) {
+if (r != 0) {
LOGE(ERROR,
"xc_domain_setmaxmem domid=%u memkb=%"PRIu64" failed
""rc=%d\n",
domid,
memorykb + LIBXL_MAXMEM_CONSTANT,
- rc);
+ r);
abort_transaction = 1;
+rc = ERROR_FAIL;
goto out;
}
}
-rc = xc_domain_set_pod_target(ctx->xch, domid,
+r = xc_domain_set_pod_target(ctx->xch, domid,
(new_target_memkb + LIBXL_MAXMEM_CONSTANT) / 4, NULL, NULL, NULL);
-if (rc != 0) {
+if (r != 0) {
LOGE(ERROR,
"xc_domain_set_pod_target domid=%d, memkb=%d ""failed rc=%d\n",
domid,
new_target_memkb / 4,
- rc);
+ r);
abort_transaction = 1;
+rc = ERROR_FAIL;
goto out;
}
@@ -4797,6 +4804,7 @@ retry_transaction:
"%"PRIu32, new_target_memkb / 1024);
libxl_dominfo_dispose(&ptr);
+rc = 0;
out:
if (!xs_transaction_end(ctx->xsh, t, abort_transaction)
&& !abort_transaction)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 01/11] libxl_pci: improve return codes for more xl commands
Return error code instead of always 0. Remove assigned-only
ret variable in libxl__create_pci_backend.
Signed-off-by: Paulina Szubarczyk
CC: Wei Liu
CC: Ian Jackson
CC: Dario Faggioli
CC: Ian Campbell
---
tools/libxl/libxl_pci.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index dc10cb7..3435ce2 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -84,13 +84,11 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
flexarray_t *front = NULL;
flexarray_t *back = NULL;
libxl__device device;
-int ret = ERROR_NOMEM, i;
+int i;
front = flexarray_make(gc, 16, 1);
back = flexarray_make(gc, 16, 1);
-ret = 0;
-
LOG(DEBUG, "Creating pci backend");
/* add pci device */
@@ -108,12 +106,10 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t
domid,
flexarray_append_pair(front, "backend-id", GCSPRINTF("%d", 0));
flexarray_append_pair(front, "state", GCSPRINTF("%d",
XenbusStateInitialising));
-libxl__device_generic_add(gc, XBT_NULL, &device,
+return libxl__device_generic_add(gc, XBT_NULL, &device,
libxl__xs_kvs_of_flexarray(gc, back,
back->count),
libxl__xs_kvs_of_flexarray(gc, front,
front->count),
NULL);
-
-return 0;
}
static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid,
libxl_device_pci *pcidev, int starting)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 04/11] xl: improve return code for freemem function
- Return 0 or 1 for freemem function
- Correct the condition of checking return values of freemem.
Signed-off-by: Paulina Szubarczyk
CC: Wei Liu
CC: Ian Jackson
CC: Dario Faggioli
CC: Ian Campbell
---
tools/libxl/xl_cmdimpl.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 990d3c9..173cd28 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2573,38 +2573,34 @@ static int preserve_domain(uint32_t *r_domid,
libxl_event *event,
static int freemem(uint32_t domid, libxl_domain_build_info *b_info)
{
-int rc, retries = 3;
+int retries = 3;
uint32_t need_memkb, free_memkb;
if (!autoballoon)
return 0;
-rc = libxl_domain_need_memory(ctx, b_info, &need_memkb);
-if (rc < 0)
-return rc;
+if (libxl_domain_need_memory(ctx, b_info, &need_memkb) < 0)
+return 1;
do {
-rc = libxl_get_free_memory(ctx, &free_memkb);
-if (rc < 0)
-return rc;
+if (libxl_get_free_memory(ctx, &free_memkb) < 0)
+return 1;
if (free_memkb >= need_memkb)
return 0;
-rc = libxl_set_memory_target(ctx, 0, free_memkb - need_memkb, 1, 0);
-if (rc < 0)
-return rc;
+if (libxl_set_memory_target(ctx, 0, free_memkb - need_memkb, 1, 0) < 0)
+return 1;
/* wait until dom0 reaches its target, as long as we are making
* progress */
-rc = libxl_wait_for_memory_target(ctx, 0, 10);
-if (rc < 0)
-return rc;
+if (libxl_wait_for_memory_target(ctx, 0, 10) < 0)
+return 1;
retries--;
} while (retries > 0);
-return ERROR_NOMEM;
+return 1;
}
static void autoconnect_console(libxl_ctx *ctx_ignored,
@@ -2870,7 +2866,7 @@ start:
if (domid_soft_reset == INVALID_DOMID) {
ret = freemem(domid, &d_config.b_info);
-if (ret < 0) {
+if (ret) {
fprintf(stderr, "failed to free memory for the domain\n");
ret = ERROR_FAIL;
goto error_out;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 03/11] libxl_pci: Return error code for more pci-* functions
Return rc value instead of always 0. Signed-off-by: Paulina Szubarczyk CC: Wei Liu CC: Ian Jackson CC: Dario Faggioli CC: Ian Campbell --- tools/libxl/libxl_pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index 6051ee4..e4a2c2c 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -1604,7 +1604,7 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid) } free(pcidevs); -return 0; +return rc; } int libxl__grant_vga_iomem_permission(libxl__gc *gc, const uint32_t domid, -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 00/11] Return failure on failure for more xl commands
This patch includes the changes from a patch prepared by George Dunlap [0] and expands them to more xl commands. This is my bite-sized outreachy project [1][2]. Return failure when the command failed for more xl commands: - mem-set - cd-insert - pci-* -- freemem -- tmem-* This makes xl more useful for scripting. In the case of mem-set, it means first cleaning up libxl_set_memory_target() to return useful error codes. For pci-* functions libxl__create_pci_backend(), libxl__device_pci_destroy_all() return error codes instead of always 0. Changes: - Remove block-attach patch - Split out removal of spurious getinfolist to a separate patch - Try to follow CODING_STYLE more closely: - In general, don't initialize rc / r, but use set-and-goto - Use 'r' for non-libxl error codes - Use EXIT_FAILURE and EXIT_SUCCESS rather than magic constants in main_foo() - Use 1 and 0 in internal functions of xl [0] http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02246.html [1] http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03031.html [2] https://www.mail-archive.com/xen-devel@lists.xen.org/msg62055.html CC: Wei Liu CC: Ian Jackson CC: Dario Faggioli CC: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] compilation fail, xen staging-4.6, vnc.c, qemu-tradintional issues under ubuntu 16.04
Cc-ing some tools, Qemu, and Stubdom/MiniOS people, and dropping xen- users (Bcc-ed)... On Fri, 2016-03-25 at 18:53 +0100, Éliás Tamás wrote: > Hi. > > Previously I was using debian 8 to compile my xen 4.6 with hvm > stubdomain support. We recently switched to ubuntu servers, thus I > needed to change my compilation environment not to have lib > dependency > issues. > > My problem is: I get the staging 4.6 xen > (http://xenbits.xen.org/gitweb/?p=xen.git;a=snapshot;h=8e89d43867922a > baa67e894938c655a6fa82affe;sf=tgz), > installed all required prereqs for my compilaton environment, but > during > compilation I get errors (I do not get them using debian 8). I'm sure > that all prereq is met, becasuse ./configure runs correctly, I'm > using > --enable-systemd --enable-stubdom ) > > Most of the problems could be solved by dirty hacks for myself, but I > belive they require some attention of qemu/xen developers to make > compilation work under ubuntu 16.04 out of the box: > > The first issue > > /usr/src/xen-staging-4.6/tools/qemu-xen-traditional-dir/vnc.c:2180: > undefined reference to `gnutls_kx_set_priority' > > could be solved by applying these patches over the auto downloaded > qemu > sources: > > https://gitlab.com/johnth/aur-xen/raw/f9d0b40e240add9a136483a450c6a1b > 39a685808/qemu-xen-traditional-gnutls-compilation.patch > > https://gitlab.com/johnth/aur-xen/raw/f9d0b40e240add9a136483a450c6a1b > 39a685808/qemu-xen-traditional-gnutls-functions.patch > > after that I got > > vl.c:2784:5: error: ‘g_mem_set_vtable’ is deprecated > [-Werror=deprecated-declarations] > g_mem_set_vtable(&mem_trace); > > > I had to apply > > https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg01262.html > > which seemes that only partially been applied (has rejects), but > after > modifying the sources by hand, it seemes working. > > Just after this, Mini-OS failed to compile: > > Makefile:17: /config/MiniOS.mk: No such file or directory > > But, the MiniOS.mk DOES exists. > > I had to manually add > > XEN_ROOT=mysourcedir > > to mini-os/Config.mk to continue. and now I'm stuck here: > > gcc -mno-red-zone -O1 -fno-omit-frame-pointer -m64 -mno-red-zone > -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g > -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > -Wdeclaration-after-statement -Wno-unused-but-set-variable > -Wno-unused-local-typedefs -fno-stack-protector -fno-exceptions > -DCONFIG_BLKFRONT -DCONFIG_TPMFRONT -DCONFIG_NETFRONT > -DCONFIG_KBDFRONT > -DCONFIG_FBFRONT -DCONFIG_CONSFRONT -DCONFIG_XENBUS -fno-builtin > -Wall > -Werror -Wredundant-decls -Wno-format -Wno-redundant-decls -Wformat > -fno-stack-protector -fgnu89-inline -Wstrict-prototypes -Wnested- > externs > -Wpointer-arith -Winline -g -D__INSIDE_MINIOS__ -m64 -mno-red-zone > -fno-reorder-blocks -fno-asynchronous-unwind-tables -isystem > /usr/src/xen-staging-4.6/extras/mini-os/include -D__MINIOS__ > -DHAVE_LIBC > -isystem /usr/src/xen-staging-4.6/extras/mini-os/include/posix > -isystem > /usr/src/xen-staging-4.6/tools/xenstore/include -isystem > /usr/src/xen-staging-4.6/extras/mini-os/include/x86 -isystem > /usr/src/xen-staging-4.6/extras/mini-os/include/x86/x86_64 -U > __linux__ > -U __FreeBSD__ -U __sun__ -nostdinc -isystem > /usr/src/xen-staging-4.6/extras/mini-os/include/posix -isystem > /usr/src/xen-staging-4.6/stubdom/cross-root-x86_64/x86_64-xen- > elf/include -isystem > /usr/lib/gcc/x86_64-linux-gnu/5/include -isystem > /usr/src/xen-staging-4.6/stubdom/lwip-x86_64/src/include -isystem > /usr/src/xen-staging-4.6/stubdom/lwip-x86_64/src/include/ipv4 > -I/usr/src/xen-staging-4.6/stubdom/include > -I/usr/src/xen-staging-4.6/xen/include -isystem > /usr/src/xen-staging-4.6/extras/mini-os/include -D__MINIOS__ > -DHAVE_LIBC > -isystem /usr/src/xen-staging-4.6/extras/mini-os/include/posix > -isystem > /usr/src/xen-staging-4.6/tools/xenstore/include > -D__XEN_INTERFACE_VERSION__=0x00030205 -isystem > /usr/src/xen-staging-4.6/extras/mini-os/include/x86 -isystem > /usr/src/xen-staging-4.6/extras/mini-os/include/x86/x86_64 -c > console/xenbus.c -o > /usr/src/xen-staging-4.6/stubdom/mini-os-x86_64-grub/console/xenbus.o > ld -r -d -nostdlib > -L/usr/src/xen-staging-4.6/stubdom/cross-root-x86_64/x86_64-xen- > elf/lib > -m elf_x86_64 -\( /usr/src/xen-staging-4.6/stubdom/grub- > x86_64/main.a > app.lds -\) -L/usr/src/xen-staging-4.6/stubdom/libs-x86_64/toollog > -whole-archive -lxentoollog -no-whole-archive > -L/usr/src/xen-staging-4.6/stubdom/libs-x86_64/evtchn -whole-archive > -lxenevtchn -no-whole-archive > -L/usr/src/xen-staging-4.6/stubdom/libs-x86_64/gnttab -whole-archive > -lxengnttab -no-whole-archive > -L/usr/src/xen-staging-4.6/stubdom/libs-x86_64/call -whole-archive > -lxencall -no-whole-archive > -L/usr/src/xen-staging-4.6/stubdom/libs-x86_64/foreignmemory > -whole-archive -lxenforeignmemory -no-whole-archive > -L/usr/src/xen-staging-4.6/stubdom/libxc-x86_64 -whole-archive > -lxenguest -lxenctrl -no-whole-a
Re: [Xen-devel] [PATCH v13 00/26] COarse-grain LOck-stepping Virtual Machines for Non-stop Service
Changlong Xie writes ("Re: [PATCH v13 00/26] COarse-grain LOck-stepping Virtual
Machines for Non-stop Service"):
> On 03/25/2016 11:51 PM, Wei Liu wrote:
> > I went over those unacked patches. The major thing I found is that you
> > didn't add in the warning text as Ian suggested. I've pointed out one
> > instance where you should add that. However, xl manage and libxl header
> > file changes are spread across multiple commits, so I'm not quite sure
> > which particular commit you should add in warning text.
> >
>
> https://github.com/Pating/xen/tree/changlox/colo_v13_fixup
>
> I just update p20, p23, p26 as Ian suggested
Oh, hi, thanks, I see our emails have crossed. Thanks for confirming
that colo_v13_fixup is what I should be looking at.
Please see my other email in response to 00/26.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13 00/26] COarse-grain LOck-stepping Virtual Machines for Non-stop Service
Changlong Xie writes ("[PATCH v13 00/26] COarse-grain LOck-stepping Virtual
Machines for Non-stop Service"):
> This patchset implemented the COLO feature for Xen.
> For detail/install/use of COLO feature, refer to:
> http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
>
> You can get the codes from here:
> https://github.com/Pating/xen/tree/changlox/colo_v13
I fetched the branches `colo_v13' and `colo_v13_fixup' and it seems
that I can get the proper versions of v13.1 from the latter. I have
acked them accordingly.
Can you confirm that that branch is what you intend for upstream ?
If so, I have a question about it:
There are two patches in it which have not been posted as part of your
series and are marked as "[DO NOT MERGE]". (Thanks for your admirably
clear marking, btw.)
They are
[DONT MERGE] don't create default ioreq server
[DONT MERGE] tools/libxc: support to resume uncooperative HVM guests
The latter patch "support to resume uncooperative HVM guests" seems to
have been posted a number of times and AFAICT most recently as
[PATCH v8 05/13] tools/libxc: support to resume uncooperative HVM guests
on the 18th of February.
Is that not required for COLO ? We need to sort this out, I think.
What is the status of the default ioreq server patch ? Why is it in
your git branch ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] blktap2: Invalid logic detecting unaligned buffers in vhd_write_block
On 03/29/2016 07:26 AM, George Dunlap wrote: > On Fri, Mar 25, 2016 at 4:34 PM, Ross Philipson > wrote: >> On 03/25/2016 12:11 PM, Wei Liu wrote: >>> On Thu, Mar 17, 2016 at 06:10:59PM -0400, Ross Philipson wrote: It seems the logic is meant to detect sector unaligned buffers for block writes. The NOTing of the logic instead masks off any unaligned bits and also would cause the function to always fail. It seems the function is not used in any of the tools so that is probably why the problem is not seen. In the vhd_read_block function it is correct. Signed-off-by: Ross Philipson >>> >>> This seems to fall under tools umbrella. I've look at blktap2 code, >>> the reasoning is convincing to me so: >>> >>> Acked-by: Wei Liu >>> >>> But I've never used blktap2 and we don't normally test it so I would >>> also wait a bit longer to see if anybody objects to this change. >>> >>> OOI if no code was using this, how did you discover this problem? >> >> We have an old fork of blktap2 from way back when. I was working to extract >> our >> changes and turn them into patches so we could rebase on upstream blktap2. >> Someone long ago found that - I have no idea how but it was a valid fix so I >> upstreamed it. >> >> There are a number of other ones that were found that are still in upstream >> blktap2 - I plan to send them too. > > Ross, > > Instead of cross-porting fixes from XenServer's blktap3 to the > bitrotting blktap2, would you consider taking up my work on replacing > blktap2 with building blktap3 as an external project? George, sorry I had to sort out some red tape before I could reply. For the record I am not cross porting from blktap3 but upstreaming from a very old fork of blktap2 that came from XenServer. But really that is of little concern because I think your idea is a really good one. Yes I would be up for taking on that work and we would very much like to re-base our project on blktap3 too. I cannot give you an exact date when I would start on it but probably I could start at the beginning of May. In the mean time I will spend time familiarizing myself with blktap3 and I will probably have some question for you too... Thanks > > The basic shape of things that need to happen for that are: > > 1. Allow qemu to provide emulated devices for disks which use hotplug > scripts (just checked in last week) > > 2. Do the tweaks necessary to allow blktap3 to be built as an > independent project (outside the XenServer build system) > > 3. Switch libxl to use the already-in-tree block-tap script (which > calls tapctl) rather than linking against the blktap library. > > 4. Add a blktap target to raisin. > > #1 is done and was just checked in last week. #2 shouldn't be a > terribly large amount of work. For #3, I've posted patches already, > and I can probably do a quick rebase for you to pick up if you wanted. > #4 shouldn't be too hard once you have an out-of-tree build working; I > can help with that as well. > > If we then add tests for upstream blktap to osstest, then we'll catch > any breakages, and automatically get updates; and we can delete the > bitrotting blktap2 out of the tree. > > What do you think? > > -George > -- Ross Philipson ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13.1 23/26] COLO nic: implement COLO nic subkind
Ian Jackson writes ("Re: [PATCH v13.1 23/26] COLO nic: implement COLO nic
subkind"):
Sorry, this mail was unclear. I meant to refer to this:
> Changlong Xie writes ("[PATCH v13.1 23/26] COLO nic: implement COLO nic
> subkind"):
> > From 699f20d46fcce0bcce8fd7f7063551088a425254 Mon Sep 17 00:00:00 2001
> > From: Wen Congyang
> > Date: Wed, 15 Jul 2015 17:18:53 +0800
> > Subject: [PATCH v13.1 23/26] COLO nic: implement COLO nic subkind
> >
> > implement COLO nic subkind.
The reference to this:
> > Subject: [PATCH v13.1 20/26] Support colo mode for qemu disk
is a c&p mistake.
> I found a proper copy of this in:
> https://github.com/Pating/xen.git#c8284df4eb79
>
> That commit is
>
> Acked-by: Ian Jackson
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13.1 20/26] Support colo mode for qemu disk
Changlong Xie writes ("[PATCH v13.1 20/26] Support colo mode for qemu disk"):
> From 468ff9fb2f6699314c28f30a7d7d09eac9aa6756 Mon Sep 17 00:00:00 2001
> From: Wen Congyang
> Date: Mon, 21 Mar 2016 15:38:30 +0800
> Subject: [PATCH v13.1 20/26] Support colo mode for qemu disk
I found a proper copy of this in:
https://github.com/Pating/xen.git#b226be1b0751
That commit is
Acked-by: Ian Jackson
Ian.
From b226be1b0751d675dcd604c4a1dbeec5757bb051 Mon Sep 17 00:00:00 2001
From: Wen Congyang
Date: Mon, 21 Mar 2016 15:38:30 +0800
Subject: [PATCH 21/28] Support colo mode for qemu disk
Usage: disk =
['...,colo,colo-host=xxx,colo-port=xxx,colo-export=xxx,active-disk=xxx,hidden-disk=xxx...']
For QEMU block replication details:
http://wiki.qemu.org/Features/BlockReplication
Note: we just introduce COLO framework, but don't implement COLO
operations in this patch.
Signed-off-by: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Changlong Xie
---
docs/man/xl.pod.1 | 41 +++--
docs/misc/xl-disk-configuration.txt | 55 +
tools/libxl/libxl.c | 51 +++-
tools/libxl/libxl_create.c | 26 +++-
tools/libxl/libxl_device.c | 11
tools/libxl/libxl_dm.c | 113 ++-
tools/libxl/libxl_types.idl |9 +++
tools/libxl/libxlu_disk_l.l | 19 ++
8 files changed, 317 insertions(+), 8 deletions(-)
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index a992a45..2664402 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -450,12 +450,43 @@ Print huge (!) amount of debug during the migration
process.
Enable Remus HA or COLO HA for domain. By default B relies on ssh as a
transport mechanism between the two hosts.
-N.B: Remus support in xl is still in experimental (proof-of-concept) phase.
- Disk replication support is limited to DRBD disks.
+B
+
+=over 4
+
+Remus support in xl is still in experimental (proof-of-concept) phase.
+Disk replication support is limited to DRBD disks.
+
+COLO support in xl is still in experimental (proof-of-concept) phase.
+There is no support for network, so the guest will confuse its network
+peers at the moment.
- COLO support in xl is still in experimental (proof-of-concept) phase.
- There is no support for network or disk, so the guest will corrupt its
- disk and confuse its network peers at the moment.
+=back
+
+B
+
+=over 4
+
+(a) An example for COLO replication's configuration: disk =['...,colo,colo-host
+=xxx,colo-port=xxx,colo-export=xxx,active-disk=xxx,hidden-disk=xxx...']
+
+=item B :Secondary host's ip address.
+
+=item B :Secondary host's port, we will run a nbd server on
+secondary host, and the nbd server will listen this port.
+
+=item B:Nbd server's disk export name of secondary host.
+
+=item B:Secondary's guest write will be buffered in this disk,
+and it's used by secondary.
+
+=item B:Primary's modified contents will be buffered in this
+disk, and it's used by secondary.
+
+Note that the COLO configuration settings should be considered unstable. They
+may change incompatibly in future versions of Xen.
+
+=back
B
diff --git a/docs/misc/xl-disk-configuration.txt
b/docs/misc/xl-disk-configuration.txt
index 29f6ddb..b3402bc 100644
--- a/docs/misc/xl-disk-configuration.txt
+++ b/docs/misc/xl-disk-configuration.txt
@@ -234,6 +234,61 @@ were intentionally created non-sparse to avoid
fragmentation of the
file.
+===
+COLO PARAMETERS
+===
+
+
+colo
+
+
+Enable COLO HA for disk. For better understanding block replication on
+QEMU, please refer to:
+http://wiki.qemu.org/Features/BlockReplication
+Note that the COLO configuration settings should be considered unstable.
+They may change incompatibly in future versions of Xen.
+
+
+colo-host
+-
+
+Description: Secondary host's address
+Mandatory: Yes when COLO enabled
+
+
+colo-port
+-
+
+Description: Secondary port
+ We will run a nbd server on secondary host,
+ and the nbd server will listen this port.
+Mandatory: Yes when COLO enabled
+
+
+colo-export
+---
+
+Description: We will run a nbd server on secondary host,
+ exportname is the nbd server's disk export name.
+Mandatory: Yes when COLO enabled
+
+
+active-disk
+---
+
+Description: This is used by secondary. Secondary guest's write
+ will be buffered in this disk.
+Mandatory: Yes when COLO enabled
+
+
+hidden-disk
+---
+
+Description: This is used by secondary. It buffers the original
+ content that is modified by the primary VM.
+Mandatory: Yes when COLO enabled
+
+
DEPRECATED PARAMETERS, PREFIXES AND SYNTAXES
===
Re: [Xen-devel] [PATCH v3 5/4] x86: reduce code size of struct cpu_info member accesses
>>> On 30.03.16 at 16:28, wrote: > On Tue, Mar 29, 2016 at 12:59:24AM -0600, Jan Beulich wrote: >> >>> On 25.03.16 at 19:47, wrote: >> > On Thu, Mar 17, 2016 at 10:14:22AM -0600, Jan Beulich wrote: >> > >> > Something is off with your patch. This is 5/4 :-) >> >> Well, yes - this got added later on top of the previously sent series, >> to make the dependency obvious. >> >> >> Instead of addressing these fields via the base of the stack (which >> >> uniformly requires 4-byte displacements), address them from the end >> >> (which for everything other than guest_cpu_user_regs requires just >> >> 1-byte ones). This yields a code size reduction somewhere between 8k >> >> and 12k in my builds. >> > >> > Also you made the macro a bit different - the %r is removed. >> > >> > Particular reason? >> >> This is an integral part of the change, so the macro can derive >> e.g. both %eax and %rax from the passed argument > > Could you pls include that explanation in the commit description.. > > And with that you can put Reviewed-by: Konrad Rzeszutek Wilk > > > on the patch. Well, I've got one of these already, without having been asked to do any adjustments. Did I mis-interpret <20160325184701.ge20...@char.us.oracle.com>? As to adding something like this to the commit message: I have a hard time seeing how this would belong there. The fact _that_ this is being done is very obvious from the patch itself, and once the reader has spotted this the fact _why_ this is needed then should become immediately obvious too. I'm all for explaining technically difficult or hard to see things, but I'm against needless bloat. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13.1 26/26] cmdline switches and config vars to control colo-proxy
Changlong Xie writes ("[PATCH v13.1 26/26] cmdline switches and config vars to
control colo-proxy"):
> From 1bfd14622455635c6cae6130396250996e49facc Mon Sep 17 00:00:00 2001
> From: Wen Congyang
> Date: Wed, 15 Jul 2015 17:18:56 +0800
> Subject: [PATCH v13.1 26/26] cmdline switches and config vars to control
> colo-proxy
I found a proper copy of this in:
https://github.com/Pating/xen.git#27e64fe8a495
That commit is
Acked-by: Ian Jackson
Ian.
From 27e64fe8a4954b5a5628696160471f89a9e6ae6e Mon Sep 17 00:00:00 2001
From: Wen Congyang
Date: Wed, 15 Jul 2015 17:18:56 +0800
Subject: [PATCH 27/28] cmdline switches and config vars to control colo-proxy
Add cmdline switches to 'xl migrate-receive' command to specify
a domain-specific hotplug script to setup COLO proxy.
Add a new config var 'colo.default.agentscript' to xl.conf, that
allows the user to override the default global script used to
setup COLO proxy.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
docs/man/xl.conf.pod.5 |6 +
docs/man/xl.pod.1|7 --
tools/libxl/libxl.c |6 +
tools/libxl/libxl_colo_restore.c |5
tools/libxl/libxl_create.c |9 ++--
tools/libxl/libxl_types.idl |1 +
tools/libxl/xl.c |3 +++
tools/libxl/xl.h |1 +
tools/libxl/xl_cmdimpl.c | 47 ++
9 files changed, 71 insertions(+), 14 deletions(-)
diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 8ae19bb..8f7fd28 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -111,6 +111,12 @@ Configures the default script used by Remus to setup
network buffering.
Default: C
+=item B
+
+Configures the default script used by COLO to setup colo-proxy.
+
+Default: C
+
=item B
Configures the default output format used by xl when printing "machine
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 2664402..9df3302 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -458,8 +458,6 @@ Remus support in xl is still in experimental
(proof-of-concept) phase.
Disk replication support is limited to DRBD disks.
COLO support in xl is still in experimental (proof-of-concept) phase.
-There is no support for network, so the guest will confuse its network
-peers at the moment.
=back
@@ -483,6 +481,11 @@ and it's used by secondary.
=item B:Primary's modified contents will be buffered in this
disk, and it's used by secondary.
+(b) An example for COLO network configuration: vif =[ '...,forwarddev=xxx,...']
+
+=item B :Forward devices for primary and secondary, there are
+directly connected.
+
Note that the COLO configuration settings should be considered unstable. They
may change incompatibly in future versions of Xen.
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 63fbe16..aabf3a7 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3378,6 +3378,11 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t
domid,
flexarray_append(back, nic->ifname);
}
+if (nic->coloft_forwarddev) {
+flexarray_append(back, "forwarddev");
+flexarray_append(back, nic->coloft_forwarddev);
+}
+
flexarray_append(back, "mac");
flexarray_append(back,GCSPRINTF(LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
if (nic->ip) {
@@ -3500,6 +3505,7 @@ static int libxl__device_nic_from_xs_be(libxl__gc *gc,
nic->ip = READ_BACKEND(NOGC, "ip");
nic->bridge = READ_BACKEND(NOGC, "bridge");
nic->script = READ_BACKEND(NOGC, "script");
+nic->coloft_forwarddev = READ_BACKEND(NOGC, "forwarddev");
/* vif_ioemu nics use the same xenstore entries as vif interfaces */
tmp = READ_BACKEND(gc, "type");
diff --git a/tools/libxl/libxl_colo_restore.c b/tools/libxl/libxl_colo_restore.c
index c8ad796..3483f39 100644
--- a/tools/libxl/libxl_colo_restore.c
+++ b/tools/libxl/libxl_colo_restore.c
@@ -233,6 +233,11 @@ void libxl__colo_restore_setup(libxl__egc *egc,
crcs->crs = crs;
crs->qdisk_setuped = false;
crs->qdisk_used = false;
+if (dcs->colo_proxy_script)
+crs->colo_proxy_script = libxl__strdup(gc, dcs->colo_proxy_script);
+else
+crs->colo_proxy_script = GCSPRINTF("%s/colo-proxy-setup",
+ libxl__xen_script_dir_path());
/* setup dsps */
crcs->dsps.ao = ao;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e2ec25c..d6028aa 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1690,6 +1690,7 @@ static void domain_create_cb(libxl__egc *egc,
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,
