On Mon, 14 Feb 2011 21:19:19 +0100 Alexander Graf <ag...@suse.de> 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
