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

[Jan Kiszka]

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