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

[Scott Wood]

On Mon, 14 Feb 2011 21:19:19 +0100
Alexander Graf <address@hidden> wrote:

> There's no nack here :). The only thing that needs to change is the anonymous 
> part, as that's a gnu extension. Just name the structs and unions and all is 
> well.

Ah, I thought it was an aesthetic objection -- didn't realize it was a
GNUism.  Oh well.

> The reason I was asking is that I assumed the code would end up being easier, 
> not more complex without the u32s. In fact, it probably would. I'll leave the 
> final decision if you want to access things by entry->u81.split.mas8 or 
> entry->mas8_1 & MAS8_1_MAS8_MASK.

After sending that, I was thinking that mas7_3 is more naturally used
as a pair, so I'd stick with the u64 there.

I think mas8_1 benefits less from the pairing, though -- it's only really
useful if you're going to put the value directly in hardware, which we
won't.

> >> The struct name should also have
> >> a version indicator - it's the data descriptor only a single specific
> >> mmu_type, right?
> > 
> > It handles both KVM_MMU_PPC_BOOK3E_NOHV and KVM_MMU_PPC_BOOK3E_HV.
> 
> Even fictional future changes to the tlb layout?

No, those need a new MMU type ID.

> >> Please state the size explicitly then. It's 1k, right?
> > 
> > It's 4K on Freescale chips.  We should probably implement sregs first, in
> > which case qemu can read the MMU config registers to find out the minimum
> > supported page size.
> > 
> > If we specify 4K here, we should probably just go ahead and stick FSL in
> > the MMU type name.  Specifying the hash itself already makes me nervous
> > about claiming the more generic name.
> 
> Yup, sounds good :).

Which one, "read the MMU config registers" or "specify 4K and stick FSL in
the name"?

-Scott