RE: RFC: New API for PPC for vcpu mmu access

[Yoder Stuart-B08248 <B08248@freescale.com>]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Monday, February 07, 2011 12:52 PM
> To: Alexander Graf
> Cc: Yoder Stuart-B08248; Wood Scott-B07421; kvm-ppc@vger.kernel.org;
> kvm@vger.kernel.org; qemu-devel@nongnu.org
> Subject: Re: RFC: New API for PPC for vcpu mmu access
> 
> On Mon, 7 Feb 2011 17:49:51 +0100
> Alexander Graf <agraf@suse.de> wrote:
> 
> >
> > On 07.02.2011, at 17:40, Yoder Stuart-B08248 wrote:
> >
> > > Suggested change to this would be to have Qemu set tlb_type as
> > > an _input_ argument.   If KVM supports it, that type gets used,
> > > else an error is returned.    This would allow Qemu to tell
> > > the kernel what type of MMU it is prepared to support.   Without
> > > this Qemu would just have to error out if the type returned is
> > > unknown.
> >
> > Yes, we could use the same struct for get and set. On set, it could
> transfer the mmu type, on get it could tell userspace the mmu type.
> 
> What happens if a get is done before the first set, and there are multiple
> MMU type options for this hardware, with differing entry sizes?
> 
> Qemu would have to know beforehand how large to make the buffer.
> 
> We could say that going forward, it's expected that qemu will do a TLB set
> (either a full one, or a lightweight alternative) after creating a vcpu.
> For compatibility, if this doesn't happen before the vcpu is run, the TLB
> is created and initialized as it is today, but no new Qemu-visible features
> will be enabled that way.

Since I think the normal thing Qemu would want to do is determine
the type/size before allocating space for the TLB, we could just
pass in NULL for tlb_data on the first set.   If tlb_data is
NULL we just set the MMU type and return the size (and type).

> If Qemu does a get without ever doing some set operation, it should get an
> error, since the requirement to do a set is added at the same time as the
> get API.

Right.

Stuart