On 2011-07-20 18:02, Avi Kivity wrote: > On 07/20/2011 06:58 PM, Jan Kiszka wrote: >> On 2011-07-20 16:54, Avi Kivity wrote: >>> On 07/20/2011 05:37 PM, Michael S. Tsirkin wrote: >>>>> >>>>> 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. >>> >>> It's the same thing. >>> >>> memory_region_init*(); >>> // we have a disconnected memory region >>> memory_region_set_log(); >>> // still disconnected, now logged >>> >>> I don't want memory_region_init() with 231 parameters. >> >> That's OK. The question is if memory_region_set_log should work on both >> invisible AND visible regions. The former makes it a bit-flip service, >> the latter requires a larger machinery. >> > > It works on both visible and invisible regions. > > Again, the entire point of this API is that visibility of a region to > the cpu is not dependent on the device itself, but also on buses in the > hierarchy. If a device wants a region to be logged (or coalesced) it > indicates this to the API, and the core does the rest. Mmm, will think about how to get rid of the start/stop callbacks at least from the memory client interface. > >> BTW, what's broken is legacy VGA mem dirty logging. Was simply dropped >> during the conversion, and now I'm missing some links between vga core >> and its users to reestablish it generically. > > You mean logging of 0xa0000-0xc0000? That's probably a bug in the > core. Once you enable logging of the framebuffer, any aliases should > inherit it. Legacy mem and also VBE aren't registered as aliases, but as independent memory regions. 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
