[Qemu-devel] KVM call agenda for Mar 23

[Qemu-devel] KVM call agenda for Mar 23

[Chris Wright]

Please send in any agenda items you are interested in covering.

Yes, usability is a valid topic esp. if you promise to come w/ GUI patches.

thanks,
-chris

[Qemu-devel] Re: KVM call agenda for Mar 23

[Juan Quintela]

Chris Wright <chrisw@redhat.com> wrote:
> Please send in any agenda items you are interested in covering.
>
> Yes, usability is a valid topic esp. if you promise to come w/ GUI patches.

- migration (we didn't end last week)
- virtIODevice model (see Virtio cleaup thread).  What is the best model
  for this?

Later, Juan.

[Qemu-devel] Re: KVM call agenda for Mar 23

[Juan Quintela]

Juan Quintela <quintela@redhat.com> wrote:
> Chris Wright <chrisw@redhat.com> wrote:
>> Please send in any agenda items you are interested in covering.
>>
>> Yes, usability is a valid topic esp. if you promise to come w/ GUI patches.
>
> - migration (we didn't end last week)

I told last Tuesday that I will look at the latest vmstate changes
This is a search of VMSTATE/qemu_get() of commits of this year.

The Anthony/Avi? (I don't remember) of checking if feature was used
_before_ sending it would have fixed all of them.  Indeed the balloon
statistics one.

Problem is that if we go this route we need:
- subsections (is the easy way to go), almost there
- being able to change the version_id of the _current_ section.  That is
  _not easy_ with current design (we can't rewind the file).  That means
  that we need something like imprement vmstet_save() to a buffer, check
  the function there and push it from there.

This still don't fixes all problems, because what do we do when we have
two independent features and only one is needed?

vmstate-foo: id = 4

vmstate-foo: id = 5
  bar1 subsection (optional depending of this function)

vmstate-foo: id = 6
  bar1 subsection (optional depending of this function)
  bar2 subsection (optional depending of this other function)


what do we do if bar2 is needed but bar1 is not needed?

Other option is just sent:

vmstate-foo: id = 4
  bar1 subsection (optional depending of this function)
  bar2 subsection (optional depending of this other function)

(same version id for the general one).  As subsections would get a
 different id_section, that could even work on devices that don't know
 about this new sections, because they would find a ->section_id that
 they don't understand/don't expect there).

What do you think?

Later, Juan.


commit ed487bb1d69040b9dac64a4fc076d8dd82b131d6
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Thu Feb 11 18:19:44 2010 -0200

    ide save/restore pio/atapi cmd transfer fields and io buffer
    
    Save/restore information necessary to continue in progress PIO/ATAPI CMD
    transfers.
    
    This includes the IO buffer.

- we can test if lenght != 0 and not sent it in that case.  no infrastructure to do it otherwise.

commit 31827373f03b0ff1550d45ddef0ca1305a2ae70d
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Mon Dec 14 12:26:17 2009 +0100

    kvm: x86: Use separate exception_injected CPUState field
    
    Marcelo correctly remarked that there are usage conflicts between QEMU
    core code and KVM /wrt exception_index. So spend a separate field and
    also save/restore it properly.
    
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

- exception_index/injected, we "could" do same trick that for ide.

commit 1a03675db146dfc760b3b48b3448075189f142cc
Author: Glauber Costa <glommer@redhat.com>
Date:   Thu Oct 22 10:26:56 2009 -0200

    v2: properly save kvm system time msr registers

- avi states that a test if the msr has ever used could be used here


commit a0fb002c6462d21ceb9eac8c5772e469ec189374
Author: Jan Kiszka <jan.kiszka@web.de>
Date:   Wed Nov 25 00:33:03 2009 +0100

    kvm: x86: Add support for VCPU event states


I guess no way around for this one.  It could be disabled for non kvm users, but that is it.

balloon statistics:

commit 625a5befc2e3200b396594f002218d235e375da5
Author: Adam Litke <agl@us.ibm.com>
Date:   Tue Jan 26 14:17:35 2010 -0600

    virtio: Add memory statistics reporting to the balloon driver
    

In this case, I don't know what to do (notice that this bit has never been in stable and has
been dropped from qemu.git), it was wrong form other reasons.

[Qemu-devel] Re: KVM call agenda for Mar 23

[Jan Kiszka]

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

Chris Wright wrote:
> Please send in any agenda items you are interested in covering.
> 
> Yes, usability is a valid topic esp. if you promise to come w/ GUI patches.
> 

- state and roadmap for upstream merge of in-kernel device models
  (looks to me like this central merge effort is stalled ATM)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: KVM call agenda for Mar 23

[Avi Kivity]

On 03/23/2010 11:31 AM, Jan Kiszka wrote:
> Chris Wright wrote:
>    
>> Please send in any agenda items you are interested in covering.
>>
>> Yes, usability is a valid topic esp. if you promise to come w/ GUI patches.
>>
>>      
> - state and roadmap for upstream merge of in-kernel device models
>    (looks to me like this central merge effort is stalled ATM)
>    

- alternative path of merging qemu-kvm.git's implementation as is and 
cleaning it up in qemu.git.

For kvm.git, I wouldn't dream of merging something with outstanding 
issues and cleaning them up "later", but the situation is somewhat 
different with qemu vs qemu-kvm.

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

[Qemu-devel] Re: KVM call agenda for Mar 23

[Jan Kiszka]

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

Avi Kivity wrote:
> On 03/23/2010 11:31 AM, Jan Kiszka wrote:
>> Chris Wright wrote:
>>   
>>> Please send in any agenda items you are interested in covering.
>>>
>>> Yes, usability is a valid topic esp. if you promise to come w/ GUI
>>> patches.
>>>
>>>      
>> - state and roadmap for upstream merge of in-kernel device models
>>    (looks to me like this central merge effort is stalled ATM)
>>    
> 
> - alternative path of merging qemu-kvm.git's implementation as is and
> cleaning it up in qemu.git.
> 
> For kvm.git, I wouldn't dream of merging something with outstanding
> issues and cleaning them up "later", but the situation is somewhat
> different with qemu vs qemu-kvm.
> 

So the benefit would be less merge conflicts/regressions on
qemu-kvm.git? But you may break non-x86 KVM support in upstream as it
already uses the cleaned up kvm subsystem. /me is not immediately
convinced...

We are more than half-way through this, so let's focus efforts for the
last bits that make the difference widely negligible. This investment
should pay off rather quickly.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: KVM call agenda for Mar 23

[Avi Kivity]

On 03/23/2010 12:50 PM, Jan Kiszka wrote:
> Avi Kivity wrote:
>    
>> On 03/23/2010 11:31 AM, Jan Kiszka wrote:
>>      
>>> Chris Wright wrote:
>>>
>>>        
>>>> Please send in any agenda items you are interested in covering.
>>>>
>>>> Yes, usability is a valid topic esp. if you promise to come w/ GUI
>>>> patches.
>>>>
>>>>
>>>>          
>>> - state and roadmap for upstream merge of in-kernel device models
>>>     (looks to me like this central merge effort is stalled ATM)
>>>
>>>        
>> - alternative path of merging qemu-kvm.git's implementation as is and
>> cleaning it up in qemu.git.
>>
>> For kvm.git, I wouldn't dream of merging something with outstanding
>> issues and cleaning them up "later", but the situation is somewhat
>> different with qemu vs qemu-kvm.
>>
>>      
> So the benefit would be less merge conflicts/regressions on
> qemu-kvm.git? But you may break non-x86 KVM support in upstream as it
> already uses the cleaned up kvm subsystem. /me is not immediately
> convinced...
>    

The benefit would be that qemu-kvm.git would become a staging tree 
instead of the master repository for kvm users.  As an example, we 
wouldn't have any bisectability problems.  kvm features would need to be 
written just once.


> We are more than half-way through this, so let's focus efforts for the
> last bits that make the difference widely negligible. This investment
> should pay off rather quickly.
>    

If we merge now, we merge the half-completed effort so we don't lose 
anything.  However, if we can complete the merge quickly, I'm all for 
it.  I don't want to introduce the ugliness into qemu.git any more than 
you do.

Note, the above discussion ignores extboot and device assignment, but 
let's focus on the thorny bits first.

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

[Qemu-devel] Re: KVM call agenda for Mar 23

[Jan Kiszka]

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

Avi Kivity wrote:
> On 03/23/2010 12:50 PM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>   
>>> On 03/23/2010 11:31 AM, Jan Kiszka wrote:
>>>     
>>>> Chris Wright wrote:
>>>>
>>>>       
>>>>> Please send in any agenda items you are interested in covering.
>>>>>
>>>>> Yes, usability is a valid topic esp. if you promise to come w/ GUI
>>>>> patches.
>>>>>
>>>>>
>>>>>          
>>>> - state and roadmap for upstream merge of in-kernel device models
>>>>     (looks to me like this central merge effort is stalled ATM)
>>>>
>>>>        
>>> - alternative path of merging qemu-kvm.git's implementation as is and
>>> cleaning it up in qemu.git.
>>>
>>> For kvm.git, I wouldn't dream of merging something with outstanding
>>> issues and cleaning them up "later", but the situation is somewhat
>>> different with qemu vs qemu-kvm.
>>>
>>>      
>> So the benefit would be less merge conflicts/regressions on
>> qemu-kvm.git? But you may break non-x86 KVM support in upstream as it
>> already uses the cleaned up kvm subsystem. /me is not immediately
>> convinced...
>>    
> 
> The benefit would be that qemu-kvm.git would become a staging tree
> instead of the master repository for kvm users.  As an example, we
> wouldn't have any bisectability problems.  kvm features would need to be
> written just once.
> 

The last item would imply throwing away what qemu.git already cleaned up
- or finally convert the rest. There is no lazy path.

> 
>> We are more than half-way through this, so let's focus efforts for the
>> last bits that make the difference widely negligible. This investment
>> should pay off rather quickly.
>>    
> 
> If we merge now, we merge the half-completed effort so we don't lose
> anything.  However, if we can complete the merge quickly, I'm all for
> it.  I don't want to introduce the ugliness into qemu.git any more than
> you do.

One issue of merging blindly is the command line option zoo of qemu-kvm.
I don't think we want this upstream first and then deprecate it quickly
again.

> 
> Note, the above discussion ignores extboot and device assignment, but
> let's focus on the thorny bits first.
> 

I don't think extboot will make it upstream anymore, now that there is
an effort for a gpxe-based virtio boot loader.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: KVM call agenda for Mar 23

[Avi Kivity]

On 03/23/2010 01:13 PM, Jan Kiszka wrote:
>
>> The benefit would be that qemu-kvm.git would become a staging tree
>> instead of the master repository for kvm users.  As an example, we
>> wouldn't have any bisectability problems.  kvm features would need to be
>> written just once.
>>
>>      
> The last item would imply throwing away what qemu.git already cleaned up
> - or finally convert the rest. There is no lazy path.
>    

The code would remain but be disabled (#ifdef KVM_UPSTREAM) (just as 
with qemu-kvm.git).  The only difference is qemu.git would be usable for 
kvm users.

I'd prefer it if the cleanup happened out-of-tree and quickly.

>>> We are more than half-way through this, so let's focus efforts for the
>>> last bits that make the difference widely negligible. This investment
>>> should pay off rather quickly.
>>>
>>>        
>> If we merge now, we merge the half-completed effort so we don't lose
>> anything.  However, if we can complete the merge quickly, I'm all for
>> it.  I don't want to introduce the ugliness into qemu.git any more than
>> you do.
>>      
> One issue of merging blindly is the command line option zoo of qemu-kvm.
> I don't think we want this upstream first and then deprecate it quickly
> again.
>    

Good point.

>> Note, the above discussion ignores extboot and device assignment, but
>> let's focus on the thorny bits first.
>>
>>      
> I don't think extboot will make it upstream anymore, now that there is
> an effort for a gpxe-based virtio boot loader.
>    

Sure, an equivalent is fine.

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

[Qemu-devel] Re: KVM call agenda for Mar 23

[Anthony Liguori]

On 03/23/2010 04:52 AM, Avi Kivity wrote:
> On 03/23/2010 11:31 AM, Jan Kiszka wrote:
>> Chris Wright wrote:
>>> Please send in any agenda items you are interested in covering.
>>>
>>> Yes, usability is a valid topic esp. if you promise to come w/ GUI 
>>> patches.
>>>
>> - state and roadmap for upstream merge of in-kernel device models
>>    (looks to me like this central merge effort is stalled ATM)
>
> - alternative path of merging qemu-kvm.git's implementation as is and 
> cleaning it up in qemu.git.
>
> For kvm.git, I wouldn't dream of merging something with outstanding 
> issues and cleaning them up "later", but the situation is somewhat 
> different with qemu vs qemu-kvm.

I don't think we can pull in:

  - extboot
  - ia64
  - in-kernel pit[1]
  - associated command line options
  - device passthrough

The question is, if we dropped those things, would people actually use 
qemu.git instead of qemu-kvm.git.  If the answer is "no", what set of 
things do we need in order for people to focus on qemu.git instead of 
qemu-kvm.git.

[1] I'd like to revisit this discussion.  We originally went the 
in-kernel pit route because of difficulties changing qemu.  That's a bad 
reason to put something in the kernel.  I'd prefer to see us fix qemu.  
After that, we can look at in-kernel pit and see if there are any 
remaining advantages (like performance).  If it's significant, we can 
still merge in-kernel pit.

Regards,

Anthony Liguori

[Qemu-devel] Re: KVM call agenda for Mar 23

[Avi Kivity]

On 03/23/2010 02:45 PM, Anthony Liguori wrote:
> On 03/23/2010 04:52 AM, Avi Kivity wrote:
>> On 03/23/2010 11:31 AM, Jan Kiszka wrote:
>>> Chris Wright wrote:
>>>> Please send in any agenda items you are interested in covering.
>>>>
>>>> Yes, usability is a valid topic esp. if you promise to come w/ GUI 
>>>> patches.
>>>>
>>> - state and roadmap for upstream merge of in-kernel device models
>>>    (looks to me like this central merge effort is stalled ATM)
>>
>> - alternative path of merging qemu-kvm.git's implementation as is and 
>> cleaning it up in qemu.git.
>>
>> For kvm.git, I wouldn't dream of merging something with outstanding 
>> issues and cleaning them up "later", but the situation is somewhat 
>> different with qemu vs qemu-kvm.
>
> I don't think we can pull in:
>
>  - extboot
>  - ia64
>  - in-kernel pit[1]
>  - associated command line options
>  - device passthrough

I'm not proposing these for merge, except [1].

> The question is, if we dropped those things, would people actually use 
> qemu.git instead of qemu-kvm.git.  If the answer is "no", what set of 
> things do we need in order for people to focus on qemu.git instead of 
> qemu-kvm.git.

Device passthrough is sufficiently obscure that most people could use 
qemu.git (not distributions, though).  ia64 is dead.  Command line 
options would need to be cleaned up.  We'd need an extboot replacement, 
people do boot from virtio.

>
> [1] I'd like to revisit this discussion.  We originally went the 
> in-kernel pit route because of difficulties changing qemu.  That's a 
> bad reason to put something in the kernel.  I'd prefer to see us fix 
> qemu.  After that, we can look at in-kernel pit and see if there are 
> any remaining advantages (like performance).  If it's significant, we 
> can still merge in-kernel pit.

The reason was drift compensation IIRC.  Also, some guests read the time 
back from the PIT.  Perhaps that's no longer the case with hpet enabled 
by default.

Drift compensation can be done in qemu by exposing ack notifiers to 
userspace; that's also needed for rtc drift compensation for Windows.

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

Re: [Qemu-devel] Re: KVM call agenda for Mar 23

[Jes Sorensen]

On 03/23/10 13:45, Anthony Liguori wrote:
> I don't think we can pull in:
>
> - extboot
> - ia64
> - in-kernel pit[1]
> - associated command line options
> - device passthrough
>
> The question is, if we dropped those things, would people actually use
> qemu.git instead of qemu-kvm.git. If the answer is "no", what set of
> things do we need in order for people to focus on qemu.git instead of
> qemu-kvm.git.

I am not sure if anyone is still actively working on ia64. According to
the qemu-kvm.git logs, there hasn't been any real ia64 changes to the
code since my last commit in June of last year and then a couple of
minor configure bits.

IMHO we can just let it rot - not sure if Xiantao is still interested?

Cheers,
Jes

RE: [Qemu-devel] Re: KVM call agenda for Mar 23

[Zhang, Xiantao]

Jes Sorensen wrote:
> On 03/23/10 13:45, Anthony Liguori wrote:
>> I don't think we can pull in:
>> 
>> - extboot
>> - ia64
>> - in-kernel pit[1]
>> - associated command line options
>> - device passthrough
>> 
>> The question is, if we dropped those things, would people actually
>> use qemu.git instead of qemu-kvm.git. If the answer is "no", what
>> set of things do we need in order for people to focus on qemu.git
>> instead of qemu-kvm.git.
> 
> I am not sure if anyone is still actively working on ia64. According
> to the qemu-kvm.git logs, there hasn't been any real ia64 changes to
> the code since my last commit in June of last year and then a couple
> of minor configure bits.
> 
> IMHO we can just let it rot - not sure if Xiantao is still interested?
For ia64 part, maybe we can keep the current qemu-kvm.git for the users. And it is not a must to push it into Qemu upstream. 
Xiantao

Re: [Qemu-devel] Re: KVM call agenda for Mar 23

[Jan Kiszka]

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

Zhang, Xiantao wrote:
> Jes Sorensen wrote:
>> On 03/23/10 13:45, Anthony Liguori wrote:
>>> I don't think we can pull in:
>>>
>>> - extboot
>>> - ia64
>>> - in-kernel pit[1]
>>> - associated command line options
>>> - device passthrough
>>>
>>> The question is, if we dropped those things, would people actually
>>> use qemu.git instead of qemu-kvm.git. If the answer is "no", what
>>> set of things do we need in order for people to focus on qemu.git
>>> instead of qemu-kvm.git.
>> I am not sure if anyone is still actively working on ia64. According
>> to the qemu-kvm.git logs, there hasn't been any real ia64 changes to
>> the code since my last commit in June of last year and then a couple
>> of minor configure bits.
>>
>> IMHO we can just let it rot - not sure if Xiantao is still interested?
> For ia64 part, maybe we can keep the current qemu-kvm.git for the users. And it is not a must to push it into Qemu upstream. 
> Xiantao
> 

Does it still build & work? Does someone test it at least infrequently?
Or are there users?

There were a few changes recently due to cleanups and/or switches to
upstream code. There will be more in the future. And at some point heavy
work will be needed when there are no more qemu-kvm* files. That could
be a point ia64 breaks forever unless someone jumps in.

BTW, I'm also carrying ia64 bits in kvm-kmod. I never compiled them
(except for the "make headers_install" which throws tons of warnings at
me), I'm just keeping them for now to enforce architecture separation in
case someone once wishes to add another arch to this wrapper.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: KVM call agenda for Mar 23

[Jes Sorensen]

On 03/25/10 10:39, Jan Kiszka wrote:
> Zhang, Xiantao wrote:
>> For ia64 part, maybe we can keep the current qemu-kvm.git for the users. And it is not a must to push it into Qemu upstream.
>> Xiantao
>>
>
> Does it still build&  work? Does someone test it at least infrequently?
> Or are there users?
>
> There were a few changes recently due to cleanups and/or switches to
> upstream code. There will be more in the future. And at some point heavy
> work will be needed when there are no more qemu-kvm* files. That could
> be a point ia64 breaks forever unless someone jumps in.
>
> BTW, I'm also carrying ia64 bits in kvm-kmod. I never compiled them
> (except for the "make headers_install" which throws tons of warnings at
> me), I'm just keeping them for now to enforce architecture separation in
> case someone once wishes to add another arch to this wrapper.

I think the end result will be that an older version of qemu-kvm will be
around, and if someone decides to pick up on it, they will have to work
from that. At this point I only see some of the Japanese vendors
potentially being interested, but I think they have mostly been looking
at Xen/ia64. Then again, I have no idea what the state is for Xen/ia64
patches for QEMU, in theory a lot of it should be shared.

As long as the bits are sitting in the tree without disturbing other
parts, then I just think we should let them sit there.

Cheers,
Jes

Re: [Qemu-devel] Re: KVM call agenda for Mar 23

[Chris Wright]

* Jes Sorensen (Jes.Sorensen@redhat.com) wrote:
> As long as the bits are sitting in the tree without disturbing other
> parts, then I just think we should let them sit there.

Yup, I agree (there == qemu-kvm.git), and it doesn't need to be a gating
factor for pushing the merge into qemu.git.

thanks,
-chris

[Qemu-devel] Re: KVM call agenda for Mar 23

[Anthony Liguori]

On 03/23/2010 01:11 AM, Chris Wright wrote:
> Please send in any agenda items you are interested in covering.
>
> Yes, usability is a valid topic esp. if you promise to come w/ GUI patches.
>    

I can't make today's call.  I'd hoping there's a discussion about 
libqemu and libvirt though and that someone sends out notes afterwards :-)

Regards,

Anthony Liguori

> thanks,
> -chris
> --
> 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
>