qemu-kvm-0.13.0-rc1

qemu-kvm-0.13.0-rc1 is now available. This release is based on the upstream qemu 0.13.0-rc1, plus kvm-specific enhancements.

This release can be used with the kvm kernel modules provided by your distribution kernel, or by the modules in the kvm-kmod package, such as kvm-kmod-2.6.35.

Please help with testing for a stable 0.13.0 release.

Quoted 3 lines · Marcelo Tosatti

qemu-kvm-0.13.0-rc1 is now available. This release is based on the upstream qemu 0.13.0-rc1, plus kvm-specific enhancements.

Quoted 6 lines

This release can be used with the kvm kernel modules provided by your distribution kernel, or by the modules in the kvm-kmod package, such as kvm-kmod-2.6.35.

Please help with testing for a stable 0.13.0 release.

The build fails when configure flag --disable-cpu-emulation is used:

...

   CC    x86_64-softmmu/pcspk.o
   CC    x86_64-softmmu/i8254.o
   CC    x86_64-softmmu/i8254-kvm.o
   CC    x86_64-softmmu/device-assignment.o
   LINK  x86_64-softmmu/qemu-system-x86_64

exec.o: In function `cpu_exec_init_all':
/home/kvm/qemu-kvm/exec.c:585: undefined reference to tcg_ctx' /home/kvm/qemu-kvm/exec.c:585: undefined reference to tcg_prologue_init'
collect2: ld returned 1 exit status
make[1]: *** [qemu-system-x86_64] Error 1
make: *** [subdir-x86_64-softmmu] Error 2
LINK x86_64-softmmu/qemu-system-x86_64
exec.o: In function `cpu_exec_init_all':
/home/kvm/qemu-kvm/exec.c:585: undefined reference to tcg_ctx' /home/kvm/qemu-kvm/exec.c:585: undefined reference to tcg_prologue_init'
collect2: ld returned 1 exit status
make[1]: *** [qemu-system-x86_64] Error 1
make: *** [subdir-x86_64-softmmu] Error 2

When line 585 'tcg_prologue_init(&tcg_ctx);' is removed, the compilation succeeds and only one non-fatal warning remains:
/home/kvm/qemu-kvm/target-i386/fake-exec.c:26: warning: no previous prototype for ‘code_gen_max_block_size’
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 4 lines · Arjan Koers

Quoted 3 lines · Marcelo Tosatti

qemu-kvm-0.13.0-rc1 is now available. This release is based on the upstream qemu 0.13.0-rc1, plus kvm-specific enhancements.

Quoted 6 lines

Quoted 5 lines

This release can be used with the kvm kernel modules provided by your distribution kernel, or by the modules in the kvm-kmod package, such as kvm-kmod-2.6.35.

Please help with testing for a stable 0.13.0 release.

The build fails when configure flag --disable-cpu-emulation is used:

That flag needs to go away.

Quoted 9 lines · Anthony Liguori

Quoted 8 lines · Arjan Koers

Quoted 7 lines · Marcelo Tosatti

qemu-kvm-0.13.0-rc1 is now available. This release is based on the upstream qemu 0.13.0-rc1, plus kvm-specific enhancements.

This release can be used with the kvm kernel modules provided by your distribution kernel, or by the modules in the kvm-kmod package, such as kvm-kmod-2.6.35.

Quoted 5 lines

Quoted 2 lines

Quoted 1 line

Please help with testing for a stable 0.13.0 release.

The build fails when configure flag --disable-cpu-emulation is used:

That flag needs to go away.

It's perfectly reasonable to want to avoid building the tcg code if you aren't going to use it.

Quoted 1 line

It's perfectly reasonable to want to avoid building the tcg code if you aren't going to use it.

Why? It doesn't do any harm to have extra code.

Quoted 4 lines · Anthony Liguori

Quoted 2 lines

It's perfectly reasonable to want to avoid building the tcg code if you aren't going to use it.

Why? It doesn't do any harm to have extra code.

It's half a megabyte of code.

Also, it's better not to have code
snippets that call mprotect(PROT_EXEC) in your executable.

Quoted 9 lines · * Avi Kivity ([email protected]) wrote:

Quoted 5 lines · Anthony Liguori

Quoted 3 lines

It's perfectly reasonable to want to avoid building the tcg code if you aren't going to use it.

Why? It doesn't do any harm to have extra code.

It's half a megabyte of code.

And half a day to compile ;)

Quoted 3 lines

Also, it's better not to have code
snippets that call mprotect(PROT_EXEC) in your executable.

I agree, is there any reason not to enable compiling less into the binary? There are folks interested in eliminating as much as possible to reduce the attack surface and auditing requirements, for example.

thanks,
-chris

Quoted 10 lines · Chris Wright

Quoted 5 lines · * Avi Kivity ([email protected]) wrote:

Quoted 3 lines · Anthony Liguori

Quoted 2 lines

It's perfectly reasonable to want to avoid building the tcg code if you aren't going to use it.

Why? It doesn't do any harm to have extra code.

It's half a megabyte of code.

And half a day to compile ;)

Quoted 2 lines

Also, it's better not to have code
snippets that call mprotect(PROT_EXEC) in your executable.

Quoted 3 lines

I agree, is there any reason not to enable compiling less into the binary? There are folks interested in eliminating as much as possible to reduce the attack surface and auditing requirements, for example.

It's not a bad idea, it's just that what --disable-cpu-emulation does is evil. Being that I wrote the implementation, I'm quite confident in declare it as such :-)

It was initially a work around in the dyngen days because a GCC 3.x compiler wasn't available for PPC 44x easily. It's always been the wrong approach to addressing the problem though and since we don't have weird compiler dependencies anymore we really should remove it.

Quoted 3 lines

I agree, is there any reason not to enable compiling less into the binary? There are folks interested in eliminating as much as possible to reduce the attack surface and auditing requirements, for example.

It's not a bad idea, it's just that what --disable-cpu-emulation does is evil. Being that I wrote the implementation, I'm quite confident in declare it as such :-)

Quoted 6 lines · Anthony Liguori

Quoted 3 lines

I agree, is there any reason not to enable compiling less into the binary? There are folks interested in eliminating as much as possible to reduce the attack surface and auditing requirements, for example.

It's not a bad idea, it's just that what --disable-cpu-emulation does is evil. Being that I wrote the implementation, I'm quite confident in declare it as such :-)

Oh, I thought you were against the idea in itself for some reason.

I'll patch it for 0.13, but any ideas on how it should be rework for master?

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Anthony Liguori

Quoted 3 lines

I agree, is there any reason not to enable compiling less into the binary? There are folks interested in eliminating as much as possible to reduce the attack surface and auditing requirements, for example.

Quoted 6 lines

Quoted 2 lines

It's not a bad idea, it's just that what --disable-cpu-emulation does is evil. Being that I wrote the implementation, I'm quite confident in declare it as such :-)

Oh, I thought you were against the idea in itself for some reason.

I'll patch it for 0.13, but any ideas on how it should be rework for master?

Glauber's old Accel interface was close to the right approach. We need to abstract the exec.c interfaces to use a function pointer table and have a TCG and KVM implementation. The function pointer tables can then be registered by a module_init() and we can simply not include the kvm or TCG files are build time to disable the functionality.

Quoted 18 lines · Anthony Liguori

Quoted 12 lines · Avi Kivity

Quoted 10 lines · Anthony Liguori

Quoted 5 lines

I agree, is there any reason not to enable compiling less into the binary?
There are folks interested in eliminating as much as possible to reduce
the attack surface and auditing requirements, for example.

It's not a bad idea, it's just that what --disable-cpu-emulation does is evil. Being that I wrote the implementation, I'm quite confident in declare it as such :-)

Quoted 4 lines

Oh, I thought you were against the idea in itself for some reason.

I'll patch it for 0.13, but any ideas on how it should be rework for master?

Quoted 6 lines

Glauber's old Accel interface was close to the right approach. We need to abstract the exec.c interfaces to use a function pointer table and have a TCG and KVM implementation. The function pointer tables can then be registered by a module_init() and we can simply not include the kvm or TCG files are build time to disable the functionality.

Yes, I remember it now.

Glauber, can you bring those patches back from the land of the dead?

Quoted 13 lines · Avi Kivity

Quoted 9 lines · Anthony Liguori

Quoted 4 lines

I agree, is there any reason not to enable compiling less into the binary?
There are folks interested in eliminating as much as possible to reduce the attack surface and auditing requirements, for example.

It's not a bad idea, it's just that what --disable-cpu-emulation does is evil. Being that I wrote the implementation, I'm quite confident in declare it as such :-)

Oh, I thought you were against the idea in itself for some reason.

Quoted 2 lines

I'll patch it for 0.13, but any ideas on how it should be rework for master?

Glauber's old Accel interface was close to the right approach. We need to abstract the exec.c interfaces to use a function pointer table and have a TCG and KVM implementation. The function pointer tables can then be registered by a module_init() and we can simply not include the kvm or TCG files are build time to disable the functionality.