-----Original Message-----
From: Alexander Graf [mailto:agraf@suse.de]
Sent: Thursday, January 31, 2013 4:58 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org
Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register
initialization earlier
=20
=20
On 31.01.2013, at 15:56, Caraman Mihai Claudiu-B02008 wrote:
=20

quoted

quoted

-----Original Message-----
From: Alexander Graf [mailto:agraf@suse.de]
Sent: Thursday, January 31, 2013 3:21 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org
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:

quoted

VCPU's MMUCFG register initialization should not depend on

KVM_CAP_SW_TLB

quoted

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

quoted

quoted

depend on input from the SW_TLB configuration. It's completely

orthogonal

quoted

quoted

to the host capabilities.

Then we have the same issue for TLBnCFG registers which need to be

configured

quoted

via SW_TLB ioctl. What is the purpose of guest tlb initalization in

e500_mmu.c

quoted

if we rely on SW_TLB?

=20
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 commi=
t
message.

=20
=20
Alex
=20