[Bug runtime/13078] investigate qemu virtio-serial channel for talking to stap-sh

["jlebon at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=13078

Jonathan Lebon <jlebon at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jlebon at redhat dot com

--- Comment #3 from Jonathan Lebon <jlebon at redhat dot com> ---
<brain_dump>

I'm currently working on making this work with virtio-serial. However, there
are two peculiarities of virtio-serial to be aware of:

(1) There is no way for the host to know if/when the guest is connected. In our
case specifically, when stapsh exits, stap doesn't get EOF at its fgets() or
fread(). It just hangs there. This is by design since the virtio-serial ports
are meant to be hot-pluggable.

(2) There can be old data left on the virtio-serial buffer. If stapsh ended
abruptly for some reason and didn't read all the data from
/dev/virtio-ports/systemtap.0, then the next stapsh session will pick up that
data. Similarly, stap has to be ready to read garbage from /tmp/foo before
reaching messages from the current stapsh session.

To work around (1), we can make stapsh send a QUITTING message to stap before
exiting. However, this would be indistinguishable from a possible output from
staprun. One way around this is to prepend all the output from staprun with
"staprun:" and replies/messages from stapsh (such as the OK acks) with
"stapsh:". This would also mean always reading from /tmp/foo line-by-line
rather than in blocks, regardless of --remote-prefix.

To work around (2), we can use a synchronization scheme in which the handshake
also includes a unique/random token, which is then used throughout the session.

I'm currently working on these workarounds.

Finally, I'm also thinking about adding a -d option to stapsh so that it acts
as a daemon, i.e. constantly waiting for input on the virtio-serial port (this
would be a bit harder than just calling read() since, as mentioned in (1),
read() will just return EOF if stap hasn't opened the socket yet -- I may have
a resolution for this without having to resort to using the KVM virtio-serial's
API).

And to bring it all together, have a script/small app which can modify
libvirt-managed VMs using virsh/libvirt API/libxml to add/verify proper
virtio-serial port setup, as well as somehow setting up a systemd service for
stapsh, possibly using libguestfs to modify the harddrive directly. This small
app could even down the road be used to do something like

stap --remote vm:VM_NAME

and it would take care of looking into the VM's configuration to find the UNIX
socket's path. This is actually what libguestfs does currently.

For non-libvirt-managed VMs, we can just document the command-line that users
need to add to the qemu invocation.

</brain_dump>

-- 
You are receiving this mail because:
You are the assignee for the bug.