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 -- 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
