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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
