lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 29 Nov 2017 22:10:47 +0800 From: Greentime Hu <green.hu@...il.com> To: Arnd Bergmann <arnd@...db.de> Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Greentime <greentime@...estech.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-arch <linux-arch@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>, Jason Cooper <jason@...edaemon.net>, Marc Zyngier <marc.zyngier@....com>, Rob Herring <robh+dt@...nel.org>, Networking <netdev@...r.kernel.org>, Vincent Chen <deanbo422@...il.com>, DTML <devicetree@...r.kernel.org>, Al Viro <viro@...iv.linux.org.uk>, David Howells <dhowells@...hat.com>, Will Deacon <will.deacon@....com>, Daniel Lezcano <daniel.lezcano@...aro.org>, "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>, Vincent Chen <vincentc@...estech.com> Subject: Re: [PATCH v2 25/35] nds32: Build infrastructure 2017-11-29 19:57 GMT+08:00 Arnd Bergmann <arnd@...db.de>: > On Wed, Nov 29, 2017 at 12:39 PM, Greentime Hu <green.hu@...il.com> wrote: >> 2017-11-29 17:25 GMT+08:00 Arnd Bergmann <arnd@...db.de>: >>> On Wed, Nov 29, 2017 at 10:10 AM, Geert Uytterhoeven >>> <geert@...ux-m68k.org> wrote: >>>> Hi Arnd, >>>> >>>> On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann <arnd@...db.de> wrote: >>>>> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@...il.com> wrote: >>>>>> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@...db.de>: >>>>>>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@...il.com> wrote: >>>>>>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu >>>>>>>> +config CPU_CACHE_NONALIASING >>>>>>>> + bool "Non-aliasing cache" >>>>>>>> + help >>>>>>>> + If this CPU is using VIPT data cache and its cache way size is larger >>>>>>>> + than page size, say N. If it is using PIPT data cache, say Y. >>>>>>>> + >>>>>>>> + If unsure, say Y. >>>>>>> >>>>>>> Can you determine this from the CPU type? >>>>>> >>>>>> There is no cpu register to determine it. It also depeneds on page >>>>>> size and way size however page size is configurable by software. >>>>>> These codes are determined at compile time will be benefit to code >>>>>> size and performance. >>>>>> IMHO, I think it would be better to be determined here. >>>>> >>>>> I meant determining it at compile time from other Kconfig symbols, >>>>> if that's possible. Do the CPU cores each have a fixed way-size? >>>>> If they do, it could be done like >>>>> >>>>> menu "CPU selection" >>>>> >>>>> config CPU_N15 >>>>> bool "AndesCore N15" >>>>> select CPU_CACHE_NONALIASING >>>>> >>>>> config CPU_N13 >>>>> bool "AndesCore N15" >>>>> select CPU_CACHE_NONALIASING if PAGE_SIZE_16K >>>>> >>>>> ... >>>>> >>>>> endmenu >>>>> >>>>> and then you can use the same CPU_... symbols to make other decisions >>>>> as well, e.g. CPU specific compiler optimizations. >>>> >>>> Do you want to support multiple CPU types in a single kernel image >>>> (I see no "choice" statement above)? >>>> If yes, you may have a mix of aliasing and non-aliasing caches, so >>>> you may want to invert the logic, and select CPU_CACHE_ALIASING >>>> instead. >>> >>> Right, my mistake. >>> >> >> Thanks to Arnd and Geert! >> >> How about this? >> >> choice >> prompt "CPU type" >> default CPU_N13 >> config CPU_N15 >> bool "AndesCore N15" >> select CPU_CACHE_NONALIASING >> config CPU_N13 >> bool "AndesCore N13" >> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB >> config CPU_N10 >> bool "AndesCore N10" >> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB >> config CPU_D15 >> bool "AndesCore D15" >> select CPU_CACHE_NONALIASING >> select HWZOL >> config CPU_D10 >> bool "AndesCore D10" >> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB >> endchoice > > With a 'choice' statement this works, but I would consider that > suboptimal for another reason: now you cannot build a kernel that > works on e.g. both N13 and N15. > > This is what we had on ARM a long time ago and on MIPS not so long > ago, but it's really a burden for testing and distribution once you get > support for more than a handful of machines supported in the mainline > kernel: If each CPU core is mutually incompatible with the other ones, > this means you likely end up having one defconfig per CPU core, > or even one defconfig per SoC or board. > > I would always try to get the largest amount of hardware to work > in the same kernel concurrently. > > One way of of this would be to define the "CPU type" as the minimum > supported CPU, e.g. selecting D15 would result in a kernel that > only works on D15, while selecting N15 would work on both N15 and > D15, and selecting D10 would work on both D10 and D15. > Hi, Arnd: Maybe we should keep the original implementation for this reason. The default value of CPU_CACHE_NONALIASING and ANDES_PAGE_SIZE_8KB is available for all CPU types for now. User can use these configs built kernel to boot on almost all nds32 CPUs. It might be a little bit weird if we config CPU_N10 but run on a N13 CPU. This might confuse our users.
Powered by blists - more mailing lists