On 01/31/2013 09:26:20 AM, Caraman Mihai Claudiu-B02008 wrote:
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@xxxxxxx]
> Sent: Thursday, January 31, 2013 4:58 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; linuxppc-
> dev@xxxxxxxxxxxxxxxx
> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register
> initialization earlier
>
>
> On 31.01.2013, at 15:56, Caraman Mihai Claudiu-B02008 wrote:
>
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf@xxxxxxx]
> >> Sent: Thursday, January 31, 2013 3:21 PM
> >> To: Caraman Mihai Claudiu-B02008
> >> Cc: kvm-ppc@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; linuxppc-
> >> dev@xxxxxxxxxxxxxxxx
> >> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG
register
> >> initialization earlier
> >>
> >>
> >> On 30.01.2013, at 14:29, Mihai Caraman wrote:
> >>
> >>> VCPU's MMUCFG register initialization should not depend on
> >> KVM_CAP_SW_TLB
> >>> ioctl call. Move it earlier into tlb initalization phase.
> >>
> >> Quite the contrary. The fact that there is an mfspr() in
e500_mmu.c
> >> already tells us that the code is broken. The TLB guest code
should
> only
> >> depend on input from the SW_TLB configuration. It's completely
> orthogonal
> >> to the host capabilities.
> >
> > Then we have the same issue for TLBnCFG registers which need to be
> configured
> > via SW_TLB ioctl. What is the purpose of guest tlb initalization
in
> e500_mmu.c
> > if we rely on SW_TLB?
>
> It's to provide a fallback to user space that doesn't implement
SW_TLB
> configuration yet.
Do we have such a case now or is it just hypothetical? For the
fallback we
need to initialize the MMUCFG register which I intended to say in the
commit
message.
I don't think we need to support a fallback for e6500, since there's
nothing to be backwards compatible with.
As for use case, I don't see us ever supporting the guest being a
different CPU than the host. Page sizes probably aren't a problem, but
there are other barriers.
The main reasons that TLBnCFG are settable through SW_TLB are:
1. The guest TLB can be enlarged as a performance hack (like in Topaz,
though QEMU doesn't currently do this),
2. The legacy default in KVM is based on the e500v1 TLB0 size, which is
half of what e500v2/e500mc have, and
3. QEMU needs to know the exact geometry of the TLB so that it can
interpret the shared data properly.
#3 seems like a compelling reason here, to avoid silent weirdness if
there's a slight mismatch between what QEMU thinks it's modelling and
what we're actually running on.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
