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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 6 Jan 2014, Wei Liu wrote:
> On Mon, Jan 06, 2014 at 07:12:07PM +0100, Andreas FÃrber wrote:
> > Am 06.01.2014 16:12, schrieb Wei Liu:
> > > On Mon, Jan 06, 2014 at 01:30:20PM +0000, Peter Maydell wrote:
> > >> On 6 January 2014 12:54, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> > >>> 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
> > >>
> > >> I think it would be better to add support to allow you to
> > >> configure with --disable-tcg. This would match the existing
> > >> --disable/--enable switches for KVM and Xen, and then you
> > >> could configure --disable-kvm --disable-tcg --enable-xen
> > >> and get a qemu-system-i386 or qemu-system-arm with only
> > >> the Xen support and none of the TCG emulation code.
> > >>
> > > 
> > > In this case the architecture-specific code in target-* is still
> > > included which might not help reduce the size much.
> > 
> > Define target-specific code in target-*? Most of that is TCG-specific
> > and wouldn't be compiled in in that case. The KVM-specific bits don't
> > get compiled in with --disable-kvm today already save for a few stubs.
> > 
> 
> Probably I used the wrong terminology. I meant, say,
> target-i386/translate.c, exec.c etc, which won't be necessary for Xen. I
> guess that's what you mean by TCG-specific.  I see the possibility to
> create some stubs for them, if that's what you mean.
> 
> > Adding yet another separate binary with no added functional value
> > doesn't strike me as the most helpful idea for the community, compared
> > to configure-optimizing the binaries built today.
> > 
> > Who would use the stripped-down binaries anyway? Just Citrix? Because
> > SUSE is headed for sharing QEMU packages between Xen and KVM, so we
> > couldn't enable such Xen-only-optimized binaries.
> > 
> 
> No, I don't speak for Citrix. I work for opensource Xen project, I just
> happen to be hired by Citrix. The general idea is to have an option for
> user to create smaller binary, without those unnecessary code compiled /
> linked in. How vendor makes their choice is out of my reach. :-)

Right.

Lots of people trying Xen on ARM today come from the embedded world:
routers, set top boxes, in-vehicle entertainment, etc. One wouldn't want
to run a full blown distro in these cases or a generic QEMU binary. The
smaller the better.

I am sure that this work would be useful even on bigger systems as
somebody already pointed out on this thread.

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