- xend forwards console traffic between the running bootloader and a pty
which it writes to the store so the xenconsole client can see it.
- the xenconsole client handles the domain's console pty changing.
- xm create no longer runs the bootloader.
- pygrub gets '-i' option to explicitly request an interactive session.
- xend unlocks the domain list during bootloading so that "xm console"
can see the domain and attach to its console pty.
Signed-off-by: Tim Deegan <Tim.Deegan@xensource.com>
There is a race condition between domain_create_ring() and the removal
of the domU entry from xenstore. If the removal of the domU entry from xenstore
comes later than the first xs_gather() call in domain_create_ring(), it will go
on and bind the evtchn port to the dying domU, which will cause below error
message: (XEN) (file=event_channel.c, line=144) EVTCHNOP failure: domain 0, error -22, line 144
Signed-off-by: Max Zhen <max.zhen@sun.com>
because it uses FD_ISSET(-1,xxx). Since the code is written that any
ring/tty handler can set d->tty_fd to -1 it has to be checked
_every_time_.
Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
No longer open the device as non-blocking: all reads immediately follow
a select() on the device indicating it's ready to read.
Signed-off-by: John Levon <john.levon@sun.com>
* Move .PHONY directives next to targets,
this makes them a lot harder to miss
* Add missing .PHONY directives
* Remove nonexistent .PHONY directives
* Hopefully I didn'T miss anything...
Signed-Off-By: Horms <horms@verge.net.au>
the intention appears to have been 500msec, but struct timeval when used with
a select() is in usec, not msec. The timeout has been set to 250msec (500msec
seems a little long, in any case).
Signed-off-by: Ewan Mellor <ewan@xensource.com>
through the buffer when the data are read by console clients. This avoids a
costly memmove with every read from the console.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
if the console client disconnected before all the data had been written to the
pty, even though the select call had indicated that the fd was previously
writable. Reads have been observed exhibiting similar behaviour too.
Closes bug #380.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
the domain has gone away, then no-one can attach to the pty because Xend will
have cleaned up the entries in the store, so the pty will never become ready to
write. The buffer will never get emptied, so cleanup will never occur. This
leaks ptys, file descriptors, and memory. Simply throw those data away instead.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
buffer that has grown beyond max_capacity. This fixes a Xenconsoled segfault
that was caused by stomping around above the buffer's allocated region. It
became possible to set the max_capacity with changeset 7431, and ever
since then we have been exposed to this bug. It would most easily be triggered
by running a domain without a client attached to the console, so that the
max_capacity was reached more easily.
Closes bug #380.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
domain has recently been removed from our list, but with a watch still in
flight. This should fix the intermittent crash in xenconsoled that is plaguing
us at the moment.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
means that any reads attempted on that tty will not cause handle_tty_read to
segfault looking for an interface that does not exist.
Move the writing of the tty node so that it happens after console/limit has
been read, as it is cleaner if the writing is the last thing that happens.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
whether a domain has been introduced to the store. Added a separate message
XS_IS_DOMAIN_INTRODUCED and API for that (xs_is_domain_introduced) to determine
whether the domain has really been introduced. This change means that the
tools can determine the correct domain path earlier in the domain creation
process, which is particularly a factor with live migration, as it allows us
to create the devices earlier in the process, and unpause the new domain before
performing the introduce. Until recently we already had these features, but
the simplification of the interface between xend and xenstored caused breakage.
No longer clear out the domain path when a domain is introduced -- this was a
hack to work around the recent problematic semantics of GetDomainPath.
Do not write the contents of the info block to the store. All the configuration
info is written to the /vm path, and anything else in the info block is either
dealt with explicitly or is ephemeral and has no place in the store.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
and xenconsole out of /usr/libexec/xen and into one of /usr/lib/xen/bin or
/usr/lib64/xen/bin. Remove all the PATH hacking inside Xend, and rely upon
the PATH being set correctly from outside. Added an auxbin module for
handling the hacky stuff.
Replace the few /usr/bin/python bang paths with /usr/bin/env python.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
handle on appropriate operations. Next step is to plug this
through to the store daemon and get rid of the nasty serialisation
mutex for transactions.
Signed-off-by: Keir Fraser <keir@xensource.com>
tools. /dev/xen/evtchn is now used by daemons to connect to
remote domains: the advantage is that the local ports are garbage
collected automatically if the daemon dies. xen no longer
constructs end-to-end event-channel port pairs -- it allocates an
unbound port in new domU and writes that port to xenstore. It is
then picked up by teh appropriate daemon which does interdomain bind
via /dev/xen/evtchn.
Signed-off-by: Keir Fraser <keir@xensource.com>
to guest console driver when the output ring is
emptied. This can be used to kick transmission of
more characters without needing to poll.
Signed-off-by: Keir Fraser <keir@xensource.com>
down and when it eventually dies. xenconsoled now only
relinquishes its handle on a domain when it dies. This
allows us to 'xm console' connect to a crashed domain,
which is very useful!
Signed-off-by: Keir Fraser <keir@xensource.com>
xs_write with O_CREAT|O_EXCL causes problems over daemon restarts, since
it's not idempotent.
It turns out noone really needs the flags word at all, so get rid of it.
It's now as if everyone specified "O_CREAT".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>