On Tue, 2012-07-10 at 15:48 -0600, Alex Williamson wrote: > > specific hypervisor calls, not sure what a MemoryListener would do > > here ... > > Hmm, the guest directed iommu updates via hypercalls may not really fit > the MemoryListener model. I'm just trying to think of ways to avoid > having an offshoot of vfio in the power code base by making use of > common abstraction layers. If we got a region_add/del callback we could > potentially move the spapr map and unmap into vfio like we do for x86. > Thanks,
In the end we don't really want to use that anyway. map and unmap are *extremely* performance sensitive in practice, so plan is to implement the hypercall directly in the kernel KVM at a level where it won't even go near generic code :-) Basically, when the hypercall gets in, we take control in what we call "real mode" on powerpc (MMU off, translation disabled), we have a window to implement critical stuff like this before we context switch the MMU to the host context (which on P7 is quite expensive). This is where I want to go directly whack the TCE table as used by the HW (provided the page has a good PTE of course), pretty much like we do for populating the main MMU hash table. So the map/unmap path will be entirely in arch specific code. The one you see in Alexey code is basically only ever going to be used by something like qemu full emulation... Cheers, Ben.
