From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Date: Wed, 29 Apr 2009 11:31:22 +0000 Subject: Re: qemu-kvm.git now live Message-Id: <49F83A8A.8040909@siemens.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 Avi Kivity wrote: > 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. So we need some notifier callbacks on slot changes so that all users can re-enable dirty logging after the update as required. Where/how does the migration code disable dirty logging? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Date: Wed, 29 Apr 2009 11:31:22 +0000 Subject: Re: qemu-kvm.git now live Message-Id: <49F83A8A.8040909@siemens.com> List-Id: References: <49F08BD0.6000706@redhat.com> <49F81496.8030407@siemens.com> <49F82F24.8040506@redhat.com> <49F83227.9000502@siemens.com> <49F83630.6020402@redhat.com> In-Reply-To: <49F83630.6020402@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Avi Kivity Cc: KVM list , Anthony Liguori , Hollis Blanchard , "Zhang, Xiantao" , kvm-ppc , "kvm-ia64@vger.kernel.org" , Carsten Otte Avi Kivity wrote: > 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. So we need some notifier callbacks on slot changes so that all users can re-enable dirty logging after the update as required. Where/how does the migration code disable dirty logging? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: qemu-kvm.git now live Date: Wed, 29 Apr 2009 13:31:22 +0200 Message-ID: <49F83A8A.8040909@siemens.com> References: <49F08BD0.6000706@redhat.com> <49F81496.8030407@siemens.com> <49F82F24.8040506@redhat.com> <49F83227.9000502@siemens.com> <49F83630.6020402@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: KVM list , Anthony Liguori , Hollis Blanchard , "Zhang, Xiantao" , kvm-ppc , "kvm-ia64@vger.kernel.org" , Carsten Otte To: Avi Kivity Return-path: Received: from gecko.sbs.de ([194.138.37.40]:15802 "EHLO gecko.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751150AbZD2Lck (ORCPT ); Wed, 29 Apr 2009 07:32:40 -0400 In-Reply-To: <49F83630.6020402@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > 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. So we need some notifier callbacks on slot changes so that all users can re-enable dirty logging after the update as required. Where/how does the migration code disable dirty logging? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux