[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Project idea: make QEMU more flexible



On Mon, 6 Jan 2014, Frediano Ziglio wrote:
> On Mon, 2014-01-06 at 12:54 +0000, Wei Liu wrote:
> > Hi all
> > 
> > This idea is to modify QEMU's Makefiles, plus implementing some stubs to
> > make it possible to tailor QEMU to a smaller binary.
> > 
> > The current setup for Xen on X86 is to build i386-softmmu, and uses this
> > single binary for two purposes:
> > 1. serves as device emulator for HVM guest.
> > 2. serves as PV driver backend for PV guest.
> > 
> 
> Perhaps even KVM would benefit too.
> Are you sure we don't emulate any instruction for other purposes?

The xenpv machine doesn't do any emulation whatsoever, in fact it is used
only for PV or ARM guests.


> > Either case CPU emulation is never used because Xen handles that
> > already. So we are in fact having a load of unused code in QEMU build.
> > 
> > What I have in mind is to build a QEMU binary which:
> > 1. does not include CPU emulation code at all.
> > 2. only includes components that's useful (what's useful is TBD).
> > 
> > And the rationales behind this idea are:
> > 
> > 1. Reduce memory footprint. One usecase would be running Xen on embedded
> >    platform (X86 or ARM). We would expect the system has very limited
> >    resources. The smaller the binary, the better.
> > 
> > 2. It doesn't make sense to have i386 emulation on ARM platform.
> >    Arguably nobody can prevent user from running i386 emulator on ARM
> >    platform, but it doesn't make sense in Xen's setup where QEMU is
> >    only used as PV device backend on ARM.
> > 
> > 3. Security concern. It's much easier to audit small code base.
> > 
> > Please note that I'm not proposing to invalidate all the other usecases.
> > I'm only speaking with my Xen developer's hat on, aiming to make QEMU
> > more flexible.
> > 
> > Down to implementation level I only need to (hopefully) add a few stubs
> > and create some new CONFIG_* options and move a few things around. It
> > might not be as intrusive as one thinks.
> > 
> > In fact I've already hacked a prototype during Christmas. What's I've
> > done so far:
> > 
> > 1. create target-null which only has some stubs to CPU emulation
> >    framework.
> > 
> > 2. add a few lines to configure / Makefiles*, create
> >    default-configs/null-softmmu
> > 
> > Finally I got a qemu-system-null. And the effect is immediately visible
> > -- the size of QEMU binary shrinked from 13MB to 7.6MB. I haven't really
> > looked at what device emulation code can be removed so the size can even
> > be made smaller.
> > 
> 
> Well, I would prefer something like a i386-nocpu. The system qemu
> emulate is still specific to a given architecture. You can't emulate ARM
> with the same executable. So we'd add default-configs/arm-nocpu.mak and
> default-config/x86_64-nocpu.mak (i386 don't make much sense anymore).

It doesn't do any emulation so it is not specific to any architecture or
any cpu.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.