[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
- Re: [Qemu-devel] [Xen-devel] Project idea: make QEMU more flexible, (continued)
- Re: [Qemu-devel] [Xen-devel] Project idea: make QEMU more flexible, Andreas Färber, 2014/01/06
- Re: [Qemu-devel] [Xen-devel] Project idea: make QEMU more flexible, Paolo Bonzini, 2014/01/06
- Re: [Qemu-devel] [Xen-devel] Project idea: make QEMU more flexible, Wei Liu, 2014/01/07
- Re: [Qemu-devel] [Xen-devel] Project idea: make QEMU more flexible, Paolo Bonzini, 2014/01/07
- Re: [Qemu-devel] [Xen-devel] Project idea: make QEMU more flexible, Wei Liu, 2014/01/07
Re: [Qemu-devel] Project idea: make QEMU more flexible, Peter Maydell, 2014/01/06