From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22396 invoked by alias); 9 Aug 2013 18:17:41 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 22191 invoked by uid 48); 9 Aug 2013 18:17:33 -0000 From: "jlebon at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/13078] investigate qemu virtio-serial channel for talking to stap-sh Date: Fri, 09 Aug 2013 18:17:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: runtime X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jlebon at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-q3/txt/msg00113.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13078 Jonathan Lebon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jlebon at redhat dot com --- Comment #3 from Jonathan Lebon --- 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. -- You are receiving this mail because: You are the assignee for the bug.