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

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

[Wei Liu]

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

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.

What do you think about this idea?

Thanks
Wei.

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

[Peter Crosthwaite]

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

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

[Peter Crosthwaite]

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

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

[Frediano Ziglio]

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?

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

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

Frediano

Re: Project idea: make QEMU more flexible

[Frediano Ziglio]

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?

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

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

Frediano

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

[Peter Maydell]

On 6 January 2014 12:54, Wei Liu <wei.liu2@citrix.com> 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.

thanks
-- PMM

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

[Stefano Stabellini]

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.

Re: Project idea: make QEMU more flexible

[Stefano Stabellini]

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.

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

[Peter Maydell]

On 6 January 2014 14:17, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> It doesn't do any emulation so it is not specific to any architecture or
> any cpu.

You presumably still care about the compiled in values of
TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...

thanks
-- PMM

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

[Peter Maydell]

On 6 January 2014 14:17, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> It doesn't do any emulation so it is not specific to any architecture or
> any cpu.

You presumably still care about the compiled in values of
TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...

thanks
-- PMM

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

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
>
> On 6 January 2014 14:17, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > It doesn't do any emulation so it is not specific to any architecture or
> > any cpu.
>
> You presumably still care about the compiled in values of
> TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...

Yup.  It's still accel=xen just with no VCPUs.

Regards,

Anthony Liguori

>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 792 bytes --]

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

[Anthony Liguori]

[-- Attachment #1.1: Type: text/plain, Size: 473 bytes --]

On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
>
> On 6 January 2014 14:17, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > It doesn't do any emulation so it is not specific to any architecture or
> > any cpu.
>
> You presumably still care about the compiled in values of
> TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...

Yup.  It's still accel=xen just with no VCPUs.

Regards,

Anthony Liguori

>
> thanks
> -- PMM
>

[-- Attachment #1.2: Type: text/html, Size: 792 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On Mon, 6 Jan 2014, Anthony Liguori wrote:
> On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
> >
> > On 6 January 2014 14:17, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> > > It doesn't do any emulation so it is not specific to any architecture or
> > > any cpu.
> >
> > You presumably still care about the compiled in values of
> > TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...

Actually it only uses XC_PAGE_SIZE and the endianness is the host
endianness.


> Yup.  It's still accel=xen just with no VCPUs.

Are you talking about introducing accel=xen to Wei's target-null?
I guess that would work OK.

On the other hand if you are thinking of avoiding the introduction of a
new target-null, how would you make xen_machine_pv.c available to
multiple architectures? How would you avoid the compilation of all the
unnecessary emulated devices?

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

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On Mon, 6 Jan 2014, Anthony Liguori wrote:
> On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
> >
> > On 6 January 2014 14:17, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> > > It doesn't do any emulation so it is not specific to any architecture or
> > > any cpu.
> >
> > You presumably still care about the compiled in values of
> > TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...

Actually it only uses XC_PAGE_SIZE and the endianness is the host
endianness.


> Yup.  It's still accel=xen just with no VCPUs.

Are you talking about introducing accel=xen to Wei's target-null?
I guess that would work OK.

On the other hand if you are thinking of avoiding the introduction of a
new target-null, how would you make xen_machine_pv.c available to
multiple architectures? How would you avoid the compilation of all the
unnecessary emulated devices?

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Peter Maydell]

On 6 January 2014 14:54, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> How would you avoid the compilation of all the
> unnecessary emulated devices?

Didn't we have some patches for doing a Kconfig-style
"select the devices you need" build recently?

-- PMM

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

[Peter Maydell]

On 6 January 2014 14:54, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> How would you avoid the compilation of all the
> unnecessary emulated devices?

Didn't we have some patches for doing a Kconfig-style
"select the devices you need" build recently?

-- PMM

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

[Wei Liu]

On Mon, Jan 06, 2014 at 11:23:24PM +1000, Peter Crosthwaite wrote:
[...]
> >
> > 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.
> 

Fair enough.

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

Cool. However small this is still a valid usecase.

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

Good point. So only avoid the CPU emulation code and leave full device
emulations alone. Will this make a sensible defconfig? ;-)

Wei.

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

[Wei Liu]

On Mon, Jan 06, 2014 at 11:23:24PM +1000, Peter Crosthwaite wrote:
[...]
> >
> > 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.
> 

Fair enough.

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

Cool. However small this is still a valid usecase.

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

Good point. So only avoid the CPU emulation code and leave full device
emulations alone. Will this make a sensible defconfig? ;-)

Wei.

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

[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@citrix.com> 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.

Wei.

> thanks
> -- PMM

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

[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@citrix.com> 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.

Wei.

> thanks
> -- PMM

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

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

On Jan 6, 2014 6:55 AM, "Stefano Stabellini" <
stefano.stabellini@eu.citrix.com> wrote:
>
> On Mon, 6 Jan 2014, Anthony Liguori wrote:
> > On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@linaro.org>
wrote:
> > >
> > > On 6 January 2014 14:17, Stefano Stabellini
> > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > It doesn't do any emulation so it is not specific to any
architecture or
> > > > any cpu.
> > >
> > > You presumably still care about the compiled in values of
> > > TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...
>
> Actually it only uses XC_PAGE_SIZE and the endianness is the host
> endianness.

If blkif in QEMU is relying on host endianness thats a bug.

>
>
> > Yup.  It's still accel=xen just with no VCPUs.
>
> Are you talking about introducing accel=xen to Wei's target-null?
> I guess that would work OK.

We already have accel=xen.  I'm echoing Peter's suggestion of having the
ability to compile out accel=tcg.

>
> On the other hand if you are thinking of avoiding the introduction of a
> new target-null, how would you make xen_machine_pv.c available to
> multiple architectures?

Why does qdisk need a full machine?

How would you avoid the compilation of all the
> unnecessary emulated devices?

Device config files.

Regards,

Anthony Liguori

[-- Attachment #2: Type: text/html, Size: 1925 bytes --]

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

[Anthony Liguori]

[-- Attachment #1.1: Type: text/plain, Size: 1292 bytes --]

On Jan 6, 2014 6:55 AM, "Stefano Stabellini" <
stefano.stabellini@eu.citrix.com> wrote:
>
> On Mon, 6 Jan 2014, Anthony Liguori wrote:
> > On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@linaro.org>
wrote:
> > >
> > > On 6 January 2014 14:17, Stefano Stabellini
> > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > It doesn't do any emulation so it is not specific to any
architecture or
> > > > any cpu.
> > >
> > > You presumably still care about the compiled in values of
> > > TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...
>
> Actually it only uses XC_PAGE_SIZE and the endianness is the host
> endianness.

If blkif in QEMU is relying on host endianness thats a bug.

>
>
> > Yup.  It's still accel=xen just with no VCPUs.
>
> Are you talking about introducing accel=xen to Wei's target-null?
> I guess that would work OK.

We already have accel=xen.  I'm echoing Peter's suggestion of having the
ability to compile out accel=tcg.

>
> On the other hand if you are thinking of avoiding the introduction of a
> new target-null, how would you make xen_machine_pv.c available to
> multiple architectures?

Why does qdisk need a full machine?

How would you avoid the compilation of all the
> unnecessary emulated devices?

Device config files.

Regards,

Anthony Liguori

[-- Attachment #1.2: Type: text/html, Size: 1925 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

On Mon, 6 Jan 2014, Anthony Liguori wrote:
> On Jan 6, 2014 6:55 AM, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com> wrote:
> >
> > On Mon, 6 Jan 2014, Anthony Liguori wrote:
> > > On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
> > > >
> > > > On 6 January 2014 14:17, Stefano Stabellini
> > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > > It doesn't do any emulation so it is not specific to any architecture or
> > > > > any cpu.
> > > >
> > > > You presumably still care about the compiled in values of
> > > > TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...
> >
> > Actually it only uses XC_PAGE_SIZE and the endianness is the host
> > endianness.
> 
> If blkif in QEMU is relying on host endianness thats a bug.

Why? Xen doesn't support a different guest/host endianness.


> > > Yup.  It's still accel=xen just with no VCPUs.
> >
> > Are you talking about introducing accel=xen to Wei's target-null?
> > I guess that would work OK.
> 
> We already have accel=xen.  I'm echoing Peter's suggestion of having the ability to compile out accel=tcg.
> 
> >
> > On the other hand if you are thinking of avoiding the introduction of a
> > new target-null, how would you make xen_machine_pv.c available to
> > multiple architectures?
> 
> Why does qdisk need a full machine?

qdisk is just one device, xen_machine_pv is the machine that initializes
the backend infrastructure (one of the backends is qdisk).
It doesn't make sense to use a full-blown machine like pc.c just to
start few backends, right?


> How would you avoid the compilation of all the
> > unnecessary emulated devices?
> 
> Device config files.

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

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

On Mon, 6 Jan 2014, Anthony Liguori wrote:
> On Jan 6, 2014 6:55 AM, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com> wrote:
> >
> > On Mon, 6 Jan 2014, Anthony Liguori wrote:
> > > On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
> > > >
> > > > On 6 January 2014 14:17, Stefano Stabellini
> > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > > It doesn't do any emulation so it is not specific to any architecture or
> > > > > any cpu.
> > > >
> > > > You presumably still care about the compiled in values of
> > > > TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...
> >
> > Actually it only uses XC_PAGE_SIZE and the endianness is the host
> > endianness.
> 
> If blkif in QEMU is relying on host endianness thats a bug.

Why? Xen doesn't support a different guest/host endianness.


> > > Yup.  It's still accel=xen just with no VCPUs.
> >
> > Are you talking about introducing accel=xen to Wei's target-null?
> > I guess that would work OK.
> 
> We already have accel=xen.  I'm echoing Peter's suggestion of having the ability to compile out accel=tcg.
> 
> >
> > On the other hand if you are thinking of avoiding the introduction of a
> > new target-null, how would you make xen_machine_pv.c available to
> > multiple architectures?
> 
> Why does qdisk need a full machine?

qdisk is just one device, xen_machine_pv is the machine that initializes
the backend infrastructure (one of the backends is qdisk).
It doesn't make sense to use a full-blown machine like pc.c just to
start few backends, right?


> How would you avoid the compilation of all the
> > unnecessary emulated devices?
> 
> Device config files.

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Peter Maydell]

On 6 January 2014 15:11, Wei Liu <wei.liu2@citrix.com> wrote:
> On Mon, Jan 06, 2014 at 11:23:24PM +1000, Peter Crosthwaite wrote:
> [...]
>> >
>> > 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.

> Cool. However small this is still a valid usecase.

However I don't think we can have a qemu-system-null
(regardless of use cases) until/unless we get rid of
all the things which are compile-time decided by
the system config. In an ideal world we wouldn't have
any of those (and perhaps you could even build
support for more than one kind of CPU into one QEMU
binary), but as it is we do have them, and so a
qemu-system-null is not possible.

thanks
-- PMM

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

[Peter Maydell]

On 6 January 2014 15:11, Wei Liu <wei.liu2@citrix.com> wrote:
> On Mon, Jan 06, 2014 at 11:23:24PM +1000, Peter Crosthwaite wrote:
> [...]
>> >
>> > 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.

> Cool. However small this is still a valid usecase.

However I don't think we can have a qemu-system-null
(regardless of use cases) until/unless we get rid of
all the things which are compile-time decided by
the system config. In an ideal world we wouldn't have
any of those (and perhaps you could even build
support for more than one kind of CPU into one QEMU
binary), but as it is we do have them, and so a
qemu-system-null is not possible.

thanks
-- PMM

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

[Stefano Stabellini]

On Mon, 6 Jan 2014, Peter Maydell wrote:
> On 6 January 2014 15:11, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Mon, Jan 06, 2014 at 11:23:24PM +1000, Peter Crosthwaite wrote:
> > [...]
> >> >
> >> > 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.
> 
> > Cool. However small this is still a valid usecase.
> 
> However I don't think we can have a qemu-system-null
> (regardless of use cases) until/unless we get rid of
> all the things which are compile-time decided by
> the system config. In an ideal world we wouldn't have
> any of those (and perhaps you could even build
> support for more than one kind of CPU into one QEMU
> binary), but as it is we do have them, and so a
> qemu-system-null is not possible.

What are these compile-time things you are referring to?

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

[Stefano Stabellini]

On Mon, 6 Jan 2014, Peter Maydell wrote:
> On 6 January 2014 15:11, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Mon, Jan 06, 2014 at 11:23:24PM +1000, Peter Crosthwaite wrote:
> > [...]
> >> >
> >> > 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.
> 
> > Cool. However small this is still a valid usecase.
> 
> However I don't think we can have a qemu-system-null
> (regardless of use cases) until/unless we get rid of
> all the things which are compile-time decided by
> the system config. In an ideal world we wouldn't have
> any of those (and perhaps you could even build
> support for more than one kind of CPU into one QEMU
> binary), but as it is we do have them, and so a
> qemu-system-null is not possible.

What are these compile-time things you are referring to?

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

[Anthony Liguori]

On Mon, Jan 6, 2014 at 7:57 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 6 Jan 2014, Anthony Liguori wrote:
>> On Jan 6, 2014 6:55 AM, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com> wrote:
>> >
>> > On Mon, 6 Jan 2014, Anthony Liguori wrote:
>> > > On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
>> > > >
>> > > > On 6 January 2014 14:17, Stefano Stabellini
>> > > > <stefano.stabellini@eu.citrix.com> wrote:
>> > > > > It doesn't do any emulation so it is not specific to any architecture or
>> > > > > any cpu.
>> > > >
>> > > > You presumably still care about the compiled in values of
>> > > > TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...
>> >
>> > Actually it only uses XC_PAGE_SIZE and the endianness is the host
>> > endianness.
>>
>> If blkif in QEMU is relying on host endianness thats a bug.
>
> Why? Xen doesn't support a different guest/host endianness.

For the same reason that the virtio devices do not rely on host endianness.

It should be possible to use the Xen devices with TCG.  It isn't today
simply because the code wasn't structured that way but it could be
refactored to do this.

>> > > Yup.  It's still accel=xen just with no VCPUs.
>> >
>> > Are you talking about introducing accel=xen to Wei's target-null?
>> > I guess that would work OK.
>>
>> We already have accel=xen.  I'm echoing Peter's suggestion of having the ability to compile out accel=tcg.
>>
>> >
>> > On the other hand if you are thinking of avoiding the introduction of a
>> > new target-null, how would you make xen_machine_pv.c available to
>> > multiple architectures?
>>
>> Why does qdisk need a full machine?
>
> qdisk is just one device, xen_machine_pv is the machine that initializes
> the backend infrastructure (one of the backends is qdisk).
> It doesn't make sense to use a full-blown machine like pc.c just to
> start few backends, right?

What prevents xen_machine_pv from being compiled for multiple targets?
 If there i386 specific things in it, they surely could be refactored
a bit, no?

Regards,

Anthony Liguori

>
>
>> How would you avoid the compilation of all the
>> > unnecessary emulated devices?
>>
>> Device config files.

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

[Anthony Liguori]

On Mon, Jan 6, 2014 at 7:57 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 6 Jan 2014, Anthony Liguori wrote:
>> On Jan 6, 2014 6:55 AM, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com> wrote:
>> >
>> > On Mon, 6 Jan 2014, Anthony Liguori wrote:
>> > > On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
>> > > >
>> > > > On 6 January 2014 14:17, Stefano Stabellini
>> > > > <stefano.stabellini@eu.citrix.com> wrote:
>> > > > > It doesn't do any emulation so it is not specific to any architecture or
>> > > > > any cpu.
>> > > >
>> > > > You presumably still care about the compiled in values of
>> > > > TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...
>> >
>> > Actually it only uses XC_PAGE_SIZE and the endianness is the host
>> > endianness.
>>
>> If blkif in QEMU is relying on host endianness thats a bug.
>
> Why? Xen doesn't support a different guest/host endianness.

For the same reason that the virtio devices do not rely on host endianness.

It should be possible to use the Xen devices with TCG.  It isn't today
simply because the code wasn't structured that way but it could be
refactored to do this.

>> > > Yup.  It's still accel=xen just with no VCPUs.
>> >
>> > Are you talking about introducing accel=xen to Wei's target-null?
>> > I guess that would work OK.
>>
>> We already have accel=xen.  I'm echoing Peter's suggestion of having the ability to compile out accel=tcg.
>>
>> >
>> > On the other hand if you are thinking of avoiding the introduction of a
>> > new target-null, how would you make xen_machine_pv.c available to
>> > multiple architectures?
>>
>> Why does qdisk need a full machine?
>
> qdisk is just one device, xen_machine_pv is the machine that initializes
> the backend infrastructure (one of the backends is qdisk).
> It doesn't make sense to use a full-blown machine like pc.c just to
> start few backends, right?

What prevents xen_machine_pv from being compiled for multiple targets?
 If there i386 specific things in it, they surely could be refactored
a bit, no?

Regards,

Anthony Liguori

>
>
>> How would you avoid the compilation of all the
>> > unnecessary emulated devices?
>>
>> Device config files.

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

[Andreas Färber]

Am 06.01.2014 16:39, schrieb Anthony Liguori:
> We already have accel=xen.  I'm echoing Peter's suggestion of having the
> ability to compile out accel=tcg.

Didn't you and Paolo even have patches for that a while ago?

Cheers,
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] Project idea: make QEMU more flexible

[Andreas Färber]

Am 06.01.2014 16:39, schrieb Anthony Liguori:
> We already have accel=xen.  I'm echoing Peter's suggestion of having the
> ability to compile out accel=tcg.

Didn't you and Paolo even have patches for that a while ago?

Cheers,
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

[Stefano Stabellini]

On Mon, 6 Jan 2014, Anthony Liguori wrote:
> On Mon, Jan 6, 2014 at 7:57 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 6 Jan 2014, Anthony Liguori wrote:
> >> On Jan 6, 2014 6:55 AM, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com> wrote:
> >> >
> >> > On Mon, 6 Jan 2014, Anthony Liguori wrote:
> >> > > On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
> >> > > >
> >> > > > On 6 January 2014 14:17, Stefano Stabellini
> >> > > > <stefano.stabellini@eu.citrix.com> wrote:
> >> > > > > It doesn't do any emulation so it is not specific to any architecture or
> >> > > > > any cpu.
> >> > > >
> >> > > > You presumably still care about the compiled in values of
> >> > > > TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...
> >> >
> >> > Actually it only uses XC_PAGE_SIZE and the endianness is the host
> >> > endianness.
> >>
> >> If blkif in QEMU is relying on host endianness thats a bug.
> >
> > Why? Xen doesn't support a different guest/host endianness.
> 
> For the same reason that the virtio devices do not rely on host endianness.
> 
> It should be possible to use the Xen devices with TCG.  It isn't today
> simply because the code wasn't structured that way but it could be
> refactored to do this.
> 
> >> > > Yup.  It's still accel=xen just with no VCPUs.
> >> >
> >> > Are you talking about introducing accel=xen to Wei's target-null?
> >> > I guess that would work OK.
> >>
> >> We already have accel=xen.  I'm echoing Peter's suggestion of having the ability to compile out accel=tcg.
> >>
> >> >
> >> > On the other hand if you are thinking of avoiding the introduction of a
> >> > new target-null, how would you make xen_machine_pv.c available to
> >> > multiple architectures?
> >>
> >> Why does qdisk need a full machine?
> >
> > qdisk is just one device, xen_machine_pv is the machine that initializes
> > the backend infrastructure (one of the backends is qdisk).
> > It doesn't make sense to use a full-blown machine like pc.c just to
> > start few backends, right?
> 
> What prevents xen_machine_pv from being compiled for multiple targets?
>  If there i386 specific things in it, they surely could be refactored
> a bit, no?

Not at all, but I thought that at the moment one machine has to be tied
to one architecture. If I am wrong, then there is no issue.

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

[Stefano Stabellini]

On Mon, 6 Jan 2014, Anthony Liguori wrote:
> On Mon, Jan 6, 2014 at 7:57 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 6 Jan 2014, Anthony Liguori wrote:
> >> On Jan 6, 2014 6:55 AM, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com> wrote:
> >> >
> >> > On Mon, 6 Jan 2014, Anthony Liguori wrote:
> >> > > On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
> >> > > >
> >> > > > On 6 January 2014 14:17, Stefano Stabellini
> >> > > > <stefano.stabellini@eu.citrix.com> wrote:
> >> > > > > It doesn't do any emulation so it is not specific to any architecture or
> >> > > > > any cpu.
> >> > > >
> >> > > > You presumably still care about the compiled in values of
> >> > > > TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...
> >> >
> >> > Actually it only uses XC_PAGE_SIZE and the endianness is the host
> >> > endianness.
> >>
> >> If blkif in QEMU is relying on host endianness thats a bug.
> >
> > Why? Xen doesn't support a different guest/host endianness.
> 
> For the same reason that the virtio devices do not rely on host endianness.
> 
> It should be possible to use the Xen devices with TCG.  It isn't today
> simply because the code wasn't structured that way but it could be
> refactored to do this.
> 
> >> > > Yup.  It's still accel=xen just with no VCPUs.
> >> >
> >> > Are you talking about introducing accel=xen to Wei's target-null?
> >> > I guess that would work OK.
> >>
> >> We already have accel=xen.  I'm echoing Peter's suggestion of having the ability to compile out accel=tcg.
> >>
> >> >
> >> > On the other hand if you are thinking of avoiding the introduction of a
> >> > new target-null, how would you make xen_machine_pv.c available to
> >> > multiple architectures?
> >>
> >> Why does qdisk need a full machine?
> >
> > qdisk is just one device, xen_machine_pv is the machine that initializes
> > the backend infrastructure (one of the backends is qdisk).
> > It doesn't make sense to use a full-blown machine like pc.c just to
> > start few backends, right?
> 
> What prevents xen_machine_pv from being compiled for multiple targets?
>  If there i386 specific things in it, they surely could be refactored
> a bit, no?

Not at all, but I thought that at the moment one machine has to be tied
to one architecture. If I am wrong, then there is no issue.

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

[Peter Maydell]

On 6 January 2014 17:34, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 6 Jan 2014, Peter Maydell wrote:
>> However I don't think we can have a qemu-system-null
>> (regardless of use cases) until/unless we get rid of
>> all the things which are compile-time decided by
>> the system config. In an ideal world we wouldn't have
>> any of those (and perhaps you could even build
>> support for more than one kind of CPU into one QEMU
>> binary), but as it is we do have them, and so a
>> qemu-system-null is not possible.
>
> What are these compile-time things you are referring to?

The identifiers poisoned by include/qemu/poison.h are
an initial but not complete list. Host and target
endianness is a particularly obvious one, as is the
size of a target long. You may not use these things
in your Xen devices, but "qemu-system-null" implies
more than "weird special purpose thing which only
has Xen devices in it".

Speaking of odd Xen special cases, it's pretty ugly
that builds with Xen enabled override the size of
ram_addr_t... maybe we should get rid of that special
casing one way or the other.

thanks
-- PMM

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

[Peter Maydell]

On 6 January 2014 17:34, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 6 Jan 2014, Peter Maydell wrote:
>> However I don't think we can have a qemu-system-null
>> (regardless of use cases) until/unless we get rid of
>> all the things which are compile-time decided by
>> the system config. In an ideal world we wouldn't have
>> any of those (and perhaps you could even build
>> support for more than one kind of CPU into one QEMU
>> binary), but as it is we do have them, and so a
>> qemu-system-null is not possible.
>
> What are these compile-time things you are referring to?

The identifiers poisoned by include/qemu/poison.h are
an initial but not complete list. Host and target
endianness is a particularly obvious one, as is the
size of a target long. You may not use these things
in your Xen devices, but "qemu-system-null" implies
more than "weird special purpose thing which only
has Xen devices in it".

Speaking of odd Xen special cases, it's pretty ugly
that builds with Xen enabled override the size of
ram_addr_t... maybe we should get rid of that special
casing one way or the other.

thanks
-- PMM

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

[Andreas Färber]

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@citrix.com> 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.

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.

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] Project idea: make QEMU more flexible

[Wei Liu]

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@citrix.com> 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] Project idea: make QEMU more flexible

[Wei Liu]

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@citrix.com> 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

[Paolo Bonzini]

Il 06/01/2014 19:00, Andreas Färber ha scritto:
> Am 06.01.2014 16:39, schrieb Anthony Liguori:
>> We already have accel=xen.  I'm echoing Peter's suggestion of having the
>> ability to compile out accel=tcg.
> 
> Didn't you and Paolo even have patches for that a while ago?

Yes, but some code shuffling is required in each target to make sure you
can compile out translate-all.c, cputlb.c, etc.  So my patches only
worked for x86 at the time.

Paolo

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

[Paolo Bonzini]

Il 06/01/2014 19:00, Andreas Färber ha scritto:
> Am 06.01.2014 16:39, schrieb Anthony Liguori:
>> We already have accel=xen.  I'm echoing Peter's suggestion of having the
>> ability to compile out accel=tcg.
> 
> Didn't you and Paolo even have patches for that a while ago?

Yes, but some code shuffling is required in each target to make sure you
can compile out translate-all.c, cputlb.c, etc.  So my patches only
worked for x86 at the time.

Paolo

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

[Paolo Bonzini]

Il 06/01/2014 16:04, Peter Maydell ha scritto:
> On 6 January 2014 14:54, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> How would you avoid the compilation of all the
>> unnecessary emulated devices?
> 
> Didn't we have some patches for doing a Kconfig-style
> "select the devices you need" build recently?

It was really "select what boards you need" and "select any additional
-device-capable devices you need".  So the covered devices were
basically ISA, PCI, USB and I2C.  Other files (e.g. scsi-bus.c or sd.c)
were picked up via dependencies so they could still be left out unless
necessary.

The final plan was to keep the default-configs/ files, and add
dependency-handling via the Kconfig language but without Kconfig sources
itself.  Akos, did you go any further with your mini_kconfig.py parser?

Paolo

Re: Project idea: make QEMU more flexible

[Paolo Bonzini]

Il 06/01/2014 16:04, Peter Maydell ha scritto:
> On 6 January 2014 14:54, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> How would you avoid the compilation of all the
>> unnecessary emulated devices?
> 
> Didn't we have some patches for doing a Kconfig-style
> "select the devices you need" build recently?

It was really "select what boards you need" and "select any additional
-device-capable devices you need".  So the covered devices were
basically ISA, PCI, USB and I2C.  Other files (e.g. scsi-bus.c or sd.c)
were picked up via dependencies so they could still be left out unless
necessary.

The final plan was to keep the default-configs/ files, and add
dependency-handling via the Kconfig language but without Kconfig sources
itself.  Akos, did you go any further with your mini_kconfig.py parser?

Paolo

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

[Wei Liu]

On Mon, Jan 06, 2014 at 09:53:37PM +0100, Paolo Bonzini wrote:
> Il 06/01/2014 19:00, Andreas Färber ha scritto:
> > Am 06.01.2014 16:39, schrieb Anthony Liguori:
> >> We already have accel=xen.  I'm echoing Peter's suggestion of having the
> >> ability to compile out accel=tcg.
> > 
> > Didn't you and Paolo even have patches for that a while ago?
> 
> Yes, but some code shuffling is required in each target to make sure you
> can compile out translate-all.c, cputlb.c, etc.  So my patches only
> worked for x86 at the time.
> 

Hi Paolo, I don't monitor qemu-devel on a daily basis. Do you have
reference to your patches? Thanks.

Wei.

> Paolo

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

[Wei Liu]

On Mon, Jan 06, 2014 at 09:53:37PM +0100, Paolo Bonzini wrote:
> Il 06/01/2014 19:00, Andreas Färber ha scritto:
> > Am 06.01.2014 16:39, schrieb Anthony Liguori:
> >> We already have accel=xen.  I'm echoing Peter's suggestion of having the
> >> ability to compile out accel=tcg.
> > 
> > Didn't you and Paolo even have patches for that a while ago?
> 
> Yes, but some code shuffling is required in each target to make sure you
> can compile out translate-all.c, cputlb.c, etc.  So my patches only
> worked for x86 at the time.
> 

Hi Paolo, I don't monitor qemu-devel on a daily basis. Do you have
reference to your patches? Thanks.

Wei.

> Paolo

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

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]

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@citrix.com> 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.

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

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]

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@citrix.com> 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.

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Stefano Stabellini]

On Mon, 6 Jan 2014, Peter Maydell wrote:
> On 6 January 2014 17:34, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 6 Jan 2014, Peter Maydell wrote:
> >> However I don't think we can have a qemu-system-null
> >> (regardless of use cases) until/unless we get rid of
> >> all the things which are compile-time decided by
> >> the system config. In an ideal world we wouldn't have
> >> any of those (and perhaps you could even build
> >> support for more than one kind of CPU into one QEMU
> >> binary), but as it is we do have them, and so a
> >> qemu-system-null is not possible.
> >
> > What are these compile-time things you are referring to?
> 
> The identifiers poisoned by include/qemu/poison.h are
> an initial but not complete list. Host and target
> endianness is a particularly obvious one, as is the
> size of a target long. You may not use these things
> in your Xen devices, but "qemu-system-null" implies
> more than "weird special purpose thing which only
> has Xen devices in it".

I see your point.
Could we allow target endinness and long size being selected at
configure time for target-null?
The default could be the same as the host, or could even be simply
statically determined, maybe little endian, 4 bytes.

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

[Stefano Stabellini]

On Mon, 6 Jan 2014, Peter Maydell wrote:
> On 6 January 2014 17:34, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 6 Jan 2014, Peter Maydell wrote:
> >> However I don't think we can have a qemu-system-null
> >> (regardless of use cases) until/unless we get rid of
> >> all the things which are compile-time decided by
> >> the system config. In an ideal world we wouldn't have
> >> any of those (and perhaps you could even build
> >> support for more than one kind of CPU into one QEMU
> >> binary), but as it is we do have them, and so a
> >> qemu-system-null is not possible.
> >
> > What are these compile-time things you are referring to?
> 
> The identifiers poisoned by include/qemu/poison.h are
> an initial but not complete list. Host and target
> endianness is a particularly obvious one, as is the
> size of a target long. You may not use these things
> in your Xen devices, but "qemu-system-null" implies
> more than "weird special purpose thing which only
> has Xen devices in it".

I see your point.
Could we allow target endinness and long size being selected at
configure time for target-null?
The default could be the same as the host, or could even be simply
statically determined, maybe little endian, 4 bytes.

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

[Paolo Bonzini]

Il 07/01/2014 13:34, Wei Liu ha scritto:
> On Mon, Jan 06, 2014 at 09:53:37PM +0100, Paolo Bonzini wrote:
>> Il 06/01/2014 19:00, Andreas Färber ha scritto:
>>> Am 06.01.2014 16:39, schrieb Anthony Liguori:
>>>> We already have accel=xen.  I'm echoing Peter's suggestion of having the
>>>> ability to compile out accel=tcg.
>>>
>>> Didn't you and Paolo even have patches for that a while ago?
>>
>> Yes, but some code shuffling is required in each target to make sure you
>> can compile out translate-all.c, cputlb.c, etc.  So my patches only
>> worked for x86 at the time.
>>
> 
> Hi Paolo, I don't monitor qemu-devel on a daily basis. Do you have
> reference to your patches? Thanks.

Googling "disable tcg" would have provided an answer, but the patches
were old enough to be basically useless.  I'll refresh the current
version in the next few days.  Currently I am (or try to be) on
vacation, so I cannot really say when, but I'll do my best. :)

Paolo

Re: Project idea: make QEMU more flexible

[Paolo Bonzini]

Il 07/01/2014 13:34, Wei Liu ha scritto:
> On Mon, Jan 06, 2014 at 09:53:37PM +0100, Paolo Bonzini wrote:
>> Il 06/01/2014 19:00, Andreas Färber ha scritto:
>>> Am 06.01.2014 16:39, schrieb Anthony Liguori:
>>>> We already have accel=xen.  I'm echoing Peter's suggestion of having the
>>>> ability to compile out accel=tcg.
>>>
>>> Didn't you and Paolo even have patches for that a while ago?
>>
>> Yes, but some code shuffling is required in each target to make sure you
>> can compile out translate-all.c, cputlb.c, etc.  So my patches only
>> worked for x86 at the time.
>>
> 
> Hi Paolo, I don't monitor qemu-devel on a daily basis. Do you have
> reference to your patches? Thanks.

Googling "disable tcg" would have provided an answer, but the patches
were old enough to be basically useless.  I'll refresh the current
version in the next few days.  Currently I am (or try to be) on
vacation, so I cannot really say when, but I'll do my best. :)

Paolo

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

[Peter Maydell]

On 7 January 2014 13:26, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 6 Jan 2014, Peter Maydell wrote:
>> The identifiers poisoned by include/qemu/poison.h are
>> an initial but not complete list. Host and target
>> endianness is a particularly obvious one, as is the
>> size of a target long. You may not use these things
>> in your Xen devices, but "qemu-system-null" implies
>> more than "weird special purpose thing which only
>> has Xen devices in it".
>
> I see your point.
> Could we allow target endinness and long size being selected at
> configure time for target-null?
> The default could be the same as the host, or could even be simply
> statically determined, maybe little endian, 4 bytes.

I think this is heading down the "weird special case for
Xen" path, which seems a bad idea. I'd rather see us
able to configure with "no tcg, no kvm" and "only
build in the devices for this minimal xen board",
which pretty much gets you to the same place without
adding a misleading target-null extra binary.

thanks
-- PMM

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

[Peter Maydell]

On 7 January 2014 13:26, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 6 Jan 2014, Peter Maydell wrote:
>> The identifiers poisoned by include/qemu/poison.h are
>> an initial but not complete list. Host and target
>> endianness is a particularly obvious one, as is the
>> size of a target long. You may not use these things
>> in your Xen devices, but "qemu-system-null" implies
>> more than "weird special purpose thing which only
>> has Xen devices in it".
>
> I see your point.
> Could we allow target endinness and long size being selected at
> configure time for target-null?
> The default could be the same as the host, or could even be simply
> statically determined, maybe little endian, 4 bytes.

I think this is heading down the "weird special case for
Xen" path, which seems a bad idea. I'd rather see us
able to configure with "no tcg, no kvm" and "only
build in the devices for this minimal xen board",
which pretty much gets you to the same place without
adding a misleading target-null extra binary.

thanks
-- PMM

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

[Wei Liu]

On Tue, Jan 07, 2014 at 02:32:38PM +0100, Paolo Bonzini wrote:
> Il 07/01/2014 13:34, Wei Liu ha scritto:
> > On Mon, Jan 06, 2014 at 09:53:37PM +0100, Paolo Bonzini wrote:
> >> Il 06/01/2014 19:00, Andreas Färber ha scritto:
> >>> Am 06.01.2014 16:39, schrieb Anthony Liguori:
> >>>> We already have accel=xen.  I'm echoing Peter's suggestion of having the
> >>>> ability to compile out accel=tcg.
> >>>
> >>> Didn't you and Paolo even have patches for that a while ago?
> >>
> >> Yes, but some code shuffling is required in each target to make sure you
> >> can compile out translate-all.c, cputlb.c, etc.  So my patches only
> >> worked for x86 at the time.
> >>
> > 
> > Hi Paolo, I don't monitor qemu-devel on a daily basis. Do you have
> > reference to your patches? Thanks.
> 
> Googling "disable tcg" would have provided an answer, but the patches
> were old enough to be basically useless.  I'll refresh the current
> version in the next few days.  Currently I am (or try to be) on
> vacation, so I cannot really say when, but I'll do my best. :)
> 

Thanks. I found them. Enjoy your vacation!

Wei.

> Paolo

Re: Project idea: make QEMU more flexible

[Wei Liu]

On Tue, Jan 07, 2014 at 02:32:38PM +0100, Paolo Bonzini wrote:
> Il 07/01/2014 13:34, Wei Liu ha scritto:
> > On Mon, Jan 06, 2014 at 09:53:37PM +0100, Paolo Bonzini wrote:
> >> Il 06/01/2014 19:00, Andreas Färber ha scritto:
> >>> Am 06.01.2014 16:39, schrieb Anthony Liguori:
> >>>> We already have accel=xen.  I'm echoing Peter's suggestion of having the
> >>>> ability to compile out accel=tcg.
> >>>
> >>> Didn't you and Paolo even have patches for that a while ago?
> >>
> >> Yes, but some code shuffling is required in each target to make sure you
> >> can compile out translate-all.c, cputlb.c, etc.  So my patches only
> >> worked for x86 at the time.
> >>
> > 
> > Hi Paolo, I don't monitor qemu-devel on a daily basis. Do you have
> > reference to your patches? Thanks.
> 
> Googling "disable tcg" would have provided an answer, but the patches
> were old enough to be basically useless.  I'll refresh the current
> version in the next few days.  Currently I am (or try to be) on
> vacation, so I cannot really say when, but I'll do my best. :)
> 

Thanks. I found them. Enjoy your vacation!

Wei.

> Paolo

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

[Paolo Bonzini]

Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
> > The identifiers poisoned by include/qemu/poison.h are
> > an initial but not complete list. Host and target
> > endianness is a particularly obvious one, as is the
> > size of a target long. You may not use these things
> > in your Xen devices, but "qemu-system-null" implies
> > more than "weird special purpose thing which only
> > has Xen devices in it".
> 
> I see your point.
> Could we allow target endinness and long size being selected at
> configure time for target-null?
> The default could be the same as the host, or could even be simply
> statically determined, maybe little endian, 4 bytes.

For Xen both long sizes are already supported by the block backend.  Are
there still guests that use BLKIF_PROTOCOL_NATIVE?  If not, long size
might not matter at all.

And if in the future Xen were to grow support for a big-endian target,
you could either enforce little-endian for the ring buffers, or
negotiate it in xenstore like you do for sizeof(long).

So let's call things by their name and add qemu-system-xenpv that covers
both x86 and ARM and anything else in the future.  Phasing out the
i386/x86_64 xenpv machine type makes total sense if the exact same code
can support ARM PV domains too.  This machine would only be compiled if
you had support for Xen.  My current patches have:

supported_target() {
    test "$tcg" = "yes" && return 0
    supported_kvm_target && return 0
    supported_xen_target && return 0
    return 1
}

but adding a more refined test for supported-on-TCG would be easy.

Paolo

Re: Project idea: make QEMU more flexible

[Paolo Bonzini]

Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
> > The identifiers poisoned by include/qemu/poison.h are
> > an initial but not complete list. Host and target
> > endianness is a particularly obvious one, as is the
> > size of a target long. You may not use these things
> > in your Xen devices, but "qemu-system-null" implies
> > more than "weird special purpose thing which only
> > has Xen devices in it".
> 
> I see your point.
> Could we allow target endinness and long size being selected at
> configure time for target-null?
> The default could be the same as the host, or could even be simply
> statically determined, maybe little endian, 4 bytes.

For Xen both long sizes are already supported by the block backend.  Are
there still guests that use BLKIF_PROTOCOL_NATIVE?  If not, long size
might not matter at all.

And if in the future Xen were to grow support for a big-endian target,
you could either enforce little-endian for the ring buffers, or
negotiate it in xenstore like you do for sizeof(long).

So let's call things by their name and add qemu-system-xenpv that covers
both x86 and ARM and anything else in the future.  Phasing out the
i386/x86_64 xenpv machine type makes total sense if the exact same code
can support ARM PV domains too.  This machine would only be compiled if
you had support for Xen.  My current patches have:

supported_target() {
    test "$tcg" = "yes" && return 0
    supported_kvm_target && return 0
    supported_xen_target && return 0
    return 1
}

but adding a more refined test for supported-on-TCG would be easy.

Paolo

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

[Stefano Stabellini]

On Tue, 7 Jan 2014, Paolo Bonzini wrote:
> Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
> > > The identifiers poisoned by include/qemu/poison.h are
> > > an initial but not complete list. Host and target
> > > endianness is a particularly obvious one, as is the
> > > size of a target long. You may not use these things
> > > in your Xen devices, but "qemu-system-null" implies
> > > more than "weird special purpose thing which only
> > > has Xen devices in it".
> > 
> > I see your point.
> > Could we allow target endinness and long size being selected at
> > configure time for target-null?
> > The default could be the same as the host, or could even be simply
> > statically determined, maybe little endian, 4 bytes.
> 
> For Xen both long sizes are already supported by the block backend.  Are
> there still guests that use BLKIF_PROTOCOL_NATIVE?  If not, long size
> might not matter at all.
> 
> And if in the future Xen were to grow support for a big-endian target,
> you could either enforce little-endian for the ring buffers, or
> negotiate it in xenstore like you do for sizeof(long).
> 
> So let's call things by their name and add qemu-system-xenpv that covers
> both x86 and ARM and anything else in the future.  Phasing out the
> i386/x86_64 xenpv machine type makes total sense if the exact same code
> can support ARM PV domains too.  This machine would only be compiled if
> you had support for Xen.

I agree with you, I would be happy with this solution.



> My current patches have:
> 
> supported_target() {
>     test "$tcg" = "yes" && return 0
>     supported_kvm_target && return 0
>     supported_xen_target && return 0
>     return 1
> }
> 
> but adding a more refined test for supported-on-TCG would be easy.

Re: Project idea: make QEMU more flexible

[Stefano Stabellini]

On Tue, 7 Jan 2014, Paolo Bonzini wrote:
> Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
> > > The identifiers poisoned by include/qemu/poison.h are
> > > an initial but not complete list. Host and target
> > > endianness is a particularly obvious one, as is the
> > > size of a target long. You may not use these things
> > > in your Xen devices, but "qemu-system-null" implies
> > > more than "weird special purpose thing which only
> > > has Xen devices in it".
> > 
> > I see your point.
> > Could we allow target endinness and long size being selected at
> > configure time for target-null?
> > The default could be the same as the host, or could even be simply
> > statically determined, maybe little endian, 4 bytes.
> 
> For Xen both long sizes are already supported by the block backend.  Are
> there still guests that use BLKIF_PROTOCOL_NATIVE?  If not, long size
> might not matter at all.
> 
> And if in the future Xen were to grow support for a big-endian target,
> you could either enforce little-endian for the ring buffers, or
> negotiate it in xenstore like you do for sizeof(long).
> 
> So let's call things by their name and add qemu-system-xenpv that covers
> both x86 and ARM and anything else in the future.  Phasing out the
> i386/x86_64 xenpv machine type makes total sense if the exact same code
> can support ARM PV domains too.  This machine would only be compiled if
> you had support for Xen.

I agree with you, I would be happy with this solution.



> My current patches have:
> 
> supported_target() {
>     test "$tcg" = "yes" && return 0
>     supported_kvm_target && return 0
>     supported_xen_target && return 0
>     return 1
> }
> 
> but adding a more refined test for supported-on-TCG would be easy.

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

[Wei Liu]

On Tue, Jan 07, 2014 at 02:50:12PM +0100, Paolo Bonzini wrote:
> Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
> > > The identifiers poisoned by include/qemu/poison.h are
> > > an initial but not complete list. Host and target
> > > endianness is a particularly obvious one, as is the
> > > size of a target long. You may not use these things
> > > in your Xen devices, but "qemu-system-null" implies
> > > more than "weird special purpose thing which only
> > > has Xen devices in it".
> > 
> > I see your point.
> > Could we allow target endinness and long size being selected at
> > configure time for target-null?
> > The default could be the same as the host, or could even be simply
> > statically determined, maybe little endian, 4 bytes.
> 
> For Xen both long sizes are already supported by the block backend.  Are
> there still guests that use BLKIF_PROTOCOL_NATIVE?  If not, long size
> might not matter at all.
> 
> And if in the future Xen were to grow support for a big-endian target,
> you could either enforce little-endian for the ring buffers, or
> negotiate it in xenstore like you do for sizeof(long).
> 
> So let's call things by their name and add qemu-system-xenpv that covers
> both x86 and ARM and anything else in the future.  Phasing out the

I think this makes sense. But does it deserve to be in default-configs/? It
will become default-configs/xenpv-softmmu.mak and target-xenpv shall be
created.

> i386/x86_64 xenpv machine type makes total sense if the exact same code
> can support ARM PV domains too.  This machine would only be compiled if
> you had support for Xen.  My current patches have:
> 
> supported_target() {
>     test "$tcg" = "yes" && return 0
>     supported_kvm_target && return 0
>     supported_xen_target && return 0
>     return 1
> }
> 
> but adding a more refined test for supported-on-TCG would be easy.
> 

I think implementing qemu-system-xenpv will be easier after your TCG
series goes in. In that case I don't need to worry about TCG stubs
anymore.

Wei.

> Paolo

Re: Project idea: make QEMU more flexible

[Wei Liu]

On Tue, Jan 07, 2014 at 02:50:12PM +0100, Paolo Bonzini wrote:
> Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
> > > The identifiers poisoned by include/qemu/poison.h are
> > > an initial but not complete list. Host and target
> > > endianness is a particularly obvious one, as is the
> > > size of a target long. You may not use these things
> > > in your Xen devices, but "qemu-system-null" implies
> > > more than "weird special purpose thing which only
> > > has Xen devices in it".
> > 
> > I see your point.
> > Could we allow target endinness and long size being selected at
> > configure time for target-null?
> > The default could be the same as the host, or could even be simply
> > statically determined, maybe little endian, 4 bytes.
> 
> For Xen both long sizes are already supported by the block backend.  Are
> there still guests that use BLKIF_PROTOCOL_NATIVE?  If not, long size
> might not matter at all.
> 
> And if in the future Xen were to grow support for a big-endian target,
> you could either enforce little-endian for the ring buffers, or
> negotiate it in xenstore like you do for sizeof(long).
> 
> So let's call things by their name and add qemu-system-xenpv that covers
> both x86 and ARM and anything else in the future.  Phasing out the

I think this makes sense. But does it deserve to be in default-configs/? It
will become default-configs/xenpv-softmmu.mak and target-xenpv shall be
created.

> i386/x86_64 xenpv machine type makes total sense if the exact same code
> can support ARM PV domains too.  This machine would only be compiled if
> you had support for Xen.  My current patches have:
> 
> supported_target() {
>     test "$tcg" = "yes" && return 0
>     supported_kvm_target && return 0
>     supported_xen_target && return 0
>     return 1
> }
> 
> but adding a more refined test for supported-on-TCG would be easy.
> 

I think implementing qemu-system-xenpv will be easier after your TCG
series goes in. In that case I don't need to worry about TCG stubs
anymore.

Wei.

> Paolo

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

[Paolo Bonzini]

Il 07/01/2014 15:38, Wei Liu ha scritto:
> On Tue, Jan 07, 2014 at 02:50:12PM +0100, Paolo Bonzini wrote:
>> Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
>>>> The identifiers poisoned by include/qemu/poison.h are
>>>> an initial but not complete list. Host and target
>>>> endianness is a particularly obvious one, as is the
>>>> size of a target long. You may not use these things
>>>> in your Xen devices, but "qemu-system-null" implies
>>>> more than "weird special purpose thing which only
>>>> has Xen devices in it".
>>>
>>> I see your point.
>>> Could we allow target endinness and long size being selected at
>>> configure time for target-null?
>>> The default could be the same as the host, or could even be simply
>>> statically determined, maybe little endian, 4 bytes.
>>
>> For Xen both long sizes are already supported by the block backend.  Are
>> there still guests that use BLKIF_PROTOCOL_NATIVE?  If not, long size
>> might not matter at all.
>>
>> And if in the future Xen were to grow support for a big-endian target,
>> you could either enforce little-endian for the ring buffers, or
>> negotiate it in xenstore like you do for sizeof(long).
>>
>> So let's call things by their name and add qemu-system-xenpv that covers
>> both x86 and ARM and anything else in the future.  Phasing out the
> 
> I think this makes sense. But does it deserve to be in default-configs/?

Sure.  You could build a qemu-system-xenpv variant that doesn't have the
framebuffer, for example.

> It will become default-configs/xenpv-softmmu.mak and target-xenpv shall be
> created.

Yes, exactly.

> I think implementing qemu-system-xenpv will be easier after your TCG
> series goes in. In that case I don't need to worry about TCG stubs
> anymore.

Right.

Paolo

Re: Project idea: make QEMU more flexible

[Paolo Bonzini]

Il 07/01/2014 15:38, Wei Liu ha scritto:
> On Tue, Jan 07, 2014 at 02:50:12PM +0100, Paolo Bonzini wrote:
>> Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
>>>> The identifiers poisoned by include/qemu/poison.h are
>>>> an initial but not complete list. Host and target
>>>> endianness is a particularly obvious one, as is the
>>>> size of a target long. You may not use these things
>>>> in your Xen devices, but "qemu-system-null" implies
>>>> more than "weird special purpose thing which only
>>>> has Xen devices in it".
>>>
>>> I see your point.
>>> Could we allow target endinness and long size being selected at
>>> configure time for target-null?
>>> The default could be the same as the host, or could even be simply
>>> statically determined, maybe little endian, 4 bytes.
>>
>> For Xen both long sizes are already supported by the block backend.  Are
>> there still guests that use BLKIF_PROTOCOL_NATIVE?  If not, long size
>> might not matter at all.
>>
>> And if in the future Xen were to grow support for a big-endian target,
>> you could either enforce little-endian for the ring buffers, or
>> negotiate it in xenstore like you do for sizeof(long).
>>
>> So let's call things by their name and add qemu-system-xenpv that covers
>> both x86 and ARM and anything else in the future.  Phasing out the
> 
> I think this makes sense. But does it deserve to be in default-configs/?

Sure.  You could build a qemu-system-xenpv variant that doesn't have the
framebuffer, for example.

> It will become default-configs/xenpv-softmmu.mak and target-xenpv shall be
> created.

Yes, exactly.

> I think implementing qemu-system-xenpv will be easier after your TCG
> series goes in. In that case I don't need to worry about TCG stubs
> anymore.

Right.

Paolo

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

[Peter Maydell]

On 7 January 2014 13:50, Paolo Bonzini <pbonzini@redhat.com> wrote:
> So let's call things by their name and add qemu-system-xenpv that covers
> both x86 and ARM and anything else in the future.

How is this going to work? Do you define a fake architecture
name "xenpv" ?  I guess we'll see what the patches look like...

thanks
-- PMM

Re: Project idea: make QEMU more flexible

[Peter Maydell]

On 7 January 2014 13:50, Paolo Bonzini <pbonzini@redhat.com> wrote:
> So let's call things by their name and add qemu-system-xenpv that covers
> both x86 and ARM and anything else in the future.

How is this going to work? Do you define a fake architecture
name "xenpv" ?  I guess we'll see what the patches look like...

thanks
-- PMM

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

[Paolo Bonzini]

Il 07/01/2014 16:11, Peter Maydell ha scritto:
>> > So let's call things by their name and add qemu-system-xenpv that covers
>> > both x86 and ARM and anything else in the future.
> How is this going to work? Do you define a fake architecture
> name "xenpv" ?

Yes, one that aborts if a CPU is created or something like that.

Paolo

Re: Project idea: make QEMU more flexible

[Paolo Bonzini]

Il 07/01/2014 16:11, Peter Maydell ha scritto:
>> > So let's call things by their name and add qemu-system-xenpv that covers
>> > both x86 and ARM and anything else in the future.
> How is this going to work? Do you define a fake architecture
> name "xenpv" ?

Yes, one that aborts if a CPU is created or something like that.

Paolo

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

[Wei Liu]

On Tue, Jan 07, 2014 at 02:32:38PM +0100, Paolo Bonzini wrote:
> Il 07/01/2014 13:34, Wei Liu ha scritto:
> > On Mon, Jan 06, 2014 at 09:53:37PM +0100, Paolo Bonzini wrote:
> >> Il 06/01/2014 19:00, Andreas Färber ha scritto:
> >>> Am 06.01.2014 16:39, schrieb Anthony Liguori:
> >>>> We already have accel=xen.  I'm echoing Peter's suggestion of having the
> >>>> ability to compile out accel=tcg.
> >>>
> >>> Didn't you and Paolo even have patches for that a while ago?
> >>
> >> Yes, but some code shuffling is required in each target to make sure you
> >> can compile out translate-all.c, cputlb.c, etc.  So my patches only
> >> worked for x86 at the time.
> >>
> > 
> > Hi Paolo, I don't monitor qemu-devel on a daily basis. Do you have
> > reference to your patches? Thanks.
> 
> Googling "disable tcg" would have provided an answer, but the patches
> were old enough to be basically useless.  I'll refresh the current
> version in the next few days.  Currently I am (or try to be) on
> vacation, so I cannot really say when, but I'll do my best. :)
> 

Hi Paolo, any update?

Wei.

> Paolo

Re: Project idea: make QEMU more flexible

[Wei Liu]

On Tue, Jan 07, 2014 at 02:32:38PM +0100, Paolo Bonzini wrote:
> Il 07/01/2014 13:34, Wei Liu ha scritto:
> > On Mon, Jan 06, 2014 at 09:53:37PM +0100, Paolo Bonzini wrote:
> >> Il 06/01/2014 19:00, Andreas Färber ha scritto:
> >>> Am 06.01.2014 16:39, schrieb Anthony Liguori:
> >>>> We already have accel=xen.  I'm echoing Peter's suggestion of having the
> >>>> ability to compile out accel=tcg.
> >>>
> >>> Didn't you and Paolo even have patches for that a while ago?
> >>
> >> Yes, but some code shuffling is required in each target to make sure you
> >> can compile out translate-all.c, cputlb.c, etc.  So my patches only
> >> worked for x86 at the time.
> >>
> > 
> > Hi Paolo, I don't monitor qemu-devel on a daily basis. Do you have
> > reference to your patches? Thanks.
> 
> Googling "disable tcg" would have provided an answer, but the patches
> were old enough to be basically useless.  I'll refresh the current
> version in the next few days.  Currently I am (or try to be) on
> vacation, so I cannot really say when, but I'll do my best. :)
> 

Hi Paolo, any update?

Wei.

> Paolo

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

[Paolo Bonzini]

Il 21/01/2014 19:27, Wei Liu ha scritto:
>> >
>> > Googling "disable tcg" would have provided an answer, but the patches
>> > were old enough to be basically useless.  I'll refresh the current
>> > version in the next few days.  Currently I am (or try to be) on
>> > vacation, so I cannot really say when, but I'll do my best. :)
>> >
> Hi Paolo, any update?

Oops, sorry, I thought I had sent that out.  It's in the disable-tcg 
branch on my github repository.

Paolo

Re: Project idea: make QEMU more flexible

[Paolo Bonzini]

Il 21/01/2014 19:27, Wei Liu ha scritto:
>> >
>> > Googling "disable tcg" would have provided an answer, but the patches
>> > were old enough to be basically useless.  I'll refresh the current
>> > version in the next few days.  Currently I am (or try to be) on
>> > vacation, so I cannot really say when, but I'll do my best. :)
>> >
> Hi Paolo, any update?

Oops, sorry, I thought I had sent that out.  It's in the disable-tcg 
branch on my github repository.

Paolo

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

[Wei Liu]

On Wed, Jan 22, 2014 at 11:20:38AM +0100, Paolo Bonzini wrote:
> Il 21/01/2014 19:27, Wei Liu ha scritto:
> >>>
> >>> Googling "disable tcg" would have provided an answer, but the patches
> >>> were old enough to be basically useless.  I'll refresh the current
> >>> version in the next few days.  Currently I am (or try to be) on
> >>> vacation, so I cannot really say when, but I'll do my best. :)
> >>>
> >Hi Paolo, any update?
> 
> Oops, sorry, I thought I had sent that out.  It's in the disable-tcg
> branch on my github repository.
> 

Thanks. I will have a look.

Wei.

> Paolo

Re: Project idea: make QEMU more flexible

[Wei Liu]

On Wed, Jan 22, 2014 at 11:20:38AM +0100, Paolo Bonzini wrote:
> Il 21/01/2014 19:27, Wei Liu ha scritto:
> >>>
> >>> Googling "disable tcg" would have provided an answer, but the patches
> >>> were old enough to be basically useless.  I'll refresh the current
> >>> version in the next few days.  Currently I am (or try to be) on
> >>> vacation, so I cannot really say when, but I'll do my best. :)
> >>>
> >Hi Paolo, any update?
> 
> Oops, sorry, I thought I had sent that out.  It's in the disable-tcg
> branch on my github repository.
> 

Thanks. I will have a look.

Wei.

> Paolo

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

[Wei Liu]

On Wed, Jan 22, 2014 at 11:20:38AM +0100, Paolo Bonzini wrote:
> Il 21/01/2014 19:27, Wei Liu ha scritto:
> >>>
> >>> Googling "disable tcg" would have provided an answer, but the patches
> >>> were old enough to be basically useless.  I'll refresh the current
> >>> version in the next few days.  Currently I am (or try to be) on
> >>> vacation, so I cannot really say when, but I'll do my best. :)
> >>>
> >Hi Paolo, any update?
> 
> Oops, sorry, I thought I had sent that out.  It's in the disable-tcg
> branch on my github repository.
> 

Unfortunately your branch didn't work when I enabled TCG support. If I
use "--disable-tcg" with configure then it works fine.

A simple "make distclean; ./configure --target-list=i386-softmmu; make
-j16" gives following errors while linking.

  LINK  i386-softmmu/qemu-system-i386
gdbstub.o: In function `gdb_vm_state_change':
/local/scratch/qemu/gdbstub.c:1227: undefined reference to `tb_flush'
../vl.o: In function `tcg_init':
/local/scratch/qemu/vl.c:2614: undefined reference to `tcg_exec_init'
hw/i386/kvmvapic.o: In function `patch_instruction':
/local/scratch/qemu/hw/i386/kvmvapic.c:409: undefined reference to `cpu_restore_state'
/local/scratch/qemu/hw/i386/kvmvapic.c:451: undefined reference to `tb_gen_code'
/local/scratch/qemu/hw/i386/kvmvapic.c:452: undefined reference to `cpu_resume_from_signal'
target-i386/cpu.o: In function `x86_cpu_common_class_init':
/local/scratch/qemu/target-i386/cpu.c:2750: undefined reference to `x86_cpu_do_interrupt'
target-i386/cpu.o: In function `x86_cpu_reset':
/local/scratch/qemu/target-i386/cpu.c:2385: undefined reference to `tlb_flush'
target-i386/cpu.o: In function `x86_cpu_initfn':
/local/scratch/qemu/target-i386/cpu.c:2693: undefined reference to `optimize_flags_init'
/local/scratch/qemu/target-i386/cpu.c:2695: undefined reference to `breakpoint_handler'
/local/scratch/qemu/target-i386/cpu.c:2695: undefined reference to `cpu_set_debug_excp_handler'
cpus.o: In function `cpu_signal':
/local/scratch/qemu/cpus.c:569: undefined reference to `exit_request'
cpus.o: In function `qemu_tcg_cpu_thread_fn':
/local/scratch/qemu/cpus.c:946: undefined reference to `exit_request'
cpus.o: In function `tcg_cpu_exec':
/local/scratch/qemu/cpus.c:1257: undefined reference to `cpu_x86_exec'
exec.o: In function `cpu_common_post_load':
/local/scratch/qemu/exec.c:405: undefined reference to `tlb_flush'
exec.o: In function `tcg_commit':
/local/scratch/qemu/exec.c:1796: undefined reference to `tlb_flush'
exec.o: In function `invalidate_and_set_dirty':
/local/scratch/qemu/exec.c:1920: undefined reference to `tb_invalidate_phys_page_range'
exec.o: In function `check_watchpoint':
/local/scratch/qemu/exec.c:1556: undefined reference to `tb_check_watchpoint'
/local/scratch/qemu/exec.c:1559: undefined reference to `cpu_loop_exit'
/local/scratch/qemu/exec.c:1562: undefined reference to `tb_gen_code'
/local/scratch/qemu/exec.c:1563: undefined reference to `cpu_resume_from_signal'
exec.o: In function `cpu_watchpoint_insert':
/local/scratch/qemu/exec.c:532: undefined reference to `tlb_flush_page'
exec.o: In function `cpu_watchpoint_remove_by_ref':
/local/scratch/qemu/exec.c:561: undefined reference to `tlb_flush_page'
exec.o: In function `notdirty_mem_write':
/local/scratch/qemu/exec.c:1491: undefined reference to `tb_invalidate_phys_page_fast'
exec.o: In function `stl_phys_notdirty':
/local/scratch/qemu/exec.c:2535: undefined reference to `tb_invalidate_phys_page_range'
exec.o: In function `breakpoint_invalidate':
/local/scratch/qemu/exec.c:488: undefined reference to `tb_invalidate_phys_addr'
exec.o: In function `cpu_single_step':
/local/scratch/qemu/exec.c:664: undefined reference to `tb_flush'
exec.o: In function `tlb_reset_dirty_range_all':
/local/scratch/qemu/exec.c:736: undefined reference to `cpu_tlb_reset_dirty_all'
exec.o: In function `notdirty_mem_write':
/local/scratch/qemu/exec.c:1515: undefined reference to `tlb_set_dirty'
monitor.o: In function `do_info_jit':
/local/scratch/qemu/monitor.c:1120: undefined reference to `dump_exec_info'
target-i386/helper.o: In function `x86_cpu_set_a20':
/local/scratch/qemu/target-i386/helper.c:397: undefined reference to `tlb_flush'
target-i386/helper.o: In function `cpu_x86_update_cr0':
/local/scratch/qemu/target-i386/helper.c:411: undefined reference to `tlb_flush'
target-i386/helper.o: In function `cpu_x86_update_cr4':
/local/scratch/qemu/target-i386/helper.c:464: undefined reference to `tlb_flush'
target-i386/helper.o: In function `cpu_x86_handle_mmu_fault':
/local/scratch/qemu/target-i386/helper.c:862: undefined reference to `tlb_set_page'
target-i386/helper.o: In function `cpu_report_tpr_access':
/local/scratch/qemu/target-i386/helper.c:1224: undefined reference to `cpu_restore_state'
target-i386/helper.o: In function `cpu_x86_update_cr3':
/local/scratch/qemu/target-i386/helper.c:452: undefined reference to `tlb_flush'
target-i386/machine.o: In function `cpu_post_load':
/local/scratch/qemu/target-i386/machine.c:330: undefined reference to `tlb_flush'
collect2: error: ld returned 1 exit status
make[1]: *** [qemu-system-i386] Error 1
make: *** [subdir-i386-softmmu] Error 2


Wei.


> Paolo

Re: Project idea: make QEMU more flexible

[Wei Liu]

On Wed, Jan 22, 2014 at 11:20:38AM +0100, Paolo Bonzini wrote:
> Il 21/01/2014 19:27, Wei Liu ha scritto:
> >>>
> >>> Googling "disable tcg" would have provided an answer, but the patches
> >>> were old enough to be basically useless.  I'll refresh the current
> >>> version in the next few days.  Currently I am (or try to be) on
> >>> vacation, so I cannot really say when, but I'll do my best. :)
> >>>
> >Hi Paolo, any update?
> 
> Oops, sorry, I thought I had sent that out.  It's in the disable-tcg
> branch on my github repository.
> 

Unfortunately your branch didn't work when I enabled TCG support. If I
use "--disable-tcg" with configure then it works fine.

A simple "make distclean; ./configure --target-list=i386-softmmu; make
-j16" gives following errors while linking.

  LINK  i386-softmmu/qemu-system-i386
gdbstub.o: In function `gdb_vm_state_change':
/local/scratch/qemu/gdbstub.c:1227: undefined reference to `tb_flush'
../vl.o: In function `tcg_init':
/local/scratch/qemu/vl.c:2614: undefined reference to `tcg_exec_init'
hw/i386/kvmvapic.o: In function `patch_instruction':
/local/scratch/qemu/hw/i386/kvmvapic.c:409: undefined reference to `cpu_restore_state'
/local/scratch/qemu/hw/i386/kvmvapic.c:451: undefined reference to `tb_gen_code'
/local/scratch/qemu/hw/i386/kvmvapic.c:452: undefined reference to `cpu_resume_from_signal'
target-i386/cpu.o: In function `x86_cpu_common_class_init':
/local/scratch/qemu/target-i386/cpu.c:2750: undefined reference to `x86_cpu_do_interrupt'
target-i386/cpu.o: In function `x86_cpu_reset':
/local/scratch/qemu/target-i386/cpu.c:2385: undefined reference to `tlb_flush'
target-i386/cpu.o: In function `x86_cpu_initfn':
/local/scratch/qemu/target-i386/cpu.c:2693: undefined reference to `optimize_flags_init'
/local/scratch/qemu/target-i386/cpu.c:2695: undefined reference to `breakpoint_handler'
/local/scratch/qemu/target-i386/cpu.c:2695: undefined reference to `cpu_set_debug_excp_handler'
cpus.o: In function `cpu_signal':
/local/scratch/qemu/cpus.c:569: undefined reference to `exit_request'
cpus.o: In function `qemu_tcg_cpu_thread_fn':
/local/scratch/qemu/cpus.c:946: undefined reference to `exit_request'
cpus.o: In function `tcg_cpu_exec':
/local/scratch/qemu/cpus.c:1257: undefined reference to `cpu_x86_exec'
exec.o: In function `cpu_common_post_load':
/local/scratch/qemu/exec.c:405: undefined reference to `tlb_flush'
exec.o: In function `tcg_commit':
/local/scratch/qemu/exec.c:1796: undefined reference to `tlb_flush'
exec.o: In function `invalidate_and_set_dirty':
/local/scratch/qemu/exec.c:1920: undefined reference to `tb_invalidate_phys_page_range'
exec.o: In function `check_watchpoint':
/local/scratch/qemu/exec.c:1556: undefined reference to `tb_check_watchpoint'
/local/scratch/qemu/exec.c:1559: undefined reference to `cpu_loop_exit'
/local/scratch/qemu/exec.c:1562: undefined reference to `tb_gen_code'
/local/scratch/qemu/exec.c:1563: undefined reference to `cpu_resume_from_signal'
exec.o: In function `cpu_watchpoint_insert':
/local/scratch/qemu/exec.c:532: undefined reference to `tlb_flush_page'
exec.o: In function `cpu_watchpoint_remove_by_ref':
/local/scratch/qemu/exec.c:561: undefined reference to `tlb_flush_page'
exec.o: In function `notdirty_mem_write':
/local/scratch/qemu/exec.c:1491: undefined reference to `tb_invalidate_phys_page_fast'
exec.o: In function `stl_phys_notdirty':
/local/scratch/qemu/exec.c:2535: undefined reference to `tb_invalidate_phys_page_range'
exec.o: In function `breakpoint_invalidate':
/local/scratch/qemu/exec.c:488: undefined reference to `tb_invalidate_phys_addr'
exec.o: In function `cpu_single_step':
/local/scratch/qemu/exec.c:664: undefined reference to `tb_flush'
exec.o: In function `tlb_reset_dirty_range_all':
/local/scratch/qemu/exec.c:736: undefined reference to `cpu_tlb_reset_dirty_all'
exec.o: In function `notdirty_mem_write':
/local/scratch/qemu/exec.c:1515: undefined reference to `tlb_set_dirty'
monitor.o: In function `do_info_jit':
/local/scratch/qemu/monitor.c:1120: undefined reference to `dump_exec_info'
target-i386/helper.o: In function `x86_cpu_set_a20':
/local/scratch/qemu/target-i386/helper.c:397: undefined reference to `tlb_flush'
target-i386/helper.o: In function `cpu_x86_update_cr0':
/local/scratch/qemu/target-i386/helper.c:411: undefined reference to `tlb_flush'
target-i386/helper.o: In function `cpu_x86_update_cr4':
/local/scratch/qemu/target-i386/helper.c:464: undefined reference to `tlb_flush'
target-i386/helper.o: In function `cpu_x86_handle_mmu_fault':
/local/scratch/qemu/target-i386/helper.c:862: undefined reference to `tlb_set_page'
target-i386/helper.o: In function `cpu_report_tpr_access':
/local/scratch/qemu/target-i386/helper.c:1224: undefined reference to `cpu_restore_state'
target-i386/helper.o: In function `cpu_x86_update_cr3':
/local/scratch/qemu/target-i386/helper.c:452: undefined reference to `tlb_flush'
target-i386/machine.o: In function `cpu_post_load':
/local/scratch/qemu/target-i386/machine.c:330: undefined reference to `tlb_flush'
collect2: error: ld returned 1 exit status
make[1]: *** [qemu-system-i386] Error 1
make: *** [subdir-i386-softmmu] Error 2


Wei.


> Paolo

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

[Paolo Bonzini]

Il 22/01/2014 17:09, Wei Liu ha scritto:
> On Wed, Jan 22, 2014 at 11:20:38AM +0100, Paolo Bonzini wrote:
>> Il 21/01/2014 19:27, Wei Liu ha scritto:
>>>>>
>>>>> Googling "disable tcg" would have provided an answer, but the patches
>>>>> were old enough to be basically useless.  I'll refresh the current
>>>>> version in the next few days.  Currently I am (or try to be) on
>>>>> vacation, so I cannot really say when, but I'll do my best. :)
>>>>>
>>> Hi Paolo, any update?
>>
>> Oops, sorry, I thought I had sent that out.  It's in the disable-tcg
>> branch on my github repository.
>>
>
> Unfortunately your branch didn't work when I enabled TCG support. If I
> use "--disable-tcg" with configure then it works fine.

Branch fixed.

Paolo

Re: Project idea: make QEMU more flexible

[Paolo Bonzini]

Il 22/01/2014 17:09, Wei Liu ha scritto:
> On Wed, Jan 22, 2014 at 11:20:38AM +0100, Paolo Bonzini wrote:
>> Il 21/01/2014 19:27, Wei Liu ha scritto:
>>>>>
>>>>> Googling "disable tcg" would have provided an answer, but the patches
>>>>> were old enough to be basically useless.  I'll refresh the current
>>>>> version in the next few days.  Currently I am (or try to be) on
>>>>> vacation, so I cannot really say when, but I'll do my best. :)
>>>>>
>>> Hi Paolo, any update?
>>
>> Oops, sorry, I thought I had sent that out.  It's in the disable-tcg
>> branch on my github repository.
>>
>
> Unfortunately your branch didn't work when I enabled TCG support. If I
> use "--disable-tcg" with configure then it works fine.

Branch fixed.

Paolo

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

[Wei Liu]

On Thu, Jan 23, 2014 at 10:11:57AM +0100, Paolo Bonzini wrote:
> Il 22/01/2014 17:09, Wei Liu ha scritto:
> >On Wed, Jan 22, 2014 at 11:20:38AM +0100, Paolo Bonzini wrote:
> >>Il 21/01/2014 19:27, Wei Liu ha scritto:
> >>>>>
> >>>>>Googling "disable tcg" would have provided an answer, but the patches
> >>>>>were old enough to be basically useless.  I'll refresh the current
> >>>>>version in the next few days.  Currently I am (or try to be) on
> >>>>>vacation, so I cannot really say when, but I'll do my best. :)
> >>>>>
> >>>Hi Paolo, any update?
> >>
> >>Oops, sorry, I thought I had sent that out.  It's in the disable-tcg
> >>branch on my github repository.
> >>
> >
> >Unfortunately your branch didn't work when I enabled TCG support. If I
> >use "--disable-tcg" with configure then it works fine.
> 
> Branch fixed.
> 

Yes, it's fixed for the case I reported. Thanks.

But it is now broken with following rune:
./configure --enable-kvm --disable-tcg --target-list=i386-softmmu
--disable-xen --enable-debug

  LINK  i386-softmmu/qemu-system-i386
  cpus.o: In function `cpu_signal':
  /local/scratch/qemu/cpus.c:569: undefined reference to `exit_request'
  cpus.o: In function `tcg_cpu_exec':
  /local/scratch/qemu/cpus.c:1257: undefined reference to `cpu_x86_exec'
  cpus.o: In function `tcg_exec_all':
  /local/scratch/qemu/cpus.c:1282: undefined reference to `exit_request'
  /local/scratch/qemu/cpus.c:1299: undefined reference to `exit_request'
  exec.o: In function `tlb_reset_dirty_range_all':
  /local/scratch/qemu/exec.c:736: undefined reference to
  `cpu_tlb_reset_dirty_all'
  collect2: error: ld returned 1 exit status
  make[1]: *** [qemu-system-i386] Error 1
  make: *** [subdir-i386-softmmu] Error 2

--enable-debug is the one to blame. Without that it links successfully.

Wei.

> Paolo

Re: Project idea: make QEMU more flexible

[Wei Liu]

On Thu, Jan 23, 2014 at 10:11:57AM +0100, Paolo Bonzini wrote:
> Il 22/01/2014 17:09, Wei Liu ha scritto:
> >On Wed, Jan 22, 2014 at 11:20:38AM +0100, Paolo Bonzini wrote:
> >>Il 21/01/2014 19:27, Wei Liu ha scritto:
> >>>>>
> >>>>>Googling "disable tcg" would have provided an answer, but the patches
> >>>>>were old enough to be basically useless.  I'll refresh the current
> >>>>>version in the next few days.  Currently I am (or try to be) on
> >>>>>vacation, so I cannot really say when, but I'll do my best. :)
> >>>>>
> >>>Hi Paolo, any update?
> >>
> >>Oops, sorry, I thought I had sent that out.  It's in the disable-tcg
> >>branch on my github repository.
> >>
> >
> >Unfortunately your branch didn't work when I enabled TCG support. If I
> >use "--disable-tcg" with configure then it works fine.
> 
> Branch fixed.
> 

Yes, it's fixed for the case I reported. Thanks.

But it is now broken with following rune:
./configure --enable-kvm --disable-tcg --target-list=i386-softmmu
--disable-xen --enable-debug

  LINK  i386-softmmu/qemu-system-i386
  cpus.o: In function `cpu_signal':
  /local/scratch/qemu/cpus.c:569: undefined reference to `exit_request'
  cpus.o: In function `tcg_cpu_exec':
  /local/scratch/qemu/cpus.c:1257: undefined reference to `cpu_x86_exec'
  cpus.o: In function `tcg_exec_all':
  /local/scratch/qemu/cpus.c:1282: undefined reference to `exit_request'
  /local/scratch/qemu/cpus.c:1299: undefined reference to `exit_request'
  exec.o: In function `tlb_reset_dirty_range_all':
  /local/scratch/qemu/exec.c:736: undefined reference to
  `cpu_tlb_reset_dirty_all'
  collect2: error: ld returned 1 exit status
  make[1]: *** [qemu-system-i386] Error 1
  make: *** [subdir-i386-softmmu] Error 2

--enable-debug is the one to blame. Without that it links successfully.

Wei.

> Paolo

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

[Wei Liu]

On Thu, Jan 23, 2014 at 01:54:40PM +0000, Wei Liu wrote:
> On Thu, Jan 23, 2014 at 10:11:57AM +0100, Paolo Bonzini wrote:
> > Il 22/01/2014 17:09, Wei Liu ha scritto:
> > >On Wed, Jan 22, 2014 at 11:20:38AM +0100, Paolo Bonzini wrote:
> > >>Il 21/01/2014 19:27, Wei Liu ha scritto:
> > >>>>>
> > >>>>>Googling "disable tcg" would have provided an answer, but the patches
> > >>>>>were old enough to be basically useless.  I'll refresh the current
> > >>>>>version in the next few days.  Currently I am (or try to be) on
> > >>>>>vacation, so I cannot really say when, but I'll do my best. :)
> > >>>>>
> > >>>Hi Paolo, any update?
> > >>
> > >>Oops, sorry, I thought I had sent that out.  It's in the disable-tcg
> > >>branch on my github repository.
> > >>
> > >
> > >Unfortunately your branch didn't work when I enabled TCG support. If I
> > >use "--disable-tcg" with configure then it works fine.
> > 
> > Branch fixed.
> > 
> 
> Yes, it's fixed for the case I reported. Thanks.
> 
> But it is now broken with following rune:
> ./configure --enable-kvm --disable-tcg --target-list=i386-softmmu
> --disable-xen --enable-debug
> 
>   LINK  i386-softmmu/qemu-system-i386
>   cpus.o: In function `cpu_signal':
>   /local/scratch/qemu/cpus.c:569: undefined reference to `exit_request'
>   cpus.o: In function `tcg_cpu_exec':
>   /local/scratch/qemu/cpus.c:1257: undefined reference to `cpu_x86_exec'
>   cpus.o: In function `tcg_exec_all':
>   /local/scratch/qemu/cpus.c:1282: undefined reference to `exit_request'
>   /local/scratch/qemu/cpus.c:1299: undefined reference to `exit_request'
>   exec.o: In function `tlb_reset_dirty_range_all':
>   /local/scratch/qemu/exec.c:736: undefined reference to
>   `cpu_tlb_reset_dirty_all'
>   collect2: error: ld returned 1 exit status
>   make[1]: *** [qemu-system-i386] Error 1
>   make: *** [subdir-i386-softmmu] Error 2
> 
> --enable-debug is the one to blame. Without that it links successfully.
> 
> Wei.
> 

Finally I figured out what was wrong. Your patch series was relying on
compiler to aggresively optimize away unused code.

So when --enable-debug is set, compiler won't optimize away the dead
code, hence those undefine references. With any optimization option -O
you series compiles successfully.

Feel free to integrate my patch below, or fix those errors in the way
you see appropriate.

Wei.

---8<---
diff --git a/cpus.c b/cpus.c
index 508b26c..2cc841b 100644
--- a/cpus.c
+++ b/cpus.c
@@ -563,6 +563,9 @@ static void cpu_handle_guest_debug(CPUState *cpu)
 
 static void cpu_signal(int sig)
 {
+
+    assert(tcg_enabled());
+
     if (current_cpu) {
         cpu_exit(current_cpu);
     }
@@ -1226,6 +1229,8 @@ static int tcg_cpu_exec(CPUArchState *env)
     int64_t ti;
 #endif
 
+    assert(tcg_enabled());
+
 #ifdef CONFIG_PROFILER
     ti = profile_getclock();
 #endif
@@ -1273,6 +1278,8 @@ static void tcg_exec_all(void)
 {
     int r;
 
+    assert(tcg_enabled());
+
     /* Account partial waits to QEMU_CLOCK_VIRTUAL.  */
     qemu_clock_warp(QEMU_CLOCK_VIRTUAL);
 
diff --git a/tcg-stub.c b/tcg-stub.c
index a06070f..b14a21d 100644
--- a/tcg-stub.c
+++ b/tcg-stub.c
@@ -29,3 +29,7 @@ void tlb_set_page(CPUArchState *env, target_ulong vaddr,
 void tb_invalidate_phys_addr(hwaddr addr)
 {
 }
+
+void cpu_tlb_reset_dirty_all(ram_addr_t start1, ram_addr_t length)
+{
+}

Re: Project idea: make QEMU more flexible

[Wei Liu]

On Thu, Jan 23, 2014 at 01:54:40PM +0000, Wei Liu wrote:
> On Thu, Jan 23, 2014 at 10:11:57AM +0100, Paolo Bonzini wrote:
> > Il 22/01/2014 17:09, Wei Liu ha scritto:
> > >On Wed, Jan 22, 2014 at 11:20:38AM +0100, Paolo Bonzini wrote:
> > >>Il 21/01/2014 19:27, Wei Liu ha scritto:
> > >>>>>
> > >>>>>Googling "disable tcg" would have provided an answer, but the patches
> > >>>>>were old enough to be basically useless.  I'll refresh the current
> > >>>>>version in the next few days.  Currently I am (or try to be) on
> > >>>>>vacation, so I cannot really say when, but I'll do my best. :)
> > >>>>>
> > >>>Hi Paolo, any update?
> > >>
> > >>Oops, sorry, I thought I had sent that out.  It's in the disable-tcg
> > >>branch on my github repository.
> > >>
> > >
> > >Unfortunately your branch didn't work when I enabled TCG support. If I
> > >use "--disable-tcg" with configure then it works fine.
> > 
> > Branch fixed.
> > 
> 
> Yes, it's fixed for the case I reported. Thanks.
> 
> But it is now broken with following rune:
> ./configure --enable-kvm --disable-tcg --target-list=i386-softmmu
> --disable-xen --enable-debug
> 
>   LINK  i386-softmmu/qemu-system-i386
>   cpus.o: In function `cpu_signal':
>   /local/scratch/qemu/cpus.c:569: undefined reference to `exit_request'
>   cpus.o: In function `tcg_cpu_exec':
>   /local/scratch/qemu/cpus.c:1257: undefined reference to `cpu_x86_exec'
>   cpus.o: In function `tcg_exec_all':
>   /local/scratch/qemu/cpus.c:1282: undefined reference to `exit_request'
>   /local/scratch/qemu/cpus.c:1299: undefined reference to `exit_request'
>   exec.o: In function `tlb_reset_dirty_range_all':
>   /local/scratch/qemu/exec.c:736: undefined reference to
>   `cpu_tlb_reset_dirty_all'
>   collect2: error: ld returned 1 exit status
>   make[1]: *** [qemu-system-i386] Error 1
>   make: *** [subdir-i386-softmmu] Error 2
> 
> --enable-debug is the one to blame. Without that it links successfully.
> 
> Wei.
> 

Finally I figured out what was wrong. Your patch series was relying on
compiler to aggresively optimize away unused code.

So when --enable-debug is set, compiler won't optimize away the dead
code, hence those undefine references. With any optimization option -O
you series compiles successfully.

Feel free to integrate my patch below, or fix those errors in the way
you see appropriate.

Wei.

---8<---
diff --git a/cpus.c b/cpus.c
index 508b26c..2cc841b 100644
--- a/cpus.c
+++ b/cpus.c
@@ -563,6 +563,9 @@ static void cpu_handle_guest_debug(CPUState *cpu)
 
 static void cpu_signal(int sig)
 {
+
+    assert(tcg_enabled());
+
     if (current_cpu) {
         cpu_exit(current_cpu);
     }
@@ -1226,6 +1229,8 @@ static int tcg_cpu_exec(CPUArchState *env)
     int64_t ti;
 #endif
 
+    assert(tcg_enabled());
+
 #ifdef CONFIG_PROFILER
     ti = profile_getclock();
 #endif
@@ -1273,6 +1278,8 @@ static void tcg_exec_all(void)
 {
     int r;
 
+    assert(tcg_enabled());
+
     /* Account partial waits to QEMU_CLOCK_VIRTUAL.  */
     qemu_clock_warp(QEMU_CLOCK_VIRTUAL);
 
diff --git a/tcg-stub.c b/tcg-stub.c
index a06070f..b14a21d 100644
--- a/tcg-stub.c
+++ b/tcg-stub.c
@@ -29,3 +29,7 @@ void tlb_set_page(CPUArchState *env, target_ulong vaddr,
 void tb_invalidate_phys_addr(hwaddr addr)
 {
 }
+
+void cpu_tlb_reset_dirty_all(ram_addr_t start1, ram_addr_t length)
+{
+}

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

[Paolo Bonzini]

Il 23/01/2014 17:23, Wei Liu ha scritto:
> On Thu, Jan 23, 2014 at 01:54:40PM +0000, Wei Liu wrote:
>> On Thu, Jan 23, 2014 at 10:11:57AM +0100, Paolo Bonzini wrote:
>>> Il 22/01/2014 17:09, Wei Liu ha scritto:
>>>> On Wed, Jan 22, 2014 at 11:20:38AM +0100, Paolo Bonzini wrote:
>>>>> Il 21/01/2014 19:27, Wei Liu ha scritto:
>>>>>>>>
>>>>>>>> Googling "disable tcg" would have provided an answer, but the patches
>>>>>>>> were old enough to be basically useless.  I'll refresh the current
>>>>>>>> version in the next few days.  Currently I am (or try to be) on
>>>>>>>> vacation, so I cannot really say when, but I'll do my best. :)
>>>>>>>>
>>>>>> Hi Paolo, any update?
>>>>>
>>>>> Oops, sorry, I thought I had sent that out.  It's in the disable-tcg
>>>>> branch on my github repository.
>>>>>
>>>>
>>>> Unfortunately your branch didn't work when I enabled TCG support. If I
>>>> use "--disable-tcg" with configure then it works fine.
>>>
>>> Branch fixed.
>>>
>>
>> Yes, it's fixed for the case I reported. Thanks.
>>
>> But it is now broken with following rune:
>> ./configure --enable-kvm --disable-tcg --target-list=i386-softmmu
>> --disable-xen --enable-debug
>>
>>   LINK  i386-softmmu/qemu-system-i386
>>   cpus.o: In function `cpu_signal':
>>   /local/scratch/qemu/cpus.c:569: undefined reference to `exit_request'
>>   cpus.o: In function `tcg_cpu_exec':
>>   /local/scratch/qemu/cpus.c:1257: undefined reference to `cpu_x86_exec'
>>   cpus.o: In function `tcg_exec_all':
>>   /local/scratch/qemu/cpus.c:1282: undefined reference to `exit_request'
>>   /local/scratch/qemu/cpus.c:1299: undefined reference to `exit_request'
>>   exec.o: In function `tlb_reset_dirty_range_all':
>>   /local/scratch/qemu/exec.c:736: undefined reference to
>>   `cpu_tlb_reset_dirty_all'
>>   collect2: error: ld returned 1 exit status
>>   make[1]: *** [qemu-system-i386] Error 1
>>   make: *** [subdir-i386-softmmu] Error 2
>>
>> --enable-debug is the one to blame. Without that it links successfully.
>>
>> Wei.
>>
>
> Finally I figured out what was wrong. Your patch series was relying on
> compiler to aggresively optimize away unused code.
>
> So when --enable-debug is set, compiler won't optimize away the dead
> code, hence those undefine references. With any optimization option -O
> you series compiles successfully.
>
> Feel free to integrate my patch below, or fix those errors in the way
> you see appropriate.

Thanks!  I added stubs for all three undefined symbols in tcg-stub.c.

Another way to fix it would be -ffunction-sections/-Wl,--gc-sections 
(which shaves 200k more out of the .text section), but that breaks glibc 
static linking.

Paolo

Re: Project idea: make QEMU more flexible

[Paolo Bonzini]

Il 23/01/2014 17:23, Wei Liu ha scritto:
> On Thu, Jan 23, 2014 at 01:54:40PM +0000, Wei Liu wrote:
>> On Thu, Jan 23, 2014 at 10:11:57AM +0100, Paolo Bonzini wrote:
>>> Il 22/01/2014 17:09, Wei Liu ha scritto:
>>>> On Wed, Jan 22, 2014 at 11:20:38AM +0100, Paolo Bonzini wrote:
>>>>> Il 21/01/2014 19:27, Wei Liu ha scritto:
>>>>>>>>
>>>>>>>> Googling "disable tcg" would have provided an answer, but the patches
>>>>>>>> were old enough to be basically useless.  I'll refresh the current
>>>>>>>> version in the next few days.  Currently I am (or try to be) on
>>>>>>>> vacation, so I cannot really say when, but I'll do my best. :)
>>>>>>>>
>>>>>> Hi Paolo, any update?
>>>>>
>>>>> Oops, sorry, I thought I had sent that out.  It's in the disable-tcg
>>>>> branch on my github repository.
>>>>>
>>>>
>>>> Unfortunately your branch didn't work when I enabled TCG support. If I
>>>> use "--disable-tcg" with configure then it works fine.
>>>
>>> Branch fixed.
>>>
>>
>> Yes, it's fixed for the case I reported. Thanks.
>>
>> But it is now broken with following rune:
>> ./configure --enable-kvm --disable-tcg --target-list=i386-softmmu
>> --disable-xen --enable-debug
>>
>>   LINK  i386-softmmu/qemu-system-i386
>>   cpus.o: In function `cpu_signal':
>>   /local/scratch/qemu/cpus.c:569: undefined reference to `exit_request'
>>   cpus.o: In function `tcg_cpu_exec':
>>   /local/scratch/qemu/cpus.c:1257: undefined reference to `cpu_x86_exec'
>>   cpus.o: In function `tcg_exec_all':
>>   /local/scratch/qemu/cpus.c:1282: undefined reference to `exit_request'
>>   /local/scratch/qemu/cpus.c:1299: undefined reference to `exit_request'
>>   exec.o: In function `tlb_reset_dirty_range_all':
>>   /local/scratch/qemu/exec.c:736: undefined reference to
>>   `cpu_tlb_reset_dirty_all'
>>   collect2: error: ld returned 1 exit status
>>   make[1]: *** [qemu-system-i386] Error 1
>>   make: *** [subdir-i386-softmmu] Error 2
>>
>> --enable-debug is the one to blame. Without that it links successfully.
>>
>> Wei.
>>
>
> Finally I figured out what was wrong. Your patch series was relying on
> compiler to aggresively optimize away unused code.
>
> So when --enable-debug is set, compiler won't optimize away the dead
> code, hence those undefine references. With any optimization option -O
> you series compiles successfully.
>
> Feel free to integrate my patch below, or fix those errors in the way
> you see appropriate.

Thanks!  I added stubs for all three undefined symbols in tcg-stub.c.

Another way to fix it would be -ffunction-sections/-Wl,--gc-sections 
(which shaves 200k more out of the .text section), but that breaks glibc 
static linking.

Paolo