On 11.02.2011, at 21:53, Scott Wood wrote: > On Fri, 11 Feb 2011 02:41:35 +0100 > Alexander Graf <ag...@suse.de> wrote: > >>>> Maybe we should go with Avi's proposal after all and simply keep the full >>>> soft-mmu synced between kernel and user space? That way we only need a >>>> setup call at first, no copying in between and simply update the user >>>> space version whenever something changes in the guest. We need to store >>>> the TLB's contents off somewhere anyways, so all we need is an additional >>>> in-kernel array with internal translation data, but that can be separate >>>> from the guest visible data, right? > > Hmm, the idea is growing on me. > >> So then everything we need to get all the functionality we need is a hint >> from kernel to user space that something changed and vice versa. >> >> From kernel to user space is simple. We can just document that after every >> RUN, all fields can be modified. >> From user space to kernel, we could modify the entries directly and then >> pass in an ioctl that passes in a dirty bitmap to kernel space. KVM can then >> decide what to do with it. I guess the easiest implementation for now would >> be to ignore the bitmap and simply flush the shadow tlb. >> >> That gives us the flush almost for free. All we need to do is set the tlb to >> all zeros (should be done by env init anyways) and pass in the "something >> changed" call. KVM can then decide to simply drop all of its shadow state or >> loop through every shadow entry and flush it individually. Maybe we should >> give a hint on the amount of flushes, so KVM can implement some threshold. > > OK. We'll also need a config ioctl to specify MMU type/size and the address > of the arrays.
Right, a setup call basically :). Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
