Re: [Xen-devel] [RFC 0/7] RFC Linux-based QEMU-upstream stub domain

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 3 Feb 2015, Eric Shelton wrote:
> This patch series updates Anthony Perard's original patch series to
> bring support for running QEMU upstream as a device model in a
> stubdomain by using a Linux-based stubdom, rather than MiniOS as
> currently used for QEMU traditional.  Anthony posted the original
> patch series on April 17, 2013.
> 
> The first three patches build Linux 3.17.8 and a disk image for the
> stubdomain itself.  QEMU is being pulled from the same repo as is
> being used for Xen 4.5.0, and some minor patches are being applied.
> A new directory is created within xen.git, stubdom-linux.  Calling
> 'make' in this directory will build Linux, QEMU upstream, and an
> ext2 disk image.  Then a 'make install' will copy the Linux kernel
> and disk image into the same directory used for other stubdomain
> images, such as MiniOS.  This build process has by no means been
> integrated with the overall Xen build process.  A more refined
> process would be expected for release code, such as integration
> with configure, eliminating the hard-coded path for 'make install',
> and only doing a single download of the QEMU sources.
> 
> The last four patches are the libxl support, which allows selecting
> between MiniOS/QEMU-traditional and Linux/QEMU-upstream.  For
> QEMU-upstream, the VM config file would include:
> 
> device_model_version = "qemu-xen" 
> device_model_stubdomain_override = 1
> 
> For QEMU-traditional, the VM config file would include:
> 
> device_model_version = "qemu-xen-traditional" 
> device_model_stubdomain_override = 1
> 
> There a number of features that are not supported yet:
> - video output (e.g., VNC)
> - save/restore
> - QMP
> 
> QMP, or at least part of the QMP protocol, will likely present
> some interesting issues.  Assumedly, there will be some subset of
> QMP commands that will require some coordination between the QEMU
> instance running in the stubdomain and a QEMU instance running in
> Dom0 (or some other domain).

I guess QMP could be routed via a PV console.


> Other expected tweaks:
> - Currently 128MB of memory is being used for the stubdomain.  This
>   is more than needed, but no attempt has been made to find the
>   appropriate lower limit.
> - The kernel config.
> - The disk image can be made smaller.
> 
> This patch series has been successfully used to run a simple Linux
> HVM guest, without the Xen drivers built into the kernel (this is
> not meant to imply that the drivers will not work, but was more to
> confirm the emulated NIC and disks provided by QEMU worked).  Once
> booted up, it was possible to successfully SSH into the Linux HVM
> guest.
> 
> Regards,
> Eric Shelton
> 
> --
> 
> Patches:
> [RFC 1/7] linux-stubdomain: Compile QEMU
> [RFC 2/7] linux-stubdomain: Compile Linux
> [RFC 3/7] linux-stubdomain: Build a disk image
> [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info
> [RFC 5/7] libxl: Handle Linux stubdomain specific QEMU options
> [RFC 6/7] libxl: Build the domain with a Linux based stubdomain
> [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel