Received: from mailapp01.imgtec.com ([195.59.15.196]:33757 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S27012169AbaJVVxViFOSZ (ORCPT ); Wed, 22 Oct 2014 23:53:21 +0200 Date: Wed, 22 Oct 2014 22:53:13 +0100 From: James Hogan Subject: Re: Single MIPS kernel Message-ID: <20141022215313.GC12296@jhogan-linux.le.imgtec.org> References: <20141022083437.GB18581@linux-mips.org> <5447EFB5.4090009@gmail.com> <20141022190515.GC12502@linux-mips.org> <20141022204209.GE12502@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <20141022204209.GE12502@linux-mips.org> Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Ralf Baechle Cc: "Maciej W. Rozycki" , David Daney , linux-mips@linux-mips.org, Ben Hutchings Message-ID: <20141022215313.NeGJvgKG4C1faBPYxXiLmX_zk19JYSHf2M2vWIVjGg0@z> Hi, On Wed, Oct 22, 2014 at 10:42:09PM +0200, Ralf Baechle wrote: > On Wed, Oct 22, 2014 at 08:19:07PM +0100, Maciej W. Rozycki wrote: > > Wouldn't it make sense to make a unified kernel virtually mapped? That > > would avoid the issue with RAM being present at different locations across > > systems and also if big pages were used, that I believe are available > > almost universally across the MIPS family, any performance hit would be > > minimal. There would be hardly any increase in the binary image size too. > > Run-time mappings such as `kmalloc' or `ioremap' could continue using > > unmapped segments. > Otoh the mapped kernel certainly would have the lowest size overhead. > I have faint memories of restrictions for TLB instructions or was it > TLB exception handlers into mapped space, would have to do some rtfming > on that topic. Yeh, KVM puts all tlb handling in arch/mips/kvm/tlb.c, which is built statically rather than being included in the kvm kernel module, exactly for this reason, so that it resides in unmapped memory space. You'd have to guarantee not to get a TLB exception while the TLB registers contain important values, since they'll get clobbered by the taking of the exception itself (e.g. EntryHi gets set to failing address, EntryLo* undefined), or the TLB entry pointed to by CP0_Index may be replaced. There's always CP0_Wired - its use in the kernel is a bit of a mess atm IIRC. Cheers James