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!
pgpB976jDV5yG.pgp
Description: PGP signature
