From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: Upstream QEMU based stubdom and rump kernel Date: Tue, 17 Mar 2015 15:27:33 +0000 Message-ID: <20150317152733.GA20522@zion.uk.xensource.com> References: <20150317142907.GD27314@zion.uk.xensource.com> <20150317151517.GI1345@perard.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20150317151517.GI1345@perard.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Anthony PERARD Cc: Wei Liu , Ian Campbell , Stefano Stabellini , Ian Jackson , xen-devel@lists.xen.org, rumpkernel-users@freelists.org List-Id: xen-devel@lists.xenproject.org On Tue, Mar 17, 2015 at 03:15:17PM +0000, Anthony PERARD wrote: > On Tue, Mar 17, 2015 at 02:29:07PM +0000, Wei Liu wrote: > > I've now successfully built QEMU upstream with rump kernel. However to > > make it fully functional as a stubdom, there are some missing pieces to > > be added in. > > > > 1. The ability to access QMP socket (a unix socket) from Dom0. That > > will be used to issue command to QEMU. > > The QMP "socket" does not needs to be a unix socket. It can be any of > those (from qemu --help): > Character device options: > -chardev null,id=id[,mux=on|off] > -chardev socket,id=id[,host=host],port=port[,to=to][,ipv4][,ipv6][,nodelay][,reconnect=seconds] > [,server][,nowait][,telnet][,reconnect=seconds][,mux=on|off] (tcp) > -chardev socket,id=id,path=path[,server][,nowait][,telnet][,reconnect=seconds][,mux=on|off] (unix) > -chardev udp,id=id[,host=host],port=port[,localaddr=localaddr] > [,localport=localport][,ipv4][,ipv6][,mux=on|off] > -chardev msmouse,id=id[,mux=on|off] > -chardev vc,id=id[[,width=width][,height=height]][[,cols=cols][,rows=rows]] > [,mux=on|off] > -chardev ringbuf,id=id[,size=size] > -chardev file,id=id,path=path[,mux=on|off] > -chardev pipe,id=id,path=path[,mux=on|off] > -chardev pty,id=id[,mux=on|off] > -chardev stdio,id=id[,mux=on|off][,signal=on|off] > -chardev serial,id=id,path=path[,mux=on|off] > -chardev tty,id=id,path=path[,mux=on|off] > -chardev parallel,id=id,path=path[,mux=on|off] > -chardev parport,id=id,path=path[,mux=on|off] > -chardev spicevmc,id=id,name=name[,debug=debug] > -chardev spiceport,id=id,name=name[,debug=debug] > Ha, thanks for the list. My brain was too locked in to the current implementation. So yes, we now have an array of possible transports at our disposal. > > 2. The ability to access files in Dom0. That will be used to write to / > > read from QEMU state file. > > To save a QEMU state (write), we do use a filename. But I guest we could > expand the QMP command (xen-save-devices-state) to use something else, if > it's easier. > That's also an option. > To restore, we provide a file descriptor from libxl to QEMU, with the fd on > the file that contain the state we want to restore. But there are a few > other way to load a state (from qemu.git/docs/migration.txt): > - tcp migration: do the migration using tcp sockets > - unix migration: do the migration using unix sockets > - exec migration: do the migration using the stdin/stdout through a process. This looks most interesting as it implies we can easily pipe a console to it. Wei. > - fd migration: do the migration using an file descriptor that is > passed to QEMU. QEMU doesn't care how this file descriptor is opened. > > -- > Anthony PERARD