[Qemu-devel] Using a simple SHM system for host/guest communication

[Matthew Rosewarne]

One problem I have with the (excellent) QEMU is that there is no way to get 
any data between hosts and guests short of file transfer.  Perhaps a solution 
to this issue could be the use of a very thin and generic shared memory 
functionality in the emulated hardware.  With this method, "drivers" could be 
written for the guest OSes and handler daemons for the hosts to use a chunk 
of shared memory to communicate.  This method would solve some of the 
problems present in other methods:
        1. Pipes/FIFOs are unidirectional, require the data to be serialised 
before transmission, and are fairly slow.
        2. Network-based approaches require not only serialisation but also a 
network layer and as such considerable overhead and more configuration.
        3. File-based approaches are worse than either, requiring 
serialisation, writing to disk, a network layer (for SMB, TFTP, etc.), 
polling, and locking, and thus are VERY slow.

An SHM approach would
        A) be fast
        B) not require serialisation to files/sockets/pipes
        C) not be dependent on networking or incur its overhead
        D) not need to be explicitly configured by the user
        E) not add any guest platform/OS-dependent code to QEMU

A hypothetical example in five acts:
                ACT 1
        1. A guest driver is written that requests a chunk of shared memory 
named "clip_buffer" from the SHM virtual device in the VM
        2. QEMU asks the host kernel to allocate a chunk of SHM and creates a 
device node for it on the host, perhaps at /tmp/qemu-${PID}/shm/clip_buffer 
(the example has a Unix host; this part would be different on other hosts)
        3. A host daemon is written that opens "/tmp/qemu-*/shm/clip_buffer" 
(again, a different on other hosts)
                ACT 2
        1. The user copies some data to the clipboard in the guest OS
        2. The guest driver scrapes the guest's clipboard for copied data and 
puts it in "clip_buffer"
        3. The host daemon listens for new data in the "clip_buffer"[s] and 
puts it in the host's clipboard (and "clip_buffer"[s] from other QEMU 
instances)
                ACT 3
        1. The user copies some data to the clipboard in the host OS
        2. The host daemon scrapes the host's clipboard for copied data and 
puts it into "clip_buffer"
        3. The guest driver (in each qemu instance) looks for new data from 
its "clip_buffer" and puts it into the guest's clipboard
                ACT 4
        1. A second guest is started that does not have a driver 
for "clip_buffer"
        2. The second guest runs correctly (just as before the SHM facility 
existed), unaware of the "clip_buffer"[s] on the host or other guests
                ACT 5
        1. The driver in the first guest is unloaded, releasing the SHM 
chunk "clip_buffer"
        2. QEMU deallocates the "clip_buffer" SHM and removes the node 
at /tmp/qemu-${PID}/shm/clip_buffer
        3. If the guest driver breaks and does not release its SHM chunks, QEMU 
forcefully destroys them after the guest powers off
        4. Noticing that the SHM device is gone, the host daemon terminates
                FIN

This facility could be used for much more than copy and paste, but I think the 
example is a good demonstration of a simple use case.  The only aspect of the 
process I left out intentionally was the starting of the daemons on the host.  
They could possibly be started by QEMU, which could have a file listing which 
daemons to start when certain chunk names are requested, or manually by the 
user (maybe in a script).  I'm not sure what the best option would be here.

Unfortunately I am probably not a good enough hacker to implement this myself, 
but I hope that somebody might get some ideas from this proposal.  Should I 
put this info (or perhaps a more terse version of it) on the savannah BTS?  
If  anyone has any questions, comments, mockery, or abuse, I'd very much like 
to hear.

~Matt

PS: Big thanks to all the QEMU contributors for such outstanding software!

pgpMXgh7pDgUL.pgp
Description: PGP signature