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=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 75A48C48BCD for ; Wed, 9 Jun 2021 09:38:55 +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 482826124C for ; Wed, 9 Jun 2021 09:38:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 482826124C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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=+5lG8BLWcwWtcVtH0lcdCxcdQwrXiCtiAR98CprLStM=; b=XOObJ/0kVbE0v7 5slAMuOy3HazG5ZSDuJqDMZ6nY5KktECmR4KMgIs1R1/FJr3BeGJR2CfQQ6Yr4oVuRRgs6y/pDjrl BMm3X+AiRBvQk8K0166f/Fb0pVpe3oYDGxFbAbcSfPExD9e6uC5pOQFYRe+/mGva6YywoEVrV7ksN TyH+yAOgknlcGCI0Ny3ev9dCTuTU01vma4IZKz0LAOy2Vf31dg8j/YbmJwxb2Il8Na4m6mVf4E2H8 VfoPEQPpty0npxkKPI7aD3o48t3oQoHXUxl9yJHtDWsc8rVDbsF0DC6ZNZhIucbO/k7ErJ5znyh2r YGtxNh/fPmIHX6RRy2zQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lqucp-00Cifw-Sf; Wed, 09 Jun 2021 09:35:52 +0000 Received: from mail-pg1-f182.google.com ([209.85.215.182]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lquUD-00CfMd-9x for linux-arm-kernel@lists.infradead.org; Wed, 09 Jun 2021 09:26:59 +0000 Received: by mail-pg1-f182.google.com with SMTP id i34so12514689pgl.9 for ; Wed, 09 Jun 2021 02:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=GY52bgM+4GBPHnXI1aU3CEtPuRYVFRnjdRrHqcJKDYk=; b=GoANw50nkTJgCVeRTk3QNQ8ljywBtb3UtgDSJzRLN+lMJQQa36wiUjZMdjRXjDWgZU vgWJRcH1UHcTpRvdlk+2AXK2LcaevTzue9bYNHIILj/ukiLf1pprJTA8+u/39y5x7O+9 +f+68kpekDrOK9edbQdFuYfJaWIj+g9GgyO7SAs95MNNxmvY4PemBzD3t/rlP2wyXwfK Zglh7+KVGLPCpGwX2CRkAHZDCURIjyefyDm5ybP58rmBA+2Er7EX2sQrkodTQbQ0StHu eXuQuq6P4q6zO22ZARVEZYrorfTrow/VLn5NuRCCGHMNVM0lWUtfpSorSLQOOnyHoaG1 3lJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=GY52bgM+4GBPHnXI1aU3CEtPuRYVFRnjdRrHqcJKDYk=; b=HCuJnM8kl/8uEsNizSj+StqD8gimMzx2OfZC4oHi34AzApe2xvMprMl9d8CjsMSlkW UvqBrn6s6bPAPpTe7zpnYh2xIXHvTER3pa4xkX8BMxei4u9rkqQbUtN3bJ1stxXz/fq+ PRx0C5mTu3/xqP3fIVDHeRHu9Fq5KQ4w55eGwk4NAZgvoVjjd0PIj7bI3Hy2f5ZClH7C E3g6loiLtr0wcdSh1GqeYI8Xqk5HSz+52SQB25vZaPklShLa5UT7E80mPDKMr6NrCuZ6 w51WMHm34sp+vU8IvjGDZpGV17r1jD5Y49Bz88Rptr5ueXYUezswRPjuDc5poKa64Ams 7SeQ== X-Gm-Message-State: AOAM533KnAlTrei9YaGLJKaz+PDeyf0a5aRsICo1vfxO10wq419mcpuP 4lW2OcI0/vOwYb9LG1by2A== X-Google-Smtp-Source: ABdhPJwT5ilYGZ4TL6kc5G2Yrd/06Y0+4o8t3cm8gvPs6eVEb8f4wQEgiFhF4tiJwq9n+zuA4fncbw== X-Received: by 2002:a05:6a00:23cf:b029:2d5:302e:dc77 with SMTP id g15-20020a056a0023cfb02902d5302edc77mr4336092pfc.63.1623230754588; Wed, 09 Jun 2021 02:25:54 -0700 (PDT) Received: from x1pad ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id j4sm4555208pjv.7.2021.06.09.02.25.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Jun 2021 02:25:54 -0700 (PDT) Date: Wed, 9 Jun 2021 17:25:46 +0800 From: Pingfan Liu To: Catalin Marinas 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: <20210609092546.GA30763@x1pad> References: <20210531084540.78546-1-kernelfans@gmail.com> <20210608173806.GA10662@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210608173806.GA10662@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210609_022657_443389_D2421866 X-CRM114-Status: GOOD ( 43.24 ) 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 08, 2021 at 06:38:07PM +0100, Catalin Marinas wrote: > 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? > > Unaligned-access is the main challedge, and the unaligned-access should be caused from the programer. Compiler has enforced different default alignment, including global and local(stack) variable, function alignment. Otherwise, the atomity can not be assumped on some base data type. But some code may violate the alignment, which compiler has no method to prevent. As Documentation/core-api/unaligned-memory-access.rst 1. Casting variables to types of different lengths 2. Pointer arithmetic followed by access to at least 2 bytes of data So in order to prevent the unaligned-access, the involved codes should be checked carefully. > > 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) > These should be not issue. Since MMU-off present a more strict memory model than MMU-on. So if a code can run on a more relaxed one, it can also run on the strict one. > 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. > Thanks for pointing out these issues. I will check. > 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? > It was planned for Pavel's series: [PATCH v13 00/18] arm64: MMU enabled kexec relocation, where Pavel uses linear mapping to copy the data. But that way should involve copy of "EL2 vectors" to tackle the transition to EL2. On the other hand, if using a global addressable idmap, the logic of transition to EL2 keeps untouched, and just enable MMU in SYM_CODE_START(arm64_relocate_new_kernel) The other call site is in trans_pgd_idmap_page() Thanks, Pingfan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel