On 2011-07-21 15:50, Avi Kivity wrote: > On 07/21/2011 04:17 PM, Jan Kiszka wrote: >> On 2011-07-21 14:58, Avi Kivity wrote: >>> On 07/21/2011 03:52 PM, Jan Kiszka wrote: >>>>> >>>>> The problem is that "update" can change lots of things. offset, size, >>>>> whether it's mmio or RAM, read-onlyness, even the wierd things like >>>>> coalesced mmio. So it's either a function with 324.2 parameters (or a >>>>> large struct), or it's a series of functions with demarcation as to >>>>> where the update begins and ends. >>>> >>>> We do not need to provide update support for each and every bit, but for >>>> the common cases. memory_region_update_alias(region, offset, size) would >>>> be an excellent first candidate IMO. >>> >>> It's not enough, look at cirrus and PAM. >> >> It's a perfect fit for cirrus, but PAM indeed requires set_readonly in >> addition. >> > > It isn't a pefect fit for cirrus. If the mode changes in a way that > makes mapping the map as RAM possible, or vice versa, and if the banks > are contiguous, then _update() results in two mappings or unmappings, > while _commit() results in just one (since m_r_update_topology() merges > the two adjacent regions). Continuous banks or mode changes are uncommon compared to offset changes of the mapped window. Cirrus does not need to bother about continuity of its banks (the memory core will), and mode changes could be implemented by allowing updates of the priority, thus reordering the regions instead of continuously deleting and recreating them. > >> I also think now that describing a memory region offline via a struct >> and then passing that to an atomic add/del/update would be a more handy >> and future-proof API than an increasing number set functions. > > Maybe. But it's not sufficient for atomic changes involving multiple > regions. Right. The question is still if there are use cases where this matters (ie. update frequencies comparable to graphic scenarios). > > btw, there is another implementation issue involving SMP - if a region > that obscures the middle of another region is removed, we'll have two > regions removed and replaced with a larger one. Yes, I've seen many of such temporary changes in the cirrus remapping logs. > That causes some memory > to be temporarily inaccessible. I don't think it's a problem in > practice, but if it is, we can fix it by stopping all vcpus if we detect > this condition, and by adding an atomic > change-memory-map-and-get-dirty-log ioctl to kvm. I'm not sure if the cirrus or any similar hardware supports consistent memory accesses during ongoing bank remappings (ie. while the CPU issuing the remapping IO commands is blocked on QEMU executing them). But such an IOCTL would resolve our problem with dropping a logged region as well, right? 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
