From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Date: Thu, 30 Apr 2009 09:12:15 +0000 Subject: Re: qemu-kvm.git now live Message-Id: <49F96B6F.6050005@redhat.com> List-Id: References: <49F08BD0.6000706@redhat.com> In-Reply-To: <49F08BD0.6000706@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ia64@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Date: Thu, 30 Apr 2009 09:12:15 +0000 Subject: Re: qemu-kvm.git now live Message-Id: <49F96B6F.6050005@redhat.com> List-Id: References: <49F08BD0.6000706@redhat.com> <49F81496.8030407@siemens.com> <49F82F24.8040506@redhat.com> <49F83227.9000502@siemens.com> <49F83630.6020402@redhat.com> <49F83A8A.8040909@siemens.com> <49F866C3.8090904@redhat.com> <49F8756C.6080503@siemens.com> In-Reply-To: <49F8756C.6080503@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jan Kiszka Cc: KVM list , Anthony Liguori , Hollis Blanchard , "Zhang, Xiantao" , kvm-ppc , "kvm-ia64@vger.kernel.org" , Carsten Otte 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: qemu-kvm.git now live Date: Thu, 30 Apr 2009 12:12:15 +0300 Message-ID: <49F96B6F.6050005@redhat.com> References: <49F08BD0.6000706@redhat.com> <49F81496.8030407@siemens.com> <49F82F24.8040506@redhat.com> <49F83227.9000502@siemens.com> <49F83630.6020402@redhat.com> <49F83A8A.8040909@siemens.com> <49F866C3.8090904@redhat.com> <49F8756C.6080503@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: KVM list , Anthony Liguori , Hollis Blanchard , "Zhang, Xiantao" , kvm-ppc , "kvm-ia64@vger.kernel.org" , Carsten Otte To: Jan Kiszka Return-path: Received: from mx2.redhat.com ([66.187.237.31]:46473 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753413AbZD3JMX (ORCPT ); Thu, 30 Apr 2009 05:12:23 -0400 In-Reply-To: <49F8756C.6080503@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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