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

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



On Mon, Jan 6, 2014 at 10:54 PM, Wei Liu <wei.liu2@xxxxxxxxxx> 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.
>
> 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
>

Your idea of aggressively reducing binary size may not really fit a
defconfig at all. If you are going lean-and-mean based on a specific
use-case I think you need to bring your own config.

> Finally I got a qemu-system-null. And the effect is immediately visible

qemu-system-null has been on my wish-list in the past, although my
reasons were slightly different to yours. Specifically, the goal was
to test CPUs in an RTL simulator interacting with RAM and peripheral
devices hosted in QEMU.

> -- 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.
>

So what exactly is an appropriate device-suite for qemu-system-null is
an open question. I would suggest that the "correct" default config
for such a QEMU would actually be the full suite of devices, not less
that whats already in i386. Free of CPU/arch restrictions, all devices
are fair game.

Regards,
Peter

> What do you think about this idea?
>
> Thanks
> Wei.
>

_______________________________________________
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®.