[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access
From: |
Scott Wood |
Subject: |
[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access |
Date: |
Mon, 14 Feb 2011 15:16:57 -0600 |
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
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, (continued)
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/10
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/10
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/10
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/10
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/11
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/11
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/11
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/13
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access,
Scott Wood <=
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Avi Kivity, 2011/02/07
- [Qemu-devel] RE: RFC: New API for PPC for vcpu mmu access, Yoder Stuart-B08248, 2011/02/07
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Avi Kivity, 2011/02/08
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/09
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/10
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Edgar E. Iglesias, 2011/02/10
- [Qemu-devel] RE: RFC: New API for PPC for vcpu mmu access, Yoder Stuart-B08248, 2011/02/02