[ANNOUNCE] qemu-kvm-0.13.0-rc1

[ANNOUNCE] qemu-kvm-0.13.0-rc1

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

Please help with testing for a stable 0.13.0 release.

http://www.linux-kvm.org

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Arjan Koers]

On 2010-09-08 18:29, Marcelo Tosatti wrote:
> 
> 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.

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’

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Anthony Liguori]

On 09/08/2010 03:05 PM, Arjan Koers wrote:
> On 2010-09-08 18:29, Marcelo Tosatti wrote:
>    
>> 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.
>>      
> The build fails when configure flag --disable-cpu-emulation is used:
>    

That flag needs to go away.

Regards,

Anthony Liguori

> ...
>    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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Avi Kivity]

  On 09/08/2010 11:33 PM, Anthony Liguori wrote:
> On 09/08/2010 03:05 PM, Arjan Koers wrote:
>> On 2010-09-08 18:29, Marcelo Tosatti wrote:
>>> 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.
>> 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.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Anthony Liguori]

On 09/09/2010 01:17 AM, Avi Kivity wrote:
>  On 09/08/2010 11:33 PM, Anthony Liguori wrote:
>> On 09/08/2010 03:05 PM, Arjan Koers wrote:
>>> On 2010-09-08 18:29, Marcelo Tosatti wrote:
>>>> 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.
>>> 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.

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

Regards,

Anthony Liguori

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Avi Kivity]

  On 09/09/2010 04:00 PM, Anthony Liguori wrote:
>> 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.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Chris Wright]

* Avi Kivity (avi@redhat.com) wrote:
>  On 09/09/2010 04:00 PM, Anthony Liguori wrote:
> >>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 ;)

> 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

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Anthony Liguori]

On 09/10/2010 02:31 PM, Chris Wright wrote:
> * Avi Kivity (avi@redhat.com) wrote:
>    
>>   On 09/09/2010 04:00 PM, Anthony Liguori wrote:
>>      
>>>> 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 ;)
>
>    
>> 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.
>    

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.

Regards,

Anthony Liguori

> thanks,
> -chris
>    

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Chris Wright]

* Anthony Liguori (anthony@codemonkey.ws) wrote:
> On 09/10/2010 02:31 PM, Chris Wright wrote:
> >* Avi Kivity (avi@redhat.com) wrote:
> >>  On 09/09/2010 04:00 PM, Anthony Liguori wrote:
> >>>>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 ;)
> >
> >>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.
> 
> 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 :-)

Heh

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

OK, I see.  Thanks for clarifying.

thanks,
-chris

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Avi Kivity]

  On 09/10/2010 10:48 PM, Anthony Liguori wrote:
>> 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?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Anthony Liguori]

On 09/12/2010 01:11 AM, Avi Kivity wrote:
>  On 09/10/2010 10:48 PM, Anthony Liguori wrote:
>>> 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?

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.

Regards,

Anthony Liguori

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Avi Kivity]

  On 09/12/2010 05:31 PM, Anthony Liguori wrote:
> On 09/12/2010 01:11 AM, Avi Kivity wrote:
>>  On 09/10/2010 10:48 PM, Anthony Liguori wrote:
>>>> 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?
>
> 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?

-- 
error compiling committee.c: too many arguments to function

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Glauber Costa]

On Sun, Sep 12, 2010 at 05:59:45PM +0200, Avi Kivity wrote:
>  On 09/12/2010 05:31 PM, Anthony Liguori wrote:
> >On 09/12/2010 01:11 AM, Avi Kivity wrote:
> >> On 09/10/2010 10:48 PM, Anthony Liguori wrote:
> >>>>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?
> >
> >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?
I could, but I myself was not entirely sure about the correct approach
in terms of granularity.

The first version was too fine grained, since I was hooking into every possible
kqemu operation, (the goal at the time was to take _that_ out, not tcg), and 
then second version got too coarse, with we having to rewrite whole parts
of memory. Now that kqemu is gone, it surely gets easier...

Re: [ANNOUNCE] qemu-kvm-0.13.0-rc1

[Jan Kiszka]

Am 12.09.2010 17:31, Anthony Liguori wrote:
> On 09/12/2010 01:11 AM, Avi Kivity wrote:
>>  On 09/10/2010 10:48 PM, Anthony Liguori wrote:
>>>> 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?
> 
> 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.

Even more flexible would be to have them linked in on demand (as
specified on the command line). Additional, in certain contexts
unsupported features could then be shipped separately without having to
provide n versions of the common core. A second step to build-time
configurability, of course.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux