qemu-devel
[Top][All Lists]
Advanced

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

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


From: Wei Liu
Subject: Re: [Qemu-devel] Project idea: make QEMU more flexible
Date: Mon, 6 Jan 2014 18:25:41 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

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 <address@hidden> 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. :-)

Wei.

> Regards,
> Andreas
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]