Re: [Qemu-devel] [RFC v4 00/58] Memory API

[Avi Kivity]

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.

> 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.

--
error compiling committee.c: too many arguments to function