Upstream QEMU stubdom

From Xen

These are the TODO items. They don't need to be finished in that order. To make QEMU stubdom works we need to finish all of them.

Bootstrap guest to specific network topology

Every virtual network device in QEMU requires a tap device. All interface should be bridged to the real network interface.

It would be good if there a way to run a sequence of commands like

 ifconfig tap0 create                                                                    
 ifconfig bridge0 create                                                                 
 brconfig add tap0 bridge0                                                               
 brconfig add xenif0 bridge0                                                             
 ...                                                                                     
                                                                                         

Or at least provide an entry point for user to program rump kernel as stop-gap solution.

Use stable rumprun interface to interact with toolstack (libxl)

I need stable rumprun command line options to specify network topology as mentioned before. Xen toolstack will just call rumprun to launch QEMU stubdom.

It's OK for rumprun to evolve over time and have better syntax for things it does. We only need backward compatibility support. It's also OK to deprecate old command line options over time, just give downstream time to adjust (preferably a few releases).

Expose a host disk device as a guest disk device

Looks like ETFS is sufficient. It's a matter of passing the right options to rumprun. Performance is tied to underlying mini-os blkfront.

Communication channel between toolstack and rump kernel QEMU

The goal is to provide a channel for monitoring machinary to communicate with Xen toolstack.

According to QEMU manual, monitor can be piped to a character device (chardev). A chardev can be piped to a TCP socket. Rump kernel has TCP socket support, so for the moment we have a solution, it is just a matter of plumbing through the right options to QEMU, which is quite easy.

Martin mentioned that he is going to look into implementing libvchan in rump kernel. QEMU stubdom can switch to use that when it's ready.