Re: [Qemu-devel] Re: KVM call agenda for Mar 23
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 signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Re: KVM call agenda for Mar 23
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Qemu-devel] Re: KVM call agenda for Mar 23
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM call agenda for Mar 23
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Mar 23
Chris Wright chr...@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. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Mar 23
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 signature.asc Description: OpenPGP digital signature
Re: KVM call agenda for Mar 23
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Mar 23
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 signature.asc Description: OpenPGP digital signature
Re: KVM call agenda for Mar 23
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Mar 23
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 signature.asc Description: OpenPGP digital signature
Re: KVM call agenda for Mar 23
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Mar 23
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Mar 23
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Mar 23
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Mar 23
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Mar 23
Juan Quintela quint...@redhat.com wrote: Chris Wright chr...@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 mtosa...@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.kis...@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.kis...@siemens.com Signed-off-by: Anthony Liguori aligu...@us.ibm.com - exception_index/injected, we could do same trick that for ide. commit 1a03675db146dfc760b3b48b3448075189f142cc Author: Glauber Costa glom...@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.kis...@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 a...@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. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
