[Xen-devel] [RFC PATCH 13/17] xenconsoled: add support for up to 3 secondary consoles
Based on previous few commits, this adds basic support for multiple
consoles in xenconsoled. A static number of them - up to 3 (+ one
primary).
---
I know this is awful, but everything else I can think of (real support
for multiple consoles, dynamically allocated) requires major restructure
of the code. Given I'm still not sure if multiple consoles are the way
to go with stubdomain, I'd rather not invest time in something that
could never by actually useful.
---
tools/console/daemon/io.c | 24
1 file changed, 24 insertions(+)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 2cf71a0..7761c60 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -133,6 +133,30 @@ static struct console_type console_type[] = {
.use_gnttab = true,
.use_reserved_gnttab = true,
},
+ {
+ .xsname = "/device/console/1",
+ .ttyname = "tty",
+ .log_suffix = "-con1",
+ .optional = true,
+ .use_gnttab = true,
+ .have_state = true,
+ },
+ {
+ .xsname = "/device/console/2",
+ .ttyname = "tty",
+ .log_suffix = "-con2",
+ .optional = true,
+ .use_gnttab = true,
+ .have_state = true,
+ },
+ {
+ .xsname = "/device/console/3",
+ .ttyname = "tty",
+ .log_suffix = "-con3",
+ .optional = true,
+ .use_gnttab = true,
+ .have_state = true,
+ },
#if defined(CONFIG_ARM)
{
.xsname = "/vuart/0",
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH 12/17] xenconsoled: make console_type->use_gnttab less confusing
Before this commit 'use_gnttab' means xenconsoled should first try
special GNTTAB_RESERVED_CONSOLE entry, and only then fallback to
ring-ref xenstore entry (being gfn of actual ring).
In case of secondary consoles, ring-ref entry contains grant table
reference (not gfn of it), which makes the old meaning of use_gnttab
really confusing (should be false for such consoles).
To solve this, add new entry in console_type (and console) structures
named 'use_reserverd_gnttab' with the old meaning of 'use_gnttab', then
use 'ues_gnttab' for consoles where ring-ref holds grant table
reference.
---
tools/console/daemon/io.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 92c3dff..2cf71a0 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -110,6 +110,7 @@ struct console {
struct domain *d;
bool optional;
bool use_gnttab;
+ bool use_reserved_gnttab;
bool have_state;
};
@@ -119,6 +120,7 @@ struct console_type {
char *log_suffix;
bool optional;
bool use_gnttab;
+ bool use_reserved_gnttab;
bool have_state; // uses 'state' xenstore entry
};
@@ -129,6 +131,7 @@ static struct console_type console_type[] = {
.log_suffix = "",
.optional = false,
.use_gnttab = true,
+ .use_reserved_gnttab = true,
},
#if defined(CONFIG_ARM)
{
@@ -670,7 +673,7 @@ static void console_unmap_interface(struct console *con)
{
if (con->interface == NULL)
return;
- if (xgt_handle && con->ring_ref == -1)
+ if (xgt_handle && con->use_gnttab)
xengnttab_unmap(xgt_handle, con->interface, 1);
else
munmap(con->interface, XC_PAGE_SIZE);
@@ -714,12 +717,19 @@ static int console_create_ring(struct console *con)
if (!con->interface && xgt_handle && con->use_gnttab) {
/* Prefer using grant table */
- con->interface = xengnttab_map_grant_ref(xgt_handle,
- dom->domid, GNTTAB_RESERVED_CONSOLE,
- PROT_READ|PROT_WRITE);
- con->ring_ref = -1;
+ if (con->use_reserved_gnttab) {
+ con->interface = xengnttab_map_grant_ref(xgt_handle,
+ dom->domid, GNTTAB_RESERVED_CONSOLE,
+ PROT_READ|PROT_WRITE);
+ con->ring_ref = -1;
+ } else {
+ con->interface = xengnttab_map_grant_ref(xgt_handle,
+ dom->domid, ring_ref,
+ PROT_READ|PROT_WRITE);
+ con->ring_ref = ring_ref;
+ }
}
- if (!con->interface) {
+ if (!con->interface && (!con->use_gnttab || con->use_reserved_gnttab)) {
/* Fall back to xc_map_foreign_range */
con->interface = xc_map_foreign_range(
xc, dom->domid, XC_PAGE_SIZE,
@@ -893,6 +903,7 @@ static int console_init(struct console *con, struct domain
*dom, void **data)
con->log_suffix = (*con_type)->log_suffix;
con->optional = (*con_type)->optional;
con->use_gnttab = (*con_type)->use_gnttab;
+ con->use_reserved_gnttab = (*con_type)->use_reserved_gnttab;
con->have_state = (*con_type)->have_state;
xsname = (char *)(*con_type)->xsname;
xspath = xs_get_domain_path(xs, dom->domid);
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH 11/17] xenconsoled: add support for consoles using 'state' xenstore entry
Add support for standard xenbus initialization protocol using 'state'
xenstore entry. It will be necessary for secondary consoles.
For consoles supporting it, read 'state' entry on the frontend and
proceed accordingly - either init console or close it. When closing,
make sure all the in-transit data is flushed (both from shared ring and
from local buffer), if possible. This is especially important for
MiniOS-based qemu stubdomain, which closes console just after writing
device model state to it.
For consoles without 'state' field behavior is unchanged - on any watch
event try to connect console, as long as domain is alive.
---
tools/console/daemon/io.c | 86 ++--
1 file changed, 83 insertions(+), 3 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 8aae87d..92c3dff 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -109,6 +110,7 @@ struct console {
struct domain *d;
bool optional;
bool use_gnttab;
+ bool have_state;
};
struct console_type {
@@ -117,6 +119,7 @@ struct console_type {
char *log_suffix;
bool optional;
bool use_gnttab;
+ bool have_state; // uses 'state' xenstore entry
};
static struct console_type console_type[] = {
@@ -156,6 +159,8 @@ typedef void (*VOID_ITER_FUNC_ARG2)(struct console *, void
*);
typedef int (*INT_ITER_FUNC_ARG3)(struct console *,
struct domain *dom, void **);
+static void handle_tty_write(struct console *con);
+
static inline bool console_enabled(struct console *con)
{
return con->local_port != -1;
@@ -647,6 +652,20 @@ static int xs_gather(struct xs_handle *xs, const char
*dir, ...)
return ret;
}
+static void set_backend_state(struct console *con, int state)
+{
+ char path[PATH_MAX], state_str[2], *be_path;
+
+ snprintf(state_str, sizeof(state_str), "%d", state);
+ snprintf(path, sizeof(path), "%s/backend", con->xspath);
+ be_path = xs_read(xs, XBT_NULL, path, NULL);
+ if (be_path) {
+ snprintf(path, sizeof(path), "%s/state", be_path);
+ xs_write(xs, XBT_NULL, path, state_str, 1);
+ free(be_path);
+ }
+}
+
static void console_unmap_interface(struct console *con)
{
if (con->interface == NULL)
@@ -658,7 +677,7 @@ static void console_unmap_interface(struct console *con)
con->interface = NULL;
con->ring_ref = -1;
}
-
+
static int console_create_ring(struct console *con)
{
int err, remote_port, ring_ref, rc;
@@ -762,10 +781,70 @@ static int console_create_ring(struct console *con)
if (log_guest && (con->log_fd == -1))
con->log_fd = create_console_log(con);
+ /* if everything ok, signal backend readiness, in backend tree */
+ set_backend_state(con, XenbusStateConnected);
+
out:
return err;
}
+/* gracefully close console */
+static int console_close(struct console *con) {
+
+ if (con->interface && con->master_fd != -1 && con->buffer.data) {
+ /* handle remaining data in buffers */
+ buffer_append(con);
+
+ /* write it out, if possible */
+ if (con->master_pollfd_idx != -1) {
+ if (fds[con->master_pollfd_idx].revents &
+ POLLOUT)
+ handle_tty_write(con);
+ }
+ }
+
+ console_close_tty(con);
+ console_unmap_interface(con);
+ set_backend_state(con, XenbusStateClosed);
+
+ return 0;
+}
+
+
+static int handle_console_state(struct console *con) {
+ int err, state;
+
+ if (!con->have_state)
+ return console_create_ring(con);
+
+ err = xs_gather(xs, con->xspath,
+ "state", "%u", ,
+ NULL);
+ if (err)
+ /* no 'state' entry, assume removal */
+ state = XenbusStateClosed;
+
+ switch (state) {
+ case XenbusStateInitialising:
+ case XenbusStateInitWait:
+ /* wait for frontent init */
+ return 0;
+ case XenbusStateInitialised:
+ case XenbusStateConnected:
+ /* ok, init backend (also on restart) */
+ return console_create_ring(con);
+ case XenbusStateClosing:
+ case XenbusStateClosed:
+ /* close requested */
+ return console_close(con);
+ default:
+ dolog(LOG_ERR,
+ "Invalid state %d set by console %s of domain
%d\n",
+ state, con->xspath, con->d->domid);
+ return 1;
+ }
+}
+
static int
[Xen-devel] [RFC PATCH 02/17] libxl: Add "stubdomain_version" to domain_build_info.
From: Eric Shelton
This enum gives the ability to select between a MiniOS-based QEMU
traditional stub domain and a Linux-based QEMU upstream stub domain. To
use the Linux-based stubdomain, the following two lines should be
included in the appropriate xl.cfg file:
device_model_version="qemu-xen"
device_model_stubdomain_override=1
To use the MiniOS-based stubdomain, the following is used instead:
device_model_version="qemu-xen-traditional"
device_model_stubdomain_override=1
Signed-off-by: Eric Shelton
---
tools/libxl/libxl_create.c | 34 +-
tools/libxl/libxl_types.idl | 7 +++
2 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 7d46824..9f5e6b7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -159,12 +159,36 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
}
if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
-b_info->device_model_version !=
-LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
libxl_defbool_val(b_info->device_model_stubdomain)) {
-LOG(ERROR,
-"device model stubdomains require \"qemu-xen-traditional\"");
-return ERROR_INVAL;
+if (!b_info->stubdomain_version) {
+switch (b_info->device_model_version) {
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+b_info->stubdomain_version = LIBXL_STUBDOMAIN_VERSION_MINIOS;
+break;
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+b_info->stubdomain_version = LIBXL_STUBDOMAIN_VERSION_LINUX;
+break;
+default: abort();
+}
+}
+
+switch (b_info->device_model_version) {
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+if (b_info->stubdomain_version != LIBXL_STUBDOMAIN_VERSION_MINIOS)
{
+LOG(ERROR,
+"\"qemu-xen-traditional\" require \"minios\" as
stubdomain");
+return ERROR_INVAL;
+}
+break;
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+if (b_info->stubdomain_version != LIBXL_STUBDOMAIN_VERSION_LINUX) {
+LOG(ERROR,
+"\"qemu-xen\" require \"linux\" as stubdomain");
+return ERROR_INVAL;
+}
+break;
+default: abort();
+}
}
if (!b_info->max_vcpus)
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f1e50a0..946c5b5 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -101,6 +101,12 @@ libxl_device_model_version =
Enumeration("device_model_version", [
(2, "QEMU_XEN"), # Upstream based qemu-xen device model
])
+# Give the kernel running in the stub-domain
+libxl_stubdomain_version = Enumeration("stubdomain_version", [
+(1, "MINIOS"),
+(2, "LINUX"),
+])
+
libxl_console_type = Enumeration("console_type", [
(0, "UNKNOWN"),
(1, "SERIAL"),
@@ -485,6 +491,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("device_model_version", libxl_device_model_version),
("device_model_stubdomain", libxl_defbool),
+("stubdomain_version", libxl_stubdomain_version),
# if you set device_model you must set device_model_version too
("device_model", string),
("device_model_ssidref", uint32),
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain.
General idea is to allow freely set device_model_version and device_model_stubdomain_override and choose the right options based on this choice. Also, allow to specific path to stubdomain kernel/ramdisk, for greater flexibility. Right now when qemu-xen in stubdomain is selected, it is assumed it's Linux-based and few decisions are based on it, specifically: - qemu args encoding (\x1b as separator, to allow spaces in arguments) - save/restore stream access (specific FDs passed to qemu by a wrapper script) - QMP access, if any It may be a good idea to document "stubdomain API" somewhere. Is there such document for MiniOS one? Here is an initial version for Linux one: Assumptions about Linux-based stubdomain for qemu-xen: * qemu command line is stored by toolstack in /vm//image/dmargs xenstore entry, arguments are separated with \x1b character * qemu can access saved state (if any) at its FD 3 * qemu can write its state (for save/migration) to its FD 4 * qemu expects backend for serial console at /dev/hvc3 * disks configured for the target are available as /dev/xvd*, in configuration order * qemu can call /etc/qemu-ifup and /etc/qemu-ifdown to connect/disconnect network interface to appropriate network Initial version has no QMP support - in initial patches it is completely disabled, which means no suspend/restore. QMP normally would be used for PCI passthrough setup, but it is worked around with MiniOS-like control protocol over xenstore, which then is translated to QMP on stubdomain side. Some option is to use separate console for that, but that require xenstoled supporting multiple consoles per domain (the goal is to not have qemu in dom0 at all). Also, it would be preferable to evaluate how libxl handle potentially malicious QMP responses. Another option is to use xenstore - either translate everything needed to MiniOS-like thing, or write already json-formatted requests to xenstore and watch there for responses. When using separate xenstore dir for that, with per-command entries (command id as a key name?) that would solve concurrency problem. QMP support over separate console: patch "libxl: access QMP socket via console for qemu-in-stubdomain" implements some early PoC of this. Major limitation: only one connection at a time and no means of out of band reset (and re-negotiate). I've tried adding very simple `qmp_reset` command for in-band connection reset, but it is unreliable because of the first limitation - xl process running in background hold this connection open and every other xl instance interfere with it. On the other hand, for libvirt use case one connection could be enough (leaving alone libvirtd restart). Xenconsoled patches add support for multiple consoles in xenconsoled, to avoid the need for qemu in dom0 for this to work. Multiple consoles for a stubdomain are used for: - logs (console 0) - save + restore (console 1, 2) - qmp (console 3) - serial terminal to target domU (console 4) Xenconsoled patches are in fact a separate series, but I'm sending them here to ease dependencies handling (latter libxl patches use that). What qmp-libxenstat socket is for? PCI passthrough support require some more love. Right now, libxl tries to setup pcifront for both target HVM and stubdomain and the former fails (race condition): xen-pciback pci-259-0: 22 Couldn't locate PCI device (:00:1b.0)! perhaps already in-use? Fortunately it isn't needed. There is also a PCI related problem on domain shutdown - it looks like first stubdomain is paused and then libxl waits for pcifront there. Also, MSI doesn't work (qemu output): [00:05.0] xen_pt_msgctrl_reg_write: setup MSI (register: 81). [00:05.0] msi_msix_setup: requested pirq 55 for MSI (vec: 0, entry: 0) [00:05.0] msi_msix_setup: Error: Mapping of MSI (err: 1, vec: 0, entry 0) [00:05.0] xen_pt_msgctrl_reg_write: Warning: Can not map MSI (register: 80)! [00:05.0] Write-back to unknown field 0x44 (partially) inhibited (0x00) [00:05.0] If the device doesn't work, try enabling permissive mode [00:05.0] (unsafe) and if it helps report the problem to xen-devel The actual stubdomain implementation is here: https://github.com/marmarek/qubes-vmm-xen-stubdom-linux (branch for-upstream) See readme there for build instructions. Remaining parts for eliminating dom0's instance of qemu: - do not force QDISK backend for CDROM This patch series is third (fourth?) attempt to get rid of limitation "if you want to use stubdomain, you're stuck with qemu-traditional", done over years, by many people. I think it should be acceptable plan to gradually add features to qemu-xen+stubdomain configuration - not necessary waiting with committing any of those patches until full feature set of qemu-xen is supported. After all, right now "feature set supported by qemu-xen+stubdom" is empty, so wouldn't be worse. Cc: Simon Gaiser Cc: Eric Shelton Cc: Ian Jackson Cc: Wei
[Xen-devel] [RFC PATCH 09/17] libxl: use \x1b to separate qemu arguments for linux stubdomain
This allows using arguments with spaces, like -append.
Stubdomain side of this require "xenstore-client: Add option for raw
in-/output" commit.
---
tools/libxl/libxl_dm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index f6bd6a1..11acbea 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1844,6 +1844,7 @@ static int libxl__write_stub_dmargs(libxl__gc *gc,
int i;
char *vm_path;
char *dmargs, *path;
+const char arg_sep = linux_stubdom ? '\x1b' : ' ';
int dmargs_size;
struct xs_permissions roperm[2];
xs_transaction_t t;
@@ -1869,8 +1870,9 @@ static int libxl__write_stub_dmargs(libxl__gc *gc,
if (linux_stubdom ||
(strcmp(args[i], "-sdl") &&
strcmp(args[i], "-M") && strcmp(args[i], "xenfv"))) {
-strcat(dmargs, " ");
strcat(dmargs, args[i]);
+if (args[i + 1] != NULL)
+strncat(dmargs, _sep, 1);
}
i++;
}
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH 04/17] libxl: Build the domain with a Linux based stubdomain
From: Eric Shelton
This will build a Linux-based stubdomain with QEMU upstream.
Signed-off-by: Eric Shelton
Simon:
* use initramfs instead of disk with rootfs
* don't initialize qmp (unused in Qubes)
* Make libxl_domain_need_memory consistent with actual stubdoma build
code (bugfix relevant also for non-linux case)
* Make stubdomain memory size configurable
Signed-off-by: Simon Gaiser
Marek:
* Make kernel and ramdisk paths configurable.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/libxl/libxl_create.c | 75 +++--
tools/libxl/libxl_dm.c | 48 ++--
tools/libxl/libxl_internal.c | 22 +++-
tools/libxl/libxl_internal.h | 4 ++-
tools/libxl/libxl_mem.c | 6 ++-
tools/libxl/libxl_types.idl | 3 +-
6 files changed, 126 insertions(+), 32 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 9f5e6b7..fff1f9c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -162,32 +162,54 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
libxl_defbool_val(b_info->device_model_stubdomain)) {
if (!b_info->stubdomain_version) {
switch (b_info->device_model_version) {
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+b_info->stubdomain_version =
LIBXL_STUBDOMAIN_VERSION_MINIOS;
+break;
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+b_info->stubdomain_version =
LIBXL_STUBDOMAIN_VERSION_LINUX;
+break;
+default: abort();
+}
+}
+
+switch (b_info->device_model_version) {
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-b_info->stubdomain_version = LIBXL_STUBDOMAIN_VERSION_MINIOS;
+if (b_info->stubdomain_version !=
LIBXL_STUBDOMAIN_VERSION_MINIOS) {
+LOG(ERROR,
+"\"qemu-xen-traditional\" require \"minios\" as
stubdomain");
+return ERROR_INVAL;
+}
break;
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-b_info->stubdomain_version = LIBXL_STUBDOMAIN_VERSION_LINUX;
+if (b_info->stubdomain_version !=
LIBXL_STUBDOMAIN_VERSION_LINUX) {
+LOG(ERROR,
+"\"qemu-xen\" require \"linux\" as stubdomain");
+return ERROR_INVAL;
+}
break;
default: abort();
-}
}
-switch (b_info->device_model_version) {
-case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-if (b_info->stubdomain_version != LIBXL_STUBDOMAIN_VERSION_MINIOS)
{
-LOG(ERROR,
-"\"qemu-xen-traditional\" require \"minios\" as
stubdomain");
-return ERROR_INVAL;
+if (!b_info->stubdomain_kernel) {
+switch (b_info->stubdomain_version) {
+case LIBXL_STUBDOMAIN_VERSION_MINIOS:
+b_info->stubdomain_kernel =
+libxl__abs_path(NOGC, "ioemu-stubdom.gz",
libxl__xenfirmwaredir_path());
+b_info->stubdomain_ramdisk = NULL;
+break;
+case LIBXL_STUBDOMAIN_VERSION_LINUX:
+b_info->stubdomain_kernel =
+libxl__abs_path(NOGC,
+"stubdom-linux-kernel",
+libxl__xenfirmwaredir_path());
+b_info->stubdomain_ramdisk =
+libxl__abs_path(NOGC,
+"stubdom-linux-rootfs",
+libxl__xenfirmwaredir_path());
+break;
+default:
+abort();
}
-break;
-case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-if (b_info->stubdomain_version != LIBXL_STUBDOMAIN_VERSION_LINUX) {
-LOG(ERROR,
-"\"qemu-xen\" require \"linux\" as stubdomain");
-return ERROR_INVAL;
-}
-break;
-default: abort();
}
}
@@ -226,6 +248,19 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
b_info->target_memkb = b_info->max_memkb;
+if (b_info->stubdomain_memkb == LIBXL_MEMKB_DEFAULT) {
+switch (b_info->stubdomain_version) {
+case LIBXL_STUBDOMAIN_VERSION_MINIOS:
+b_info->stubdomain_memkb = 28 * 1024;
+break;
+case LIBXL_STUBDOMAIN_VERSION_LINUX:
+b_info->stubdomain_memkb = LIBXL_LINUX_STUBDOM_MEM * 1024;;
+break;
+default:
+b_info->stubdomain_memkb = 0; // no stubdomain
+}
+}
+
[Xen-devel] [RFC PATCH 03/17] libxl: Handle Linux stubdomain specific QEMU options.
From: Eric Shelton
This patch creates an appropriate command line for the QEMU instance
running in a Linux-based stubdomain.
NOTE: a number of items are not currently implemented for Linux-based
stubdomains, such as:
- save/restore
- QMP socket
- graphics output (e.g., VNC)
Signed-off-by: Eric Shelton
Simon:
* fix disk path
* fix cdrom path and "format"
* pass downscript for network interfaces
---
tools/libxl/libxl_dm.c | 106 --
1 file changed, 72 insertions(+), 34 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3b0b58e..b38c1d2 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -25,9 +25,24 @@
#include
#include
-static const char *libxl_tapif_script(libxl__gc *gc)
+static const char *libxl_tapif_script(libxl__gc *gc,
+ const libxl_domain_build_info *info)
{
#if defined(__linux__) || defined(__FreeBSD__)
+if (info->stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX)
+return libxl__sprintf(gc, "/etc/qemu-ifup");
+return libxl__strdup(gc, "no");
+#else
+return GCSPRINTF("%s/qemu-ifup", libxl__xen_script_dir_path());
+#endif
+}
+
+static const char *libxl_tapif_downscript(libxl__gc *gc,
+ const libxl_domain_build_info *info)
+{
+#if defined(__linux__) || defined(__FreeBSD__)
+if (info->stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX)
+return libxl__sprintf(gc, "/etc/qemu-ifdown");
return libxl__strdup(gc, "no");
#else
return GCSPRINTF("%s/qemu-ifup", libxl__xen_script_dir_path());
@@ -616,8 +631,8 @@ static int libxl__build_device_model_args_old(libxl__gc *gc,
"tap,vlan=%d,ifname=%s,bridge=%s,"
"script=%s,downscript=%s",
nics[i].devid, ifname, nics[i].bridge,
- libxl_tapif_script(gc),
- libxl_tapif_script(gc)),
+ libxl_tapif_script(gc, b_info),
+ libxl_tapif_downscript(gc, b_info)),
NULL);
ioemu_nics++;
}
@@ -933,6 +948,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
const char *path, *chardev;
char *user = NULL;
struct passwd *user_base, user_pwbuf;
+bool is_stubdom = libxl_defbool_val(b_info->device_model_stubdomain);
dm_args = flexarray_make(gc, 16, 1);
dm_envs = flexarray_make(gc, 16, 1);
@@ -943,24 +959,27 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
"-xen-domid",
GCSPRINTF("%d", guest_domid), NULL);
-flexarray_append(dm_args, "-chardev");
-flexarray_append(dm_args,
- GCSPRINTF("socket,id=libxl-cmd,"
-"path=%s/qmp-libxl-%d,server,nowait",
-libxl__run_dir_path(), guest_domid));
+/* There is currently no way to access the QMP socket in the stubdom */
+if (!is_stubdom) {
+flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args,
+ GCSPRINTF("socket,id=libxl-cmd,"
+"path=%s/qmp-libxl-%d,server,nowait",
+libxl__run_dir_path(), guest_domid));
-flexarray_append(dm_args, "-no-shutdown");
-flexarray_append(dm_args, "-mon");
-flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
+flexarray_append(dm_args, "-no-shutdown");
+flexarray_append(dm_args, "-mon");
+flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
-flexarray_append(dm_args, "-chardev");
-flexarray_append(dm_args,
- GCSPRINTF("socket,id=libxenstat-cmd,"
-"path=%s/qmp-libxenstat-%d,server,nowait",
-libxl__run_dir_path(), guest_domid));
+flexarray_append(dm_args, "-chardev");
+flexarray_append(dm_args,
+ GCSPRINTF("socket,id=libxenstat-cmd,"
+
"path=%s/qmp-libxenstat-%d,server,nowait",
+libxl__run_dir_path(), guest_domid));
-flexarray_append(dm_args, "-mon");
-flexarray_append(dm_args, "chardev=libxenstat-cmd,mode=control");
+flexarray_append(dm_args, "-mon");
+flexarray_append(dm_args, "chardev=libxenstat-cmd,mode=control");
+}
for (i = 0; i < guest_config->num_channels; i++) {
connection = guest_config->channels[i].connection;
@@ -1004,7 +1023,7 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
flexarray_vappend(dm_args, "-name", c_info->name, NULL);
}
-if (vnc) {
+if (vnc && !is_stubdom) {
[Xen-devel] [RFC PATCH 01/17] libxl: fix qemu-trad cmdline for no sdl/vnc case
When qemu is running in stubdomain, any attempt to initialize vnc/sdl
there will crash it (on failed attempt to load a keymap from a file). If
vfb is present, all those cases are skipped. But since
b053f0c4c9e533f3d97837cf897eb920b8355ed3 "libxl: do not start dom0 qemu
for stubdomain when not needed" it is possible to create a stubdomain
without vfb and contrary to the comment -vnc none do trigger VNC
initialization code (just skips exposing it externally).
Change the implicit SDL avoiding method to -nographics option, used when
none of SDL or VNC is enabled.
---
tools/libxl/libxl_dm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bd18746..3b0b58e 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -475,14 +475,14 @@ static int libxl__build_device_model_args_old(libxl__gc
*gc,
if (libxl_defbool_val(vnc->findunused)) {
flexarray_append(dm_args, "-vncunused");
}
-} else
+} else if (!sdl)
/*
* VNC is not enabled by default by qemu-xen-traditional,
- * however passing -vnc none causes SDL to not be
- * (unexpectedly) enabled by default. This is overridden by
- * explicitly passing -sdl below as required.
+ * however skipping -vnc causes SDL to be
+ * (unexpectedly) enabled by default. If undesired, disable graphics at
+ * all.
*/
-flexarray_append_pair(dm_args, "-vnc", "none");
+flexarray_append(dm_args, "-nographics");
if (sdl) {
flexarray_append(dm_args, "-sdl");
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH 07/17] libxl: add save/restore support for qemu-xen in stubdomain
Rely on a wrapper script in stubdomain to attach FD 3/4 of qemu to
relevant consoles.
---
tools/libxl/libxl_dm.c | 23 +++
tools/libxl/libxl_dom_suspend.c | 10 --
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 7828444..f6bd6a1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1444,10 +1444,17 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
flexarray_append(dm_args, "-xen-domid-restrict");
if (state->saved_state) {
-/* This file descriptor is meant to be used by QEMU */
-*dm_state_fd = open(state->saved_state, O_RDONLY);
-flexarray_append(dm_args, "-incoming");
-flexarray_append(dm_args, GCSPRINTF("fd:%d",*dm_state_fd));
+if (is_stubdom) {
+/* Linux stubdomain connects specific FD to STUBDOM_CONSOLE_RESTORE
+ */
+flexarray_append(dm_args, "-incoming");
+flexarray_append(dm_args, "fd:3");
+} else {
+/* This file descriptor is meant to be used by QEMU */
+*dm_state_fd = open(state->saved_state, O_RDONLY);
+flexarray_append(dm_args, "-incoming");
+flexarray_append(dm_args, GCSPRINTF("fd:%d",*dm_state_fd));
+}
}
for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
flexarray_append(dm_args, b_info->extra[i]);
@@ -1929,14 +1936,6 @@ void libxl__spawn_stub_dm(libxl__egc *egc,
libxl__stub_dm_spawn_state *sdss)
assert(libxl_defbool_val(guest_config->b_info.device_model_stubdomain));
-if (guest_config->b_info.stubdomain_version ==
LIBXL_STUBDOMAIN_VERSION_LINUX) {
-if (d_state->saved_state) {
-LOG(ERROR, "Save/Restore not supported yet with Linux Stubdom.");
-ret = -1;
-goto out;
-}
-}
-
sdss->pvqemu.guest_domid = 0;
libxl_domain_create_info_init(_config->c_info);
diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
index 1e904ba..8c8ae84 100644
--- a/tools/libxl/libxl_dom_suspend.c
+++ b/tools/libxl/libxl_dom_suspend.c
@@ -73,7 +73,8 @@ int libxl__domain_suspend_device_model(libxl__gc *gc,
{
int ret = 0;
uint32_t const domid = dsps->domid;
-const char *const filename = dsps->dm_savefile;
+uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
+const char * filename = dsps->dm_savefile;
switch (libxl__device_model_version_running(gc, domid)) {
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
@@ -86,8 +87,13 @@ int libxl__domain_suspend_device_model(libxl__gc *gc,
if (libxl__qmp_stop(gc, domid))
return ERROR_FAIL;
/* Save DM state into filename */
+if (dm_domid) {
+/* if DM is in stubdomain, instruct it to use console, which is
+ * connected to a file pointed by filename */
+filename = "/proc/self/fd/4";
+}
ret = libxl__qmp_save(gc, domid, filename, dsps->live);
-if (ret)
+if (ret && !dm_domid)
unlink(filename);
break;
default:
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH 17/17] libxl: use xenconsoled even for multiple stubdomain's consoles
Since multiple consoles support was added to xenconsoled, use it for
stubdomain. This makes it possible to have HVM without qemu in dom0 at
al. As long as no other feature requiring qemu in dom0 is used, like VNC
or qdisk.
---
tools/libxl/libxl_dm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 062020e..6c9d23e 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2133,7 +2133,9 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
for (i = 0; i < num_console; i++) {
console[i].devid = i;
-console[i].consback = LIBXL__CONSOLE_BACKEND_IOEMU;
+/* will be changed back to LIBXL__CONSOLE_BACKEND_IOEMU if qemu
+ * will be in use */
+console[i].consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
/* STUBDOM_CONSOLE_LOGGING (console 0) is for minios logging
* STUBDOM_CONSOLE_SAVE (console 1) is for writing the save file
* STUBDOM_CONSOLE_RESTORE (console 2) is for reading the save file
@@ -2149,9 +2151,6 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
if (ret) goto out;
console[i].output = GCSPRINTF("file:%s", filename);
free(filename);
-/* will be changed back to LIBXL__CONSOLE_BACKEND_IOEMU if qemu
- * will be in use */
-console[i].consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
break;
case STUBDOM_CONSOLE_SAVE:
console[i].output = GCSPRINTF("file:%s",
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH 05/17] libxl: use xenstore for pci hotplug qemu-in-linux-stubdom commands
From: Simon Gaiser
There is no QMP socket access, re-use the same mechanism as for MiniOS
based stubdom.
---
tools/libxl/libxl_pci.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4755a0c..311fad4 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -995,6 +995,7 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid,
libxl_device_pci *pcidev, i
uint32_t flag = XEN_DOMCTL_DEV_RDM_RELAXED;
uint32_t domainid = domid;
bool isstubdom = libxl_is_stubdom(ctx, domid, );
+uint32_t dm_domid;
if (type == LIBXL_DOMAIN_TYPE_INVALID)
return ERROR_FAIL;
@@ -1010,7 +1011,15 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid,
libxl_device_pci *pcidev, i
rc = qemu_pci_add_xenstore(gc, domid, pcidev);
break;
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-rc = libxl__qmp_pci_add(gc, domid, pcidev);
+dm_domid = libxl_get_stubdom_id(ctx, domid);
+
+if (dm_domid != 0
+&& libxl__stubdomain_version_running(gc, dm_domid) ==
+ LIBXL_STUBDOMAIN_VERSION_LINUX) {
+rc = qemu_pci_add_xenstore(gc, domid, pcidev);
+} else {
+rc = libxl__qmp_pci_add(gc, domid, pcidev);
+}
break;
default:
return ERROR_INVAL;
@@ -1362,7 +1371,7 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
libxl_device_pci *assigned;
libxl_domain_type type = libxl__domain_type(gc, domid);
int hvm = 0, rc, num;
-int stubdomid = 0;
+int stubdomid = libxl_get_stubdom_id(ctx, domid);
uint32_t domainid = domid;
bool isstubdom = libxl_is_stubdom(ctx, domid, );
@@ -1390,7 +1399,13 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
rc = qemu_pci_remove_xenstore(gc, domid, pcidev, force);
break;
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-rc = libxl__qmp_pci_del(gc, domid, pcidev);
+if (stubdomid != 0
+&& libxl__stubdomain_version_running(gc, stubdomid) ==
+ LIBXL_STUBDOMAIN_VERSION_LINUX) {
+rc = qemu_pci_remove_xenstore(gc, domid, pcidev, force);
+} else {
+rc = libxl__qmp_pci_del(gc, domid, pcidev);
+}
break;
default:
rc = ERROR_INVAL;
@@ -1470,7 +1485,6 @@ out:
LOGED(ERROR, domainid, "xc_deassign_device failed");
}
-stubdomid = libxl_get_stubdom_id(ctx, domid);
if (stubdomid != 0) {
libxl_device_pci pcidev_s = *pcidev;
libxl__device_pci_remove_common(gc, stubdomid, _s, force);
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH 10/17] xenconsoled: install xenstore watch for all supported consoles
Not only for the primary one (/local/domain//console path).
---
tools/console/daemon/io.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index e22009a..8aae87d 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -766,24 +766,24 @@ static int console_create_ring(struct console *con)
return err;
}
-static bool watch_domain(struct domain *dom, bool watch)
+static int watch_domain(struct console *con, struct domain *dom, void **data)
{
+ bool watch = data;
char domid_str[3 + MAX_STRLEN(dom->domid)];
bool success;
- struct console *con = >console[0];
snprintf(domid_str, sizeof(domid_str), "dom%u", dom->domid);
if (watch) {
success = xs_watch(xs, con->xspath, domid_str);
if (success)
- console_iter_int_arg1(dom, console_create_ring);
+ console_create_ring(con);
else
xs_unwatch(xs, con->xspath, domid_str);
} else {
success = xs_unwatch(xs, con->xspath, domid_str);
}
- return success;
+ return !success;
}
static int console_init(struct console *con, struct domain *dom, void **data)
@@ -853,7 +853,7 @@ static struct domain *create_domain(int domid)
if (console_iter_int_arg3(dom, console_init, (void **)_type))
goto out;
- if (!watch_domain(dom, true))
+ if (console_iter_int_arg3(dom, watch_domain, (void**)true))
goto out;
dom->next = dom_head;
@@ -927,7 +927,7 @@ static void console_close_evtchn(struct console *con)
static void shutdown_domain(struct domain *d)
{
d->is_dead = true;
- watch_domain(d, false);
+ console_iter_int_arg3(d, watch_domain, (void**)false);
console_iter_void_arg1(d, console_unmap_interface);
console_iter_void_arg1(d, console_close_evtchn);
}
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH 14/17] xenconsoled: deduplicate error handling
---
tools/console/daemon/io.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 7761c60..508bc2c 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -794,9 +794,7 @@ static int console_create_ring(struct console *con)
if (rc == -1) {
err = errno;
- xenevtchn_close(con->xce_handle);
- con->xce_handle = NULL;
- goto out;
+ goto err_xce;
}
con->local_port = rc;
con->remote_port = remote_port;
@@ -804,11 +802,7 @@ static int console_create_ring(struct console *con)
if (con->master_fd == -1) {
if (!console_create_tty(con)) {
err = errno;
- xenevtchn_close(con->xce_handle);
- con->xce_handle = NULL;
- con->local_port = -1;
- con->remote_port = -1;
- goto out;
+ goto err_xce;
}
}
@@ -818,6 +812,13 @@ static int console_create_ring(struct console *con)
/* if everything ok, signal backend readiness, in backend tree */
set_backend_state(con, XenbusStateConnected);
+ err_xce:
+ if (err) {
+ xenevtchn_close(con->xce_handle);
+ con->xce_handle = NULL;
+ con->local_port = -1;
+ con->remote_port = -1;
+ }
out:
return err;
}
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH 06/17] libxl: create vkb device only for guests with graphics output
The forced vkb device is meant for better performance of qemu access
(at least according to ebbd2561b4cefb299f0f68a88b2788504223de18 "libxl:
Add a vkbd frontend/backend pair for HVM guests"), which isn't used if
there is no configured channel to actually access that keyboard.
One can still add vkb device manually if needed.
This is continuation of b053f0c4c9e533f3d97837cf897eb920b8355ed3 "libxl: do
not start dom0 qemu for stubdomain when not needed".
---
tools/libxl/libxl_create.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index fff1f9c..4f10a6f 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1451,9 +1451,13 @@ static void domcreate_launch_dm(libxl__egc *egc,
libxl__multidev *multidev,
libxl__device_console_add(gc, domid, , state, );
libxl__device_console_dispose();
-libxl_device_vkb_init();
-libxl__device_add(gc, domid, __vkb_devtype, );
-libxl_device_vkb_dispose();
+if (libxl_defbool_val(d_config->b_info.u.hvm.vnc.enable)
+|| libxl_defbool_val(d_config->b_info.u.hvm.spice.enable)
+|| libxl_defbool_val(d_config->b_info.u.hvm.sdl.enable)) {
+libxl_device_vkb_init();
+libxl__device_add(gc, domid, __vkb_devtype, );
+libxl_device_vkb_dispose();
+}
dcs->sdss.dm.guest_domid = domid;
if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH 15/17] xenconsoled: add support for non-pty output
Handle 'output' xenstore entry, as qemu does. Right now support only few
simple options:
- "pty" (unchanged)
- "file:path" (overwrite file)
- "pipe:path" (read-write file/pipe)
- "null"
Also, when ever read() returns 0, stop reading from that source, instead
of spinning in a loop.
For now, in case of reconnect, intentionally use pty (ignore 'output'
xenstore entry), as for normal files close+open can be harmful
(especially with O_TRUNC).
---
According to qemu docs, "pipe" should behave differently - it should
open two pipes, with ".in" and ".out". According to actual qemu code, it
does that, but if it fails it fallbacks to just one file. And libxl
relies on that fallback, so I've implemented that version only.
If xenconsoled would have some man page, I'd add it there...
---
tools/console/daemon/io.c | 62
1 file changed, 57 insertions(+), 5 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 508bc2c..7afff99 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -95,6 +95,8 @@ struct console {
int master_fd;
int master_pollfd_idx;
int slave_fd;
+ bool master_fd_can_read;
+ bool master_fd_can_write;
int log_fd;
struct buffer buffer;
char *xspath;
@@ -705,6 +707,53 @@ static void console_unmap_interface(struct console *con)
con->ring_ref = -1;
}
+static int create_console_output(struct console *con)
+{
+ int err;
+ char *output, *path;
+
+ if (asprintf(, "%s/%s", con->xspath, "output") == -1) {
+ err = ENOMEM;
+ goto out;
+ }
+
+ con->master_fd_can_read = true;
+ con->master_fd_can_write = true;
+
+ output = xs_read(xs, XBT_NULL, path, NULL);
+
+ if (!output || !strcmp(output, "pty")) {
+ if (!console_create_tty(con)) {
+ err = errno;
+ goto out;
+ }
+ } else if (!strncmp(output, "file:", 5)) {
+ con->master_fd = open(output+5, O_WRONLY | O_CREAT | O_TRUNC,
0600);
+ if (con->master_fd == -1) {
+ err = errno;
+ goto out;
+ }
+ /* this is write-only file */
+ con->master_fd_can_read = false;
+ } else if (!strncmp(output, "pipe:", 5)) {
+ con->master_fd = open(output+5, O_RDWR);
+ if (con->master_fd == -1) {
+ err = errno;
+ goto out;
+ }
+ } else if (!strcmp(output, "null")) {
+ con->master_fd = open("/dev/null", O_RDWR);
+ if (con->master_fd == -1) {
+ err = errno;
+ goto out;
+ }
+ }
+
+ err = 0;
+out:
+ return err;
+}
+
static int console_create_ring(struct console *con)
{
int err, remote_port, ring_ref, rc;
@@ -800,10 +849,9 @@ static int console_create_ring(struct console *con)
con->remote_port = remote_port;
if (con->master_fd == -1) {
- if (!console_create_tty(con)) {
- err = errno;
+ err = create_console_output(con);
+ if (err)
goto err_xce;
- }
}
if (log_guest && (con->log_fd == -1))
@@ -916,6 +964,8 @@ static int console_init(struct console *con, struct domain
*dom, void **data)
con->master_fd = -1;
con->master_pollfd_idx = -1;
+ con->master_fd_can_read = true;
+ con->master_fd_can_write = true;
con->slave_fd = -1;
con->log_fd = -1;
con->ring_ref = -1;
@@ -1127,6 +1177,8 @@ static void handle_tty_read(struct console *con)
*/
if (len < 0) {
console_handle_broken_tty(con, domain_is_valid(dom->domid));
+ } else if (len == 0) {
+ con->master_fd_can_read = false;
} else if (domain_is_valid(dom->domid)) {
prod = intf->in_prod;
for (i = 0; i < len; i++) {
@@ -1371,10 +1423,10 @@ static void maybe_add_console_tty_fd(struct console
*con)
{
if (con->master_fd != -1) {
short events = 0;
- if (!con->d->is_dead && ring_free_bytes(con))
+ if (!con->d->is_dead && con->master_fd_can_read &&
ring_free_bytes(con))
events |= POLLIN;
- if (!buffer_empty(>buffer))
+ if (con->master_fd_can_write && !buffer_empty(>buffer))
events |= POLLOUT;
if (events)
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH 08/17] xl: add stubdomain related options to xl config parser
--- docs/man/xl.cfg.pod.5.in | 23 +++ tools/xl/xl_parse.c | 7 +++ 2 files changed, 26 insertions(+), 4 deletions(-) diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in index 099a28d..9c8ff31 100644 --- a/docs/man/xl.cfg.pod.5.in +++ b/docs/man/xl.cfg.pod.5.in @@ -2636,10 +2636,25 @@ model which they were installed with. =item B -Override the path to the binary to be used as the device-model. The -binary provided here MUST be consistent with the -B which you have specified. You should not -normally need to specify this option. +Override the path to the binary to be used as the device-model running in +toolstack domain. The binary provided here MUST be consistent with the +B which you have specified. You should not normally need +to specify this option. + +=item B + +Override the path to the kernel image used as device-model stubdomain. +The binary provided here MUST be consistent with the +B which you have specified. +In case of B it is expected to be MiniOS-based stubdomain +image, in case of B it is expected to be Linux-based stubdomain +kernel. + +=item B + +Override the path to the ramdisk image used as device-model stubdomain. +The binary provided here is to be used by a kernel pointed by B. +It is known to be used only by Linux-based stubdomain kernel. =item B diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index f9147f6..c99c77b 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -2391,6 +2391,13 @@ skip_usbdev: xlu_cfg_replace_string(config, "device_model_user", _info->device_model_user, 0); +xlu_cfg_replace_string (config, "stubdomain_kernel", +_info->stubdomain_kernel, 0); +xlu_cfg_replace_string (config, "stubdomain_ramdisk", +_info->stubdomain_ramdisk, 0); +if (!xlu_cfg_get_long (config, "stubdomain_memory", , 0)) +b_info->stubdomain_memkb = l * 1024; + #define parse_extra_args(type)\ e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \ _info->extra##type, 0);\ -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] xenconsole: add option to avoid escape sequences in log
Add --replace-escape option to xenconsoled, which replaces ESC with
'.' in console output written to log file. This makes it slightly safer
to do tail -f on a console output of untrusted guest.
The pty output is unaffected by this option.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- optimize do_replace_escape() per Wei's suggestion
- expand help string
- avoid variable sized array on stack per Christopher's suggestion
(although this made the code a little more ugly :/ - I try hard to
not impact performance when this option is disabled)
---
tools/console/daemon/io.c | 27 ++-
tools/console/daemon/main.c | 8 +++-
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index e22009aa39..1457b954fa 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -68,6 +68,7 @@ extern int log_time_hv;
extern int log_time_guest;
extern char *log_dir;
extern int discard_overflowed_data;
+extern int replace_escape;
static int log_time_hv_needts = 1;
static int log_time_guest_needts = 1;
@@ -227,10 +228,34 @@ static inline int console_iter_int_arg3(struct domain *d,
return ret;
}
+static void do_replace_escape(const char *src, char *dest, int len)
+{
+ int i;
+
+ for (i = 0; i < len; i++) {
+ if (src[i] == '\033')
+ dest[i] = '.';
+ else
+ dest[i] = src[i];
+ }
+}
+
static int write_all(int fd, const char* buf, size_t len)
{
+ char buf_replaced[1024];
+ size_t this_round;
+
while (len) {
- ssize_t ret = write(fd, buf, len);
+ ssize_t ret;
+ if (replace_escape) {
+ if (len > sizeof(buf_replaced))
+ this_round = sizeof(buf_replaced);
+ else
+ this_round = len;
+ do_replace_escape(buf, buf_replaced, this_round);
+ ret = write(fd, buf_replaced, this_round);
+ } else
+ ret = write(fd, buf, len);
if (ret == -1 && errno == EINTR)
continue;
if (ret <= 0)
diff --git a/tools/console/daemon/main.c b/tools/console/daemon/main.c
index 806d2fd611..5d9d55b430 100644
--- a/tools/console/daemon/main.c
+++ b/tools/console/daemon/main.c
@@ -40,6 +40,7 @@ int log_time_hv = 0;
int log_time_guest = 0;
char *log_dir = NULL;
int discard_overflowed_data = 1;
+int replace_escape = 0;
static void handle_hup(int sig)
{
@@ -48,7 +49,8 @@ static void handle_hup(int sig)
static void usage(char *name)
{
- printf("Usage: %s [-h] [-V] [-v] [-i] [--log=none|guest|hv|all]
[--log-dir=DIR] [--pid-file=PATH] [-t, --timestamp=none|guest|hv|all] [-o,
--overflow-data=discard|keep]\n", name);
+ printf("Usage: %s [-h] [-V] [-v] [-i] [--log=none|guest|hv|all]
[--log-dir=DIR] [--pid-file=PATH] [-t, --timestamp=none|guest|hv|all] [-o,
--overflow-data=discard|keep] [--replace-escape]\n", name);
+ printf(" --replace-escape - replace ESC character with dot when
writing console log\n");
}
static void version(char *name)
@@ -104,6 +106,7 @@ int main(int argc, char **argv)
{ "pid-file", 1, 0, 'p' },
{ "timestamp", 1, 0, 't' },
{ "overflow-data", 1, 0, 'o'},
+ { "replace-escape", 0, 0, 'e'},
{ 0 },
};
bool is_interactive = false;
@@ -168,6 +171,9 @@ int main(int argc, char **argv)
discard_overflowed_data = 1;
}
break;
+ case 'e':
+ replace_escape = 1;
+ break;
case '?':
fprintf(stderr,
"Try `%s --help' for more information\n",
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/2] xenstore-client: Add option for raw in-/output
From: Simon Gaiser
Parsing/generating the escape sequences used by xenstore-client is non
trivial. So make scripting (for use in stubdom) easier by adding a raw
option.
[added man page entries, facor out expand_buffer]
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- man page entries
- factor out expand_buffer
---
docs/man/xenstore-read.pod.1 | 4 ++
docs/man/xenstore-write.pod.1| 4 ++
tools/xenstore/xenstore_client.c | 65
3 files changed, 57 insertions(+), 16 deletions(-)
diff --git a/docs/man/xenstore-read.pod.1 b/docs/man/xenstore-read.pod.1
index 256d58fb7d..5496de17a8 100644
--- a/docs/man/xenstore-read.pod.1
+++ b/docs/man/xenstore-read.pod.1
@@ -20,6 +20,10 @@ Prefix value with key name.
Connect to the Xenstore daemon using a local socket only.
+=item B<-R>
+
+Read raw value, skip escaping non-printable characters (\x..).
+
=back
=head1 BUGS
diff --git a/docs/man/xenstore-write.pod.1 b/docs/man/xenstore-write.pod.1
index 424ab0e30e..78cbbe1a69 100644
--- a/docs/man/xenstore-write.pod.1
+++ b/docs/man/xenstore-write.pod.1
@@ -17,6 +17,10 @@ provided to write them at once - in one Xenstore transaction.
Connect to the Xenstore daemon using a local socket only.
+=item B<-R>
+
+Write raw value, skip parsing escaped characters (\x..).
+
=back
=head1 BUGS
diff --git a/tools/xenstore/xenstore_client.c b/tools/xenstore/xenstore_client.c
index 3d14d37e62..3afc630ab8 100644
--- a/tools/xenstore/xenstore_client.c
+++ b/tools/xenstore/xenstore_client.c
@@ -44,6 +44,17 @@ static struct expanding_buffer ebuf;
static int output_size = 0;
+/* make sure there is at least 'len' more space in output_buf */
+static void expand_buffer(size_t len)
+{
+if (output_pos + len > output_size) {
+output_size += len + 1024;
+output_buf = realloc(output_buf, output_size);
+if (output_buf == NULL)
+err(1, "malloc");
+}
+}
+
static void
output(const char *fmt, ...) {
va_list ap;
@@ -55,12 +66,7 @@ output(const char *fmt, ...) {
if (len < 0)
err(1, "output");
va_end(ap);
-if (len + 1 + output_pos > output_size) {
- output_size += len + 1024;
- output_buf = realloc(output_buf, output_size);
- if (output_buf == NULL)
- err(1, "malloc");
-}
+expand_buffer(len + 1);
va_start(ap, fmt);
if (vsnprintf(_buf[output_pos], len + 1, fmt, ap) != len)
err(1, "output");
@@ -68,6 +74,14 @@ output(const char *fmt, ...) {
output_pos += len;
}
+static void
+output_raw(const char *data, int len)
+{
+expand_buffer(len);
+memcpy(_buf[output_pos], data, len);
+output_pos += len;
+}
+
static void
usage(enum mode mode, int incl_mode, const char *progname)
{
@@ -78,10 +92,10 @@ usage(enum mode mode, int incl_mode, const char *progname)
errx(1, "Usage: %s [-h] [...]", progname);
case MODE_read:
mstr = incl_mode ? "read " : "";
- errx(1, "Usage: %s %s[-h] [-p] [-s] key [...]", progname, mstr);
+ errx(1, "Usage: %s %s[-h] [-p] [-s] [-R] key [...]", progname, mstr);
case MODE_write:
mstr = incl_mode ? "write " : "";
- errx(1, "Usage: %s %s[-h] [-s] key value [...]", progname, mstr);
+ errx(1, "Usage: %s %s[-h] [-s] [-R] key value [...]", progname, mstr);
case MODE_rm:
mstr = incl_mode ? "rm " : "";
errx(1, "Usage: %s %s[-h] [-s] [-t] key [...]", progname, mstr);
@@ -293,7 +307,8 @@ do_watch(struct xs_handle *xsh, int max_events)
static int
perform(enum mode mode, int optind, int argc, char **argv, struct xs_handle
*xsh,
-xs_transaction_t xth, int prefix, int tidy, int upto, int recurse, int
nr_watches)
+xs_transaction_t xth, int prefix, int tidy, int upto, int recurse, int
nr_watches,
+int raw)
{
switch (mode) {
case MODE_ls:
@@ -322,17 +337,27 @@ perform(enum mode mode, int optind, int argc, char
**argv, struct xs_handle *xsh
}
if (prefix)
output("%s: ", argv[optind]);
-output("%s\n", sanitise_value(, val, len));
+if (raw)
+output_raw(val, len);
+else
+output("%s\n", sanitise_value(, val, len));
free(val);
optind++;
break;
}
case MODE_write: {
char *val_spec = argv[optind + 1];
+char *val;
unsigned len;
-expanding_buffer_ensure(, strlen(val_spec)+1);
-unsanitise_value(ebuf.buf, , val_spec);
-if (!xs_write(xsh, xth, argv[optind], ebuf.buf, len)) {
+if (raw) {
+val = val_spec;
+len = strlen(val_spec);
+} else {
+expanding_buffer_ensure(, strlen(val_spec)+1);
+unsanitise_value(ebuf.buf, , val_spec);
+val = ebuf.buf;
+}
+if (!xs_write(xsh, xth,
[Xen-devel] [PATCH v2 1/2] docs: add xenstore-read and xenstore-write man pages
Signed-off-by: Marek Marczykowski-Górecki --- Changes in v2: - new patch --- docs/man/xenstore-read.pod.1 | 28 docs/man/xenstore-write.pod.1 | 25 + 2 files changed, 53 insertions(+) create mode 100644 docs/man/xenstore-read.pod.1 create mode 100644 docs/man/xenstore-write.pod.1 diff --git a/docs/man/xenstore-read.pod.1 b/docs/man/xenstore-read.pod.1 new file mode 100644 index 00..256d58fb7d --- /dev/null +++ b/docs/man/xenstore-read.pod.1 @@ -0,0 +1,28 @@ +=head1 NAME + +xenstore-read - read Xenstore values + +=head1 SYNOPSIS + +B [I]... [I]... + +=head1 DESCRIPTION + +Read values of one or more Xenstore Is. + +=over + +=item B<-p> + +Prefix value with key name. + +=item B<-s> + +Connect to the Xenstore daemon using a local socket only. + +=back + +=head1 BUGS + +Send bugs to xen-de...@lists.xen.org, see +http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports. diff --git a/docs/man/xenstore-write.pod.1 b/docs/man/xenstore-write.pod.1 new file mode 100644 index 00..424ab0e30e --- /dev/null +++ b/docs/man/xenstore-write.pod.1 @@ -0,0 +1,25 @@ +=head1 NAME + +xenstore-write - write Xenstore values + +=head1 SYNOPSIS + +B [I]... I I... + +=head1 DESCRIPTION + +Write Is to Xenstore Is. Multiple pairs I I can be +provided to write them at once - in one Xenstore transaction. + +=over + +=item B<-s> + +Connect to the Xenstore daemon using a local socket only. + +=back + +=head1 BUGS + +Send bugs to xen-de...@lists.xen.org, see +http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports. -- 2.17.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] tools/gdbsx: fix 'g' packet response for 64bit guests
gdb 8.0 fixed bounds checking for 'g' packet (commit
9dc193c3be85aafa60ceff57d3b0430af607b4ce "Check for truncated
registers in process_g_packet"). This revealed that gdbsx did
not properly formatted 'g' packet - segment registers and eflags are
expected to be 32-bit fields in the response (according to
gdb/features/i386/64bit-core.xml in gdb sources). Specific error is:
Truncated register 26 in remote 'g' packet
instead of silently truncating part of register.
Additionally, it looks like segment registers of 64bit guests were never
reported correctly, because of type mismatch.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/debugger/gdbsx/gx/gx_local.c | 6 +++---
tools/debugger/gdbsx/xg/xg_main.c | 20 ++--
tools/debugger/gdbsx/xg/xg_public.h | 18 +-
3 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/tools/debugger/gdbsx/gx/gx_local.c
b/tools/debugger/gdbsx/gx/gx_local.c
index 1bec03d49c..33556a582d 100644
--- a/tools/debugger/gdbsx/gx/gx_local.c
+++ b/tools/debugger/gdbsx/gx/gx_local.c
@@ -45,8 +45,8 @@ prnt_32regs(struct xg_gdb_regs32 *r32p)
static void
prnt_64regs(struct xg_gdb_regs64 *r64p)
{
-printf("rip:"XGF64" rsp:"XGF64" flags:"XGF64"\n", r64p->rip, r64p->rsp,
- r64p->rflags);
+printf("rip:"XGF64" rsp:"XGF64" flags:%08x\n", r64p->rip, r64p->rsp,
+ r64p->eflags);
printf("rax:"XGF64" rbx:"XGF64" rcx:"XGF64"\n", r64p->rax, r64p->rbx,
r64p->rcx);
printf("rdx:"XGF64" rsi:"XGF64" rdi:"XGF64"\n", r64p->rdx, r64p->rsi,
@@ -57,7 +57,7 @@ prnt_64regs(struct xg_gdb_regs64 *r64p)
r64p->r13);
printf("r14:"XGF64" r15:"XGF64" rbp:"XGF64"\n", r64p->r14, r64p->r15,
r64p->rbp);
-printf("cs:"XGF64" ds:"XGF64" fs:"XGF64" gs:"XGF64"\n", r64p->cs,
+printf("cs:%08x ds:%08x fs:%08x gs:%08x\n", r64p->cs,
r64p->ds, r64p->fs, r64p->gs);
printf("\n");
}
diff --git a/tools/debugger/gdbsx/xg/xg_main.c
b/tools/debugger/gdbsx/xg/xg_main.c
index cc640d1d82..a4e8653168 100644
--- a/tools/debugger/gdbsx/xg/xg_main.c
+++ b/tools/debugger/gdbsx/xg/xg_main.c
@@ -580,14 +580,14 @@ _cp_64ctxt_to_64gdb(struct cpu_user_regs_x86_64 *cp,
struct xg_gdb_regs64 *rp)
rp->rax = cp->rax;
rp->rip = cp->rip;
rp->rsp = cp->rsp;
-rp->rflags = cp->rflags;
-
-rp->cs = (uint64_t)cp->cs;
-rp->ss = (uint64_t)cp->ss;
-rp->es = (uint64_t)cp->es;
-rp->ds = (uint64_t)cp->ds;
-rp->fs = (uint64_t)cp->fs;
-rp->gs = (uint64_t)cp->gs;
+rp->eflags = cp->rflags;
+
+rp->cs = cp->cs;
+rp->ss = cp->ss;
+rp->es = cp->es;
+rp->ds = cp->ds;
+rp->fs = cp->fs;
+rp->gs = cp->gs;
#if 0
printf("cp:%llx bp:%llx rip:%llx\n", rp->rsp, rp->rbp, rp->rip);
printf("rax:%llx rbx:%llx\n", rp->rax, rp->rbx);
@@ -635,7 +635,7 @@ _cp_32gdb_to_64ctxt(struct xg_gdb_regs32 *rp, struct
cpu_user_regs_x86_64 *cp)
cp->ds = rp->ds;
cp->fs = rp->fs;
cp->gs = rp->gs;
-cp->rflags = rp->eflags;
+cp->eflags = rp->eflags;
}
static void
@@ -658,7 +658,7 @@ _cp_64gdb_to_64ctxt(struct xg_gdb_regs64 *rp, struct
cpu_user_regs_x86_64 *cp)
cp->rax = rp->rax;
cp->rip = rp->rip;
cp->rsp = rp->rsp;
-cp->rflags = rp->rflags;
+cp->rflags = rp->eflags;
cp->cs = (uint16_t)rp->cs;
cp->ss = (uint16_t)rp->ss;
diff --git a/tools/debugger/gdbsx/xg/xg_public.h
b/tools/debugger/gdbsx/xg/xg_public.h
index 3f905a2f0d..cffb2f7532 100644
--- a/tools/debugger/gdbsx/xg/xg_public.h
+++ b/tools/debugger/gdbsx/xg/xg_public.h
@@ -61,7 +61,7 @@ struct xg_gdb_regs32 {
uint32_t gs;
};
-/* this from: regformats/reg-x86-64.dat in gdbserver */
+/* based on gdb/features/i386/64bit-core.xml in gdb */
struct xg_gdb_regs64 {
uint64_t rax;
uint64_t rbx;
@@ -80,14 +80,14 @@ struct xg_gdb_regs64 {
uint64_t r14;
uint64_t r15;
uint64_t rip;
-uint64_t rflags;
-uint64_t cs;
-uint64_t ss;
-uint64_t ds;
-uint64_t es;
-uint64_t fs;
-uint64_t gs;
-};
+uint32_t eflags;
+uint32_t cs;
+uint32_t ss;
+uint32_t ds;
+uint32_t es;
+uint32_t fs;
+uint32_t gs;
+} __attribute__((__packed__));
union xg_gdb_regs {
struct xg_gdb_regs32 gregs_32;
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 baseline-only test] 75027: regressions - FAIL
This run is configured for baseline tests only. flight 75027 linux-3.18 real [real] http://osstest.xensource.com/osstest/logs/75027/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 11 guest-startfail REGR. vs. 75024 test-amd64-amd64-xl-multivcpu 12 guest-start fail REGR. vs. 75024 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 75024 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 75024 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail like 75024 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail like 75024 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail like 75024 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail like 75024 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail like 75024 test-amd64-amd64-xl-pvshim 12 guest-start fail like 75024 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 75024 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 75024 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 75024 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 75024 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 75024 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 75024 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win10-i386 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linuxdbba166b0e442d4d38ae0f244d32338c3e92d16f baseline version: linux7612025fbc7a5ab54bf71f48b99b0b6a15fc7b06 Last test of basis75024 2018-07-29 01:22:30 Z1 days Testing same since75027 2018-07-30 13:51:29 Z0 days1 attempts People who touched revisions under test: Alan Stern Alessandro Antenucci Alexander Sverdlin Alexey Brodkin Andrew Morton Anssi Hannula Arnd Bergmann Bin Liu Borislav Petkov David S. Miller Dewet Thibaut Eric Dumazet Felipe Balbi Greg Kroah-Hartman Gustavo A. R. Silva Jack
[Xen-devel] [xen-unstable-smoke test] 125690: tolerable all pass - PUSHED
flight 125690 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125690/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen f93021754b34f65f61812491f0beefe3d46d8e7e baseline version: xen 1f7574763cbb2c85825b8cc4d81f386e767a476f Last test of basis 125687 2018-07-30 15:00:46 Z0 days Testing same since 125690 2018-07-30 19:00:42 Z0 days1 attempts People who touched revisions under test: Doug Goldstein jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 1f7574763c..f93021754b f93021754b34f65f61812491f0beefe3d46d8e7e -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 125667: tolerable FAIL - PUSHED
flight 125667 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/125667/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 125652 pass in 125667 test-amd64-amd64-examine 4 memdisk-try-append fail pass in 125652 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125178 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125178 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125178 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125178 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125178 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125178 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125178 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125178 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 125178 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen acd00a303378ce48bd6bbd8a579f1fe2f1b21a7d baseline version: xen e3f667bc5f51d0aa44357a64ca134cd952679c81 Last test of basis 125178 2018-07-15 10:20:11 Z 15 days Failing since125259 2018-07-17 04:22:41 Z 13 days 11 attempts Testing same since 125645 2018-07-28 07:09:00 Z2 days3 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Christian Lindig Christopher Clark Christopher Clark Doug
[Xen-devel] [libvirt test] 125668: regressions - FAIL
flight 125668 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/125668/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a version targeted for testing: libvirt 7f6d6b965a878cb2ac3e163e3cad0fa0855b1ffe baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 55 days Failing since123840 2018-06-06 04:19:28 Z 54 days 42 attempts Testing same since 125647 2018-07-28 15:32:40 Z2 days3 attempts People who touched revisions under test: Ales Musil Andrea Bolognani Anya Harter Bjoern Walk Bobo Du Boris Fiuczynski Brijesh Singh Changkuo Shi Chen Hanxiao Christian Ehrhardt Cole Robinson Daniel Nicoletti Daniel P. Berrangé Daniel Veillard Eric Blake Erik Skultety Fabiano Fidêncio Filip Alac Han Han intrigeri intrigeri Jamie Strandboge Jie Wang Jiri Denemark John Ferlan Julio Faracco Ján Tomko Kashyap Chamarthy Katerina Koukiou Laine Stump Laszlo Ersek Luyao Huang Marc Hartmayer Marc Hartmayer Marcos Paulo de Souza Martin Kletzander Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Radostin Stoyanov Ramy Elkest ramyelkest Richard W.M. Jones Roman Bogorodskiy Shi Lei Shichangkuo Simon Kobyda Stefan Bader Stefan Berger Sukrit Bhatnagar Tomáš Golembiovský w00251574 Weilun Zhu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2
Re: [Xen-devel] [PATCH v2 19/21] xen/arm: introduce create_domUs
On Mon, 30 Jul 2018, Julien Grall wrote: > Hi Stefano, > > On 28/07/18 03:42, Stefano Stabellini wrote: > > On Tue, 24 Jul 2018, Julien Grall wrote: > > > > + > > > > +domain_unpause_by_systemcontroller(d); > > > > > > If a domain is bound to CPU0, then it will not boot until CPU0 is done > > > with > > > creating domain. Is that what you want? > > > > Are you suggesting to move the domain_unpause_by_systemcontroller(d) to > > a second loop after the domU creation loop? > > I was trying to understand what are the pro/cons of unpausing a DomU here. Did > you explore it? OK, let's dig into it. domain_unpause_by_systemcontroller doesn't actually trigger a DomU boot right away. It only marks the vcpu as ready to be started. Then, it is up to Xen wanting to leave hypervisor mode and start running a guest vcpu. So there should be no issues in unpausing the vcpus here, in fact, it should make no difference whether it is done inside this loop or on a second loop. In my experiments, cpu1 starts first, running dom1v0, then cpu0 (after completely start_xen) running dom0v0. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125687: tolerable all pass - PUSHED
flight 125687 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125687/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 1f7574763cbb2c85825b8cc4d81f386e767a476f baseline version: xen acd00a303378ce48bd6bbd8a579f1fe2f1b21a7d Last test of basis 125617 2018-07-27 09:01:58 Z3 days Testing same since 125687 2018-07-30 15:00:46 Z0 days1 attempts People who touched revisions under test: Anthony PERARD Ian Jackson Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git acd00a3033..1f7574763c 1f7574763cbb2c85825b8cc4d81f386e767a476f -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v8 01/11] arm: remove the ARM HDLCD driver
The ARM HDLCD driver is unused. The device itself can only be found on
Virtual Express boards that are for early development only. Remove the
driver.
Also remove vexpress_syscfg, now unused, and "select VIDEO" that is not
useful anymore.
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
Changes in v3:
- remove "select VIDEO"
- remove vexpress_syscfg
Changes in v2:
- patch added
---
xen/arch/arm/Kconfig | 2 -
xen/arch/arm/platforms/vexpress.c| 35
xen/drivers/video/Kconfig| 3 -
xen/drivers/video/Makefile | 1 -
xen/drivers/video/arm_hdlcd.c| 281 ---
xen/include/asm-arm/platforms/vexpress.h | 6 -
6 files changed, 328 deletions(-)
delete mode 100644 xen/drivers/video/arm_hdlcd.c
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c..4dc7ef5 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -17,12 +17,10 @@ config ARM_64
config ARM
def_bool y
select HAS_ALTERNATIVE
- select HAS_ARM_HDLCD
select HAS_DEVICE_TREE
select HAS_MEM_ACCESS
select HAS_PASSTHROUGH
select HAS_PDX
- select VIDEO
config ARCH_DEFCONFIG
string
diff --git a/xen/arch/arm/platforms/vexpress.c
b/xen/arch/arm/platforms/vexpress.c
index 70839d6..b6193f7 100644
--- a/xen/arch/arm/platforms/vexpress.c
+++ b/xen/arch/arm/platforms/vexpress.c
@@ -59,41 +59,6 @@ static inline int vexpress_ctrl_start(uint32_t *syscfg, int
write,
return 0;
}
-int vexpress_syscfg(int write, int function, int device, uint32_t *data)
-{
-uint32_t *syscfg = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
-int ret = -1;
-
-set_fixmap(FIXMAP_MISC, maddr_to_mfn(V2M_SYS_MMIO_BASE),
- PAGE_HYPERVISOR_NOCACHE);
-
-if ( syscfg[V2M_SYS_CFGCTRL/4] & V2M_SYS_CFG_START )
-goto out;
-
-/* clear the complete bit in the V2M_SYS_CFGSTAT status register */
-syscfg[V2M_SYS_CFGSTAT/4] = 0;
-
-if ( write )
-{
-/* write data */
-syscfg[V2M_SYS_CFGDATA/4] = *data;
-
-if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
-goto out;
-} else {
-if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
-goto out;
-else
-/* read data */
-*data = syscfg[V2M_SYS_CFGDATA/4];
-}
-
-ret = 0;
-out:
-clear_fixmap(FIXMAP_MISC);
-return ret;
-}
-
/*
* TODO: Get base address from the device tree
* See arm,vexpress-reset node
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
index 52e8ce6..41ca503 100644
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -11,6 +11,3 @@ config VGA
Enable VGA output for the Xen hypervisor.
If unsure, say Y.
-
-config HAS_ARM_HDLCD
- bool
diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index 2bb91d6..2b3fc76 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -4,4 +4,3 @@ obj-$(CONFIG_VIDEO) += font_8x16.o
obj-$(CONFIG_VIDEO) += font_8x8.o
obj-$(CONFIG_VIDEO) += lfb.o
obj-$(CONFIG_VGA) += vesa.o
-obj-$(CONFIG_HAS_ARM_HDLCD) += arm_hdlcd.o
diff --git a/xen/drivers/video/arm_hdlcd.c b/xen/drivers/video/arm_hdlcd.c
deleted file mode 100644
index e1174b2..000
--- a/xen/drivers/video/arm_hdlcd.c
+++ /dev/null
@@ -1,281 +0,0 @@
-/*
- * xen/drivers/video/arm_hdlcd.c
- *
- * Driver for ARM HDLCD Controller
- *
- * Stefano Stabellini
- * Copyright (c) 2013 Citrix Systems.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "font.h"
-#include "lfb.h"
-#include "modelines.h"
-
-#define HDLCD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_MISC))
-
-#define HDLCD_INTMASK (0x18/4)
-#define HDLCD_FBBASE(0x100/4)
-#define HDLCD_LINELENGTH(0x104/4)
-#define HDLCD_LINECOUNT (0x108/4)
-#define HDLCD_LINEPITCH (0x10C/4)
-#define HDLCD_BUS (0x110/4)
-#define HDLCD_VSYNC (0x200/4)
-#define HDLCD_VBACK (0x204/4)
-#define HDLCD_VDATA (0x208/4)
-#define HDLCD_VFRONT(0x20C/4)
-#define HDLCD_HSYNC (0x210/4)
-#define HDLCD_HBACK (0x214/4)
-#define HDLCD_HDATA (0x218/4)
-#define HDLCD_HFRONT(0x21C/4)
-#define HDLCD_POLARITIES(0x220/4)
-#define HDLCD_COMMAND (0x230/4)
-#define HDLCD_PF(0x240/4)
[Xen-devel] [PATCH v8 11/11] xen: specify support for EXPERT and DEBUG Kconfig options
Add a clear statement about them, reflecting the current security support status of Kconfig options (no changes to current policies). Signed-off-by: Stefano Stabellini Acked-by: Jan Beulich CC: george.dun...@eu.citrix.com CC: ian.jack...@eu.citrix.com CC: jbeul...@suse.com CC: andrew.coop...@citrix.com CC: Konrad Rzeszutek Wilk CC: Tim Deegan CC: Wei Liu --- Changes in v7: - talk about EXPERT and DEBUG rather than CONFIG_EXPERT and CONFIG_DEBUG --- SUPPORT.md | 6 ++ 1 file changed, 6 insertions(+) diff --git a/SUPPORT.md b/SUPPORT.md index 264b23f..e3e49e2 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -16,6 +16,12 @@ for the definitions of the support status levels etc. # Feature Support +## Kconfig + +EXPERT and DEBUG Kconfig options are not security supported. Other +Kconfig options are supported, if the related features are marked as +supported in this document. + ## Host Architecture ### x86-64 -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v8 08/11] arm: add ALL_PLAT, QEMU, Rcar3 and MPSoC configs
Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3, MPSOC and ALL_PLAT. They enable the required options for their hardware platform. ALL_PLAT enables all available platforms and it's the default. It doesn't automatically select any of the related drivers, otherwise they cannot be disabled. ALL_PLAT is implemented by using hidden options with default values depending on ALL_PLAT. In the case of the MPSOC that has a platform file under arch/arm/platforms/, build the file if MPSOC. Signed-off-by: Stefano Stabellini CC: artem_myga...@epam.com CC: volodymyr_babc...@epam.com --- Changes in v8: - remove QEMU_PLATFORM and RCAR3_PLATFORM that are currently unused - remove selects from ALL - rename ALL to ALL_PLAT - introduce ALL64_PLAT and ALL32_PLAT Changes in v5: - turn platform support into a choice - add ALL Changes in v4: - fix GICv3/GICV3 - default y to all options - build xilinx-zynqmp if MPSOC --- xen/arch/arm/Kconfig| 2 ++ xen/arch/arm/platforms/Kconfig | 52 + xen/arch/arm/platforms/Makefile | 2 +- 3 files changed, 55 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/platforms/Kconfig diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 2b87111..75cacfb 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -213,6 +213,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR config ARM32_HARDEN_BRANCH_PREDICTOR def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR +source "arch/arm/platforms/Kconfig" + source "common/Kconfig" source "drivers/Kconfig" diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig new file mode 100644 index 000..409d3f8 --- /dev/null +++ b/xen/arch/arm/platforms/Kconfig @@ -0,0 +1,52 @@ +choice + prompt "Platform Support" + default ALL_PLAT + ---help--- + Choose which hardware platform to enable in Xen. + + If unsure, choose ALL_PLAT. + +config ALL_PLAT + bool "All Platforms" + ---help--- + Enable support for all available hardware platforms. It doesn't + automatically select any of the related drivers. + +config QEMU + bool "QEMU aarch virt machine support" + depends on ARM_64 + select GICV3 + select HAS_PL011 + ---help--- + Enable all the required drivers for QEMU aarch64 virt emulated + machine. + +config RCAR3 + bool "Renesas RCar3 support" + depends on ARM_64 + select HAS_SCIF + ---help--- + Enable all the required drivers for Renesas RCar3 + +config MPSOC + bool "Xilinx Ultrascale+ MPSoC support" + depends on ARM_64 + select HAS_CADENCE_UART + select ARM_SMMU + ---help--- + Enable all the required drivers for Xilinx Ultrascale+ MPSoC + +endchoice + +config ALL64_PLAT + bool + default (ALL_PLAT && ARM_64) + +config ALL32_PLAT + bool + default (ALL_PLAT && ARM_32) + +config MPSOC_PLATFORM + bool + default (ALL64_PLAT || MPSOC) + diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 80e555c..a79bdb9 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -8,4 +8,4 @@ obj-$(CONFIG_ARM_64) += seattle.o obj-y += sunxi.o obj-$(CONFIG_ARM_64) += thunderx.o obj-$(CONFIG_ARM_64) += xgene-storm.o -obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o +obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v8 04/11] Make MEM_ACCESS configurable
Select MEM_ACCESS_ALWAYS_ON on x86 to mark that MEM_ACCESS is not configurable on x86. Avoid selecting it on ARM. Rename HAS_MEM_ACCESS to MEM_ACCESS everywhere. Add a prompt and a description to MEM_ACCESS in xen/common/Kconfig. The result is that the user-visible option is MEM_ACCESS, and it is configurable only on ARM (disabled by default). At the moment the arch-specific mem_access code remains enabled on ARM, even with MEM_ACCESS=y. The purpose is to reduce code size. The option doesn't depend on EXPERT because it would be nice to ecurity-support configurations without MEM_ACCESS and a non-expert should be able to disable it. Suggested-by: Julien Grall Signed-off-by: Stefano Stabellini Acked-by: Jan Beulich Acked-by: Julien Grall CC: dgde...@tycho.nsa.gov CC: andrew.coop...@citrix.com CC: george.dun...@eu.citrix.com CC: ian.jack...@eu.citrix.com CC: jbeul...@suse.com CC: julien.gr...@arm.com CC: konrad.w...@oracle.com CC: sstabell...@kernel.org CC: t...@xen.org CC: wei.l...@citrix.com --- Changes in v5: - change MEM_ACCESS_ALWAYS_ON to bool - change default for MEM_ACCESS, default y if MEM_ACCESS_ALWAYS_ON Changes in v4: - remove HAS_MEM_ACCESS - move MEM_ACCESS_ALWAYS_ON to common - combile default and bool to def_bool Changes in v3: - keep HAS_MEM_ACCESS to mark that an arch can do MEM_ACCESS - introduce MEM_ACCESS_ALWAYS_ON - the main MEM_ACCESS option is in xen/common/Kconfig Changes in v2: - patch added --- tools/firmware/xen-dir/shim.config | 2 +- xen/arch/arm/Kconfig | 1 - xen/arch/x86/Kconfig | 2 +- xen/common/Kconfig | 10 +- xen/common/Makefile| 2 +- xen/common/domctl.c| 2 +- xen/include/xen/mem_access.h | 4 ++-- xen/include/xsm/dummy.h| 2 +- xen/include/xsm/xsm.h | 4 ++-- xen/xsm/dummy.c| 2 +- xen/xsm/flask/hooks.c | 4 ++-- 11 files changed, 21 insertions(+), 14 deletions(-) diff --git a/tools/firmware/xen-dir/shim.config b/tools/firmware/xen-dir/shim.config index 4d5630f..21d7075 100644 --- a/tools/firmware/xen-dir/shim.config +++ b/tools/firmware/xen-dir/shim.config @@ -29,7 +29,7 @@ CONFIG_COMPAT=y CONFIG_CORE_PARKING=y CONFIG_HAS_ALTERNATIVE=y CONFIG_HAS_EX_TABLE=y -CONFIG_HAS_MEM_ACCESS=y +CONFIG_MEM_ACCESS=y CONFIG_HAS_MEM_PAGING=y CONFIG_HAS_MEM_SHARING=y CONFIG_HAS_PDX=y diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 66adce4..2b87111 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -17,7 +17,6 @@ config ARM def_bool y select HAS_ALTERNATIVE select HAS_DEVICE_TREE - select HAS_MEM_ACCESS select HAS_PASSTHROUGH select HAS_PDX diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index f64fc56..9a85fe9 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -15,7 +15,7 @@ config X86 select HAS_GDBSX select HAS_IOPORTS select HAS_KEXEC - select HAS_MEM_ACCESS + select MEM_ACCESS_ALWAYS_ON select HAS_MEM_PAGING select HAS_MEM_SHARING select HAS_NS16550 diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 9043dce..db6bb2d 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -20,9 +20,17 @@ config HAS_DEVICE_TREE config HAS_EX_TABLE bool -config HAS_MEM_ACCESS +config MEM_ACCESS_ALWAYS_ON bool +config MEM_ACCESS + def_bool MEM_ACCESS_ALWAYS_ON + prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON + ---help--- + + Framework to configure memory access types for guests and receive + related events in userspace. + config HAS_MEM_PAGING bool diff --git a/xen/common/Makefile b/xen/common/Makefile index 24d4752..6f2b3fc 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -22,7 +22,7 @@ obj-y += lib.o obj-$(CONFIG_NEEDS_LIST_SORT) += list_sort.o obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o obj-y += lzo.o -obj-$(CONFIG_HAS_MEM_ACCESS) += mem_access.o +obj-$(CONFIG_MEM_ACCESS) += mem_access.o obj-y += memory.o obj-y += monitor.o obj-y += multicall.o diff --git a/xen/common/domctl.c b/xen/common/domctl.c index 9b7bc08..891ad58 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -1085,7 +1085,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) copyback = 1; break; -#ifdef CONFIG_HAS_MEM_ACCESS +#ifdef CONFIG_MEM_ACCESS case XEN_DOMCTL_set_access_required: if ( unlikely(current->domain == d) ) /* no domain_pause() */ ret = -EPERM; diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h index 5ab34c1..7e95eab 100644 --- a/xen/include/xen/mem_access.h +++ b/xen/include/xen/mem_access.h @@ -78,7 +78,7 @@ long p2m_set_mem_access_multi(struct domain *d, */ int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access); -#ifdef CONFIG_HAS_MEM_ACCESS
[Xen-devel] [PATCH v8 09/11] xen: add per-platform defaults for NR_CPUS
Add specific per-platform defaults for NR_CPUS. Note that the order of the defaults matter: they need to go first, otherwise the generic defaults will be applied. This is done so that Xen builds customized for a specific hardware platform can have the right NR_CPUS number. Signed-off-by: Stefano Stabellini Acked-by: Jan Beulich Acked-by: Julien Grall CC: jbeul...@suse.com CC: andrew.coop...@citrix.com --- Changes in v6: - remove useless additional default for ALL --- xen/arch/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig index cf0acb7..1954d1c 100644 --- a/xen/arch/Kconfig +++ b/xen/arch/Kconfig @@ -3,6 +3,9 @@ config NR_CPUS int "Maximum number of physical CPUs" range 1 4095 default "256" if X86 + default "8" if ARM && RCAR3 + default "4" if ARM && QEMU + default "4" if ARM && MPSOC default "128" if ARM ---help--- Specifies the maximum number of physical CPUs which Xen will support. -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v8 05/11] make it possible to enable/disable UART drivers
All the UART drivers are silent options. Add one line descriptions so that can be de/selected via menuconfig. Add an x86 dependency to HAS_EHCI: EHCI PCI has not been used on ARM. In fact, it depends on PCI, and moreover we have drivers for several embedded UARTs for various ARM boards. NS16550 remains not selectable on x86. Signed-off-by: Stefano Stabellini Acked-by: Julien Grall --- Changes in v4: - improve commit message - remove prompt for HAS_EHCI Changes in v3: - NS16550 prompt if ARM Changes in v2: - make HAS_EHCI depend on x86 --- xen/drivers/char/Kconfig | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index cc78ec3..b1f07f8 100644 --- a/xen/drivers/char/Kconfig +++ b/xen/drivers/char/Kconfig @@ -1,11 +1,11 @@ config HAS_NS16550 - bool + bool "NS16550 UART driver" if ARM default y help This selects the 16550-series UART support. For most systems, say Y. config HAS_CADENCE_UART - bool + bool "Xilinx Cadence UART driver" default y depends on ARM_64 help @@ -13,7 +13,7 @@ config HAS_CADENCE_UART based board, say Y. config HAS_MVEBU - bool + bool "Marvell MVEBU UART driver" default y depends on ARM_64 help @@ -21,7 +21,7 @@ config HAS_MVEBU based board, say Y. config HAS_PL011 - bool + bool "ARM PL011 UART driver" default y depends on ARM help @@ -29,7 +29,7 @@ config HAS_PL011 an Integrator/PP2, Integrator/CP or Versatile platform, say Y. config HAS_EXYNOS4210 - bool + bool "Samsung Exynos 4210 UART driver" default y depends on ARM_32 help @@ -37,7 +37,7 @@ config HAS_EXYNOS4210 Exynos based board, say Y. config HAS_OMAP - bool + bool "Texas Instruments OMAP UART driver" default y depends on ARM_32 help @@ -45,7 +45,7 @@ config HAS_OMAP Instruments based CPU, say Y. config HAS_SCIF - bool + bool "SuperH SCI(F) UART driver" default y depends on ARM help @@ -54,6 +54,7 @@ config HAS_SCIF config HAS_EHCI bool + depends on X86 help This selects the USB based EHCI debug port to be used as a UART. If you have an x86 based system with USB, say Y. -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v8 02/11] arm: make it possible to disable HAS_GICV3
Today it is a silent option. This patch adds a one line description and makes it optional. Signed-off-by: Stefano Stabellini Acked-by: Julien Grall CC: george.dun...@eu.citrix.com CC: ian.jack...@eu.citrix.com CC: jbeul...@suse.com CC: andrew.coop...@citrix.com --- Changes in v3: - remove any changes to MEM_ACCESS - update commit message Changes in v2: - make HAS_GICv3 depend on ARM_64 - remove modifications to ARM_HDLCD kconfig, it has been removed --- xen/arch/arm/Kconfig | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 4dc7ef5..fb69a66 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -12,7 +12,6 @@ config ARM_32 config ARM_64 def_bool y depends on 64BIT - select HAS_GICV3 config ARM def_bool y @@ -42,6 +41,13 @@ config ACPI config HAS_GICV3 bool + prompt "GICv3 driver" + depends on ARM_64 + default y + ---help--- + + Driver for the ARM Generic Interrupt Controller v3. + If unsure, say Y config HAS_ITS bool -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v8 00/11] arm: more kconfig configurability and small default configs
Hi all, This patch series is the first step toward building a small certifiable Xen hypervisor for ARM boards. The series makes a few changes to allow disabling more kconfig options: most of them already exist but cannot be disabled. It also introduces a reference kconfig for Renesas RCar (due to popular demand, candidate for certifications), Xilinx MPSoC, and for QEMU aarch64 (not for certifications, but useful for debugging). The last patch clarifies the security support status of kconfig options in Xen. All patches are already acked, except for patch #8: "arm: add ALL_PLAT, QEMU, Rcar3 and MPSoC configs". Cheers, Stefano The following changes since commit 16fb4b5a9a79f95df17f10ba62e9f44d21cf89b5: docs/gen-html-index: Make HTML::TreeBuilder::XPath optional again (2018-04-13 17:04:36 +0100) are available in the git repository at: http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git small-kconfig-v8 for you to fetch changes up to 0a32269da030bf379a17b5203faa00578de9c919: xen: specify support for EXPERT and DEBUG Kconfig options (2018-07-30 10:41:41 -0700) Stefano Stabellini (11): arm: remove the ARM HDLCD driver arm: make it possible to disable HAS_GICV3 arm: rename HAS_GICV3 to GICV3 Make MEM_ACCESS configurable make it possible to enable/disable UART drivers arm: make it possible to disable the SMMU driver arm: add a tiny kconfig configuration arm: add ALL_PLAT, QEMU, Rcar3 and MPSoC configs xen: add per-platform defaults for NR_CPUS xen: add cloc target xen: specify support for EXPERT and DEBUG Kconfig options SUPPORT.md | 6 + tools/firmware/xen-dir/shim.config | 2 +- xen/Makefile | 12 ++ xen/arch/Kconfig | 3 + xen/arch/arm/Kconfig | 17 +- xen/arch/arm/Makefile| 4 +- xen/arch/arm/configs/tiny64.conf | 38 + xen/arch/arm/platforms/Kconfig | 52 ++ xen/arch/arm/platforms/Makefile | 2 +- xen/arch/arm/platforms/vexpress.c| 35 xen/arch/arm/vgic.c | 2 +- xen/arch/arm/vgic/vgic.c | 2 +- xen/arch/x86/Kconfig | 2 +- xen/common/Kconfig | 10 +- xen/common/Makefile | 2 +- xen/common/domctl.c | 2 +- xen/drivers/char/Kconfig | 15 +- xen/drivers/passthrough/Kconfig | 12 ++ xen/drivers/passthrough/arm/Makefile | 2 +- xen/drivers/video/Kconfig| 3 - xen/drivers/video/Makefile | 1 - xen/drivers/video/arm_hdlcd.c| 281 --- xen/include/asm-arm/gic.h| 4 +- xen/include/asm-arm/platforms/vexpress.h | 6 - xen/include/asm-arm/vgic.h | 4 +- xen/include/xen/mem_access.h | 4 +- xen/include/xsm/dummy.h | 2 +- xen/include/xsm/xsm.h| 4 +- xen/xsm/dummy.c | 2 +- xen/xsm/flask/hooks.c| 4 +- 30 files changed, 173 insertions(+), 362 deletions(-) create mode 100644 xen/arch/arm/configs/tiny64.conf create mode 100644 xen/arch/arm/platforms/Kconfig delete mode 100644 xen/drivers/video/arm_hdlcd.c ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v8 07/11] arm: add a tiny kconfig configuration
Add a tiny kconfig configuration. Enabled only the credit scheduler. It only carries non-default options (use make menuconfig or make olddefconfig to produce a complete .config file). Signed-off-by: Stefano Stabellini Acked-by: Julien Grall --- Changes in v7: - remove NULL because it is still experimental --- xen/arch/arm/configs/tiny64.conf | 38 ++ 1 file changed, 38 insertions(+) create mode 100644 xen/arch/arm/configs/tiny64.conf diff --git a/xen/arch/arm/configs/tiny64.conf b/xen/arch/arm/configs/tiny64.conf new file mode 100644 index 000..aecc55c --- /dev/null +++ b/xen/arch/arm/configs/tiny64.conf @@ -0,0 +1,38 @@ +CONFIG_ARM_64=y +CONFIG_ARM=y + +# +# Architecture Features +# +# CONFIG_GICV3 is not set +# CONFIG_MEM_ACCESS is not set +# CONFIG_SBSA_VUART_CONSOLE is not set + +# +# Common Features +# +# CONFIG_TMEM is not set +CONFIG_SCHED_CREDIT=y +# CONFIG_SCHED_CREDIT2 is not set +# CONFIG_SCHED_RTDS is not set +# CONFIG_SCHED_ARINC653 is not set +# CONFIG_SCHED_NULL is not set +# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set + +# +# Device Drivers +# +# CONFIG_HAS_NS16550 is not set +# CONFIG_HAS_CADENCE_UART is not set +# CONFIG_HAS_MVEBU is not set +# CONFIG_HAS_PL011 is not set +# CONFIG_HAS_SCIF is not set +# CONFIG_ARM_SMMU is not set + +# +# Debugging Options +# +# CONFIG_DEBUG is not set +# CONFIG_FRAME_POINTER is not set +# CONFIG_VERBOSE_DEBUG is not set +# CONFIG_SCRUB_DEBUG is not set -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v8 03/11] arm: rename HAS_GICV3 to GICV3
HAS_GICV3 has become selectable by the user. To mark the change, rename
the option from HAS_GICV3 to GICV3.
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- no changes
Changes in v2:
- patch added
---
xen/arch/arm/Kconfig | 4 ++--
xen/arch/arm/Makefile | 4 ++--
xen/arch/arm/vgic.c| 2 +-
xen/arch/arm/vgic/vgic.c | 2 +-
xen/include/asm-arm/gic.h | 4 ++--
xen/include/asm-arm/vgic.h | 4 ++--
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index fb69a66..66adce4 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -39,7 +39,7 @@ config ACPI
Advanced Configuration and Power Interface (ACPI) support for Xen is
an alternative to device tree on ARM64.
-config HAS_GICV3
+config GICV3
bool
prompt "GICv3 driver"
depends on ARM_64
@@ -52,7 +52,7 @@ config HAS_GICV3
config HAS_ITS
bool
prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
-depends on HAS_GICV3 && !NEW_VGIC
+depends on GICV3 && !NEW_VGIC
config NEW_VGIC
bool
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index a9533b1..b9c2fb7 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -17,7 +17,7 @@ obj-y += domctl.o
obj-$(EARLY_PRINTK) += early_printk.o
obj-y += gic.o
obj-y += gic-v2.o
-obj-$(CONFIG_HAS_GICV3) += gic-v3.o
+obj-$(CONFIG_GICV3) += gic-v3.o
obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
obj-$(CONFIG_HAS_ITS) += gic-v3-lpi.o
obj-y += guestcopy.o
@@ -51,7 +51,7 @@ ifneq ($(CONFIG_NEW_VGIC),y)
obj-y += gic-vgic.o
obj-y += vgic.o
obj-y += vgic-v2.o
-obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
+obj-$(CONFIG_GICV3) += vgic-v3.o
obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
endif
obj-y += vm_event.o
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 3fafdd0..7a2c455 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -98,7 +98,7 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
{
switch ( d->arch.vgic.version )
{
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
case GIC_V3:
if ( vgic_v3_init(d, mmio_count) )
return -ENODEV;
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index a35449b..832632a 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -974,7 +974,7 @@ unsigned int vgic_max_vcpus(const struct domain *d)
return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
}
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
/* Dummy implementation to allow building without actual vGICv3 support. */
void vgic_v3_setup_hw(paddr_t dbase,
unsigned int nr_rdist_regions,
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 58b910f..22fa122 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -166,7 +166,7 @@
#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3")
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
/*
* GICv3 registers that needs to be saved/restored
*/
@@ -194,7 +194,7 @@ struct gic_v2 {
*/
union gic_state_data {
struct gic_v2 v2;
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
struct gic_v3 v3;
#endif
};
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 2a58ea3..374fdaa 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -156,7 +156,7 @@ struct vgic_dist {
struct pending_irq *pending_irqs;
/* Base address for guest GIC */
paddr_t dbase; /* Distributor base address */
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
/* GIC V3 addressing */
/* List of contiguous occupied by the redistributors */
struct vgic_rdist_region {
@@ -359,7 +359,7 @@ unsigned int vgic_max_vcpus(const struct domain *d);
void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
paddr_t vbase, uint32_t aliased_offset);
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
struct rdist_region;
void vgic_v3_setup_hw(paddr_t dbase,
unsigned int nr_rdist_regions,
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] linux-next: manual merge of the akpm-current tree with the xen-tip tree
On 07/30/2018 01:02 PM, Boris Ostrovsky wrote:
> On 07/30/2018 05:02 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>> drivers/xen/gntdev.c
>>
>> between commit:
>>
>> 1d3145675538 ("xen/gntdev: Make private routines/structures accessible")
>>
>> from the xen-tip tree and commit:
>>
>> aaefcabe9c25 ("mm, oom: distinguish blockable mode for mmu notifiers")
>>
>> from the akpm-current tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging. You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>>
>> -- Cheers, Stephen Rothwell diff --cc drivers/xen/gntdev.c index
>> c866a62f766d,55b4f0e3f4d6.. --- a/drivers/xen/gntdev.c +++
>> b/drivers/xen/gntdev.c @@@ -479,7 -441,20 +479,20 @@@ static const
>> struct vm_operations_struc /*
>> -- */
>> -static bool in_range(struct grant_map *map, ++static bool
>> in_range(struct gntdev_grant_map *map, + unsigned long start, unsigned
>> long end) + { + if (!map->vma) + return false; + if
>> (map->vma->vm_start >= end) + return false; + if (map->vma->vm_end <=
>> start) + return false; + + return true; + } + -static void
>> unmap_if_in_range(struct grant_map *map, +static void
>> unmap_if_in_range(struct gntdev_grant_map *map, unsigned long start,
>> unsigned long end) { unsigned long mstart, mend; @@@ -503,15 -472,26
>> +510,26 @@@ WARN_ON(err); } - static void mn_invl_range_start(struct
>> mmu_notifier *mn, + static int mn_invl_range_start(struct mmu_notifier
>> *mn, struct mm_struct *mm, - unsigned long start, unsigned long end) +
>> unsigned long start, unsigned long end, + bool blockable) { struct
>> gntdev_priv *priv = container_of(mn, struct gntdev_priv, mn); - struct
>> grant_map *map; + struct gntdev_grant_map *map; + int ret = 0; + + /*
>> TODO do we really need a mutex here? */ + if (blockable) +
>> mutex_lock(>lock); + else if (!mutex_trylock(>lock)) +
>> return -EAGAIN; - mutex_lock(>lock); list_for_each_entry(map,
>> >maps, next) { + if (in_range(map, start, end)) { + ret =
>> -EAGAIN; + goto out_unlock; + } unmap_if_in_range(map, start, end); }
>> list_for_each_entry(map, >freeable_maps, next) {
Ugh... That's some interesting whitespace optimization on part of
thundebird. Let me paste the relevant patch hunk here.
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index bd56653b9bbc..55b4f0e3f4d6 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -441,18 +441,25 @@ static const struct vm_operations_struct gntdev_vmops = {
/* -- */
+static bool in_range(struct grant_map *map,
+ unsigned long start, unsigned long end)
+{
+ if (!map->vma)
+ return false;
+ if (map->vma->vm_start >= end)
+ return false;
+ if (map->vma->vm_end <= start)
+ return false;
+
+ return true;
+}
+
static void unmap_if_in_range(struct grant_map *map,
unsigned long start, unsigned long end)
{
unsigned long mstart, mend;
int err;
- if (!map->vma)
- return;
- if (map->vma->vm_start >= end)
- return;
- if (map->vma->vm_end <= start)
- return;
mstart = max(start, map->vma->vm_start);
mend = min(end, map->vma->vm_end);
pr_debug("map %d+%d (%lx %lx), range %lx %lx, mrange %lx %lx\n",
@@ -465,21 +472,40 @@ static void unmap_if_in_range(struct grant_map *map,
WARN_ON(err);
}
-static void mn_invl_range_start(struct mmu_notifier *mn,
+static int mn_invl_range_start(struct mmu_notifier *mn,
struct mm_struct *mm,
- unsigned long start, unsigned long end)
+ unsigned long start, unsigned long end,
+ bool blockable)
{
struct gntdev_priv *priv = container_of(mn, struct gntdev_priv, mn);
struct grant_map *map;
+ int ret = 0;
+
+ /* TODO do we really need a mutex here? */
+ if (blockable)
+ mutex_lock(>lock);
+ else if (!mutex_trylock(>lock))
+ return -EAGAIN;
- mutex_lock(>lock);
list_for_each_entry(map, >maps, next) {
+ if (in_range(map, start, end)) {
+ ret = -EAGAIN;
+ goto out_unlock;
+ }
unmap_if_in_range(map, start, end);
}
list_for_each_entry(map, >freeable_maps, next) {
+ if (in_range(map, start, end)) {
+
Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs
On Mon, 30 Jul 2018, Julien Grall wrote: > Hi Stefano, > > On 28/07/18 00:30, Stefano Stabellini wrote: > > On Fri, 27 Jul 2018, Julien Grall wrote: > > > Hi Stefano, > > > Sorry for the top posting. > > > > > > I think Andrii made a good point. With your new code MPSOC will get built > > > on Arm 32 bit as well. > > > > > > This was not the case before this patch. > > > > > > So I would like at least that to be fixed before any commit. > > > > OK, this is a problem. I'll fix it. > > > > Looking into it I think there is a way to solve it that doesn't require > > duplication, and not even the introduction of ALL_32 and ALL_64: we just > > need to add "if ARM_64" for the ARM64 platforms and "if ARM_32" for the > > ARM32 platforms. > > > > So today we would have (the "if ARM_64" is new compared to this patch): > > > >config ALL > >bool "All Platforms" > >select MPSOC_PLATFORM if ARM_64 > > > > In the furure, assuming that we had EXYNOS5 and OMAP5 options, it would > > become: > > > >config ALL > >bool "All Platforms" > >select MPSOC_PLATFORM if ARM_64 > >select EXYNOS5 if ARM_32 > >select OMAP5 if ARM_32 > > > > What do you think? > > I think I would prefer the suggestion I made on Andrii's answer: > > choice >config ALL_PLAT > bool "All Platforms" > "" > endchoice > > config ALL_PLAT_64 > default (ALL && ARM_64) > > config ALL_PLAT_32 > default (ALL_PLAT && ARM_32) > > config MPSOC_PLATFORM > bool > default (ALL_PLAT_64 || MPSOC) > > This would avoid a long list in "ALL_PLATFORMS". > > Also, I just noticed that 'ALL' will become CONFIG_ALL. This is slightly too > vague as a name. It would be better to include "PLAT" in it. I verified that this also works as expected. I'll make the changes and resend the series. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST] Install GnuTLS for libvirt builds
Since libvirt commit 60d9ad6f GnuTLS is required to build libvirt. The
various libvirt build tests in osstest began failing after the commit
hit libvirt.git master. Adding libgnutls28-dev to the list of packages
needed to build libvirt will fix the currently broken builds.
Signed-off-by: Jim Fehlig
---
I cribbed the 'libgnutls28-dev' package name from the libvirt jenkins CI
https://libvirt.org/git/?p=libvirt-jenkins-ci.git;a=blob;f=guests/vars/mappings.yml;h=be356aae616e7dacf603175fe1bea8ce398629e1;hb=HEAD#l138
Osstest/Toolstack/libvirt.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 45df173..d5cda77 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -26,7 +26,7 @@ use XML::LibXML;
sub new {
my ($class, $ho, $methname,$asset) = @_;
-my @extra_packages = qw(libavahi-client3);
+my @extra_packages = qw(libavahi-client3 libgnutls28-dev);
my $nl_lib = "libnl-3-200";
$nl_lib = "libnl1" if ($ho->{Suite} =~ m/wheezy/);
push(@extra_packages, $nl_lib);
--
2.18.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] linux-next: manual merge of the akpm-current tree with the xen-tip tree
On 07/30/2018 05:02 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> drivers/xen/gntdev.c
>
> between commit:
>
> 1d3145675538 ("xen/gntdev: Make private routines/structures accessible")
>
> from the xen-tip tree and commit:
>
> aaefcabe9c25 ("mm, oom: distinguish blockable mode for mmu notifiers")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> -- Cheers, Stephen Rothwell diff --cc drivers/xen/gntdev.c index
> c866a62f766d,55b4f0e3f4d6.. --- a/drivers/xen/gntdev.c +++
> b/drivers/xen/gntdev.c @@@ -479,7 -441,20 +479,20 @@@ static const
> struct vm_operations_struc /*
> -- */
> -static bool in_range(struct grant_map *map, ++static bool
> in_range(struct gntdev_grant_map *map, + unsigned long start, unsigned
> long end) + { + if (!map->vma) + return false; + if
> (map->vma->vm_start >= end) + return false; + if (map->vma->vm_end <=
> start) + return false; + + return true; + } + -static void
> unmap_if_in_range(struct grant_map *map, +static void
> unmap_if_in_range(struct gntdev_grant_map *map, unsigned long start,
> unsigned long end) { unsigned long mstart, mend; @@@ -503,15 -472,26
> +510,26 @@@ WARN_ON(err); } - static void mn_invl_range_start(struct
> mmu_notifier *mn, + static int mn_invl_range_start(struct mmu_notifier
> *mn, struct mm_struct *mm, - unsigned long start, unsigned long end) +
> unsigned long start, unsigned long end, + bool blockable) { struct
> gntdev_priv *priv = container_of(mn, struct gntdev_priv, mn); - struct
> grant_map *map; + struct gntdev_grant_map *map; + int ret = 0; + + /*
> TODO do we really need a mutex here? */ + if (blockable) +
> mutex_lock(>lock); + else if (!mutex_trylock(>lock)) +
> return -EAGAIN; - mutex_lock(>lock); list_for_each_entry(map,
> >maps, next) { + if (in_range(map, start, end)) { + ret =
> -EAGAIN; + goto out_unlock; + } unmap_if_in_range(map, start, end); }
> list_for_each_entry(map, >freeable_maps, next) {
I clearly missed this (aaefcabe9c25) patch but now that I am looking at
it I don't think I understand the logic for changes in
list_for_each_entry() loops.
Aren't we ending up never unmapping grant pages? Michal, can you explain
what you are trying to do here?
-boris
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen-netfront: wait xenbus state change when load module manually
From: Xiao Liang Date: Fri, 27 Jul 2018 17:56:08 +0800 > When loading module manually, after call xenbus_switch_state to initializes > the state of the netfront device, the driver state did not change so fast > that may lead no dev created in latest kernel. This patch adds wait to make > sure xenbus knows the driver is not in closed/unknown state. ... > Signed-off-by: Xiao Liang Applied and queued up for -stable, thanks. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs
Hello Stefano, > Ah, yes, I understand what you mean now. My point was to get the feature of minimal platform support right away. You are interested in Xilinx, so you make a minimal configuration for MPSOC. And stack the rest into an *optional* all platforms support. So maintainers of other platforms can show their interest with appropriate patches for minimal configuration supporting their targets. > Given that this patch series has been > out for a while now and has all the required acks, I would prefer to > commit it as is (with the small change requested by Julien) and make > changes for vexpress, sunxi, and others in follow-up patches. So let it be. *ANDRII ANISOV* ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/4] automation: remove dead code from containerize
On Sat, Jul 28, 2018 at 12:11:51PM -0500, Doug Goldstein wrote: > This is more dead code. > > Signed-off-by: Doug Goldstein Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/4] automation: ensure created are not owned as root
On Sat, Jul 28, 2018 at 12:11:52PM -0500, Doug Goldstein wrote: > By default the container runs as the root user and since the source tree > is bind mounted into the container, any file is created and owned by the > root user which harms ergonomics when working outside of the container > environment. This maps the root user within the container to the uid of > the user outside of the container so files are not owned by root. > > Signed-off-by: Doug Goldstein Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/4] automation: drop container name from containerize
On Sat, Jul 28, 2018 at 12:11:50PM -0500, Doug Goldstein wrote: > This was something that existed for some scripting support for a totally > unrelated project and when I copied this script I failed to remove it so > this removes it. Build containers for Xen are best as ephemeral > environments and should just utilizes Docker's default container naming > behavior. > > Signed-off-by: Doug Goldstein Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] automation: standardize containerize env names
On Sat, Jul 28, 2018 at 12:11:49PM -0500, Doug Goldstein wrote:
> # Figure out the base of what we want as our sources
> # by using the top of the git repo
> -if [[ -n ${WORKDIR} ]]; then
> -WORKDIR="${WORKDIR}"
> +if [[ -n ${CONTAINER_PATH} ]]; then
> +:
> else
> -WORKDIR=$(git rev-parse --show-toplevel)
> +CONTAINER_PATH=$(git rev-parse --show-toplevel)
I think you can use -z here and get rid of the empty branch?
The rest looks fine.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] automation: add CentOS 7.x image
On Sun, Jul 29, 2018 at 04:53:15PM -0500, Doug Goldstein wrote: > This image will always track the latest CentOS 7.x release. Add this > container to containerize for easy access. > > Signed-off-by: Doug Goldstein Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] ci: enable builds with CentOS 7.x
On Sun, Jul 29, 2018 at 04:53:16PM -0500, Doug Goldstein wrote: > Add the CentOS 7.x images to be used for build testing. > > Signed-off-by: Doug Goldstein Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.9-testing test] 125663: regressions - FAIL
flight 125663 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125663/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail in 125253 REGR. vs. 124248 test-amd64-amd64-libvirt-pair 23 guest-migrate/dst_host/src_host fail in 125253 REGR. vs. 124328 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-boot fail in 125253 pass in 125663 test-amd64-i386-libvirt-xsm 10 debian-install fail in 125253 pass in 125663 test-amd64-i386-xl-raw 10 debian-di-install fail in 125253 pass in 125663 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-saverestore.2 fail in 125642 pass in 125663 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 125253 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 125642 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail blocked in 124328 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 125253 like 124248 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 125253 like 124328 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 125253 like 124328 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 125253 like 124328 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigratefail like 124248 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124248 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 124248 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 124248 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeatfail like 124248 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 124328 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 124328 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 124328 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 124328 test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
[Xen-devel] [PATCH 0/4] This series improves the containerize script to hopefully make it more
friendly for folks to use to locally do build tests under different distros. Doug Goldstein (4): automation: standardize containerize env names automation: drop container name from containerize automation: remove dead code from containerize automation: ensure created are not owned as root automation/build/README.md | 15 +-- automation/scripts/containerize | 21 ++--- 2 files changed, 11 insertions(+), 25 deletions(-) base-commit: acd00a303378ce48bd6bbd8a579f1fe2f1b21a7d -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/2] automation: CentOS 7.x container
Add a CentOS 7.x container that tracks the latest CentOS 7 release along with the GitLab CI changes to build with it. A test run is available here: https://gitlab.com/cardoe/xen/pipelines/26695770 Doug Goldstein (2): automation: add CentOS 7.x image ci: enable builds with CentOS 7.x .gitlab-ci.yml | 16 +- automation/build/centos/7.dockerfile | 49 +- automation/scripts/containerize | 1 +- 3 files changed, 66 insertions(+) create mode 100644 automation/build/centos/7.dockerfile base-commit: acd00a303378ce48bd6bbd8a579f1fe2f1b21a7d -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 test] 125658: tolerable FAIL - PUSHED
flight 125658 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/125658/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail in 125649 pass in 125658 test-amd64-amd64-xl 18 guest-localmigrate/x10 fail pass in 125649 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail pass in 125649 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail like 125600 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeatfail like 125600 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125641 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125641 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125641 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125641 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125641 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125641 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass build-arm64-pvops 6 kernel-build fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linuxdbba166b0e442d4d38ae0f244d32338c3e92d16f baseline version: linux7612025fbc7a5ab54bf71f48b99b0b6a15fc7b06 Last test of basis 125641 2018-07-27 23:50:06 Z2 days Testing same since 125649 2018-07-29 01:15:18 Z1 days2 attempts
[Xen-devel] [freebsd-master test] 125673: regressions - trouble: blocked/fail
flight 125673 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/125673/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 125317 Tests which did not succeed, but are not blocking: build-amd64-freebsd-again 1 build-check(1) blocked n/a version targeted for testing: freebsd 48e7325363c5117801df79dd30d869b06fe60d30 baseline version: freebsd bf65d05707104df94117a293327d797d71a0118d Last test of basis 125317 2018-07-18 09:19:47 Z 12 days Failing since125467 2018-07-20 09:19:59 Z 10 days5 attempts Testing same since 125673 2018-07-30 09:18:54 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> alc allanjude andrew antoine asomers avg bde br brd bz cem cperciva cy dab daichi davidcs delphij dim eadler emaste eugen ganbold gavin gjb hselasky ian imp jhb jhibbits jhixson kevans kib leitao luporl lwhsu manu marius markj mav mm mmacy mmel np obrien oshogbo pkelsey pstef rmacklem royger rpokala rrs sef shurd trasz truckman tuexen uqs will woodsb02 wulf zleslie jobs: build-amd64-freebsd-againblocked build-amd64-freebsd 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 4025 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs
Hi Stefano, On 28/07/18 00:30, Stefano Stabellini wrote: On Fri, 27 Jul 2018, Julien Grall wrote: Hi Stefano, Sorry for the top posting. I think Andrii made a good point. With your new code MPSOC will get built on Arm 32 bit as well. This was not the case before this patch. So I would like at least that to be fixed before any commit. OK, this is a problem. I'll fix it. Looking into it I think there is a way to solve it that doesn't require duplication, and not even the introduction of ALL_32 and ALL_64: we just need to add "if ARM_64" for the ARM64 platforms and "if ARM_32" for the ARM32 platforms. So today we would have (the "if ARM_64" is new compared to this patch): config ALL bool "All Platforms" select MPSOC_PLATFORM if ARM_64 In the furure, assuming that we had EXYNOS5 and OMAP5 options, it would become: config ALL bool "All Platforms" select MPSOC_PLATFORM if ARM_64 select EXYNOS5 if ARM_32 select OMAP5 if ARM_32 What do you think? I think I would prefer the suggestion I made on Andrii's answer: choice config ALL_PLAT bool "All Platforms" "" endchoice config ALL_PLAT_64 default (ALL && ARM_64) config ALL_PLAT_32 default (ALL_PLAT && ARM_32) config MPSOC_PLATFORM bool default (ALL_PLAT_64 || MPSOC) This would avoid a long list in "ALL_PLATFORMS". Also, I just noticed that 'ALL' will become CONFIG_ALL. This is slightly too vague as a name. It would be better to include "PLAT" in it. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 19/21] xen/arm: introduce create_domUs
Hi Stefano, On 28/07/18 03:42, Stefano Stabellini wrote: On Tue, 24 Jul 2018, Julien Grall wrote: + +domain_unpause_by_systemcontroller(d); If a domain is bound to CPU0, then it will not boot until CPU0 is done with creating domain. Is that what you want? Are you suggesting to move the domain_unpause_by_systemcontroller(d) to a second loop after the domU creation loop? I was trying to understand what are the pro/cons of unpausing a DomU here. Did you explore it? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 125657: regressions - FAIL
flight 125657 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/125657/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 125648 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125648 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125648 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125648 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125648 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125648 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125648 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125648 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125648 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linuxa26fb01c2879ed7026e6cbd78bb701912d249eef baseline version: linuxdd63bf22fccd68913e3088c5ed5de3bf406a7546 Last test of basis 125648 2018-07-28 22:58:46 Z1 days Testing same since 125657 2018-07-29 16:03:35 Z0 days1 attempts People who touched revisions under test: Katsuhiro Suzuki Linus Torvalds Linus Walleij Masahiro Yamada Paul Burton Rafał Miłecki Theodore Ts'o jobs: build-amd64-xsm pass build-arm64-xsm
[Xen-devel] [distros-debian-sid test] 75026: tolerable FAIL
flight 75026 distros-debian-sid real [real] http://osstest.xensource.com/osstest/logs/75026/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-sid-netboot-pygrub 10 debian-di-install fail like 74997 test-amd64-amd64-i386-sid-netboot-pygrub 10 debian-di-install fail like 74997 test-amd64-i386-amd64-sid-netboot-pygrub 10 debian-di-install fail like 74997 test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 74997 test-amd64-amd64-amd64-sid-netboot-pvgrub 10 debian-di-install fail like 74997 baseline version: flight 74997 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-sid-netboot-pvgrubfail test-amd64-i386-i386-sid-netboot-pvgrub fail test-amd64-i386-amd64-sid-netboot-pygrub fail test-armhf-armhf-armhf-sid-netboot-pygrubfail test-amd64-amd64-i386-sid-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] linux-next: manual merge of the akpm-current tree with the xen-tip tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
drivers/xen/gntdev.c
between commit:
1d3145675538 ("xen/gntdev: Make private routines/structures accessible")
from the xen-tip tree and commit:
aaefcabe9c25 ("mm, oom: distinguish blockable mode for mmu notifiers")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/xen/gntdev.c
index c866a62f766d,55b4f0e3f4d6..
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@@ -479,7 -441,20 +479,20 @@@ static const struct vm_operations_struc
/* -- */
-static bool in_range(struct grant_map *map,
++static bool in_range(struct gntdev_grant_map *map,
+ unsigned long start, unsigned long end)
+ {
+ if (!map->vma)
+ return false;
+ if (map->vma->vm_start >= end)
+ return false;
+ if (map->vma->vm_end <= start)
+ return false;
+
+ return true;
+ }
+
-static void unmap_if_in_range(struct grant_map *map,
+static void unmap_if_in_range(struct gntdev_grant_map *map,
unsigned long start, unsigned long end)
{
unsigned long mstart, mend;
@@@ -503,15 -472,26 +510,26 @@@
WARN_ON(err);
}
- static void mn_invl_range_start(struct mmu_notifier *mn,
+ static int mn_invl_range_start(struct mmu_notifier *mn,
struct mm_struct *mm,
- unsigned long start, unsigned long end)
+ unsigned long start, unsigned long end,
+ bool blockable)
{
struct gntdev_priv *priv = container_of(mn, struct gntdev_priv, mn);
- struct grant_map *map;
+ struct gntdev_grant_map *map;
+ int ret = 0;
+
+ /* TODO do we really need a mutex here? */
+ if (blockable)
+ mutex_lock(>lock);
+ else if (!mutex_trylock(>lock))
+ return -EAGAIN;
- mutex_lock(>lock);
list_for_each_entry(map, >maps, next) {
+ if (in_range(map, start, end)) {
+ ret = -EAGAIN;
+ goto out_unlock;
+ }
unmap_if_in_range(map, start, end);
}
list_for_each_entry(map, >freeable_maps, next) {
pgpIoVVkPGNHq.pgp
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] firmware/shim : filter output files during Xen tree setup
>>> On 30.07.18 at 03:22, wrote:
> On Fri, Jul 27, 2018 at 1:34 AM, Jan Beulich wrote:
>
>> >>> On 26.07.18 at 23:16, wrote:
>> > Exclude named output files from the Xen tree setup.
>> >
>> > The linkfarm.stamp content will differ between top level "make"
>> > and "make install" invocations, due to the introduction of these
>> > output files that are produced during the "make" build.
>> >
>> > Filter these out to prevent an unnecessary rebuild of the shim
>> > during "make install", after "make" within a fresh source tree.
>> >
>> > Excluded from consideration with this change: differences in stamp
>> > content when performing incremental builds in an existing tree.
>>
>> I don't understand this (as well as you most recent remark on the
>> v2 thread): The "make install" invocation _is_ an incremental
>> rebuild. Hence I don't understand how excluding some but not all
>> generated files helps. But I'm not going to exclude that this is
>> simply because I don't understand well enough the logic in
>> xen-dir/Makefile when to trigger a rebuild.
>>
>>
>>
> OK, so "make install" is considered to be an incremental rebuild here -
> which makes sense - because in the implementation, it causes almost the
> same actions, within the same tree, as the preceding "make":
>
> "make" has the default target of all, which only depends on dist, dist
> depends on the dist-s, and those each depend on
> install-s. "make install" depends on install-s. A
> main difference with "make install" is the destination directories that are
> populated with the output.
>
> Here's what's actually going on: it's parallel builds that are not working
> correctly ("make -j ", where N>1). When multiple threads are available
> to build with, the tools build starts before the xen subsystem build
> finishes, so the first contents of linkfarm.stamp is a snapshot of a moving
> tree, and it ends up missing the final xen subsystem build products.
>
> The reason the v3 patch (mostly) works is that it lists the later build
> products of the xen subsystem. The earlier ones, such as the headers, are
> added to the xen tree long enough before the tools build gets started, so
> they are witnessed and captured in the linkfarm.stamp file. I say the v3
> patch mostly works, because I've found that its short exclusion list is
> missing "xen.gz.new", which is briefly present as a temporary file and can
> end up caught in the linkfarm.stamp file. It would need to be added to the
> exclusion list if continuing with that filtering approach.
>
> An alternative approach is to serialize the xen and tools subsystem builds
> in the top level Makefile, not allowing the tools build to proceed until
> the xen build is complete. I don't currently have a patch to propose to do
> this. In the absence of that in place, the workaround is simple: build just
> the xen subsystem alone first.
Thanks for the thorough analysis. I don't think the goal should be to
restrict the two builds to happen one after the other. Instead, as said
before, the goal ought to be to disregard _all_ generated files when
producing the stamp file.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen-netfront: wait xenbus state change when load module manually
Thanks, David On 07/29/2018 11:30 PM, David Miller wrote: From: Xiao Liang Date: Fri, 27 Jul 2018 17:56:08 +0800 @@ -1330,6 +1331,11 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev) netif_carrier_off(netdev); xenbus_switch_state(dev, XenbusStateInitialising); + wait_event(module_load_q, + xenbus_read_driver_state(dev->otherend) != + XenbusStateClosed && + xenbus_read_driver_state(dev->otherend) != + XenbusStateUnknown); return netdev; exit: What performs the wakeups that will trigger for this sleep site? In my understanding, backend leaving closed/unknow state can trigger the wakeups. I mean to make sure both sides are ready for creating connection. Thanks, Liang Thank you. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen-netfront: wait xenbus state change when load module manually
Thanks, Boris
Please see my reply inline.
On 07/28/2018 02:40 AM, Boris Ostrovsky wrote:
On 07/27/2018 05:56 AM, Xiao Liang wrote:
When loading module manually, after call xenbus_switch_state to initializes
the state of the netfront device, the driver state did not change so fast
that may lead no dev created in latest kernel. This patch adds wait to make
sure xenbus knows the driver is not in closed/unknown state.
Current state:
[vm]# ethtool eth0
Settings for eth0:
Link detected: yes
[vm]# modprobe -r xen_netfront
[vm]# modprobe xen_netfront
[vm]# ethtool eth0
Settings for eth0:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available
With the patch installed.
[vm]# ethtool eth0
Settings for eth0:
Link detected: yes
[vm]# modprobe -r xen_netfront
[vm]# modprobe xen_netfront
[vm]# ethtool eth0
Settings for eth0:
Link detected: yes
Signed-off-by: Xiao Liang
---
drivers/net/xen-netfront.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index a57daecf1d57..2d8812dd1534 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -87,6 +87,7 @@ struct netfront_cb {
/* IRQ name is queue name with "-tx" or "-rx" appended */
#define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3)
+static DECLARE_WAIT_QUEUE_HEAD(module_load_q);
static DECLARE_WAIT_QUEUE_HEAD(module_unload_q);
struct netfront_stats {
@@ -1330,6 +1331,11 @@ static struct net_device *xennet_create_dev(struct
xenbus_device *dev)
netif_carrier_off(netdev);
xenbus_switch_state(dev, XenbusStateInitialising);
+ wait_event(module_load_q,
+ xenbus_read_driver_state(dev->otherend) !=
+ XenbusStateClosed &&
+ xenbus_read_driver_state(dev->otherend) !=
+ XenbusStateUnknown);
return netdev;
exit:
Should we have a wake_up somewhere?
In my understanding, netback_changed handles it if dev state is in
XenbusStateInitialising and otherend is in XenbusStateInitWait, and then
create connection to backend.
But in most cases, it breaks out as dev->state not in
XenbusStateInitialising. So I added a wait here.
And what about other states --- is,
for example, XenbusStateClosing a valid reason to continue?
I think XenbusStateClosing should not be a valid reason to continue.
My purpose is waiting otherend status to be XenbusStateInitWait(after
new dev created).To avoid unnecessary impact, I only check it leaves
closed and unknow state in this patch.
In my testing, hotplug vifs from guest in host or load/unload module in
guest over 100 times, only waiting XenbusStateInitWait or as this patch
does, both are working.
vifs can be created each time successfully.
Thanks,
Xiao Liang
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] linux-next: build failure after merge of the xen-tip tree
From: Stephen Rothwell Date: Mon, 30 Jul 2018 15:08:21 +1000 Subject: [PATCH] xen/gntdev: fix up for attach callback API change Signed-off-by: Stephen Rothwell Thank you for your patch, Reviewed-by: Oleksandr Andrushchenko ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libgnttab: Add support for Linux dma-buf
On 07/25/2018 12:39 PM, Wei Liu wrote: On Mon, Jul 23, 2018 at 03:27:25PM +0300, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Add support for Linux grant device driver extension which allows converting existing dma-buf's into an array of grant references and vise versa. This is only implemented for Linux as other OSes have no Linux dma-buf support. Bump gnttab library minor version to 3. Signed-off-by: Oleksandr Andrushchenko Has the Linux side been merged yet? It is now merged [1] in Xen tip kernel tree Wei. [1] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/log/?h=linux-next ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 10/10] ALSA: xen: Use standard pcm_format_to_bits() for ALSA format bits
Hello, Takashi! Date: Wed, 25 Jul 2018 23:19:45 +0200 From: Takashi Iwai To: alsa-de...@alsa-project.org Subject: [alsa-devel] [PATCH 10/10] ALSA: xen: Use standard pcm_format_to_bits() for ALSA format bits Message-ID: <20180725211945.19222-11-ti...@suse.de> The open codes with the bit shift in xen_snd_front_alsa.c give sparse warnings as the PCM format type is with __bitwise. There is already a standard macro to get the format bits, so let's use it instead. This fixes sparse warnings like: sound/xen/xen_snd_front_alsa.c:191:47: warning: restricted snd_pcm_format_t degrades to integer Signed-off-by: Takashi Iwai --- sound/xen/xen_snd_front_alsa.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/xen/xen_snd_front_alsa.c b/sound/xen/xen_snd_front_alsa.c index 5a2bd70a2fa1..129180e17db1 100644 --- a/sound/xen/xen_snd_front_alsa.c +++ b/sound/xen/xen_snd_front_alsa.c @@ -188,7 +188,7 @@ static u64 to_sndif_formats_mask(u64 alsa_formats) mask = 0; for (i = 0; i < ARRAY_SIZE(ALSA_SNDIF_FORMATS); i++) - if (1 << ALSA_SNDIF_FORMATS[i].alsa & alsa_formats) + if (pcm_format_to_bits(ALSA_SNDIF_FORMATS[i].alsa) & alsa_formats) mask |= 1 << ALSA_SNDIF_FORMATS[i].sndif; return mask; @@ -202,7 +202,7 @@ static u64 to_alsa_formats_mask(u64 sndif_formats) mask = 0; for (i = 0; i < ARRAY_SIZE(ALSA_SNDIF_FORMATS); i++) if (1 << ALSA_SNDIF_FORMATS[i].sndif & sndif_formats) - mask |= 1 << ALSA_SNDIF_FORMATS[i].alsa; + mask |= pcm_format_to_bits(ALSA_SNDIF_FORMATS[i].alsa); return mask; } Thank you for your patch, Reviewed-by: Oleksandr Andrushchenko Thank you, Oleksandr ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable test] 125652: regressions - FAIL
On Mon, Jul 30, 2018 at 02:53:31AM +, osstest service owner wrote: > flight 125652 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/125652/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 > guest-localmigrate/x10 fail REGR. vs. 125178 This seems to have failed due to the kernel failing to suspend: [ 336.580230] Freezing remaining freezable tasks ... [ 356.590051] Freezing of tasks failed after 20.005 seconds (1 tasks refusing to freeze, wq_busy=0): [ 356.597842] jbd2/xvda5-8D 8109e380 0 113 2 0x [ 356.604353] 88002e967510 0046 00013200 88002ea0bfd8 [ 356.611377] 00013200 88002e967510 88002f813ab0 88002fbce0f8 [ 356.618587] 0002 811df230 88002ea0bc80 88002ea9bb98 [ 356.625475] Call Trace: [ 356.627738] [] ? generic_block_bmap+0x50/0x50 [ 356.633125] [] ? io_schedule+0x99/0x120 [ 356.637981] [] ? sleep_on_buffer+0xa/0x10 [ 356.643019] [] ? __wait_on_bit+0x5c/0x90 [ 356.647979] [] ? generic_block_bmap+0x50/0x50 [ 356.653302] [] ? out_of_line_wait_on_bit+0x77/0x90 [ 356.658992] [] ? autoremove_wake_function+0x30/0x30 [ 356.664861] [] ? jbd2_journal_commit_transaction+0x182a/0x1a30 [jbd2] [ 356.672028] [] ? kjournald2+0xb2/0x240 [jbd2] [ 356.677445] [] ? prepare_to_wait_event+0xf0/0xf0 [ 356.683095] [] ? commit_timeout+0x10/0x10 [jbd2] [ 356.688701] [] ? kthread+0xbd/0xe0 [ 356.693194] [] ? kthread_create_on_node+0x180/0x180 [ 356.698980] [] ? ret_from_fork+0x58/0x90 [ 356.704043] [] ? kthread_create_on_node+0x180/0x180 [ 356.709949] [ 356.711357] Restarting kernel threads ... done. [ 356.718027] xen:manage: do_suspend: freeze kernel threads failed -16 [ 356.723898] Restarting tasks ... done. I cannot figure out which task caused this however. Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
