On 10/12/2012 04:51 AM, Benjamin Herrenschmidt wrote: > On Thu, 2012-10-11 at 15:57 +0200, Avi Kivity wrote: >> >> Map/unmap is supported via address_space_map(), which calls >> >> ->translate(). I don't see how a lower-level map/unmap helps, >> unless >> >> the hardware supplies such a function. >> > >> > Yep, it's just the map/unmap callbacks that are not supported >> anymore, >> > but nobody uses that feature of DMAContext yet. >> >> What do those callbacks it even mean? > > Well, the unmap callback was meant for notifying the device that did a > map() that the iommu has invalidated part of that mapping. > > The rough idea was that the actual invalidations would be delayed until > all "previous" maps have gone away, which works fine without callbacks > for transcient maps (packet buffers ,etc...) but doesn't for long lived > ones.
Something like the kernel's kvm_read_guest_cached()? You can then invalidate translations by incrementing a generation counter. Problem is you don't get a simple pointer, but rather something with an API that needs to be used. > > So in addition, we would call that callback for devices who own long > lived maps, asking them to dispose of them (and eventually re-try them, > which might or might not fail depending on why the invalidation occurred > in the first place). > > The invalidation would still be delayed until the last old map has gone > away, so it's not a synchronous callback, more like a notification to > the device to wakeup & do something. > > But in the latest patches that went in, because the whole scheme was too > complex and not really that useful, I ripped out the whole map tracking > etc... I kept the unmap callback API there in case we want to re-do it > more sanely. > > When emulating HW iommu's the "invalidation not complete" is easy to > report asynchronously to the guest via a status bit that the guest is > supposdly polling after doing an invalidation request. > > On something like synchronous hcalls (PAPR), the idea was to delay the > hcall completion by suspending the cpu who issued it. With the above, you can synchronize using synchronize_rcu(). > > A lot of pain for what is essentially a corner case that doesn't happen > in practice... unless we start doing mapping games. > > By mapping games, I mean having an emulated device MMIO space being > mapped into user space in a way where the kernel might change the > mapping "live" (for example to point to backup memory as it migrates > thing away, etc...). This kind of stuff typically happens with graphics > where graphic objects can move between memory and vram. > Sounds nasty. In general we try to avoid special cases during migration, it's fragile enough. -- error compiling committee.c: too many arguments to function
