From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC v4 00/58] Memory API Date: Wed, 20 Jul 2011 16:42:27 +0200 Message-ID: <4E26E953.3090802@siemens.com> References: <1310901265-32051-1-git-send-email-avi@redhat.com> <20110719135601.GA7194@redhat.com> <4E25B85C.1030809@siemens.com> <4E25BB7A.7030105@redhat.com> <4E25BF26.6080900@siemens.com> <4E268E20.5050807@redhat.com> <4E26BF77.7070705@siemens.com> <4E26C290.8010604@redhat.com> <4E26DECC.9000700@siemens.com> <4E26E716.2090109@redhat.com> <20110720143720.GC6787@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" To: "Michael S. Tsirkin" Return-path: Received: from goliath.siemens.de ([192.35.17.28]:21167 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751778Ab1GTOmf (ORCPT ); Wed, 20 Jul 2011 10:42:35 -0400 In-Reply-To: <20110720143720.GC6787@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-07-20 16:37, Michael S. Tsirkin wrote: > On Wed, Jul 20, 2011 at 05:32:54PM +0300, Avi Kivity wrote: >> On 07/20/2011 04:57 PM, Jan Kiszka wrote: >>> Something around dirty logging is still seriously borken: when I boot >>> with standard or cirrus vga, the screen is not properly updated in >>> logged modes. >>> >> >> I don't see this here, will retest. >> >>> I bet the reason is lacking semantics of >>> cpu_register_physical_memory_log(..., true), ie. the chance to register >>> a memory region with logging enabled. We need to explicitly enable it >>> now via memory_region_set_log, right? Is there any ordering issue to >>> expect, ie. when can I first call memory_region_set_log (as it issues >>> the start/stop client callbacks)? >> >> There should be no ordering issue at all. >> >> If you do a memory_region_set_log() immediately after >> memory_region_init_ram(), then as soon as the framebuffer is added >> to the memory hierarchy, it will have logging enabled (or any >> aliases of the framebuffer). > > Still, I think we should specify logging on/off when region is created, > and avoid APIs that tweak dirty logging. > I don't think there's actual need for device to enable/disable > logging. What devices seem to need, instead, is enable/disable a region > through a back channel. Dropping memory_region_set_log would allow to drop the corresponding client callbacks as well. However, we apparently need enable/disable semantic for the crazy vmware vga. I tried without but failed. But we could map it for this single user on delete/recreate (like I did with my original patches). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjXyr-0001X0-GX for qemu-devel@nongnu.org; Wed, 20 Jul 2011 10:42:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjXyp-00058a-3d for qemu-devel@nongnu.org; Wed, 20 Jul 2011 10:42:32 -0400 Received: from goliath.siemens.de ([192.35.17.28]:20906) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjXyn-00057q-W6 for qemu-devel@nongnu.org; Wed, 20 Jul 2011 10:42:30 -0400 Message-ID: <4E26E953.3090802@siemens.com> Date: Wed, 20 Jul 2011 16:42:27 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1310901265-32051-1-git-send-email-avi@redhat.com> <20110719135601.GA7194@redhat.com> <4E25B85C.1030809@siemens.com> <4E25BB7A.7030105@redhat.com> <4E25BF26.6080900@siemens.com> <4E268E20.5050807@redhat.com> <4E26BF77.7070705@siemens.com> <4E26C290.8010604@redhat.com> <4E26DECC.9000700@siemens.com> <4E26E716.2090109@redhat.com> <20110720143720.GC6787@redhat.com> In-Reply-To: <20110720143720.GC6787@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v4 00/58] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Avi Kivity , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" On 2011-07-20 16:37, Michael S. Tsirkin wrote: > On Wed, Jul 20, 2011 at 05:32:54PM +0300, Avi Kivity wrote: >> On 07/20/2011 04:57 PM, Jan Kiszka wrote: >>> Something around dirty logging is still seriously borken: when I boot >>> with standard or cirrus vga, the screen is not properly updated in >>> logged modes. >>> >> >> I don't see this here, will retest. >> >>> I bet the reason is lacking semantics of >>> cpu_register_physical_memory_log(..., true), ie. the chance to register >>> a memory region with logging enabled. We need to explicitly enable it >>> now via memory_region_set_log, right? Is there any ordering issue to >>> expect, ie. when can I first call memory_region_set_log (as it issues >>> the start/stop client callbacks)? >> >> There should be no ordering issue at all. >> >> If you do a memory_region_set_log() immediately after >> memory_region_init_ram(), then as soon as the framebuffer is added >> to the memory hierarchy, it will have logging enabled (or any >> aliases of the framebuffer). > > Still, I think we should specify logging on/off when region is created, > and avoid APIs that tweak dirty logging. > I don't think there's actual need for device to enable/disable > logging. What devices seem to need, instead, is enable/disable a region > through a back channel. Dropping memory_region_set_log would allow to drop the corresponding client callbacks as well. However, we apparently need enable/disable semantic for the crazy vmware vga. I tried without but failed. But we could map it for this single user on delete/recreate (like I did with my original patches). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux