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=-5.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 2F8FFC47082 for ; Tue, 8 Jun 2021 17:39:48 +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 F0EB06128E for ; Tue, 8 Jun 2021 17:39:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F0EB06128E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=jb8e+iJTsZ3SRiOynmFFsekL6FENdTLAm+HjEvynGeo=; b=bQgUqhpn7v2Qj8 VZfUn58KikMkydWScE94g9zsimI6AZ0/3PrQ+WwMH1rOvzqiuFCGToGArNz1m2UtuNNC9SaOv+VT3 i8vzsFXLxY/vUi2ZLvZx+lnbnzyrxXqiWylVlNXihcx8PYJwxLS7AcuAoE1Hka7yu68JlvBxBoXJF YlYadNwSWxiAWXkKIYRbQ1YaL7ky6DTcANk8A/lU5XI6Pi2SavYU9vevypNtsC92mREvEsv7Y5I9V IiKiF/0sq6ZdThVNBfnMS2iMwc8cF3oS2kzXguaWc6t2YTJ7ok91WAe0IU2ryuOhV/xNRSw/0fhuQ 7VUmxYNzykgPqFuNq9JQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lqfg7-009lWu-Tt; Tue, 08 Jun 2021 17:38:16 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lqfg4-009lWU-Ng for linux-arm-kernel@lists.infradead.org; Tue, 08 Jun 2021 17:38:14 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id B9B936128E; Tue, 8 Jun 2021 17:38:09 +0000 (UTC) Date: Tue, 8 Jun 2021 18:38:07 +0100 From: Catalin Marinas To: Pingfan Liu Cc: Ard Biesheuvel , Linux ARM , Will Deacon , Marc Zyngier , Kristina Martsenko , James Morse , Steven Price , Jonathan Cameron , Pavel Tatashin , Anshuman Khandual , Atish Patra , Mike Rapoport , Logan Gunthorpe , Mark Brown Subject: Re: [PATCHv3 0/5] use __create_pgd_mapping() to implement idmap and unify codes Message-ID: <20210608173806.GA10662@arm.com> References: <20210531084540.78546-1-kernelfans@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210608_103812_825186_0F3587F8 X-CRM114-Status: GOOD ( 31.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 01, 2021 at 05:25:49PM +0800, Pingfan Liu wrote: > On Tue, Jun 1, 2021 at 3:50 AM Ard Biesheuvel wrote: > > On Mon, 31 May 2021 at 10:46, Pingfan Liu wrote: > > > v2 -> v3: > > > -1. leave out the part of redefinition the CONFIG_PGTABLE_LEVEL, > > > concentrate on sharing __create_pgd_mapping() in head.S as the first > > > step. > > > -2. make IDMAP_PGTABLE_LEVELS use the max value ([3/5]) > > > > > > rfc -> v2: > > > more debug and test > > > > > > *** Goal of this series *** > > > > > > __create_pgd_mapping() sets up the pgtable for mapping __va(paddr) -> > > > paddr under the MMU-on situation. Since pgtable upper level holds the > > > paddr of the lower level, with a slight adaptation, > > > __create_pgd_mapping() can also set up the mapping under the MMU-off > > > situation. ([4/5]) > > > > > > After that, both idmap_pg_dir and init_pg_dir can be created by > > > __create_pgd_mapping(). And the counterpart asm code can be simplified. > > > > I understand the desire to simplify the page table construction code > > in head.S, but up until now, we have been very careful to avoid > > calling into C code with the MMU off. There are simply too many > > assumptions in the compiler about the context the generated code will > > execute in: one example is unaligned access, which must be disabled > > for source files that may be called with the MMU off, as otherwise, > > the compiler is permitted to emit loads and stores that are not > > allowed on device memory (which is the default memory type used for > > all memory with the MMU off) > > You are right. These C routines happen to use "unsigned long", which > can exclude this unaligned case. > To make an guarantee, is "-mno-unaligned-access" good enough? > > Besides unaligned-access, any further risk originating from compiler > assumption? (I think that the common optimization: reordering, > merging, reloading on this "device" memory has no bad effect) There's also instrumentation that needs disabling (kasan, ubsan, kcov, gcov). You can look at arch/arm64/kvm/hyp/nvhe/Makefile for various flags added or filtered out, though the KVM hyp code runs with the MMU on. I'm not sure what other flags are needed to guarantee the generated code can run with the MMU off but we can always ask the toolchain folk. However, I'm still not convinced about sharing __create_pgd_mapping() with the early head.S code. A better option would be a separate, stand-alone file where we have more control on what gets called or accessed (of course, if there's any value in going this route). > > Do you have a killer use case for this feature? Or is it just a nice cleanup? > > Yes, in the omitted part in v2, I had planned to provide an unified > page table manipulation routine, and provide an create_idmap() API. So > there can be an handy interface to create a whole RAM addressable > idmapX where needed. Where would this be needed? -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel