search for: xs_read_watch

...com> --- tools/xenstore/xs.c | 41 ++++++++++++++++++++++++++++++++++++++++- 1 files changed, 40 insertions(+), 1 deletions(-) diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c index b951015..31aad14 100644 --- a/tools/xenstore/xs.c +++ b/tools/xenstore/xs.c @@ -855,14 +855,53 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num) bool xs_unwatch(struct xs_handle *h, const char *path, const char *token) { struct iovec iov[2]; + struct xs_stored_msg *msg, *tmsg; + bool res; + char *strings; + unsigned int num_strings, i; + char c; iov[0].iov_base = (char *)path; iov[0].iov_len...

...ore the reply to the unwatch command. So at the point where the unwatch reply has been processed (after xs_talkv), any such now-deleted watch events will definitely have made it to libxenstore''s queue where we can remove them. As for other threads in the same process: if two threads call xs_read_watch and xs_unwatch, it is acceptable for the xs_read_watch to return the event being deleted. What is not allowed is for an xs_read_watch entered after xs_unwatch returns to return the deleted event, and this code does indeed ensure that. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> S...

Hello all Xen devels, I''m writing howto''s in brazilian portuguese language about Xen-3.3.0 stubdom, pv-grub and others configurations. Following what is written in xen-3.3.0/stubdom/README, I tried start a HVM but without success. When I start the virtual machine calling ''xm create hvmtest'' command, in a few seconds the virtual machine is dead (see

...d. xen_blk: Initialising virtual block device driver Trying to free free IRQ261 vbd: probe of vbd-769 failed with error -2 xen_blk: bind_evtchn_to_irqhandler failed (err=-16) vbd: probe of vbd-770 failed with error -2 XENBUS xs_read_watch: 0 xen_blk: Timeout connecting to device! xen_net: Initialising virtual ethernet driver. vif: probe of vif-0 failed with error -2 XENBUS xs_read_watch: 0 xen_net: Timeout connecting to device! The same linux-2.6 xen0/xenU kernels work f...

.../ - if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1)) - while (read(h->watch_pipe[0], &c, 1) != 1) - continue; - + xs_maybe_clear_watch_pipe(h); mutex_unlock(&h->watch_mutex); assert(msg->hdr.type == XS_WATCH_EVENT); @@ -855,14 +873,66 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num) bool xs_unwatch(struct xs_handle *h, const char *path, const char *token) { struct iovec iov[2]; + struct xs_stored_msg *msg, *tmsg; + bool res; + char *s, *p; + unsigned int i; + char *l_token, *l_path; iov[0].iov_base = (char *)path; iov[0].iov_le...

...df5e76 100644 --- a/tools/xenstore/xenstore.h +++ b/tools/xenstore/xenstore.h @@ -27,6 +27,27 @@ #define XS_OPEN_READONLY 1UL<<0 #define XS_OPEN_SOCKETONLY 1UL<<1 +/* + * Setting XS_UNWATCH_FILTER arranges that after xs_unwatch, no + * related watch events will be delivered via xs_read_watch. But + * this relies on the couple token, subpath is unique. + * + * XS_UNWATCH_FILTER clear XS_UNWATCH_FILTER set + * + * Even after xs_unwatch, "stale" After xs_unwatch returns, no + * instances of the watch event watch events with the same + * may be delivered....

...df5e76 100644 --- a/tools/xenstore/xenstore.h +++ b/tools/xenstore/xenstore.h @@ -27,6 +27,27 @@ #define XS_OPEN_READONLY 1UL<<0 #define XS_OPEN_SOCKETONLY 1UL<<1 +/* + * Setting XS_UNWATCH_FILTER arranges that after xs_unwatch, no + * related watch events will be delivered via xs_read_watch. But + * this relies on the couple token, subpath is unique. + * + * XS_UNWATCH_FILTER clear XS_UNWATCH_FILTER set + * + * Even after xs_unwatch, "stale" After xs_unwatch returns, no + * instances of the watch event watch events with the same + * may be delivered....

...T(xs_fileno(xs), &fdset); - if ((select(xs_fileno(xs) + 1, &fdset, NULL, NULL, &tv)) != 1) { + if ((select(xs_fileno(xs) + 1, &fdset, NULL, NULL, &tv)) != 1) errx(1, "timed out waiting for qemu to switch buffers\n"); - exit(1); - } watch = xs_read_watch(xs, &len); free(watch); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...e variable, which leads to a medium change (even if there isn't any), since we are comparing something like aio:/path/to/file with /path/to/file. This only happens one time, since xenstore_parse_domain_config is the only place where we strip the prefix. The result of this bug is the following: xs_read_watch() -> /local/domain/0/backend/qdisk/19/5632/params hdc close(7) close blk: backend=/local/domain/0/backend/qdisk/19/5632 node=/local/domain/19/device/vbd/5632 (XEN) HVM18: HVM Loader (XEN) HVM18: Detected Xen v4.3-unstable (XEN) HVM18: Xenbus rings @0xfeffc000, event channel 4 (XEN) HVM18: System...

The following series of 10 patches is a merge of the xenfb and xenconsoled functionality into the qemu-dm code. The general approach taken is to have qemu-dm provide two machine types - one for xen paravirt, the other for fullyvirt. For compatability the later is the default. The goals overall are to kill LibVNCServer, remove alot of code duplication and/or parallel impls of the same concepts, and

...medium change (even if there isn''t any), since we are comparing something like aio:/path/to/file with /path/to/file. This only happens one time, since xenstore_parse_domain_config is the only place where we strip the prefix. The result of this bug is the following: xs_read_watch() -> /local/domain/0/backend/qdisk/19/5632/params hdc close(7) close blk: backend=/local/domain/0/backend/qdisk/19/5632 node=/local/domain/19/device/vbd/5632 (XEN) HVM18: HVM Loader (XEN) HVM18: Detected Xen v4.3-unstable (XEN) HVM18: Xenbus rings @0xfeffc000, event chann...

...6.0 - xs_get_domain_path at VERS_4.0 4.16.0 - xs_get_permissions at VERS_4.0 4.16.0 - xs_introduce_domain at VERS_4.0 4.16.0 - xs_is_domain_introduced at VERS_4.0 4.16.0 - xs_mkdir at VERS_4.0 4.16.0 - xs_open at VERS_4.0 4.16.0 - xs_path_is_subpath at VERS_4.0 4.16.0 - xs_read at VERS_4.0 4.16.0 - xs_read_watch at VERS_4.0 4.16.0 - xs_release_domain at VERS_4.0 4.16.0 - xs_restrict at VERS_4.0 4.16.0 - xs_resume_domain at VERS_4.0 4.16.0 - xs_rm at VERS_4.0 4.16.0 - xs_set_permissions at VERS_4.0 4.16.0 - xs_set_target at VERS_4.0 4.16.0 - xs_strings_to_perms at VERS_4.0 4.16.0 - xs_suspend_evtchn_port at...

...%s failed", path); - } else { - path = "/child"; - otherpath = "/parent"; - - if (write(fds[1], "", 1) != 1) - barf_perror("Write to parent failed"); - } - - for (i = 0; i < (argv[1] ? (unsigned)atoi(argv[1]) : 100);) { - char **vec; - - vec = xs_read_watch(h); - if (!vec) - barf_perror("Read watch failed"); - - if (!streq(vec[1], "token")) - barf("Watch token %s bad", vec[1]); - if (streq(vec[0], otherpath)) { - char number[32]; - - data = xs_read(h, otherpath, &len); - if (!data) - barf_perror("...

I''m running Xen3 7775 with udev 073 (which was a PITA to get working, as the initrd I''ve been running for quite some time uses an older one -- but that''s an entirely different story). My dom0 is Gentoo-based. When I try to start a DomU, it times out waiting for hotplug-based notification, as per the following: DEBUG (DevController:69) Waiting for devices vif. DEBUG

I''m running Xen3 7775 with udev 073 (which was a PITA to get working, as the initrd I''ve been running for quite some time uses an older one -- but that''s an entirely different story). My dom0 is Gentoo-based. When I try to start a DomU, it times out waiting for hotplug-based notification, as per the following: DEBUG (DevController:69) Waiting for devices vif. DEBUG

This patch series introduces the tapback daemon, the user space daemon that acts as a device''s back-end, essentially most of blkback in user space. The daemon is responsible for coordinating the front-end and tapdisk. It creates tapdisk process as needed, instructs them to connect to/disconnect from the shared ring, and manages the state of the back-end. The shared ring between the

Changes: tools/blktap: remove unneeded pointer dereferencing in convert_dev_name_to_num tools/blktap: constify string arrays in convert_dev_name_to_num tools/blktap: fix params and physical-device parsing tools/blktap: remove unneeded pointer dereferencing from img2qcow.c tools/blktap: remove unneeded pointer dereferencing from qcow2raw.c tools/blktap2: fix build errors caused by Werror in

...int wait_for_dev_destroy(libxl_ctx *ctx, struct timeval *tv) { + libxl_gc gc = LIBXL_INIT_GC(ctx); int nfds, rc; unsigned int n; fd_set rfds; @@ -262,57 +277,52 @@ int wait_for_dev_destroy(libxl_ctx *ctx, if (select(nfds, &rfds, NULL, NULL, tv) > 0) { l1 = xs_read_watch(ctx->xsh, &n); if (l1 != NULL) { - char *state = libxl_xs_read(ctx, XBT_NULL, l1[XS_WATCH_PATH]); + char *state = libxl_xs_read(&gc, XBT_NULL, l1[XS_WATCH_PATH]); if (!state || atoi(state) == 6) { xs_unwatch(ctx->xsh, l1[0],...

Hi all, this is the long awaited patch series to add xen device model support in qemu; the main author is Anthony Perard. Developing this series we tried to come up with the cleanest possible solution from the qemu point of view, limiting the amount of changes to common code as much as possible. The end result still requires a couple of hooks in piix_pci but overall the impact should be very