Re: qemu-kvm.git now live
On Sat, 2009-05-02 at 10:52 +0300, Avi Kivity wrote: Hollis Blanchard wrote: In that case it's sufficient to have the build system use the upstream kvm integration (CONFIG_KVM) rather than the qemu-kvm integration (USE_KVM). OK, I give up... how is this supposed to work? Nobody ever sets CONFIG_KVM or KVM_UPSTREAM, but there are a couple tests for it. Glauber once sent a patch related to that, but I don't see how it helps. KVM_UPSTREAM is just a marker to let us know which parts of upstream qemu/kvm integration conflict with qemu-kvm.git. OK, so where do I define KVM_UPSTREAM? Also, where do I define CONFIG_KVM? I would expect the configure script to do that, but apparently it does not. -- Hollis Blanchard IBM Linux Technology Center -- 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-kvm.git now live
Anthony Liguori wrote: Hollis Blanchard wrote: On Wed, 2009-04-29 at 11:29 +0300, Avi Kivity wrote: * configure completely ignores --kerneldir and only uses kvm/kernel headers instead. That's intentional. Huh? If --kerneldir does nothing, why does it exist? BTW Avi, if you intend on carrying the KVM kernel headers in qemu-kvm, I see no strong reason not to do the same in QEMU. That's the plan. I'd like to move them from kvm/kernel/include to kvm/include. I'm open to suggestion actually. How often do you intend on updating the headers? For qemu-kvm.git, as often as they're updated in kvm.git. For qemu.git, every major Linux release. This way we don't commit to an ABI which may change. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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-kvm.git now live
Hollis Blanchard wrote: In that case it's sufficient to have the build system use the upstream kvm integration (CONFIG_KVM) rather than the qemu-kvm integration (USE_KVM). OK, I give up... how is this supposed to work? Nobody ever sets CONFIG_KVM or KVM_UPSTREAM, but there are a couple tests for it. Glauber once sent a patch related to that, but I don't see how it helps. KVM_UPSTREAM is just a marker to let us know which parts of upstream qemu/kvm integration conflict with qemu-kvm.git. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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-kvm.git now live
Hollis Blanchard wrote: They were generated by the old 'make sync' to remove CONFIG_ dependencies. I guess a better way to generate them is a 'make headers-install' from the kernel tree and grab the results. 'make headers_install' only produces include/asm/kvm.h, which apparently is not sufficient. That's a bug then. People should be able to use kvm without copying and hacking headers from the kernel source tree. I can use output from an old 'make sync' for now, but obviously that doesn't help with future changes to these headers. Defining a process for updating those headers would be useful. I plan to setup a script for that (basically an updated make sync). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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-kvm.git now live
Hollis Blanchard wrote: On Wed, 2009-04-29 at 11:29 +0300, Avi Kivity wrote: * configure completely ignores --kerneldir and only uses kvm/kernel headers instead. That's intentional. Huh? If --kerneldir does nothing, why does it exist? --kerneldir predates the inclusion of headers in qemu-kvm.git. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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-kvm.git now live
On Fri, May 01, 2009 at 04:23:45PM -0500, Hollis Blanchard wrote: I can use output from an old 'make sync' for now, but obviously that doesn't help with future changes to these headers. Defining a process for updating those headers would be useful. Two thumbs up. People doing kvm development which is not-quite-yet ready for upstream inclusion will appreciate having a way of keeping their (changed) kernel headers in sync with the userspace bits as transparently as possible. Cheers, Muli -- Muli Ben-Yehuda | m...@il.ibm.com | +972-4-8281080 Manager, Virtualization and Systems Architecture Master Inventor, IBM Haifa Research Laboratory SYSTOR 2009---The Israeli Experimental Systems Conference http://www.haifa.il.ibm.com/conferences/systor2009/ -- 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-kvm.git now live
Hollis Blanchard wrote: In that case it's sufficient to have the build system use the upstream kvm integration (CONFIG_KVM) rather than the qemu-kvm integration (USE_KVM). OK, I give up... how is this supposed to work? Nobody ever sets CONFIG_KVM or KVM_UPSTREAM, but there are a couple tests for it. Glauber once sent a patch related to that, but I don't see how it helps. KVM_UPSTREAM is just a marker to let us know which parts of upstream qemu/kvm integration conflict with qemu-kvm.git. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Hollis Blanchard wrote: On Wed, 2009-04-29 at 11:29 +0300, Avi Kivity wrote: * configure completely ignores --kerneldir and only uses kvm/kernel headers instead. That's intentional. Huh? If --kerneldir does nothing, why does it exist? --kerneldir predates the inclusion of headers in qemu-kvm.git. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
On Fri, May 01, 2009 at 04:23:45PM -0500, Hollis Blanchard wrote: I can use output from an old 'make sync' for now, but obviously that doesn't help with future changes to these headers. Defining a process for updating those headers would be useful. Two thumbs up. People doing kvm development which is not-quite-yet ready for upstream inclusion will appreciate having a way of keeping their (changed) kernel headers in sync with the userspace bits as transparently as possible. Cheers, Muli -- Muli Ben-Yehuda | m...@il.ibm.com | +972-4-8281080 Manager, Virtualization and Systems Architecture Master Inventor, IBM Haifa Research Laboratory SYSTOR 2009---The Israeli Experimental Systems Conference http://www.haifa.il.ibm.com/conferences/systor2009/ -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
On Wed, 2009-04-29 at 11:29 +0300, Avi Kivity wrote: * configure completely ignores --kerneldir and only uses kvm/kernel headers instead. That's intentional. Huh? If --kerneldir does nothing, why does it exist? * The headers in kvm/kernel/arch/foo seem to be the important ones, but they have odd ifdefs at the top and I'm not sure how they should be generated. They were generated by the old 'make sync' to remove CONFIG_ dependencies. I guess a better way to generate them is a 'make headers-install' from the kernel tree and grab the results. 'make headers_install' only produces include/asm/kvm.h, which apparently is not sufficient. I can use output from an old 'make sync' for now, but obviously that doesn't help with future changes to these headers. Defining a process for updating those headers would be useful. I'll send patches separately. -- Hollis Blanchard IBM Linux Technology Center -- 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-kvm.git now live
On Wed, 2009-04-29 at 11:31 +0300, Avi Kivity wrote: Hollis Blanchard wrote: Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? I was going to take that position too, except Avi asked me specifically if some of the code inside TARGET_I386 ifdefs in qemu-kvm.c works for other architectures. In that case it's sufficient to have the build system use the upstream kvm integration (CONFIG_KVM) rather than the qemu-kvm integration (USE_KVM). OK, I give up... how is this supposed to work? Nobody ever sets CONFIG_KVM or KVM_UPSTREAM, but there are a couple tests for it. Glauber once sent a patch related to that, but I don't see how it helps. For reference, the actual error is about a hundred instances of e.g. /home/hollisb/source/qemu-kvm.git/vl.c:3393: undefined reference to `kvm_allowed' -- Hollis Blanchard IBM Linux Technology Center -- 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-kvm.git now live
Hollis Blanchard wrote: On Wed, 2009-04-29 at 11:29 +0300, Avi Kivity wrote: * configure completely ignores --kerneldir and only uses kvm/kernel headers instead. That's intentional. Huh? If --kerneldir does nothing, why does it exist? BTW Avi, if you intend on carrying the KVM kernel headers in qemu-kvm, I see no strong reason not to do the same in QEMU. I'd like to move them from kvm/kernel/include to kvm/include. I'm open to suggestion actually. How often do you intend on updating the headers? 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: qemu-kvm.git now live
On Wed, 2009-04-29 at 11:31 +0300, Avi Kivity wrote: Hollis Blanchard wrote: Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? I was going to take that position too, except Avi asked me specifically if some of the code inside TARGET_I386 ifdefs in qemu-kvm.c works for other architectures. In that case it's sufficient to have the build system use the upstream kvm integration (CONFIG_KVM) rather than the qemu-kvm integration (USE_KVM). OK, I give up... how is this supposed to work? Nobody ever sets CONFIG_KVM or KVM_UPSTREAM, but there are a couple tests for it. Glauber once sent a patch related to that, but I don't see how it helps. For reference, the actual error is about a hundred instances of e.g. /home/hollisb/source/qemu-kvm.git/vl.c:3393: undefined reference to `kvm_allowed' -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Hollis Blanchard wrote: On Wed, 2009-04-29 at 11:29 +0300, Avi Kivity wrote: * configure completely ignores --kerneldir and only uses kvm/kernel headers instead. That's intentional. Huh? If --kerneldir does nothing, why does it exist? BTW Avi, if you intend on carrying the KVM kernel headers in qemu-kvm, I see no strong reason not to do the same in QEMU. I'd like to move them from kvm/kernel/include to kvm/include. I'm open to suggestion actually. How often do you intend on updating the headers? Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Jan Kiszka wrote: That's sort of what's implemented in qemu-kvm.git. In qemu.git vga logging does not get disabled, which is really broken. It prevents optimizations like disabling logging when the screen is not displayed to a human. Is there a channel that tells vga nothing will be displayed? I may have missed it while removing all those disable-logging-as-it-may- confuse-slot-management hooks. I think currently qemu simply stops calling vga_draw_graphic(). This makes sense for tcg since it needs to track dirty memory regardless (so it can invalidate TBs). But for kvm we'll want to add an explicit channel. Note that it isn't likely to make a huge difference: if you don't actively read-and-reset the dirty bitmap, kvm will keep the shadow ptes with write permission and you won't see any performance hit. The only difference is whether large pages can be used or not. Where/how does the migration code disable dirty logging? Should be phase 3 of ram_save_live(). But only in qemu-kvm. What is the plan about pushing it upstream? Then we could discuss how to extend the exiting support best. Pushing things upstream is quite difficult because of the very different infrastructure. It's unfortunate that upstream rewrote everything instead of changing things incrementally. Rewrites are almost always a mistake since they throw away accumulated knowledge. -- 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-kvm.git now live
Jan Kiszka wrote: Avi Kivity wrote: Where/how does the migration code disable dirty logging? Should be phase 3 of ram_save_live(). But only in qemu-kvm. What is the plan about pushing it upstream? Then we could discuss how to extend the exiting support best. Pushing things upstream is quite difficult because of the very different infrastructure. Isn't the midterm goal to get rid of most of these differences (namely libkvm)? Yes, but not by removing existing functionality. It's unfortunate that upstream rewrote everything instead of changing things incrementally. Rewrites are almost always a mistake since they throw away accumulated knowledge. I disagree, at least in this particular case. Upstream already diverged from qemu-kvm, and the latter provided no comparable alternative for slot management and dirty logging. And I still don't see that we lost anything that could not easily be re-integrated into upstream (ie. global dirty logging), finally leading to a cleaner and more complete result. It could have been done differently, by morphing the existing support into something mergable, and merging that. In this way, we'd ensure no needed functionality is lost. As is, we're adding something simple, then discovering it's insufficient. We're throwing away information, that's not a good way to make progress. So, what bits are missing to make KVM migration work in upstream? I don't know of anything beyond dirty logging. -- 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-kvm.git now live
Avi Kivity wrote: Where/how does the migration code disable dirty logging? Should be phase 3 of ram_save_live(). But only in qemu-kvm. What is the plan about pushing it upstream? Then we could discuss how to extend the exiting support best. Pushing things upstream is quite difficult because of the very different infrastructure. Isn't the midterm goal to get rid of most of these differences (namely libkvm)? It's unfortunate that upstream rewrote everything instead of changing things incrementally. Rewrites are almost always a mistake since they throw away accumulated knowledge. I disagree, at least in this particular case. Upstream already diverged from qemu-kvm, and the latter provided no comparable alternative for slot management and dirty logging. And I still don't see that we lost anything that could not easily be re-integrated into upstream (ie. global dirty logging), finally leading to a cleaner and more complete result. So, what bits are missing to make KVM migration work in upstream? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- 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-kvm.git now live
Avi Kivity wrote: Jan Kiszka wrote: Avi Kivity wrote: Where/how does the migration code disable dirty logging? Should be phase 3 of ram_save_live(). But only in qemu-kvm. What is the plan about pushing it upstream? Then we could discuss how to extend the exiting support best. Pushing things upstream is quite difficult because of the very different infrastructure. Isn't the midterm goal to get rid of most of these differences (namely libkvm)? Yes, but not by removing existing functionality. No one said this. It's unfortunate that upstream rewrote everything instead of changing things incrementally. Rewrites are almost always a mistake since they throw away accumulated knowledge. I disagree, at least in this particular case. Upstream already diverged from qemu-kvm, and the latter provided no comparable alternative for slot management and dirty logging. And I still don't see that we lost anything that could not easily be re-integrated into upstream (ie. global dirty logging), finally leading to a cleaner and more complete result. It could have been done differently, by morphing the existing support into something mergable, and merging that. In this way, we'd ensure no needed functionality is lost. The existing support lacked features upstream already had and instead required additional hacks to make qemu-kvm work. As is, we're adding something simple, then discovering it's insufficient. We're throwing away information, that's not a good way to make progress. I doubt this applies here. So, what bits are missing to make KVM migration work in upstream? I don't know of anything beyond dirty logging. OK, then I will pick this up and have a look at something comparable to cpu_physical_memory_set_dirty_tracking() for upstream. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- 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-kvm.git now live
Avi Kivity wrote: Jan Kiszka wrote: Avi Kivity wrote: Where/how does the migration code disable dirty logging? Should be phase 3 of ram_save_live(). But only in qemu-kvm. What is the plan about pushing it upstream? Then we could discuss how to extend the exiting support best. Pushing things upstream is quite difficult because of the very different infrastructure. Isn't the midterm goal to get rid of most of these differences (namely libkvm)? Yes, but not by removing existing functionality. No one said this. It's unfortunate that upstream rewrote everything instead of changing things incrementally. Rewrites are almost always a mistake since they throw away accumulated knowledge. I disagree, at least in this particular case. Upstream already diverged from qemu-kvm, and the latter provided no comparable alternative for slot management and dirty logging. And I still don't see that we lost anything that could not easily be re-integrated into upstream (ie. global dirty logging), finally leading to a cleaner and more complete result. It could have been done differently, by morphing the existing support into something mergable, and merging that. In this way, we'd ensure no needed functionality is lost. The existing support lacked features upstream already had and instead required additional hacks to make qemu-kvm work. As is, we're adding something simple, then discovering it's insufficient. We're throwing away information, that's not a good way to make progress. I doubt this applies here. So, what bits are missing to make KVM migration work in upstream? I don't know of anything beyond dirty logging. OK, then I will pick this up and have a look at something comparable to cpu_physical_memory_set_dirty_tracking() for upstream. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Jan Kiszka wrote: Pushing things upstream is quite difficult because of the very different infrastructure. Isn't the midterm goal to get rid of most of these differences (namely libkvm)? Yes, but not by removing existing functionality. No one said this. I'm sure no one meant it either, but that is what's happening. This is the flow: * qemu.git has very limited kvm support * more kvm support is added to qemu.git * because it's a rewrite, not all the knowledge that has gone into qemu-kvm.git is added * when I merge qemu.git into qemu-kvm.git, the two implementation methods clash, and things break This has happened on most clean rewrites I've seen. The new code is clean, but the old code works better. It's much better to morph the old code into shape (though more time consuming and a lot less fun). As is, we're adding something simple, then discovering it's insufficient. We're throwing away information, that's not a good way to make progress. I doubt this applies here. In fact it's happened. qemu-kvm.git knows that the dirty logging flag is a shared resource. qemu-kvm.git also handles older kernels (though I think that was intentional). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Hollis Blanchard wrote: On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Some of the bigger problems: * configure completely ignores --kerneldir and only uses kvm/kernel headers instead. That's intentional. * The headers in kvm/kernel/arch/foo seem to be the important ones, but they have odd ifdefs at the top and I'm not sure how they should be generated. They were generated by the old 'make sync' to remove CONFIG_ dependencies. I guess a better way to generate them is a 'make headers-install' from the kernel tree and grab the results. * make -C kvm/kernel sync doesn't even come close to working. One of the goals of qemu-kvm.git was to have a standalone repository so I could release kvm-kmod and qemu-kvm independently. There are a host of other issues and confusing issues, even with a fresh checkout. In general it seems like the mess that was kvm-userspace has been rearranged, and as a consequence is even worse than before. Can you detail specific grievances? Please exclude temporary brokenness that was the result of the change. How am I supposed to create kvm/kernel/arch/powerpc/include/asm/*? Just cp from a Linux tree, or must I add funny ifdefs somehow? cp from a Linux tree won't compile. The results of the old 'make sync' would do, but a 'make headers-install' is probably better. Here's one patch that I think will be needed: Set kvm_arch=powerpc for PPC builds. The name of the Linux arch directory is powerpc, not ppc. Signed-off-by: Hollis Blanchard holl...@us.ibm.com diff --git a/configure b/configure index fc0fb9b..257cf02 100755 --- a/configure +++ b/configure @@ -816,6 +816,9 @@ case $cpu in i386 | x86_64) kvm_arch=x86 ;; +ppc) + kvm_arch=powerpc + ;; *) kvm_arch=$cpu ;; Applied, thanks. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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-kvm.git now live
Hollis Blanchard wrote: Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? I was going to take that position too, except Avi asked me specifically if some of the code inside TARGET_I386 ifdefs in qemu-kvm.c works for other architectures. In that case it's sufficient to have the build system use the upstream kvm integration (CONFIG_KVM) rather than the qemu-kvm integration (USE_KVM). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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-kvm.git now live
Avi Kivity wrote: After a lengthy testing phase, qemu-kvm.git has replaced kvm-userspace.git as the source repository for kvm userspace development. Differences from kvm-userspace.git are as follows: - everything under qemu/ has been moved to the top-level directory - everything not under qemu/ has been moved under a new top-level directory, kvm/ - all qemu subversion commits have been rewritten to be compatible with what will become the master qemu git repository - all branches and tags have been converted - qemu-kvm.git builds standalone (does not require kvm.git) The repository is compatible with upstream qemu.git; merges and cherry-picking will work fine in either direction Still missing: - I have not tested powerpc or ia64. Patches welcome! - testsuite (kvm/user/ directory) does not build - proper guest memory setup During merge with upstream, the call to qemu_alloc_physram dropped under the table (due to removal of phys_ram_base from qemu). And that means we no longer call kvm_setup_guest_memory (fork will cause troubles, deja vu...) and -mempath is broken. Sorry, I'm not deep enough into all parts to provide a quick-fix. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- 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-kvm.git now live
Jan Kiszka wrote: Avi Kivity wrote: After a lengthy testing phase, qemu-kvm.git has replaced kvm-userspace.git as the source repository for kvm userspace development. Differences from kvm-userspace.git are as follows: - everything under qemu/ has been moved to the top-level directory - everything not under qemu/ has been moved under a new top-level directory, kvm/ - all qemu subversion commits have been rewritten to be compatible with what will become the master qemu git repository - all branches and tags have been converted - qemu-kvm.git builds standalone (does not require kvm.git) The repository is compatible with upstream qemu.git; merges and cherry-picking will work fine in either direction Still missing: - I have not tested powerpc or ia64. Patches welcome! - testsuite (kvm/user/ directory) does not build - proper guest memory setup During merge with upstream, the call to qemu_alloc_physram dropped under the table (due to removal of phys_ram_base from qemu). And that means we no longer call kvm_setup_guest_memory (fork will cause troubles, deja vu...) and -mempath is broken. Sorry, I'm not deep enough into all parts to provide a quick-fix. That's unrelated to the repository conversion. I'm unhappy with both qemu.git and qemu-kvm.git memory slot management; qemu-kvm.git is clumsy, and qemu.git is too simplistic (for example, it ignores the fact that dirty logging is a global resource with multiple users). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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-kvm.git now live
Jan Kiszka wrote: I'm unhappy with both qemu.git and qemu-kvm.git memory slot management; qemu-kvm.git is clumsy, and qemu.git is too simplistic (for example, it ignores the fact that dirty logging is a global resource with multiple users). Don't get your point yet. Can you name a concrete scenario that is problematic in upstream? I'd really like to get slot management right there before we drop the old version of qemu-kvm. If migration disables dirty memory logging, it must keep the vga logging enabled, and vice versa. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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-kvm.git now live
Jan Kiszka wrote: If migration disables dirty memory logging, it must keep the vga logging enabled, and vice versa. So we need some notifier callbacks on slot changes so that all users can re-enable dirty logging after the update as required. Simpler to do reference counting. When a user enables logging for a memory range, the refcount for all slots containing that range gets bumped. When a user enables logging for all of memory, a global refcount is bumped. For a given slot, dirty logging is enabled if either the slot logging refcount or the global logging refcount is nonzero. That's sort of what's implemented in qemu-kvm.git. In qemu.git vga logging does not get disabled, which is really broken. It prevents optimizations like disabling logging when the screen is not displayed to a human. Where/how does the migration code disable dirty logging? Should be phase 3 of ram_save_live(). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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-kvm.git now live
Avi Kivity wrote: Jan Kiszka wrote: If migration disables dirty memory logging, it must keep the vga logging enabled, and vice versa. So we need some notifier callbacks on slot changes so that all users can re-enable dirty logging after the update as required. Simpler to do reference counting. When a user enables logging for a memory range, the refcount for all slots containing that range gets bumped. When a user enables logging for all of memory, a global refcount is bumped. For a given slot, dirty logging is enabled if either the slot logging refcount or the global logging refcount is nonzero. OK, but then we just need to check for that global flag after registering/modifying slots and enable logging unconditionally. That's indeed a simple add-on. That's sort of what's implemented in qemu-kvm.git. In qemu.git vga logging does not get disabled, which is really broken. It prevents optimizations like disabling logging when the screen is not displayed to a human. Is there a channel that tells vga nothing will be displayed? I may have missed it while removing all those disable-logging-as-it-may- confuse-slot-management hooks. Where/how does the migration code disable dirty logging? Should be phase 3 of ram_save_live(). But only in qemu-kvm. What is the plan about pushing it upstream? Then we could discuss how to extend the exiting support best. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- 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-kvm.git now live
Hollis Blanchard wrote: On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Some of the bigger problems: * configure completely ignores --kerneldir and only uses kvm/kernel headers instead. That's intentional. * The headers in kvm/kernel/arch/foo seem to be the important ones, but they have odd ifdefs at the top and I'm not sure how they should be generated. They were generated by the old 'make sync' to remove CONFIG_ dependencies. I guess a better way to generate them is a 'make headers-install' from the kernel tree and grab the results. * make -C kvm/kernel sync doesn't even come close to working. One of the goals of qemu-kvm.git was to have a standalone repository so I could release kvm-kmod and qemu-kvm independently. There are a host of other issues and confusing issues, even with a fresh checkout. In general it seems like the mess that was kvm-userspace has been rearranged, and as a consequence is even worse than before. Can you detail specific grievances? Please exclude temporary brokenness that was the result of the change. How am I supposed to create kvm/kernel/arch/powerpc/include/asm/*? Just cp from a Linux tree, or must I add funny ifdefs somehow? cp from a Linux tree won't compile. The results of the old 'make sync' would do, but a 'make headers-install' is probably better. Here's one patch that I think will be needed: Set kvm_arch=powerpc for PPC builds. The name of the Linux arch directory is powerpc, not ppc. Signed-off-by: Hollis Blanchard holl...@us.ibm.com diff --git a/configure b/configure index fc0fb9b..257cf02 100755 --- a/configure +++ b/configure @@ -816,6 +816,9 @@ case $cpu in i386 | x86_64) kvm_arch=x86 ;; +ppc) + kvm_arch=powerpc + ;; *) kvm_arch=$cpu ;; Applied, thanks. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Hollis Blanchard wrote: Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? I was going to take that position too, except Avi asked me specifically if some of the code inside TARGET_I386 ifdefs in qemu-kvm.c works for other architectures. In that case it's sufficient to have the build system use the upstream kvm integration (CONFIG_KVM) rather than the qemu-kvm integration (USE_KVM). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Avi Kivity wrote: Jan Kiszka wrote: Avi Kivity wrote: After a lengthy testing phase, qemu-kvm.git has replaced kvm-userspace.git as the source repository for kvm userspace development. Differences from kvm-userspace.git are as follows: - everything under qemu/ has been moved to the top-level directory - everything not under qemu/ has been moved under a new top-level directory, kvm/ - all qemu subversion commits have been rewritten to be compatible with what will become the master qemu git repository - all branches and tags have been converted - qemu-kvm.git builds standalone (does not require kvm.git) The repository is compatible with upstream qemu.git; merges and cherry-picking will work fine in either direction Still missing: - I have not tested powerpc or ia64. Patches welcome! - testsuite (kvm/user/ directory) does not build - proper guest memory setup During merge with upstream, the call to qemu_alloc_physram dropped under the table (due to removal of phys_ram_base from qemu). And that means we no longer call kvm_setup_guest_memory (fork will cause troubles, deja vu...) and -mempath is broken. Sorry, I'm not deep enough into all parts to provide a quick-fix. That's unrelated to the repository conversion. Then it's a merge artifact, but it's a problematic regression compared to still-working kvm-userspace. I'm unhappy with both qemu.git and qemu-kvm.git memory slot management; qemu-kvm.git is clumsy, and qemu.git is too simplistic (for example, it ignores the fact that dirty logging is a global resource with multiple users). Don't get your point yet. Can you name a concrete scenario that is problematic in upstream? I'd really like to get slot management right there before we drop the old version of qemu-kvm. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Jan Kiszka wrote: If migration disables dirty memory logging, it must keep the vga logging enabled, and vice versa. So we need some notifier callbacks on slot changes so that all users can re-enable dirty logging after the update as required. Simpler to do reference counting. When a user enables logging for a memory range, the refcount for all slots containing that range gets bumped. When a user enables logging for all of memory, a global refcount is bumped. For a given slot, dirty logging is enabled if either the slot logging refcount or the global logging refcount is nonzero. That's sort of what's implemented in qemu-kvm.git. In qemu.git vga logging does not get disabled, which is really broken. It prevents optimizations like disabling logging when the screen is not displayed to a human. Where/how does the migration code disable dirty logging? Should be phase 3 of ram_save_live(). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Hollis Blanchard wrote: On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? 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: qemu-kvm.git now live
On Tue, Apr 28, 2009 at 7:20 PM, Anthony Liguori anth...@codemonkey.ws wrote: Hollis Blanchard wrote: On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? Yes. There are people (me) who still rely on building everything from the same source. It can only be done by the superset (qemu-kvm.git) -- Glauber Costa. Free as in Freedom http://glommer.net The less confident you are, the more serious you have to act. -- 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-kvm.git now live
Glauber Costa wrote: Yes. There are people (me) who still rely on building everything from the same source. It can only be done by the superset (qemu-kvm.git) Fedora doesn't package a KVM enabled qemu-system-ppcemb, do they? 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: qemu-kvm.git now live
On Tue, 2009-04-28 at 17:20 -0500, Anthony Liguori wrote: Hollis Blanchard wrote: On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? I was going to take that position too, except Avi asked me specifically if some of the code inside TARGET_I386 ifdefs in qemu-kvm.c works for other architectures. Since it's a safe bet that some version of this code will probably be submitted to qemu-devel, I figured I'd try a build test... and discovered that qemu-kvm.git was released a little prematurely. -- Hollis Blanchard IBM Linux Technology Center -- 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-kvm.git now live
On Tue, 2009-04-28 at 17:28 -0500, Anthony Liguori wrote: Glauber Costa wrote: Yes. There are people (me) who still rely on building everything from the same source. It can only be done by the superset (qemu-kvm.git) Fedora doesn't package a KVM enabled qemu-system-ppcemb, do they? The more people who notice when the PowerPC build breaks, the better. -- Hollis Blanchard IBM Linux Technology Center -- 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-kvm.git now live
On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Some of the bigger problems: * configure completely ignores --kerneldir and only uses kvm/kernel headers instead. * The headers in kvm/kernel/arch/foo seem to be the important ones, but they have odd ifdefs at the top and I'm not sure how they should be generated. * make -C kvm/kernel sync doesn't even come close to working. There are a host of other issues and confusing issues, even with a fresh checkout. In general it seems like the mess that was kvm-userspace has been rearranged, and as a consequence is even worse than before. How am I supposed to create kvm/kernel/arch/powerpc/include/asm/*? Just cp from a Linux tree, or must I add funny ifdefs somehow? Here's one patch that I think will be needed: Set kvm_arch=powerpc for PPC builds. The name of the Linux arch directory is powerpc, not ppc. Signed-off-by: Hollis Blanchard holl...@us.ibm.com diff --git a/configure b/configure index fc0fb9b..257cf02 100755 --- a/configure +++ b/configure @@ -816,6 +816,9 @@ case $cpu in i386 | x86_64) kvm_arch=x86 ;; +ppc) + kvm_arch=powerpc + ;; *) kvm_arch=$cpu ;; -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Hollis Blanchard wrote: On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
On Tue, Apr 28, 2009 at 7:20 PM, Anthony Liguori anth...@codemonkey.ws wrote: Hollis Blanchard wrote: On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? Yes. There are people (me) who still rely on building everything from the same source. It can only be done by the superset (qemu-kvm.git) -- Glauber Costa. Free as in Freedom http://glommer.net The less confident you are, the more serious you have to act. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Glauber Costa wrote: Yes. There are people (me) who still rely on building everything from the same source. It can only be done by the superset (qemu-kvm.git) Fedora doesn't package a KVM enabled qemu-system-ppcemb, do they? Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
On Tue, 2009-04-28 at 17:20 -0500, Anthony Liguori wrote: Hollis Blanchard wrote: On Thu, 2009-04-23 at 18:40 +0300, Avi Kivity wrote: Still missing: - I have not tested powerpc or ia64. Patches welcome! This repository seems pretty messed up; I'm not even sure what you want from me. Since PPC is now supported in upstream QEMU, does it really matter if it works in qemu-kvm.git? I was going to take that position too, except Avi asked me specifically if some of the code inside TARGET_I386 ifdefs in qemu-kvm.c works for other architectures. Since it's a safe bet that some version of this code will probably be submitted to qemu-devel, I figured I'd try a build test... and discovered that qemu-kvm.git was released a little prematurely. -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
On Tue, 2009-04-28 at 17:28 -0500, Anthony Liguori wrote: Glauber Costa wrote: Yes. There are people (me) who still rely on building everything from the same source. It can only be done by the superset (qemu-kvm.git) Fedora doesn't package a KVM enabled qemu-system-ppcemb, do they? The more people who notice when the PowerPC build breaks, the better. -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Cameron Macdonell wrote:
Great. They work as expected. One thing I noticed is that make clean
doesn't remove libkvm.{o,a} and .libkvm.d. Should it?
Should, but doesn't. Another thing to fix.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
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-kvm.git now live
Cam Macdonell wrote: When I run configure on a clean copy I get this error: KVM support no - (field 'arch' has incomplete type, field 'arch' has incomplete type) I think it's caused by the include/asm and include-compat/asm symlinks not being created until the kvm/configure script runs. Should configure call the qemu-kvm/kvm configure script? There was a big mix-up in this area. I just pushed changes to make everything work as expected (./configure make - builds qemu) Is make supposed to build the host kernel module? No, the external module build will be moved to a different repository. -- 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-kvm.git now live
Liu Yu-B13201 wrote: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git Is there a http interface? http://www.kernel.org/pub/scm/virt/kvm/qemu-kvm.git -- 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-kvm.git now live
Liu Yu-B13201 wrote: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git Is there a http interface? http://www.kernel.org/pub/scm/virt/kvm/qemu-kvm.git -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Hi, Liu Yu-B13201 Yu.Liu at freescale.com writes: After a lengthy testing phase, qemu-kvm.git has replaced kvm-userspace.git as the source repository for kvm userspace development. git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git Is there a http interface? Yes. http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=summary -- 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
qemu-kvm.git now live
After a lengthy testing phase, qemu-kvm.git has replaced kvm-userspace.git as the source repository for kvm userspace development. Differences from kvm-userspace.git are as follows: - everything under qemu/ has been moved to the top-level directory - everything not under qemu/ has been moved under a new top-level directory, kvm/ - all qemu subversion commits have been rewritten to be compatible with what will become the master qemu git repository - all branches and tags have been converted - qemu-kvm.git builds standalone (does not require kvm.git) The repository is compatible with upstream qemu.git; merges and cherry-picking will work fine in either direction Still missing: - I have not tested powerpc or ia64. Patches welcome! - testsuite (kvm/user/ directory) does not build git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git -- 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-kvm.git now live
Avi Kivity wrote: After a lengthy testing phase, qemu-kvm.git has replaced kvm-userspace.git as the source repository for kvm userspace development. Differences from kvm-userspace.git are as follows: - everything under qemu/ has been moved to the top-level directory - everything not under qemu/ has been moved under a new top-level directory, kvm/ - all qemu subversion commits have been rewritten to be compatible with what will become the master qemu git repository - all branches and tags have been converted - qemu-kvm.git builds standalone (does not require kvm.git) The repository is compatible with upstream qemu.git; merges and cherry-picking will work fine in either direction Still missing: - I have not tested powerpc or ia64. Patches welcome! - testsuite (kvm/user/ directory) does not build git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git I just tried running configure on x86 and amd_64 and I got no kvm support (field 'arch' has incomplete type). Is this the expected result? Just for fun I also tried running configure in the top-level kvm directory and got thousands of unkillable 'configure' processes that quickly filled my 1-gig swap partition. I doubt that's the expected result :-) -- 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-kvm.git now live
Avi Kivity wrote: After a lengthy testing phase, qemu-kvm.git has replaced kvm-userspace.git as the source repository for kvm userspace development. Differences from kvm-userspace.git are as follows: - everything under qemu/ has been moved to the top-level directory - everything not under qemu/ has been moved under a new top-level directory, kvm/ - all qemu subversion commits have been rewritten to be compatible with what will become the master qemu git repository - all branches and tags have been converted - qemu-kvm.git builds standalone (does not require kvm.git) Hi Avi, When I run configure on a clean copy I get this error: KVM support no - (field 'arch' has incomplete type, field 'arch' has incomplete type) I think it's caused by the include/asm and include-compat/asm symlinks not being created until the kvm/configure script runs. Should configure call the qemu-kvm/kvm configure script? Is make supposed to build the host kernel module? Thanks, Cam -- 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-kvm.git now live
-Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Avi Kivity Sent: Thursday, April 23, 2009 11:40 PM To: KVM list Cc: Anthony Liguori; Hollis Blanchard; Zhang, Xiantao; kvm-ppc; kvm-i...@vger.kernel.org; Carsten Otte Subject: qemu-kvm.git now live After a lengthy testing phase, qemu-kvm.git has replaced kvm-userspace.git as the source repository for kvm userspace development. Differences from kvm-userspace.git are as follows: - everything under qemu/ has been moved to the top-level directory - everything not under qemu/ has been moved under a new top-level directory, kvm/ - all qemu subversion commits have been rewritten to be compatible with what will become the master qemu git repository - all branches and tags have been converted - qemu-kvm.git builds standalone (does not require kvm.git) The repository is compatible with upstream qemu.git; merges and cherry-picking will work fine in either direction Still missing: - I have not tested powerpc or ia64. Patches welcome! - testsuite (kvm/user/ directory) does not build git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git Is there a http interface?
qemu-kvm.git now live
After a lengthy testing phase, qemu-kvm.git has replaced kvm-userspace.git as the source repository for kvm userspace development. Differences from kvm-userspace.git are as follows: - everything under qemu/ has been moved to the top-level directory - everything not under qemu/ has been moved under a new top-level directory, kvm/ - all qemu subversion commits have been rewritten to be compatible with what will become the master qemu git repository - all branches and tags have been converted - qemu-kvm.git builds standalone (does not require kvm.git) The repository is compatible with upstream qemu.git; merges and cherry-picking will work fine in either direction Still missing: - I have not tested powerpc or ia64. Patches welcome! - testsuite (kvm/user/ directory) does not build git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: qemu-kvm.git now live
-Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Avi Kivity Sent: Thursday, April 23, 2009 11:40 PM To: KVM list Cc: Anthony Liguori; Hollis Blanchard; Zhang, Xiantao; kvm-ppc; kvm-i...@vger.kernel.org; Carsten Otte Subject: qemu-kvm.git now live After a lengthy testing phase, qemu-kvm.git has replaced kvm-userspace.git as the source repository for kvm userspace development. Differences from kvm-userspace.git are as follows: - everything under qemu/ has been moved to the top-level directory - everything not under qemu/ has been moved under a new top-level directory, kvm/ - all qemu subversion commits have been rewritten to be compatible with what will become the master qemu git repository - all branches and tags have been converted - qemu-kvm.git builds standalone (does not require kvm.git) The repository is compatible with upstream qemu.git; merges and cherry-picking will work fine in either direction Still missing: - I have not tested powerpc or ia64. Patches welcome! - testsuite (kvm/user/ directory) does not build git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git Is there a http interface?
