qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCHv2 1/3] qemu: memory notifiers


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCHv2 1/3] qemu: memory notifiers
Date: Mon, 18 Jan 2010 18:08:33 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

On Mon, Jan 18, 2010 at 06:04:40PM +0200, Avi Kivity wrote:
> On 01/18/2010 05:45 PM, Michael S. Tsirkin wrote:
>>
>> cpu_register_physical_memory_offset already is O(memory size) btw.
>>    
>
> Right, but we'd like to replace it with a range API.

So, when we do the implementation of notifiers can follow?

>>>>> Maybe we mandate clients be registered at init-time?
>>>>>
>>>>>          
>>>> This might be tricky - vhost currently only registers when the
>>>> first device is hot-added.
>>>>
>>>>        
>>> I see.
>>>
>>> Maybe coalesce adjacent pages and call the callback with the ranges?
>>>      
>> Hmm, it turns out to be tricky: it seems whether we can do this
>> really depends on what get_ram_ptr returns ...
>> Can't we just rely on callback to do the coalescing?
>>    
>
> If the callback can do the coalescing, surely the caller can as well?

The callback calls qemu_ram_ptr and coalesces when the virtual memory
pointers are matching. caller can do this as well but it looks ugly: we
don't know this is what caller does ...

> This way we don't introduce a new per-page API.

What do you mean by new per-page API?
The API is range-based, implementation
currently scans all pages.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]