On Sun, Oct 26, 2008 at 06:33:44PM -0700, Chad Reese wrote: > >> -#ifdef CONFIG_64BIT > >> +#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_CAVIUM_OCTEON) > >> + /* > >> + * Note: We always set ST0_KX on Octeon since IO addresses are at > >> + * 64bit addresses. Keep in mind this also moves the TLB handler. > >> + */ > >> setup_c0_status ST0_KX 0 > > > > That's a bit odd - on 64-bit kernels KX would be set anyway and on 32-bit > > kernels would be corrupted by exceptions or interrupts, so 64-bit > > addresses are not safe to use on 32-bit kernels for most part. > > > > 32-bit virtual addresses mapped to a non-compat address otoh will work fine > > without KX set. > > > > Ralf > > The Octeon IO space regions are significantly larger than a 32bit kernel > could tlb map easily. The entire range takes 49 bits to address. As a > not particularly clean, but working alternative, we enable 64bit > addressing in the kernel and used XKPHYS to access IO. Every access was > surrounded by a local_irq_save/local_irq_restore. Since this is ugly to > the extreme, maybe we should drop being able to boot a 32bit kernel on > Octeon until something better is worked out. That address space may be huge but for any given application you're probably only ever going to access a tiny fraction of it - in particular one where the kernel model of choice is a 32-bit kernel. If these assumptions don't hold for the Cavium, then I ditching 32-bit kernels is the obvious choice. We've given up on 32-bit kernels for the SGI O2 for example - it was just too ugly, too painful. For very small configurations of SGI Origins it would have been possible similarly for small Broadcom Sibyte configs - but in practice these days we use 64-bit kernels. 32-bit is just so yesterday and the 64-bit Linux/MIPS kernels are now nearly a decade old. Ralf
