> -----Original Message----- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Thursday, January 31, 2013 4:58 PM > To: Caraman Mihai Claudiu-B02008 > Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org > 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:ag...@suse.de] > >> Sent: Thursday, January 31, 2013 3:21 PM > >> To: Caraman Mihai Claudiu-B02008 > >> Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc- > >> d...@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: > >> > >>> 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. > > > Alex > -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
