[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access

[Scott Wood]

On Fri, 11 Feb 2011 02:41:35 +0100
Alexander Graf <address@hidden> 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.

> Also, please tell me you didn't implement the previous revisions already.

I didn't. :-)

-Scott