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

[Alexander Graf]

On 10.02.2011, at 19:51, Scott Wood wrote:

> On Thu, 10 Feb 2011 12:45:38 +0100
> Alexander Graf <address@hidden> wrote:
> 
>> Ok, thinking about this a bit more. You're basically proposing a list of
>> tlb set calls, with each array field identifying one tlb set call. What
>> I was thinking of was a full TLB sync, so we could keep qemu's internal
>> TLB representation identical to the ioctl layout and then just call that
>> one ioctl to completely overwrite all of qemu's internal data (and vice
>> versa).
> 
> No, this is a full sync -- the list replaces any existing TLB entries (need
> to make that explicit in the doc).  Basically it's an invalidate plus a
> list of tlb set operations.
> 
> Qemu's internal representation will want to be ordered with no missing
> entries.  If we require that of the transfer representation we can't do
> early termination.  It would also limit Qemu's flexibility in choosing its
> internal representation, and make it more awkward to support multiple MMU
> types.

Well, but this way it means we'll have to assemble/disassemble a list of 
entries multiple times:

SET:
 * qemu assembles the list from its internal representation
 * kvm disassembles the list into its internal structure

GET:
 * kvm assembles the list from its internal representation
 * qemu disassembles the list into its internal structure

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?


Alex