(no subject)

(no subject)

[Ian Jackson]

This series removes the usleeps and waiting loops in libxl_dom.c and
replaces them with event-callback code.

Firstly, some documentation of things I had to reverse-engineer:
 01/23 xen: Document XEN_DOMCTL_subscribe
 02/23 xen: Document that EVTCHNOP_bind_interdomain signals
 03/23 docs: Document event-channel-based suspend protocol
 04/23 libxc: Document xenctrl.h event channel calls
Arguably these might be 4.4 material (hence the CC to George).

We want some additional libxl event facilities:
 05/23 libxl: init: Provide a gc later in libxl_ctx_alloc
 06/23 libxl: init: libxl__poller_init and _get take gc
 07/23 libxl: events: const-correct *_inuse, *_isregistered
 08/23 libxl: events: Provide libxl__xswait_*
 09/23 libxl: events: Use libxl__xswait_* in spawn code
 10/23 libxl: events: Provide libxl__ev_evtchn*

We need to clean up some unfortunate code in libxc:
 11/23 libxc: suspend: Rename, improve xc_suspend_evtchn_init
 12/23 libxc: suspend: Fix suspend event channel locking

We do some shuffling around of the libxl suspend control flow:
 13/23 libxl: suspend: Async libxl__domain_suspend_callback
 14/23 libxl: suspend: Async domain_suspend_callback_common
 15/23 libxl: suspend: Reorg domain_suspend_callback_common
 16/23 libxl: suspend: New libxl__domain_pvcontrol_xspath
 17/23 libxl: suspend: New domain_suspend_pvcontrol_acked
No functional change in those five.  These changes are broken down
just to make the changes reviewable.

Finally, we can start to work on the event code, removing the bugs,
usleeps and loops one at a time:
 18/23 libxl: suspend: domain_suspend_callback_common xs errs
 19/23 libxl: suspend: Async xenstore pvcontrol wait
 20/23 libxl: suspend: Abolish usleeps in domain suspend wait
 21/23 libxl: suspend: Fix suspend wait corner cases
 22/23 libxl: suspend: Async evtchn wait
 23/23 libxl: suspend: Apply guest timeout in evtchn case

I have tested this with a Debian pvops kernel (xenstore pvcontrol
suspend signalling) and OpenSUSE 11 (event channel suspend
signalling).

Shriram: I haven't really touched the Remus-specific code here but
this series ought to be suitable for you to base things on, assuming
my co-maintainers like the general approach.

Thanks,
Ian.

[PATCH 01/23] xen: Document XEN_DOMCTL_subscribe

[Ian Jackson]

Arguably this domctl is misnamed.  But, for now, document its actual
behaviour (reverse-engineered from the code and found in the commit
message for 4539594d46f9) under its actual name.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Shriram Rajagopalan <rshriram@cs.ubc.ca>
CC: Jan Beulich <JBeulich@suse.com>
---
 tools/libxc/xenctrl.h       |    4 +++-
 xen/include/public/domctl.h |   16 ++++++++++++++++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 6e58ebe..096a590 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1452,8 +1452,10 @@ int xc_version(xc_interface *xch, int cmd, void *arg);
 int xc_flask_op(xc_interface *xch, xen_flask_op_t *op);
 
 /*
- * Subscribe to state changes in a domain via evtchn.
+ * Subscribe to domain suspend via evtchn.
  * Returns -1 on failure, in which case errno will be set appropriately.
+ * Just calls XEN_DOMCTL_subscribe - see the caveats for that domctl
+ * (in its doc comment in domctl.h).
  */
 int xc_domain_subscribe_for_suspend(
     xc_interface *xch, domid_t domid, evtchn_port_t port);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 01a3652..91f01fa 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -619,6 +619,22 @@ typedef struct xen_domctl_cpuid xen_domctl_cpuid_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_cpuid_t);
 #endif
 
+/*
+ * Arranges that if the domain suspends (specifically, if it shuts
+ * down with code SHUTDOWN_suspend), this event channel will be
+ * notified.
+ *
+ * This is _instead of_ the usual notification to the global
+ * VIRQ_DOM_EXC.  (In most systems that pirq is owned by xenstored.)
+ *
+ * Only one subscription per domain is possible.  Last subscriber
+ * wins; others are silently displaced.
+ *
+ * NB that contrary to the rather general name, it only applies to
+ * domain shutdown with code suspend.  Shutdown for other reasons
+ * (including crash), and domain death, are notified to VIRQ_DOM_EXC
+ * regardless.
+ */
 /* XEN_DOMCTL_subscribe */
 struct xen_domctl_subscribe {
     uint32_t port; /* IN */
-- 
1.7.10.4

[PATCH 02/23] xen: Document that EVTCHNOP_bind_interdomain signals

[Ian Jackson]

EVTCHNOP_bind_interdomain signals the event channel.  Document this.

Also explain the usual use pattern.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
---
 xen/include/public/event_channel.h |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/xen/include/public/event_channel.h b/xen/include/public/event_channel.h
index b78ee32..49ac8cc 100644
--- a/xen/include/public/event_channel.h
+++ b/xen/include/public/event_channel.h
@@ -101,6 +101,17 @@ typedef struct evtchn_alloc_unbound evtchn_alloc_unbound_t;
  * a port that is unbound and marked as accepting bindings from the calling
  * domain. A fresh port is allocated in the calling domain and returned as
  * <local_port>.
+ *
+ * In case the peer domain has already tried to set our event channel
+ * pending, before it was bound, EVTCHNOP_bind_interdomain always sets
+ * the local event channel pending.
+ *
+ * The usual pattern of use, in the guest's upcall (or subsequent
+ * handler) is as follows: (Re-enable the event channel for subsequent
+ * signalling and then) check for the existence of whatever condition
+ * is being waited for by other means, and take whatever action is
+ * needed (if any).
+ *
  * NOTES:
  *  1. <remote_dom> may be DOMID_SELF, allowing loopback connections.
  */
-- 
1.7.10.4

[PATCH 03/23] docs: Document event-channel-based suspend protocol

[Ian Jackson]

Document the event channel protocol in xenstore-paths.markdown, in the
section for ~/device/suspend/event-channel.

Protocol reverse-engineered from commentary and commit messages of
  4539594d46f9  Add facility to get notification of domain suspend ...
  17636f47a474  Teach xc_save to use event-channel-based ...
and implementations in
  xc_save (current version)
  libxl (current version)
  linux-2.6.18-xen (mercurial 1241:2993033a77ca)

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Shriram Rajagopalan <rshriram@cs.ubc.ca>
---
 docs/misc/xenstore-paths.markdown |   23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-paths.markdown
index a0fc003..70ab7f4 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -143,10 +143,29 @@ The size of the video RAM this domain is configured with.
 
 #### ~/device/suspend/event-channel = ""|EVTCHN [w]
 
-The domain's suspend event channel. The use of a suspend event channel
-is optional at the domain's discretion. The toolstack will create this
+The domain's suspend event channel. The toolstack will create this
 path with an empty value which the guest may choose to overwrite.
 
+If the guest overwrites this, it will be with the number of an unbound
+event channel port it has acquired.  The toolstack is expected to use
+an interdomain bind, and then, when it wishes to ask the guest to
+suspend, to signal the event channel.
+
+The guest does not need to explicitly acknowledge the request; indeed,
+there is no explicit signalling by the guest in the reverse direction.
+The guest, when it is ready, simply shuts down (`SCHEDOP_shutdown`)
+with reason code `SHUTDOWN_suspend`.  The toolstack is expected to use
+`XEN_DOMCTL_subscribe` to be alerted to guest state changes, and
+`XEN_SYSCTL_getdomaininfolist` to verify that the domain has
+suspended.
+
+Note that the use of this event channel suspend protocol is optional
+for both sides.  By writing a non-empty string to the node, the guest
+is advertising its support.  However, the toolstack is at liberty to
+use the xenstore-based protocol instead (see ~/control/shutdown,
+below) even if the guest has advertised support for the event channel
+protocol.
+
 #### ~/hvmloader/generation-id-address = ADDRESS [r,HVM,INTERNAL]
 
 The hexadecimal representation of the address of the domain's
-- 
1.7.10.4

[PATCH 04/23] libxc: Document xenctrl.h event channel calls

[Ian Jackson]

Provide semantic documentation for how the libxc calls relate to the
hypervisor interface, and how they are to be used.

Also document the bug (present at least in Linux 3.12) that setting
the evtchn fd to nonblocking doesn't in fact make xc_evtchn_pending
nonblocking, and describe the appropriate workaround.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Jan Beulich <JBeulich@suse.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/libxc/xenctrl.h |   27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 096a590..13f816b 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1043,6 +1043,18 @@ int xc_evtchn_close(xc_evtchn *xce);
 
 /*
  * Return an fd that can be select()ed on.
+ *
+ * Note that due to bugs, setting this fd to non blocking may not
+ * work: you would hope that it would result in xc_evtchn_pending
+ * failing with EWOULDBLOCK if there are no events signaled, but in
+ * fact it may block.  (Bug is present in at least Linux 3.12, and
+ * perhaps on other platforms or later version.)
+ *
+ * To be safe, you must use poll() or select() before each call to
+ * xc_evtchn_pending.  If you have multiple threads (or processes)
+ * sharing a single xce handle this will not work, and there is no
+ * straightforward workaround.  Please design your program some other
+ * way.
  */
 int xc_evtchn_fd(xc_evtchn *xce);
 
@@ -1082,7 +1094,20 @@ int xc_evtchn_unbind(xc_evtchn *xce, evtchn_port_t port);
 
 /*
  * Return the next event channel to become pending, or -1 on failure, in which
- * case errno will be set appropriately.  
+ * case errno will be set appropriately.
+ *
+ * At the hypervisor level the event channel will have been masked,
+ * and then cleared, by the underlying machinery (evtchn kernel
+ * driver, or equivalent).  So if the event channel is signaled again
+ * after it is returned here, it will be queued up, and delivered
+ * again after you unmask it.  (See the documentation in the Xen
+ * public header event_channel.h.)
+ *
+ * On receiving the notification from xc_evtchn_pending, you should
+ * normally: check (by other means) what work needs doing; do the
+ * necessary work (if any); unmask the event channel with
+ * xc_evtchn_unmask (if you want to receive any further
+ * notifications).
  */
 evtchn_port_or_error_t
 xc_evtchn_pending(xc_evtchn *xce);
-- 
1.7.10.4

[PATCH 05/23] libxl: init: Provide a gc later in libxl_ctx_alloc

[Ian Jackson]

Provide libxl__gc *gc for the second half of libxl_ctx_alloc.
(For the first half of the function, gc is in scope but set to NULL.)

This makes it possible to make gc-requiring calls.  For example, it
makes error logging more convenient.

Make use of this by changing the logging calls to use the LOG*
convenience macros.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index e8ad610..cfd1435 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -25,6 +25,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags, xentoollog_logger * lg)
 {
     libxl_ctx *ctx = NULL;
+    libxl__gc gc_buf, *gc = NULL;
     int rc;
 
     if (version != LIBXL_VERSION) { rc = ERROR_VERSION; goto out; }
@@ -79,6 +80,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     }
 
     /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
+    LIBXL_INIT_GC(gc_buf,ctx);
+    gc = &gc_buf;
+    /* Now gc is useable */
 
     rc = libxl__atfork_init(ctx);
     if (rc) goto out;
@@ -88,8 +92,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     ctx->xch = xc_interface_open(lg,lg,0);
     if (!ctx->xch) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
-                        "cannot open libxc handle");
+        LOGEV(ERROR, errno, "cannot open libxc handle");
         rc = ERROR_FAIL; goto out;
     }
 
@@ -97,8 +100,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     if (!ctx->xsh)
         ctx->xsh = xs_domain_open();
     if (!ctx->xsh) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
-                        "cannot connect to xenstore");
+        LOGEV(ERROR, errno, "cannot connect to xenstore");
         rc = ERROR_FAIL; goto out;
     }
 
@@ -106,6 +108,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return 0;
 
  out:
+    if (gc) libxl__free_all(gc);
     libxl_ctx_free(ctx);
     *pctx = NULL;
     return rc;
-- 
1.7.10.4

[PATCH 06/23] libxl: init: libxl__poller_init and _get take gc

[Ian Jackson]

Change libxl__poller_init and libxl__poller__get to take a libxl__gc*
rather than a libxl_ctx*.  The gc is not used for memory allocation
but simply to provide the standard local variable "gc" expected by the
convenience macros.  Doing this makes the error logging more
convenient.

Hence, convert the logging calls to use the LOG* convenience macros.

And consequently, change the call sites, and the function bodies to
use CTX rather than ctx.

Also convert a call to malloc() (with error check) in
libxl__poller_get, to libxl__zalloc (no error check needed).

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |    2 +-
 tools/libxl/libxl_event.c    |   25 ++++++++++---------------
 tools/libxl/libxl_internal.h |    4 ++--
 3 files changed, 13 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index cfd1435..85b56a9 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -87,7 +87,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     rc = libxl__atfork_init(ctx);
     if (rc) goto out;
 
-    rc = libxl__poller_init(ctx, &ctx->poller_app);
+    rc = libxl__poller_init(gc, &ctx->poller_app);
     if (rc) goto out;
 
     ctx->xch = xc_interface_open(lg,lg,0);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index bdef7ac..9c4fe1c 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1274,7 +1274,7 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
  * Manipulation of pollers
  */
 
-int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
+int libxl__poller_init(libxl__gc *gc, libxl__poller *p)
 {
     int r, rc;
     p->fd_polls = 0;
@@ -1282,15 +1282,15 @@ int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
 
     r = pipe(p->wakeup_pipe);
     if (r) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot create poller pipe");
+        LOGE(ERROR, "cannot create poller pipe");
         rc = ERROR_FAIL;
         goto out;
     }
 
-    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[0], 1);
+    rc = libxl_fd_set_nonblock(CTX, p->wakeup_pipe[0], 1);
     if (rc) goto out;
 
-    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[1], 1);
+    rc = libxl_fd_set_nonblock(CTX, p->wakeup_pipe[1], 1);
     if (rc) goto out;
 
     return 0;
@@ -1308,25 +1308,20 @@ void libxl__poller_dispose(libxl__poller *p)
     free(p->fd_rindices);
 }
 
-libxl__poller *libxl__poller_get(libxl_ctx *ctx)
+libxl__poller *libxl__poller_get(libxl__gc *gc)
 {
     /* must be called with ctx locked */
     int rc;
 
-    libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
+    libxl__poller *p = LIBXL_LIST_FIRST(&CTX->pollers_idle);
     if (p) {
         LIBXL_LIST_REMOVE(p, entry);
         return p;
     }
 
-    p = malloc(sizeof(*p));
-    if (!p) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot allocate poller");
-        return 0;
-    }
-    memset(p, 0, sizeof(*p));
+    p = libxl__zalloc(NOGC, sizeof(*p));
 
-    rc = libxl__poller_init(ctx, p);
+    rc = libxl__poller_init(gc, p);
     if (rc) {
         free(p);
         return NULL;
@@ -1446,7 +1441,7 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     EGC_INIT(ctx);
     CTX_LOCK;
 
-    poller = libxl__poller_get(ctx);
+    poller = libxl__poller_get(gc);
     if (!poller) { rc = ERROR_FAIL; goto out; }
 
     for (;;) {
@@ -1622,7 +1617,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
     if (how) {
         ao->how = *how;
     } else {
-        ao->poller = libxl__poller_get(ctx);
+        ao->poller = libxl__poller_get(&ao->gc);
         if (!ao->poller) goto out;
     }
     libxl__log(ctx,XTL_DEBUG,-1,file,line,func,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1bd23ff..2712005 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -823,13 +823,13 @@ _hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
 
 /* Fills in, or disposes of, the resources held by, a poller whose
  * space the caller has allocated.  ctx must be locked. */
-_hidden int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
+_hidden int libxl__poller_init(libxl__gc *gc, libxl__poller *p);
 _hidden void libxl__poller_dispose(libxl__poller *p);
 
 /* Obtain a fresh poller from malloc or the idle list, and put it
  * away again afterwards.  _get can fail, returning NULL.
  * ctx must be locked. */
-_hidden libxl__poller *libxl__poller_get(libxl_ctx *ctx);
+_hidden libxl__poller *libxl__poller_get(libxl__gc *gc);
 _hidden void libxl__poller_put(libxl_ctx*, libxl__poller *p /* may be NULL */);
 
 /* Notifies whoever is polling using p that they should wake up.
-- 
1.7.10.4

[PATCH 07/23] libxl: events: const-correct *_inuse, *_isregistered

[Ian Jackson]

The comments for libxl__ev_time_isregistered and the corresponding
watch function even say that these should be const.  Make it so.

Also fix libxl__ev_child_inuse and libxl__ev_spawn_inuse.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2712005..51d6c6d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -716,7 +716,7 @@ _hidden int libxl__ev_fd_modify(libxl__gc*, libxl__ev_fd *ev,
 _hidden void libxl__ev_fd_deregister(libxl__gc*, libxl__ev_fd *ev);
 static inline void libxl__ev_fd_init(libxl__ev_fd *efd)
                     { efd->fd = -1; }
-static inline int libxl__ev_fd_isregistered(libxl__ev_fd *efd)
+static inline int libxl__ev_fd_isregistered(const libxl__ev_fd *efd)
                     { return efd->fd >= 0; }
 
 _hidden int libxl__ev_time_register_rel(libxl__gc*, libxl__ev_time *ev_out,
@@ -732,7 +732,7 @@ _hidden int libxl__ev_time_modify_abs(libxl__gc*, libxl__ev_time *ev,
 _hidden void libxl__ev_time_deregister(libxl__gc*, libxl__ev_time *ev);
 static inline void libxl__ev_time_init(libxl__ev_time *ev)
                 { ev->func = 0; }
-static inline int libxl__ev_time_isregistered(libxl__ev_time *ev)
+static inline int libxl__ev_time_isregistered(const libxl__ev_time *ev)
                 { return !!ev->func; }
 
 
@@ -772,7 +772,7 @@ _hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
                                  libxl__ev_child_callback *death);
 static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
                 { childw_out->pid = -1; }
-static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+static inline int libxl__ev_child_inuse(const libxl__ev_child *childw_out)
                 { return childw_out->pid >= 0; }
 
 /* Useable (only) in the child to once more make the ctx useable for
@@ -1213,7 +1213,7 @@ struct libxl__spawn_state {
     libxl__ev_xswatch xswatch;
 };
 
-static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
+static inline int libxl__spawn_inuse(const libxl__spawn_state *ss)
     { return libxl__ev_child_inuse(&ss->mid); }
 
 /*
-- 
1.7.10.4

[PATCH 08/23] libxl: events: Provide libxl__xswait_*

[Ian Jackson]

This is an ao utility for for conveniently doing a timed wait on
xenstore.  It handles setting up and cancelling the timeout, and also
conveniently reads the key for you.

No callers yet in this patch.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_aoutils.c  |   77 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   52 ++++++++++++++++++++++++++++
 2 files changed, 129 insertions(+)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index b4eb6e5..477717b 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -16,6 +16,83 @@
 
 #include "libxl_internal.h"
 
+/*----- xswait -----*/
+
+static libxl__ev_xswatch_callback xswait_xswatch_callback;
+static libxl__ev_time_callback xswait_timeout_callback;
+static void xswait_report_error(libxl__egc*, libxl__xswait_state*, int rc);
+
+void libxl__xswait_init(libxl__xswait_state *xswa)
+{
+    libxl__ev_time_init(&xswa->time_ev);
+    libxl__ev_xswatch_init(&xswa->watch_ev);
+}
+
+void libxl__xswait_stop(libxl__gc *gc, libxl__xswait_state *xswa)
+{
+    libxl__ev_time_deregister(gc, &xswa->time_ev);
+    libxl__ev_xswatch_deregister(gc, &xswa->watch_ev);
+}
+
+bool libxl__xswait_inuse(const libxl__xswait_state *xswa)
+{
+    bool time_inuse = libxl__ev_time_isregistered(&xswa->time_ev);
+    bool watch_inuse = libxl__ev_xswatch_isregistered(&xswa->watch_ev);
+    assert(time_inuse == watch_inuse);
+    return time_inuse;
+}
+
+int libxl__xswait_start(libxl__gc *gc, libxl__xswait_state *xswa)
+{
+    int rc;
+
+    rc = libxl__ev_time_register_rel(gc, &xswa->time_ev,
+                                     xswait_timeout_callback, xswa->timeout_ms);
+    if (rc) goto err;
+
+    rc = libxl__ev_xswatch_register(gc, &xswa->watch_ev,
+                                    xswait_xswatch_callback, xswa->path);
+    if (rc) goto err;
+
+    return 0;
+
+ err:
+    libxl__xswait_stop(gc, xswa);
+    return rc;
+}
+
+void xswait_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *xsw,
+                             const char *watch_path, const char *event_path)
+{
+    EGC_GC;
+    libxl__xswait_state *xswa = CONTAINER_OF(xsw, *xswa, watch_ev);
+    int rc;
+    const char *data;
+
+    rc = libxl__xs_read_checked(gc, XBT_NULL, xswa->path, &data);
+    if (rc) { xswait_report_error(egc, xswa, rc); return; }
+
+    xswa->callback(egc, xswa, 0, data);
+}
+
+void xswait_timeout_callback(libxl__egc *egc, libxl__ev_time *ev,
+                             const struct timeval *requested_abs)
+{
+    EGC_GC;
+    libxl__xswait_state *xswa = CONTAINER_OF(ev, *xswa, time_ev);
+    LOG(DEBUG, "%s: xswait timeout (path=%s)", xswa->what, xswa->path);
+    xswait_report_error(egc, xswa, ERROR_TIMEDOUT);
+}
+
+static void xswait_report_error(libxl__egc *egc, libxl__xswait_state *xswa,
+                                int rc)
+{
+    EGC_GC;
+    libxl__xswait_stop(gc, xswa);
+    xswa->callback(egc, xswa, rc, 0);
+}
+
+
 /*----- data copier -----*/
 
 void libxl__datacopier_init(libxl__datacopier_state *dc)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 51d6c6d..36de135 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1068,6 +1068,58 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
                                       libxl_device_pci *pcidev, int num);
 _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
 
+/*----- xswait: wait for a xenstore node to be suitable -----*/
+
+typedef struct libxl__xswait_state libxl__xswait_state;
+
+/*
+ * rc describes the circumstances of this callback:
+ *
+ * rc==0
+ *
+ *     The xenstore path (may have) changed.  It has been read for
+ *     you.  The result is in data (allocated from the ao gc).
+ *     data may be NULL, which means that the xenstore read gave
+ *     ENOENT.
+ *
+ *     If you are satisfied, you MUST call libxl__xswait_stop.
+ *     Otherwise, xswait will continue waiting and watching and
+ *     will call you back later.
+ *
+ * rc==ETIMEDOUT
+ *
+ *     The specified timeout was reached.
+ *     This has NOT been logged (except to the debug log).
+ *     xswait will not continue (but calling libxl__xswait_stop is OK).
+ *
+ * rc!=0
+ *
+ *     Some other error occurred.
+ *     This HAS been logged.
+ *     xswait will not continue (but calling libxl__xswait_stop is OK).
+ *
+ */
+typedef void libxl__xswait_callback(libxl__egc *egc,
+      libxl__xswait_state *xswa, int rc, const char *data);
+
+struct libxl__xswait_state {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ao *ao;
+    const char *what; /* for error msgs: noun phrase, what we're waiting for */
+    const char *path;
+    int timeout_ms; /* as for poll(2) */
+    libxl__xswait_callback *callback;
+    /* remaining fields are private to xswait */
+    libxl__ev_time time_ev;
+    libxl__ev_xswatch watch_ev;
+};
+
+void libxl__xswait_init(libxl__xswait_state*);
+void libxl__xswait_stop(libxl__gc*, libxl__xswait_state*); /*idempotent*/
+bool libxl__xswait_inuse(const libxl__xswait_state *ss);
+
+int libxl__xswait_start(libxl__gc*, libxl__xswait_state*);
+
 /*
  *----- spawn -----
  *
-- 
1.7.10.4

[PATCH 09/23] libxl: events: Use libxl__xswait_* in spawn code

[Ian Jackson]

Replace open-coded use of ev_time and ev_xswatch with xswait.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_exec.c     |   49 +++++++++++++++---------------------------
 tools/libxl/libxl_internal.h |    3 +--
 2 files changed, 18 insertions(+), 34 deletions(-)

diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index b6efa0f..4b012dc 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -257,10 +257,8 @@ err:
  */
 
 /* Event callbacks. */
-static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
-                              const char *watch_path, const char *event_path);
-static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
-                          const struct timeval *requested_abs);
+static void spawn_watch_event(libxl__egc *egc, libxl__xswait_state *xswa,
+                              int rc, const char *xsdata);
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status);
 
@@ -274,8 +272,7 @@ static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss);
 void libxl__spawn_init(libxl__spawn_state *ss)
 {
     libxl__ev_child_init(&ss->mid);
-    libxl__ev_time_init(&ss->timeout);
-    libxl__ev_xswatch_init(&ss->xswatch);
+    libxl__xswait_init(&ss->xswait);
 }
 
 int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
@@ -288,12 +285,12 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     libxl__spawn_init(ss);
     ss->failed = ss->detaching = 0;
 
-    rc = libxl__ev_time_register_rel(gc, &ss->timeout,
-                                     spawn_timeout, ss->timeout_ms);
-    if (rc) goto out_err;
-
-    rc = libxl__ev_xswatch_register(gc, &ss->xswatch,
-                                    spawn_watch_event, ss->xspath);
+    ss->xswait.ao = ao;
+    ss->xswait.what = GCSPRINTF("%s startup", ss->what);
+    ss->xswait.path = ss->xspath;
+    ss->xswait.timeout_ms = ss->timeout_ms;
+    ss->xswait.callback = spawn_watch_event;
+    rc = libxl__xswait_start(gc, &ss->xswait);
     if (rc) goto out_err;
 
     pid_t middle = libxl__ev_child_fork(gc, &ss->mid, spawn_middle_death);
@@ -350,8 +347,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
     assert(!libxl__ev_child_inuse(&ss->mid));
-    libxl__ev_time_deregister(gc, &ss->timeout);
-    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+    libxl__xswait_stop(gc, &ss->xswait);
 }
 
 static void spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
@@ -362,8 +358,7 @@ static void spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
     int r;
 
     assert(libxl__ev_child_inuse(&ss->mid));
-    libxl__ev_time_deregister(gc, &ss->timeout);
-    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+    libxl__xswait_stop(gc, &ss->xswait);
 
     pid_t child = ss->mid.pid;
     r = kill(child, SIGKILL);
@@ -387,25 +382,15 @@ static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss)
     spawn_detach(gc, ss);
 }
 
-static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
-                          const struct timeval *requested_abs)
-{
-    /* Before event, was Attached. */
-    EGC_GC;
-    libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
-    LOG(ERROR, "%s: startup timed out", ss->what);
-    spawn_fail(egc, ss); /* must be last */
-}
-
-static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
-                              const char *watch_path, const char *event_path)
+static void spawn_watch_event(libxl__egc *egc, libxl__xswait_state *xswa,
+                              int rc, const char *p)
 {
     /* On entry, is Attached. */
     EGC_GC;
-    libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
-    char *p = libxl__xs_read(gc, 0, ss->xspath);
-    if (!p && errno != ENOENT) {
-        LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
+    libxl__spawn_state *ss = CONTAINER_OF(xswa, *ss, xswait);
+    if (rc) {
+        if (rc == ERROR_TIMEDOUT)
+            LOG(ERROR, "%s: startup timed out", ss->what);
         spawn_fail(egc, ss); /* must be last */
         return;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 36de135..5d2e651 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1261,8 +1261,7 @@ struct libxl__spawn_state {
     int detaching; /* we are in Detaching */
     int failed; /* might be true whenever we are not Idle */
     libxl__ev_child mid; /* always in use whenever we are not Idle */
-    libxl__ev_time timeout;
-    libxl__ev_xswatch xswatch;
+    libxl__xswait_state xswait;
 };
 
 static inline int libxl__spawn_inuse(const libxl__spawn_state *ss)
-- 
1.7.10.4

[PATCH 10/23] libxl: events: Provide libxl__ev_evtchn*

[Ian Jackson]

This also involves providing a gc for the latter part of
libxl_ctx_alloc.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |    9 +++
 tools/libxl/libxl_event.c    |  152 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   48 +++++++++++++
 3 files changed, 209 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 85b56a9..51158aa 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -60,6 +60,10 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_SLIST_INIT(&ctx->watch_freeslots);
     libxl__ev_fd_init(&ctx->watch_efd);
 
+    ctx->xce = 0;
+    LIBXL_LIST_INIT(&ctx->evtchns_waiting);
+    libxl__ev_fd_init(&ctx->evtchn_efd);
+
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
@@ -104,6 +108,8 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
         rc = ERROR_FAIL; goto out;
     }
 
+    rc = libxl__ctx_evtchn_init(gc);
+
     *pctx = ctx;
     return 0;
 
@@ -147,16 +153,19 @@ int libxl_ctx_free(libxl_ctx *ctx)
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
     libxl__ev_fd_deregister(gc, &ctx->watch_efd);
+    libxl__ev_fd_deregister(gc, &ctx->evtchn_efd);
     libxl__ev_fd_deregister(gc, &ctx->sigchld_selfpipe_efd);
 
     /* Now there should be no more events requested from the application: */
 
     assert(LIBXL_LIST_EMPTY(&ctx->efds));
     assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
+    assert(LIBXL_LIST_EMPTY(&ctx->evtchns_waiting));
 
     if (ctx->xch) xc_interface_close(ctx->xch);
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
+    if (ctx->xce) xc_evtchn_close(ctx->xce);
 
     libxl__poller_dispose(&ctx->poller_app);
     assert(LIBXL_LIST_EMPTY(&ctx->pollers_event));
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 9c4fe1c..838b620 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -614,6 +614,158 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
 }
 
 /*
+ * evtchn
+ */
+
+static int evtchn_revents_check(libxl__egc *egc, int revents)
+{
+    EGC_GC;
+
+    if (revents & ~POLLIN) {
+        LOG(ERROR, "unexpected poll event on event channel fd: %x", revents);
+        LIBXL__EVENT_DISASTER(egc,
+                   "unexpected poll event on event channel fd", 0, 0);
+        libxl__ev_fd_deregister(gc, &CTX->evtchn_efd);
+        return ERROR_FAIL;
+    }
+
+    assert(revents & POLLIN);
+
+    return 0;
+}
+
+static void evtchn_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
+                               int fd, short events, short revents)
+{
+    EGC_GC;
+    libxl__ev_evtchn *evev;
+    int port, r, rc;
+    struct pollfd recheck;
+
+    rc = evtchn_revents_check(egc, revents);
+    if (rc) return;
+
+    for (;;) {
+        /* Check the fd again.  The incoming revent may no longer be
+         * true, because the libxl ctx lock has not necessarily been
+         * held continuously since someone noticed the fd.  Normally
+         * this wouldn't be a problem but evtchn devices don't always
+         * honour O_NONBLOCK (see xenctrl.h). */
+
+        recheck.fd = fd;
+        recheck.events = POLLIN;
+        recheck.revents = 0;
+        r = poll(&recheck, 1, 0);
+        DBG("ev_evtchn recheck r=%d revents=%#x", r, recheck.revents);
+        if (r < 0) {
+            LIBXL__EVENT_DISASTER(egc,
+     "unexpected failure polling event channel fd for recheck",
+                                  errno, 0);
+            return;
+        }
+        if (r == 0)
+            break;
+        rc = evtchn_revents_check(egc, recheck.revents);
+        if (rc) return;
+
+        /* OK, that's that workaround done.  We can actually check for
+         * work for us to do: */
+
+        port = xc_evtchn_pending(CTX->xce);
+        if (port < 0) {
+            if (errno == EAGAIN)
+                break;
+            LIBXL__EVENT_DISASTER(egc,
+     "unexpected failure fetching occurring event port number from evtchn",
+                                  errno, 0);
+            return;
+        }
+
+        LIBXL_LIST_FOREACH(evev, &CTX->evtchns_waiting, entry)
+            if (port == evev->port)
+                goto found;
+        /* not found */
+        DBG("ev_evtchn port=%d no-one cared", port);
+        continue;
+
+    found:
+        DBG("ev_evtchn=%p port=%d signaled", evev, port);
+        evev->waiting = 0;
+        LIBXL_LIST_REMOVE(evev, entry);
+        evev->callback(egc, evev);
+    }
+}
+
+int libxl__ctx_evtchn_init(libxl__gc *gc) {
+    xc_evtchn *xce;
+    int rc, fd;
+
+    if (CTX->xce)
+        return 0;
+
+    xce = xc_evtchn_open(CTX->lg, 0);
+    if (!xce) {
+        LOGE(ERROR,"cannot open libxc evtchn handle");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    fd = xc_evtchn_fd(xce);
+    assert(fd >= 0);
+
+    rc = libxl_fd_set_nonblock(CTX, fd, 1);
+    if (rc) goto out;
+
+    rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd,
+                               evtchn_fd_callback, fd, POLLIN);
+    if (rc) goto out;
+
+    CTX->xce = xce;
+    return 0;
+
+ out:
+    xc_evtchn_close(xce);
+    return rc;
+}
+
+int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
+{
+    int r, rc;
+
+    DBG("ev_evtchn=%p port=%d wait (was waiting=%d)",
+        evev, evev->port, evev->waiting);
+
+    if (evev->waiting)
+        return 0;
+
+    r = xc_evtchn_unmask(CTX->xce, evev->port);
+    if (r) {
+        LOGE(ERROR,"cannot unmask event channel %d",evev->port);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    evev->waiting = 1;
+    LIBXL_LIST_INSERT_HEAD(&CTX->evtchns_waiting, evev, entry);
+    return 0;
+
+ out:
+    return rc;
+}
+
+void libxl__ev_evtchn_cancel(libxl__gc *gc, libxl__ev_evtchn *evev)
+{
+    DBG("ev_evtchn=%p port=%d cancel (was waiting=%d)",
+        evev, evev->port, evev->waiting);
+
+    if (!evev->waiting)
+        return;
+
+    evev->waiting = 0;
+    LIBXL_LIST_REMOVE(evev, entry);
+}
+
+/*
  * waiting for device state
  */
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5d2e651..c519abc 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -197,6 +197,17 @@ struct libxl__ev_xswatch {
     uint32_t counterval;
 };
 
+typedef struct libxl__ev_evtchn libxl__ev_evtchn;
+typedef void libxl__ev_evtchn_callback(libxl__egc *egc, libxl__ev_evtchn*);
+struct libxl__ev_evtchn {
+    /* caller must fill these in, and they must all remain valid */
+    libxl__ev_evtchn_callback *callback;
+    int port;
+    /* remainder is private for libxl__ev_evtchn_... */
+    bool waiting;
+    LIBXL_LIST_ENTRY(libxl__ev_evtchn) entry;
+};
+
 /*
  * An entry in the watch_slots table is either:
  *  1. an entry in the free list, ie NULL or pointer to next free list entry
@@ -343,6 +354,10 @@ struct libxl__ctx {
     uint32_t watch_counter; /* helps disambiguate slot reuse */
     libxl__ev_fd watch_efd;
 
+    xc_evtchn *xce; /* for waiting use only libxl__ev_evtchn* */
+    LIBXL_LIST_HEAD(, libxl__ev_evtchn) evtchns_waiting;
+    libxl__ev_fd evtchn_efd;
+
     LIBXL_TAILQ_HEAD(libxl__evgen_domain_death_list, libxl_evgen_domain_death)
         death_list /* sorted by domid */,
         death_reported;
@@ -748,6 +763,39 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * The evtchn facility is one-shot per call t libxl__ev_evtchn_wait.
+ * You should call some suitable xc bind function on (or to obtain)
+ * the port, then libxl__ev_evtchn_wait.
+ *
+ * When the event is signaled then the callback will be made, once.
+ * Then you must call libxl__ev_evtchn_wait again, if desired.
+ *
+ * You must NOT call xc_evtchn_unmask.  wait will do that for you.
+ *
+ * Calling libxl__ev_evtchn_cancel will arrange for libxl to disregard
+ * future occurrences of event.  Both libxl__ev_evtchn_wait and
+ * libxl__ev_evtchn_cancel are idempotent.
+ *
+ * (Note of course that an event channel becomes signaled when it is
+ * first bound, so you will get one call to libxl__ev_evtchn_wait
+ * "right away"; unless you have won a very fast race, the condition
+ * you were waiting for won't exist yet so when you check for it
+ * you'll find you need to call wait again.)
+ *
+ * You must not wait on the same port twice at once (that is, with
+ * two separate libxl__ev_evtchn's).
+ */
+_hidden int libxl__ev_evtchn_wait(libxl__gc*, libxl__ev_evtchn *evev);
+_hidden void libxl__ev_evtchn_cancel(libxl__gc *gc, libxl__ev_evtchn *evev);
+
+static inline void libxl__ev_evtchn_init(libxl__ev_evtchn *evev)
+                { evev->waiting = 0; }
+static inline bool libxl__ev_evtchn_iswaiting(const libxl__ev_evtchn *evev)
+                { return evev->waiting; }
+
+_hidden int libxl__ctx_evtchn_init(libxl__gc *gc); /* for libxl_ctx_alloc */
+
+/*
  * For making subprocesses.  This is the only permitted mechanism for
  * code in libxl to do so.
  *
-- 
1.7.10.4

[PATCH 11/23] libxc: suspend: Rename, improve xc_suspend_evtchn_init

[Ian Jackson]

xc_suspend_evtchn_init expects to eat the first event on the xce.  If
the xce is used for any other purpose then this can break.  Document
this fact and rename the function to xc_suspend_evtchn_init_exclusive.
(I haven't checked the call sites for improper shared use of the xce.)

Provide a corresponding xc_suspend_evtchn_init_sane which doesn't try
to eat an event, and instead leaves the caller the ability to
demultiplex.

Also document that xc_await_suspend needs exclusive use of the xce.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Shriram Rajagopalan <rshriram@cs.ubc.ca>
---
 tools/libxc/xc_suspend.c                           |   21 ++++++++++++++++----
 tools/libxc/xenguest.h                             |   13 +++++++++++-
 tools/libxl/libxl_dom.c                            |    2 +-
 tools/misc/xen-hptool.c                            |    2 +-
 .../python/xen/lowlevel/checkpoint/libcheckpoint.c |    2 +-
 tools/xcutils/xc_save.c                            |    2 +-
 6 files changed, 33 insertions(+), 9 deletions(-)

diff --git a/tools/libxc/xc_suspend.c b/tools/libxc/xc_suspend.c
index 1ace411..7968a44 100644
--- a/tools/libxc/xc_suspend.c
+++ b/tools/libxc/xc_suspend.c
@@ -14,6 +14,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
  */
 
+#include <assert.h>
+
 #include "xc_private.h"
 #include "xenguest.h"
 
@@ -102,7 +104,7 @@ int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int domid, int
     return unlock_suspend_event(xch, domid);
 }
 
-int xc_suspend_evtchn_init(xc_interface *xch, xc_evtchn *xce, int domid, int port)
+int xc_suspend_evtchn_init_sane(xc_interface *xch, xc_evtchn *xce, int domid, int port)
 {
     int rc, suspend_evtchn = -1;
 
@@ -121,9 +123,6 @@ int xc_suspend_evtchn_init(xc_interface *xch, xc_evtchn *xce, int domid, int por
         goto cleanup;
     }
 
-    /* event channel is pending immediately after binding */
-    xc_await_suspend(xch, xce, suspend_evtchn);
-
     return suspend_evtchn;
 
 cleanup:
@@ -132,3 +131,17 @@ cleanup:
 
     return -1;
 }
+
+int xc_suspend_evtchn_init_exclusive(xc_interface *xch, xc_evtchn *xce, int domid, int port)
+{
+    int suspend_evtchn;
+
+    suspend_evtchn = xc_suspend_evtchn_init_sane(xch, xce, domid, port);
+    if (suspend_evtchn < 0)
+        return suspend_evtchn;
+
+    /* event channel is pending immediately after binding */
+    xc_await_suspend(xch, xce, suspend_evtchn);
+
+    return suspend_evtchn;
+}
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index a0e30e1..ce5456c 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -256,10 +256,21 @@ int xc_hvm_build_target_mem(xc_interface *xch,
 
 int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int domid, int suspend_evtchn);
 
-int xc_suspend_evtchn_init(xc_interface *xch, xc_evtchn *xce, int domid, int port);
+/**
+ * This function eats the initial notification.
+ * xce must not be used for anything else
+ */
+int xc_suspend_evtchn_init_exclusive(xc_interface *xch, xc_evtchn *xce, int domid, int port);
 
+/* xce must not be used for anything else */
 int xc_await_suspend(xc_interface *xch, xc_evtchn *xce, int suspend_evtchn);
 
+/**
+ * The port will be signaled immediately after this call
+ * The caller should check the domain status and look for the next event
+ */
+int xc_suspend_evtchn_init_sane(xc_interface *xch, xc_evtchn *xce, int domid, int port);
+
 int xc_get_bit_size(xc_interface *xch,
                     const char *image_name, const char *cmdline,
                     const char *features, int *type);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 55f74b2..4b42856 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1358,7 +1358,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 
         if (port >= 0) {
             dss->suspend_eventchn =
-                xc_suspend_evtchn_init(CTX->xch, dss->xce, dss->domid, port);
+                xc_suspend_evtchn_init_exclusive(CTX->xch, dss->xce, dss->domid, port);
 
             if (dss->suspend_eventchn < 0)
                 LOG(WARN, "Suspend event channel initialization failed");
diff --git a/tools/misc/xen-hptool.c b/tools/misc/xen-hptool.c
index 24c3e95..db76f79 100644
--- a/tools/misc/xen-hptool.c
+++ b/tools/misc/xen-hptool.c
@@ -112,7 +112,7 @@ static int suspend_guest(xc_interface *xch, xc_evtchn *xce, int domid, int *evtc
         fprintf(stderr, "DOM%d: No suspend port, try live migration\n", domid);
         goto failed;
     }
-    suspend_evtchn = xc_suspend_evtchn_init(xch, xce, domid, port);
+    suspend_evtchn = xc_suspend_evtchn_init_exclusive(xch, xce, domid, port);
     if (suspend_evtchn < 0)
     {
         fprintf(stderr, "Suspend evtchn initialization failed\n");
diff --git a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
index 01c0d47..817d272 100644
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
@@ -360,7 +360,7 @@ static int setup_suspend_evtchn(checkpoint_state* s)
     return -1;
   }
 
-  s->suspend_evtchn = xc_suspend_evtchn_init(s->xch, s->xce, s->domid, port);
+  s->suspend_evtchn = xc_suspend_evtchn_init_exclusive(s->xch, s->xce, s->domid, port);
   if (s->suspend_evtchn < 0) {
       s->errstr = "failed to bind suspend event channel";
       return -1;
diff --git a/tools/xcutils/xc_save.c b/tools/xcutils/xc_save.c
index e34bd2c..974f706 100644
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -202,7 +202,7 @@ main(int argc, char **argv)
         else
         {
             si.suspend_evtchn =
-              xc_suspend_evtchn_init(si.xch, si.xce, si.domid, port);
+              xc_suspend_evtchn_init_exclusive(si.xch, si.xce, si.domid, port);
 
             if (si.suspend_evtchn < 0)
                 warnx("suspend event channel initialization failed, "
-- 
1.7.10.4

[PATCH 12/23] libxc: suspend: Fix suspend event channel locking

[Ian Jackson]

Use fcntl F_SETLK, rather than writing our pid into a "lock" file.
That way if we crash we don't leave the lockfile lying about.  Callers
now need to keep the fd for our lockfile.  (We don't use flock because
we don't want anyone who inherits this fd across fork to end up with a
handle onto the lock.)

While we are here:
 * Move the lockfile to /var/run/xen
 * De-duplicate the calculation of the pathname
 * Compute the buffer size for the pathname so that it will definitely
   not overrun (and use the computed value everywhere)
 * Fix various error handling bugs

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Shriram Rajagopalan <rshriram@cs.ubc.ca>
---
 tools/libxc/xc_suspend.c                           |  159 +++++++++++++-------
 tools/libxc/xenguest.h                             |   16 +-
 tools/libxl/libxl_dom.c                            |    6 +-
 tools/libxl/libxl_internal.h                       |    1 +
 tools/misc/xen-hptool.c                            |   19 ++-
 tools/python/xen/lowlevel/checkpoint/checkpoint.h  |    2 +-
 .../python/xen/lowlevel/checkpoint/libcheckpoint.c |    7 +-
 tools/xcutils/xc_save.c                            |    8 +-
 8 files changed, 149 insertions(+), 69 deletions(-)

diff --git a/tools/libxc/xc_suspend.c b/tools/libxc/xc_suspend.c
index 7968a44..f0f70c1 100644
--- a/tools/libxc/xc_suspend.c
+++ b/tools/libxc/xc_suspend.c
@@ -15,66 +15,115 @@
  */
 
 #include <assert.h>
+#include <unistd.h>
+#include <fcntl.h>
 
 #include "xc_private.h"
 #include "xenguest.h"
 
-#define SUSPEND_LOCK_FILE "/var/lib/xen/suspend_evtchn"
-static int lock_suspend_event(xc_interface *xch, int domid)
+#define SUSPEND_LOCK_FILE "/var/run/xen/suspend-evtchn-%d.lock"
+
+/*
+ * locking
+ */
+
+#define ERR(x) do{                                                      \
+    ERROR("Can't " #x " lock file for suspend event channel %s: %s\n",  \
+          suspend_file, strerror(errno));                               \
+    goto err;                                                           \
+}while(0)
+
+#define SUSPEND_FILE_BUFLEN (sizeof(SUSPEND_LOCK_FILE) + 10)
+
+static void get_suspend_file(char buf[SUSPEND_FILE_BUFLEN], int domid)
 {
-    int fd, rc;
-    mode_t mask;
-    char buf[128];
-    char suspend_file[256];
-
-    snprintf(suspend_file, sizeof(suspend_file), "%s_%d_lock.d",
-	    SUSPEND_LOCK_FILE, domid);
-    mask = umask(022);
-    fd = open(suspend_file, O_CREAT | O_EXCL | O_RDWR, 0666);
-    if (fd < 0)
-    {
-        ERROR("Can't create lock file for suspend event channel %s\n",
-		suspend_file);
-        return -EINVAL;
+    snprintf(buf, sizeof(buf), SUSPEND_LOCK_FILE, domid);
+}
+
+static int lock_suspend_event(xc_interface *xch, int domid, int *lockfd)
+{
+    int fd = -1, r;
+    char suspend_file[SUSPEND_FILE_BUFLEN];
+    struct stat ours, theirs;
+    struct flock fl;
+
+    get_suspend_file(suspend_file, domid);
+
+    *lockfd = -1;
+
+    for (;;) {
+        if (fd >= 0)
+            close (fd);
+
+        fd = open(suspend_file, O_CREAT | O_RDWR, 0600);
+        if (fd < 0)
+            ERR("create");
+
+        r = fcntl(fd, F_SETFD, FD_CLOEXEC);
+        if (r)
+            ERR("fcntl F_SETFD FD_CLOEXEC");
+
+        memset(&fl, 0, sizeof(fl));
+        fl.l_type = F_WRLCK;
+        fl.l_whence = SEEK_SET;
+        fl.l_len = 1;
+        r = fcntl(fd, F_SETLK, &fl);
+        if (r)
+            ERR("fcntl F_SETLK");
+
+        r = fstat(fd, &ours);
+        if (r)
+            ERR("fstat");
+
+        r = stat(suspend_file, &theirs);
+        if (r) {
+            if (errno == ENOENT)
+                /* try again */
+                continue;
+            ERR("stat");
+        }
+
+        if (ours.st_ino != theirs.st_ino)
+            /* someone else must have removed it while we were locking it */
+            continue;
+
+        break;
     }
-    umask(mask);
-    snprintf(buf, sizeof(buf), "%10ld", (long)getpid());
 
-    rc = write_exact(fd, buf, strlen(buf));
-    close(fd);
+    *lockfd = fd;
+    return 0;
 
-    return rc;
+ err:
+    if (fd >= 0)
+        close(fd);
+
+    return -1;
 }
 
-static int unlock_suspend_event(xc_interface *xch, int domid)
+static int unlock_suspend_event(xc_interface *xch, int domid, int *lockfd)
 {
-    int fd, pid, n;
-    char buf[128];
-    char suspend_file[256];
+    int r;
+    char suspend_file[SUSPEND_FILE_BUFLEN];
 
-    snprintf(suspend_file, sizeof(suspend_file), "%s_%d_lock.d",
-	    SUSPEND_LOCK_FILE, domid);
-    fd = open(suspend_file, O_RDWR);
+    if (*lockfd < 0)
+        return 0;
 
-    if (fd < 0)
-        return -EINVAL;
+    get_suspend_file(suspend_file, domid);
 
-    n = read(fd, buf, 127);
+    r = unlink(suspend_file);
+    if (r)
+        ERR("unlink");
 
-    close(fd);
+    r = close(*lockfd);
+    *lockfd = -1;
+    if (r)
+        ERR("close");
 
-    if (n > 0)
-    {
-        sscanf(buf, "%d", &pid);
-        /* We are the owner, so we can simply delete the file */
-        if (pid == getpid())
-        {
-            unlink(suspend_file);
-            return 0;
-        }
-    }
+ err:
+    if (*lockfd >= 0)
+        close(*lockfd);
 
-    return -EPERM;
+    return -1;
 }
 
 int xc_await_suspend(xc_interface *xch, xc_evtchn *xce, int suspend_evtchn)
@@ -96,20 +145,26 @@ int xc_await_suspend(xc_interface *xch, xc_evtchn *xce, int suspend_evtchn)
     return 0;
 }
 
-int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int domid, int suspend_evtchn)
+/* Internal callers are allowed to call this with suspend_evtchn<0
+ * but *lockfd>0. */
+int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce,
+                              int domid, int suspend_evtchn, int *lockfd)
 {
     if (suspend_evtchn >= 0)
         xc_evtchn_unbind(xce, suspend_evtchn);
 
-    return unlock_suspend_event(xch, domid);
+    return unlock_suspend_event(xch, domid, lockfd);
 }
 
-int xc_suspend_evtchn_init_sane(xc_interface *xch, xc_evtchn *xce, int domid, int port)
+int xc_suspend_evtchn_init_sane(xc_interface *xch, xc_evtchn *xce,
+                                int domid, int port, int *lockfd)
 {
     int rc, suspend_evtchn = -1;
 
-    if (lock_suspend_event(xch, domid))
-        return -EINVAL;
+    if (lock_suspend_event(xch, domid, lockfd)) {
+        errno = EINVAL;
+        goto cleanup;
+    }
 
     suspend_evtchn = xc_evtchn_bind_interdomain(xce, domid, port);
     if (suspend_evtchn < 0) {
@@ -126,17 +181,17 @@ int xc_suspend_evtchn_init_sane(xc_interface *xch, xc_evtchn *xce, int domid, in
     return suspend_evtchn;
 
 cleanup:
-    if (suspend_evtchn != -1)
-        xc_suspend_evtchn_release(xch, xce, domid, suspend_evtchn);
+    xc_suspend_evtchn_release(xch, xce, domid, suspend_evtchn, lockfd);
 
     return -1;
 }
 
-int xc_suspend_evtchn_init_exclusive(xc_interface *xch, xc_evtchn *xce, int domid, int port)
+int xc_suspend_evtchn_init_exclusive(xc_interface *xch, xc_evtchn *xce,
+                                     int domid, int port, int *lockfd)
 {
     int suspend_evtchn;
 
-    suspend_evtchn = xc_suspend_evtchn_init_sane(xch, xce, domid, port);
+    suspend_evtchn = xc_suspend_evtchn_init_sane(xch, xce, domid, port, lockfd);
     if (suspend_evtchn < 0)
         return suspend_evtchn;
 
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index ce5456c..1f216cd 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -254,13 +254,19 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                             int target,
                             const char *image_name);
 
-int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int domid, int suspend_evtchn);
+/*
+ * Sets *lockfd to -1.
+ * Has deallocated everything even on error.
+ */
+int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int domid, int suspend_evtchn, int *lockfd);
 
 /**
  * This function eats the initial notification.
  * xce must not be used for anything else
+ * See xc_suspend_evtchn_init_sane re lockfd.
  */
-int xc_suspend_evtchn_init_exclusive(xc_interface *xch, xc_evtchn *xce, int domid, int port);
+int xc_suspend_evtchn_init_exclusive(xc_interface *xch, xc_evtchn *xce,
+                                     int domid, int port, int *lockfd);
 
 /* xce must not be used for anything else */
 int xc_await_suspend(xc_interface *xch, xc_evtchn *xce, int suspend_evtchn);
@@ -268,8 +274,12 @@ int xc_await_suspend(xc_interface *xch, xc_evtchn *xce, int suspend_evtchn);
 /**
  * The port will be signaled immediately after this call
  * The caller should check the domain status and look for the next event
+ * On success, *lockfd will be set to >=0 and *lockfd must be preserved
+ * and fed to xc_suspend_evtchn_release.  (On error *lockfd is
+ * undefined and xc_suspend_evtchn_release is not allowed.)
  */
-int xc_suspend_evtchn_init_sane(xc_interface *xch, xc_evtchn *xce, int domid, int port);
+int xc_suspend_evtchn_init_sane(xc_interface *xch, xc_evtchn *xce,
+                                int domid, int port, int *lockfd);
 
 int xc_get_bit_size(xc_interface *xch,
                     const char *image_name, const char *cmdline,
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 4b42856..48a4b8e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1340,6 +1340,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
           | (dss->hvm ? XCFLAGS_HVM : 0);
 
     dss->suspend_eventchn = -1;
+    dss->guest_evtchn_lockfd = -1;
     dss->guest_responded = 0;
     dss->dm_savefile = libxl__device_model_savefile(gc, domid);
 
@@ -1358,7 +1359,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 
         if (port >= 0) {
             dss->suspend_eventchn =
-                xc_suspend_evtchn_init_exclusive(CTX->xch, dss->xce, dss->domid, port);
+                xc_suspend_evtchn_init_exclusive(CTX->xch, dss->xce,
+                                  dss->domid, port, &dss->guest_evtchn_lockfd);
 
             if (dss->suspend_eventchn < 0)
                 LOG(WARN, "Suspend event channel initialization failed");
@@ -1522,7 +1524,7 @@ static void domain_suspend_done(libxl__egc *egc,
 
     if (dss->suspend_eventchn > 0)
         xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
-                                  dss->suspend_eventchn);
+                           dss->suspend_eventchn, &dss->guest_evtchn_lockfd);
     if (dss->xce != NULL)
         xc_evtchn_close(dss->xce);
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c519abc..01873c0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2405,6 +2405,7 @@ struct libxl__domain_suspend_state {
     /* private */
     xc_evtchn *xce; /* event channel handle */
     int suspend_eventchn;
+    int guest_evtchn_lockfd;
     int hvm;
     int xcflags;
     int guest_responded;
diff --git a/tools/misc/xen-hptool.c b/tools/misc/xen-hptool.c
index db76f79..bd9d936 100644
--- a/tools/misc/xen-hptool.c
+++ b/tools/misc/xen-hptool.c
@@ -99,10 +99,13 @@ static int hp_mem_query_func(int argc, char *argv[])
 
 extern int xs_suspend_evtchn_port(int domid);
 
-static int suspend_guest(xc_interface *xch, xc_evtchn *xce, int domid, int *evtchn)
+static int suspend_guest(xc_interface *xch, xc_evtchn *xce, int domid,
+                         int *evtchn, int *lockfd)
 {
     int port, rc, suspend_evtchn = -1;
 
+    *lockfd = -1;
+
     if (!evtchn)
         return -1;
 
@@ -112,7 +115,8 @@ static int suspend_guest(xc_interface *xch, xc_evtchn *xce, int domid, int *evtc
         fprintf(stderr, "DOM%d: No suspend port, try live migration\n", domid);
         goto failed;
     }
-    suspend_evtchn = xc_suspend_evtchn_init_exclusive(xch, xce, domid, port);
+    suspend_evtchn = xc_suspend_evtchn_init_exclusive(xch, xce, domid,
+                                                      port, lockfd);
     if (suspend_evtchn < 0)
     {
         fprintf(stderr, "Suspend evtchn initialization failed\n");
@@ -135,7 +139,8 @@ static int suspend_guest(xc_interface *xch, xc_evtchn *xce, int domid, int *evtc
 
 failed:
     if (suspend_evtchn != -1)
-        xc_suspend_evtchn_release(xch, xce, domid, suspend_evtchn);
+        xc_suspend_evtchn_release(xch, xce, domid,
+                                  suspend_evtchn, lockfd);
 
     return -1;
 }
@@ -193,7 +198,7 @@ static int hp_mem_offline_func(int argc, char *argv[])
                 }
                 else if (status & PG_OFFLINE_OWNED)
                 {
-                    int result, suspend_evtchn = -1;
+                    int result, suspend_evtchn = -1, suspend_lockfd = -1;
                     xc_evtchn *xce;
                     xce = xc_evtchn_open(NULL, 0);
 
@@ -205,7 +210,8 @@ static int hp_mem_offline_func(int argc, char *argv[])
                     }
 
                     domid = status >> PG_OFFLINE_OWNER_SHIFT;
-                    if (suspend_guest(xch, xce, domid, &suspend_evtchn))
+                    if (suspend_guest(xch, xce, domid,
+                                      &suspend_evtchn, &suspend_lockfd))
                     {
                         fprintf(stderr, "Failed to suspend guest %d for"
                                 " mfn %lx\n", domid, mfn);
@@ -231,7 +237,8 @@ static int hp_mem_offline_func(int argc, char *argv[])
                                 mfn, domid);
                     }
                     xc_domain_resume(xch, domid, 1);
-                    xc_suspend_evtchn_release(xch, xce, domid, suspend_evtchn);
+                    xc_suspend_evtchn_release(xch, xce, domid,
+                                              suspend_evtchn, &suspend_lockfd);
                     xc_evtchn_close(xce);
                 }
                 break;
diff --git a/tools/python/xen/lowlevel/checkpoint/checkpoint.h b/tools/python/xen/lowlevel/checkpoint/checkpoint.h
index 187d9d7..2414956 100644
--- a/tools/python/xen/lowlevel/checkpoint/checkpoint.h
+++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.h
@@ -27,7 +27,7 @@ typedef struct {
     checkpoint_domtype domtype;
     int fd;
 
-    int suspend_evtchn;
+    int suspend_evtchn, suspend_lockfd;
 
     char* errstr;
 
diff --git a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
index 817d272..74ca062 100644
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
@@ -57,6 +57,7 @@ void checkpoint_init(checkpoint_state* s)
     s->fd = -1;
 
     s->suspend_evtchn = -1;
+    s->suspend_lockfd = -1;
 
     s->errstr = NULL;
 
@@ -360,7 +361,8 @@ static int setup_suspend_evtchn(checkpoint_state* s)
     return -1;
   }
 
-  s->suspend_evtchn = xc_suspend_evtchn_init_exclusive(s->xch, s->xce, s->domid, port);
+  s->suspend_evtchn = xc_suspend_evtchn_init_exclusive(s->xch, s->xce,
+                                    s->domid, port, &s->suspend_lockfd);
   if (s->suspend_evtchn < 0) {
       s->errstr = "failed to bind suspend event channel";
       return -1;
@@ -377,7 +379,8 @@ static void release_suspend_evtchn(checkpoint_state *s)
 {
   /* TODO: teach xen to clean up if port is unbound */
   if (s->xce != NULL && s->suspend_evtchn >= 0) {
-    xc_suspend_evtchn_release(s->xch, s->xce, s->domid, s->suspend_evtchn);
+    xc_suspend_evtchn_release(s->xch, s->xce, s->domid,
+                              s->suspend_evtchn, &s->suspend_lockfd);
     s->suspend_evtchn = -1;
   }
 }
diff --git a/tools/xcutils/xc_save.c b/tools/xcutils/xc_save.c
index 974f706..bf74e46 100644
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -167,7 +167,7 @@ int
 main(int argc, char **argv)
 {
     unsigned int maxit, max_f, lflags;
-    int io_fd, ret, port;
+    int io_fd, ret, port, suspend_lockfd = -1;
     struct save_callbacks callbacks;
     xentoollog_level lvl;
     xentoollog_logger *l;
@@ -202,7 +202,8 @@ main(int argc, char **argv)
         else
         {
             si.suspend_evtchn =
-              xc_suspend_evtchn_init_exclusive(si.xch, si.xce, si.domid, port);
+              xc_suspend_evtchn_init_exclusive(si.xch, si.xce, si.domid,
+                                               port, &suspend_lockfd);
 
             if (si.suspend_evtchn < 0)
                 warnx("suspend event channel initialization failed, "
@@ -216,7 +217,8 @@ main(int argc, char **argv)
                          &callbacks, !!(si.flags & XCFLAGS_HVM), 0);
 
     if (si.suspend_evtchn > 0)
-	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);
+	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid,
+                                   si.suspend_evtchn, &suspend_lockfd);
 
     if (si.xce > 0)
         xc_evtchn_close(si.xce);
-- 
1.7.10.4

[PATCH 13/23] libxl: suspend: Async libxl__domain_suspend_callback

[Ian Jackson]

Mark the suspend callback libxl__domain_suspend_callback as
asynchronous in the helper stub generator (libxl_save_msgs_gen.pl).
We are going to want to provide an asynchronous version of this
function to get rid of the usleeps and waiting loops in the suspend
code.

libxl__domain_suspend_common_callback, the common synchronous core,
which used to be provided directly as the callback function for the
helper machinery, becomes libxl__domain_suspend_callback_common.  It
can now take a typesafe parameter.

For now, provide two very similar asynchronous wrappers for it.  Each
is a simple function which contains only boilerplate, calls the common
synchronous core, and returns the asynchronous response.

Essentially, we have just moved (in the case of suspend callbacks) the
call site of libxl__srm_callout_callback_complete.  It was in the
switch statement in the autogenerated _libxl_save_msgs_callout.c, and
is now in the handwritten libxl_dom.c.

No functional change.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Cc: Ian Campbell <ian.campbell@citrix.com>

---
v2: Commit message mentions usleeps, not Remus, as motivation.
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c            |   25 +++++++++++++++++++------
 tools/libxl/libxl_internal.h       |    2 +-
 tools/libxl/libxl_save_msgs_gen.pl |    2 +-
 3 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 48a4b8e..1c0f04f 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1020,10 +1020,8 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-int libxl__domain_suspend_common_callback(void *user)
+int libxl__domain_suspend_callback_common(libxl__domain_suspend_state *dss)
 {
-    libxl__save_helper_state *shs = user;
-    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
@@ -1242,12 +1240,27 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
     return 0;
 }
 
+static void libxl__domain_suspend_callback(void *data)
+{
+    libxl__save_helper_state *shs = data;
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+
+    int ok = libxl__domain_suspend_callback_common(dss);
+    libxl__xc_domain_saverestore_async_callback_done(egc, shs, ok);
+}
+
 /*----- remus callbacks -----*/
 
-static int libxl__remus_domain_suspend_callback(void *data)
+static void libxl__remus_domain_suspend_callback(void *data)
 {
+    libxl__save_helper_state *shs = data;
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+
     /* REMUS TODO: Issue disk and network checkpoint reqs. */
-    return libxl__domain_suspend_common_callback(data);
+    int ok = libxl__domain_suspend_callback_common(dss);
+    libxl__xc_domain_saverestore_async_callback_done(egc, shs, ok);
 }
 
 static int libxl__remus_domain_resume_callback(void *data)
@@ -1373,7 +1386,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
         callbacks->postcopy = libxl__remus_domain_resume_callback;
         callbacks->checkpoint = libxl__remus_domain_checkpoint_callback;
     } else
-        callbacks->suspend = libxl__domain_suspend_common_callback;
+        callbacks->suspend = libxl__domain_suspend_callback;
 
     callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 01873c0..9b9264e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2705,7 +2705,7 @@ _hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
 void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
                            libxl__save_helper_state *shs, int return_value);
 
-_hidden int libxl__domain_suspend_common_callback(void *data);
+_hidden int libxl__domain_suspend_callback_common(libxl__domain_suspend_state*);
 _hidden void libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data);
 _hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index ee126c7..3c6bd57 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -23,7 +23,7 @@ our @msgs = (
                                                  STRING doing_what),
                                                 'unsigned long', 'done',
                                                 'unsigned long', 'total'] ],
-    [  3, 'scxW',   "suspend", [] ],         
+    [  3, 'scxA',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
     [  5, 'scxA',   "checkpoint", [] ],      
     [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
-- 
1.7.10.4

[PATCH 14/23] libxl: suspend: Async domain_suspend_callback_common

[Ian Jackson]

Make domain_suspend_callback_common do its work and then call
dss->callback_common_done, rather than simply returning its answer.

This is preparatory to abolishing the usleeps in this function and
replacing them with use of the event machinery.

No functional change.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c      |   46 ++++++++++++++++++++++++++++++------------
 tools/libxl/libxl_internal.h |    4 +++-
 2 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1c0f04f..39f06da 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -755,6 +755,10 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
 
 static void domain_suspend_done(libxl__egc *egc,
                         libxl__domain_suspend_state *dss, int rc);
+static void domain_suspend_callback_common_done(libxl__egc *egc,
+                                libxl__domain_suspend_state *dss, int ok);
+static void remus_domain_suspend_callback_common_done(libxl__egc *egc,
+                                libxl__domain_suspend_state *dss, int ok);
 
 /*----- complicated callback, called by xc_domain_save -----*/
 
@@ -1020,7 +1024,9 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-int libxl__domain_suspend_callback_common(libxl__domain_suspend_state *dss)
+/* calls dss->callback_common_done when done */
+static void domain_suspend_callback_common(libxl__egc *egc,
+                                           libxl__domain_suspend_state *dss)
 {
     STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
@@ -1043,12 +1049,12 @@ int libxl__domain_suspend_callback_common(libxl__domain_suspend_state *dss)
         ret = xc_evtchn_notify(dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
             LOG(ERROR, "xc_evtchn_notify failed ret=%d", ret);
-            return 0;
+            goto err;
         }
         ret = xc_await_suspend(CTX->xch, dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
             LOG(ERROR, "xc_await_suspend failed ret=%d", ret);
-            return 0;
+            goto err;
         }
         dss->guest_responded = 1;
         goto guest_suspended;
@@ -1059,7 +1065,7 @@ int libxl__domain_suspend_callback_common(libxl__domain_suspend_state *dss)
         ret = xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_suspend);
         if (ret < 0) {
             LOGE(ERROR, "xc_domain_shutdown failed");
-            return 0;
+            goto err;
         }
         /* The guest does not (need to) respond to this sort of request. */
         dss->guest_responded = 1;
@@ -1113,7 +1119,7 @@ int libxl__domain_suspend_callback_common(libxl__domain_suspend_state *dss)
          */
         if (!strcmp(state, "suspend")) {
             LOG(ERROR, "guest didn't acknowledge suspend, request cancelled");
-            return 0;
+            goto err;
         }
 
         LOG(DEBUG, "guest acknowledged suspend request");
@@ -1143,17 +1149,19 @@ int libxl__domain_suspend_callback_common(libxl__domain_suspend_state *dss)
     }
 
     LOG(ERROR, "guest did not suspend");
-    return 0;
+ err:
+    dss->callback_common_done(egc, dss, 0);
+    return;
 
  guest_suspended:
     if (dss->hvm) {
         ret = libxl__domain_suspend_device_model(gc, dss);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
-            return 0;
+            goto err;
         }
     }
-    return 1;
+    dss->callback_common_done(egc, dss, 1);
 }
 
 static inline char *physmap_path(libxl__gc *gc, uint32_t domid,
@@ -1246,10 +1254,16 @@ static void libxl__domain_suspend_callback(void *data)
     libxl__egc *egc = shs->egc;
     libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
 
-    int ok = libxl__domain_suspend_callback_common(dss);
-    libxl__xc_domain_saverestore_async_callback_done(egc, shs, ok);
+    dss->callback_common_done = domain_suspend_callback_common_done;
+    domain_suspend_callback_common(egc, dss);
 }
 
+static void domain_suspend_callback_common_done(libxl__egc *egc,
+                                libxl__domain_suspend_state *dss, int ok)
+{
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, ok);
+}    
+
 /*----- remus callbacks -----*/
 
 static void libxl__remus_domain_suspend_callback(void *data)
@@ -1258,11 +1272,17 @@ static void libxl__remus_domain_suspend_callback(void *data)
     libxl__egc *egc = shs->egc;
     libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
 
-    /* REMUS TODO: Issue disk and network checkpoint reqs. */
-    int ok = libxl__domain_suspend_callback_common(dss);
-    libxl__xc_domain_saverestore_async_callback_done(egc, shs, ok);
+    dss->callback_common_done = remus_domain_suspend_callback_common_done;
+    domain_suspend_callback_common(egc, dss);
 }
 
+static void remus_domain_suspend_callback_common_done(libxl__egc *egc,
+                                libxl__domain_suspend_state *dss, int ok)
+{
+    /* REMUS TODO: Issue disk and network checkpoint reqs. */
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, ok);
+}    
+
 static int libxl__remus_domain_resume_callback(void *data)
 {
     libxl__save_helper_state *shs = data;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9b9264e..55293f1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2413,6 +2413,8 @@ struct libxl__domain_suspend_state {
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
     libxl__logdirty_switch logdirty;
+    void (*callback_common_done)(libxl__egc*,
+                                 struct libxl__domain_suspend_state*, int ok);
     /* private for libxl__domain_save_device_model */
     libxl__save_device_model_cb *save_dm_callback;
     libxl__datacopier_state save_dm_datacopier;
@@ -2705,7 +2707,7 @@ _hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
 void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
                            libxl__save_helper_state *shs, int return_value);
 
-_hidden int libxl__domain_suspend_callback_common(libxl__domain_suspend_state*);
+
 _hidden void libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data);
 _hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
-- 
1.7.10.4

[PATCH 15/23] libxl: suspend: Reorg domain_suspend_callback_common

[Ian Jackson]

Make domain_suspend_callback_common more callback-oriented:

* Turn the functionality behind the goto labels "err" and
  "guest_suspended" into functions which can be called just before
  "return".

* Deindent the "issuing %s suspend request via XenBus control node"
  branch; it is going to be split up into various functions as the
  xenstore work becomes callback-based.

No functional change.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |  158 ++++++++++++++++++++++++++++++-----------------
 1 file changed, 103 insertions(+), 55 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 39f06da..59f6ce3 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1024,6 +1024,16 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
+static void domain_suspend_common_wait_guest(libxl__egc *egc,
+                                             libxl__domain_suspend_state *dss);
+static void domain_suspend_common_guest_suspended(libxl__egc *egc,
+                                         libxl__domain_suspend_state *dss);
+static void domain_suspend_common_failed(libxl__egc *egc,
+                                         libxl__domain_suspend_state *dss);
+static void domain_suspend_common_done(libxl__egc *egc,
+                                       libxl__domain_suspend_state *dss,
+                                       bool ok);
+
 /* calls dss->callback_common_done when done */
 static void domain_suspend_callback_common(libxl__egc *egc,
                                            libxl__domain_suspend_state *dss)
@@ -1057,7 +1067,8 @@ static void domain_suspend_callback_common(libxl__egc *egc,
             goto err;
         }
         dss->guest_responded = 1;
-        goto guest_suspended;
+        domain_suspend_common_guest_suspended(egc, dss);
+        return;
     }
 
     if (dss->hvm && (!hvm_pvdrv || hvm_s_state)) {
@@ -1069,63 +1080,81 @@ static void domain_suspend_callback_common(libxl__egc *egc,
         }
         /* The guest does not (need to) respond to this sort of request. */
         dss->guest_responded = 1;
-    } else {
-        LOG(DEBUG, "issuing %s suspend request via XenBus control node",
-            dss->hvm ? "PVHVM" : "PV");
+        domain_suspend_common_wait_guest(egc, dss);
+        return;
+    }
 
-        libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "suspend");
+    LOG(DEBUG, "issuing %s suspend request via XenBus control node",
+        dss->hvm ? "PVHVM" : "PV");
 
-        LOG(DEBUG, "wait for the guest to acknowledge suspend request");
-        watchdog = 60;
-        while (!strcmp(state, "suspend") && watchdog > 0) {
-            usleep(100000);
+    libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "suspend");
 
-            state = libxl__domain_pvcontrol_read(gc, XBT_NULL, domid);
-            if (!state) state = "";
+    LOG(DEBUG, "wait for the guest to acknowledge suspend request");
+    watchdog = 60;
+    while (!strcmp(state, "suspend") && watchdog > 0) {
+        usleep(100000);
 
-            watchdog--;
-        }
+        state = libxl__domain_pvcontrol_read(gc, XBT_NULL, domid);
+        if (!state) state = "";
 
-        /*
-         * Guest appears to not be responding. Cancel the suspend
-         * request.
-         *
-         * We re-read the suspend node and clear it within a
-         * transaction in order to handle the case where we race
-         * against the guest catching up and acknowledging the request
-         * at the last minute.
-         */
-        if (!strcmp(state, "suspend")) {
-            LOG(ERROR, "guest didn't acknowledge suspend, cancelling request");
-        retry_transaction:
-            t = xs_transaction_start(CTX->xsh);
-
-            state = libxl__domain_pvcontrol_read(gc, t, domid);
-            if (!state) state = "";
-
-            if (!strcmp(state, "suspend"))
-                libxl__domain_pvcontrol_write(gc, t, domid, "");
-
-            if (!xs_transaction_end(CTX->xsh, t, 0))
-                if (errno == EAGAIN)
-                    goto retry_transaction;
+        watchdog--;
+    }
 
-        }
+    /*
+     * Guest appears to not be responding. Cancel the suspend
+     * request.
+     *
+     * We re-read the suspend node and clear it within a
+     * transaction in order to handle the case where we race
+     * against the guest catching up and acknowledging the request
+     * at the last minute.
+     */
+    if (!strcmp(state, "suspend")) {
+        LOG(ERROR, "guest didn't acknowledge suspend, cancelling request");
+    retry_transaction:
+        t = xs_transaction_start(CTX->xsh);
 
-        /*
-         * Final check for guest acknowledgement. The guest may have
-         * acknowledged while we were cancelling the request in which
-         * case we lost the race while cancelling and should continue.
-         */
-        if (!strcmp(state, "suspend")) {
-            LOG(ERROR, "guest didn't acknowledge suspend, request cancelled");
-            goto err;
-        }
+        state = libxl__domain_pvcontrol_read(gc, t, domid);
+        if (!state) state = "";
+
+        if (!strcmp(state, "suspend"))
+            libxl__domain_pvcontrol_write(gc, t, domid, "");
+
+        if (!xs_transaction_end(CTX->xsh, t, 0))
+            if (errno == EAGAIN)
+                goto retry_transaction;
 
-        LOG(DEBUG, "guest acknowledged suspend request");
-        dss->guest_responded = 1;
     }
 
+    /*
+     * Final check for guest acknowledgement. The guest may have
+     * acknowledged while we were cancelling the request in which
+     * case we lost the race while cancelling and should continue.
+     */
+    if (!strcmp(state, "suspend")) {
+        LOG(ERROR, "guest didn't acknowledge suspend, request cancelled");
+        goto err;
+    }
+
+    LOG(DEBUG, "guest acknowledged suspend request");
+    dss->guest_responded = 1;
+    domain_suspend_common_wait_guest(egc,dss);
+    return;
+
+ err:
+    domain_suspend_common_failed(egc, dss);
+}
+
+static void domain_suspend_common_wait_guest(libxl__egc *egc,
+                                             libxl__domain_suspend_state *dss)
+{
+    STATE_AO_GC(dss->ao);
+    int ret;
+    int watchdog;
+
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
     LOG(DEBUG, "wait for the guest to suspend");
     watchdog = 60;
     while (watchdog > 0) {
@@ -1141,7 +1170,8 @@ static void domain_suspend_callback_common(libxl__egc *egc,
                 & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
                 LOG(DEBUG, "guest has suspended");
-                goto guest_suspended;
+                domain_suspend_common_guest_suspended(egc, dss);
+                return;
             }
         }
 
@@ -1149,19 +1179,37 @@ static void domain_suspend_callback_common(libxl__egc *egc,
     }
 
     LOG(ERROR, "guest did not suspend");
- err:
-    dss->callback_common_done(egc, dss, 0);
-    return;
+    domain_suspend_common_failed(egc, dss);
+}
+
+static void domain_suspend_common_guest_suspended(libxl__egc *egc,
+                                         libxl__domain_suspend_state *dss)
+{
+    STATE_AO_GC(dss->ao);
+    int ret;
 
- guest_suspended:
     if (dss->hvm) {
         ret = libxl__domain_suspend_device_model(gc, dss);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
-            goto err;
+            domain_suspend_common_failed(egc, dss);
+            return;
         }
     }
-    dss->callback_common_done(egc, dss, 1);
+    domain_suspend_common_done(egc, dss, 1);
+}
+
+static void domain_suspend_common_failed(libxl__egc *egc,
+                                         libxl__domain_suspend_state *dss)
+{
+    domain_suspend_common_done(egc, dss, 0);
+}
+
+static void domain_suspend_common_done(libxl__egc *egc,
+                                       libxl__domain_suspend_state *dss,
+                                       bool ok)
+{
+    dss->callback_common_done(egc, dss, ok);
 }
 
 static inline char *physmap_path(libxl__gc *gc, uint32_t domid,
-- 
1.7.10.4

[PATCH 16/23] libxl: suspend: New libxl__domain_pvcontrol_xspath

[Ian Jackson]

Factor out the pv control node xenstore path calculation into
libxl__domain_pvcontrol_xspath.

This xs path calculation was open coded in
libxl__domain_pvcontrol_read and _write.  This is undesirable because
it duplicates the code and because it makes the path inaccessible to
other parts of libxl (which are soon going to want it).

No functional change.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |   21 +++++++++++----------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 51158aa..8d70a45 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -898,17 +898,23 @@ int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
     return !!pvdriver;
 }
 
-char * libxl__domain_pvcontrol_read(libxl__gc *gc, xs_transaction_t t,
-                                    uint32_t domid)
+const char *libxl__domain_pvcontrol_xspath(libxl__gc *gc, uint32_t domid)
 {
-    const char *shutdown_path;
     const char *dom_path;
 
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path)
         return NULL;
 
-    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
+    return GCSPRINTF("%s/control/shutdown", dom_path);
+}
+
+char * libxl__domain_pvcontrol_read(libxl__gc *gc, xs_transaction_t t,
+                                    uint32_t domid)
+{
+    const char *shutdown_path;
+
+    shutdown_path = libxl__domain_pvcontrol_xspath(gc, domid);
     if (!shutdown_path)
         return NULL;
 
@@ -919,13 +925,8 @@ int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
                                   uint32_t domid, const char *cmd)
 {
     const char *shutdown_path;
-    const char *dom_path;
-
-    dom_path = libxl__xs_get_dompath(gc, domid);
-    if (!dom_path)
-        return ERROR_FAIL;
 
-    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
+    shutdown_path = libxl__domain_pvcontrol_xspath(gc, domid);
     if (!shutdown_path)
         return ERROR_FAIL;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 55293f1..93e0d4e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -967,6 +967,7 @@ _hidden int libxl__domain_resume(libxl__gc *gc, uint32_t domid,
 /* returns 0 or 1, or a libxl error code */
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
 
+_hidden const char *libxl__domain_pvcontrol_xspath(libxl__gc*, uint32_t domid);
 _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
                                             xs_transaction_t t, uint32_t domid);
 _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
-- 
1.7.10.4

[PATCH 17/23] libxl: suspend: New domain_suspend_pvcontrol_acked

[Ian Jackson]

Factor out domain_suspend_pvcontrol_acked.

This replaces a bunch of open-coded strcmp()s and makes the code
clearer.  It also eliminates the need to check for state==NULL each
time it's read, because we can check for NULL once before the strcmp.

No functional change.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |   17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 59f6ce3..a0b3a57 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1034,6 +1034,12 @@ static void domain_suspend_common_done(libxl__egc *egc,
                                        libxl__domain_suspend_state *dss,
                                        bool ok);
 
+static bool domain_suspend_pvcontrol_acked(const char *state) {
+    /* any value other than "suspend", including ENOENT, is OK */
+    if (!state) return 1;
+    return strcmp(state,"suspend");
+}
+
 /* calls dss->callback_common_done when done */
 static void domain_suspend_callback_common(libxl__egc *egc,
                                            libxl__domain_suspend_state *dss)
@@ -1091,11 +1097,10 @@ static void domain_suspend_callback_common(libxl__egc *egc,
 
     LOG(DEBUG, "wait for the guest to acknowledge suspend request");
     watchdog = 60;
-    while (!strcmp(state, "suspend") && watchdog > 0) {
+    while (!domain_suspend_pvcontrol_acked(state) && watchdog > 0) {
         usleep(100000);
 
         state = libxl__domain_pvcontrol_read(gc, XBT_NULL, domid);
-        if (!state) state = "";
 
         watchdog--;
     }
@@ -1109,21 +1114,19 @@ static void domain_suspend_callback_common(libxl__egc *egc,
      * against the guest catching up and acknowledging the request
      * at the last minute.
      */
-    if (!strcmp(state, "suspend")) {
+    if (!domain_suspend_pvcontrol_acked(state)) {
         LOG(ERROR, "guest didn't acknowledge suspend, cancelling request");
     retry_transaction:
         t = xs_transaction_start(CTX->xsh);
 
         state = libxl__domain_pvcontrol_read(gc, t, domid);
-        if (!state) state = "";
 
-        if (!strcmp(state, "suspend"))
+        if (!domain_suspend_pvcontrol_acked(state))
             libxl__domain_pvcontrol_write(gc, t, domid, "");
 
         if (!xs_transaction_end(CTX->xsh, t, 0))
             if (errno == EAGAIN)
                 goto retry_transaction;
-
     }
 
     /*
@@ -1131,7 +1134,7 @@ static void domain_suspend_callback_common(libxl__egc *egc,
      * acknowledged while we were cancelling the request in which
      * case we lost the race while cancelling and should continue.
      */
-    if (!strcmp(state, "suspend")) {
+    if (!domain_suspend_pvcontrol_acked(state)) {
         LOG(ERROR, "guest didn't acknowledge suspend, request cancelled");
         goto err;
     }
-- 
1.7.10.4

[PATCH 18/23] libxl: suspend: domain_suspend_callback_common xs errs

[Ian Jackson]

In domain_suspend_callback_common, use libxl__xs_transaction_start in
a loop, rather than xs_transaction_start and a goto label.

This will improve the error handling, but have no other semantic
effect.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |   19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a0b3a57..8aceba9 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1050,6 +1050,7 @@ static void domain_suspend_callback_common(libxl__egc *egc,
     char *state = "suspend";
     int watchdog;
     xs_transaction_t t;
+    int rc;
 
     /* Convenience aliases */
     const uint32_t domid = dss->domid;
@@ -1116,17 +1117,19 @@ static void domain_suspend_callback_common(libxl__egc *egc,
      */
     if (!domain_suspend_pvcontrol_acked(state)) {
         LOG(ERROR, "guest didn't acknowledge suspend, cancelling request");
-    retry_transaction:
-        t = xs_transaction_start(CTX->xsh);
+        for (;;) {
+            rc = libxl__xs_transaction_start(gc, &t);
+            if (rc) goto err;
 
-        state = libxl__domain_pvcontrol_read(gc, t, domid);
+            state = libxl__domain_pvcontrol_read(gc, t, domid);
 
-        if (!domain_suspend_pvcontrol_acked(state))
-            libxl__domain_pvcontrol_write(gc, t, domid, "");
+            if (!domain_suspend_pvcontrol_acked(state))
+                libxl__domain_pvcontrol_write(gc, t, domid, "");
 
-        if (!xs_transaction_end(CTX->xsh, t, 0))
-            if (errno == EAGAIN)
-                goto retry_transaction;
+            rc = libxl__xs_transaction_commit(gc, &t);
+            if (!rc) break;
+            if (rc<0) goto err;
+        }
     }
 
     /*
-- 
1.7.10.4

[PATCH 19/23] libxl: suspend: Async xenstore pvcontrol wait

[Ian Jackson]

When negotiating guest suspend via the xenstore pvcontrol protocol
(ie when the guest does NOT support the evtchn fast suspend protocol):

Replace the use of loops and usleep with a call to libxl__xswait.

Also, replace the xenstore transaction loop with one using
libxl__xs_transaction_start et al.

There is not intended to be any semantic change, other than to make
the algorithm properly asynchronous.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c      |   93 ++++++++++++++++++++++++++----------------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 59 insertions(+), 35 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 8aceba9..dde7e33 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1028,6 +1028,8 @@ static void domain_suspend_common_wait_guest(libxl__egc *egc,
                                              libxl__domain_suspend_state *dss);
 static void domain_suspend_common_guest_suspended(libxl__egc *egc,
                                          libxl__domain_suspend_state *dss);
+static void domain_suspend_common_pvcontrol_suspending(libxl__egc *egc,
+      libxl__xswait_state *xswa, int rc, const char *state);
 static void domain_suspend_common_failed(libxl__egc *egc,
                                          libxl__domain_suspend_state *dss);
 static void domain_suspend_common_done(libxl__egc *egc,
@@ -1047,10 +1049,6 @@ static void domain_suspend_callback_common(libxl__egc *egc,
     STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
-    char *state = "suspend";
-    int watchdog;
-    xs_transaction_t t;
-    int rc;
 
     /* Convenience aliases */
     const uint32_t domid = dss->domid;
@@ -1096,59 +1094,81 @@ static void domain_suspend_callback_common(libxl__egc *egc,
 
     libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "suspend");
 
-    LOG(DEBUG, "wait for the guest to acknowledge suspend request");
-    watchdog = 60;
-    while (!domain_suspend_pvcontrol_acked(state) && watchdog > 0) {
-        usleep(100000);
+    dss->pvcontrol.path = libxl__domain_pvcontrol_xspath(gc, domid);
+    if (!dss->pvcontrol.path) goto err;
 
-        state = libxl__domain_pvcontrol_read(gc, XBT_NULL, domid);
+    dss->pvcontrol.ao = ao;
+    dss->pvcontrol.what = "guest acknowledgement of suspend request";
+    dss->pvcontrol.timeout_ms = 60 * 1000;
+    dss->pvcontrol.callback = domain_suspend_common_pvcontrol_suspending;
+    libxl__xswait_start(gc, &dss->pvcontrol);
+    return;
 
-        watchdog--;
-    }
+ err:
+    domain_suspend_common_failed(egc, dss);
+}
 
-    /*
-     * Guest appears to not be responding. Cancel the suspend
-     * request.
-     *
-     * We re-read the suspend node and clear it within a
-     * transaction in order to handle the case where we race
-     * against the guest catching up and acknowledging the request
-     * at the last minute.
-     */
-    if (!domain_suspend_pvcontrol_acked(state)) {
-        LOG(ERROR, "guest didn't acknowledge suspend, cancelling request");
+static void domain_suspend_common_pvcontrol_suspending(libxl__egc *egc,
+      libxl__xswait_state *xswa, int rc, const char *state)
+{
+    libxl__domain_suspend_state *dss = CONTAINER_OF(xswa, *dss, pvcontrol);
+    STATE_AO_GC(dss->ao);
+    xs_transaction_t t = 0;
+
+    if (!rc && !domain_suspend_pvcontrol_acked(state))
+        /* keep waiting */
+        return;
+
+    libxl__xswait_stop(gc, &dss->pvcontrol);
+
+    if (rc == ERROR_TIMEDOUT) {
+        /*
+         * Guest appears to not be responding. Cancel the suspend
+         * request.
+         *
+         * We re-read the suspend node and clear it within a
+         * transaction in order to handle the case where we race
+         * against the guest catching up and acknowledging the request
+         * at the last minute.
+         */
         for (;;) {
             rc = libxl__xs_transaction_start(gc, &t);
             if (rc) goto err;
 
-            state = libxl__domain_pvcontrol_read(gc, t, domid);
+            rc = libxl__xs_read_checked(gc, t, xswa->path, &state);
+            if (rc) goto err;
+
+            if (domain_suspend_pvcontrol_acked(state))
+                break;
 
-            if (!domain_suspend_pvcontrol_acked(state))
-                libxl__domain_pvcontrol_write(gc, t, domid, "");
+            rc = libxl__xs_write_checked(gc, t, xswa->path, "");
+            if (rc) goto err;
 
             rc = libxl__xs_transaction_commit(gc, &t);
-            if (!rc) break;
+            if (!rc) {
+                LOG(ERROR,
+                    "guest didn't acknowledge suspend, cancelling request");
+                goto err;
+            }
             if (rc<0) goto err;
         }
-    }
-
-    /*
-     * Final check for guest acknowledgement. The guest may have
-     * acknowledged while we were cancelling the request in which
-     * case we lost the race while cancelling and should continue.
-     */
-    if (!domain_suspend_pvcontrol_acked(state)) {
-        LOG(ERROR, "guest didn't acknowledge suspend, request cancelled");
+    } else if (rc) {
+        /* some error in xswait's read of xenstore, already logged */
         goto err;
     }
 
+    assert(domain_suspend_pvcontrol_acked(state));
     LOG(DEBUG, "guest acknowledged suspend request");
+
+    libxl__xs_transaction_abort(gc, &t);
     dss->guest_responded = 1;
     domain_suspend_common_wait_guest(egc,dss);
     return;
 
  err:
+    libxl__xs_transaction_abort(gc, &t);
     domain_suspend_common_failed(egc, dss);
+    return;
 }
 
 static void domain_suspend_common_wait_guest(libxl__egc *egc,
@@ -1215,6 +1235,8 @@ static void domain_suspend_common_done(libxl__egc *egc,
                                        libxl__domain_suspend_state *dss,
                                        bool ok)
 {
+    EGC_GC;
+    assert(!libxl__xswait_inuse(&dss->pvcontrol));
     dss->callback_common_done(egc, dss, ok);
 }
 
@@ -1400,6 +1422,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
         &dss->shs.callbacks.save.a;
 
     logdirty_init(&dss->logdirty);
+    libxl__xswait_init(&dss->pvcontrol);
 
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 93e0d4e..c4a509b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2410,6 +2410,7 @@ struct libxl__domain_suspend_state {
     int hvm;
     int xcflags;
     int guest_responded;
+    libxl__xswait_state pvcontrol;
     const char *dm_savefile;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
-- 
1.7.10.4

[PATCH 20/23] libxl: suspend: Abolish usleeps in domain suspend wait

[Ian Jackson]

Replace the use of a loop with usleep().

Instead, use a xenstore watch and an event system timeout.  xenstore
fires watches on @releaseDomain when a domain shuts down.

The logic which checks for the state of the domain is unchanged, and
not ideal, but we will leave that for the next patch.

There is not intended to be any semantic change, other than to make
the algorithm properly asynchronous and the consequential waiting on
xenstore, rather than polling.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c      |   80 ++++++++++++++++++++++++++++++------------
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 60 insertions(+), 22 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index dde7e33..6291115 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1028,8 +1028,14 @@ static void domain_suspend_common_wait_guest(libxl__egc *egc,
                                              libxl__domain_suspend_state *dss);
 static void domain_suspend_common_guest_suspended(libxl__egc *egc,
                                          libxl__domain_suspend_state *dss);
+
 static void domain_suspend_common_pvcontrol_suspending(libxl__egc *egc,
       libxl__xswait_state *xswa, int rc, const char *state);
+static void suspend_common_wait_guest_watch(libxl__egc *egc,
+      libxl__ev_xswatch *xsw, const char *watch_path, const char *event_path);
+static void suspend_common_wait_guest_timeout(libxl__egc *egc,
+      libxl__ev_time *ev, const struct timeval *requested_abs);
+
 static void domain_suspend_common_failed(libxl__egc *egc,
                                          libxl__domain_suspend_state *dss);
 static void domain_suspend_common_done(libxl__egc *egc,
@@ -1175,36 +1181,59 @@ static void domain_suspend_common_wait_guest(libxl__egc *egc,
                                              libxl__domain_suspend_state *dss)
 {
     STATE_AO_GC(dss->ao);
+    int rc;
+
+    LOG(DEBUG, "wait for the guest to suspend");
+
+    rc = libxl__ev_xswatch_register(gc, &dss->guest_watch,
+                                    suspend_common_wait_guest_watch,
+                                    "@releaseDomain");
+    if (rc) goto err;
+
+    rc = libxl__ev_time_register_rel(gc, &dss->guest_timeout, 
+                                     suspend_common_wait_guest_timeout,
+                                     60*1000);
+    if (rc) goto err;
+    return;
+
+ err:
+    domain_suspend_common_failed(egc, dss);
+}
+
+static void suspend_common_wait_guest_watch(libxl__egc *egc,
+      libxl__ev_xswatch *xsw, const char *watch_path, const char *event_path)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(xsw, *dss, guest_watch);
+    STATE_AO_GC(dss->ao);
+    xc_domaininfo_t info;
     int ret;
-    int watchdog;
 
     /* Convenience aliases */
     const uint32_t domid = dss->domid;
 
-    LOG(DEBUG, "wait for the guest to suspend");
-    watchdog = 60;
-    while (watchdog > 0) {
-        xc_domaininfo_t info;
-
-        usleep(100000);
-        ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
-        if (ret == 1 && info.domain == domid &&
-            (info.flags & XEN_DOMINF_shutdown)) {
-            int shutdown_reason;
-
-            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
-                & XEN_DOMINF_shutdownmask;
-            if (shutdown_reason == SHUTDOWN_suspend) {
-                LOG(DEBUG, "guest has suspended");
-                domain_suspend_common_guest_suspended(egc, dss);
-                return;
-            }
+    ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
+    if (ret == 1 && info.domain == domid &&
+        (info.flags & XEN_DOMINF_shutdown)) {
+        int shutdown_reason;
+
+        shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
+            & XEN_DOMINF_shutdownmask;
+        if (shutdown_reason == SHUTDOWN_suspend) {
+            LOG(DEBUG, "guest has suspended");
+            domain_suspend_common_guest_suspended(egc, dss);
+            return;
         }
-
-        watchdog--;
     }
+    /* otherwise, keep waiting */
+}
 
-    LOG(ERROR, "guest did not suspend");
+static void suspend_common_wait_guest_timeout(libxl__egc *egc,
+      libxl__ev_time *ev, const struct timeval *requested_abs)
+{
+    libxl__domain_suspend_state *dss = CONTAINER_OF(ev, *dss, guest_timeout);
+    STATE_AO_GC(dss->ao);
+    LOG(ERROR, "guest did not suspend, timed out");
     domain_suspend_common_failed(egc, dss);
 }
 
@@ -1214,6 +1243,9 @@ static void domain_suspend_common_guest_suspended(libxl__egc *egc,
     STATE_AO_GC(dss->ao);
     int ret;
 
+    libxl__ev_xswatch_deregister(gc, &dss->guest_watch);
+    libxl__ev_time_deregister(gc, &dss->guest_timeout);
+
     if (dss->hvm) {
         ret = libxl__domain_suspend_device_model(gc, dss);
         if (ret) {
@@ -1237,6 +1269,8 @@ static void domain_suspend_common_done(libxl__egc *egc,
 {
     EGC_GC;
     assert(!libxl__xswait_inuse(&dss->pvcontrol));
+    libxl__ev_xswatch_deregister(gc, &dss->guest_watch);
+    libxl__ev_time_deregister(gc, &dss->guest_timeout);
     dss->callback_common_done(egc, dss, ok);
 }
 
@@ -1423,6 +1457,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 
     logdirty_init(&dss->logdirty);
     libxl__xswait_init(&dss->pvcontrol);
+    libxl__ev_xswatch_init(&dss->guest_watch);
+    libxl__ev_time_init(&dss->guest_timeout);
 
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c4a509b..d428e77 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2411,6 +2411,8 @@ struct libxl__domain_suspend_state {
     int xcflags;
     int guest_responded;
     libxl__xswait_state pvcontrol;
+    libxl__ev_xswatch guest_watch;
+    libxl__ev_time guest_timeout;
     const char *dm_savefile;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
-- 
1.7.10.4

[PATCH 21/23] libxl: suspend: Fix suspend wait corner cases

[Ian Jackson]

When we are waiting for a guest to suspend, this suspend operation
would continue to wait (until the timeout) if the guest was destroyed
or shut down for another reason, or if xc_domain_getinfolist failed.

Handle these cases correctly, as errors.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |   42 ++++++++++++++++++++++++++++++------------
 1 file changed, 30 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 6291115..88700ee 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1208,24 +1208,42 @@ static void suspend_common_wait_guest_watch(libxl__egc *egc,
     STATE_AO_GC(dss->ao);
     xc_domaininfo_t info;
     int ret;
+    int shutdown_reason;
 
     /* Convenience aliases */
     const uint32_t domid = dss->domid;
 
     ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
-    if (ret == 1 && info.domain == domid &&
-        (info.flags & XEN_DOMINF_shutdown)) {
-        int shutdown_reason;
-
-        shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
-            & XEN_DOMINF_shutdownmask;
-        if (shutdown_reason == SHUTDOWN_suspend) {
-            LOG(DEBUG, "guest has suspended");
-            domain_suspend_common_guest_suspended(egc, dss);
-            return;
-        }
+    if (ret < 0) {
+        LOGE(ERROR, "unable to check for status of guest %"PRId32"", domid);
+        goto err;
+        domain_suspend_common_failed(egc, dss);
+    }
+
+    if (!(ret == 1 && info.domain == domid)) {
+        LOGE(ERROR, "guest %"PRId32" we were suspending has been destroyed",
+             domid);
+        goto err;
+    }
+
+    if (!(info.flags & XEN_DOMINF_shutdown))
+        /* keep waiting */
+        return;
+
+    shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
+        & XEN_DOMINF_shutdownmask;
+    if (shutdown_reason != SHUTDOWN_suspend) {
+        LOG(DEBUG, "guest %"PRId32" we were suspending has shut down"
+            " with unexpected reason code %d", domid, shutdown_reason);
+        goto err;
     }
-    /* otherwise, keep waiting */
+
+    LOG(DEBUG, "guest has suspended");
+    domain_suspend_common_guest_suspended(egc, dss);
+    return;
+
+ err:
+    domain_suspend_common_failed(egc, dss);
 }
 
 static void suspend_common_wait_guest_timeout(libxl__egc *egc,
-- 
1.7.10.4

[PATCH 22/23] libxl: suspend: Async evtchn wait

[Ian Jackson]

When negotiating guest suspend via the evtchn ("fast") protocol,
abolish synchronous wait for domain suspend.

If the guest supports the event channel suspend protocol, we used to
sit in a loop waiting for it to suspend.

Instead, use the new libxl event channel event facility.  When we see
that the event is signaled, we look at the domain to see if it has
suspended.

So the suspend operation no longer blocks with the libxl ctx lock
held, and instead returns to the event loop.  Additionally, domains
which signal the event channel themselves, or undergo other state
changes, will be handled more correctly.

We end up making a few more hypercalls.

Also, if we encounter errors setting up the suspend event channel
(which should not happen), abort the operation rather than falling
back to the xenstore protocol.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c      |   78 ++++++++++++++++++++++++++----------------
 tools/libxl/libxl_internal.h |    3 +-
 2 files changed, 50 insertions(+), 31 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 88700ee..c431a2d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1031,8 +1031,12 @@ static void domain_suspend_common_guest_suspended(libxl__egc *egc,
 
 static void domain_suspend_common_pvcontrol_suspending(libxl__egc *egc,
       libxl__xswait_state *xswa, int rc, const char *state);
+static void domain_suspend_common_wait_guest_evtchn(libxl__egc *egc,
+        libxl__ev_evtchn *evev);
 static void suspend_common_wait_guest_watch(libxl__egc *egc,
       libxl__ev_xswatch *xsw, const char *watch_path, const char *event_path);
+static void suspend_common_wait_guest_check(libxl__egc *egc,
+        libxl__domain_suspend_state *dss);
 static void suspend_common_wait_guest_timeout(libxl__egc *egc,
       libxl__ev_time *ev, const struct timeval *requested_abs);
 
@@ -1054,7 +1058,7 @@ static void domain_suspend_callback_common(libxl__egc *egc,
 {
     STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
-    int ret;
+    int ret, rc;
 
     /* Convenience aliases */
     const uint32_t domid = dss->domid;
@@ -1064,21 +1068,19 @@ static void domain_suspend_callback_common(libxl__egc *egc,
         xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
     }
 
-    if ((hvm_s_state == 0) && (dss->suspend_eventchn >= 0)) {
+    if ((hvm_s_state == 0) && (dss->guest_evtchn.port >= 0)) {
         LOG(DEBUG, "issuing %s suspend request via event channel",
             dss->hvm ? "PVHVM" : "PV");
-        ret = xc_evtchn_notify(dss->xce, dss->suspend_eventchn);
+        ret = xc_evtchn_notify(CTX->xce, dss->guest_evtchn.port);
         if (ret < 0) {
             LOG(ERROR, "xc_evtchn_notify failed ret=%d", ret);
             goto err;
         }
-        ret = xc_await_suspend(CTX->xch, dss->xce, dss->suspend_eventchn);
-        if (ret < 0) {
-            LOG(ERROR, "xc_await_suspend failed ret=%d", ret);
-            goto err;
-        }
-        dss->guest_responded = 1;
-        domain_suspend_common_guest_suspended(egc, dss);
+
+        dss->guest_evtchn.callback = domain_suspend_common_wait_guest_evtchn;
+        rc = libxl__ev_evtchn_wait(gc, &dss->guest_evtchn);
+        if (rc) goto err;
+
         return;
     }
 
@@ -1114,6 +1116,19 @@ static void domain_suspend_callback_common(libxl__egc *egc,
     domain_suspend_common_failed(egc, dss);
 }
 
+static void domain_suspend_common_wait_guest_evtchn(libxl__egc *egc,
+        libxl__ev_evtchn *evev)
+{
+    libxl__domain_suspend_state *dss = CONTAINER_OF(evev, *dss, guest_evtchn);
+    STATE_AO_GC(dss->ao);
+    /* If we should be done waiting, suspend_common_wait_guest_check
+     * will end up calling domain_suspend_common_guest_suspended or
+     * domain_suspend_common_failed, both of which cancel the evtchn
+     * wait.  So re-enable it now. */
+    libxl__ev_evtchn_wait(gc, &dss->guest_evtchn);
+    suspend_common_wait_guest_check(egc, dss);
+}
+
 static void domain_suspend_common_pvcontrol_suspending(libxl__egc *egc,
       libxl__xswait_state *xswa, int rc, const char *state)
 {
@@ -1203,8 +1218,13 @@ static void domain_suspend_common_wait_guest(libxl__egc *egc,
 static void suspend_common_wait_guest_watch(libxl__egc *egc,
       libxl__ev_xswatch *xsw, const char *watch_path, const char *event_path)
 {
-    libxl__domain_suspend_state *dss =
-        CONTAINER_OF(xsw, *dss, guest_watch);
+    libxl__domain_suspend_state *dss = CONTAINER_OF(xsw, *dss, guest_watch);
+    suspend_common_wait_guest_check(egc, dss);
+}
+
+static void suspend_common_wait_guest_check(libxl__egc *egc,
+        libxl__domain_suspend_state *dss)
+{
     STATE_AO_GC(dss->ao);
     xc_domaininfo_t info;
     int ret;
@@ -1261,6 +1281,7 @@ static void domain_suspend_common_guest_suspended(libxl__egc *egc,
     STATE_AO_GC(dss->ao);
     int ret;
 
+    libxl__ev_evtchn_cancel(gc, &dss->guest_evtchn);
     libxl__ev_xswatch_deregister(gc, &dss->guest_watch);
     libxl__ev_time_deregister(gc, &dss->guest_timeout);
 
@@ -1287,6 +1308,7 @@ static void domain_suspend_common_done(libxl__egc *egc,
 {
     EGC_GC;
     assert(!libxl__xswait_inuse(&dss->pvcontrol));
+    libxl__ev_evtchn_cancel(gc, &dss->guest_evtchn);
     libxl__ev_xswatch_deregister(gc, &dss->guest_watch);
     libxl__ev_time_deregister(gc, &dss->guest_timeout);
     dss->callback_common_done(egc, dss, ok);
@@ -1475,6 +1497,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 
     logdirty_init(&dss->logdirty);
     libxl__xswait_init(&dss->pvcontrol);
+    libxl__ev_evtchn_init(&dss->guest_evtchn);
     libxl__ev_xswatch_init(&dss->guest_watch);
     libxl__ev_time_init(&dss->guest_timeout);
 
@@ -1503,7 +1526,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
           | (debug ? XCFLAGS_DEBUG : 0)
           | (dss->hvm ? XCFLAGS_HVM : 0);
 
-    dss->suspend_eventchn = -1;
+    dss->guest_evtchn.port = -1;
     dss->guest_evtchn_lockfd = -1;
     dss->guest_responded = 0;
     dss->dm_savefile = libxl__device_model_savefile(gc, domid);
@@ -1514,20 +1537,17 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
             dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
     }
 
-    dss->xce = xc_evtchn_open(NULL, 0);
-    if (dss->xce == NULL)
-        goto out;
-    else
-    {
-        port = xs_suspend_evtchn_port(dss->domid);
+    port = xs_suspend_evtchn_port(dss->domid);
 
-        if (port >= 0) {
-            dss->suspend_eventchn =
-                xc_suspend_evtchn_init_exclusive(CTX->xch, dss->xce,
+    if (port >= 0) {
+        dss->guest_evtchn.port =
+            xc_suspend_evtchn_init_exclusive(CTX->xch, CTX->xce,
                                   dss->domid, port, &dss->guest_evtchn_lockfd);
 
-            if (dss->suspend_eventchn < 0)
-                LOG(WARN, "Suspend event channel initialization failed");
+        if (dss->guest_evtchn.port < 0) {
+            LOG(WARN, "Suspend event channel initialization failed");
+            rc = ERROR_FAIL;
+            goto out;
         }
     }
 
@@ -1686,11 +1706,11 @@ static void domain_suspend_done(libxl__egc *egc,
     /* Convenience aliases */
     const uint32_t domid = dss->domid;
 
-    if (dss->suspend_eventchn > 0)
-        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
-                           dss->suspend_eventchn, &dss->guest_evtchn_lockfd);
-    if (dss->xce != NULL)
-        xc_evtchn_close(dss->xce);
+    libxl__ev_evtchn_cancel(gc, &dss->guest_evtchn);
+
+    if (dss->guest_evtchn.port > 0)
+        xc_suspend_evtchn_release(CTX->xch, CTX->xce, domid,
+                           dss->guest_evtchn.port, &dss->guest_evtchn_lockfd);
 
     dss->callback(egc, dss, rc);
 }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d428e77..126e5bf 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2404,8 +2404,7 @@ struct libxl__domain_suspend_state {
     int debug;
     const libxl_domain_remus_info *remus;
     /* private */
-    xc_evtchn *xce; /* event channel handle */
-    int suspend_eventchn;
+    libxl__ev_evtchn guest_evtchn;
     int guest_evtchn_lockfd;
     int hvm;
     int xcflags;
-- 
1.7.10.4

[PATCH 23/23] libxl: suspend: Apply guest timeout in evtchn case

[Ian Jackson]

When negotiating guest suspend via the evtchn ("fast") protocol,
the guest may still fail to respond.

So set the timeout.  The existing error path will already properly
tear down our (event channel) wait.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c431a2d..820ec3a 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1081,6 +1081,11 @@ static void domain_suspend_callback_common(libxl__egc *egc,
         rc = libxl__ev_evtchn_wait(gc, &dss->guest_evtchn);
         if (rc) goto err;
 
+        rc = libxl__ev_time_register_rel(gc, &dss->guest_timeout,
+                                         suspend_common_wait_guest_timeout,
+                                         60*1000);
+        if (rc) goto err;
+
         return;
     }
 
-- 
1.7.10.4

Re: (no subject)

[George Dunlap]

On 12/17/2013 06:35 PM, Ian Jackson wrote:
> This series removes the usleeps and waiting loops in libxl_dom.c and
> replaces them with event-callback code.
>
> Firstly, some documentation of things I had to reverse-engineer:
>   01/23 xen: Document XEN_DOMCTL_subscribe
>   02/23 xen: Document that EVTCHNOP_bind_interdomain signals
>   03/23 docs: Document event-channel-based suspend protocol
>   04/23 libxc: Document xenctrl.h event channel calls
> Arguably these might be 4.4 material (hence the CC to George).

These document pretty important aspects of behavior (fixing what might 
be considered documentation bugs), and obviously can have no functional 
impact.  I guess the only risk is that they might be wrong and mislead 
someone, but I think that's pretty low. :-)

These four:

Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Re: (no subject)

[Ian Campbell]

On Wed, 2013-12-18 at 11:19 +0000, George Dunlap wrote:
> On 12/17/2013 06:35 PM, Ian Jackson wrote:
> > This series removes the usleeps and waiting loops in libxl_dom.c and
> > replaces them with event-callback code.
> >
> > Firstly, some documentation of things I had to reverse-engineer:
> >   01/23 xen: Document XEN_DOMCTL_subscribe
> >   02/23 xen: Document that EVTCHNOP_bind_interdomain signals
> >   03/23 docs: Document event-channel-based suspend protocol
> >   04/23 libxc: Document xenctrl.h event channel calls
> > Arguably these might be 4.4 material (hence the CC to George).
> 
> These document pretty important aspects of behavior (fixing what might 
> be considered documentation bugs), and obviously can have no functional 
> impact.  I guess the only risk is that they might be wrong and mislead 
> someone, but I think that's pretty low. :-)
> 
> These four:
> 
> Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>

They look good to me too:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Re: [PATCH 05/23] libxl: init: Provide a gc later in libxl_ctx_alloc

[Ian Campbell]

On Tue, 2013-12-17 at 18:35 +0000, Ian Jackson wrote:
> Provide libxl__gc *gc for the second half of libxl_ctx_alloc.
> (For the first half of the function, gc is in scope but set to NULL.)

libxl uses -Wno-declaration-after-statement so it would be valid to just
declare it at the point it becomes valid, would avoid mistakes with
people adding uses before this point.

> This makes it possible to make gc-requiring calls.  For example, it
> makes error logging more convenient.
> 
> Make use of this by changing the logging calls to use the LOG*
> convenience macros.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/libxl/libxl.c |   11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index e8ad610..cfd1435 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -25,6 +25,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>                      unsigned flags, xentoollog_logger * lg)
>  {
>      libxl_ctx *ctx = NULL;
> +    libxl__gc gc_buf, *gc = NULL;
>      int rc;
>  
>      if (version != LIBXL_VERSION) { rc = ERROR_VERSION; goto out; }
> @@ -79,6 +80,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      }
>  
>      /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
> +    LIBXL_INIT_GC(gc_buf,ctx);
> +    gc = &gc_buf;
> +    /* Now gc is useable */
>  
>      rc = libxl__atfork_init(ctx);
>      if (rc) goto out;
> @@ -88,8 +92,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>  
>      ctx->xch = xc_interface_open(lg,lg,0);
>      if (!ctx->xch) {
> -        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
> -                        "cannot open libxc handle");
> +        LOGEV(ERROR, errno, "cannot open libxc handle");
>          rc = ERROR_FAIL; goto out;
>      }
>  
> @@ -97,8 +100,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      if (!ctx->xsh)
>          ctx->xsh = xs_domain_open();
>      if (!ctx->xsh) {
> -        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
> -                        "cannot connect to xenstore");
> +        LOGEV(ERROR, errno, "cannot connect to xenstore");
>          rc = ERROR_FAIL; goto out;
>      }
>  
> @@ -106,6 +108,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      return 0;
>  
>   out:
> +    if (gc) libxl__free_all(gc);
>      libxl_ctx_free(ctx);
>      *pctx = NULL;
>      return rc;

Re: [PATCH 06/23] libxl: init: libxl__poller_init and _get take gc

[Ian Campbell]

On Tue, 2013-12-17 at 18:35 +0000, Ian Jackson wrote:
> @@ -1622,7 +1617,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
>      if (how) {
>          ao->how = *how;
>      } else {
> -        ao->poller = libxl__poller_get(ctx);
> +        ao->poller = libxl__poller_get(&ao->gc);

this is a bit subtle, libxl__poller_get would previously have gotten the
toplevel ctx gc and not the ao-gc, if it had thought to init a GC at
all.

It only actually uses whatever it gets for logging, so that's ok, but
I'm not sure which would be the correct/expected gc to use. I take it
you considered this?

libxl__poller_get does a NOGC allocation and the associated manual
memory mgmt -- now that it has the ao->gc in hand could it use that? Is
the poller's lifecycle entirely contained within the ao?

Ian.

Re: [PATCH 07/23] libxl: events: const-correct *_inuse, *_isregistered

[Ian Campbell]

On Tue, 2013-12-17 at 18:35 +0000, Ian Jackson wrote:
> The comments for libxl__ev_time_isregistered and the corresponding
> watch function even say that these should be const.  Make it so.
> 
> Also fix libxl__ev_child_inuse and libxl__ev_spawn_inuse.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |    8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 2712005..51d6c6d 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -716,7 +716,7 @@ _hidden int libxl__ev_fd_modify(libxl__gc*, libxl__ev_fd *ev,
>  _hidden void libxl__ev_fd_deregister(libxl__gc*, libxl__ev_fd *ev);
>  static inline void libxl__ev_fd_init(libxl__ev_fd *efd)
>                      { efd->fd = -1; }
> -static inline int libxl__ev_fd_isregistered(libxl__ev_fd *efd)
> +static inline int libxl__ev_fd_isregistered(const libxl__ev_fd *efd)
>                      { return efd->fd >= 0; }
>  
>  _hidden int libxl__ev_time_register_rel(libxl__gc*, libxl__ev_time *ev_out,
> @@ -732,7 +732,7 @@ _hidden int libxl__ev_time_modify_abs(libxl__gc*, libxl__ev_time *ev,
>  _hidden void libxl__ev_time_deregister(libxl__gc*, libxl__ev_time *ev);
>  static inline void libxl__ev_time_init(libxl__ev_time *ev)
>                  { ev->func = 0; }
> -static inline int libxl__ev_time_isregistered(libxl__ev_time *ev)
> +static inline int libxl__ev_time_isregistered(const libxl__ev_time *ev)
>                  { return !!ev->func; }
>  
> 
> @@ -772,7 +772,7 @@ _hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
>                                   libxl__ev_child_callback *death);
>  static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
>                  { childw_out->pid = -1; }
> -static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
> +static inline int libxl__ev_child_inuse(const libxl__ev_child *childw_out)
>                  { return childw_out->pid >= 0; }
>  
>  /* Useable (only) in the child to once more make the ctx useable for
> @@ -1213,7 +1213,7 @@ struct libxl__spawn_state {
>      libxl__ev_xswatch xswatch;
>  };
>  
> -static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
> +static inline int libxl__spawn_inuse(const libxl__spawn_state *ss)
>      { return libxl__ev_child_inuse(&ss->mid); }
>  
>  /*

Re: [PATCH 08/23] libxl: events: Provide libxl__xswait_*

[Ian Campbell]

On Tue, 2013-12-17 at 18:35 +0000, Ian Jackson wrote:
> +/*----- xswait: wait for a xenstore node to be suitable -----*/
> +
> +typedef struct libxl__xswait_state libxl__xswait_state;
> +
> +/*
> + * rc describes the circumstances of this callback:
> + *
> + * rc==0
> + *
> + *     The xenstore path (may have) changed.  It has been read for
> + *     you.  The result is in data (allocated from the ao gc).
> + *     data may be NULL, which means that the xenstore read gave
> + *     ENOENT.
> + *
> + *     If you are satisfied, you MUST call libxl__xswait_stop.
> + *     Otherwise, xswait will continue waiting and watching and
> + *     will call you back later.
> + *
> + * rc==ETIMEDOUT

Isn't rc actual a libxl error and hence ERROR_TIMEDOUT?

> + *
> + *     The specified timeout was reached.
> + *     This has NOT been logged (except to the debug log).
> + *     xswait will not continue (but calling libxl__xswait_stop is OK).
> + *
> + * rc!=0

also != E{,RROR_}TIMEDOUT </pedant>

> + *
> + *     Some other error occurred.
> + *     This HAS been logged.
> + *     xswait will not continue (but calling libxl__xswait_stop is OK).
> + *
> + */
> +typedef void libxl__xswait_callback(libxl__egc *egc,
> +      libxl__xswait_state *xswa, int rc, const char *data);
> +
> +struct libxl__xswait_state {
> +    /* caller must fill these in, and they must all remain valid */
> +    libxl__ao *ao;
> +    const char *what; /* for error msgs: noun phrase, what we're waiting for */
> +    const char *path;
> +    int timeout_ms; /* as for poll(2) */
> +    libxl__xswait_callback *callback;
> +    /* remaining fields are private to xswait */
> +    libxl__ev_time time_ev;
> +    libxl__ev_xswatch watch_ev;
> +};
> +
> +void libxl__xswait_init(libxl__xswait_state*);
> +void libxl__xswait_stop(libxl__gc*, libxl__xswait_state*); /*idempotent*/
> +bool libxl__xswait_inuse(const libxl__xswait_state *ss);
> +
> +int libxl__xswait_start(libxl__gc*, libxl__xswait_state*);
> +
>  /*
>   *----- spawn -----
>   *

Re: [PATCH 09/23] libxl: events: Use libxl__xswait_* in spawn code

[Ian Campbell]

On Tue, 2013-12-17 at 18:35 +0000, Ian Jackson wrote:
> Replace open-coded use of ev_time and ev_xswatch with xswait.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Re: [PATCH 10/23] libxl: events: Provide libxl__ev_evtchn*

[Ian Campbell]

On Tue, 2013-12-17 at 18:35 +0000, Ian Jackson wrote:
> This also involves providing a gc for the latter part of
> libxl_ctx_alloc.

Didn't you do that bit in an earlier patch? I guess you forgot to update
this message when you refactored.

> +static void evtchn_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
> +                               int fd, short events, short revents)
> +{
> +    EGC_GC;
> +    libxl__ev_evtchn *evev;
> +    int port, r, rc;

Should port be evtchn_port_or_error_t ? (from the use I don't think
plain evtchn_port_t would be valid)

> [...]
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 5d2e651..c519abc 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -197,6 +197,17 @@ struct libxl__ev_xswatch {
>      uint32_t counterval;
>  };
>  
> +typedef struct libxl__ev_evtchn libxl__ev_evtchn;
> +typedef void libxl__ev_evtchn_callback(libxl__egc *egc, libxl__ev_evtchn*);
> +struct libxl__ev_evtchn {
> +    /* caller must fill these in, and they must all remain valid */
> +    libxl__ev_evtchn_callback *callback;
> +    int port;

evtchn_port_t?

> +    /* remainder is private for libxl__ev_evtchn_... */
> +    bool waiting;
> +    LIBXL_LIST_ENTRY(libxl__ev_evtchn) entry;
> +};
> +
>  /*
>   * An entry in the watch_slots table is either:
>   *  1. an entry in the free list, ie NULL or pointer to next free list entry
> @@ -343,6 +354,10 @@ struct libxl__ctx {
>      uint32_t watch_counter; /* helps disambiguate slot reuse */
>      libxl__ev_fd watch_efd;
>  
> +    xc_evtchn *xce; /* for waiting use only libxl__ev_evtchn* */

The comment means "don't use directly, use libxl__ev-evtchn"?

Or does it imply that for uses other than waiting you may use it
directly?

> +    LIBXL_LIST_HEAD(, libxl__ev_evtchn) evtchns_waiting;

Are there any locking requirements relating to this list?

> +    libxl__ev_fd evtchn_efd;
> +
>      LIBXL_TAILQ_HEAD(libxl__evgen_domain_death_list, libxl_evgen_domain_death)
>          death_list /* sorted by domid */,
>          death_reported;
> @@ -748,6 +763,39 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
>  
> 
>  /*
> + * The evtchn facility is one-shot per call t libxl__ev_evtchn_wait.

s/ t / to /

> + * You should call some suitable xc bind function on (or to obtain)
> + * the port, then libxl__ev_evtchn_wait.
> + *
> + * When the event is signaled then the callback will be made, once.
> + * Then you must call libxl__ev_evtchn_wait again, if desired.
> + *
> + * You must NOT call xc_evtchn_unmask.  wait will do that for you.
> + *
> + * Calling libxl__ev_evtchn_cancel will arrange for libxl to disregard
> + * future occurrences of event.  Both libxl__ev_evtchn_wait and
> + * libxl__ev_evtchn_cancel are idempotent.
> + *
> + * (Note of course that an event channel becomes signaled when it is
> + * first bound, so you will get one call to libxl__ev_evtchn_wait
> + * "right away"; unless you have won a very fast race, the condition
> + * you were waiting for won't exist yet so when you check for it
> + * you'll find you need to call wait again.)
> + *
> + * You must not wait on the same port twice at once (that is, with
> + * two separate libxl__ev_evtchn's).

Doing so would require per wait xce_handles? Worth avoiding.

> + */
> +_hidden int libxl__ev_evtchn_wait(libxl__gc*, libxl__ev_evtchn *evev);
> +_hidden void libxl__ev_evtchn_cancel(libxl__gc *gc, libxl__ev_evtchn *evev);
> +
> +static inline void libxl__ev_evtchn_init(libxl__ev_evtchn *evev)
> +                { evev->waiting = 0; }
> +static inline bool libxl__ev_evtchn_iswaiting(const libxl__ev_evtchn *evev)
> +                { return evev->waiting; }
> +
> +_hidden int libxl__ctx_evtchn_init(libxl__gc *gc); /* for libxl_ctx_alloc */
> +
> +/*
>   * For making subprocesses.  This is the only permitted mechanism for
>   * code in libxl to do so.
>   *

Re: [PATCH 05/23] libxl: init: Provide a gc later in libxl_ctx_alloc

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 05/23] libxl: init: Provide a gc later in libxl_ctx_alloc"):
> On Tue, 2013-12-17 at 18:35 +0000, Ian Jackson wrote:
> > Provide libxl__gc *gc for the second half of libxl_ctx_alloc.
> > (For the first half of the function, gc is in scope but set to NULL.)
> 
> libxl uses -Wno-declaration-after-statement so it would be valid to just
> declare it at the point it becomes valid, would avoid mistakes with
> people adding uses before this point.

However, that would involve changing the "goto out" in the malloc
failure case to something else, because "goto out" would jump past the
initialisation of gc to NULL.

The malloc failure case can't be handled with our usual fatal error
logic because that depends on having a ctx.  I guess we could have a
dummy ctx but it would get fiddly.

Ian.

Re: [PATCH 06/23] libxl: init: libxl__poller_init and _get take gc

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 06/23] libxl: init: libxl__poller_init and _get take gc"):
> On Tue, 2013-12-17 at 18:35 +0000, Ian Jackson wrote:
> > @@ -1622,7 +1617,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
> >      if (how) {
> >          ao->how = *how;
> >      } else {
> > -        ao->poller = libxl__poller_get(ctx);
> > +        ao->poller = libxl__poller_get(&ao->gc);
> 
> this is a bit subtle, libxl__poller_get would previously have gotten the
> toplevel ctx gc and not the ao-gc, if it had thought to init a GC at
> all.

Yes.

> It only actually uses whatever it gets for logging, so that's ok, but
> I'm not sure which would be the correct/expected gc to use. I take it
> you considered this?

Indeed.

> libxl__poller_get does a NOGC allocation and the associated manual
> memory mgmt -- now that it has the ao->gc in hand could it use that? Is
> the poller's lifecycle entirely contained within the ao?

No, it isn't.  The poller is longer-lived, mainly as a way to avoid
having to recreate the pipe on each occasion.

Ian.

Re: [PATCH 08/23] libxl: events: Provide libxl__xswait_*

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 08/23] libxl: events: Provide libxl__xswait_*"):
> On Tue, 2013-12-17 at 18:35 +0000, Ian Jackson wrote:
> > +/*----- xswait: wait for a xenstore node to be suitable -----*/
> > + *     If you are satisfied, you MUST call libxl__xswait_stop.
> > + *     Otherwise, xswait will continue waiting and watching and
> > + *     will call you back later.
> > + *
> > + * rc==ETIMEDOUT
> 
> Isn't rc actual a libxl error and hence ERROR_TIMEDOUT?

Err, yes.

> > + *
> > + *     The specified timeout was reached.
> > + *     This has NOT been logged (except to the debug log).
> > + *     xswait will not continue (but calling libxl__xswait_stop is OK).
> > + *
> > + * rc!=0
> 
> also != E{,RROR_}TIMEDOUT </pedant>

Both will be fixed in v2.

Ian.

Re: [PATCH 10/23] libxl: events: Provide libxl__ev_evtchn*

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 10/23] libxl: events: Provide libxl__ev_evtchn*"):
> On Tue, 2013-12-17 at 18:35 +0000, Ian Jackson wrote:
> > This also involves providing a gc for the latter part of
> > libxl_ctx_alloc.
> 
> Didn't you do that bit in an earlier patch? I guess you forgot to update
> this message when you refactored.

Yes.

> > +static void evtchn_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
> > +                               int fd, short events, short revents)
> > +{
> > +    EGC_GC;
> > +    libxl__ev_evtchn *evev;
> > +    int port, r, rc;
> 
> Should port be evtchn_port_or_error_t ? (from the use I don't think
> plain evtchn_port_t would be valid)

Fixed.

> > [...]
> > +struct libxl__ev_evtchn {
> > +    /* caller must fill these in, and they must all remain valid */
> > +    libxl__ev_evtchn_callback *callback;
> > +    int port;
> 
> evtchn_port_t?

Leaving it as "int" means that the caller can put -1 in it if the
struct isn't in use or the port not allocated.  That avoids the caller
needing to have a separate copy of the value, or a separate boolean.
And later, we do.

> > @@ -343,6 +354,10 @@ struct libxl__ctx {
> >      uint32_t watch_counter; /* helps disambiguate slot reuse */
> >      libxl__ev_fd watch_efd;
> >  
> > +    xc_evtchn *xce; /* for waiting use only libxl__ev_evtchn* */
> 
> The comment means "don't use directly, use libxl__ev-evtchn"?
>
> Or does it imply that for uses other than waiting you may use it
> directly?

The latter.  I'm open to suggestions for improved wording.

> > +    LIBXL_LIST_HEAD(, libxl__ev_evtchn) evtchns_waiting;
> 
> Are there any locking requirements relating to this list?

They are the same as all the other event-related data structures in
the ctx: the ctx mutex protects them.  This isn't particularly
explicit here but I think it's fairly obvious.  Only the event code
looks at this list anyway and it all takes a gc.

> >  /*
> > + * The evtchn facility is one-shot per call t libxl__ev_evtchn_wait.
> 
> s/ t / to /

Fixed.

> > + * You must not wait on the same port twice at once (that is, with
> > + * two separate libxl__ev_evtchn's).
> 
> Doing so would require per wait xce_handles? Worth avoiding.

It would be possible to improve the data structure and event code to
support this.  The obvious way would be to keep scanning the
evtchns_waiting list after we found one waiter, but you'd have to do
something fiddly to avoid reentering the same waiter again right away.

Thanks,
Ian.

Re: [PATCH 10/23] libxl: events: Provide libxl__ev_evtchn*

[Ian Campbell]

On Thu, 2013-12-19 at 17:47 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 10/23] libxl: events: Provide libxl__ev_evtchn*"):
> > > [...]
> > > +struct libxl__ev_evtchn {
> > > +    /* caller must fill these in, and they must all remain valid */
> > > +    libxl__ev_evtchn_callback *callback;
> > > +    int port;
> > 
> > evtchn_port_t?
> 
> Leaving it as "int" means that the caller can put -1 in it if the
> struct isn't in use or the port not allocated.  That avoids the caller
> needing to have a separate copy of the value, or a separate boolean.
> And later, we do.

I suppose that's vaguely the same sort of thing as
evtchn_port_or_error_t, but not quite.

> 
> > > @@ -343,6 +354,10 @@ struct libxl__ctx {
> > >      uint32_t watch_counter; /* helps disambiguate slot reuse */
> > >      libxl__ev_fd watch_efd;
> > >  
> > > +    xc_evtchn *xce; /* for waiting use only libxl__ev_evtchn* */
> > 
> > The comment means "don't use directly, use libxl__ev-evtchn"?
> >
> > Or does it imply that for uses other than waiting you may use it
> > directly?
> 
> The latter.  I'm open to suggestions for improved wording.

"waiting must only be done via libxl__ev_..." not much better though.

> 
> > > +    LIBXL_LIST_HEAD(, libxl__ev_evtchn) evtchns_waiting;
> > 
> > Are there any locking requirements relating to this list?
> 
> They are the same as all the other event-related data structures in
> the ctx: the ctx mutex protects them.  This isn't particularly
> explicit here but I think it's fairly obvious.  Only the event code
> looks at this list anyway and it all takes a gc.

OK.

> > > + * You must not wait on the same port twice at once (that is, with
> > > + * two separate libxl__ev_evtchn's).
> > 
> > Doing so would require per wait xce_handles? Worth avoiding.
> 
> It would be possible to improve the data structure and event code to
> support this.  The obvious way would be to keep scanning the
> evtchns_waiting list after we found one waiter, but you'd have to do
> something fiddly to avoid reentering the same waiter again right away.

Yes, easiest to avoid until the requirement occurs I think.

Ian.

Re: [PATCH 10/23] libxl: events: Provide libxl__ev_evtchn*

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 10/23] libxl: events: Provide libxl__ev_evtchn*"):
> On Thu, 2013-12-19 at 17:47 +0000, Ian Jackson wrote:
> > Leaving it as "int" means that the caller can put -1 in it if the
> > struct isn't in use or the port not allocated.  That avoids the caller
> > needing to have a separate copy of the value, or a separate boolean.
> > And later, we do.
> 
> I suppose that's vaguely the same sort of thing as
> evtchn_port_or_error_t, but not quite.

Yes.

> > The latter.  I'm open to suggestions for improved wording.
> 
> "waiting must only be done via libxl__ev_..." not much better though.

I will change it to:

    xc_evtchn *xce; /* waiting must be done only with libxl__ev_evtchn* */
    
Thanks,
Ian.

Re: (no subject)

[Ian Campbell]

On Wed, 2013-12-18 at 13:35 +0000, Ian Campbell wrote:
> On Wed, 2013-12-18 at 11:19 +0000, George Dunlap wrote:
> > On 12/17/2013 06:35 PM, Ian Jackson wrote:
> > > This series removes the usleeps and waiting loops in libxl_dom.c and
> > > replaces them with event-callback code.
> > >
> > > Firstly, some documentation of things I had to reverse-engineer:
> > >   01/23 xen: Document XEN_DOMCTL_subscribe
> > >   02/23 xen: Document that EVTCHNOP_bind_interdomain signals
> > >   03/23 docs: Document event-channel-based suspend protocol
> > >   04/23 libxc: Document xenctrl.h event channel calls
> > > Arguably these might be 4.4 material (hence the CC to George).
> > 
> > These document pretty important aspects of behavior (fixing what might 
> > be considered documentation bugs), and obviously can have no functional 
> > impact.  I guess the only risk is that they might be wrong and mislead 
> > someone, but I think that's pretty low. :-)
> > 
> > These four:
> > 
> > Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> They look good to me too:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

And I've now applied just those 4 docs changes.

Ian.

Re: [PATCH 11/23] libxc: suspend: Rename, improve xc_suspend_evtchn_init

[Ian Campbell]

On Tue, 2013-12-17 at 18:35 +0000, Ian Jackson wrote:
> xc_suspend_evtchn_init expects to eat the first event on the xce.  If
> the xce is used for any other purpose then this can break.  Document
> this fact and rename the function to xc_suspend_evtchn_init_exclusive.
> (I haven't checked the call sites for improper shared use of the xce.)
> 
> Provide a corresponding xc_suspend_evtchn_init_sane which doesn't try
> to eat an event, and instead leaves the caller the ability to
> demultiplex.

I'd much rather have fixed the existing one (and its callers as
necessary) but I can see why you wouldn't have the appetite for that.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Also document that xc_await_suspend needs exclusive use of the xce.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Ian Campbell <ian.campbell@citrix.com>
> CC: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> ---
>  tools/libxc/xc_suspend.c                           |   21 ++++++++++++++++----
>  tools/libxc/xenguest.h                             |   13 +++++++++++-
>  tools/libxl/libxl_dom.c                            |    2 +-
>  tools/misc/xen-hptool.c                            |    2 +-
>  .../python/xen/lowlevel/checkpoint/libcheckpoint.c |    2 +-
>  tools/xcutils/xc_save.c                            |    2 +-
>  6 files changed, 33 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/libxc/xc_suspend.c b/tools/libxc/xc_suspend.c
> index 1ace411..7968a44 100644
> --- a/tools/libxc/xc_suspend.c
> +++ b/tools/libxc/xc_suspend.c
> @@ -14,6 +14,8 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
>   */
>  
> +#include <assert.h>
> +
>  #include "xc_private.h"
>  #include "xenguest.h"
>  
> @@ -102,7 +104,7 @@ int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int domid, int
>      return unlock_suspend_event(xch, domid);
>  }
>  
> -int xc_suspend_evtchn_init(xc_interface *xch, xc_evtchn *xce, int domid, int port)
> +int xc_suspend_evtchn_init_sane(xc_interface *xch, xc_evtchn *xce, int domid, int port)
>  {
>      int rc, suspend_evtchn = -1;
>  
> @@ -121,9 +123,6 @@ int xc_suspend_evtchn_init(xc_interface *xch, xc_evtchn *xce, int domid, int por
>          goto cleanup;
>      }
>  
> -    /* event channel is pending immediately after binding */
> -    xc_await_suspend(xch, xce, suspend_evtchn);
> -
>      return suspend_evtchn;
>  
>  cleanup:
> @@ -132,3 +131,17 @@ cleanup:
>  
>      return -1;
>  }
> +
> +int xc_suspend_evtchn_init_exclusive(xc_interface *xch, xc_evtchn *xce, int domid, int port)
> +{
> +    int suspend_evtchn;
> +
> +    suspend_evtchn = xc_suspend_evtchn_init_sane(xch, xce, domid, port);
> +    if (suspend_evtchn < 0)
> +        return suspend_evtchn;
> +
> +    /* event channel is pending immediately after binding */
> +    xc_await_suspend(xch, xce, suspend_evtchn);
> +
> +    return suspend_evtchn;
> +}
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index a0e30e1..ce5456c 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -256,10 +256,21 @@ int xc_hvm_build_target_mem(xc_interface *xch,
>  
>  int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int domid, int suspend_evtchn);
>  
> -int xc_suspend_evtchn_init(xc_interface *xch, xc_evtchn *xce, int domid, int port);
> +/**
> + * This function eats the initial notification.
> + * xce must not be used for anything else
> + */
> +int xc_suspend_evtchn_init_exclusive(xc_interface *xch, xc_evtchn *xce, int domid, int port);
>  
> +/* xce must not be used for anything else */
>  int xc_await_suspend(xc_interface *xch, xc_evtchn *xce, int suspend_evtchn);
>  
> +/**
> + * The port will be signaled immediately after this call
> + * The caller should check the domain status and look for the next event
> + */
> +int xc_suspend_evtchn_init_sane(xc_interface *xch, xc_evtchn *xce, int domid, int port);
> +
>  int xc_get_bit_size(xc_interface *xch,
>                      const char *image_name, const char *cmdline,
>                      const char *features, int *type);
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 55f74b2..4b42856 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -1358,7 +1358,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
>  
>          if (port >= 0) {
>              dss->suspend_eventchn =
> -                xc_suspend_evtchn_init(CTX->xch, dss->xce, dss->domid, port);
> +                xc_suspend_evtchn_init_exclusive(CTX->xch, dss->xce, dss->domid, port);
>  
>              if (dss->suspend_eventchn < 0)
>                  LOG(WARN, "Suspend event channel initialization failed");
> diff --git a/tools/misc/xen-hptool.c b/tools/misc/xen-hptool.c
> index 24c3e95..db76f79 100644
> --- a/tools/misc/xen-hptool.c
> +++ b/tools/misc/xen-hptool.c
> @@ -112,7 +112,7 @@ static int suspend_guest(xc_interface *xch, xc_evtchn *xce, int domid, int *evtc
>          fprintf(stderr, "DOM%d: No suspend port, try live migration\n", domid);
>          goto failed;
>      }
> -    suspend_evtchn = xc_suspend_evtchn_init(xch, xce, domid, port);
> +    suspend_evtchn = xc_suspend_evtchn_init_exclusive(xch, xce, domid, port);
>      if (suspend_evtchn < 0)
>      {
>          fprintf(stderr, "Suspend evtchn initialization failed\n");
> diff --git a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> index 01c0d47..817d272 100644
> --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> @@ -360,7 +360,7 @@ static int setup_suspend_evtchn(checkpoint_state* s)
>      return -1;
>    }
>  
> -  s->suspend_evtchn = xc_suspend_evtchn_init(s->xch, s->xce, s->domid, port);
> +  s->suspend_evtchn = xc_suspend_evtchn_init_exclusive(s->xch, s->xce, s->domid, port);
>    if (s->suspend_evtchn < 0) {
>        s->errstr = "failed to bind suspend event channel";
>        return -1;
> diff --git a/tools/xcutils/xc_save.c b/tools/xcutils/xc_save.c
> index e34bd2c..974f706 100644
> --- a/tools/xcutils/xc_save.c
> +++ b/tools/xcutils/xc_save.c
> @@ -202,7 +202,7 @@ main(int argc, char **argv)
>          else
>          {
>              si.suspend_evtchn =
> -              xc_suspend_evtchn_init(si.xch, si.xce, si.domid, port);
> +              xc_suspend_evtchn_init_exclusive(si.xch, si.xce, si.domid, port);
>  
>              if (si.suspend_evtchn < 0)
>                  warnx("suspend event channel initialization failed, "

Re: (no subject)

[Razvan Cojocaru]

Apologies, the subject should have been, of course, "[PATCH V7 0/5] Fix
VGA logdirty related display freezes with altp2m", which I did paste in,
but ommited to uncomment.


Sorry,
Razvan

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

(no subject)

[Razvan Cojocaru]

This series aims to prevent the display from freezing when
enabling altp2m and switching to a new view (and assorted problems
when resizing the display).

The first patch introduces p2m_{init,free}_logdirty(), the second
allocates  a new logdirty rangeset for each new altp2m, and the
fourth propagates (under lock) changes to all p2ms.

Since the last version of the series, what has previously been
the first patch is already upstream, and two patches kindly
authored by George Dunlap have been appended. The patches
optimize the way rangeset changes are propagated in
change_type_range().

[PATCH V7 1/5] x86/mm: introduce p2m_{init,free}_logdirty()
[PATCH V7 2/5] x86/mm: allocate logdirty_ranges for altp2ms
[PATCH V7 3/5] x86/altp2m: fix display frozen when switching to a new view early
[PATCH V7 4/5] p2m: Always use hostp2m when clipping rangesets
[PATCH V7 5/5] p2m: change_range_type: Only invalidate mapped gfns


Thanks,
Razvan

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

(no subject)

[futurelieswithin]

[-- Attachment #1.1: Type: text/plain, Size: 299 bytes --]

A story perhaps i remember snapping my fingers and at mr miagi request it actually makes things appear and quantasize then a paculiar planet red and orange appeared outa nowhere it was a Pic of what the earth looked like 13.6 billion years  



Sent from my Samsung Galaxy , an AT&T LTE smartphone

[-- Attachment #1.2: Type: text/html, Size: 577 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[Chao Gao]

From 3aa2541108f28cfdf0f3bf47ddae9b762b73b532 Mon Sep 17 00:00:00 2001
From: Chao Gao <chao.gao@intel.com>
Date: Mon, 7 Aug 2017 04:50:04 +0800
Subject: [PATCH v9] VT-d: use correct BDF for VF to search VT-d unit

When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under
the scope of the same VT-d unit as the 'Physical Function'. A 'Physical
Function' can be a 'Traditional Function' or an ARI 'Extended Function'.
And furthermore, 'Extended Functions' on an endpoint are under the scope of
the same VT-d unit as the 'Traditional Functions' on the endpoint. To search
VT-d unit, the BDF of PF or the BDF of a traditional function may be used. And
it depends on whether the PF is an extended function or not.

Current code uses PCI_SLOT() to recognize an ARI 'Extended Funcion'. But it
is conceptually wrong w/o checking whether PF is an extended function and
would lead to match VFs of a RC endpoint to a wrong VT-d unit.

This patch uses VF's 'is_extfn' field to indicate whether the PF of this VF is
an extended function. The field helps to use correct BDF to search VT-d unit.

Reported-by: Crawford, Eric R <Eric.R.Crawford@intel.com>
Signed-off-by: Chao Gao <chao.gao@intel.com>
---
v9:
 - check 'is_virtfn' first in pci_add_device() to avoid potential error if
 linux side sets VF's 'is_extfn'
 - comments changes to make it clear that we use VF's 'is_extfn' intentionally
 otherwise the patch seems like a workaround.

v8:
 - use "conceptually wrong", instead of "a corner case" in commit message
 - check 'is_virtfn' first in acpi_find_matched_drhd_unit()

v7:
 - Drop Eric's tested-by
 - Change commit message to be clearer
 - Re-use VF's is_extfn field
 - access PF's is_extfn field in locked area

---
 xen/drivers/passthrough/pci.c      | 14 ++++++++++----
 xen/drivers/passthrough/vtd/dmar.c | 12 ++++++------
 xen/include/xen/pci.h              |  1 +
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 27bdb71..0e27e29 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -599,21 +599,24 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
     unsigned int slot = PCI_SLOT(devfn), func = PCI_FUNC(devfn);
     const char *pdev_type;
     int ret;
+    bool pf_is_extfn = false;
 
-    if (!info)
+    if ( !info )
         pdev_type = "device";
-    else if (info->is_extfn)
-        pdev_type = "extended function";
-    else if (info->is_virtfn)
+    else if ( info->is_virtfn )
     {
         pcidevs_lock();
         pdev = pci_get_pdev(seg, info->physfn.bus, info->physfn.devfn);
+        if ( pdev )
+            pf_is_extfn = pdev->info.is_extfn;
         pcidevs_unlock();
         if ( !pdev )
             pci_add_device(seg, info->physfn.bus, info->physfn.devfn,
                            NULL, node);
         pdev_type = "virtual function";
     }
+    else if ( info->is_extfn )
+        pdev_type = "extended function";
     else
     {
         info = NULL;
@@ -707,6 +710,9 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
                    seg, bus, slot, func, ctrl);
     }
 
+    /* VF's 'is_extfn' is used to indicate whether PF is an extended function */
+    if ( pdev->info.is_virtfn )
+        pdev->info.is_extfn = pf_is_extfn;
     check_pdev(pdev);
 
     ret = 0;
diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
index 82040dd..75c9c92 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -211,15 +211,15 @@ struct acpi_drhd_unit *acpi_find_matched_drhd_unit(const struct pci_dev *pdev)
     if ( pdev == NULL )
         return NULL;
 
-    if ( pdev->info.is_extfn )
+    if ( pdev->info.is_virtfn )
     {
-        bus = pdev->bus;
-        devfn = 0;
+        bus = pdev->info.physfn.bus;
+        devfn = pdev->info.is_extfn ? 0 : pdev->info.physfn.devfn;
     }
-    else if ( pdev->info.is_virtfn )
+    else if ( pdev->info.is_extfn )
     {
-        bus = pdev->info.physfn.bus;
-        devfn = PCI_SLOT(pdev->info.physfn.devfn) ? 0 : pdev->info.physfn.devfn;
+        bus = pdev->bus;
+        devfn = 0;
     }
     else
     {
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 59b6e8a..4dd42ac 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -39,6 +39,7 @@
 #define PCI_SBDF3(s,b,df) ((((s) & 0xffff) << 16) | PCI_BDF2(b, df))
 
 struct pci_dev_info {
+    /* VF's 'is_extfn' is used to show whether its PF an extended function */
     bool_t is_extfn;
     bool_t is_virtfn;
     struct {
-- 
1.8.3.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[Manonmani]

[-- Attachment #1.1: Type: text/plain, Size: 580 bytes --]

Is it possible to use VFB for paravirtualised Guest? How to display
Domain-U in physical monitor? I have added vfb in my Guest configuration
and it returns the following error :

Parsing config from
/etc/xen/arch_domU_1.cfg
libxl: error: libxl_dm.c:1233:libxl__spawn_local_dm: device model
/usr/lib/xen/b
in/qemu-dm is not executable: No such file or
directory
libxl: error: libxl_dm.c:1371:device_model_spawn_outcome: (null): spawn
failed (
rc=-3)

libxl: error: libxl_create.c:1186:domcreate_devmodel_started: device model
did n
ot start: -3

Thanks in advance.

Regards,
Joker

[-- Attachment #1.2: Type: text/html, Size: 916 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[Raviprasad Gurikar]

[-- Attachment #1.1: Type: text/plain, Size: 512 bytes --]


Hi .

I am ravi student from Indian I working on the xen arm development . I have plan to run the xen arm on fastmodel. But I am getting problem in the rootfilesystem creation and debootstrap  for this link https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/RootFilesystem. I am not able to entry the chroot ; if give the commands like this 

Sudo chroot /mnt;
Getting error like – error ; no such file or directory /bin/bash.

Please help me . 
Sent from Mail for Windows 10


[-- Attachment #1.2: Type: text/html, Size: 2158 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[Seraphime Kirkovski]

<ian.jackson@eu.citrix.com>
Bcc: 
Subject: Re: [PATCH] libxc: fix segfault on uninitialized xch->fmem
Reply-To: 
In-Reply-To: <20170404101507.lohlu5rbx4jq5md2@citrix.com>

On Tue, Apr 04, 2017 at 11:15:07AM +0100, Wei Liu wrote:
> Since there are a few handles in xch, it would be better to initialise
> them all at once by doing:
> 
>     struct xc_interface_core xch_buf = { 0 }
> 
> >      xch->flags = open_flags;
> >      xch->dombuild_logger_file = 0;
> >      xc_clear_last_error(xch);
> > -- 
> > 2.11.0
> > 

Hi, thanks for the reply.

Literally 10 minutes after sending this, I thought that a bzero would
be better. Will send a V2 shortly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[George Dunlap]

On Mon, Feb 27, 2017 at 6:12 PM, Dmitry Rockosov <rockosov@gmail.com> wrote:
> Hi guys,
>
> Do you know when *recognized* Virtual Interrupt on VM-Entry will be
> delivered if Virtual-Interrupt Delivery is enabled and interrupt delivery is
> blocking by STI?
>
> Previously, VMM used Interrupt-Window, but as I see in XEN code,
> Interrupt-Window is not used when Virtual Interrupt Delivery is enabled.
>
> Does it mean, we will get Virtual Interrupt on the next VM-entry?

CC'ing the VMX maintainer.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[Dmitry Rockosov]

[-- Attachment #1.1: Type: text/plain, Size: 421 bytes --]

Hi guys,

Do you know when *recognized* Virtual Interrupt on VM-Entry will be
delivered if Virtual-Interrupt Delivery is enabled and interrupt delivery
is blocking by STI?

Previously, VMM used Interrupt-Window, but as I see in XEN code,
Interrupt-Window is not used when Virtual Interrupt Delivery is enabled.

Does it mean, we will get Virtual Interrupt on the next VM-entry?

Thank you!

Best Regards,
Rockosov Dmitry

[-- Attachment #1.2: Type: text/html, Size: 676 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1927 bytes --]

On Fri, 2017-02-17 at 22:47 +0530, dhara buch wrote:
> Hello,
> 
> I have installed Ubuntu 15.10 in which have installed Xen with
> source.
> 
> Booting is done with Xen as well as commands like xl infor, xl list
> are also working fine.
> 
> For creating Virtual Machine, I have installed Virtual Machine
> Manager, but when I try to run it, it gives error as follows:
> 
> Unable to connect to libvirt.
> 
> internal error: libxenlight state driver is not active
> 
This means you have not installed the libvirt, libxl driver. Or that
you have, but trying to load it is failing.

There should be something in the libvirt logs.

However, since you said you've installed Xen from sources, you probably
need to build and install libvirt from sources too.

In fact, I don't know how exactly it is in Ubuntu, but in all the
distro I've tried, trying to install libvirt-daemon-driver-libxl (or
whatever the package is called), would fail, unless Xen hypervisor,
toolstack and libraries are also installed with the distro package
mamanger.

If that is not the case, install would either fail, or would bring in
those Xen packages, which would then either overrun or conflict with
your source installation.

> Verify that:
>  - A Xen host kernel was booted
>  - The Xen service has been started
> 
> I tried by installing libvirt as
> apt-get install libvirt-bin
> 
> but, still the same problem is found. Libvirtd service is also not
> getting started.
> 
> Where am I lacking?
> 
As said above. In all the distro I tried, when I build Xen from source,
I've always also had to build libvirt from sources.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[dhara buch]

[-- Attachment #1.1: Type: text/plain, Size: 660 bytes --]

Hello,

I have installed Ubuntu 15.10 in which have installed Xen with source.

Booting is done with Xen as well as commands like xl infor, xl list are
also working fine.

For creating Virtual Machine, I have installed Virtual Machine Manager, but
when I try to run it, it gives error as follows:







*Unable to connect to libvirt.internal error: libxenlight state driver is
not activeVerify that: - A Xen host kernel was booted - The Xen service has
been started*

I tried by installing libvirt as
apt-get install libvirt-bin

but, still the same problem is found. Libvirtd service is also not getting
started.

Where am I lacking?

Thank you,

Dhara Buch

[-- Attachment #1.2: Type: text/html, Size: 823 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Andrew Cooper]

On 17/02/17 10:47, Norbert Manthey wrote:
> Dear Xen developers,
>
> I would like to bring the attached two patches online, as they fix minor defects
> in the upstream code base.

Thankyou for the fixes; they are both good.

For future fixes, please can you CC the appropriate maintainers
(https://wiki.xen.org/wiki/Submitting_Xen_Project_Patches#Cc_the_maintainer_of_the_code_you_are_modifying),
and you probably want to join the xen-devel mailing list to avoid
getting held in moderation.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[Norbert Manthey]

Dear Xen developers,

I would like to bring the attached two patches online, as they fix minor defects
in the upstream code base.

Best,
Norbert

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[David Howells]

> -header-y += msr-index.h

I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI.  I don't think you can
remove it unless you can guarantee there are no userspace users.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[David Howells]

Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:

> This header file is exported, thus move it to uapi.

Exported how?

> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__		int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__	unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__	unsigned long
> +#endif

These weren't defined by the kernel before, so why do we need to define them
now?

Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by
changing the signature on C++ functions that use uintptr_t?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Stefano Stabellini]

On Wed, 28 Dec 2016, Ronald Rojas wrote:
> The first 57 commits are merged from previous work done by 
> George Dunlap at (https://github.com/gwd/schedbench) and 
> implement manipulating Cpu pool. The last 2 commits merge 
> his work onto the Xen tree and implement finding system 
> information and throwing errors.

You need to add your Signed-off-by to all patches you touched for
copyright reasons. In fact, usually people add their Signed-off-by to
all patches. 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[Ronald Rojas]

The first 57 commits are merged from previous work done by 
George Dunlap at (https://github.com/gwd/schedbench) and 
implement manipulating Cpu pool. The last 2 commits merge 
his work onto the Xen tree and implement finding system 
information and throwing errors.

CC: xen-devel <xen-devel@lists.xen.org>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: George Dunlap <george.dunlap@citrix.com>
CC: George Dunlap <dunlapg@umich.edu>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[Ronald Rojas]

Create a Makefile for the golang xenlight project, which will
allow users to access libxl functionality in Golang. Makefile 
rules were also added to tools/Makefile for the project to be 
built and installed. A template Golang file was also created 
for the project to be properly built. 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Ian Jackson]

George Dunlap writes ("Re:"):
> On 07/07/16 12:03, Dario Faggioli wrote:
> > So, you're saying I should change both Xen, xentrace_format and
> > xenalyze.c all at once, in the same patch, right?
...
> I think it often does make sense to check things out by component.  And
> of course before xenalyze was in tree, it doesn't matter when the change
> was done.  I suppose I've always been prejudiced against
> xentrace_format, which is why I'd never thought about regressions in it
> (although I probably should have).
> 
> But now that xenalyze is in-tree, I think we want to avoid situations
> where the in-tree xenalyze is broken, even just for one changeset, if we
> can avoid it.

This kind of situation is not that uncommon.  For any part of our
system where we don't offer a stable API, or at least one-way
intercompatibility, it is necessary to make incompatible changes both
in the producer and in all consumers.

(Sometimes this can mean a patch to xen.git needs to be combined with
a QEMU_TAG update for qemu-trad, too; in theory trying to decouple the
Xen API for qemu upstream.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[姚 å¿ å°†]

[-- Attachment #1.1: Type: text/plain, Size: 785 bytes --]

   Recently , I made a test to compare the performance of I/O between xen project and xenserver. I found the performance of xenserver is much better than that of xen project .

I want to find the reason why xenserver is better so I search through google.com. On the website www.xenproject.org<http://www.xenproject.org> , I found url http://wiki.xenproject.org/wiki/Tuning_Xen_for_Performance and http://wiki.xenproject.org/wiki/Network_Throughput_and_Performance_Guide .
I set these parameters as the url given. But , it looks doesn’t work. The performance got no obvious improvement.

So , I send this mail to get some advise . will you help me ? if so , I’ll  be much appreciate.


发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用


[-- Attachment #1.2: Type: text/html, Size: 3309 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 909 bytes --]

On Thu, 2016-07-07 at 13:48 +0100, George Dunlap wrote:
> On 07/07/16 12:03, Dario Faggioli wrote:
> > On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
> > > Could you re-send this with the trace change moved from the
> > > previous
> > > patch to this patch?
> > > 
> > So, you're saying I should change both Xen, xentrace_format and
> > xenalyze.c all at once, in the same patch, right?
> > 
> But now that xenalyze is in-tree, I think we want to avoid situations
> where the in-tree xenalyze is broken, even just for one changeset, if
> we
> can avoid it.
> 
Ok, this makes sense. Will do.

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[George Dunlap]

On 07/07/16 12:03, Dario Faggioli wrote:
> On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
>> On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
>> <dario.faggioli@citrix.com> wrote:
>>>
>>> in both xenalyze and formats (for xentrace_format).
>>>
>>> In particular, in xenalyze, now that we have the precision
>>> of the fixed point load values in the tracepoint, show both
>>> the raw value and the (easier to interpreet) percentage.
>>>
>>> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>> The change looks good in itself; but it makes me realize that
>> technically by changing the trace format, the previous patch
>> introduced a regression which is fixed here.  There's a part of me
>> that's tempted to overlook it because it's minor, but on balance I
>> think we should try to be diligent with this sort of thing.
>>
> Sure!
> 
>> Could you re-send this with the trace change moved from the previous
>> patch to this patch?
>>
> So, you're saying I should change both Xen, xentrace_format and
> xenalyze.c all at once, in the same patch, right?
> 
> I'm asking just to double check, as, although I see your point,
> separating things by component seemed a good thing to do to me, even at
> the price you describe, and I've done it before. :-)
> 
> As said, I'm fine doing that, I just want to be sure this is what you
> are asking.

I think it often does make sense to check things out by component.  And
of course before xenalyze was in tree, it doesn't matter when the change
was done.  I suppose I've always been prejudiced against
xentrace_format, which is why I'd never thought about regressions in it
(although I probably should have).

But now that xenalyze is in-tree, I think we want to avoid situations
where the in-tree xenalyze is broken, even just for one changeset, if we
can avoid it.

Thanks,
 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1801 bytes --]

On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
> On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
> <dario.faggioli@citrix.com> wrote:
> > 
> > in both xenalyze and formats (for xentrace_format).
> > 
> > In particular, in xenalyze, now that we have the precision
> > of the fixed point load values in the tracepoint, show both
> > the raw value and the (easier to interpreet) percentage.
> > 
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> The change looks good in itself; but it makes me realize that
> technically by changing the trace format, the previous patch
> introduced a regression which is fixed here.  There's a part of me
> that's tempted to overlook it because it's minor, but on balance I
> think we should try to be diligent with this sort of thing.
> 
Sure!

> Could you re-send this with the trace change moved from the previous
> patch to this patch?
> 
So, you're saying I should change both Xen, xentrace_format and
xenalyze.c all at once, in the same patch, right?

I'm asking just to double check, as, although I see your point,
separating things by component seemed a good thing to do to me, even at
the price you describe, and I've done it before. :-)

As said, I'm fine doing that, I just want to be sure this is what you
are asking.

> If you don't make any other changes, you can retain the reviewed-by
> of
> the previous patch, and add this one to this patch:
> 
> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
>
Ok, thanks.

Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[George Dunlap]

On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> in both xenalyze and formats (for xentrace_format).
>
> In particular, in xenalyze, now that we have the precision
> of the fixed point load values in the tracepoint, show both
> the raw value and the (easier to interpreet) percentage.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

The change looks good in itself; but it makes me realize that
technically by changing the trace format, the previous patch
introduced a regression which is fixed here.  There's a part of me
that's tempted to overlook it because it's minor, but on balance I
think we should try to be diligent with this sort of thing.

Could you re-send this with the trace change moved from the previous
patch to this patch?

If you don't make any other changes, you can retain the reviewed-by of
the previous patch, and add this one to this patch:

Reviewed-by: George Dunlap <george.dunlap@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[Roger Pau Monné]

<George.Dunlap@eu.citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Jan 
Beulich <jbeulich@suse.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
Stefano Stabellini <sstabellini@kernel.org>, Tim Deegan <tim@xen.org>, Wei 
Liu <wei.liu2@citrix.com>
Bcc: 
Subject: Bump library names just after branching
Reply-To: 

Hello,

Currently we bump the shared library names just before the release, so ATM 
xen-unstable is still using the library names from the 4.6 release. This is 
an issue if someone wants to install both Xen 4.6 and xen-unstable in the 
same box (unless you use a different prefix/DESTDIR), because libraries from 
xen-unstable will replace the stable ones.

IMHO, it would make more sense to bump the library names just *after* we 
branch and open the tree for development again. We could even have the 
library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so 
that we don't need to go around the different library makefiles bumping the 
versions manually.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Safa Hamza]

[-- Attachment #1.1: Type: text/plain, Size: 470 bytes --]

i solve the problem

On Thu, Mar 17, 2016 at 1:20 PM, Safa Hamza <safahamza1@gmail.com> wrote:

> i'm trying to run xen on omap5 and installing some guests ..  it seems it
> works and a xen boot dom0 as shown the screen shot
> but with this arago project i can't download any package ..all commands
> such as apt-get ,update ... are not found
> i tried to have another file system but its not working ..
> can you help me .. with which file system can i work
> thanks
>

[-- Attachment #1.2: Type: text/html, Size: 830 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Safa Hamza]

[-- Attachment #1.1: Type: text/plain, Size: 358 bytes --]

i'm trying to run xen on omap5 and installing some guests ..  it seems it
works and a xen boot dom0 as shown the screen shot
but with this arago project i can't download any package ..all commands
such as apt-get ,update ... are not found
i tried to have another file system but its not working ..
can you help me .. with which file system can i work
thanks

[-- Attachment #1.2: Type: text/html, Size: 437 bytes --]

[-- Attachment #2: dom0-boot.PNG --]
[-- Type: image/png, Size: 39281 bytes --]

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Ayushi Arora]

[-- Attachment #1.1: Type: text/plain, Size: 787 bytes --]

Hello,
As asked of in the previous mail, I tried compiling Xen from source.
I am not sure whether we can ask questions for the task given, but I have
been stuck at it from yesterday.
I followed all the steps, and wherever there was some problem, I looked up
that in wiki of Xen, but after building and installing that with ovmf
enabled in ./configure, I moved on to the network configuration, and on
rebooting after the configuration, it is showing ' ERROR: Can't find
hypervisor information in sysfs!' on xm list and brctl shows no bridge
enabled. On further checking, it showed 'ERROR: Not running inside Xen'.
I have tried finding the problem, and I will check this again but I can't
move forward until the hypervisor runs!
Not sure where to check for the error.

Thank you,

Ayushi.

[-- Attachment #1.2: Type: text/html, Size: 933 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Ian Jackson]

I'm intending to be able to do database schema updates.  But I don't
want to play around with such code on a live database.  So I need a
test database.

Thus, a yak: arrangements to make a test database.

As I say, I have tested this and it now does the right things in,
apparently, the right order, and seems to leave things in a good state
even when it collapses halfway or is ^C'd.

In v2 I have addressed the comments, and added a couple of new safety
catches.  For ease of review these are mostly as followup patches to
the mg-schema-test-database script, rather than folded in.

(no subject)

[Martin Pohlack]

Sending again without MUA-mangled patch.
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

(no subject)

[Konrad Rzeszutek Wilk]

I am proposing to put this in the 'staging-4.5' tree but would
appreciate an English speaker to take a look and make sure it
sounds good.

Thank you.

Re: (no subject)

[Ian Campbell]

On Fri, 2014-12-19 at 17:53 +0800, Minalkumar Patel wrote:
> i got daily patch emails from xen-devel but i don't need on this email
> address so how to deactivate it please tell me

Please visit http://lists.xen.org/cgi-bin/mailman/options/xen-devel

Ian.

(no subject)

[Minalkumar Patel]

[-- Attachment #1.1: Type: text/plain, Size: 117 bytes --]

i got daily patch emails from xen-devel but i don't need on this email address so how to deactivate it please tell me

[-- Attachment #1.2: Type: text/html, Size: 359 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Zir Blazer]

[-- Attachment #1.1: Type: text/plain, Size: 1027 bytes --]

>> I can't understand this as disk activity should be running on cores 0,>> 1  and 2, but never on core 3. The only thing running on core 3 should>> by my paravirtual machine and the hypervisor stub.>>>> Any idea what's going on?
Your Core i3 is a Dual Core Processor with Hyper Threading. Hyper Threading allows each Core to run two Threads simultaneously, in what is called physical Core and virtual Core (Or around those lines, but you get the idea). They share resources, and the extra Thread actually gets the free resources/execution time that weren't used by the main Thread. As Core 3 is the virtual core of the physical Core 2 (Assuming that on Linux it sees and numbers them as Physical Core 0, Logical Core 1, Physical Core 2 and Logical Core 3 and so on), you're giving that VM just a spare virtual Core with the free resources that weren't used by the physical Core. You should try with a full physical Core (Core 2 and 3), otherwise whatever runs on Core 2 WILL impact heavily what you see on Core 3. 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 1401 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Don Slutz]

On 02/13/14 11:10, Andrew Cooper wrote:
> On 13/02/14 16:01, Simon Martin wrote:
>> Hi all,
>>
>> I  am  now successfully running my little operating system inside Xen.
> Congratulations!
>
>> It  is  fully  preemptive and working a treat, but I have just noticed
>> something  I  wasn't expecting, and will really be a problem for me if
>> I can't work around it.
>>
>> My configuration is as follows:
>>
>> 1.- Hardware: Intel i3, 4GB RAM, 64GB SSD.
> Can you be more specific - this covers 4 generations of Intel CPUs.
>

I think most i3's have Intel's hyper-threading. If this is a 2 core/4 
thread chip, I would expect this kind of result. I also know that for 
the "sandy bridge" version I am using:

Intel® Xeon® E3-1260L processors (“Sandy Bridge” microarchitecture)
(2.4/2.5/3.3 GHz, 4 cores/8 threads)

How many instruction per second a thread gets does depend on the 
"idleness" of other threads (no longer just the hyperThread's parther). 
For example running my test code that does:


0x0000000000400ee0 <workerMain+432>: inc %eax
0x0000000000400ee2 <workerMain+434>: cmp $0xffffffffffffffff,%eax
0x0000000000400ee5 <workerMain+437>: jne 0x400ee0 <workerMain+432>

for almost 4GiI in this loop.

On the setup:


[root@dcs-xen-53 ~]# xl cpupool-list
Name CPUs Sched Active Domain count
Pool-0 8 credit y 9
[root@dcs-xen-53 ~]# xl vcpu-list
Name ID VCPU CPU State Time(s) CPU Affinity
Domain-0 0 0 7 r-- 1033.2 any cpu
Domain-0 0 1 3 -b- 255.9 any cpu
Domain-0 0 2 2 -b- 451.7 any cpu
Domain-0 0 3 6 -b- 231.7 any cpu
Domain-0 0 4 3 -b- 197.0 any cpu
Domain-0 0 5 0 -b- 115.1 any cpu
Domain-0 0 6 0 -b- 69.9 any cpu
Domain-0 0 7 5 -b- 214.9 any cpu
P-1-0 2 0 0 -b- 73.6 0
P-1-2 4 0 2 -b- 46.5 2
P-1-3 5 0 3 -b- 44.6 3
P-1-4 6 0 4 -b- 38.1 4
P-1-5 7 0 5 -b- 41.3 5
P-1-6 8 0 6 -b- 38.6 6
P-1-7 9 0 7 -b- 40.6 7
P-1-1 10 0 1 -b- 35.3 1

(They are HVM not PV):



xentop - 17:20:57 Xen 4.3.2-rc1
9 domains: 2 running, 7 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 33544044k total, 30265044k used, 3279000k free CPUs: 8 @ 2400MHz
NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS 
NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID
Domain-0 -----r 2629 9.4 4194304 12.5 no limit n/a 8 0 0 0 0 0 0 0 0 0 0
P-1-0 --b--- 140 6.3 3145868 9.4 3146752 9.4 1 2 61 8 0 0 0 0 0 0 0
P-1-1 --b--- 101 6.1 3145868 9.4 3146752 9.4 1 2 2 0 0 0 0 0 0 0 0
P-1-2 --b--- 113 6.3 3145868 9.4 3146752 9.4 1 2 96 10 0 0 0 0 0 0 0
P-1-3 --b--- 111 6.3 3145868 9.4 3146752 9.4 1 2 100 12 0 0 0 0 0 0 0
P-1-4 --b--- 61 2.1 3145868 9.4 3146752 9.4 1 2 8 0 0 0 0 0 0 0 0
P-1-5 --b--- 90 4.5 3145868 9.4 3146752 9.4 1 2 5 0 0 0 0 0 0 0 0
P-1-6 --b--- 162 2.7 3145868 9.4 3146752 9.4 1 2 55 20 0 0 0 0 0 0 0
P-1-7 -----r 519 100.0 3145868 9.4 3146752 9.4 1 2 46 21 0 0 0 0 0 0 0


start done
thr 0: 13 Feb 14 12:20:54.201596 13 Feb 14 12:21:22.847245
+28.645649 ~= 28.65 and 4.19 GiI/Sec

And 6&7 at the same time:

xentop - 17:21:58 Xen 4.3.2-rc1
9 domains: 3 running, 6 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 33544044k total, 30265044k used, 3279000k free CPUs: 8 @ 2400MHz
NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS 
NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID
Domain-0 -----r 2633 6.1 4194304 12.5 no limit n/a 8 0 0 0 0 0 0 0 0 0 0
P-1-0 --b--- 144 6.2 3145868 9.4 3146752 9.4 1 2 63 8 0 0 0 0 0 0 0
P-1-1 --b--- 105 6.2 3145868 9.4 3146752 9.4 1 2 2 0 0 0 0 0 0 0 0
P-1-2 --b--- 117 6.6 3145868 9.4 3146752 9.4 1 2 98 10 0 0 0 0 0 0 0
P-1-3 --b--- 115 6.5 3145868 9.4 3146752 9.4 1 2 103 12 0 0 0 0 0 0 0
P-1-4 --b--- 62 2.1 3145868 9.4 3146752 9.4 1 2 8 0 0 0 0 0 0 0 0
P-1-5 --b--- 93 4.5 3145868 9.4 3146752 9.4 1 2 5 0 0 0 0 0 0 0 0
P-1-6 -----r 168 100.0 3145868 9.4 3146752 9.4 1 2 58 20 0 0 0 0 0 0 0
P-1-7 -----r 550 100.0 3145868 9.4 3146752 9.4 1 2 49 22 0 0 0 0 0 0 0


start done
thr 0: 13 Feb 14 12:21:55.073588 13 Feb 14 12:22:50.905476
+55.831888 ~= 55.83 and 2.15 GiI/Sec

start done
thr 0: 13 Feb 14 12:21:54.847626 13 Feb 14 12:22:49.206362
+54.358736 ~= 54.36 and 2.21 GiI/Sec


(The DomU are all CentOS 5.3, which why Dom0 is spending so much time 
running QEMU.)

I would excpect the same from PV guests.

-Don Slutz
>> 2.- Xen: 4.4 (just pulled from repository)
>>
>> 3.- Dom0: Debian Wheezy (Kernel 3.2)
>>
>> 4.- 2 cpu pools:
>>
>> # xl cpupool-list
>> Name               CPUs   Sched     Active   Domain count
>> Pool-0               3    credit       y          2
>> pv499                1  arinc653       y          1
>>
>> 5.- 2 domU:
>>
>> # xl list
>> Name                                        ID   Mem VCPUs      State   Time(s)
>> Domain-0                                     0   984     3     r-----      39.7
>> win7x64                                      1  2046     3     -b----     143.0
>> pv499                                        3   128     1     -b----      61.2
>>
>> 6.- All VCPUs are pinned:
>>
>> # xl vcpu-list
>> Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
>> Domain-0                             0     0    0   -b-      27.5  0
>> Domain-0                             0     1    1   -b-       7.2  1
>> Domain-0                             0     2    2   r--       5.1  2
>> win7x64                              1     0    0   -b-      71.6  0
>> win7x64                              1     1    1   -b-      37.7  1
>> win7x64                              1     2    2   -b-      34.5  2
>> pv499                                3     0    3   -b-      62.1  3
>>
>> 7.- pv499 is the domU that I am testing. It has no disk or vif devices
>> (yet). I am running a little test program in pv499 and the timing I
>> see is varies depending on disk activity.
>>
>> My test program runs prints up the time taken in milliseconds for a
>> million cycles. With no disk activity I see 940 ms, with disk activity
>> I see 1200 ms.
>>
>> I can't understand this as disk activity should be running on cores 0,
>> 1  and 2, but never on core 3. The only thing running on core 3 should
>> by my paravirtual machine and the hypervisor stub.
>>
>> Any idea what's going on?
> Curious.  Lets try ruling some things out.
>
> How are you measuring time in pv499?
>
> What is your Cstates and Pstates looking like?  If you can, try
> disabling turbo?
>
> ~Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: (no subject)

[Andrew Cooper]

On 13/02/14 16:01, Simon Martin wrote:
> Hi all,
>
> I  am  now successfully running my little operating system inside Xen.

Congratulations!

> It  is  fully  preemptive and working a treat, but I have just noticed
> something  I  wasn't expecting, and will really be a problem for me if
> I can't work around it.
>
> My configuration is as follows:
>
> 1.- Hardware: Intel i3, 4GB RAM, 64GB SSD.

Can you be more specific - this covers 4 generations of Intel CPUs.

>
> 2.- Xen: 4.4 (just pulled from repository)
>
> 3.- Dom0: Debian Wheezy (Kernel 3.2)
>
> 4.- 2 cpu pools:
>
> # xl cpupool-list
> Name               CPUs   Sched     Active   Domain count
> Pool-0               3    credit       y          2
> pv499                1  arinc653       y          1
>
> 5.- 2 domU:
>
> # xl list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   984     3     r-----      39.7
> win7x64                                      1  2046     3     -b----     143.0
> pv499                                        3   128     1     -b----      61.2
>
> 6.- All VCPUs are pinned:
>
> # xl vcpu-list
> Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
> Domain-0                             0     0    0   -b-      27.5  0
> Domain-0                             0     1    1   -b-       7.2  1
> Domain-0                             0     2    2   r--       5.1  2
> win7x64                              1     0    0   -b-      71.6  0
> win7x64                              1     1    1   -b-      37.7  1
> win7x64                              1     2    2   -b-      34.5  2
> pv499                                3     0    3   -b-      62.1  3
>
> 7.- pv499 is the domU that I am testing. It has no disk or vif devices
> (yet). I am running a little test program in pv499 and the timing I
> see is varies depending on disk activity.
>
> My test program runs prints up the time taken in milliseconds for a
> million cycles. With no disk activity I see 940 ms, with disk activity
> I see 1200 ms.
>
> I can't understand this as disk activity should be running on cores 0,
> 1  and 2, but never on core 3. The only thing running on core 3 should
> by my paravirtual machine and the hypervisor stub.
>
> Any idea what's going on?

Curious.  Lets try ruling some things out.

How are you measuring time in pv499?

What is your Cstates and Pstates looking like?  If you can, try
disabling turbo?

~Andrew

(no subject)

[Simon Martin]

Hi all,

I  am  now successfully running my little operating system inside Xen.
It  is  fully  preemptive and working a treat, but I have just noticed
something  I  wasn't expecting, and will really be a problem for me if
I can't work around it.

My configuration is as follows:

1.- Hardware: Intel i3, 4GB RAM, 64GB SSD.

2.- Xen: 4.4 (just pulled from repository)

3.- Dom0: Debian Wheezy (Kernel 3.2)

4.- 2 cpu pools:

# xl cpupool-list
Name               CPUs   Sched     Active   Domain count
Pool-0               3    credit       y          2
pv499                1  arinc653       y          1

5.- 2 domU:

# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   984     3     r-----      39.7
win7x64                                      1  2046     3     -b----     143.0
pv499                                        3   128     1     -b----      61.2

6.- All VCPUs are pinned:

# xl vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0    0   -b-      27.5  0
Domain-0                             0     1    1   -b-       7.2  1
Domain-0                             0     2    2   r--       5.1  2
win7x64                              1     0    0   -b-      71.6  0
win7x64                              1     1    1   -b-      37.7  1
win7x64                              1     2    2   -b-      34.5  2
pv499                                3     0    3   -b-      62.1  3

7.- pv499 is the domU that I am testing. It has no disk or vif devices
(yet). I am running a little test program in pv499 and the timing I
see is varies depending on disk activity.

My test program runs prints up the time taken in milliseconds for a
million cycles. With no disk activity I see 940 ms, with disk activity
I see 1200 ms.

I can't understand this as disk activity should be running on cores 0,
1  and 2, but never on core 3. The only thing running on core 3 should
by my paravirtual machine and the hypervisor stub.

Any idea what's going on?


-- 
Best regards,
 Simon                          mailto:furryfuttock@gmail.com

(no subject)

[Konrad Rzeszutek Wilk]

This had been posted way way back:  https://lkml.org/lkml/2013/1/16/696

and the discussion about it was:
 - If there are no uses of v2, then why not rip out the support for it.
   [b/c the work for it would be in the networking code and I am still
    hoping that will be done?]
 - Why not do all of this in the toolstack. Enforce that the guest
   can only use v1 ".. if the backend isn't going to make use of them."
   (Matt).
   I am not sure how one would set up the plumbing to properly figure out
   whether the backend (say a driver domain) would communicate to hypervisor
   or XenBus that it is going to use v1 only if it has not yet started.
   (It would not have started b/c the guest hasn't started yet).

   My thinking is that once the frontend and backend start using the
   esoteric features of v2 we can rip this patch out. And also implement
   the proper code for PVHVM/PVH to actually use v2 grants.

(no subject)

[Adel Amani]

[-- Attachment #1.1: Type: text/plain, Size: 284 bytes --]

 Hello
I attach tow pic of code and error.
I try to dirty_count in function of csched_credit.c calculate... :-( But I confront to error.
now can you help me?
Thanks.

Adel Amani
M.Sc. Candidate@Computer Engineering Department, University of Isfahan
Email: A.Amani@eng.ui.ac.ir

[-- Attachment #1.2: Type: text/html, Size: 2122 bytes --]

[-- Attachment #2: pic1.png --]
[-- Type: image/png, Size: 104979 bytes --]

[-- Attachment #3: pic2.JPG --]
[-- Type: image/jpeg, Size: 11865 bytes --]

[-- Attachment #4: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[George Dunlap]

On Wed, Nov 13, 2013 at 7:02 PM, Jim Durand <jdurand@hrsg.ca> wrote:
> See log errors below, trying to live migrate VM's from Xen 3.1.2 -> Xen
> 4.2.3. Perhaps we cannot live migrate across major revs?

According to http://wiki.xen.org/wiki/Xen_Version_Compatibility :

"Xen supports migration (including live migration and save restore)
both within a stable release branch (e.g. between any versions in the
4.2.x branch) and from one major release to the next (e.g. from
release N to releaseN+1). This allows one to upgrade a pool of Xen
hosts by evacuating and upgrading the hosts one by one.

"Although it is not formally supported skipping a major release (e.g.
migration from release N to release N+2) may often work. "

Unfortunately that would mean 3.1 -> 3.2 -> 3.3 -> 3.4 -> 4.0 -> 4.1
-> 4.2... at that point shutting down the VM and starting it back up
again looks like the more attractive option.

 -George

(no subject)

[Jim Durand]

[-- Attachment #1.1: Type: text/plain, Size: 1189 bytes --]

See log errors below, trying to live migrate VM's from Xen 3.1.2 -> Xen 4.2.3. Perhaps we cannot live migrate across major revs?

[2013-11-13 11:49:00 xend 29149] DEBUG (XendCheckpoint:89) [xc_save]: /usr/lib64/xen/bin/xc_save 4 35 0 0 5
[2013-11-13 11:49:00 xend 29149] INFO (XendCheckpoint:353) Saving memory pages: iter 1   0%ERROR Internal error: Error when writing to state file (5) (errno 104)
[2013-11-13 11:49:00 xend 29149] INFO (XendCheckpoint:353) Save exit rc=1
[2013-11-13 11:49:00 xend 29149] ERROR (XendCheckpoint:133) Save failed on domain Pasiphae2 (35).
Traceback (most recent call last):
  File "/usr/lib64/python2.4/site-packages/xen/xend/XendCheckpoint.py", line 110, in save
    forkHelper(cmd, fd, saveInputHandler, False)
  File "/usr/lib64/python2.4/site-packages/xen/xend/XendCheckpoint.py", line 341, in forkHelper
    raise XendError("%s failed" % string.join(cmd))
XendError: /usr/lib64/xen/bin/xc_save 4 35 0 0 5 failed
[2013-11-13 11:49:00 xend.XendDomainInfo 29149] DEBUG (XendDomainInfo:2206) XendDomainInfo.resumeDomain(35)
[2013-11-13 11:49:00 xend 29149] DEBUG (XendCheckpoint:136) XendCheckpoint.save: resumeDomain



Thank you!
Jim

[-- Attachment #1.2: Type: text/html, Size: 3554 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[David Vrabel]

This is an RFC of Linux guest-side implementation of the FIFO-based
event channel ABI described in this design document:

http://xenbits.xen.org/people/dvrabel/event-channels-E.pdf

Refer also to the Xen series.

Remaining work:

* Add an function to set a event channel's priority and use this to
  set the VIRQ timer to the highest priority.

Patch 1 is a obvious refactoring of common code.

Patch 2-6 prepare for supporting multiple ABIs.

Patch 7 adds the low-level evtchn_ops hooks.

Patch 8-9 add an additional hook for ABI-specific per-port setup
(used for expanding the event array as more event are bound).

Patch 10 allows many more event channels to be supported by altering
how the event channel to irq map is allocated.  Note that other
factors limit the number of supported IRQs (IRQs is 8192 + 64 *
NR_CPUS).

Patch 11 is some trival refactoring.

Patch 12-13 add the ABI and the implementation.

David

Re: (no subject)

[agya naila]

[-- Attachment #1.1: Type: text/plain, Size: 643 bytes --]

Hi,

In my case I used the live migration for VoIP service. I make a simple
measurement by using wireshark,  I generate the call and then shut down one
of my virtual machine. Then using packet captured via wireshark I generate
the jitter using telephony RTP stream anaysis. If you read the report you
may see the maximum delta that correlated to the downtime in my case for my
voip service.

Best Regards,


Agya


On Wed, Aug 14, 2013 at 9:28 AM, yvxiang <linyvxiang@gmail.com> wrote:

> Hi,Agya,
>
> Now I need to measure the downtime while doing a live migration. I saw
> your mail before about this topic.  How did you measure the time?
>

[-- Attachment #1.2: Type: text/html, Size: 1207 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[yvxiang]

[-- Attachment #1.1: Type: text/plain, Size: 370 bytes --]

So sorry,I forgot the subject..


2013/8/14 yvxiang <linyvxiang@gmail.com>

> Hi,Agya,
>
> Now I need to measure the downtime while doing a live migration. I saw
> your mail before about this topic.  How did you measure the time?
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

[-- Attachment #1.2: Type: text/html, Size: 829 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[yvxiang]

[-- Attachment #1.1: Type: text/plain, Size: 147 bytes --]

Hi,Agya,

Now I need to measure the downtime while doing a live migration. I saw your
mail before about this topic.  How did you measure the time?

[-- Attachment #1.2: Type: text/html, Size: 191 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Tim Deegan]

Oops, a wandering newline seems to have got into the headers here. :)

Tim.

At 12:32 +0100 on 04 Jul (1372941166), Tim Deegan wrote:
> Bcc: Tim Deegan <tjd-xen@phlegethon.org>
> Subject: Re: [Xen-devel] [PATCH 08/10] xen: arm: add scope to dsb and dmb macros
> Reply-To: 
> In-Reply-To: <1372435856-14040-8-git-send-email-ian.campbell@citrix.com>
> 
> At 17:10 +0100 on 28 Jun (1372439454), Ian Campbell wrote:
> > Everywhere currently passes "sy"stem, so no actual change.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Tim Deegan <tim@xen.org>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

(no subject)

[Tim Deegan]

Bcc: Tim Deegan <tjd-xen@phlegethon.org>
Subject: Re: [Xen-devel] [PATCH 08/10] xen: arm: add scope to dsb and dmb macros
Reply-To: 
In-Reply-To: <1372435856-14040-8-git-send-email-ian.campbell@citrix.com>

At 17:10 +0100 on 28 Jun (1372439454), Ian Campbell wrote:
> Everywhere currently passes "sy"stem, so no actual change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

Re: (no subject)

[Ian Campbell]

On Wed, 2013-06-26 at 17:12 +0530, Divya Kapil wrote:
> How can i change migration code in xen?

I'm sorry but your question is so vague as to be unanswerable with
anything other than a snide remark like "with vi or emacs".

http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions

Ian.

(no subject)

[Divya Kapil]

How can i change migration code in xen?

(no subject)

[wei.liu2]

We would like you to answer the following questions (feel free to
write up your own report if you're a power user):

* What's the sotware setup?
  * Dom0: e.g. 64 bit CentOS 6.2
  * DomU: e.g. Debian Wheezy
  * Xen: e.g. 4.1 installed with apt-get / 4.2 compiled from tarball
  * toolstack: xl / xm / libvirt ...

* What's the hardware setup?

* What were you trying to achieve?

* What commands did you run?

* What's the expected outcome?

* What's the actual outcome?

(no subject)

[Feng Tang]

Bcc: 
Subject: Re: [PATCH 2/3] timekeeping: sync persistent clock and RTC on system time step changes
Reply-To: 

Hi David,

> From: David Vrabel <david.vrabel@citrix.com>
> Date: 2013/5/14
> Subject: Re: [PATCH 2/3] timekeeping: sync persistent clock and RTC on
> system time step changes
> To: John Stultz <john.stultz@linaro.org>
> Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Konrad
> Rzeszutek Wilk <konrad.wilk@oracle.com>, Thomas Gleixner
> <tglx@linutronix.de>, "linux-kernel@vger.kernel.org"
> <linux-kernel@vger.kernel.org>
> 
> 
> On 14/05/13 01:40, John Stultz wrote:
> > On 05/13/2013 10:56 AM, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> The persistent clock or the RTC is only synchronized with system time
> >> every 11 minutes if NTP is running.  This gives a window where the
> >> persistent clock may be incorrect after a step change in the time
> >> (such as on first boot).
> >>
> >> This particularly affects Xen guests as until an update to the control
> >> domain's persistent clock, new guests will start with the incorrect
> >> system time.
> >>
> >> When there is a step change in the system time, call
> >> update_persistent_clock or rtc_set_ntp_time() to synchronize the
> >> persistent clock or RTC to the new system time.
> >
> > I'm sorry, this isn't quite making sense to me. Could you further
> > describe the exact problematic behavior you're seeing here, and why its
> > a problem?
> 
> The Xen wallclock is used as the persistent clock for Xen guests.  This
> is initialized (by Xen) with the CMOS RTC at the start of day.  If the
> RTC is incorrect then guests will see an incorrect wallclock time until
> dom0 has corrected it.
> 
> Currently dom0 only updates the Xen wallclock with the 11 min periodic
> work when NTP is synced.  This leaves a window where newly started
> guests will see an incorrect wallclock time.  This can cause guests to
> fail to start correctly if the wallclock is now behind what it was when
> the guest last started. (e.g., fsck of its disk fails as its last mount
> time appears to be far into the future).

Is it possible for Xen to resync its wallclock time from the RTC device
whenever it gets a request of starting a new guest? as usually a new
guest OS needs to get the time base from Xen's wallclock anyway.

Thanks,
Feng

(no subject)

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 1926 bytes --]

> Subject: Looking for volunteer to help man LinuxCon Japan booth (1-2 hours
> a day)
>
> Dear Community member,
>
> the Xen Project was planning to have a booth at LinuxCon Japan this year
> (for more information, see
> http://events.linuxfoundation.org/events/linuxcon-japan/<https://mail.citrix.com/owa/redir.aspx?C=dnbPGSChGEWoACoWH_QLpH7EveZxG9BIE6cabrXu0jA-wgQqxbnVAgQREizU60s78z6uEa6Tkac.&URL=http%3a%2f%2fevents.linuxfoundation.org%2fevents%2flinuxcon-japan%2f>).
We are
> looking for one or two users (or developers of Xen) to help out a couple
> of hours a day on the Xen Project booth. I am looking for people who know
> Xen, XAPI or XCP, speak Japanese and want to spend an hour or two a day
> on the booth with me and a few other community members. If this is you,
> please get in touch!
>
> I will be able to get you a free conference pass for LinuxCon. If this is
> you and you would like to attend LinuxCon, but cannot afford it, we do
have
> a number of travel stipends available. In that case, please also send me
> an e-mail.
>
> Best Regards
> Lars


-----

みなさま、こんにちは

The Xen Community ManagerのLars Kurthです。



The Xen Projectコミュニティでは、5/29 - 31 椿山荘で開催されるLinuxCon Japan / CloudOpen Japan
にて展示ブースを出す予定です。

https://events.linuxfoundation.jp/events/linuxcon-japan

https://events.linuxfoundation.jp/events/cloudopen-japan



そこで展示ブーススタッフを募集しています。OSS Xenの開発者、ユーザー、

その他関連各位で、半日でも、１日でもお時間が取れる方がいらっしゃれば

ご連絡いただければと思います。



もちろん、ブーススタッフとして協力いただける方には、

LinuxCon Japan / CloudOpen Japan のFree Passチケットをお渡しします。



よろしくお願いいたします。



連絡先

Lars Kurth lars.kurth@citrix.com  (英語)
Kimihiko Kitase Kimihiko.Kitase@citrix.co.jp (日本語)

[-- Attachment #1.2: Type: text/html, Size: 8578 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Tim Deegan]

Hi,

At 17:56 -0400 on 22 Apr (1366653364), Cutter 409 wrote:
> I'm finally to a point where I can start looking at this more closely. I'm
> trying to wrap my head around the shadow code to figure out the right
> course of action.
> 
> I'd want HVMOP_set_mem_access to work with both shadow and EPT, so I'd want
> things to work via p2m somehow. I think I understand this part.
> 
> * HVMOP_set_mem_access is used to change the p2m_access_t for the target
> page(s). This should already be implemented I think?

Yep.  The shadow code uses the same p2m implementataion as NPT, so that
should all be fine. 

> * During propagation, I'll check the p2m map to see if I should mask off
> any permission bits.

Yep.  You'll already be doing a p2m lookup to get the MFN, so you just
need to look at the p2ma as well. 

> * On a shadow paging fault, I'll check if the fault was caused by p2m
> permissions, somehow integrating that with the code for read-only guest
> page tables safely.

Yes.  The common case will be handled in _sh_propagate, which is where
the shadow PTE is constructed.  For the rest you'll need to look at the
places where the shadow fault handler calls the emulator and DTRT
(either before the call or in the callbacks that the emulator uses to
access guest memory).

> Questions:
> 
> * Just for background, am I correct in my understanding that the log_dirty
> code is used to track which gfns have been written to by the guest, in
> order to speed up migration?

That's right.  It's also used to track which parts of an emulated
framebuffer have been updated, to make VNC connections more efficient.

> * Are multiple shadow tables maintained per domain? Is there one per VCPU?
> One shadow table per guest page table? Is it blown away every time the
> guest changes CR3? I'm having some trouble tracking this down.

There's one set of shadows per domain, shared among all VCPUs.  A given
page of memory may have multiple shadows though, e.g. if it's seen both
as a top-level pagetables and a leaf pagetable. 

Shadows are kept around until:
 - it looks like the page is no longer a pagetable;
 - the guest explicitly tells us it's no longer a pagetable; or
 - we need the memory to shadow some other page. 

Mostly, a pages's shadow(s) are kept in sync with any changes the guest
makes to the page, by trapping and emulating all writes.  For
performance, we allow some l1 pagetables to be 'out of sync' ('oos' in
the code), letting the guest write to the page directly.  On guest CR3
writes (and other TLB-flush-related activity) we make sure any OOS
shadows are brought up to date. 

> * How should I clear/update existing shadow entries after changing the
> p2m_access_t? Can I clear the shadow tables somehow and force everything to
> be repopulated? Is that insane?

It depends how often you're changing the access permissions.
sh_remove_all_mappings() and sh_remove_write_access() will try to flush
mappings of a single MFN from the shadows, but they can be expensive
(e.g. involving a brute-force scan of all shadows) so if you're going to
do a lot of them it may be worth considering batching them up and
calling shadow_blow_tables() once instead.

Cheers,

Tim.

Re: (no subject)

[Cutter 409]

[-- Attachment #1.1: Type: text/plain, Size: 3206 bytes --]

Hi,

I'm finally to a point where I can start looking at this more closely. I'm
trying to wrap my head around the shadow code to figure out the right
course of action.

I'd want HVMOP_set_mem_access to work with both shadow and EPT, so I'd want
things to work via p2m somehow. I think I understand this part.

* HVMOP_set_mem_access is used to change the p2m_access_t for the target
page(s). This should already be implemented I think?
* During propagation, I'll check the p2m map to see if I should mask off
any permission bits.
* On a shadow paging fault, I'll check if the fault was caused by p2m
permissions, somehow integrating that with the code for read-only guest
page tables safely.

Questions:

* Just for background, am I correct in my understanding that the log_dirty
code is used to track which gfns have been written to by the guest, in
order to speed up migration?
* Are multiple shadow tables maintained per domain? Is there one per VCPU?
One shadow table per guest page table? Is it blown away every time the
guest changes CR3? I'm having some trouble tracking this down.
* How should I clear/update existing shadow entries after changing the
p2m_access_t? Can I clear the shadow tables somehow and force everything to
be repopulated? Is that insane?

Thanks!



On Thu, Nov 15, 2012 at 7:08 AM, Tim Deegan <tim@xen.org> wrote:

> Bcc: Tim Deegan <tjd-xen@phlegethon.org>
> Subject: Re: [Xen-devel] Guest memory access hooking
> Reply-To:
> In-Reply-To: <
> CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com>
>
> Hi,
>
> At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> > I'm trying to do some research with malware, and I'm trying to get
> > notifications on arbitrary guest page accesses (similar to what Ether
> > does.) I've noticed the mem-event API and it seems like it might be close
> > to what I need, but I can't find much documentation about how it works or
> > how to use it.
>
> Yes, the mem-event api, and in particular the HVMOP_set_mem_access
> hypercall, looks like what you want.  As you say, there isn't much
> documentation for it, except the xen-access.c client and the mailing
> list archive.
>
> CC'ing Aravindh, who has worked on this code most recently and might be
> able to help with specific questions.
>
> > I know that that mem-event API works only with EPT, but is the code to
> > change permissions modifying the guest page tables, or does it work via
> > EPT? (Can the guest detect it?)
>
> It works by EPT.  The guest can't detect it by looking at its pagetables
> or page fault patterns, though it might be able to detect it by looking
> at timings.
>
> > I'm also interested monitoring arbitrary page access via the shadow page
> > tables. I've been reading through the code, but if anyone has any insight
> > or some kind of push in the right direction, I'd really appreciate it.
>
> Your best bet is to modify _sh_propagate.  Look at how it handles
> shadow_mode_log_dirty() -- any time a writeable mapping is shadowed, the
> shadow PTE is made read-only until the guest is actually doing a write,
> then mark_dirty can be called.  You should be able to do the same thing
> for other kinds of access.
>
> Cheers,
>
> Tim.
>

[-- Attachment #1.2: Type: text/html, Size: 4078 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Lonnie Cumberland]

[-- Attachment #1.1: Type: text/plain, Size: 1457 bytes --]

Greetings All,

I am very new to Xen but have spent a considerable amount of time
researching various emulators and simulators like QEMU, Virtualbox, Bochs,
etc.... to find out which may be good for a project that I am interested in
moving towards related to the x86_64 platform.

It seems that XEN may be the best solution as I need something that can be
billed as a Type I and also Type II emulator. Xen and HXen meet these goals.

Now I am entering the learning curve to get a feel for the source code but
had a question related to the layout of Xen.

I am trying to understand where the main init functions are in Xen as for
example in QEMU they are in the v1.c file and as to where the mian loops
are for the hypervisor are to loop through the vCPU's.

I am also trying to get a feel for where the memory allocation functions
are in Xen.

Also, in the Xen 4.2.1 distro, is qemu called for each HPV.

Please forgive these questions if they should be obvious to me, but I would
like to get a good feel for the booting sequence and control loops that Xen
has to utilize.

I have read a number of documents on the website that give me briev
overview of how Xen operates with  Dom0 and DomU guests but now it is time
for me to get a feel for the sources so that I might be able to learn and
contribute to the effort of a very wonderful hypervisor.

Any guidance or help would be greatly appreciated.

Kind Regards and have a great day,
Lonnie T. Cumberland

[-- Attachment #1.2: Type: text/html, Size: 1866 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[jacek burghardt]

[-- Attachment #1.1: Type: text/plain, Size: 250 bytes --]

Does xcp supports assignment of USB or xen-api ? I know that spice allows
for USB redirection. Also remote desktop supports redirection of devices. I
like using android devices with xen hosted servers as remote desktop
exports my SD cards to server.

[-- Attachment #1.2: Type: text/html, Size: 258 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Mina Jafari]

[-- Attachment #1.1: Type: text/plain, Size: 3275 bytes --]

I can't install any guest vm,(I'm trying this on Fedora13 and kernel
3.2.7,compiled as dom0 and xen 4.1.2)
virt-manager connect to xen but when trying to create a new guest it
fails with this error:

Unable to complete install: 'POST operation failed: xend_post: error
from xen daemon: (xend.err 'Device 0 (vif) could not be connected.
Hotplug scripts not working.')'
operation failed: xend_post: error from xen daemon: (xend.err 'Device
0 (vif) could not be connected. Hotplug scripts not working.')
Traceback (most recent call last):
  File "/usr/share/virt-manager/
virtManager/create.py", line 1567, in
do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line
1023, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line
1088, in _do_install
    "install")
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line
1059, in _create_guest
    dom = self.conn.createLinux(start_xml, 0)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1277, in
createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed',
conn=self)
libvirtError: POST operation failed: xend_post: error from xen daemon:
(xend.err 'Device 0 (vif) could not be connected. Hotplug scripts not
working.')

and the same problem when creating by commandline.

I'v set up a bridge:
brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0024e8e7bd75       no              eth0
virbr0          8000.000000000000       yes


ifcfg-br0  file :
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
NM_CONTROLLED=yes



ifconfig
br0       Link encap:Ethernet  HWaddr 00:24:E8:E7:BD:75
          inet6 addr: fe80::224:e8ff:fee7:bd75/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:554 (554.0 b)

eth0      Link encap:Ethernet  HWaddr 00:24:E8:E7:BD:75
          UP BROADCAST MULTICAST  MTU:9000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:36 Base address:0x8000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:131950 errors:0 dropped:0 overruns:0 frame:0
          TX packets:131950 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:15243838 (14.5 MiB)  TX bytes:15243838 (14.5 MiB)

virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          inet addr:#.#.#.#  Bcast:#.#.#.#  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

[-- Attachment #1.2: Type: text/html, Size: 3829 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Pasi Kärkkäinen]

On Fri, Mar 15, 2013 at 01:10:02PM +0530, digvijay chauhan wrote:
>    Hello,
>                I am trying to install xen4.2 but when ifire make tools
>    command it gives me,
> 
>    Cloning into 'seabios-dir-remote.tmp'...
>    fatal: unable to connect to [1]xenbits.xen.org:
>    [2]xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out
> 

So maybe your firewall is blocking the connection? 

-- Pasi

>    make[3]: *** [seabios-dir] Error 128
>    make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/
>    firmware'
>    make[2]: *** [subdir-install-firmware] Error 2
>    make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
>    make[1]: *** [subdirs-install] Error 2
>    make[1]: Leaving directory `/home/ce/xen-4.2.0/tools'
>    make: *** [install-tools] Error 2
> 
>    so how can i overcome it.
> 
>    regards,
>    DigvijaySingh
> 
> References
> 
>    Visible links
>    1. http://xenbits.xen.org/
>    2. http://xenbits.xen.org/

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: (no subject)

[Ian Campbell]

Digvijay,

You have cross posted this message to multiple lists I have already
asked you not to do this on at least one occasion.

You have also CCd various people, including myself, seemingly at random,
*and* posted the same message three times in quick succession.

Please stop this antisocial behaviour.

Post to a single list (xen-users@ in the common case for the sorts of
questions you are asking) and wait a reasonable amount of time (i.e.
measured in days) for a response before pinging.

Ian.

(no subject)

[digvijay chauhan]

[-- Attachment #1.1: Type: text/plain, Size: 627 bytes --]

Hello,
            I am trying to install xen4.2 but when ifire make tools command
it gives me,

Cloning into 'seabios-dir-remote.tmp'...
fatal: unable to connect to xenbits.xen.org:
xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out

make[3]: *** [seabios-dir] Error 128
make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/
firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/ce/xen-4.2.0/tools'
make: *** [install-tools] Error 2


so how can i overcome it.

regards,
DigvijaySingh

[-- Attachment #1.2: Type: text/html, Size: 842 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Rushikesh Jadhav]

[-- Attachment #1.1: Type: text/plain, Size: 331 bytes --]

Hello List,

Please help me in diagnosing below error in /var/log/messages

HVM1[16586]:  txftrans.c:4498 -- TXF_HARD_ERROR (0xC01A002B) for RM:
fffff8800d099000

Im unable to find any google reference related to above C file or its
source code. http://lmgtfy.com/?q=txftrans.c

Thanks for reading and helping.

Regards,
Rushikesh

[-- Attachment #1.2: Type: text/html, Size: 484 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Aravindh Puthiyaparambil]

On Thu, Nov 15, 2012 at 4:08 AM, Tim Deegan <tim@xen.org> wrote:
>
> Bcc: Tim Deegan <tjd-xen@phlegethon.org>
> Subject: Re: [Xen-devel] Guest memory access hooking
> Reply-To:
> In-Reply-To: <CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com>
>
> Hi,
>
> At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> > I'm trying to do some research with malware, and I'm trying to get
> > notifications on arbitrary guest page accesses (similar to what Ether
> > does.) I've noticed the mem-event API and it seems like it might be close
> > to what I need, but I can't find much documentation about how it works or
> > how to use it.
>
> Yes, the mem-event api, and in particular the HVMOP_set_mem_access
> hypercall, looks like what you want.  As you say, there isn't much
> documentation for it, except the xen-access.c client and the mailing
> list archive.
>
> CC'ing Aravindh, who has worked on this code most recently and might be
> able to help with specific questions.

Sure, I can help with the specifics of the API usage.

> > I know that that mem-event API works only with EPT, but is the code to
> > change permissions modifying the guest page tables, or does it work via
> > EPT? (Can the guest detect it?)
>
> It works by EPT.  The guest can't detect it by looking at its pagetables
> or page fault patterns, though it might be able to detect it by looking
> at timings.
>
> > I'm also interested monitoring arbitrary page access via the shadow page
> > tables. I've been reading through the code, but if anyone has any insight
> > or some kind of push in the right direction, I'd really appreciate it.

It might be useful to get mem-event working with shadow by following
Tim's suggestions to achieve what you are after.

Thanks,
Aravindh

(no subject)

[Tim Deegan]

Bcc: Tim Deegan <tjd-xen@phlegethon.org>
Subject: Re: [Xen-devel] Guest memory access hooking
Reply-To: 
In-Reply-To: <CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com>

Hi,

At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> I'm trying to do some research with malware, and I'm trying to get
> notifications on arbitrary guest page accesses (similar to what Ether
> does.) I've noticed the mem-event API and it seems like it might be close
> to what I need, but I can't find much documentation about how it works or
> how to use it.

Yes, the mem-event api, and in particular the HVMOP_set_mem_access
hypercall, looks like what you want.  As you say, there isn't much
documentation for it, except the xen-access.c client and the mailing
list archive. 

CC'ing Aravindh, who has worked on this code most recently and might be
able to help with specific questions.

> I know that that mem-event API works only with EPT, but is the code to
> change permissions modifying the guest page tables, or does it work via
> EPT? (Can the guest detect it?)

It works by EPT.  The guest can't detect it by looking at its pagetables
or page fault patterns, though it might be able to detect it by looking
at timings.

> I'm also interested monitoring arbitrary page access via the shadow page
> tables. I've been reading through the code, but if anyone has any insight
> or some kind of push in the right direction, I'd really appreciate it.

Your best bet is to modify _sh_propagate.  Look at how it handles
shadow_mode_log_dirty() -- any time a writeable mapping is shadowed, the
shadow PTE is made read-only until the guest is actually doing a write,
then mark_dirty can be called.  You should be able to do the same thing
for other kinds of access.

Cheers,

Tim.

(no subject)

[lmw]

What is the easiest way to determine the Dom Id of a unmodified Xen HVM guest from within a daemon process running in the guest?

Re: (no subject)

[Tim Deegan]

At 04:16 +0000 on 14 Jul (1342239382), ???? wrote:
> 
> Hi, list,
> Where can I find the "tools/tests/mem-sharing/memshrtool.c" ?I didn't find it in the latest version of xen-4.1.2. Thanks.

You'll find it in the xen-unstable tree.  In general the memory-sharing
code in 4.1.x is not stable enough to use. 

Cheers,

Tim.

(no subject)

[张智]

[-- Attachment #1.1: Type: text/plain, Size: 168 bytes --]


Hi, list,
Where can I find the "tools/tests/mem-sharing/memshrtool.c" ?I didn't find it in the latest version of xen-4.1.2. Thanks.
All the very best,Henry 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 844 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Lin Ming]

Hi all,

These 2 patches try to fix the "perf top" soft lockups under Xen
reported by Steven at: https://lkml.org/lkml/2012/2/9/506

I tested it with 3.4-rc2 and "perf top" works well now.

Steven,
Could you please help to test it too?

The soft lockup code path is:

__irq_work_queue
  arch_irq_work_raise
    apic->send_IPI_self(IRQ_WORK_VECTOR);
      apic_send_IPI_self
        __default_send_IPI_shortcut
          __xapic_wait_icr_idle

static inline void __xapic_wait_icr_idle(void)
{
        while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
                cpu_relax();
}

The lockup happens at above while looop.
                                                                
The cause is that Xen has not implemented the APIC IPI interface yet.
Xen has IPI interface: xen_send_IPI_one, but it's only used in
xen_smp_send_reschedule, xen_smp_send_call_function_ipi and
xen_smp_send_call_function_single_ipi, etc.

So we need to implement Xen's APIC IPI interface as Ben's patch does.
And implement Xen's IRQ_WORK_VECTOR handler.

Ben Guthro (1):
      xen: implement apic ipi interface

Lin Ming (1):
      xen: implement IRQ_WORK_VECTOR handler

 arch/x86/include/asm/xen/events.h |    1 +
 arch/x86/xen/enlighten.c          |    7 ++
 arch/x86/xen/smp.c                |  111 +++++++++++++++++++++++++++++++++++-
 arch/x86/xen/smp.h                |   12 ++++
 4 files changed, 127 insertions(+), 4 deletions(-)

Any comment is appreciated.
Lin Ming

Re: (no subject)

[Francisco Rocha]

________________________________________
From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com]
Sent: 06 April 2012 16:14
To: Wei Huang
Cc: Francisco Rocha; Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On Fri, Apr 06, 2012 at 09:51:52AM -0500, Wei Huang wrote:
> Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
> xsave/xrstor.

Hm .

.. snip..
> >kernel /boot/xen.gz blah blah xsave=0
> >module blah blah
> >blah
> >
> >Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
> >
> >Thank you for the help.
> >
> >Francisco
> >
> >-Wei
> >
> >>Anyway, shouldn't Xen support it?
> >>
> >>cheers,
> >>Francisco
> >The xsave=0 command line parameter solves the problem.

Francisco,

What version of Xen do you have? Xen 4.1? What is the motherboard/CPU combination.

I downloaded the latest version from xen-unstable.hg yesterday.

My machine is a Toshiba laptop R840-12F. Here is some info:

# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
stepping	: 7
microcode	: 0x25
cpu MHz		: 800.000
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 5382.80
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

BIOS: TOSHIBA
Version: Version 3.60  
Release Date: 01/24/2012

Re: (no subject)

[Konrad Rzeszutek Wilk]

On Fri, Apr 06, 2012 at 09:51:52AM -0500, Wei Huang wrote:
> Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
> xsave/xrstor.

Hm .

.. snip..
> >kernel /boot/xen.gz blah blah xsave=0
> >module blah blah
> >blah
> >
> >Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
> >
> >Thank you for the help.
> >
> >Francisco
> >
> >-Wei
> >
> >>Anyway, shouldn't Xen support it?
> >>
> >>cheers,
> >>Francisco
> >The xsave=0 command line parameter solves the problem.

Francisco,

What version of Xen do you have? Xen 4.1? What is the motherboard/CPU combination.

Re: (no subject)

[Francisco Rocha]

________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 06 April 2012 15:51
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
xsave/xrstor.

-Wei

I didn't change the kernel, it's a fresh install.
I tried the latest for Fedora 16 and Xubuntu 11.10 both 
rebooted the machine.

Cheers,
Francisco

On 04/06/2012 09:53 AM, Francisco Rocha wrote:
> ________________________________________
> From: Francisco Rocha
> Sent: 05 April 2012 21:43
> To: wei.huang2@amd.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] (no subject)
>
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 21:27
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 03:17 PM, Francisco Rocha wrote:
>> ________________________________________
>> From: Wei Huang [wei.huang2@amd.com]
>> Sent: 05 April 2012 20:36
>> To: Francisco Rocha
>> Cc: Andrew Cooper; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] (no subject)
>>
>> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>>> To:<xen-devel@lists.xen.org>
>>> Subject: Re: [Xen-devel] lastest xen unstable crash
>>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>
>>> On 05/04/12 18:37, Francisco Rocha wrote:
>>>> Hi everyone,
>>>>
>>>> I was trying to build a new machine but the system keeps rebooting.
>>>> I used the lasted unstable version from xen-unstable.hg.
>>>>
>>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>>
>>>> The output to my serial console is attached.
>>>>
>>>> Cheers,
>>>> Francisco
>>> What is your Linux command line? does it include "console=hvc0"?
>>> Perhaps some early_printk settings are required.
>>>
>>> Please include my email in your replies, thank you.
>>>
>>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>>
>>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>>> root         (hd0,0)
>>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>>> module       /initrd-2.6.31.6.img
>>>
>>> Something like this, I am not at the machine anymore.
>>>
>>> Francisco
>>>
>> It looks like xsave/xrstore instructions (xsetbv instruction in
>> xstate_enable() function to be exact) related. You can try to disable
>> xsave to to see if this helps.
>>
>> -Wei
>>
>> Sorry about the untitled message.
>>
>> Should I be the one disabling xsave or is that for Andrew to change something?
>> How can I do that?
> Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
> should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
> line of grub entry and boot again. Something like this:
>
> kernel /boot/xen.gz blah blah xsave=0
> module blah blah
> blah
>
> Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
>
> Thank you for the help.
>
> Francisco
>
> -Wei
>
>> Anyway, shouldn't Xen support it?
>>
>> cheers,
>> Francisco
> The xsave=0 command line parameter solves the problem.
>
> Thank you,
> Francisco
>

Re: (no subject)

[Francisco Rocha]

________________________________________
From: Francisco Rocha
Sent: 05 April 2012 21:43
To: wei.huang2@amd.com
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: RE: [Xen-devel] (no subject)

________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 21:27
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.

Thank you for the help.

Francisco

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco

The xsave=0 command line parameter solves the problem.

Thank you,
Francisco

Re: (no subject)

[Wei Huang]

Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with 
xsave/xrstor.

-Wei

On 04/06/2012 09:53 AM, Francisco Rocha wrote:
> ________________________________________
> From: Francisco Rocha
> Sent: 05 April 2012 21:43
> To: wei.huang2@amd.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] (no subject)
>
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 21:27
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 03:17 PM, Francisco Rocha wrote:
>> ________________________________________
>> From: Wei Huang [wei.huang2@amd.com]
>> Sent: 05 April 2012 20:36
>> To: Francisco Rocha
>> Cc: Andrew Cooper; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] (no subject)
>>
>> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>>> To:<xen-devel@lists.xen.org>
>>> Subject: Re: [Xen-devel] lastest xen unstable crash
>>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>
>>> On 05/04/12 18:37, Francisco Rocha wrote:
>>>> Hi everyone,
>>>>
>>>> I was trying to build a new machine but the system keeps rebooting.
>>>> I used the lasted unstable version from xen-unstable.hg.
>>>>
>>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>>
>>>> The output to my serial console is attached.
>>>>
>>>> Cheers,
>>>> Francisco
>>> What is your Linux command line? does it include "console=hvc0"?
>>> Perhaps some early_printk settings are required.
>>>
>>> Please include my email in your replies, thank you.
>>>
>>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>>
>>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>>> root         (hd0,0)
>>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>>> module       /initrd-2.6.31.6.img
>>>
>>> Something like this, I am not at the machine anymore.
>>>
>>> Francisco
>>>
>> It looks like xsave/xrstore instructions (xsetbv instruction in
>> xstate_enable() function to be exact) related. You can try to disable
>> xsave to to see if this helps.
>>
>> -Wei
>>
>> Sorry about the untitled message.
>>
>> Should I be the one disabling xsave or is that for Andrew to change something?
>> How can I do that?
> Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
> should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
> line of grub entry and boot again. Something like this:
>
> kernel /boot/xen.gz blah blah xsave=0
> module blah blah
> blah
>
> Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
>
> Thank you for the help.
>
> Francisco
>
> -Wei
>
>> Anyway, shouldn't Xen support it?
>>
>> cheers,
>> Francisco
> The xsave=0 command line parameter solves the problem.
>
> Thank you,
> Francisco
>

Re: (no subject)

[Francisco Rocha]

________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 21:27
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.

Thank you for the help.

Francisco

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco

Re: (no subject)

[Wei Huang]

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which 
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz 
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco

Re: (no subject)

[Francisco Rocha]

________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 20:36
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 01:26 PM, Francisco Rocha wrote:
> Date: Thu, 5 Apr 2012 18:44:14 +0100
> From: Andrew Cooper<andrew.cooper3@citrix.com>
> To:<xen-devel@lists.xen.org>
> Subject: Re: [Xen-devel] lastest xen unstable crash
> Message-ID:<4F7DD9EE.3080404@citrix.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 05/04/12 18:37, Francisco Rocha wrote:
>> Hi everyone,
>>
>> I was trying to build a new machine but the system keeps rebooting.
>> I used the lasted unstable version from xen-unstable.hg.
>>
>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>
>> The output to my serial console is attached.
>>
>> Cheers,
>> Francisco
> What is your Linux command line? does it include "console=hvc0"?
> Perhaps some early_printk settings are required.
>
> Please include my email in your replies, thank you.
>
> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>
> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
> root         (hd0,0)
> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
> module       /initrd-2.6.31.6.img
>
> Something like this, I am not at the machine anymore.
>
> Francisco
>
It looks like xsave/xrstore instructions (xsetbv instruction in
xstate_enable() function to be exact) related. You can try to disable
xsave to to see if this helps.

-Wei

Sorry about the untitled message. 

Should I be the one disabling xsave or is that for Andrew to change something?
How can I do that?

Anyway, shouldn't Xen support it?

cheers,
Francisco

Re: (no subject)

[Wei Huang]

On 04/05/2012 01:26 PM, Francisco Rocha wrote:
> Date: Thu, 5 Apr 2012 18:44:14 +0100
> From: Andrew Cooper<andrew.cooper3@citrix.com>
> To:<xen-devel@lists.xen.org>
> Subject: Re: [Xen-devel] lastest xen unstable crash
> Message-ID:<4F7DD9EE.3080404@citrix.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 05/04/12 18:37, Francisco Rocha wrote:
>> Hi everyone,
>>
>> I was trying to build a new machine but the system keeps rebooting.
>> I used the lasted unstable version from xen-unstable.hg.
>>
>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>
>> The output to my serial console is attached.
>>
>> Cheers,
>> Francisco
> What is your Linux command line? does it include "console=hvc0"?
> Perhaps some early_printk settings are required.
>
> Please include my email in your replies, thank you.
>
> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>
> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
> root         (hd0,0)
> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
> module       /initrd-2.6.31.6.img
>
> Something like this, I am not at the machine anymore.
>
> Francisco
>
It looks like xsave/xrstore instructions (xsetbv instruction in 
xstate_enable() function to be exact) related. You can try to disable 
xsave to to see if this helps.

-Wei

(no subject)

[Francisco Rocha]

Date: Thu, 5 Apr 2012 18:44:14 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
Message-ID: <4F7DD9EE.3080404@citrix.com>
Content-Type: text/plain; charset="ISO-8859-1"

On 05/04/12 18:37, Francisco Rocha wrote:
> Hi everyone,
>
> I was trying to build a new machine but the system keeps rebooting.
> I used the lasted unstable version from xen-unstable.hg.
>
> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>
> The output to my serial console is attached.
>
> Cheers,
> Francisco

What is your Linux command line? does it include "console=hvc0"? 
Perhaps some early_printk settings are required.

Please include my email in your replies, thank you.

Yes, it includes hvc0. I used your tutorial to setup the SOL.

title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
root         (hd0,0)
kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
module       /initrd-2.6.31.6.img

Something like this, I am not at the machine anymore.

Francisco

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

(no subject)

[Ian Jackson]

Once again, I have not executed the code in this series!

These three are intended to be bugfixes to sort out
the deadlock problem that Roger Pau Monne reported:
 01/15 libxl: ao: allow immediate completion
 02/15 libxl: fix hang due to libxl__initiate_device_remove

These are other bugfixes:
 03/15 libxl: Fix eventloop_iteration over-locking
 04/15 libxl: Fix leak of ctx->lock
 05/15 libxl: abolish libxl_ctx_postfork
 06/15 tools: Correct PTHREAD options in config/StdGNU.mk
 07/15 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
 08/15 libxl: Crash (more sensibly) on malloc failure

These are handy new bits for internal libxl users:
 09/15 libxl: Make libxl__zalloc et al tolerate a NULL gc
 10/15 libxl: Introduce some convenience macros
 11/15 libxl: Protect fds with CLOEXEC even with forking threads
 12/15 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
 14/15 libxl: Provide libxl_string_list_length
 15/15 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds

This is the new child-handling machinery:
 13/15 libxl: event API: new facilities for waiting for subprocesses

There are not any users for much of this code in this series.  I have
a half-written rework of libxl_bootloader.c to make it event-driven,
but it's not suitable for review at this stage.  It doesn't even
compile.

(no subject)

[Ian Jackson]

>From Ian Jackson <ian.jackson@eu.citrix.com> # This line is ignored.
From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [RFC PATCH 0/6] libxl: New child process handling
In-Reply-To: 

This is the first draft of my new libxl API for child process
handling.

 1/6 libxl: Fix leak of ctx->lock
 2/6 libxl: abolish libxl_ctx_postfork
 3/6 tools: Correct PTHREAD options in config/StdGNU.mk
 4/6 libxl: Protect fds with CLOEXEC even with forking threads
 5/6 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
 6/6 libxl: event API: new facilities for waiting for subprocesses

Please comment.  I'm particularly keen on comments about:

 * The correctness of the pthread_atfork logic in 4/6.
 * The sufficiency for applications of the child handling API in 6/6.
 * The portability of the pthread command line option changes in 3/6.
 * Correctness :-).

If you want to apply it to make sense of, you'll need to know that
this series is on top of my recently-posted 3-patch libxl event fixup
series.

Thanks,
Ian.

Re: (no subject)

[Paolo Bonzini]

On 10/17/2011 07:05 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 17, 2011 at 09:40:49AM +0200, Paolo Bonzini wrote:
>
> Something went wrong with your patchbomb..
>
> anyhow, lets CC Ian here since he is the maintainer.

Already resent, and acked by Jan. :)

Paolo

Re: (no subject)

[Ian Campbell]

On Mon, 2011-10-17 at 18:05 +0100, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 17, 2011 at 09:40:49AM +0200, Paolo Bonzini wrote:
> 
> Something went wrong with your patchbomb..
> 
> anyhow, lets CC Ian here since he is the maintainer.

This is a 2.6.18-xen patch. I'm not especially interested in that tree
-- Jan looks after it though and picked up this patch from the resend.

Ian.

> 
> > 
> > Writing [PATCH] netback: disable features not supported by netfront ...
> > ntent-Transfer-Encoding: 7bit
> > Subject: [PATCH] netback: disable features not supported by netfront
> > X-Mercurial-Node: eb896361fc70b60b9a257d0c82e19633a11b9d41
> > Message-Id: <eb896361fc70b60b9a25.1318837062@yakj.usersys.redhat.com>
> > User-Agent: Mercurial-patchbomb/1.9.1
> > Date: Mon, 17 Oct 2011 09:37:42 +0200
> > From: pbonzini@redhat.com
> > To: pbonzini@redhat.com
> > 
> > # HG changeset patch
> > # User Paolo Bonzini <pbonzini@redhat.com>
> > # Date 1318837036 -7200
> > # Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41
> > # Parent  3c900d6a5f6a51ff1547f21fef30ab8b92feccc9
> > netback: disable features not supported by netfront
> > 
> > Netback works by first setting all possible features, and then
> > resetting some after connection, if the front-end didn't negotiate them.
> > Except that in the old 2.6.18 tree the "resetting" part was missing.
> > In the pvops tree, this should work correctly through the fix_features
> > mechanism.
> > 
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > 
> > diff --git a/drivers/xen/netback/interface.c b/drivers/xen/netback/interface.c
> > --- a/drivers/xen/netback/interface.c
> > +++ b/drivers/xen/netback/interface.c
> > @@ -98,8 +98,9 @@ static int netbk_change_mtu(struct net_d
> >  void netif_set_features(netif_t *netif)
> >  {
> >  	struct net_device *dev = netif->dev;
> > -	int features = dev->features;
> > +	int features;
> >  
> > +	features = dev->features & ~(NETIF_F_SG|NETIF_F_TSO|NETIF_F_IP_CSUM);
> >  	if (netif->can_sg)
> >  		features |= NETIF_F_SG;
> >  	if (netif->gso)
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

Re: (no subject)

[Konrad Rzeszutek Wilk]

On Mon, Oct 17, 2011 at 09:40:49AM +0200, Paolo Bonzini wrote:

Something went wrong with your patchbomb..

anyhow, lets CC Ian here since he is the maintainer.

> 
> Writing [PATCH] netback: disable features not supported by netfront ...
> ntent-Transfer-Encoding: 7bit
> Subject: [PATCH] netback: disable features not supported by netfront
> X-Mercurial-Node: eb896361fc70b60b9a257d0c82e19633a11b9d41
> Message-Id: <eb896361fc70b60b9a25.1318837062@yakj.usersys.redhat.com>
> User-Agent: Mercurial-patchbomb/1.9.1
> Date: Mon, 17 Oct 2011 09:37:42 +0200
> From: pbonzini@redhat.com
> To: pbonzini@redhat.com
> 
> # HG changeset patch
> # User Paolo Bonzini <pbonzini@redhat.com>
> # Date 1318837036 -7200
> # Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41
> # Parent  3c900d6a5f6a51ff1547f21fef30ab8b92feccc9
> netback: disable features not supported by netfront
> 
> Netback works by first setting all possible features, and then
> resetting some after connection, if the front-end didn't negotiate them.
> Except that in the old 2.6.18 tree the "resetting" part was missing.
> In the pvops tree, this should work correctly through the fix_features
> mechanism.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> diff --git a/drivers/xen/netback/interface.c b/drivers/xen/netback/interface.c
> --- a/drivers/xen/netback/interface.c
> +++ b/drivers/xen/netback/interface.c
> @@ -98,8 +98,9 @@ static int netbk_change_mtu(struct net_d
>  void netif_set_features(netif_t *netif)
>  {
>  	struct net_device *dev = netif->dev;
> -	int features = dev->features;
> +	int features;
>  
> +	features = dev->features & ~(NETIF_F_SG|NETIF_F_TSO|NETIF_F_IP_CSUM);
>  	if (netif->can_sg)
>  		features |= NETIF_F_SG;
>  	if (netif->gso)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

(no subject)

[Paolo Bonzini]

Writing [PATCH] netback: disable features not supported by netfront ...
ntent-Transfer-Encoding: 7bit
Subject: [PATCH] netback: disable features not supported by netfront
X-Mercurial-Node: eb896361fc70b60b9a257d0c82e19633a11b9d41
Message-Id: <eb896361fc70b60b9a25.1318837062@yakj.usersys.redhat.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 17 Oct 2011 09:37:42 +0200
From: pbonzini@redhat.com
To: pbonzini@redhat.com

# HG changeset patch
# User Paolo Bonzini <pbonzini@redhat.com>
# Date 1318837036 -7200
# Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41
# Parent  3c900d6a5f6a51ff1547f21fef30ab8b92feccc9
netback: disable features not supported by netfront

Netback works by first setting all possible features, and then
resetting some after connection, if the front-end didn't negotiate them.
Except that in the old 2.6.18 tree the "resetting" part was missing.
In the pvops tree, this should work correctly through the fix_features
mechanism.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

diff --git a/drivers/xen/netback/interface.c b/drivers/xen/netback/interface.c
--- a/drivers/xen/netback/interface.c
+++ b/drivers/xen/netback/interface.c
@@ -98,8 +98,9 @@ static int netbk_change_mtu(struct net_d
 void netif_set_features(netif_t *netif)
 {
 	struct net_device *dev = netif->dev;
-	int features = dev->features;
+	int features;
 
+	features = dev->features & ~(NETIF_F_SG|NETIF_F_TSO|NETIF_F_IP_CSUM);
 	if (netif->can_sg)
 		features |= NETIF_F_SG;
 	if (netif->gso)

Re: (no subject)

[Andrew Cooper]

On 06/10/11 14:11, Pratik shinde wrote:
> why coscheduling is not implemented in xen?

http://wiki.xen.org/xenwiki/AskingXenDevelQuestions

After reading that wiki page, please explain why you think coscheduling
should be implemented on Xen.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

(no subject)

[Pratik shinde]

[-- Attachment #1.1: Type: text/plain, Size: 44 bytes --]

why coscheduling is not implemented in xen?

[-- Attachment #1.2: Type: text/html, Size: 48 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Grant McWilliams]

http://succeedonpurpose.com/google.php

Re: (no subject)

[Konrad Rzeszutek Wilk]

On Tue, Jun 21, 2011 at 05:39:46AM +0200, Attila Jecs wrote:
> Hi!
> 
> well, i got this when booting to gentoo/x64 xen/4.1 kernel/3.0rc3

Thank you.

That is a benign error. Does it continue booting?
> 
> Jun 21 05:18:02 szerver kernel: Initializing cgroup subsys perf_event
> Jun 21 05:18:02 szerver kernel: tseg: 00cfe00000
> Jun 21 05:18:02 szerver kernel: CPU: Physical Processor ID: 0
> Jun 21 05:18:02 szerver kernel: CPU: Processor Core ID: 0
> Jun 21 05:18:02 szerver kernel: ACPI: Core revision 20110413
> Jun 21 05:18:02 szerver kernel: cpu 0 spinlock event irq 273
> Jun 21 05:18:02 szerver kernel: Performance Events: AMD PMU driver.
> Jun 21 05:18:02 szerver kernel: ------------[ cut here ]------------
> Jun 21 05:18:02 szerver kernel: WARNING: at arch/x86/xen/enlighten.c:714
> 0xffffffff815cd65f()
> Jun 21 05:18:02 szerver kernel: Hardware name: GA-890FXA-UD5
> Jun 21 05:18:02 szerver kernel: Modules linked in:
> Jun 21 05:18:02 szerver kernel: Pid: 1, comm: swapper Not tainted 3.0.0-rc3
> #8
> Jun 21 05:18:02 szerver kernel: Call Trace:
> Jun 21 05:18:02 szerver kernel: [<ffffffff8104e3db>] ? 0xffffffff8104e3db
> Jun 21 05:18:02 szerver kernel: [<ffffffff815cd65f>] ? 0xffffffff815cd65f
> Jun 21 05:18:02 szerver kernel: [<ffffffff815cd1cd>] ? 0xffffffff815cd1cd
> Jun 21 05:18:02 szerver kernel: [<ffffffff8100214a>] ? 0xffffffff8100214a
> Jun 21 05:18:02 szerver kernel: [<ffffffff815c4c07>] ? 0xffffffff815c4c07
> Jun 21 05:18:02 szerver kernel: [<ffffffff81463d64>] ? 0xffffffff81463d64
> Jun 21 05:18:02 szerver kernel: [<ffffffff81463176>] ? 0xffffffff81463176
> Jun 21 05:18:02 szerver kernel: [<ffffffff814628e1>] ? 0xffffffff814628e1
> Jun 21 05:18:02 szerver kernel: [<ffffffff81463d60>] ? 0xffffffff81463d60
> Jun 21 05:18:02 szerver kernel: ---[ end trace 4eaa2a86a8e2da22 ]---
> Jun 21 05:18:02 szerver kernel: ... version:                0
> Jun 21 05:18:02 szerver kernel: ... bit width:              48
> Jun 21 05:18:02 szerver kernel: ... generic registers:      4
> Jun 21 05:18:02 szerver kernel: ... value mask:             0000ffffffffffff
> Jun 21 05:18:02 szerver kernel: ... max period:             00007fffffffffff
> Jun 21 05:18:02 szerver kernel: ... fixed-purpose events:   0
> Jun 21 05:18:02 szerver kernel: ... event mask:             000000000000000f
> Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 1
> Jun 21 05:18:02 szerver kernel: cpu 1 spinlock event irq 279
> Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 2
> Jun 21 05:18:02 szerver kernel: cpu 2 spinlock event irq 285
> Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 3
> Jun 21 05:18:02 szerver kernel: cpu 3 spinlock event irq 291
> Jun 21 05:18:02 szerver kernel: Brought up 4 CPUs
> Jun 21 05:18:02 szerver kernel: devtmpfs: initialized
> 
> maybe it helps.
> if u need more info, just tell me
> -- 
> Attila Jecs

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

(no subject)

[Attila Jecs]

[-- Attachment #1.1: Type: text/plain, Size: 2657 bytes --]

Hi!

well, i got this when booting to gentoo/x64 xen/4.1 kernel/3.0rc3

Jun 21 05:18:02 szerver kernel: Initializing cgroup subsys perf_event
Jun 21 05:18:02 szerver kernel: tseg: 00cfe00000
Jun 21 05:18:02 szerver kernel: CPU: Physical Processor ID: 0
Jun 21 05:18:02 szerver kernel: CPU: Processor Core ID: 0
Jun 21 05:18:02 szerver kernel: ACPI: Core revision 20110413
Jun 21 05:18:02 szerver kernel: cpu 0 spinlock event irq 273
Jun 21 05:18:02 szerver kernel: Performance Events: AMD PMU driver.
Jun 21 05:18:02 szerver kernel: ------------[ cut here ]------------
Jun 21 05:18:02 szerver kernel: WARNING: at arch/x86/xen/enlighten.c:714
0xffffffff815cd65f()
Jun 21 05:18:02 szerver kernel: Hardware name: GA-890FXA-UD5
Jun 21 05:18:02 szerver kernel: Modules linked in:
Jun 21 05:18:02 szerver kernel: Pid: 1, comm: swapper Not tainted 3.0.0-rc3
#8
Jun 21 05:18:02 szerver kernel: Call Trace:
Jun 21 05:18:02 szerver kernel: [<ffffffff8104e3db>] ? 0xffffffff8104e3db
Jun 21 05:18:02 szerver kernel: [<ffffffff815cd65f>] ? 0xffffffff815cd65f
Jun 21 05:18:02 szerver kernel: [<ffffffff815cd1cd>] ? 0xffffffff815cd1cd
Jun 21 05:18:02 szerver kernel: [<ffffffff8100214a>] ? 0xffffffff8100214a
Jun 21 05:18:02 szerver kernel: [<ffffffff815c4c07>] ? 0xffffffff815c4c07
Jun 21 05:18:02 szerver kernel: [<ffffffff81463d64>] ? 0xffffffff81463d64
Jun 21 05:18:02 szerver kernel: [<ffffffff81463176>] ? 0xffffffff81463176
Jun 21 05:18:02 szerver kernel: [<ffffffff814628e1>] ? 0xffffffff814628e1
Jun 21 05:18:02 szerver kernel: [<ffffffff81463d60>] ? 0xffffffff81463d60
Jun 21 05:18:02 szerver kernel: ---[ end trace 4eaa2a86a8e2da22 ]---
Jun 21 05:18:02 szerver kernel: ... version:                0
Jun 21 05:18:02 szerver kernel: ... bit width:              48
Jun 21 05:18:02 szerver kernel: ... generic registers:      4
Jun 21 05:18:02 szerver kernel: ... value mask:             0000ffffffffffff
Jun 21 05:18:02 szerver kernel: ... max period:             00007fffffffffff
Jun 21 05:18:02 szerver kernel: ... fixed-purpose events:   0
Jun 21 05:18:02 szerver kernel: ... event mask:             000000000000000f
Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 1
Jun 21 05:18:02 szerver kernel: cpu 1 spinlock event irq 279
Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 2
Jun 21 05:18:02 szerver kernel: cpu 2 spinlock event irq 285
Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 3
Jun 21 05:18:02 szerver kernel: cpu 3 spinlock event irq 291
Jun 21 05:18:02 szerver kernel: Brought up 4 CPUs
Jun 21 05:18:02 szerver kernel: devtmpfs: initialized

maybe it helps.
if u need more info, just tell me
-- 
Attila Jecs

[-- Attachment #1.2: Type: text/html, Size: 3237 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Novik, Alex]

[-- Attachment #1.1: Type: text/plain, Size: 503 bytes --]

Hi, all.
 How do I activate the battery management in pass-through mode?  XEN 4.1, platform Lenovo.
 Thanks in advance,
 Alex Novik.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[-- Attachment #1.2: Type: text/html, Size: 2312 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Keshav Darak]

[-- Attachment #1.1: Type: text/plain, Size: 1585 bytes --]

We have implemented hugepage support for guests in following manner

In
 our implementation we added a parameter hugepage_num which is specified
 in the config file of the DomU. It is the number of hugepages that the 
guest is guaranteed to receive whenever the kernel asks for hugepage by 
using its boot time parameter or reserving after booting (eg. Using echo
 XX > /proc/sys/vm/nr_hugepages). During creation of the domain we 
reserve MFN's for these hugepages and store them in the list. The 
listhead of this list is inside the domain structure with name 
"hugepage_list". When the domain is booting, at that time the memory 
seen by the kernel is allocated memory  less the amount required for hugepages. The function 
reserve_hugepage_range is called as a initcall. Before this function the
 xen_extra_mem_start points to this apparent end of the memory. In this 
function we reserve the PFN range for the hugepages which are going to 
be allocated by kernel by incrementing the xen_extra_mem_start. We 
maintain these PFNs as pages in "xen_hugepfn_list" in the kernel. 

Now before the kernel requests for hugepages, it makes a hypercall HYPERVISOR_memory_op  to get count of hugepages allocated to it and accordingly reserves the pfn range.
then whenever kernel requests for hugepages it again make hypercall HYPERVISOR_memory_op to get the preallocated hugepage and according makes the p2m mapping on both sides (xen as well as kernel side)

The approach can be better explained using the presentation attached.

--
Keshav Darak

 




      

[-- Attachment #1.2: Type: text/html, Size: 1742 bytes --]

[-- Attachment #2: xen_patch_210311_0227.patch --]
[-- Type: application/x-download, Size: 18234 bytes --]

[-- Attachment #3: jeremy-kernel.patch --]
[-- Type: application/x-download, Size: 6731 bytes --]

[-- Attachment #4: our_hugepage_approach.ppt --]
[-- Type: application/vnd.ms-powerpoint, Size: 327168 bytes --]

[-- Attachment #5: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Ken Ash]

 h

Sent from my iPhone

Re: (no subject)

[George Shuklin]

В Чтв, 07/10/2010 в 15:21 +0100, Ian Campbell пишет:
> On Thu, 2010-10-07 at 14:43 +0100, George Shuklin wrote:
> > Please note this bug:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711
> > 
> > This behavior confirmed in lenny and squeeze. Kernel is very unstable
> > (compare to centos/suse) and cause OOM killer without any rational
> > reason.
> 
> I wasn't aware that this issue was present on Squeeze as well as Lenny,
> there is no mention of that in the bug.
> 
> The two kernels have practically nothing in common wrt the Xen port
> (Lenny was classic-Xen patch based and Squeeze is pvops based) so if you
> are seeing something similar under Squeeze as well please file a
> separate bug report.

OK, I'll recheck bug in squeeze and report it separately.

Main problem for this bug is very high value of free memory when OOM
killer starts. In my tests it appear when about 300MiB was free. And it
kill not most 'badness' process, but runs repeatedly for few (or even
all) process. 

But, again, I'll recheck it in clean environment with reproducible
behavior and submit it.

Re: (no subject)

[Ian Campbell]

On Thu, 2010-10-07 at 14:43 +0100, George Shuklin wrote:
> Please note this bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711
> 
> This behavior confirmed in lenny and squeeze. Kernel is very unstable
> (compare to centos/suse) and cause OOM killer without any rational
> reason.

I wasn't aware that this issue was present on Squeeze as well as Lenny,
there is no mention of that in the bug.

The two kernels have practically nothing in common wrt the Xen port
(Lenny was classic-Xen patch based and Squeeze is pvops based) so if you
are seeing something similar under Squeeze as well please file a
separate bug report.

(Note that only the OS in the specific VM which is exhibiting the
problem is relevant, so even if you are seeing the issue with a Lenny VM
hosted on a Squeeze dom0 that does not imply the bug is present in
Squeeze).

I'm afraid that at this point I do not have cycles to spend on the Lenny
issue. Unfortunately my best recommendation is not to balloon such
systems too aggressively or to use a more recent kernel (e.g. a backport
of the Squeeze kernel).

Ian.

-- 
Ian Campbell
Current Noise: Twisted Sister - Tear It Loose

Other restrictions may apply.

Re: (no subject)

[Ian Campbell]

On Thu, 2010-10-07 at 03:46 +0100, Mike Viau wrote:
> I have search the archives for reference to Ian Campbell's Debian
> binaries found at: http://xenbits.xen.org/people/ianc/

> http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%
> 2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!
> &idxname=xen-devel&max=20&result=normal&sort=score

They were posted on my personal website
http://www.hellion.org.uk/debian/test/
and referred to by
http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01912.html
but I moved them to xen.org and just left a pointer on my website, I
didn't bother to announce this.

> I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or
> http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way
> be added to Debian's apt sources file?

I'm afraid the necessary meta data is not present to allow them to be
used as an apt source so they are download+dpkg only.

Originally they were intended to simply verify that the issues people
were seeing related to changesets which had been excluded from the
Debian kernel.

I haven't decided if these are something I necessarily want to maintain
for the lifetime of Squeeze. For the moment I build them for my own
personal use and so I publish them, since I might as well do so, but
they are not a formal xen.org service or anything like that.

For something provided by xen.org I think we would more likely want to
track the latest xen.git#xen/stable-2.6.x.y branch rather than the
Debian packages.

Ian.

Re: (no subject)

[George Shuklin]

Please note this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711

This behavior confirmed in lenny and squeeze. Kernel is very unstable
(compare to centos/suse) and cause OOM killer without any rational
reason.


В Чтв, 07/10/2010 в 11:43 +0100, Stefano Stabellini пишет:
> On Thu, 7 Oct 2010, Mike Viau wrote:
> > 
> > I have search the archives for reference to Ian Campbell's Debian binaries found at: http://xenbits.xen.org/people/ianc/
> > 
> > http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!&idxname=xen-devel&max=20&result=normal&sort=score
> > 
> > I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way be added to Debian's apt sources file?
> > 
> 
> We intend to publish debian and centos packages for the xen hypervisor
> and tools, however the project is stalling a bit recently.
> Hopefully those packages will be published in the next few weeks.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: (no subject)

[Stefano Stabellini]

On Thu, 7 Oct 2010, Mike Viau wrote:
> 
> I have search the archives for reference to Ian Campbell's Debian binaries found at: http://xenbits.xen.org/people/ianc/
> 
> http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!&idxname=xen-devel&max=20&result=normal&sort=score
> 
> I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way be added to Debian's apt sources file?
> 

We intend to publish debian and centos packages for the xen hypervisor
and tools, however the project is stalling a bit recently.
Hopefully those packages will be published in the next few weeks.

(no subject)

[Mike Viau]

I have search the archives for reference to Ian Campbell's Debian binaries found at: http://xenbits.xen.org/people/ianc/


http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!&idxname=xen-devel&max=20&result=normal&sort=score


I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way be added to Debian's apt sources file?


Thanks.



-Mike Viau


 		 	   		  

(no subject)

[Jiang, Yunhong]

[-- Attachment #1: Type: text/plain, Size: 10984 bytes --]

Add a x86_mcinfo_reserve() function, to reserve space from mc_info.

With this method, we don't need to collect bank and globalinformation to a
local variable and do x86_mcinfo_add() to copy that information to mc_info.
This avoid copy and also we can be aware earlier if there is enough space
in the mc_info.

Also extract function that get global/bank information to seperated
function mca_init_bank/mca_init_global.

It's meaningless to get the current information in mce context, keep it here
but should be removed in future.

Also a flag added to mc_info, to indicate some information is lost due to OOM.

Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>

diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 16 18:51:58 2010 +0800
@@ -125,6 +125,88 @@ void mce_need_clearbank_register(mce_nee
     mc_need_clearbank_scan = cbfunc;
 }
 
+static struct mcinfo_bank *mca_init_bank(enum mca_source who,
+                                         struct mc_info *mi, int bank)
+{
+	struct mcinfo_bank *mib;
+	uint64_t addr=0, misc = 0;
+
+	if (!mi)
+		return NULL;
+
+	mib = x86_mcinfo_reserve(mi, sizeof(struct mcinfo_bank));
+	if (!mib)
+	{
+		mi->flags |= MCINFO_FLAGS_UNCOMPLETE;
+		return NULL;
+	}
+
+	memset(mib, 0, sizeof (struct mcinfo_bank));
+	mca_rdmsrl(MSR_IA32_MC0_STATUS + bank * 4, mib->mc_status);
+
+	mib->common.type = MC_TYPE_BANK;
+	mib->common.size = sizeof (struct mcinfo_bank);
+	mib->mc_bank = bank;
+
+	addr = misc = 0;
+	if (mib->mc_status & MCi_STATUS_MISCV)
+		mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * bank, mib->mc_misc);
+
+	if (mib->mc_status & MCi_STATUS_ADDRV)
+	{
+		mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * bank, mib->mc_addr);
+
+		if (mfn_valid(paddr_to_pfn(mib->mc_addr))) {
+			struct domain *d;
+
+			d = maddr_get_owner(mib->mc_addr);
+			if (d != NULL && (who == MCA_POLLER ||
+				  who == MCA_CMCI_HANDLER))
+				mib->mc_domid = d->domain_id;
+		}
+	}
+
+	if (who == MCA_CMCI_HANDLER) {
+		mca_rdmsrl(MSR_IA32_MC0_CTL2 + bank, mib->mc_ctrl2);
+		rdtscll(mib->mc_tsc);
+	}
+
+	return mib;
+}
+
+static int mca_init_global(uint32_t flags, struct mcinfo_global *mig)
+{
+	uint64_t status;
+	int cpu_nr;
+	struct vcpu *v = current;
+	struct domain *d;
+
+	/* Set global information */
+	memset(mig, 0, sizeof (struct mcinfo_global));
+	mig->common.type = MC_TYPE_GLOBAL;
+	mig->common.size = sizeof (struct mcinfo_global);
+	mca_rdmsrl(MSR_IA32_MCG_STATUS, status);
+	mig->mc_gstatus = status;
+	mig->mc_domid = mig->mc_vcpuid = -1;
+	mig->mc_flags = flags;
+	cpu_nr = smp_processor_id();
+	/* Retrieve detector information */
+	x86_mc_get_cpu_info(cpu_nr, &mig->mc_socketid,
+	  &mig->mc_coreid, &mig->mc_core_threadid,
+	  &mig->mc_apicid, NULL, NULL, NULL);
+
+	/* This is really meaningless */
+	if (v != NULL && ((d = v->domain) != NULL)) {
+		mig->mc_domid = d->domain_id;
+		mig->mc_vcpuid = v->vcpu_id;
+	} else {
+		mig->mc_domid = -1;
+		mig->mc_vcpuid = -1;
+	}
+
+	return 0;
+}
+
 /* Utility function to perform MCA bank telemetry readout and to push that
  * telemetry towards an interested dom0 for logging and diagnosis.
  * The caller - #MC handler or MCA poll function - must arrange that we
@@ -139,64 +221,38 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 mctelem_cookie_t mcheck_mca_logout(enum mca_source who, cpu_banks_t bankmask,
     struct mca_summary *sp, cpu_banks_t* clear_bank)
 {
-	struct vcpu *v = current;
-	struct domain *d;
-	uint64_t gstatus, status, addr, misc;
-	struct mcinfo_global mcg;	/* on stack */
-	struct mcinfo_common *mic;
-	struct mcinfo_global *mig;	/* on stack */
+	uint64_t gstatus, status;
+	struct mcinfo_global *mig = NULL;	/* on stack */
 	mctelem_cookie_t mctc = NULL;
-	uint32_t uc = 0, pcc = 0, recover, need_clear = 1 ;
+	uint32_t uc = 0, pcc = 0, recover, need_clear = 1, mc_flags = 0;
 	struct mc_info *mci = NULL;
 	mctelem_class_t which = MC_URGENT;	/* XXXgcc */
-	unsigned int cpu_nr;
 	int errcnt = 0;
 	int i;
 	enum mca_extinfo cbret = MCA_EXTINFO_IGNORED;
 
-	cpu_nr = smp_processor_id();
-	BUG_ON(cpu_nr != v->processor);
-
 	mca_rdmsrl(MSR_IA32_MCG_STATUS, gstatus);
-
-	memset(&mcg, 0, sizeof (mcg));
-	mcg.common.type = MC_TYPE_GLOBAL;
-	mcg.common.size = sizeof (mcg);
-	if (v != NULL && ((d = v->domain) != NULL)) {
-		mcg.mc_domid = d->domain_id;
-		mcg.mc_vcpuid = v->vcpu_id;
-	} else {
-		mcg.mc_domid = -1;
-		mcg.mc_vcpuid = -1;
-	}
-	mcg.mc_gstatus = gstatus;	/* MCG_STATUS */
-
 	switch (who) {
 	case MCA_MCE_HANDLER:
 	case MCA_MCE_SCAN:
-		mcg.mc_flags = MC_FLAG_MCE;
+		mc_flags = MC_FLAG_MCE;
 		which = MC_URGENT;
 		break;
 
 	case MCA_POLLER:
 	case MCA_RESET:
-		mcg.mc_flags = MC_FLAG_POLLED;
+		mc_flags = MC_FLAG_POLLED;
 		which = MC_NONURGENT;
 		break;
 
 	case MCA_CMCI_HANDLER:
-		mcg.mc_flags = MC_FLAG_CMCI;
+		mc_flags = MC_FLAG_CMCI;
 		which = MC_NONURGENT;
 		break;
 
 	default:
 		BUG();
 	}
-
-	/* Retrieve detector information */
-	x86_mc_get_cpu_info(cpu_nr, &mcg.mc_socketid,
-	    &mcg.mc_coreid, &mcg.mc_core_threadid,
-	    &mcg.mc_apicid, NULL, NULL, NULL);
 
 	/* If no mc_recovery_scan callback handler registered,
 	 * this error is not recoverable
@@ -204,7 +260,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 	recover = (mc_recoverable_scan)? 1: 0;
 
 	for (i = 0; i < 32 && i < nr_mce_banks; i++) {
-		struct mcinfo_bank mcb;		/* on stack */
+		struct mcinfo_bank *mib;		/* on stack */
 
 		/* Skip bank if corresponding bit in bankmask is clear */
 		if (!test_bit(i, bankmask))
@@ -227,17 +283,16 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		 * a poller;  this can fail (for example dom0 may not
 		 * yet have consumed past telemetry). */
 		if (errcnt == 0) {
-			if ((mctc = mctelem_reserve(which)) != NULL) {
+			if ( (mctc = mctelem_reserve(which)) != NULL ) {
 				mci = mctelem_dataptr(mctc);
 				mcinfo_clear(mci);
+				mig = (struct mcinfo_global*)x86_mcinfo_reserve
+				  (mci, sizeof(struct mcinfo_global));
+				/* mc_info should at least hold up the global information */
+				ASSERT(mig);
+				mca_init_global(mc_flags, mig);
 			}
 		}
-
-		memset(&mcb, 0, sizeof (mcb));
-		mcb.common.type = MC_TYPE_BANK;
-		mcb.common.size = sizeof (mcb);
-		mcb.mc_bank = i;
-		mcb.mc_status = status;
 
 		/* form a mask of which banks have logged uncorrected errors */
 		if ((status & MCi_STATUS_UC) != 0)
@@ -252,37 +307,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		  */
 			recover = mc_recoverable_scan(status);
 
-		addr = misc = 0;
-
-		if (status & MCi_STATUS_ADDRV) {
-			mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * i, addr);
-			if (mfn_valid(paddr_to_pfn(addr))) {
-				d = maddr_get_owner(addr);
-				if (d != NULL && (who == MCA_POLLER ||
-				    who == MCA_CMCI_HANDLER))
-					mcb.mc_domid = d->domain_id;
-			}
-		}
-
-		if (status & MCi_STATUS_MISCV)
-			mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * i, misc);
-
-		mcb.mc_addr = addr;
-		mcb.mc_misc = misc;
-
-		if (who == MCA_CMCI_HANDLER) {
-			mca_rdmsrl(MSR_IA32_MC0_CTL2 + i, mcb.mc_ctrl2);
-			rdtscll(mcb.mc_tsc);
-		}
-
-		/* Increment the error count;  if this is the first bank
-		 * with a valid error then add the global info to the mcinfo. */
-		if (errcnt++ == 0 && mci != NULL)
-			x86_mcinfo_add(mci, &mcg);
-
-		/* Add the bank data */
-		if (mci != NULL)
-			x86_mcinfo_add(mci, &mcb);
+		mib = mca_init_bank(who, mci, i);
 
 		if (mc_callback_bank_extended && cbret != MCA_EXTINFO_GLOBAL) {
 			cbret = mc_callback_bank_extended(mci, i, status);
@@ -298,12 +323,8 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		wmb();
 	}
 
-	if (mci != NULL && errcnt > 0) {
-		x86_mcinfo_lookup(mic, mci, MC_TYPE_GLOBAL);
-		mig = container_of(mic, struct mcinfo_global, common);
-		if (mic == NULL)
-			;
-		else if (pcc)
+	if (mig && errcnt > 0) {
+		if (pcc)
 			mig->mc_flags |= MC_FLAG_UNCORRECTABLE;
 		else if (uc)
 			mig->mc_flags |= MC_FLAG_RECOVERABLE;
@@ -758,13 +779,12 @@ static void mcinfo_clear(struct mc_info 
 	x86_mcinfo_nentries(mi) = 0;
 }
 
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+void *x86_mcinfo_reserve(struct mc_info *mi, int size)
 {
 	int i;
 	unsigned long end1, end2;
-	struct mcinfo_common *mic, *mic_base, *mic_index;
-
-	mic = (struct mcinfo_common *)mcinfo;
+	struct mcinfo_common *mic_base, *mic_index;
+
 	mic_index = mic_base = x86_mcinfo_first(mi);
 
 	/* go to first free entry */
@@ -774,16 +794,35 @@ int x86_mcinfo_add(struct mc_info *mi, v
 
 	/* check if there is enough size */
 	end1 = (unsigned long)((uint8_t *)mic_base + sizeof(struct mc_info));
-	end2 = (unsigned long)((uint8_t *)mic_index + mic->size);
+	end2 = (unsigned long)((uint8_t *)mic_index + size);
 
 	if (end1 < end2)
-		return x86_mcerr("mcinfo_add: no more sparc", -ENOSPC);
+	{
+		mce_printk(MCE_CRITICAL,
+			"mcinfo_add: No space left in mc_info\n");
+		return NULL;
+	}
 
 	/* there's enough space. add entry. */
-	memcpy(mic_index, mic, mic->size);
 	x86_mcinfo_nentries(mi)++;
 
-	return 0;
+    return mic_index;
+}
+
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+{
+	struct mcinfo_common *mic, *buf;
+
+	mic = (struct mcinfo_common *)mcinfo;
+	buf = x86_mcinfo_reserve(mi, mic->size);
+
+	if ( !buf )
+		mce_printk(MCE_CRITICAL,
+			"mcinfo_add: No space left in mc_info\n");
+	else
+		memcpy(buf, mic, mic->size);
+
+	return buf;
 }
 
 /* Dump machine check information in a format,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Apr 16 18:51:58 2010 +0800
@@ -161,7 +161,8 @@ typedef enum mca_extinfo (*x86_mce_callb
     (struct mc_info *, uint16_t, uint64_t);
 extern void x86_mce_callback_register(x86_mce_callback_t);
 
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_reserve(struct mc_info *mi, int size);
 void x86_mcinfo_dump(struct mc_info *mi);
 
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/include/public/arch-x86/xen-mca.h	Fri Apr 16 18:51:58 2010 +0800
@@ -233,10 +233,11 @@ struct mcinfo_recovery
 #define MCINFO_HYPERCALLSIZE	1024
 #define MCINFO_MAXSIZE		768
 
+#define MCINFO_FLAGS_UNCOMPLETE 0x1
 struct mc_info {
     /* Number of mcinfo_* entries in mi_data */
     uint32_t mi_nentries;
-    uint32_t _pad0;
+    uint32_t flags;
     uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
 };
 typedef struct mc_info mc_info_t;



[-- Attachment #2: mcinfo_reserve.patch --]
[-- Type: application/octet-stream, Size: 10822 bytes --]

# HG changeset patch
# User Yunhong Jiang <yunhong.jiang@intel.com>
# Date 1271415118 -28800
# Node ID 63632454170a30f4e0cbffa78be62b33e87605bb
# Parent  4e1d1e56e8b90f8594db6f812b5bd5f35f6e87be
Add a x86_mcinfo_reserve() function, to reserve space from mc_info.

With this method, we don't need to collect bank and globalinformation to a
local variable and do x86_mcinfo_add() to copy that information to mc_info.
This avoid copy and also we can be aware earlier if there is enough space
in the mc_info.

Also extract function that get global/bank information to seperated
function mca_init_bank/mca_init_global.

It's meaningless to get the current information in mce context, keep it here
but should be removed in future.

Also a flag added to mc_info, to indicate some information is lost due to OOM.

Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>

diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 16 18:51:58 2010 +0800
@@ -125,6 +125,88 @@ void mce_need_clearbank_register(mce_nee
     mc_need_clearbank_scan = cbfunc;
 }
 
+static struct mcinfo_bank *mca_init_bank(enum mca_source who,
+                                         struct mc_info *mi, int bank)
+{
+	struct mcinfo_bank *mib;
+	uint64_t addr=0, misc = 0;
+
+	if (!mi)
+		return NULL;
+
+	mib = x86_mcinfo_reserve(mi, sizeof(struct mcinfo_bank));
+	if (!mib)
+	{
+		mi->flags |= MCINFO_FLAGS_UNCOMPLETE;
+		return NULL;
+	}
+
+	memset(mib, 0, sizeof (struct mcinfo_bank));
+	mca_rdmsrl(MSR_IA32_MC0_STATUS + bank * 4, mib->mc_status);
+
+	mib->common.type = MC_TYPE_BANK;
+	mib->common.size = sizeof (struct mcinfo_bank);
+	mib->mc_bank = bank;
+
+	addr = misc = 0;
+	if (mib->mc_status & MCi_STATUS_MISCV)
+		mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * bank, mib->mc_misc);
+
+	if (mib->mc_status & MCi_STATUS_ADDRV)
+	{
+		mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * bank, mib->mc_addr);
+
+		if (mfn_valid(paddr_to_pfn(mib->mc_addr))) {
+			struct domain *d;
+
+			d = maddr_get_owner(mib->mc_addr);
+			if (d != NULL && (who == MCA_POLLER ||
+				  who == MCA_CMCI_HANDLER))
+				mib->mc_domid = d->domain_id;
+		}
+	}
+
+	if (who == MCA_CMCI_HANDLER) {
+		mca_rdmsrl(MSR_IA32_MC0_CTL2 + bank, mib->mc_ctrl2);
+		rdtscll(mib->mc_tsc);
+	}
+
+	return mib;
+}
+
+static int mca_init_global(uint32_t flags, struct mcinfo_global *mig)
+{
+	uint64_t status;
+	int cpu_nr;
+	struct vcpu *v = current;
+	struct domain *d;
+
+	/* Set global information */
+	memset(mig, 0, sizeof (struct mcinfo_global));
+	mig->common.type = MC_TYPE_GLOBAL;
+	mig->common.size = sizeof (struct mcinfo_global);
+	mca_rdmsrl(MSR_IA32_MCG_STATUS, status);
+	mig->mc_gstatus = status;
+	mig->mc_domid = mig->mc_vcpuid = -1;
+	mig->mc_flags = flags;
+	cpu_nr = smp_processor_id();
+	/* Retrieve detector information */
+	x86_mc_get_cpu_info(cpu_nr, &mig->mc_socketid,
+	  &mig->mc_coreid, &mig->mc_core_threadid,
+	  &mig->mc_apicid, NULL, NULL, NULL);
+
+	/* This is really meaningless */
+	if (v != NULL && ((d = v->domain) != NULL)) {
+		mig->mc_domid = d->domain_id;
+		mig->mc_vcpuid = v->vcpu_id;
+	} else {
+		mig->mc_domid = -1;
+		mig->mc_vcpuid = -1;
+	}
+
+	return 0;
+}
+
 /* Utility function to perform MCA bank telemetry readout and to push that
  * telemetry towards an interested dom0 for logging and diagnosis.
  * The caller - #MC handler or MCA poll function - must arrange that we
@@ -139,64 +221,38 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 mctelem_cookie_t mcheck_mca_logout(enum mca_source who, cpu_banks_t bankmask,
     struct mca_summary *sp, cpu_banks_t* clear_bank)
 {
-	struct vcpu *v = current;
-	struct domain *d;
-	uint64_t gstatus, status, addr, misc;
-	struct mcinfo_global mcg;	/* on stack */
-	struct mcinfo_common *mic;
-	struct mcinfo_global *mig;	/* on stack */
+	uint64_t gstatus, status;
+	struct mcinfo_global *mig = NULL;	/* on stack */
 	mctelem_cookie_t mctc = NULL;
-	uint32_t uc = 0, pcc = 0, recover, need_clear = 1 ;
+	uint32_t uc = 0, pcc = 0, recover, need_clear = 1, mc_flags = 0;
 	struct mc_info *mci = NULL;
 	mctelem_class_t which = MC_URGENT;	/* XXXgcc */
-	unsigned int cpu_nr;
 	int errcnt = 0;
 	int i;
 	enum mca_extinfo cbret = MCA_EXTINFO_IGNORED;
 
-	cpu_nr = smp_processor_id();
-	BUG_ON(cpu_nr != v->processor);
-
 	mca_rdmsrl(MSR_IA32_MCG_STATUS, gstatus);
-
-	memset(&mcg, 0, sizeof (mcg));
-	mcg.common.type = MC_TYPE_GLOBAL;
-	mcg.common.size = sizeof (mcg);
-	if (v != NULL && ((d = v->domain) != NULL)) {
-		mcg.mc_domid = d->domain_id;
-		mcg.mc_vcpuid = v->vcpu_id;
-	} else {
-		mcg.mc_domid = -1;
-		mcg.mc_vcpuid = -1;
-	}
-	mcg.mc_gstatus = gstatus;	/* MCG_STATUS */
-
 	switch (who) {
 	case MCA_MCE_HANDLER:
 	case MCA_MCE_SCAN:
-		mcg.mc_flags = MC_FLAG_MCE;
+		mc_flags = MC_FLAG_MCE;
 		which = MC_URGENT;
 		break;
 
 	case MCA_POLLER:
 	case MCA_RESET:
-		mcg.mc_flags = MC_FLAG_POLLED;
+		mc_flags = MC_FLAG_POLLED;
 		which = MC_NONURGENT;
 		break;
 
 	case MCA_CMCI_HANDLER:
-		mcg.mc_flags = MC_FLAG_CMCI;
+		mc_flags = MC_FLAG_CMCI;
 		which = MC_NONURGENT;
 		break;
 
 	default:
 		BUG();
 	}
-
-	/* Retrieve detector information */
-	x86_mc_get_cpu_info(cpu_nr, &mcg.mc_socketid,
-	    &mcg.mc_coreid, &mcg.mc_core_threadid,
-	    &mcg.mc_apicid, NULL, NULL, NULL);
 
 	/* If no mc_recovery_scan callback handler registered,
 	 * this error is not recoverable
@@ -204,7 +260,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 	recover = (mc_recoverable_scan)? 1: 0;
 
 	for (i = 0; i < 32 && i < nr_mce_banks; i++) {
-		struct mcinfo_bank mcb;		/* on stack */
+		struct mcinfo_bank *mib;		/* on stack */
 
 		/* Skip bank if corresponding bit in bankmask is clear */
 		if (!test_bit(i, bankmask))
@@ -227,17 +283,16 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		 * a poller;  this can fail (for example dom0 may not
 		 * yet have consumed past telemetry). */
 		if (errcnt == 0) {
-			if ((mctc = mctelem_reserve(which)) != NULL) {
+			if ( (mctc = mctelem_reserve(which)) != NULL ) {
 				mci = mctelem_dataptr(mctc);
 				mcinfo_clear(mci);
+				mig = (struct mcinfo_global*)x86_mcinfo_reserve
+				  (mci, sizeof(struct mcinfo_global));
+				/* mc_info should at least hold up the global information */
+				ASSERT(mig);
+				mca_init_global(mc_flags, mig);
 			}
 		}
-
-		memset(&mcb, 0, sizeof (mcb));
-		mcb.common.type = MC_TYPE_BANK;
-		mcb.common.size = sizeof (mcb);
-		mcb.mc_bank = i;
-		mcb.mc_status = status;
 
 		/* form a mask of which banks have logged uncorrected errors */
 		if ((status & MCi_STATUS_UC) != 0)
@@ -252,37 +307,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		  */
 			recover = mc_recoverable_scan(status);
 
-		addr = misc = 0;
-
-		if (status & MCi_STATUS_ADDRV) {
-			mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * i, addr);
-			if (mfn_valid(paddr_to_pfn(addr))) {
-				d = maddr_get_owner(addr);
-				if (d != NULL && (who == MCA_POLLER ||
-				    who == MCA_CMCI_HANDLER))
-					mcb.mc_domid = d->domain_id;
-			}
-		}
-
-		if (status & MCi_STATUS_MISCV)
-			mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * i, misc);
-
-		mcb.mc_addr = addr;
-		mcb.mc_misc = misc;
-
-		if (who == MCA_CMCI_HANDLER) {
-			mca_rdmsrl(MSR_IA32_MC0_CTL2 + i, mcb.mc_ctrl2);
-			rdtscll(mcb.mc_tsc);
-		}
-
-		/* Increment the error count;  if this is the first bank
-		 * with a valid error then add the global info to the mcinfo. */
-		if (errcnt++ == 0 && mci != NULL)
-			x86_mcinfo_add(mci, &mcg);
-
-		/* Add the bank data */
-		if (mci != NULL)
-			x86_mcinfo_add(mci, &mcb);
+		mib = mca_init_bank(who, mci, i);
 
 		if (mc_callback_bank_extended && cbret != MCA_EXTINFO_GLOBAL) {
 			cbret = mc_callback_bank_extended(mci, i, status);
@@ -298,12 +323,8 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		wmb();
 	}
 
-	if (mci != NULL && errcnt > 0) {
-		x86_mcinfo_lookup(mic, mci, MC_TYPE_GLOBAL);
-		mig = container_of(mic, struct mcinfo_global, common);
-		if (mic == NULL)
-			;
-		else if (pcc)
+	if (mig && errcnt > 0) {
+		if (pcc)
 			mig->mc_flags |= MC_FLAG_UNCORRECTABLE;
 		else if (uc)
 			mig->mc_flags |= MC_FLAG_RECOVERABLE;
@@ -758,13 +779,12 @@ static void mcinfo_clear(struct mc_info 
 	x86_mcinfo_nentries(mi) = 0;
 }
 
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+void *x86_mcinfo_reserve(struct mc_info *mi, int size)
 {
 	int i;
 	unsigned long end1, end2;
-	struct mcinfo_common *mic, *mic_base, *mic_index;
-
-	mic = (struct mcinfo_common *)mcinfo;
+	struct mcinfo_common *mic_base, *mic_index;
+
 	mic_index = mic_base = x86_mcinfo_first(mi);
 
 	/* go to first free entry */
@@ -774,16 +794,35 @@ int x86_mcinfo_add(struct mc_info *mi, v
 
 	/* check if there is enough size */
 	end1 = (unsigned long)((uint8_t *)mic_base + sizeof(struct mc_info));
-	end2 = (unsigned long)((uint8_t *)mic_index + mic->size);
+	end2 = (unsigned long)((uint8_t *)mic_index + size);
 
 	if (end1 < end2)
-		return x86_mcerr("mcinfo_add: no more sparc", -ENOSPC);
+	{
+		mce_printk(MCE_CRITICAL,
+			"mcinfo_add: No space left in mc_info\n");
+		return NULL;
+	}
 
 	/* there's enough space. add entry. */
-	memcpy(mic_index, mic, mic->size);
 	x86_mcinfo_nentries(mi)++;
 
-	return 0;
+    return mic_index;
+}
+
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+{
+	struct mcinfo_common *mic, *buf;
+
+	mic = (struct mcinfo_common *)mcinfo;
+	buf = x86_mcinfo_reserve(mi, mic->size);
+
+	if ( !buf )
+		mce_printk(MCE_CRITICAL,
+			"mcinfo_add: No space left in mc_info\n");
+	else
+		memcpy(buf, mic, mic->size);
+
+	return buf;
 }
 
 /* Dump machine check information in a format,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Apr 16 18:51:58 2010 +0800
@@ -161,7 +161,8 @@ typedef enum mca_extinfo (*x86_mce_callb
     (struct mc_info *, uint16_t, uint64_t);
 extern void x86_mce_callback_register(x86_mce_callback_t);
 
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_reserve(struct mc_info *mi, int size);
 void x86_mcinfo_dump(struct mc_info *mi);
 
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/include/public/arch-x86/xen-mca.h	Fri Apr 16 18:51:58 2010 +0800
@@ -233,10 +233,11 @@ struct mcinfo_recovery
 #define MCINFO_HYPERCALLSIZE	1024
 #define MCINFO_MAXSIZE		768
 
+#define MCINFO_FLAGS_UNCOMPLETE 0x1
 struct mc_info {
     /* Number of mcinfo_* entries in mi_data */
     uint32_t mi_nentries;
-    uint32_t _pad0;
+    uint32_t flags;
     uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
 };
 typedef struct mc_info mc_info_t;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Eads, Joshua Michael (S&T-Student)]

I have an HVM guest and I am trying to have a usermode program in Dom0 query the context (CPU registers, specifically) of the guest.  

I first tried using xc_domain_getcontext() in xenctrl.h but I haven't figured out what data structure ctxt_buf is that it returns.  Next, I have tried using xc_vcpu_getcontext() in xenctrl.h but so far it always returns -1 for failure.  For xc_vcpu_getcontext, I am passing in a vcpu number of 1 (I only have a single virtual CPU domU running) along with an unallocated vcpu_guest_context_t pointer.

Is this the right direction to pull guest registers, or is there another method I need to use to get the HVM guest context?

Thanks,
Josh

(no subject)

[Alexia Benington]

[-- Attachment #1.1: Type: text/plain, Size: 4183 bytes --]

Hi all,

My Dom0 crashed if I use the first grub configuration, but is ok if I use
the following one.

kernel          /boot/xen-3.4-unstable.gz
module          /boot/vmlinuz-2.6.18.8-xen root=/dev/sda2 ro

kernel          /boot/xen-3.4-unstable.gz com1=9600,8n1 console=com1 iommu=1
module          /boot/vmlinuz-2.6.18.8-xen root=/dev/sda2 ro xencons=ttyS
console=tty0 console=ttyS0

I've attached the full boot trace. Below is a snippet of the crash region.
Does anyone have any idea what's going on?

Thanks and have a nice day.


- Alexia

================================================
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1a.0: UHCI Host Controller
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000e0e0
(XEN) [VT-D]iommu.c:721: iommu_page_fault: iommu->reg = ffff828bfff55000
(XEN) [VT-D]iommu.c:693: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:675: iommu_fault:DMA Read: 0:1a.0 addr bf7ed000 REASON 6
iommu->reg = ffff828bfff55000
(XEN) print_vtd_entries: iommu = ffff8300bfef10f0 bdf = 0:1a:0 gmfn = bf7ed
(XEN)     root_entry = ffff83013bdea000
(XEN)     root_entry[0] = 1374a0001
(XEN)     context = ffff8301374a0000
(XEN)     context[d0] = 101_13bde6001
(XEN)     l3 = ffff83013bde6000
(XEN)     l3_index = 2
(XEN)     l3[2] = 137a83003
(XEN)     l2 = ffff830137a83000
(XEN)     l2_index = 1fb
(XEN)     l2[1fb] = 137887003
(XEN)     l1 = ffff830137887000
(XEN)     l1_index = 1ed
(XEN)     l1[1ed] = 0
(XEN)     l1[1ed] not present
uhci_hcd 0000:00:1a.0: host system error, PCI problems?
uhci_hcd 0000:00:1a.0: host controller halted, very bad!
uhci_hcd 0000:00:1a.0: HC died; cleaning up
usb usb1: configuration #1 chosen from 1 choice
usb usb1: can't set config #1, error -108
uhci_hcd 0000:00:1a.0: HC died; cleaning up
Unable to handle kernel NULL pointer dereference at 0000000000000018 RIP:
 [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
PGD ef053067 PUD ef051067 PMD 0
Oops: 0000 [1] SMP
CPU 3
Modules linked in: uhci_hcd usbcore thermal processor fan
Pid: 496, comm: insmod Not tainted 2.6.18.8-xen #1
RIP: e030:[<ffffffff88019be9>]  [<ffffffff88019be9>]
:usbcore:usb_kick_khubd+0x7/0x17
RSP: e02b:ffff8800eeb6fc50  EFLAGS: 00010002
RAX: 0000000000000000 RBX: ffff8800eed03c00 RCX: ffffffffff578000
RDX: ffffffffff578000 RSI: 0000000000000001 RDI: ffff8800ef03e000
RBP: 0000000000000000 R08: 000000000000000e R09: 0000000000000001
R10: ffff8800ef052570 R11: ffffffff80300885 R12: ffff8800eecb01c8
R13: 0000000000000000 R14: ffff8800ef03e000 R15: ffff8800eecb0070
FS:  00002ad0ef6c66d0(0000) GS:ffffffff804d9180(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process insmod (pid: 496, threadinfo ffff8800eeb6e000, task
ffff8800eec867a0)
Stack:  ffffffff8801a39b 0000000000000012 ffff8800ef03e000 ffff8800eed03c00
 ffffffff8801ad3c 0000001000000004 ffff8800eecb00e0 ffff8800eed03c00
 ffff8800eecb0000 0000000000000004 ffffffff8803d4a0 0000000000000000
Call Trace:
 [<ffffffff8801a39b>] :usbcore:usb_hc_died+0x5f/0x72
 [<ffffffff8801ad3c>] :usbcore:usb_add_hcd+0x4eb/0x562
 [<ffffffff880230cf>] :usbcore:usb_hcd_pci_probe+0x1e6/0x28f
 [<ffffffff802f4f5e>] pci_device_probe+0x4c/0x75
 [<ffffffff8034f250>] pci_bus_probe_wrapper+0x86/0x92
 [<ffffffff802f4e48>] pci_match_device+0x13/0xbd
 [<ffffffff8803d000>] :uhci_hcd:uhci_start+0x21e/0x3c0
 [<ffffffff802f4f06>] pci_bus_match+0x14/0x20
 [<ffffffff80346048>] driver_probe_device+0x52/0xa8
 [<ffffffff80346177>] __driver_attach+0x6d/0xaa
 [<ffffffff8034610a>] __driver_attach+0x0/0xaa
 [<ffffffff80345a49>] bus_for_each_dev+0x43/0x6e
 [<ffffffff803456a7>] bus_add_driver+0x7e/0x130
 [<ffffffff802f50f9>] __pci_register_driver+0x57/0x7d
 [<ffffffff8804305c>] :uhci_hcd:uhci_hcd_init+0x5c/0x97
 [<ffffffff8024b1f5>] sys_init_module+0x16cc/0x1883
 [<ffffffff8020a518>] system_call+0x68/0x6d
 [<ffffffff8020a4b0>] system_call+0x0/0x6d


Code: 48 8b 40 18 48 8b b8 f0 01 00 00 e9 52 db ff ff 41 56 41 55
RIP  [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
 RSP <ffff8800eeb6fc50>
CR2: 0000000000000018
 Killed

[-- Attachment #1.2: Type: text/html, Size: 5276 bytes --]

[-- Attachment #2: boottrace.txt --]
[-- Type: text/plain, Size: 16160 bytes --]

 \ \/ /___ _ __   |___ /| || |     _   _ _ __  ___| |_ __ _| |__ | | ___ 
  \  // _ \ '_ \    |_ \| || |_ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | |  ___) |__   _|__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_| |____(_) |_|     \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
                                                                         
(XEN) Xen version 3.4-unstable (xxx@xxx.xxx.xxx) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) Thu Jan 22 12:06:54 EST 2009
(XEN) Latest ChangeSet: Thu Jan 22 11:07:32 2009 +0000 19067:a92ed09b4032
(XEN) Command line: com1=9600,8n1 console=com1 iommu=1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009e800 (usable)
(XEN)  000000000009e800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bfae1000 (usable)
(XEN)  00000000bfae1000 - 00000000bfb24000 (ACPI NVS)
(XEN)  00000000bfb24000 - 00000000bfd42000 (reserved)
(XEN)  00000000bfd42000 - 00000000bfd43000 (ACPI NVS)
(XEN)  00000000bfd43000 - 00000000bfd48000 (reserved)
(XEN)  00000000bfd48000 - 00000000bfd50000 (ACPI data)
(XEN)  00000000bfd50000 - 00000000bfd6b000 (ACPI NVS)
(XEN)  00000000bfd6b000 - 00000000bfd8a000 (reserved)
(XEN)  00000000bfd8a000 - 00000000bfd90000 (ACPI NVS)
(XEN)  00000000bfd90000 - 00000000bff00000 (usable)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000013c000000 (usable)
(XEN) System RAM: 4027MB (4124604kB)
(XEN) ACPI: RSDP 000F03C0, 0024 (r2  INTEL)
(XEN) ACPI: XSDT BFD4EE18, 005C (r1 INTEL  DQ45CB         43 MSFT    10013)
(XEN) ACPI: FACP BFD4DD98, 00F4 (r4  INTEL    A M I  6222004 MSFT    10013)
(XEN) ACPI: DSDT BFD48018, 4EFD (r1 INTEL  DQ45CB         43 INTL 20051117)
(XEN) ACPI: FACS BFD56F40, 0040
(XEN) ACPI: APIC BFD4DF18, 006C (r2 INTEL  DQ45CB         43 MSFT    10013)
(XEN) ACPI: MCFG BFD58E18, 003C (r1 INTEL  DQ45CB         43 MSFT       97)
(XEN) ACPI: ASF! BFD57D18, 00A0 (r32 INTEL  DQ45CB         43 TFSM    F4240)
(XEN) ACPI: SPCR BFD58D18, 0050 (r1 INTEL  DQ45CB         43 AMI.        3)
(XEN) ACPI: TCPA BFD58C98, 0032 (r2 INTEL  DQ45CB         43 MSFT  1000013)
(XEN) ACPI: DMAR BFD42F18, 00D8 (r1 INTEL  DQ45CB         43 INTL        1)
(XEN) Domain heap initialised
(XEN) Processor #0 7:7 APIC version 20
(XEN) Processor #1 7:7 APIC version 20
(XEN) Processor #2 7:7 APIC version 20
(XEN) Processor #3 7:7 APIC version 20
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Intel VT-d has been enabled
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2499.770 MHz processor.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN) HVM: VMX enabled
(XEN) CPU0: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz stepping 07
(XEN) Booting processor 1/1 eip 8c000
(XEN) CPU1: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz stepping 07
(XEN) Booting processor 2/2 eip 8c000
(XEN) CPU2: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz stepping 07
(XEN) Booting processor 3/3 eip 8c000
(XEN) CPU3: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz stepping 07
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) checking TSC synchronization across 4 CPUs: passed.
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Brought up 4 CPUs
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) mtrr: your CPUs had inconsistent fixed MTRR settings
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, lsb, paddr 0xffffffff80200000 -> 0xffffffff805bf88c
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000134000000->0000000136000000 (970253 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff80200000->ffffffff805bf88c
(XEN)  Init. ramdisk: ffffffff805c0000->ffffffff80956400
(XEN)  Phys-Mach map: ffffffff80957000->ffffffff810ce068
(XEN)  Start info:    ffffffff810cf000->ffffffff810cf4b4
(XEN)  Page tables:   ffffffff810d0000->ffffffff810dd000
(XEN)  Boot stack:    ffffffff810dd000->ffffffff810de000
(XEN)  TOTAL:         ffffffff80000000->ffffffff81400000
(XEN)  ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 108kB init memory.
kernel direct mapping tables up to ef60d000 @ 10e0000-1861000
Bootdata ok (command line is root=/dev/sda2 ro xencons=ttyS console=tty0 console=ttyS0)
Linux version 2.6.18.8-xen (root@amber) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Thu Jan 22 12:02:23 EST 2009
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 00000000ef60d000 (usable)
DMI 2.4 present.
No mptable found.
  >>> ERROR: Invalid checksum
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Setting APIC routing to xen
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at c0000000 (gap: bff00000:3ee1c000)
Built 1 zonelists.  Total pages: 967088
Kernel command line: root=/dev/sda2 ro xencons=ttyS console=tty0 console=ttyS0
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Xen reported: 2499.770 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Software IO TLB enabled: 
 Aperture:     64 megabytes
 Kernel range: ffff880005a7a000 - ffff880009a7a000
 Address size: 27 bits
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Memory: 3764092k/3921972k available (2027k kernel code, 149244k reserved, 887k data, 180k init)
Calibrating delay using timer specific routine.. 5000.60 BogoMIPS (lpj=25003009)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 256
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20060707
SMP alternatives: switching to SMP code
Initializing CPU#1
Initializing CPU#2
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
Brought up 4 CPUs
Initializing CPU#3
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 3
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 2
migration_cost=9
checking if image is initramfs... it is
Freeing initrd memory: 3673k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 *7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 7 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
(XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=4
(XEN) ioapic_guest_write: old_entry=000009f1, new_entry=000109f1
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
pnp: PnP ACPI: found 10 devices
xen_mem: Initialising balloon driver.
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
pnp: 00:02: ioport range 0xa20-0xa3f has been reserved
pnp: 00:02: ioport range 0xa00-0xa1f has been reserved
pnp: 00:02: ioport range 0xb78-0xb7f has been reserved
pnp: 00:02: ioport range 0xf78-0xf7f has been reserved
pnp: 00:09: ioport range 0x400-0x47f could not be reserved
pnp: 00:09: ioport range 0x1180-0x119f has been reserved
pnp: 00:09: ioport range 0x500-0x57f has been reserved
PCI: Bridge: 0000:00:01.0
  IO window: d000-dfff
  MEM window: c0000000-d00fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: d0100000-d01fffff
  PREFETCH window: disabled.
GSI 16 sharing vector 0xA8 and IRQ 16
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
IA-32 Microcode Update Driver: v1.14a-xen <tigran@veritas.com>
audit: initializing netlink socket (disabled)
audit(1232672414.325:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
0000:00:1a.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
Xen virtual console successfully installed as ttyS0
Event-channel device installed.
netfront: Initialising virtual ethernet driver.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 1
NET: Registered protocol family 17
ACPI: (supports S0 S1 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Freeing unused kernel memory: 180k freed
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [   AMI] OemTableId [     IST] [20060707]
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 0 initialization completed
ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 1 initialization completed
ACPI: CPU2 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 2 initialization completed
ACPI: CPU3 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 3 initialization completed
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1a.0: UHCI Host Controller
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000e0e0
(XEN) [VT-D]iommu.c:721: iommu_page_fault: iommu->reg = ffff828bfff55000
(XEN) [VT-D]iommu.c:693: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:675: iommu_fault:DMA Read: 0:1a.0 addr bf7ed000 REASON 6 iommu->reg = ffff828bfff55000
(XEN) print_vtd_entries: iommu = ffff8300bfef10f0 bdf = 0:1a:0 gmfn = bf7ed
(XEN)     root_entry = ffff83013bdea000
(XEN)     root_entry[0] = 1374a0001
(XEN)     context = ffff8301374a0000
(XEN)     context[d0] = 101_13bde6001
(XEN)     l3 = ffff83013bde6000
(XEN)     l3_index = 2
(XEN)     l3[2] = 137a83003
(XEN)     l2 = ffff830137a83000
(XEN)     l2_index = 1fb
(XEN)     l2[1fb] = 137887003
(XEN)     l1 = ffff830137887000
(XEN)     l1_index = 1ed
(XEN)     l1[1ed] = 0
(XEN)     l1[1ed] not present
uhci_hcd 0000:00:1a.0: host system error, PCI problems?
uhci_hcd 0000:00:1a.0: host controller halted, very bad!
uhci_hcd 0000:00:1a.0: HC died; cleaning up
usb usb1: configuration #1 chosen from 1 choice
usb usb1: can't set config #1, error -108
uhci_hcd 0000:00:1a.0: HC died; cleaning up
Unable to handle kernel NULL pointer dereference at 0000000000000018 RIP: 
 [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
PGD ef053067 PUD ef051067 PMD 0 
Oops: 0000 [1] SMP 
CPU 3 
Modules linked in: uhci_hcd usbcore thermal processor fan
Pid: 496, comm: insmod Not tainted 2.6.18.8-xen #1
RIP: e030:[<ffffffff88019be9>]  [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
RSP: e02b:ffff8800eeb6fc50  EFLAGS: 00010002
RAX: 0000000000000000 RBX: ffff8800eed03c00 RCX: ffffffffff578000
RDX: ffffffffff578000 RSI: 0000000000000001 RDI: ffff8800ef03e000
RBP: 0000000000000000 R08: 000000000000000e R09: 0000000000000001
R10: ffff8800ef052570 R11: ffffffff80300885 R12: ffff8800eecb01c8
R13: 0000000000000000 R14: ffff8800ef03e000 R15: ffff8800eecb0070
FS:  00002ad0ef6c66d0(0000) GS:ffffffff804d9180(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process insmod (pid: 496, threadinfo ffff8800eeb6e000, task ffff8800eec867a0)
Stack:  ffffffff8801a39b 0000000000000012 ffff8800ef03e000 ffff8800eed03c00
 ffffffff8801ad3c 0000001000000004 ffff8800eecb00e0 ffff8800eed03c00
 ffff8800eecb0000 0000000000000004 ffffffff8803d4a0 0000000000000000
Call Trace:
 [<ffffffff8801a39b>] :usbcore:usb_hc_died+0x5f/0x72
 [<ffffffff8801ad3c>] :usbcore:usb_add_hcd+0x4eb/0x562
 [<ffffffff880230cf>] :usbcore:usb_hcd_pci_probe+0x1e6/0x28f
 [<ffffffff802f4f5e>] pci_device_probe+0x4c/0x75
 [<ffffffff8034f250>] pci_bus_probe_wrapper+0x86/0x92
 [<ffffffff802f4e48>] pci_match_device+0x13/0xbd
 [<ffffffff8803d000>] :uhci_hcd:uhci_start+0x21e/0x3c0
 [<ffffffff802f4f06>] pci_bus_match+0x14/0x20
 [<ffffffff80346048>] driver_probe_device+0x52/0xa8
 [<ffffffff80346177>] __driver_attach+0x6d/0xaa
 [<ffffffff8034610a>] __driver_attach+0x0/0xaa
 [<ffffffff80345a49>] bus_for_each_dev+0x43/0x6e
 [<ffffffff803456a7>] bus_add_driver+0x7e/0x130
 [<ffffffff802f50f9>] __pci_register_driver+0x57/0x7d
 [<ffffffff8804305c>] :uhci_hcd:uhci_hcd_init+0x5c/0x97
 [<ffffffff8024b1f5>] sys_init_module+0x16cc/0x1883
 [<ffffffff8020a518>] system_call+0x68/0x6d
 [<ffffffff8020a4b0>] system_call+0x0/0x6d


Code: 48 8b 40 18 48 8b b8 f0 01 00 00 e9 52 db ff ff 41 56 41 55 
RIP  [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
 RSP <ffff8800eeb6fc50>
CR2: 0000000000000018
 Killed


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: (no subject)

[James Harper]

> 
> Does anybody know if Storport is supported on XEN?  I only see
references
> to SCSIPORT (i.e xenscsi.sys).
> 

If you are referring to the gplpv drivers, then I have only developed
with scsiport at the moment. Storport is only supported under 2003 and
later and I didn't want to maintain two versions of the same code. I'm
not yet convinced that storport will give any noticeable advantage over
scsiport for what we are doing.

xenvbd (scsi emulation of block device) and xenscsi (pvscsi scsi
passthrough) are both scsiport drivers, but xenscsi doesn't work at the
moment as it only worked with a slightly modified version of the 3.2
version of pvscsi. It will be incompatible with the 3.3 version. I will
update it once I get 3.3 installed on my dev box (waiting for some
Debian packages).

Thanks

James

(no subject)

[Bowen, Clair]

[-- Attachment #1.1: Type: text/plain, Size: 126 bytes --]

Does anybody know if Storport is supported on XEN?  I only see references to SCSIPORT (i.e xenscsi.sys).

Regards,

CJ


[-- Attachment #1.2: Type: text/html, Size: 4277 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Swapna Shingre]

[-- Attachment #1.1: Type: text/plain, Size: 167 bytes --]

hi all,
  can anyone tell me what exactly the iret hypercall does?
and, is there any way to disable the fast system call handlers and use
normal system call handling?

[-- Attachment #1.2: Type: text/html, Size: 204 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[James Song]

I test stubdom in xen-3.3.1, when I start it,  just see the message bellow using "xm li" . It seems stubdom haven't start. 

Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   964     2     r-----     34.8
hvmachine                                    1  1024     1     ------      0.0

   the two config files : 
#hvmachine
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory =  256
name = "hvmachine"
vcpus=2
vif = [ 'type=ioemu, bridge=eth0' ]
device_model = '/usr/lib/xen/bin/stubdom-dm'
boot="cd"
sdl=0
opengl=0
vnc=1
vnclisten="172.30.206.1"
stdvga=0
-------------------------------------------------------------------------


#hvmachine-dm
kernel = "/usr/lib/xen/boot/ioemu-stubdom.gz"
vif = [ 'ip=172.30.206.1', 'bridge=eth0,mac=00:16:3e:21:a2:94' ]
disk = [ 'file:/home/images/opensuse11-2/disk0,hda,w' ]



what's wrong I make?


best regards,
-- James

Re: (no subject)

[pradeep singh rautela]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 6/11/07, Gautham Kampalapur Shankar, TLS, Chennai  wrote:
>
>
>
>
>  How xen bus and xen store works ? How they related to each other ?
Gautham you are supposed to use a proper subject for a prompt reply.

thanks

- --
- ---
pradeep singh rautela

"Genius is 1% inspiration, and 99% perspiration" - not me :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org

iD8DBQFGbSmLky6Gd9lpXlERAu12AJ4kdzmyofihA5fmShaCuNbQv5z+ZQCePElh
JA4gh+llY+9GVInFabWvVHw=
=UC9B
-----END PGP SIGNATURE-----

(no subject)

[Gautham Kampalapur Shankar, TLS, Chennai]

[-- Attachment #1: Type: text/html, Size: 420 bytes --]

[-- Attachment #2: Type: text/plain, Size: 984 bytes --]

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Timo Benk]

Hi,

i am using two domains, which are internally connected by one virtual interface.

xendom1: Backend Domain without a physical interface
xendom2: normal Domain-U using xendom1 as a vif-Backend-Domain

 ---------      ---------
| xendom1 |    | xendom2 |
|         |    |         |
|  vif2.0--------eth0    |
|         |    |         |
 ---------      ---------

Then i add another virtual interface to xendom2.

 ---------      ---------
| xendom1 |    | xendom2 |
|         |    |         |
|  vif2.0--------eth0    |
|         |    |         |
|  vif2.1--------eth1    |
|         |    |         |
 ---------      ---------

Domain-0:~ # xm network-attach xendom2 backend=xendom1
                script=vif-nothing

---<snip>---
# /etc/xen/script/vif-nothing in Domain xendom1
dir=$(dirname "$0")
. "$dir/vif-common.sh"

success
---<snap>---

Then i save both domains:

Domain-0:~ # xm save xendom2
Domain-0:~ # xm save xendom1
Error: /usr/lib/xen/bin/xc_save 17 4 0 0 0 failed
Usage: xm save <Domain> <CheckpointFile>

Save a domain state to restore later.

Domain-0:~ # xm list
Name                       ID Mem(MiB) VCPUs State   Time(s)
Domain-0                   0      985     2 r-----     62.5
Zombie-migrating-xendom2   5      512     1 ---s-d     18.0
xendom1                    4      128     1 ---s--     19.6

Both domains are not reachable anymore, i need to destroy xendom1 and xendom2 lives another life as a zombie domain :-(

Greetings,
-timo
-- 
Timo Benk - B1 Systems GmbH (http://www.b1-systems.de)
Jabber ID: fry@jabber.org - ICQ ID: #241877854
PGP Public Key: http://m28s01.vlinux.de/b1_gpg_key.asc

(no subject)

[Li, Xin B]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

on x86_64, when guest has more than 2G memory, "startx" will cause qemu
dm die, this patch fixes it.

Signed-off-by: Xin Li <xin.b.li@intel.com>

diff -r ecb8ff1fcf1f tools/ioemu/hw/vga.c
--- a/tools/ioemu/hw/vga.c  Fri Jul 14 18:53:27 2006 +0100
+++ b/tools/ioemu/hw/vga.c  Mon Jul 17 22:35:54 2006 +0800
@@ -1392,7 +1392,8 @@ static void vga_draw_graphic(VGAState *s
 static void vga_draw_graphic(VGAState *s, int full_update)
 {
     int y1, y, update, page_min, page_max, linesize, y_start,
double_scan, mask;
-    int width, height, shift_control, line_offset, page0, page1,
bwidth;
+    int width, height, shift_control, line_offset, bwidth;
+    ram_addr_t page0, page1;
     int disp_width, multi_scan, multi_run;
     uint8_t *d;
     uint32_t v, addr1, addr;

[-- Attachment #2: vga.patch --]
[-- Type: application/octet-stream, Size: 621 bytes --]

diff -r ecb8ff1fcf1f tools/ioemu/hw/vga.c
--- a/tools/ioemu/hw/vga.c	Fri Jul 14 18:53:27 2006 +0100
+++ b/tools/ioemu/hw/vga.c	Mon Jul 17 22:35:54 2006 +0800
@@ -1392,7 +1392,8 @@ static void vga_draw_graphic(VGAState *s
 static void vga_draw_graphic(VGAState *s, int full_update)
 {
     int y1, y, update, page_min, page_max, linesize, y_start, double_scan, mask;
-    int width, height, shift_control, line_offset, page0, page1, bwidth;
+    int width, height, shift_control, line_offset, bwidth;
+    ram_addr_t page0, page1;
     int disp_width, multi_scan, multi_run;
     uint8_t *d;
     uint32_t v, addr1, addr;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[vineet chadha]

Hi,

Compiling xen-3.0.2.2 on host redhat 2.4.18 kernel I am getting following error:


make[2]: Entering directory `/root/software/xen-3.0.2-2'
if grep "^CONFIG_MODULES=" linux-2.6.16-xen/.config ; then \
    make -C linux-2.6.16-xen ARCH=i386 modules ; \
    make -C linux-2.6.16-xen ARCH=i386
INSTALL_MOD_PATH=/root/software/xen-3.0.2-2/dist/install
modules_install ; \
fi
CONFIG_MODULES=y
make[3]: Entering directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
  CHK     include/linux/version.h
  Building modules, stage 2.
  MODPOST
make[3]: Leaving directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
make[3]: Entering directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
Warning: you may need to install module-init-tools
See http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt
rm: invalid option -- x
Try `rm --help' for more information.
make[3]: *** [_modinst_] Error 1
make[3]: Leaving directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
make[2]: *** [build] Error 2
make[2]: Leaving directory `/root/software/xen-3.0.2-2'
make[1]: *** [linux-2.6-xen-install] Error 2
make[1]: Leaving directory `/root/software/xen-3.0.2-2'
make: *** [install-kernels] Error 1

Please help
-John

(no subject)

[Kevin Tronkowski]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

Attached is a patch which extends vmxassist to handle two cases 
related to mode switching found while experimenting with different 
boot loaders.

The first case is use of the JMP instruction with memory location 
operands to complete a switch to protected mode. This patch adds 
emulation for this form of the JMP instruction to vmxassist.

The second case is where boot loader code does not save/restore a 
non-zero SS register across a protected mode traversal. 
Zeroing the SS register in vmxassist results in all sorts of problems 
in the domU after returning back to real mode. This patch stores 
segment register values before entering protected mode and correctly 
restores the old values (instead of an incorrect zero value) when 
reentering real mode. 

Signed-off-by Kevin Tronkowski <ktronkowski@virtualiron.com>

Kevin


[-- Attachment #2: vm86.patch --]
[-- Type: application/octet-stream, Size: 4282 bytes --]

diff -r 6993a0f91efc tools/firmware/vmxassist/vm86.c
--- a/tools/firmware/vmxassist/vm86.c	Thu Jun  1 18:10:00 2006 +0100
+++ b/tools/firmware/vmxassist/vm86.c	Thu Jun  1 16:40:28 2006 -0400
@@ -36,6 +36,8 @@
 
 static unsigned prev_eip = 0;
 enum vm86_mode mode = 0;
+
+static struct regs saved_rm_regs;
 
 #ifdef DEBUG
 int traceset = 0;
@@ -795,6 +797,8 @@ protected_mode(struct regs *regs)
 	oldctx.esp = regs->uesp;
 	oldctx.eflags = regs->eflags;
 
+	memset(&saved_rm_regs, 0, sizeof(struct regs));
+
 	/* reload all segment registers */
 	if (!load_seg(regs->cs, &oldctx.cs_base,
 				&oldctx.cs_limit, &oldctx.cs_arbytes))
@@ -808,6 +812,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.es_base,
 			    &oldctx.es_limit, &oldctx.es_arbytes);
 		oldctx.es_sel = 0;
+		saved_rm_regs.ves = regs->ves;
 	}
 
 	if (load_seg(regs->uss, &oldctx.ss_base,
@@ -817,6 +822,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.ss_base,
 			    &oldctx.ss_limit, &oldctx.ss_arbytes);
 		oldctx.ss_sel = 0;
+		saved_rm_regs.uss = regs->uss;
 	}
 
 	if (load_seg(regs->vds, &oldctx.ds_base,
@@ -826,6 +832,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.ds_base,
 			    &oldctx.ds_limit, &oldctx.ds_arbytes);
 		oldctx.ds_sel = 0;
+		saved_rm_regs.vds = regs->vds;
 	}
 
 	if (load_seg(regs->vfs, &oldctx.fs_base,
@@ -835,6 +842,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.fs_base,
 			    &oldctx.fs_limit, &oldctx.fs_arbytes);
 		oldctx.fs_sel = 0;
+		saved_rm_regs.vfs = regs->vfs;
 	}
 
 	if (load_seg(regs->vgs, &oldctx.gs_base,
@@ -844,6 +852,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.gs_base,
 			    &oldctx.gs_limit, &oldctx.gs_arbytes);
 		oldctx.gs_sel = 0;
+		saved_rm_regs.vgs = regs->vgs;
 	}
 
 	/* initialize jump environment to warp back to protected mode */
@@ -880,16 +889,22 @@ real_mode(struct regs *regs)
 		if (regs->uss >= HIGHMEM)
 			panic("%%ss 0x%lx higher than 1MB", regs->uss);
 		regs->uss = address(regs, regs->uss, 0) >> 4;
+	} else {
+	  regs->uss = saved_rm_regs.uss;
 	}
 	if (regs->vds != 0) {
 		if (regs->vds >= HIGHMEM)
 			panic("%%ds 0x%lx higher than 1MB", regs->vds);
 		regs->vds = address(regs, regs->vds, 0) >> 4;
+	} else {
+	  regs->vds = saved_rm_regs.vds;
 	}
 	if (regs->ves != 0) {
 		if (regs->ves >= HIGHMEM)
 			panic("%%es 0x%lx higher than 1MB", regs->ves);
 		regs->ves = address(regs, regs->ves, 0) >> 4;
+	} else {
+	  regs->ves = saved_rm_regs.ves;
 	}
 
 	/* this should get us into 16-bit mode */
@@ -971,6 +986,39 @@ jmpl(struct regs *regs, int prefix)
 	} else if (mode == VM86_PROTECTED_TO_REAL) { /* jump to real mode */
 		eip = (prefix & DATA32) ? fetch32(regs) : fetch16(regs);
 		cs = fetch16(regs);
+
+		TRACE((regs, (regs->eip - n) + 1, "jmpl 0x%x:0x%x", cs, eip));
+
+                regs->cs = cs;
+                regs->eip = eip;
+		set_mode(regs, VM86_REAL);
+	} else
+		panic("jmpl");
+}
+
+static void
+jmpl_indirect(struct regs *regs, int prefix, unsigned modrm)
+{
+	unsigned n = regs->eip;
+	unsigned cs, eip;
+	unsigned addr;
+
+	addr  = operand(prefix, regs, modrm);
+
+	if (mode == VM86_REAL_TO_PROTECTED) { /* jump to protected mode */
+		eip = (prefix & DATA32) ? read32(addr) : read16(addr);
+		addr += (prefix & DATA32) ? 4 : 2;
+		cs = read16(addr);
+
+		TRACE((regs, (regs->eip - n) + 1, "jmpl 0x%x:0x%x", cs, eip));
+
+                regs->cs = cs;
+                regs->eip = eip;
+		set_mode(regs, VM86_PROTECTED);
+	} else if (mode == VM86_PROTECTED_TO_REAL) { /* jump to real mode */
+		eip = (prefix & DATA32) ? read32(addr) : read16(addr);
+		addr += (prefix & DATA32) ? 4 : 2;
+		cs = read16(addr);
 
 		TRACE((regs, (regs->eip - n) + 1, "jmpl 0x%x:0x%x", cs, eip));
 
@@ -1306,6 +1354,23 @@ opcode(struct regs *regs)
 			}
 			goto invalid;
 
+		case 0xFF: /* jmpl (indirect) */
+			if ((mode == VM86_REAL_TO_PROTECTED) ||
+			    (mode == VM86_PROTECTED_TO_REAL)) {
+			 	unsigned modrm = fetch8(regs);
+				
+				switch((modrm >> 3) & 7) {
+				case 5:
+				  jmpl_indirect(regs, prefix, modrm);
+				  return OPC_INVALID;
+
+				default:
+				  break;
+				}
+
+			}
+			goto invalid;
+
 		case 0xEB: /* short jump */
 			if ((mode == VM86_REAL_TO_PROTECTED) ||
 			    (mode == VM86_PROTECTED_TO_REAL)) {

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Nivedita Singhvi]

[-- Attachment #1.1: Type: text/plain, Size: 913 bytes --]





Hello!

Just wanted to let everyone know Jiuxing  has populated a mercurial
tree (very kindly hosted by XenSource) with his code at the following site:

http://xenbits.xensource.com/ext/xen-smartio.hg

This contains the current source code for a xen infiniband frontend
and backend driver. The source code is in very preliminary stages
of development, just a proof of concept for now (works). We have
a long way to go.  We'd like to invite interested folks to take a look
and get involved in the continuing design and development as an
open-source community.

We will be putting up a Wiki page for this shortly on the Xen Wiki.
Stay tuned...

There is also a mailing list we set up for discussion on
virtualization of smart I/O in Xen at:

http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-smartio

However, at Ian's request we're going to contain most discussion
to xen-devel itself.


thanks,
Nivedita

[-- Attachment #1.2: Type: text/html, Size: 1194 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(no subject)

[Li, Xin B]

Leendert, when I'm reading the vmxassist code, I think we need this
patch, can you take a look for me?
Thanks
-Xin

diff -r 47013962e411 tools/firmware/vmxassist/setup.c
--- a/tools/firmware/vmxassist/setup.c  Fri Feb 10 02:23:36 2006
+++ b/tools/firmware/vmxassist/setup.c  Fri Feb 10 15:28:17 2006
@@ -363,7 +363,7 @@

        initialize_real_mode = 1;
        cr0 = get_cr0();
-#ifndef TEST
+#ifdef TEST
        set_cr0(cr0 | CR0_PE);
 #endif
        set_cr0(cr0 & ~CR0_PE);

(no subject)

[Purav Saraiya]

I am facing problems with debugging DomU.

I have made changes in the gdt table in the file head.S for Dom U. Because
of that the domain is crashing.

For debugging, I followed the steps mentioned in the file
/xen-unstable/tools/debugger/gdb/README. I also made changes in the
/xen/Rules.mk file and compiled domU with -g C flag.

However, as mentioned in the README file no
/var/xen/dump/<Domain-name>.<DomainID>.core file is generated.

Rules.mk file :
verbose     ?= y
debug       ?= y
perfc       ?= n
perfc_arrays?= n
domu_debug  ?= y
crash_debug ?= y

Am I missing something?

Thanks for replies.
-Purav

(no subject)

[Prashanth Radhakrishnan]

> Yes, I'm still working on it.  The focus of that work was copy-on-write
> sharing of memory for the purposes of building a (virtual) network of
> honeypot systems.  We have a paper in SOSP this year, talking about that
> work and the copy-on-write memory implementation.  See
>     http://www.cs.ucsd.edu/~mvrable/papers/2005-sosp-potemkin.pdf
> for some information.
>
> I'm presently working on updating and cleaning that work up.
>
> --Michael Vrable

Thanks for the info, Michael. Just wondering if this code has been checked 
into the Xen-unstable branch, or around when it would be checked in.
(I din't find any related checkin by searching at 
http://lists.xensource.com/archives/html/xen-changelog/)

thanks again,
prashanth

(no subject)

[Li, Chengyuan]

[-- Attachment #1: Type: text/plain, Size: 244 bytes --]


Set guest selectors to be null if it's not valid when switch to
protected-mode in the guest firmware.

Signed-off-by: Chengyuan Li <chengyuan.li@intel.com>
Signed-off-by: Asit Mallick <asit.k.mallick@intel.com>


Thanks,
Chengyuan


[-- Attachment #2: vmxassist_selector.patch --]
[-- Type: application/octet-stream, Size: 2097 bytes --]

diff -r f069a06e650f tools/firmware/vmxassist/vm86.c
--- a/tools/firmware/vmxassist/vm86.c	Wed Sep 28 21:18:30 2005
+++ b/tools/firmware/vmxassist/vm86.c	Thu Sep 29 12:59:36 2005
@@ -470,10 +470,21 @@
 	unsigned long long entry;
 
 	/* protected mode: use seg as index into gdt */
-	if (sel == 0 || sel > oldctx.gdtr_limit)
+	if (sel > oldctx.gdtr_limit)
 		return 0;
 
+    if (sel == 0) {
+        arbytes->fields.null_bit = 1;
+        return 1;
+    }
+
 	entry =  ((unsigned long long *) oldctx.gdtr_base)[sel >> 3];
+
+    /* Check the P bit fisrt*/
+    if (!((entry >> (15+32)) & 0x1) && sel != 0) {
+        return 0;
+    }
+
 	*base =  (((entry >> (56-24)) & 0xFF000000) |
 		  ((entry >> (32-16)) & 0x00FF0000) |
 		  ((entry >> (   16)) & 0x0000FFFF));
@@ -519,22 +530,42 @@
 	if (load_seg(regs->ves, &oldctx.es_base,
 				&oldctx.es_limit, &oldctx.es_arbytes))
 		oldctx.es_sel = regs->ves;
+    else {
+        load_seg(0, &oldctx.es_base,&oldctx.es_limit, &oldctx.es_arbytes);
+        oldctx.es_sel = 0;
+    }
 
 	if (load_seg(regs->uss, &oldctx.ss_base,
 				&oldctx.ss_limit, &oldctx.ss_arbytes))
 		oldctx.ss_sel = regs->uss;
+    else {
+        load_seg(0, &oldctx.ss_base, &oldctx.ss_limit, &oldctx.ss_arbytes);
+        oldctx.ss_sel = 0;
+    }
 
 	if (load_seg(regs->vds, &oldctx.ds_base,
 				&oldctx.ds_limit, &oldctx.ds_arbytes))
 		oldctx.ds_sel = regs->vds;
+    else {
+        load_seg(0, &oldctx.ds_base, &oldctx.ds_limit, &oldctx.ds_arbytes);
+        oldctx.ds_sel = 0;
+    }
 
 	if (load_seg(regs->vfs, &oldctx.fs_base,
 				&oldctx.fs_limit, &oldctx.fs_arbytes))
 		oldctx.fs_sel = regs->vfs;
+    else {
+        load_seg(0, &oldctx.fs_base, &oldctx.fs_limit, &oldctx.fs_arbytes);
+        oldctx.fs_sel = 0;
+    }
 
 	if (load_seg(regs->vgs, &oldctx.gs_base,
 				&oldctx.gs_limit, &oldctx.gs_arbytes))
 		oldctx.gs_sel = regs->vgs;
+    else {
+        load_seg(0, &oldctx.gs_base, &oldctx.gs_limit, &oldctx.gs_arbytes);
+        oldctx.gs_sel = 0;
+    }
 
 	/* initialize jump environment to warp back to protected mode */
 	regs->cs = CODE_SELECTOR;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: (no subject)

[Christian Limpach]

On 9/23/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> Oops, I tried it only using a cross-compiler.  When I compiled
> natively on ia64, it is still necessary to specify
> LINUX_ARCH=ia64 on the make-line, else I get x86 configs.
>
> I think the fix is to change in buildconfig/Rules.mk from
>
> ifneq ($(ARCH),ia64)
>  to
> ifneq ($(XEN_TARGET_ARCH),ia64)
>
> I'll roll this fix in at the next merge with xen-ia64-unstable.

Yes, thanks!

    christian

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

> -----Original Message-----
> From: Magenheimer, Dan (HP Labs Fort Collins) 
> Sent: Wednesday, September 21, 2005 2:50 PM
> To: 'Christian Limpach'
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] (no subject)
> 
> > > I suppose it would be nice if on ia64 just 'make' did the
> > > right thing, e.g. set LINUX_ARCH=ia64 without the need to
> > > specify it on the command line.  In that case, adding it
> > > to all the calls to mkbuildtree is necessary.  How do
> > > I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
> > > if x86 (or x86_64) and the architecture it is running on
> > > (e.g. ia64) otherwise?
> > 
> > I'll check it in tomorrow, and I'll make it set LINUX_ARCH
> > dependent on ARCH, like you did in your original patch...
> 
> Thanks very much!  I tried it and it works great!  Using
> this, I have started committing files into the ia64 subdirs
> of -sparse in xen-ia64-unstable.hg which will be pulled
> into the xen-unstable tree at the next sync.  I have already
> built and tested a "driver-less" domain0 from -sparse.

Oops, I tried it only using a cross-compiler.  When I compiled
natively on ia64, it is still necessary to specify
LINUX_ARCH=ia64 on the make-line, else I get x86 configs.

I think the fix is to change in buildconfig/Rules.mk from

ifneq ($(ARCH),ia64)
  to
ifneq ($(XEN_TARGET_ARCH),ia64)

I'll roll this fix in at the next merge with xen-ia64-unstable.

Thanks,
Dan

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

> > I suppose it would be nice if on ia64 just 'make' did the
> > right thing, e.g. set LINUX_ARCH=ia64 without the need to
> > specify it on the command line.  In that case, adding it
> > to all the calls to mkbuildtree is necessary.  How do
> > I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
> > if x86 (or x86_64) and the architecture it is running on
> > (e.g. ia64) otherwise?
> 
> I'll check it in tomorrow, and I'll make it set LINUX_ARCH
> dependent on ARCH, like you did in your original patch...

Thanks very much!  I tried it and it works great!  Using
this, I have started committing files into the ia64 subdirs
of -sparse in xen-ia64-unstable.hg which will be pulled
into the xen-unstable tree at the next sync.  I have already
built and tested a "driver-less" domain0 from -sparse.

Dan

Re: (no subject)

[Christian Limpach]

On Mon, Sep 19, 2005 at 01:52:36PM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > Rules.mk is fine.  What I meant is that LINUX_ARCH won't get
> > passed to mkbuildtree unless you add it to its environment.
> > I confirmed this now by adding this to mkbuildtree:
> > echo ${LINUX_ARCH} >>/tmp/xxxxxxxx
> > LINUX_ARCH is empty and thus your hook script won't run.  Maybe
> > you have LINUX_ARCH set in your shell environment where you ran
> > make?  Odd...
> 
> No, it's not in my shell environment.  However, when I run make
> to build for ia64 I run it as: 'make LINUX_ARCH=ia64 ...' and
> I'm guessing make must export it to subshells.  If I add the
> 'echo', I do get ia64 in /tmp/xxxxxx and the ia64 hook scripts
> do get run.

Yes, that explains it.

> I suppose it would be nice if on ia64 just 'make' did the
> right thing, e.g. set LINUX_ARCH=ia64 without the need to
> specify it on the command line.  In that case, adding it
> to all the calls to mkbuildtree is necessary.  How do
> I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
> if x86 (or x86_64) and the architecture it is running on
> (e.g. ia64) otherwise?

I'll check it in tomorrow, and I'll make it set LINUX_ARCH
dependent on ARCH, like you did in your original patch...

Thanks!

    christian

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

> > > You have to export LINUX_ARCH to the script.  We don't want to
> > > unconditionally polute the environment of all the commands we
> > > run, so you'll have to add it to all the calls to mkbuildtree.
> > 
> > I'm not sure I follow... I don't know exactly how make or bash
> > work wrt to exporting... I didn't explicitly export LINUX_ARCH
> > but it seems to be known by mkbuildtree and all the mk.linux's
> > anyway.  (I successfully built for x86 and ia64 with the
> > patch.)
> > 
> > Or are you suggesting I *not* define it in buildconfigs/Rules.mk
> > so as to avoid polluting the environment?
> 
> Rules.mk is fine.  What I meant is that LINUX_ARCH won't get
> passed to mkbuildtree unless you add it to its environment.
> I confirmed this now by adding this to mkbuildtree:
> echo ${LINUX_ARCH} >>/tmp/xxxxxxxx
> LINUX_ARCH is empty and thus your hook script won't run.  Maybe
> you have LINUX_ARCH set in your shell environment where you ran
> make?  Odd...

No, it's not in my shell environment.  However, when I run make
to build for ia64 I run it as: 'make LINUX_ARCH=ia64 ...' and
I'm guessing make must export it to subshells.  If I add the
'echo', I do get ia64 in /tmp/xxxxxx and the ia64 hook scripts
do get run.

But if I build (for xen/x86) with just 'make', nothing gets
echoed to the file and, as you pointed out, no hook script
gets run.  But that's the default behavior we want, correct?

I suppose it would be nice if on ia64 just 'make' did the
right thing, e.g. set LINUX_ARCH=ia64 without the need to
specify it on the command line.  In that case, adding it
to all the calls to mkbuildtree is necessary.  How do
I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
if x86 (or x86_64) and the architecture it is running on
(e.g. ia64) otherwise?

So I think the patch is OK as is... I've built successfully
for both x86 and ia64... but I can still change it and
resubmit if you prefer the other way.

Thanks,
Dan

Re: (no subject)

[Christian Limpach]

On Mon, Sep 19, 2005 at 12:20:41PM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > > OK, I see.  This cleans it up nicely. New patch attached.
> > 
> > You have to export LINUX_ARCH to the script.  We don't want to
> > unconditionally polute the environment of all the commands we
> > run, so you'll have to add it to all the calls to mkbuildtree.
> 
> I'm not sure I follow... I don't know exactly how make or bash
> work wrt to exporting... I didn't explicitly export LINUX_ARCH
> but it seems to be known by mkbuildtree and all the mk.linux's
> anyway.  (I successfully built for x86 and ia64 with the
> patch.)
> 
> Or are you suggesting I *not* define it in buildconfigs/Rules.mk
> so as to avoid polluting the environment?

Rules.mk is fine.  What I meant is that LINUX_ARCH won't get
passed to mkbuildtree unless you add it to its environment.
I confirmed this now by adding this to mkbuildtree:
echo ${LINUX_ARCH} >>/tmp/xxxxxxxx
LINUX_ARCH is empty and thus your hook script won't run.  Maybe
you have LINUX_ARCH set in your shell environment where you ran
make?  Odd...

> That's OK with me.  If enlightenment (is that a bad word in
> Xen land now?) from the above requires me to re-generate
> the patch, I will change the names.

Cheers!

   christian

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

> > > Please define LINUX_ARCH in buildconfigs/Rules.mk and use 
> that where
> > > we run make ARCH=xen.
> > > If you can name your config file xen0_defconfig_ia64 and use
> > > LINUX_ARCH for the path, then you won't need to duplicate 
> the config
> > > file code.
> > 
> > OK, I see.  This cleans it up nicely. New patch attached.
> 
> You have to export LINUX_ARCH to the script.  We don't want to
> unconditionally polute the environment of all the commands we
> run, so you'll have to add it to all the calls to mkbuildtree.

I'm not sure I follow... I don't know exactly how make or bash
work wrt to exporting... I didn't explicitly export LINUX_ARCH
but it seems to be known by mkbuildtree and all the mk.linux's
anyway.  (I successfully built for x86 and ia64 with the
patch.)

Or are you suggesting I *not* define it in buildconfigs/Rules.mk
so as to avoid polluting the environment?
 
> I think I'd prefer xen-mkbuildtree-{pre,post} as the name of 
> the scripts
> to run, but not too fussed about that...

That's OK with me.  If enlightenment (is that a bad word in
Xen land now?) from the above requires me to re-generate
the patch, I will change the names.

Thanks!
Dan

Re: (no subject)

[Christian Limpach]

On Mon, Sep 19, 2005 at 09:49:05AM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > Please define LINUX_ARCH in buildconfigs/Rules.mk and use that where
> > we run make ARCH=xen.
> > If you can name your config file xen0_defconfig_ia64 and use
> > LINUX_ARCH for the path, then you won't need to duplicate the config
> > file code.
> 
> OK, I see.  This cleans it up nicely. New patch attached.

You have to export LINUX_ARCH to the script.  We don't want to
unconditionally polute the environment of all the commands we
run, so you'll have to add it to all the calls to mkbuildtree.

I think I'd prefer xen-mkbuildtree-{pre,post} as the name of the scripts
to run, but not too fussed about that...

> Do the changes have no impact to non-Xen non-x86 kernels?
> Since xenlinux/ia64 is transparently paravirtualized,
> the changes looked like they might be xen-specific, and
> xenlinux/ia64 has been running out-of-tree without any
> of those changes, the script moves them aside.  If there's
> no impact, I can move them back in (but will probably
> do so slowly for testing purposes).
> 
> In any case, drivers/xen definitely is not yet fully
> archdep, so I need to use the pre- or post-mkbuildtree
> to do some patching in the short term.  Agree in the longer
> term, these files should be empty but if you don't mind
> greatly, having the archdep hooks there will probably
> make things easier for arch's for now.

Ok, let's go with the pre/post link scripts for now, but I think
it would be good to make our changes work when building non-x86/non-xen.

    christian

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

> > > Why are you piping in tons of nothing into Make here 
> using the "yes"
> > > command?
> > 
> > This mechanically does the same as manually hitting
> > "enter" at every prompt from "make oldconfig", thus it
> > applies the default response for every unconfigured
> > option without manual intervention.
> 
> I think it's preferable to have default config files which don't cause
> any prompting.
> 
> Also if people upgrade, they probably want to be prompted on any new
> options.  If not, then let's get the default behaviour for "make
> oldconfig" changed upstream...

I've just used this for convenience.  The defconfigs in
Linux/ia64 cause prompting and the config change required for
Xen/ia64 support (because it is transparently paravirtualized)
is adding "CONFIG_XEN=y".  But I can easily put the output
of make oldconfig in the xen defconfig file if the
preference is to have no prompting (thus the "yes" pipe
is removed from the previously posted patch).

Thanks,
Dan

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

(Sorry about the "no subject" in the original message...
fat fingers on my part.)

> Please define LINUX_ARCH in buildconfigs/Rules.mk and use that where
> we run make ARCH=xen.
> If you can name your config file xen0_defconfig_ia64 and use
> LINUX_ARCH for the path, then you won't need to duplicate the config
> file code.

OK, I see.  This cleans it up nicely. New patch attached.

> Please also change all mk.linux files.

Done.

> > 2) A sequence of mkbuildtree "massage" commands need to
> >   be executed before mkbuildtree does its linking thing.
> >   Perhaps this could be done as:
> >    if -e mkbuildtree.prelink.$XENARCH
> >        mkbuildtree.prelink.$XENARCH
> >   Though ia64 doesn't need it, maybe also add a "postlink"
> >   equivalent?
> 
> Why do you need to move these out of the way in the first place?  If
> any of the changes we've made break ia64, then we should cleanup our
> changes.

Do the changes have no impact to non-Xen non-x86 kernels?
Since xenlinux/ia64 is transparently paravirtualized,
the changes looked like they might be xen-specific, and
xenlinux/ia64 has been running out-of-tree without any
of those changes, the script moves them aside.  If there's
no impact, I can move them back in (but will probably
do so slowly for testing purposes).

In any case, drivers/xen definitely is not yet fully
archdep, so I need to use the pre- or post-mkbuildtree
to do some patching in the short term.  Agree in the longer
term, these files should be empty but if you don't mind
greatly, having the archdep hooks there will probably
make things easier for arch's for now.

> > Could someone with the necessary build knowledge make
> > the improvements and commit this please? Let me know if/when
> > it goes in and I will populate the ia64 -sparse branches.
> 
> Please give creating a patch another try, taking the suggestions above
> into consideration.  Thanks!

OK, let me know if this is better.

Thanks,
Dan

[-- Attachment #2: xenia64sparse2 --]
[-- Type: application/octet-stream, Size: 7395 bytes --]

diff -r ec01850d0ee9 buildconfigs/Rules.mk
--- a/buildconfigs/Rules.mk	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/Rules.mk	Mon Sep 19 10:45:52 2005
@@ -14,6 +14,9 @@
 # Setup pristine search path
 PRISTINE_SRC_PATH	?= .:..
 vpath pristine-% $(PRISTINE_SRC_PATH)
+
+# By default, build Linux with ARCH=xen (overridden by some non arch's)
+LINUX_ARCH	?= xen
 
 # Expand Linux series to Linux version
 LINUX_SERIES	?= 2.6
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.4-xenU
--- a/buildconfigs/mk.linux-2.4-xenU	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.4-xenU	Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -36,16 +36,16 @@
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
-	make -C $(LINUX_DIR) ARCH=xen oldconfig
-	make -C $(LINUX_DIR) ARCH=xen dep
+	make -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
+	make -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) dep
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen dep
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) dep
 
 clean::
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.6-xen
--- a/buildconfigs/mk.linux-2.6-xen	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.6-xen	Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -38,14 +38,14 @@
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
 
 clean::
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.6-xen0
--- a/buildconfigs/mk.linux-2.6-xen0	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.6-xen0	Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -38,14 +38,14 @@
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
 
 clean::
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.6-xenU
--- a/buildconfigs/mk.linux-2.6-xenU	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.6-xenU	Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -38,14 +38,14 @@
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
 
 clean::
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r ec01850d0ee9 linux-2.6-xen-sparse/mkbuildtree
--- a/linux-2.6-xen-sparse/mkbuildtree	Mon Sep 19 15:21:09 2005
+++ b/linux-2.6-xen-sparse/mkbuildtree	Mon Sep 19 10:45:52 2005
@@ -89,6 +89,11 @@
 abs_to_rel ${AD} ${AS}
 RS=$DESTPATH
 
+# Arch-specific pre-processing
+if [ -x arch/${LINUX_ARCH}/xen-pre-mkbuildtree ]; then
+	arch/${LINUX_ARCH}/xen-pre-mkbuildtree
+fi
+
 # Remove old copies of files and directories at the destination
 for i in `find . -type f -o -type l` ; do rm -f ${AD}/${i#./} ; done
 
@@ -110,3 +115,10 @@
 
 cd ${AD}/include/asm-xen/linux-public
 ln -sf ../../../${RS}/../tools/xenstore/xenstored.h
+
+# Arch-specific post-processing
+cd ${AD}
+if [ -x arch/${LINUX_ARCH}/xen-post-mkbuildtree ]; then
+	arch/${LINUX_ARCH}/xen-post-mkbuildtree
+fi
+

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: (no subject)

[Christian Limpach]

On 9/19/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> > On Mon, 2005-09-19 at 06:43 -0700, Magenheimer, Dan (HP Labs Fort
> > Collins) wrote:
> >
> > > +ifeq ($(ARCH),ia64)
> > > +       yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> > > +else
> >
> > Why are you piping in tons of nothing into Make here using the "yes"
> > command?
> 
> This mechanically does the same as manually hitting
> "enter" at every prompt from "make oldconfig", thus it
> applies the default response for every unconfigured
> option without manual intervention.

I think it's preferable to have default config files which don't cause
any prompting.

Also if people upgrade, they probably want to be prompted on any new
options.  If not, then let's get the default behaviour for "make
oldconfig" changed upstream...

    christian

Re: (no subject)

[Mark Williamson]

> Collins) wrote:
> > +ifeq ($(ARCH),ia64)
> > +       yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> > +else
>
> Why are you piping in tons of nothing into Make here using the "yes"
> command?

I guess, to answer <ret> (choose default) to any questions oldconfig throws 
up.

Cheers,
Mark

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

> On Mon, 2005-09-19 at 06:43 -0700, Magenheimer, Dan (HP Labs Fort
> Collins) wrote:
> 
> > +ifeq ($(ARCH),ia64)
> > +       yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> > +else
> 
> Why are you piping in tons of nothing into Make here using the "yes"
> command? 

This mechanically does the same as manually hitting
"enter" at every prompt from "make oldconfig", thus it
applies the default response for every unconfigured
option without manual intervention.

Dan

Re: (no subject)

[Jerone Young]

On Mon, 2005-09-19 at 06:43 -0700, Magenheimer, Dan (HP Labs Fort
Collins) wrote:

> +ifeq ($(ARCH),ia64)
> +       yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> +else

Why are you piping in tons of nothing into Make here using the "yes"
command? 

-- 
Jerone Young
IBM Linux Technology Center
jyoung5@us.ibm.com
512-838-1157 (T/L: 678-1157)

Re: (no subject)

[Christian Limpach]

On 9/19/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> The primary changes are:
> 1) wherever a make is done with ARCH=xen, this needs
>   to be converted to ARCH=ia64.  (This can probably
>   be done as ARCH=$(XENARCH) or something like that
>   but I'm not sure how to do it without requiring x86
>   and x86_64 builds to specify XENARCH= at build time.)

Please define LINUX_ARCH in buildconfigs/Rules.mk and use that where
we run make ARCH=xen.
If you can name your config file xen0_defconfig_ia64 and use
LINUX_ARCH for the path, then you won't need to duplicate the config
file code.
Please also change all mk.linux files.

> 2) A sequence of mkbuildtree "massage" commands need to
>   be executed before mkbuildtree does its linking thing.
>   Perhaps this could be done as:
>    if -e mkbuildtree.prelink.$XENARCH
>        mkbuildtree.prelink.$XENARCH
>   Though ia64 doesn't need it, maybe also add a "postlink"
>   equivalent?

Why do you need to move these out of the way in the first place?  If
any of the changes we've made break ia64, then we should cleanup our
changes.

> Could someone with the necessary build knowledge make
> the improvements and commit this please? Let me know if/when
> it goes in and I will populate the ia64 -sparse branches.

Please give creating a patch another try, taking the suggestions above
into consideration.  Thanks!

    christian

(no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

Attached is an (ugly but relatively simple) patch that allows
Xenlinux/ia64 to be built using the linux "-sparse" tree
methodology (once I populate some files in the -sparse tree).

The changes are not dramatic and I think they can be done
much more cleanly, but I'm not a build expert so would
appreciate improvements from those more comfortable with
the Xen build environment... and perhaps it can be
made more generic so the ppc guys can benefit too.

The primary changes are:
1) wherever a make is done with ARCH=xen, this needs
   to be converted to ARCH=ia64.  (This can probably
   be done as ARCH=$(XENARCH) or something like that
   but I'm not sure how to do it without requiring x86
   and x86_64 builds to specify XENARCH= at build time.)
2) A sequence of mkbuildtree "massage" commands need to
   be executed before mkbuildtree does its linking thing.
   Perhaps this could be done as:
    if -e mkbuildtree.prelink.$XENARCH
        mkbuildtree.prelink.$XENARCH
   Though ia64 doesn't need it, maybe also add a "postlink"
   equivalent?

There is also one change because the ia64 defconfig filename
is different.  I can change this filename to conform with
the existing convention but perhaps the defconfig pathname
could be set as part of the prelink file?

Could someone with the necessary build knowledge make
the improvements and commit this please? Let me know if/when
it goes in and I will populate the ia64 -sparse branches.

Thanks,
Dan

[-- Attachment #2: xenia64sparse --]
[-- Type: application/octet-stream, Size: 3406 bytes --]

diff -r 8d133d172bfd buildconfigs/mk.linux-2.6-xen0
--- a/buildconfigs/mk.linux-2.6-xen0	Sun Sep 18 18:18:57 2005
+++ b/buildconfigs/mk.linux-2.6-xen0	Sun Sep 18 14:31:47 2005
@@ -14,11 +14,19 @@
 
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
+ifeq ($(ARCH),ia64)
+	$(MAKE) -C $(LINUX_DIR) ARCH=ia64 INSTALL_PATH=$(DESTDIR) install
+	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=ia64 modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=ia64 INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	fi
+else
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
 	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
 	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
 	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+endif
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -27,25 +35,45 @@
 	( cd linux-$(LINUX_SERIES)-xen-sparse ; \
           ./mkbuildtree ../$(LINUX_DIR) )
 	# Re-use config from install dir if one exits else use default config
+ifeq ($(ARCH),ia64)
+	CONFIG_VERSION=$$(sed -ne 's/^EXTRAVERSION = //p' $(LINUX_DIR)/Makefile); \
+	[ -r $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) ] && \
+	  cp $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) $(LINUX_DIR)/.config \
+	  || cp $(LINUX_DIR)/arch/ia64/configs/xen_zx1_defconfig \
+		$(LINUX_DIR)/.config
+else
 	CONFIG_VERSION=$$(sed -ne 's/^EXTRAVERSION = //p' $(LINUX_DIR)/Makefile); \
 	[ -r $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) ] && \
 	  cp $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) $(LINUX_DIR)/.config \
 	  || cp $(LINUX_DIR)/arch/xen/configs/$(EXTRAVERSION)_defconfig_$(XEN_TARGET_ARCH) \
 		$(LINUX_DIR)/.config
+endif
 	# See if we need to munge config to enable PAE
 	$(MAKE) CONFIG_FILE=$(LINUX_DIR)/.config -f buildconfigs/Rules.mk config-update-pae
 	# Patch kernel Makefile to set EXTRAVERSION
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
+ifeq ($(ARCH),ia64)
+	yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
+else
 	$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+endif
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
+ifeq ($(ARCH),ia64)
+	$(MAKE) -C $(LINUX_DIR) $(CONFIGMODE)
+else
 	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+endif
 
 clean::
+ifeq ($(ARCH),ia64)
+	$(MAKE) -C $(LINUX_DIR) ARCH=ia64 clean
+else
 	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+endif
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r 8d133d172bfd linux-2.6-xen-sparse/mkbuildtree
--- a/linux-2.6-xen-sparse/mkbuildtree	Sun Sep 18 18:18:57 2005
+++ b/linux-2.6-xen-sparse/mkbuildtree	Sun Sep 18 14:31:47 2005
@@ -92,6 +92,16 @@
 # Remove old copies of files and directories at the destination
 for i in `find . -type f -o -type l` ; do rm -f ${AD}/${i#./} ; done
 
+if [ "$ARCH" = "ia64" ]; then
+mv arch/xen/kernel drivers/xen/core
+mv mm mm.x86
+mv net net.x86
+mv kernel kernel.x86
+mv arch/xen arch/xen.x86
+mv include/asm-generic include/asm-generic.x86
+mv include/linux include/linux.x86
+fi
+
 # We now work from the destination directory
 cd ${AD} || { echo "cannot cd to ${AD}"; exit 1; }
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Igor Feoktistov]

Hi,

has anybody tried linux-iscsi-4.0.2 with linux-2.6.11-xen0?
scsi-transport-iscsi failed to compile due to different structure
definitions in scsi_transport_iscsi.h
Using scsi-transport-iscsi from linux-2.6.11-xen0 distro I was able
to open iscsi session. However, there is tons of kernel errors like below.
Any ideas how to cure it?
--
Jul  5 15:18:31 iscsi-rh4u1 kernel: SCSI device sdc: 73400320 512-byte hdwr sectors (375
Jul  5 15:18:31 iscsi-rh4u1 kernel: Badness in local_bh_enable at kernel/softirq.c:140  
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c011e495>] local_bh_enable+0x68/0x89             
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c896a742>] iscsi_queuecommand+0x173/0x1e3 [iscsi_
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c029c2f8>] scsi_dispatch_cmd+0x140/0x22e         
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c029c53a>] scsi_done+0x0/0x26                    
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c029ebdb>] scsi_times_out+0x0/0xa0               
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a19de>] scsi_request_fn+0x234/0x452           
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c0227bda>] __elv_add_request+0x84/0xb1           
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c022a708>] blk_insert_request+0xd7/0x104         
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a05aa>] scsi_insert_special_req+0x3a/0x40     
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a07f2>] scsi_wait_req+0x69/0x9b               
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a06ef>] scsi_wait_done+0x0/0x9a               
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a1e1d>] __scsi_mode_sense+0xc7/0x286          
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c0119be3>] vprintk+0x140/0x1b7                   
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030fc98>] sd_read_cache_type+0x5f/0x216         
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c029bce8>] scsi_allocate_request+0x28/0x62       
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030ff48>] sd_revalidate_disk+0xf9/0x131         
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030fe4f>] sd_revalidate_disk+0x0/0x131          
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030ea83>] sd_open+0x0/0xf0                      
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c0185201>] rescan_partitions+0xdd/0x103          
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030ea83>] sd_open+0x0/0xf0                      
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c015b05c>] do_open+0x2a7/0x390                   
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c015b1c8>] blkdev_get+0x83/0x8e                  

(no subject)

[Reiner Sailer]

> Message: 4
> Date: Sat, 25 Jun 2005 19:21:21 -0500
> From: Anthony Liguori <aliguori@us.ibm.com>
> Subject: Re: [Xen-devel] [PATCH] 1 of 2: default ssid to 0
> To: Stefan Berger <stefanb@us.ibm.com>
> Cc: xen-devel@lists.xensource.com
> Message-ID: <42BDF501.4090502@us.ibm.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Please make sure to increment the DOM0_INTERFACE_VERSION when this is 
> committed.

Correct. The DOM0 interface treats "non-existing" ssidref configurations 
now
differently (sets them to 0 instead of ffffffff).

> 
> Anthony Liguori
> 
> Stefan Berger wrote:

Thanks
Reiner

(no subject)

[田冠华]

Hello ，
    I am interested in Xen project,but  I am a stranger .
    I think it is helpful to read  the emails which the other participationers have posted .
    Could you post me some emails in which other people discussed about Xen project



Best wishes
　　　　　　　　tianguanhua@ncic.ac.cn
　　　　　　　　　　2005-04-28

(no subject)

[田冠华]

Hello ，
    I am interested in Xen project,but  I am a stranger .
    I have got the code of Xen project,but there is no explanation in the lines ,I can not understand the code ,

    Could you give me a document about  software construction of Xen project ,including how many modules ,how these modules are organised and etc.

   Who have designed the CPU modules ,can you shou me a light on how you organise the CPU modules?



Best wishes
　　　　　　　　tianguanhua@ncic.ac.cn
　　　　　　　　　　2005-04-28

Re: (no subject)

[Keir Fraser]

On 18 Apr 2005, at 17:43, tarawa1943@comcast.net wrote:

> Thank you sir, I will check that. I did do another build with 12apr05 
> xen-unstable and it did not have the same symptom/problem, 
> xen-unstable changed around 16-17apr05, to expose this symptom on a 
> thinkpad. Will look deeper.

Not that much has been checked in since then. You could try backing out 
the local APIC code changes (checked in on 16th April) but even that 
seems unlikely to break the floppy driver, I think.

  -- Keir

(no subject)

[tarawa1943]

Ian

Thank you sir, I will check that. I did do another build with 12apr05 xen-unstable and it did not have the same symptom/problem, xen-unstable changed around 16-17apr05, to expose this symptom on a thinkpad. Will look deeper.

woody
========================================
Date: Mon, 18 Apr 2005 10:26:16 +0100
From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk>
Subject: RE: [Xen-devel] "Floppy drive(s): fd0 is 1.44M" 
To: <tarawa1943@comcast.net>,	<xen-devel@lists.xensource.com>
Cc: christopher.w.clark@gmail.com
Message-ID:
	<A95E2296287EAD4EB592B5DEEFCE0E9D1E3BF4@liverpoolst.ad.cl.cam.ac.uk>
Content-Type: text/plain;	charset="us-ascii"


> Subject: [Xen-devel] "Floppy drive(s): fd0 is 1.44M" 
> 
> Thanks for your response, and how would you suggest that one 
> would fix that?
> It hangs in the boot process!

Have you tried messing with the 'floppy=' parameter on the kernel
command line?
See Documentation/floppy.txt

Alternatively, just config the driver out of your kernel, to confirm
that this is what is causing the hang.

We use the floppy driver in PIO rather than DMA mode, and this is must
be causing the probe code to get confused under some circumstances.
(thinkpad floppy drives are somewhat notorious, and there's lots of work
arounds in the probe code)

Ian

RE: (no subject)

[Ian Pratt]

> ps: I decided to split out these patches, and send upstream, 
> before uploading
>     my deb packages.  If possible, I'd like to have these 
> applied, and a new
>     version rolled based on them.

I like all the patches. Any comments from anyone else?

I guess there's enough fixes in 2.0-testing to warrant a release,  but
I'd like to leave all the patches in testing for a couple of days to get
exercised. 

Ian


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

(no subject)

[Adam Heath]

===
Name: proper-depends.patch
Description: Use proper targets in makefiles
 A rule in make should produce only what it's target allows.  When it
 produces side-effects, things like ctrl-c and parallellism break it
 oddly.
DiffStat:
 xen/Makefile              |    9 +++++----
 xen/arch/x86/Makefile     |   14 ++++++++++----
 xen/common/Makefile       |    3 ++-
 xen/drivers/acpi/Makefile |    3 ++-
 xen/drivers/char/Makefile |    3 ++-
 xen/drivers/pci/Makefile  |    3 ++-
 6 files changed, 23 insertions(+), 12 deletions(-)
===
Description: Use proper targets in makefiles
 A rule in make should produce only what it's target allows.  When it
 produces side-effects, things like ctrl-c and parallellism break it
 oddly.

--- xen-2.0.3.orig/xen/arch/x86/Makefile
+++ xen-2.0.3/xen/arch/x86/Makefile
@@ -12,12 +12,18 @@

 OBJS := $(subst $(TARGET_SUBARCH)/asm-offsets.o,,$(OBJS))

-default: boot/$(TARGET_SUBARCH).o $(OBJS) boot/mkelf32
-	$(LD) $(LDFLAGS) -r -o arch.o $(OBJS)
-	$(LD) $(LDFLAGS) -T $(TARGET_SUBARCH)/xen.lds -N \
-	    boot/$(TARGET_SUBARCH).o $(ALL_OBJS) -o $(TARGET)-syms
+default: $(TARGET)
+
+$(TARGET): $(TARGET)-syms boot/mkelf32
 	./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000

+$(CURDIR)/arch.o: $(OBJS)
+	$(LD) $(LDFLAGS) -r -o $@ $(OBJS)
+
+$(TARGET)-syms: boot/$(TARGET_SUBARCH).o $(ALL_OBJS) $(TARGET_SUBARCH)/xen.lds
+	$(LD) $(LDFLAGS) -T $(TARGET_SUBARCH)/xen.lds -N \
+	    boot/$(TARGET_SUBARCH).o $(ALL_OBJS) -o $@
+
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
 	$(CC) $(CFLAGS) -S -o $@ $<

--- xen-2.0.3.orig/xen/common/Makefile
+++ xen-2.0.3/xen/common/Makefile
@@ -19,7 +19,8 @@
 OBJS := $(subst trace.o,,$(OBJS))
 endif

-default: $(OBJS)
+default: common.o
+common.o: $(OBJS)
 	$(LD) $(LDFLAGS) -r -o common.o $(OBJS)

 clean:
--- xen-2.0.3.orig/xen/drivers/pci/Makefile
+++ xen-2.0.3/xen/drivers/pci/Makefile
@@ -28,7 +28,8 @@
 #obj-y += syscall.o
 #endif

-default: $(OBJS)
+default: driver.o
+driver.o: $(OBJS)
 	$(LD) $(LDFLAGS) -r -o driver.o $(OBJS)

 clean:
--- xen-2.0.3.orig/xen/drivers/char/Makefile
+++ xen-2.0.3/xen/drivers/char/Makefile
@@ -1,7 +1,8 @@

 include $(BASEDIR)/Rules.mk

-default: $(OBJS)
+default: driver.o
+driver.o: $(OBJS)
 	$(LD) $(LDFLAGS) -r -o driver.o $(OBJS)

 clean:
--- xen-2.0.3.orig/xen/drivers/acpi/Makefile
+++ xen-2.0.3/xen/drivers/acpi/Makefile
@@ -6,7 +6,8 @@

 OBJS := acpi_ksyms.o tables.o

-default: $(OBJS)
+default: driver.o
+driver.o: $(OBJS)
 	$(LD) $(LDFLAGS) -r -o driver.o $(OBJS)

 clean:
--- xen-2.0.3.orig/xen/Makefile
+++ xen-2.0.3/xen/Makefile
@@ -9,14 +9,15 @@

 include Rules.mk

-default: $(TARGET)
-	gzip -f -9 < $(TARGET) > $(TARGET).gz
+default: $(TARGET).gz
+$(TARGET).gz: $(TARGET)
+	gzip -f -9 < $< > $@.new
+	mv $@.new $@

 debug:
 	objdump -D -S $(TARGET)-syms > $(TARGET).s

-install: $(TARGET)
-	gzip -f -9 < $(TARGET) > $(TARGET).gz
+install: $(TARGET).gz
 	mkdir -p $(prefix)/boot
 	install -m0644 $(TARGET).gz $(prefix)/boot
 	install -m0644 $(TARGET)-syms $(prefix)/boot




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

(no subject)

[Adam Heath]

I spent last night and this morning splitting the single patch I had, into 13
separate patches.  Most are build system tweaks(DESTDIR, parallel make,
INSTALL, proper target depends).  Also, proper PIC support in the libs, and a
few other things.

Below is the meta-info that my patch oriented build system maintains.  I'll be
sending each patch as a separate mail(I apologize for the mail flood ahead of
time).

ps: I decided to split out these patches, and send upstream, before uploading
    my deb packages.  If possible, I'd like to have these applied, and a new
    version rolled based on them.

pps: These are generated against 2.0.3.

===
Name: proper-depends.patch
Description: Use proper targets in makefiles
 A rule in make should produce only what it's target allows.  When it
 produces side-effects, things like ctrl-c and parallellism break it
 oddly.
DiffStat:
 xen/Makefile              |    9 +++++----
 xen/arch/x86/Makefile     |   14 ++++++++++----
 xen/common/Makefile       |    3 ++-
 xen/drivers/acpi/Makefile |    3 ++-
 xen/drivers/char/Makefile |    3 ++-
 xen/drivers/pci/Makefile  |    3 ++-
 6 files changed, 23 insertions(+), 12 deletions(-)

Name: pic-lib.patch
Description: support PIC code generation
 Libraries have 2 methods of being compiled; a .so must contain non-pic
 objects, while the .a can contain standard objects.
DiffStat:
 tools/libxc/Makefile    |   34 +++++++++++++++++++++-------------
 tools/libxutil/Makefile |   11 ++++++++---
 2 files changed, 29 insertions(+), 16 deletions(-)

Name: doc-make-vars.patch
Description: Use vars for complex programs
 It's generally standard to call complex programs indirectly thru make
 variables.  This allows them to be replaced easily with alternative
 versions, without editting each makefile.
 .
 Additionally, this patch makes use of $(pkgdocdir) in docs/Makefile.
DiffStat:
 docs/Makefile |   53 +++++++++++++++++++++++++++++++++++------------------
 1 files changed, 35 insertions(+), 18 deletions(-)

Name: INSTALL.patch
Depends: proper-depends.patch, pic-lib.patch, doc-make-vars.patch
Description: use INSTALL everywhere
 Use install(by way of INSTALL variables) to create directories, install
 programs, and install data files.
DiffStat:
 Makefile                     |   22 +++++++++++++---------
 docs/Makefile                |   10 ++++++----
 tools/examples/Makefile      |   20 ++++++++++++--------
 tools/libxc/Makefile         |   12 ++++++++----
 tools/libxutil/Makefile      |    9 +++++++--
 tools/misc/Makefile          |   11 +++++++----
 tools/misc/miniterm/Makefile |    7 +++++--
 tools/sv/Makefile            |   18 ++++++++++--------
 tools/xentrace/Makefile      |   16 ++++++++++------
 tools/xfrd/Makefile          |    8 ++++++--
 xen/Makefile                 |   17 ++++++++++-------
 11 files changed, 94 insertions(+), 56 deletions(-)

Name: bash-for-mkbuildtree.patch
Description: mkbuildtree requires bash
DiffStat:
 linux-2.4.28-xen-sparse/mkbuildtree |    2 +-
 linux-2.6.10-xen-sparse/mkbuildtree |    2 +-
 netbsd-2.0-xen-sparse/mkbuildtree   |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

Name: parallel-make.patch
Depends: INSTALL.patch, proper-depends.patch
Description: support parallellism better
 Using shell for loops doesn't allow make to run it the most parallel
 modes.  Use patsubst/addsuffix tricks to make this work.
DiffStat:
 Makefile     |   60 +++++++++++++++++++++++------------------------------------
 xen/Makefile |    9 +++-----
 2 files changed, 28 insertions(+), 41 deletions(-)

Name: init-script-force-reload.patch
Description: add force-reload option
 Debian policy requires init scripts to implement force-reload.  So, alias
 that to restart.
DiffStat:
 tools/examples/init.d/xend |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Name: fhs-paths.patch
Depends: INSTALL.patch
Description: Use FHS-compatible paths
DiffStat:
 tools/python/xen/sv/params.py     |    4 ++--
 tools/python/xen/xend/XendRoot.py |    2 +-
 tools/sv/Makefile                 |    2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

Name: linux-2.4-modules.patch
Description: conditionally call modules targets for 2.4
 There was a complaint on the mailing list about linux 2.6 not building
 if module support was disabled; a patch was done to fix this.  However,
 the same change was not done to the 2.4 files.
DiffStat:
 buildconfigs/mk.linux-2.4-xen0 |    6 ++++--
 buildconfigs/mk.linux-2.4-xenU |    6 ++++--
 2 files changed, 8 insertions(+), 4 deletions(-)

Name: python-path.patch
Description: fix path to python
 There is no python2 in debian.  Instead, use python.
DiffStat:
 tools/python/xen/xend/server/SrvServer.py |    2 +-
 tools/python/xen/xend/sxp.py              |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Name: prefix-DESTDIR.patch
Depends: INSTALL.patch, doc-make-vars.patch, fhs-paths.patch, linux-2.4-modules.patch, parallel-make.patch, pic-lib.patch, proper-depends.patch
Description: use DESTDIR correctly
 Standard makefiles always attempt to install to the root(/).  Setting
 DESTDIR is the normal way to install to an alternative location.
 .
 Setting prefix has the possibility of breaking programs, as the prefix
 may have been embedded inside a compiled binary.
DiffStat:
 Makefile                       |   11 ++++++-----
 buildconfigs/mk.linux-2.4-xen0 |    4 ++--
 buildconfigs/mk.linux-2.4-xenU |    4 ++--
 buildconfigs/mk.linux-2.6-xen0 |    4 ++--
 buildconfigs/mk.linux-2.6-xenU |    4 ++--
 docs/Makefile                  |   13 +++++++------
 tools/examples/Makefile        |   20 ++++++++++----------
 tools/libxc/Makefile           |   12 ++++++------
 tools/libxutil/Makefile        |    8 ++++----
 tools/misc/Makefile            |    8 ++++----
 tools/misc/miniterm/Makefile   |    4 ++--
 tools/python/Makefile          |    6 ++----
 tools/sv/Makefile              |   14 +++++++-------
 tools/xentrace/Makefile        |   12 ++++++------
 tools/xfrd/Makefile            |    4 ++--
 xen/Makefile                   |   20 ++++++++++----------
 16 files changed, 74 insertions(+), 74 deletions(-)

Name: sane-make-syntax.patch
Depends: INSTALL.patch, parallel-make.patch, prefix-DESTDIR.patch
Description: fix non-standard make/shell syntax
 Fix use of `pwd`, &&, and || true.  Also, remove ().
DiffStat:
 Makefile       |   16 ++++++++--------
 tools/Makefile |    2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

Name: xen-banner.patch
Depends: INSTALL.patch, parallel-make.patch, prefix-DESTDIR.patch, proper-depends.patch
Description: split banner.h
 Split banner.h, to make it easier to edit, and more properly fit in with
 normal build systems.
 .
 Also, inline the rules to actually build figlet.
DiffStat:
 xen/Makefile                 |   50 +++++++++++++++++++++++--------------------
 xen/include/xen/banner.h     |   12 ++++++++++
 xen/include/xen/compile.h.in |   13 +++++++++++
 3 files changed, 52 insertions(+), 23 deletions(-)


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

(no subject)

[M.A. Williamson]

All these problems are to be expected - the guest can't make privileged 
access to the machine's hardware so updating microcode, clock, etc won't 
work. I'm not actually sure what "keytable" does but it doesn't look like 
it's needed ;-), gpm is definitely not needed.

It's nothing to worry about - you should just disable these services so 
that they don't get run. e.g. on Redhat something like

# chkconfig --del servicename

for each service.  Or use you favourite console / GUI admin tool.

As mentioned in another post, the microcode update seems to be trying to 
load the module for the wrong kernel version (which is odd). Even if it 
were the right version, it still wouldn't work...

Cheers,
Mark

> 1) Applying Intel IA32 Microcode update: insmod: 
> /lib/modules/2.6.5-7.97-smp/kernel/arch/i386/kernel/microcode.o: insmod 
> char-major-10-184 failed
> 
> 2) Starting keytable:  Loading keymap: /etc/rc5.d/S17keytable: line 26: 
> /dev/tty0: No such device
> [FAILED]
> 
> 3) Starting console mouse services: gpm: oops() invoked from gpn.c(132) 
> loadlut: is your kernel compiled with CONFIG_SELECTION on?: Invalid 
> argument [FAILED] (This is probably because the initial OS installation 
> was configured to have a graphical interface)
> 
> During Halt:
> 1) Sending all processes the KILL signal...
> Syncing hardware clock to system time modprobe: modprobe: Can't locate 
> module char-major-10-135
> hwclock is unable to get I/O port access:  the iopl(3) call failed.
> 
> Guest OS boots-up and halts fine. (except for the above errors)
> 
> Any suggesstions??
> 
> Thanks,
> 
> Amitabh
> 
> 
> From: "M.A. Williamson" <maw48@cam.ac.uk>
> Reply-To: maw48@cantab.net
> To: "Fajar A. Nugraha" <fajar@telkom.co.id>
> CC: Amitabh Tamhane <amitabh_2k@hotmail.com>, 
> xen-devel@lists.sourceforge.net
> Subject: Re: [Xen-devel] Porting of Guest OS
> Date: 30 Dec 2004 14:50:25 +0000
> 
> > > The exact error I am getting is: Could not find LABLE=/ and boots in 
> > > >
> >the "repair filesystem" mode.
> >
> > that's /etc/fstab allright. Change the line that says LABEL=/ to 
> > /dev/sda1. You might also need to remove the line that mounts /boot For 
> > kernel-2.6-based or nptl-enabled distro, you also need to remove 
> > /lib/tls and /usr/lib/tls on the domain root file system (Xen will tell 
> > you to do this when it boots).
> 
> Using LABEL=blah requires a) you to set the label on the disk file you 
> created b) you to boot with a suitable initrd (e.g. one that came with 
> your distro) to perform the lookup of filesystem labels.
> 
> You will find it easier to get stuff working if you just specify 
> /dev/whatever explicitly in the config file and edit the guest fstab to 
> match.
> 
> > > The guest OS could talk with the outside world but `xm list` command 
> > > >
> >shows state as -b--- (blocked) for the domain I am trying to boot.
> > >
> >Is that what "-b---" means? All my virtual domains shows that, and yet 
> >they're working perfectly.
> 
> If they're not doing work on the CPU at this instant then they're 
> probably blocked - unless they're doing something CPU intensive they'll 
> be in that state a lot.
> 
> If you've only got one CPU then you'll never see another domain in the 
> running state - the fact that dom0 is running at this instant implies 
> that the other domains aren't :-)
> 
> HTH,
> Mark
> 
> 
> 



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

(no subject)

[James Harper]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

  
It's actually xenU I want to test it in (but compiling under xen0), and a make says this:

Note: using kernel source from /lib/modules/2.6.7-xen0/build containing
kernel version 2.6.7

Note: using kernel config from /boot/config-2.6.7-xen0

So i set TOPDIR too, and also had to patch iscsi-id.c to fix these two errors:

iscsi-id.c:90: error: too few arguments to function `sysfs_open_class_device'
iscsi-id.c:94: error: too few arguments to function `sysfs_open_class_device'

by changing the calls to sysfs_open_class_device_path. hope that's the right thing to do. I must have a different version of sysfs (debian version is 1.1.0-1)

'make ARCH=xen' seems to do the right thing, but 'make ARCH=xen install' says:

Installing iSCSI driver for Linux 2.6.7-xen0

doh!

then I replaced all occurences of 'shell uname -r' in the makefile with 'shell echo 2.6.7-xenU'

and it compiles finally. The only problem is that I just did a bk pull and enabled SCSI in xenU, and now the kernel won't compile. i've attached the output of 'make linux26' (but it got rejected so i'm posting it without), the errors are to do with undefined references to 'direct_remap_area_pages'. Do you think that it is to do with the latest bk pull or to do with me enabling device drivers in an unprivileged kernel?

i'll get there eventually!

thanks

James

[-- Attachment #2: Type: text/html, Size: 2362 bytes --]

(no subject)

[Jan van Rensburg]

Brian,

I've done basically the same thing with the Xen FAQ. I've watched the 
list and updated the FAQ as new questions came along. In order to 
centralize the Xen documentation, won't you pull the Xen FAQ into the 
wiki? It can be found here:
http://xen.epiuse.com/xen-faq.txt

Once you're done that I'll replace the FAQ with an automatic redirect 
to your page. The FAQ was last updated about 3 months ago (Sorry 
everybody about that! Work got a bit hectic).

Jan



> Message: 1
> Date: Sun, 18 Apr 2004 12:31:02 -0500 (CDT)
> From: "Brian Wolfe" <brianw@terrabox.com>
> To: xen-devel@lists.sourceforge.net
> Subject: [Xen-devel] xen wiki site available http://xen.terrabox.com
>
> http://xen.terrabox.com
>
> I will attempt to keep the site updated based on the xen-devel list
> traffic. If anyone wants to contribute, feel free. Eventually I will 
> get
> the main sections locked down. But until then, i'm leaving them open so
> that anyone that gets bored can easilly update, correct, etc what I 
> have
> up there.
>
> The ultimate goal of the wiki site is to provide as much information 
> about
> Xen as possible in a format that is easilly understood.
>
> Curent sections planned:
>   Resource links as the homepage (downloads, official docs, Distro
> Packages, FAQs, mailing lists, companies offering xen based hosting)
>   Documentation: Official text files, paginated with cross links, and 
> man
> pages of every program/daemon/config file.
>   Debian Packages: sources.list entries
>   Xen FAQ: Standard paginated faq of common questions from xen-devel.
>   Mailing Lists: list of sites archiving xen mailing lists and
> subscription management links.
>   Companies offering xen hosting: table of company, url, price range, 
> and
> notes.
>
> It is my ultimate goal to provide an easilly maintained resource that 
> will
> serve as the basis of the end user/administrator documentation as well 
> as
> FAQ and other associated resources.
>
> Any advice is desired and welcome, especially considering that I am 
> new to
> phpwiki. :)
>
> -- 
> Brian Wolfe           | Phone 1-(214)-764-1204
> President,            | Email  brianw@terrabox.com
> TerraBox.com Inc.     |



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click