From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A76CEC3A5A9 for ; Mon, 4 May 2020 11:27:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 898E42073B for ; Mon, 4 May 2020 11:27:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728562AbgEDL1u (ORCPT ); Mon, 4 May 2020 07:27:50 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:55445 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727976AbgEDL1u (ORCPT ); Mon, 4 May 2020 07:27:50 -0400 Received: from mail-qk1-f171.google.com ([209.85.222.171]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1N5CMP-1j3YFF0wSr-011DFF for ; Mon, 04 May 2020 13:27:48 +0200 Received: by mail-qk1-f171.google.com with SMTP id i14so4852097qka.10 for ; Mon, 04 May 2020 04:27:48 -0700 (PDT) X-Gm-Message-State: AGi0PuZvXndvkmVdut3iGs0aopXJQvYMpBIXQIjJQlEOmI/Qrm5lyfYF 4IKWuhQquyXEsungG+06+NLvNQeB7iJ2M9uoM2E= X-Google-Smtp-Source: APiQypIIHoujLODItegRRgCsMaNglRK7LNUpimxq01cun2hB/w8fYeIm4nZCEGen6hYmmyMPRHB0gBdjFi2URrtAcZQ= X-Received: by 2002:a37:a492:: with SMTP id n140mr16289220qke.352.1588591667069; Mon, 04 May 2020 04:27:47 -0700 (PDT) MIME-Version: 1.0 References: <20200331093241.3728-1-tesheng@andestech.com> <20200408035118.GA1451@andestech.com> <20200414151748.GA5624@afzalpc> <20200415135407.GA6553@afzalpc> <20200503145017.GA5074@afzalpc> <20200504091018.GA24897@afzalpc> In-Reply-To: <20200504091018.GA24897@afzalpc> From: Arnd Bergmann Date: Mon, 4 May 2020 13:27:31 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] Highmem support for 32-bit RISC-V To: afzal mohammed Cc: Russell King , Alan Kao , Eric Lin , Gary Guo , alex@ghiti.fr, David Abdurachmanov , Anup Patel , "linux-kernel@vger.kernel.org" , Andrew Morton , Steven Price , atish.patra@wdc.com, yash.shah@sifive.com, Albert Ou , Palmer Dabbelt , Greentime Hu , zong.li@sifive.com, Paul Walmsley , Mike Rapoport , Thomas Gleixner , Borislav Petkov , Logan Gunthorpe , linux-riscv@lists.infradead.org, Linux ARM Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:h8TK6tTY8IJxPzp2xKXu8vHec7/caLMkY2RIP/P9mLMkxvHhpnV TNe/DZbrW75p+bANVWhmSdm6gFNckfZ1xt+sYhark9ua3PTFyc6uLmnIYEMm0zVAh5XToit snzAVVynsnbO/Xb06UEOtuuTGbXFUr8J7Ugp0vt47SM30oxRvMEMgjfl5UbQb4cqp5R7AKu E60a40gmC+5WkGMpUUJbA== X-UI-Out-Filterresults: notjunk:1;V03:K0:41GJnzizHjA=:6G4P0KRSZ2watz0fMnPHg/ GBQWiNAt03J2AKbpF9rkhkNV1S6hMmptTR3S6ZnWfYLjJtoGPBc/A8PdBydod3gYyLKnmGWZ5 7x6ypjbgyMwXFnLb2OVNoaiPfsR41Mm8iqAeOQ3qShv7IR7DCtsGxAsVtxrfeeBWxM2yG2ilc nI/qsFdjpnfpuMx/WjWU7XJlAaTFh2Sc7S4VMzew8S0i18NmBjptOI1WK56SCMETCYFxmFERZ u8MEuPclhyD66pzxwP3V45bqPhuZi5sFISWJT0mIGBc9xlVvjWB8oLe1NCBJfg8mDduLbSBOC GzgHvDHOAA5rMEG6kwPiHdw1ew9HJOvhvBmxYQIcFNaHL2k1RhWouxsQQeqW90fHyK4xkbsuZ OgY6fIpSJK90QPumlE7BZgZx1DTE0fnR1Hw/5QQGBO2osL2JmnVE4bKFqdpQ1D/gOmgn/fxc/ Fxymm6VQwjkHN0sEWDn2OSeLRnjq21EX2adZBIw1OzB2W0fSpF+LtOrqjnIk/x+Zrn08zsg6F wY4IK1pWQgUlVxbPFqI0aYUVi/9LOgGDG/wzDjqT8x72waAH+pkJulJRLdm/dWcgQYaX8SKsD dQTXvbWKzV0drzViT5biWe+TETLThTB2Zc3kDBuah2ZrV3kbt1yVDJsSf5Y3WCucj6+5fRSCV 3SwAWN2h8Aql0xTYKko4aoTkB8BuCcWiSwqK/qHmLHf6OTrMPgLSp7JzHt1j49pBmaUwUnuDG CLUHmm+VcGRQnsXl/Chvo8cSGTh0XYKj5WVY6jqouqXpjiJrwqculzN9tlsxMwJO7KhJR8ezV jl7LNYEl4hwzdeEU954jiNpJ2d3P/MoneBXrk3Z0YKB7wLAF1Y= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 4, 2020 at 11:10 AM afzal mohammed wrote: > > [ +linux-arm-kernel > > Context: This is regarding VMSPLIT_4G_4G support for 32-bit ARM as a > possible replacement to highmem. For that, initially, it is being > attempted to move static kernel mapping from lowmem to vmalloc space. > > in next reply, i will remove everyone/list !ARM related ] > > Hi, > > On Sun, May 03, 2020 at 10:20:39PM +0200, Arnd Bergmann wrote: > > > Which SoC platform are you running this on? Just making > > sure that this won't conflict with static mappings later. > > Versatile Express V2P-CA15 on qemu, qemu options include --smp 2 & > 2GB memory. Ok > BTW, i could not convince myself why, except for DEBUG_LL, static io > mappings are used. I don't think vexpress uses it, but others have some 'struct map_desc' instances mostly for historic reasons, e.g. to map some registers that are needed at very early boot time, or from assembler files. > > One problem I see immediately in arm_memblock_init() > > Earlier it went past arm_memblock_init(), issue was clearing the page > tables from VMALLOC_START in devicemaps_init() thr' paging_init(), > which was like cutting the sitting branch of the tree. > > Now it is crashing at debug_ll_io_init() of devicemap_init(), and > printascii/earlycon was & is being used to debug :). Things are going > wrong when it tries to create mapping for debug_ll. It looks like a > conflict with static mapping, which you mentioned above, at the same > time i am not seeing kernel static mapping in the same virtual > address, need to dig deeper. > > Also tried removing DEBUG_LL, there is a deafening silence in the > console ;) I don't think there is any other mapping that would conflict with the DEBUG_LL one, but you may be in a hole where the existing one is not mapped. IIRC it first gets mapped in __create_page_tables() in arch/arm/kernel/head.S, and later in debug_ll_io_init(), but if the old page tables were just discarded, it won't work for a bit. Using gdb to step through the code in qemu is often more reliable than printing to the console, at least until you get to the point when you have registered the real console. > __virt_to_phys_nodebug() which does the actual work on __pa() invocation > has been modifed to handle that case (ideas lifted from ARM64's > implementation), though currently it is a hack as below (and applicable > only for ARM_PATCH_PHYS_VIRT disabled case), other hacks being > VMALLOC_OFFSET set to 0 and adjusting vmalloc size. > > static inline phys_addr_t __virt_to_phys_nodebug(unsigned long x) > { > phys_addr_t __x = (phys_addr_t)x; > > if (__x >= 0xf0000000) > return __x - KIMAGE_OFFSET + PHYS_OFFSET; > else > return __x - PAGE_OFFSET + PHYS_OFFSET; > } Ok, makes sense. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C59DEC3A5A9 for ; Mon, 4 May 2020 11:28:01 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9AFD52073B for ; Mon, 4 May 2020 11:28:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lXSJybRK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9AFD52073B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:To: Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=9ZOLLHTnQZUZwincSOGGc3EQxTyvADvqMiVZhyFEpI8=; b=lXSJybRKc/wid0an8V2rjAwwA hMteraEPNvCWKs7Df+vyn0LbElYxUS/T9as10VZj/atkSXoZXUqZIWsCH0YT4r9UluSWi+gx9gCig mT8nRNPPKHUyvKCLoZcC4VEIQnf9G4vBReUe4Wj3Z7C+jA5zK6qhGxhwF907HQIqA4mtIH6vwOzNQ Hvp2NN9t7+kn2lCeKhctMaqDD/DC38I80Mloxbe532R0Nw9k0Hl3RCgHYNTC7FDZUv6S5Uc9vHwfN rB9gtjp18PJiztXtj/b38I8uHccWvCrdhDrCXuI9cLqYCJnmMU78BbeY91dJEc89UzaRZtOtS8QWi nrE4lzU6w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jVZGM-0007J4-1k; Mon, 04 May 2020 11:27:54 +0000 Received: from mout.kundenserver.de ([212.227.126.134]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jVZGJ-0007IC-8D; Mon, 04 May 2020 11:27:52 +0000 Received: from mail-qk1-f179.google.com ([209.85.222.179]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1McpW6-1ivgXu291m-00a0nZ; Mon, 04 May 2020 13:27:48 +0200 Received: by mail-qk1-f179.google.com with SMTP id g185so2547754qke.7; Mon, 04 May 2020 04:27:48 -0700 (PDT) X-Gm-Message-State: AGi0PuaUC+2HrxCUgN2IesRCGbfrHx8QPc4184NIyVwewWTUYmjSf+v1 8chruImgNXFDnUqPoskjcIESomSEWbR6fcwOA0k= X-Google-Smtp-Source: APiQypIIHoujLODItegRRgCsMaNglRK7LNUpimxq01cun2hB/w8fYeIm4nZCEGen6hYmmyMPRHB0gBdjFi2URrtAcZQ= X-Received: by 2002:a37:a492:: with SMTP id n140mr16289220qke.352.1588591667069; Mon, 04 May 2020 04:27:47 -0700 (PDT) MIME-Version: 1.0 References: <20200331093241.3728-1-tesheng@andestech.com> <20200408035118.GA1451@andestech.com> <20200414151748.GA5624@afzalpc> <20200415135407.GA6553@afzalpc> <20200503145017.GA5074@afzalpc> <20200504091018.GA24897@afzalpc> In-Reply-To: <20200504091018.GA24897@afzalpc> From: Arnd Bergmann Date: Mon, 4 May 2020 13:27:31 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] Highmem support for 32-bit RISC-V To: afzal mohammed Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:/i9t9qRKXOiKxyqXA6m/MK1Dt9wZmarX1euFn6iZiLiRMY1dmMs 5gRsCO2AVEnZiWpuU85IphtVlTrWoTUYyxfUnfSgMVc8Td7fDHIYdZVPsFFZjQqapv4d8yj u8l0CqQOUU6BuOJLp7bIcmy9EHMkO3iTxKTA8uK0z3044eT4hK37756rS/Z37GNASNLzx/V ow/SqdlHxJYCk0aMz9Vrw== X-UI-Out-Filterresults: notjunk:1;V03:K0:uoER3ETRvKQ=:szTyIVw5GpnxpP1S+y/L7J PJzUI53uNk2B+Ml8oMXHdOzudq/Lokn2OEuepcxoBiVh//xtctDrNZCsm1Ux90HoZRXaqESHe kO8UQiG0Wz8QKBknpMVrJt+5MYdMckT1gQUcZlvA88L2SkeIMyslH/Z17aBujaj4eYfvZ5Hma KfFww/qukA9Mfl/DEHdXt7iogVeAoRwVSrCVjgt0bMgqOlp2nF9Har1qxdFZ4pTikFpWeea5B IEoz7K/TWfwQ/rjuSBxQzmS/Cc/V8445Ewx01MDH2DfPSv83ideW7QLALmuJ2SWSsHNX4PWgI Ma8uM9PG3arKw5427wrcqz+Ja8U0fSPz9uz1ZJD1+yCJB2EwNQBaqLDxxjf8DlyhFHoAQFHye zf3e6plf9qGr13yZoyOeBovfZxhdLMS2tkIBaMFbx7lWcwURxtPeFMJ/5LDWURwy2xLRbsBSV N7RgVfG6J1xx3xzJwuTA4l+p/LJBGJw6RU83PDjjnUvI/yg+NDLKIKEcXPrD1topzQzTqPIwP R29ilskpHNMqNNuzMVh/Mf3/CtFuXunTLBbPegr74v/AUGeaVabWqorsUvfRZGVIF/fgjTM6T KqlvoNZkLu/TbvA/jLpBOd8p/FgE/imKK3RnXvnzm/Mtm5Ke6ENbnaQDGwuPP+s0BCzCP8Oqt 609DiBLZLCbUesdK7RXHLiH+Qf77bRZEBFRbX41sGJllwJ1uyi1qr3T5kB9jUM46ZcKrpcI6O BY+izBPW6T681wKE1py+HOxnnw/xmt0eO5klV2NYLhg+vjFANlju/oq3oVYfj3SzgTy/Onl65 GvU1d02swley3SKbR9x1IJZxojcFiJKmfk/j7DTzEny7TS9mTw= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200504_042751_597832_F6AE1FE9 X-CRM114-Status: GOOD ( 22.17 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: zong.li@sifive.com, Alan Kao , atish.patra@wdc.com, Albert Ou , Gary Guo , linux-riscv@lists.infradead.org, Steven Price , alex@ghiti.fr, Russell King , Mike Rapoport , Borislav Petkov , Eric Lin , Greentime Hu , Paul Walmsley , Thomas Gleixner , Linux ARM , David Abdurachmanov , Anup Patel , "linux-kernel@vger.kernel.org" , yash.shah@sifive.com, Palmer Dabbelt , Andrew Morton , Logan Gunthorpe Sender: "linux-riscv" Errors-To: linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org On Mon, May 4, 2020 at 11:10 AM afzal mohammed wrote: > > [ +linux-arm-kernel > > Context: This is regarding VMSPLIT_4G_4G support for 32-bit ARM as a > possible replacement to highmem. For that, initially, it is being > attempted to move static kernel mapping from lowmem to vmalloc space. > > in next reply, i will remove everyone/list !ARM related ] > > Hi, > > On Sun, May 03, 2020 at 10:20:39PM +0200, Arnd Bergmann wrote: > > > Which SoC platform are you running this on? Just making > > sure that this won't conflict with static mappings later. > > Versatile Express V2P-CA15 on qemu, qemu options include --smp 2 & > 2GB memory. Ok > BTW, i could not convince myself why, except for DEBUG_LL, static io > mappings are used. I don't think vexpress uses it, but others have some 'struct map_desc' instances mostly for historic reasons, e.g. to map some registers that are needed at very early boot time, or from assembler files. > > One problem I see immediately in arm_memblock_init() > > Earlier it went past arm_memblock_init(), issue was clearing the page > tables from VMALLOC_START in devicemaps_init() thr' paging_init(), > which was like cutting the sitting branch of the tree. > > Now it is crashing at debug_ll_io_init() of devicemap_init(), and > printascii/earlycon was & is being used to debug :). Things are going > wrong when it tries to create mapping for debug_ll. It looks like a > conflict with static mapping, which you mentioned above, at the same > time i am not seeing kernel static mapping in the same virtual > address, need to dig deeper. > > Also tried removing DEBUG_LL, there is a deafening silence in the > console ;) I don't think there is any other mapping that would conflict with the DEBUG_LL one, but you may be in a hole where the existing one is not mapped. IIRC it first gets mapped in __create_page_tables() in arch/arm/kernel/head.S, and later in debug_ll_io_init(), but if the old page tables were just discarded, it won't work for a bit. Using gdb to step through the code in qemu is often more reliable than printing to the console, at least until you get to the point when you have registered the real console. > __virt_to_phys_nodebug() which does the actual work on __pa() invocation > has been modifed to handle that case (ideas lifted from ARM64's > implementation), though currently it is a hack as below (and applicable > only for ARM_PATCH_PHYS_VIRT disabled case), other hacks being > VMALLOC_OFFSET set to 0 and adjusting vmalloc size. > > static inline phys_addr_t __virt_to_phys_nodebug(unsigned long x) > { > phys_addr_t __x = (phys_addr_t)x; > > if (__x >= 0xf0000000) > return __x - KIMAGE_OFFSET + PHYS_OFFSET; > else > return __x - PAGE_OFFSET + PHYS_OFFSET; > } Ok, makes sense. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD0CFC3A5A9 for ; Mon, 4 May 2020 11:27:56 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A120C2073B for ; Mon, 4 May 2020 11:27:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="OXTpldof" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A120C2073B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xJ+l9nTX6s6Onm1W+GvtaftRy+PAx/t5Jmk7u/X5md4=; b=OXTpldofpYXLmP Zs3AjjNDBiWggzHsVYkv0wrUjKyME/cbHhUJcYlWgym7Vzesk/9AZQtEUsUT2KhGgHheLPJkAWFn/ 05csRWvjTPBLzOp6fBAG12ntqAQ7YuL4CTVML5Ja2+BuVOHkHnfhkofcJU0fnUTi1Ay6i8/sxGWPZ uHcESoLsOJZRrP6Fokr5NeW1uM0WNofbt5vAUbAcDePUqdAUtNW8OQ5Z5q4iofrts2VKybUK5RIfg XgjanCz0Sz+YLabG9yNQDi2ZJPFuUFh7THsGomx809dVxDZKBgtmL83If5F6tInNog7q0q9IwLAoh F6lcngH2dhX8hIuLxPGw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jVZGN-0007KA-Lm; Mon, 04 May 2020 11:27:55 +0000 Received: from mout.kundenserver.de ([212.227.126.134]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jVZGJ-0007IC-8D; Mon, 04 May 2020 11:27:52 +0000 Received: from mail-qk1-f179.google.com ([209.85.222.179]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1McpW6-1ivgXu291m-00a0nZ; Mon, 04 May 2020 13:27:48 +0200 Received: by mail-qk1-f179.google.com with SMTP id g185so2547754qke.7; Mon, 04 May 2020 04:27:48 -0700 (PDT) X-Gm-Message-State: AGi0PuaUC+2HrxCUgN2IesRCGbfrHx8QPc4184NIyVwewWTUYmjSf+v1 8chruImgNXFDnUqPoskjcIESomSEWbR6fcwOA0k= X-Google-Smtp-Source: APiQypIIHoujLODItegRRgCsMaNglRK7LNUpimxq01cun2hB/w8fYeIm4nZCEGen6hYmmyMPRHB0gBdjFi2URrtAcZQ= X-Received: by 2002:a37:a492:: with SMTP id n140mr16289220qke.352.1588591667069; Mon, 04 May 2020 04:27:47 -0700 (PDT) MIME-Version: 1.0 References: <20200331093241.3728-1-tesheng@andestech.com> <20200408035118.GA1451@andestech.com> <20200414151748.GA5624@afzalpc> <20200415135407.GA6553@afzalpc> <20200503145017.GA5074@afzalpc> <20200504091018.GA24897@afzalpc> In-Reply-To: <20200504091018.GA24897@afzalpc> From: Arnd Bergmann Date: Mon, 4 May 2020 13:27:31 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] Highmem support for 32-bit RISC-V To: afzal mohammed X-Provags-ID: V03:K1:/i9t9qRKXOiKxyqXA6m/MK1Dt9wZmarX1euFn6iZiLiRMY1dmMs 5gRsCO2AVEnZiWpuU85IphtVlTrWoTUYyxfUnfSgMVc8Td7fDHIYdZVPsFFZjQqapv4d8yj u8l0CqQOUU6BuOJLp7bIcmy9EHMkO3iTxKTA8uK0z3044eT4hK37756rS/Z37GNASNLzx/V ow/SqdlHxJYCk0aMz9Vrw== X-UI-Out-Filterresults: notjunk:1;V03:K0:uoER3ETRvKQ=:szTyIVw5GpnxpP1S+y/L7J PJzUI53uNk2B+Ml8oMXHdOzudq/Lokn2OEuepcxoBiVh//xtctDrNZCsm1Ux90HoZRXaqESHe kO8UQiG0Wz8QKBknpMVrJt+5MYdMckT1gQUcZlvA88L2SkeIMyslH/Z17aBujaj4eYfvZ5Hma KfFww/qukA9Mfl/DEHdXt7iogVeAoRwVSrCVjgt0bMgqOlp2nF9Har1qxdFZ4pTikFpWeea5B IEoz7K/TWfwQ/rjuSBxQzmS/Cc/V8445Ewx01MDH2DfPSv83ideW7QLALmuJ2SWSsHNX4PWgI Ma8uM9PG3arKw5427wrcqz+Ja8U0fSPz9uz1ZJD1+yCJB2EwNQBaqLDxxjf8DlyhFHoAQFHye zf3e6plf9qGr13yZoyOeBovfZxhdLMS2tkIBaMFbx7lWcwURxtPeFMJ/5LDWURwy2xLRbsBSV N7RgVfG6J1xx3xzJwuTA4l+p/LJBGJw6RU83PDjjnUvI/yg+NDLKIKEcXPrD1topzQzTqPIwP R29ilskpHNMqNNuzMVh/Mf3/CtFuXunTLBbPegr74v/AUGeaVabWqorsUvfRZGVIF/fgjTM6T KqlvoNZkLu/TbvA/jLpBOd8p/FgE/imKK3RnXvnzm/Mtm5Ke6ENbnaQDGwuPP+s0BCzCP8Oqt 609DiBLZLCbUesdK7RXHLiH+Qf77bRZEBFRbX41sGJllwJ1uyi1qr3T5kB9jUM46ZcKrpcI6O BY+izBPW6T681wKE1py+HOxnnw/xmt0eO5klV2NYLhg+vjFANlju/oq3oVYfj3SzgTy/Onl65 GvU1d02swley3SKbR9x1IJZxojcFiJKmfk/j7DTzEny7TS9mTw= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200504_042751_597832_F6AE1FE9 X-CRM114-Status: GOOD ( 22.17 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: zong.li@sifive.com, Alan Kao , atish.patra@wdc.com, Albert Ou , Gary Guo , linux-riscv@lists.infradead.org, Steven Price , alex@ghiti.fr, Russell King , Mike Rapoport , Borislav Petkov , Eric Lin , Greentime Hu , Paul Walmsley , Thomas Gleixner , Linux ARM , David Abdurachmanov , Anup Patel , "linux-kernel@vger.kernel.org" , yash.shah@sifive.com, Palmer Dabbelt , Andrew Morton , Logan Gunthorpe Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, May 4, 2020 at 11:10 AM afzal mohammed wrote: > > [ +linux-arm-kernel > > Context: This is regarding VMSPLIT_4G_4G support for 32-bit ARM as a > possible replacement to highmem. For that, initially, it is being > attempted to move static kernel mapping from lowmem to vmalloc space. > > in next reply, i will remove everyone/list !ARM related ] > > Hi, > > On Sun, May 03, 2020 at 10:20:39PM +0200, Arnd Bergmann wrote: > > > Which SoC platform are you running this on? Just making > > sure that this won't conflict with static mappings later. > > Versatile Express V2P-CA15 on qemu, qemu options include --smp 2 & > 2GB memory. Ok > BTW, i could not convince myself why, except for DEBUG_LL, static io > mappings are used. I don't think vexpress uses it, but others have some 'struct map_desc' instances mostly for historic reasons, e.g. to map some registers that are needed at very early boot time, or from assembler files. > > One problem I see immediately in arm_memblock_init() > > Earlier it went past arm_memblock_init(), issue was clearing the page > tables from VMALLOC_START in devicemaps_init() thr' paging_init(), > which was like cutting the sitting branch of the tree. > > Now it is crashing at debug_ll_io_init() of devicemap_init(), and > printascii/earlycon was & is being used to debug :). Things are going > wrong when it tries to create mapping for debug_ll. It looks like a > conflict with static mapping, which you mentioned above, at the same > time i am not seeing kernel static mapping in the same virtual > address, need to dig deeper. > > Also tried removing DEBUG_LL, there is a deafening silence in the > console ;) I don't think there is any other mapping that would conflict with the DEBUG_LL one, but you may be in a hole where the existing one is not mapped. IIRC it first gets mapped in __create_page_tables() in arch/arm/kernel/head.S, and later in debug_ll_io_init(), but if the old page tables were just discarded, it won't work for a bit. Using gdb to step through the code in qemu is often more reliable than printing to the console, at least until you get to the point when you have registered the real console. > __virt_to_phys_nodebug() which does the actual work on __pa() invocation > has been modifed to handle that case (ideas lifted from ARM64's > implementation), though currently it is a hack as below (and applicable > only for ARM_PATCH_PHYS_VIRT disabled case), other hacks being > VMALLOC_OFFSET set to 0 and adjusting vmalloc size. > > static inline phys_addr_t __virt_to_phys_nodebug(unsigned long x) > { > phys_addr_t __x = (phys_addr_t)x; > > if (__x >= 0xf0000000) > return __x - KIMAGE_OFFSET + PHYS_OFFSET; > else > return __x - PAGE_OFFSET + PHYS_OFFSET; > } Ok, makes sense. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel