From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TNnwJ-0007CS-OS for qemu-devel@nongnu.org; Mon, 15 Oct 2012 12:54:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TNnwD-0003YX-ON for qemu-devel@nongnu.org; Mon, 15 Oct 2012 12:54:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17973) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TNnwD-0003Xa-Fm for qemu-devel@nongnu.org; Mon, 15 Oct 2012 12:54:45 -0400 Message-ID: <507C3FB8.70409@redhat.com> Date: Mon, 15 Oct 2012 18:54:16 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1349962023-560-1-git-send-email-avi@redhat.com> <1349962023-560-4-git-send-email-avi@redhat.com> <5076CCAB.5030202@redhat.com> <5076CD8F.7030808@redhat.com> <5076CF7B.3030101@redhat.com> <5076D02D.2070107@redhat.com> <1350010269.20486.138.camel@pasglop> In-Reply-To: <1350010269.20486.138.camel@pasglop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v1 3/7] memory: iommu support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: "Michael S. Tsirkin" , qemu-devel@nongnu.org, liu ping fan , Blue Swirl , Alex Williamson , Anthony Liguori , Paolo Bonzini , David Gibson 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