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