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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 CF050C4338F for ; Sat, 21 Aug 2021 08:17:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A9237611EF for ; Sat, 21 Aug 2021 08:17:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233037AbhHUIRy (ORCPT ); Sat, 21 Aug 2021 04:17:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48662 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232077AbhHUIRs (ORCPT ); Sat, 21 Aug 2021 04:17:48 -0400 Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C641C061575 for ; Sat, 21 Aug 2021 01:17:09 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id i7so15295614iow.1 for ; Sat, 21 Aug 2021 01:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Cs7sjRSMZhIH3zoMGmleQcDUMRVb41/98HuNbOapDA=; b=gXHdJwj/2CEW4yAdYMroDCsdSXlE/A0qgoBOB7UQgpXFBoIwr0VEfjLZQtXFJdlh1o k1u9YeJugeKce3G485+mtom5IHUpWPqOFOBXXBr97EU7j73F7wNIekle3KHJQ5X+ze8E S2xMaGvDtdEI5Z3Gy5dLBUchI71XAbYENjBj2zAZqFU7VnPeHpPAqcJWCCWPv1PjnnTj llwZlSU033wvkd9Y/IKbLyu34fGoLj6oAELUIoR5bFJNSNUUtmVf6w4oQHzUwXUsUeSg gw8cPzPzhQ0Nee1kWDO+c8cOMCVFa2sipk61mwr0+O0QXACzVHMz8axoEzms7M7X4mFq wP9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Cs7sjRSMZhIH3zoMGmleQcDUMRVb41/98HuNbOapDA=; b=srfiH5bRCibh97phfKlJAhcb1LsIg+z6e7xaRkjO2Y7lmg+yFmPh8BNXQE//c4p1GW Y2uLperpIZzE8xlPRThpr/XSi+Ajnv3CS3LNjQUCLX5Z+3aM4xM6LLTtdsgQk7j4GaWi 1gKwwmkYu2hSOkhojOLacXpXK4CKlLU+ETFh5pStrJj9usPthHHG8OqaxqU+LfOUlra3 Ktwkeu9hHATN6ldLYL3+Y6GZssySQRviDTPqHnMDPIku36Mpn40y8IsWTVikhbWB6yz+ lgtZx/Xg4LMNs6xSdIOTCtV+d/0JlUpUqbLz/20iKwSMpn0nyZNIDom6OwhbsPph/Tph 0LHg== X-Gm-Message-State: AOAM5300o4QRdrEZiDKzoZwosUGtijqnGo2VjwUcqZYJGyuGLdj8BVPo 3DRxJ6/2Q6S/zSKN1M5MxvsBNGVP9frrAD0t5TQ= X-Google-Smtp-Source: ABdhPJxXgnjCoIW95PhkxVQnAtbdbp7DZne7KQuXCEI9RC7iWhQnlH1SFW7NpKWnOlyszO1U5Lt6c9MaQFif460En6Y= X-Received: by 2002:a5d:97d0:: with SMTP id k16mr19504802ios.38.1629533828547; Sat, 21 Aug 2021 01:17:08 -0700 (PDT) MIME-Version: 1.0 References: <20210706041820.1536502-1-chenhuacai@loongson.cn> <20210706041820.1536502-5-chenhuacai@loongson.cn> In-Reply-To: From: Huacai Chen Date: Sat, 21 Aug 2021 16:16:56 +0800 Message-ID: Subject: Re: [PATCH 04/19] LoongArch: Add common headers To: Arnd Bergmann Cc: Huacai Chen , Andy Lutomirski , Thomas Gleixner , Peter Zijlstra , Andrew Morton , David Airlie , Linus Torvalds , linux-arch , Xuefeng Li , Jiaxun Yang Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org Hi, Arnd, On Fri, Aug 20, 2021 at 3:55 PM Arnd Bergmann wrote: > > On Fri, Aug 20, 2021 at 6:00 AM Huacai Chen wrote: > > On Wed, Aug 18, 2021 at 5:38 PM Arnd Bergmann wrote: > > > > > How common are Loongarch64 CPUs that limit the virtual address space > > > > > to 40 bits instead of the full 48 bits? What is the purpose of limiting the > > > > > CPU this way? > > > > We have some low-end 64bits CPU whose VA is 40bits, this can reduce > > > > the internal address bus width, so save some hardware cost and > > > > complexity. > > > > > > Ok. So I could understand making CONFIG_VA_BITS_40 hardcode the > > > VA size at compile time, but if you always support the fallback to any > > > size at runtime, just allow using the high addresses. > > Define a larger VA_BITS and fallback to a smaller one (TASKSIZE64) if > > hardware doesn't support it? If so, there will be a problem: we should > > define a 4-level page table, but the fallback only needs a 2-level or > > 3-level page table. > > The number of levels is usually hardcoded based on the configuration, > though I think at least x86 and s390 have code to do this dynamically, > either depending on the CPU capability, or the largest address used > in a task. > > The easiest example to replicate would be arch/arm64, which lets you > pick the page size first, and then offers different VA_BITS options that > depend on this page size. > > Another method is to have a single 'choice' statement in Kconfig that > simply enumerates all the sensible options, such as > > 4K-3level (39 bits) > 4K-4level (48 bits) > 4K-5level (56 bits) > 16K-2level (36 bits) > 16K-3level (47 bits) > 64K-2level (42 bits) > 64K-3level (55 bits) > > You might prefer to offer the order-1 PGD versions of these to get > to 40/48/56 bits instead of 39/47/55, or just offer both alternatives. Use combination option is a good idea, thanks. Huacai > > Arnd