[Qemu-devel] KVM call minutes for Mar 8

[Qemu-devel] KVM call minutes for Mar 8

[Chris Wright]

QAPI merge plans
- should be 100% back compat
- qmp moved over
- hmp moved over
- 1st pass, core infrastructure (includes test framework)
- 2nd pass, command conversion
- 3rd pass, more controversial bits
- adds dependencies: glib and python
- some testing based on kvm-unit-test micro-os instance (e.g. added a balloon
  and run commands against it to test)
  - add more functionality here? (kvm autotest is slow, above is quick)
    - will hit some point where full functionality is needed
  - have a mini linux to do this (lags where driver updates are part of test)
- generated code can obfuscate the debugging process
  - code generator has some ugly corners (python writing C...)
  - but generated code should be debuggable, readable, etc.
- some grumbling regarding glib dependency
  - reducing NIH and relying on external functionality is solid way to
    grow qemu as a project

Read wiki here and review closely:

  http://wiki.qemu.org/Features/QAPI

virt-agent
- json string converted to command (and vice versa)
- add to qmp schema - allows generated marshalling code to sanity check in/out
- problem with qmp not being bi-directional (rpc - in, events - out)
  - posted events allow migration to save and send unposted events
- any issues with guest agent interface extensibility
  - will add command to return schema
  - can add (optional) parameters to commands
- make libqmp a shared object for 0.16 (too much going on for 0.15)
- can terminate in qemu (e.g. vnc server internally qmp client to interact
  with guest cut 'n paste) or externally proxying to/from endpoint
- possibly revisit dynamic schema in future

glib, main loop, events
- (context was setfd changes from amit)
- iothread work is more critical to do first and get merged
- glib work starting just in qapi

iothread merge?
- progressing slowly, marcelo working on it
- have found regressions (signal handling code) (ifdef'd away for now)

Re: [Qemu-devel] KVM call minutes for Mar 8

[Anthony Liguori]

On 03/08/2011 09:50 AM, Chris Wright wrote:
> QAPI merge plans
> - should be 100% back compat
> - qmp moved over
> - hmp moved over
> - 1st pass, core infrastructure (includes test framework)
> - 2nd pass, command conversion
> - 3rd pass, more controversial bits
> - adds dependencies: glib and python
> - some testing based on kvm-unit-test micro-os instance (e.g. added a balloon
>    and run commands against it to test)
>    - add more functionality here? (kvm autotest is slow, above is quick)
>      - will hit some point where full functionality is needed
>    - have a mini linux to do this (lags where driver updates are part of test)
> - generated code can obfuscate the debugging process
>    - code generator has some ugly corners (python writing C...)
>    - but generated code should be debuggable, readable, etc.
> - some grumbling regarding glib dependency
>    - reducing NIH and relying on external functionality is solid way to
>      grow qemu as a project
>
> Read wiki here and review closely:
>
>    http://wiki.qemu.org/Features/QAPI
>
> virt-agent
> - json string converted to command (and vice versa)
> - add to qmp schema - allows generated marshalling code to sanity check in/out
> - problem with qmp not being bi-directional (rpc - in, events - out)
>    - posted events allow migration to save and send unposted events
> - any issues with guest agent interface extensibility
>    - will add command to return schema
>    - can add (optional) parameters to commands
> - make libqmp a shared object for 0.16 (too much going on for 0.15)
> - can terminate in qemu (e.g. vnc server internally qmp client to interact
>    with guest cut 'n paste) or externally proxying to/from endpoint
> - possibly revisit dynamic schema in future

http://wiki.qemu.org/Features/QAPI/VirtAgent

BTW, would it make sense to start using etherpad to take notes for this 
call?

Regards,

Anthony Liguori

> glib, main loop, events
> - (context was setfd changes from amit)
> - iothread work is more critical to do first and get merged
> - glib work starting just in qapi
>
> iothread merge?
> - progressing slowly, marcelo working on it
> - have found regressions (signal handling code) (ifdef'd away for now)
>

Re: [Qemu-devel] KVM call minutes for Mar 8

[Stefan Hajnoczi]

On Tue, Mar 8, 2011 at 4:00 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> http://wiki.qemu.org/Features/QAPI/VirtAgent

That page does not exist.  I think you meant this one:
http://wiki.qemu.org/Features/QAPI/GuestAgent

Stefan

[Qemu-devel] Re: KVM call minutes for Mar 8

[Jan Kiszka]

On 2011-03-08 16:50, Chris Wright wrote:
> iothread merge?
> - progressing slowly, marcelo working on it
> - have found regressions (signal handling code) (ifdef'd away for now)

The regressions will automagically go away (to be replaced with others
then...) when the switch of qemu-kvm to upstream bits is performed. They
were related to qemu-kvm implementing iothread on top of non-threaded
qemu and /me not looking careful enough on the implications.

How this switch may look like can be seen here (slightly outdated version):

http://git.kiszka.org/?p=qemu-kvm.git;a=shortlog;h=refs/heads/queues/qemu-kvm-merge
git://git.kiszka.org/qemu-kvm.git queues/qemu-kvm-merge

Part V of KVM upstream patches is under review ATM. I can post v2 if no
one has further remarks. Then we could start with the review/merge work
on qemu-kvm.

The next time upstream will be involved again would be when preparing
its device models and adding "-machine xxx,kvm-irqchip=..." for
in-kernel irqchip support. That's more work, but it should not affect
the execution model anymore.

Jan

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

[Qemu-devel] Re: KVM call minutes for Mar 8

[Paolo Bonzini]

On 03/08/2011 05:51 PM, Jan Kiszka wrote:
>> >  iothread merge?
>> >  - progressing slowly, marcelo working on it
>> >  - have found regressions (signal handling code) (ifdef'd away for now)
> The regressions will automagically go away (to be replaced with others
> then...) when the switch of qemu-kvm to upstream bits is performed. They
> were related to qemu-kvm implementing iothread on top of non-threaded
> qemu and /me not looking careful enough on the implications.

The qemu.git bit seen with my win32 patch series should also be a 
regression from qemu-kvm.git to qemu.git, no?

(Sorry, not on the call today).

Paolo

[Qemu-devel] Re: KVM call minutes for Mar 8

[Jan Kiszka]

On 2011-03-08 17:58, Paolo Bonzini wrote:
> On 03/08/2011 05:51 PM, Jan Kiszka wrote:
>>>>  iothread merge?
>>>>  - progressing slowly, marcelo working on it
>>>>  - have found regressions (signal handling code) (ifdef'd away for now)
>> The regressions will automagically go away (to be replaced with others
>> then...) when the switch of qemu-kvm to upstream bits is performed. They
>> were related to qemu-kvm implementing iothread on top of non-threaded
>> qemu and /me not looking careful enough on the implications.
> 
> The qemu.git bit seen with my win32 patch series should also be a 
> regression from qemu-kvm.git to qemu.git, no?

Can't follow. What do you mean?

Jan

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

[Qemu-devel] Re: KVM call minutes for Mar 8

[Paolo Bonzini]

On 03/08/2011 06:10 PM, Jan Kiszka wrote:
> >  The qemu.git bit seen with my win32 patch series should also be a
> >  regression from qemu-kvm.git to qemu.git, no?
>
> Can't follow. What do you mean?

I didn't understand very well Avi and Marcelo's exchange, but this test 
definitely 1) fails with qemu iothread, 2) works with qemu non-iothread. 
  What I didn't understand is whether it works with qemu-kvm.

Paolo

[Qemu-devel] Re: KVM call minutes for Mar 8

[Jan Kiszka]

On 2011-03-08 18:15, Paolo Bonzini wrote:
> On 03/08/2011 06:10 PM, Jan Kiszka wrote:
>>>  The qemu.git bit seen with my win32 patch series should also be a
>>>  regression from qemu-kvm.git to qemu.git, no?
>>
>> Can't follow. What do you mean?
> 
> I didn't understand very well Avi and Marcelo's exchange, but this test 
> definitely 1) fails with qemu iothread, 2) works with qemu non-iothread. 
>   What I didn't understand is whether it works with qemu-kvm.

Are we talking about the failing Fedora installations? Or something else?

Jan

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

[Qemu-devel] Re: KVM call minutes for Mar 8

[Avi Kivity]

On 03/08/2011 07:21 PM, Jan Kiszka wrote:
> On 2011-03-08 18:15, Paolo Bonzini wrote:
> >  On 03/08/2011 06:10 PM, Jan Kiszka wrote:
> >>>   The qemu.git bit seen with my win32 patch series should also be a
> >>>   regression from qemu-kvm.git to qemu.git, no?
> >>
> >>  Can't follow. What do you mean?
> >
> >  I didn't understand very well Avi and Marcelo's exchange, but this test
> >  definitely 1) fails with qemu iothread, 2) works with qemu non-iothread.
> >    What I didn't understand is whether it works with qemu-kvm.

That was Paolo's patchset which I tested, yes?  I wasn't talking about 
that in the call.

> Are we talking about the failing Fedora installations? Or something else?

Something else - 27f368604a3d27ca4d.

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

[Qemu-devel] Re: KVM call minutes for Mar 8

[Avi Kivity]

On 03/08/2011 07:40 PM, Avi Kivity wrote:
> On 03/08/2011 07:21 PM, Jan Kiszka wrote:
>> On 2011-03-08 18:15, Paolo Bonzini wrote:
>> >  On 03/08/2011 06:10 PM, Jan Kiszka wrote:
>> >>>   The qemu.git bit seen with my win32 patch series should also be a
>> >>>   regression from qemu-kvm.git to qemu.git, no?
>> >>
>> >>  Can't follow. What do you mean?
>> >
>> >  I didn't understand very well Avi and Marcelo's exchange, but this 
>> test
>> >  definitely 1) fails with qemu iothread, 2) works with qemu 
>> non-iothread.
>> >    What I didn't understand is whether it works with qemu-kvm.
>
> That was Paolo's patchset which I tested, yes?  I wasn't talking about 
> that in the call.

Of course, this is an important issue in its own right.

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

[Qemu-devel] Re: KVM call minutes for Mar 8

[Jan Kiszka]

On 2011-03-08 18:41, Avi Kivity wrote:
> On 03/08/2011 07:40 PM, Avi Kivity wrote:
>> On 03/08/2011 07:21 PM, Jan Kiszka wrote:
>>> On 2011-03-08 18:15, Paolo Bonzini wrote:
>>>>  On 03/08/2011 06:10 PM, Jan Kiszka wrote:
>>>>>>   The qemu.git bit seen with my win32 patch series should also be a
>>>>>>   regression from qemu-kvm.git to qemu.git, no?
>>>>>
>>>>>  Can't follow. What do you mean?
>>>>
>>>>  I didn't understand very well Avi and Marcelo's exchange, but this 
>>> test
>>>>  definitely 1) fails with qemu iothread, 2) works with qemu 
>>> non-iothread.
>>>>    What I didn't understand is whether it works with qemu-kvm.
>>
>> That was Paolo's patchset which I tested, yes?  I wasn't talking about 
>> that in the call.
> 
> Of course, this is an important issue in its own right.

For sure, and it must also go in before starting to looki at glib
mainloops etc.

Jan

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

[Qemu-devel] Re: KVM call minutes for Mar 8

[Jan Kiszka]

On 2011-03-08 18:40, Avi Kivity wrote:
> On 03/08/2011 07:21 PM, Jan Kiszka wrote:
>> On 2011-03-08 18:15, Paolo Bonzini wrote:
>>>  On 03/08/2011 06:10 PM, Jan Kiszka wrote:
>>>>>   The qemu.git bit seen with my win32 patch series should also be a
>>>>>   regression from qemu-kvm.git to qemu.git, no?
>>>>
>>>>  Can't follow. What do you mean?
>>>
>>>  I didn't understand very well Avi and Marcelo's exchange, but this test
>>>  definitely 1) fails with qemu iothread, 2) works with qemu non-iothread.
>>>    What I didn't understand is whether it works with qemu-kvm.
> 
> That was Paolo's patchset which I tested, yes?  I wasn't talking about 
> that in the call.
> 
>> Are we talking about the failing Fedora installations? Or something else?
> 
> Something else - 27f368604a3d27ca4d.

I already thought so. But that is understood, fixed, and will be
obsoleted by the merge.

More interesting are open issues. Any news from that front?

Jan

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

[Qemu-devel] Re: KVM call minutes for Mar 8

[Avi Kivity]

On 03/08/2011 07:43 PM, Jan Kiszka wrote:
> >
> >  Something else - 27f368604a3d27ca4d.
>
> I already thought so. But that is understood, fixed, and will be
> obsoleted by the merge.

Ok, will look at your new stuff.

> More interesting are open issues. Any news from that front?
>

None known.

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

[Qemu-devel] Re: KVM call minutes for Mar 8

[Marcelo Tosatti]

On Tue, Mar 08, 2011 at 06:21:07PM +0100, Jan Kiszka wrote:
> On 2011-03-08 18:15, Paolo Bonzini wrote:
> > On 03/08/2011 06:10 PM, Jan Kiszka wrote:
> >>>  The qemu.git bit seen with my win32 patch series should also be a
> >>>  regression from qemu-kvm.git to qemu.git, no?
> >>
> >> Can't follow. What do you mean?
> > 
> > I didn't understand very well Avi and Marcelo's exchange, but this test 
> > definitely 1) fails with qemu iothread, 2) works with qemu non-iothread. 
> >   What I didn't understand is whether it works with qemu-kvm.
> 
> Are we talking about the failing Fedora installations? Or something else?
> 
> Jan

The failing Fedora installation problem is gone.

[Qemu-devel] Re: KVM call minutes for Mar 8

[Jan Kiszka]

On 2011-03-15 04:38, Marcelo Tosatti wrote:
> On Tue, Mar 08, 2011 at 06:21:07PM +0100, Jan Kiszka wrote:
>> On 2011-03-08 18:15, Paolo Bonzini wrote:
>>> On 03/08/2011 06:10 PM, Jan Kiszka wrote:
>>>>>  The qemu.git bit seen with my win32 patch series should also be a
>>>>>  regression from qemu-kvm.git to qemu.git, no?
>>>>
>>>> Can't follow. What do you mean?
>>>
>>> I didn't understand very well Avi and Marcelo's exchange, but this test 
>>> definitely 1) fails with qemu iothread, 2) works with qemu non-iothread. 
>>>   What I didn't understand is whether it works with qemu-kvm.
>>
>> Are we talking about the failing Fedora installations? Or something else?
>>
>> Jan
> 
> The failing Fedora installation problem is gone.

You lost it :), or was it solved?

Anyway, will now repost part V of upstream patches later today.

Jan

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

Re: [Qemu-devel] KVM call minutes for Mar 8

[Kevin Wolf]

Am 08.03.2011 16:50, schrieb Chris Wright:
> QAPI merge plans
> - should be 100% back compat
> - qmp moved over
> - hmp moved over
> - 1st pass, core infrastructure (includes test framework)
> - 2nd pass, command conversion
> - 3rd pass, more controversial bits
> - adds dependencies: glib and python
> - some testing based on kvm-unit-test micro-os instance (e.g. added a balloon
>   and run commands against it to test)
>   - add more functionality here? (kvm autotest is slow, above is quick)
>     - will hit some point where full functionality is needed
>   - have a mini linux to do this (lags where driver updates are part of test)

Depending on what we want to include in such tests, we might want to
have tests with a badly behaving kernel, which Linux hopefully isn't.

Kevin

Re: [Qemu-devel] KVM call minutes for Mar 8

[Anthony Liguori]

On 03/09/2011 03:25 AM, Kevin Wolf wrote:
> Am 08.03.2011 16:50, schrieb Chris Wright:
>> QAPI merge plans
>> - should be 100% back compat
>> - qmp moved over
>> - hmp moved over
>> - 1st pass, core infrastructure (includes test framework)
>> - 2nd pass, command conversion
>> - 3rd pass, more controversial bits
>> - adds dependencies: glib and python
>> - some testing based on kvm-unit-test micro-os instance (e.g. added a balloon
>>    and run commands against it to test)
>>    - add more functionality here? (kvm autotest is slow, above is quick)
>>      - will hit some point where full functionality is needed
>>    - have a mini linux to do this (lags where driver updates are part of test)
> Depending on what we want to include in such tests, we might want to
> have tests with a badly behaving kernel, which Linux hopefully isn't.

Yeah, that's a big advantage of kvm-unit-test is that you can't really 
hack the upstream version of virtio-balloon to do evil things.

Regards,

Anthony Liguori

> Kevin
>