Re: [PATCH] memory: transaction API

Jan Kiszka
2011-07-21T12:09:08Z

On 2011-07-21 14:05, Avi Kivity wrote:
> On 07/21/2011 01:38 PM, Jan Kiszka wrote:
>> On 2011-07-21 12:21, Avi Kivity wrote:
>>> Allow changes to the memory hierarchy to be accumulated and
>>> made visible all at once. This reduces computational effort,
>>> especially when an accelerator (e.g. kvm) is involved.
>>>
>>> Useful when a single register update causes multiple changes
>>> to an address space.
>>
>> That's simple to implement in the core, but complicates life for the
>> users, at least for the simple "update this region" use case.
>>
>
> Why? just stick a _begin() and _commit() at the start and end of the
> update_mapping() function. It's an optional API, for simple cases (like
> mapping a BAR) you don't have to use it.

begin
delete old
free old
create new
add new
end

vs.

update

>
>
>> Do we have transactional scenarios during runtime where multiple memory
>> regions are reconfigured?
>
> Both cirrus and 440fx PAM, I believe. They don't check for the "no
> change" condition (at least, not completely) and instead override the
> previous mapping.

That's the job of the memory mapping core IIUC. But it can only be done
efficiently with an 'update' operation.

Jan

--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux