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