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.
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.
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
