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=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,MSGID_FROM_MTA_HEADER,NICE_REPLY_A,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 3310FC433E7 for ; Tue, 13 Oct 2020 17:40:31 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 7C32F25372 for ; Tue, 13 Oct 2020 17:40:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="yfRVbhgo"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=armh.onmicrosoft.com header.i=@armh.onmicrosoft.com header.b="tYImtQ0j" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7C32F25372 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=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=y1FBzgD5uUpyGHZbH/t0QuHjE69sqkbjLfOcBhyPOHk=; b=yfRVbhgoxuKhj4CF5c/0YN7JD zT1l+LM+CtmcrtKzKMIHyBOtKlMawgfTyk0tbm42purpjKUJcc8i8QMPaKkJFqa4p4mm3K4uId+eN qZNHeMsh/rvhfG3gFViyU2JQTDOjLGUq8SJZEILZS1c+HQ3KJUFXFVSowx8SJIIwCnQ58qiNAyyeW 18z6ZHzq3C04DohJg7bDllFTqR9DHSwy1WNoMGS9SD2PBJNB9/GWJJqmPAleblDVot9BVKHlON+YO Uk4JqouwixFKWWUL8bTuqp/DscSrMM/ZgeFqNv61MC9YzYWPRrWKv0ri7EnNM4AzDXL7FWihn3j2f Wtd3JgksA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSOGI-0005R4-Dl; Tue, 13 Oct 2020 17:38:58 +0000 Received: from mail-eopbgr20078.outbound.protection.outlook.com ([40.107.2.78] helo=EUR02-VE1-obe.outbound.protection.outlook.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSOGE-0005QN-Q2 for linux-arm-kernel@lists.infradead.org; Tue, 13 Oct 2020 17:38:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dcRMw9i2ouT3pK8zgPMf7jE0ZKqKQw1W90V6MGzEASSdg1whiYYVxbtAWiO03SznUStliS285diYCtiCxk1vJx2ZpenozURjycfGV8LGHi8H/TiEe/k68OwECiwJ83jBc8cbVLl/wN76FngO8pCVx/+qntDMOL7gtAFOluJ4uEhxjLBS4Fa5RZY0pmJ0KnbEU7V6i2ABf+JE5kBSki5/ASt1xqzXnN6sswNInOmRJlwI/ZP6f+cDSSGImRK+Zt7m1K+LnfcNlvQX5wcHRaRQEgyqJxgtPgpad1YIo9T8ILlbwVW/Ipe2sewanDw22RWLUkIH2JhcQ8wjlFbAsaGcSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8AfqB2oPtgXHTfu9ldMn3fV+uVsDoSIM0+WrnIa3diA=; b=mOuPCuP78S3wW3TdfY6llkfUFjMMQV7ovzxrnvsb8QQPMovAz/Yr/q5l91As381yn9ZI0a8jnEQ2BohSnDMVmgZSXB90+93eu/EXBkhZYaVu12gmgTiwtvAEK3hJs+w6oChIrz2pBTTZXdAMdsk0VF2+BJRvpaqQ3Gos95elnLgn/F3KhIJZEN2d77ZzZQ0RX7bkAETJYhFGbigDGkiNsWpTd4PMQtS+NucEi57gN/oVVZhhJK9g0X+Czx4bSsEG55kw9y0CbgmrJTUADdFAMkkipnOxS2s3QHIoUg0ev3ucIOpRlGS6ygGpsi8ExTYylThsn9kkTabe0f45ylFB/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8AfqB2oPtgXHTfu9ldMn3fV+uVsDoSIM0+WrnIa3diA=; b=tYImtQ0j0ZN3yebdRNU9mBEsfRDJCx945VmJ7BVQHQzH4pkrxk4XExKoJWxJBY31v3rgP3sdz2F1TynoZWRvGndSQadHwQ7bW34PArcgcv4nqh5088K+PSxta1ANZTBJI0Fs4G1V+/UB/Yq8wU5Zr9SGyWGcgjrw/+yf1hP9gOI= Authentication-Results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=arm.com; Received: from DB8PR08MB4986.eurprd08.prod.outlook.com (2603:10a6:10:e0::18) by DB6PR0801MB1847.eurprd08.prod.outlook.com (2603:10a6:4:3c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.26; Tue, 13 Oct 2020 17:38:51 +0000 Received: from DB8PR08MB4986.eurprd08.prod.outlook.com ([fe80::c5d:cff0:e468:4e2c]) by DB8PR08MB4986.eurprd08.prod.outlook.com ([fe80::c5d:cff0:e468:4e2c%3]) with mapi id 15.20.3455.030; Tue, 13 Oct 2020 17:38:50 +0000 Subject: Re: [PATCH v2 2/4] arm64: mm: extend linear region for 52-bit VA configurations To: Ard Biesheuvel References: <20201008153602.9467-1-ardb@kernel.org> <20201008153602.9467-3-ardb@kernel.org> <68c0ac2b-e622-ee29-138b-1415cb80becb@arm.com> From: Steve Capper Message-ID: Date: Tue, 13 Oct 2020 18:38:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 In-Reply-To: Content-Language: en-GB X-Originating-IP: [82.20.144.136] X-ClientProxiedBy: LO2P123CA0018.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::30) To DB8PR08MB4986.eurprd08.prod.outlook.com (2603:10a6:10:e0::18) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.43] (82.20.144.136) by LO2P123CA0018.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23 via Frontend Transport; Tue, 13 Oct 2020 17:38:49 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1fa75ac6-fe63-4198-4610-08d86f9ed893 X-MS-TrafficTypeDiagnostic: DB6PR0801MB1847: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +EpBbCg/P6uJijpjTsfLbr3pDQ7VBev/iLP7wlZk13yuq/sRsGvV+WAYxNNZy1++SmYHfPsNMSxH4THRVdoWQV0NRuHRZGbgbNgE3Oc4oIN6+0rNPcuSr+JoXObCLYjkFFN1a9QAbwmH1EXzD62fikM7nALIxA+/jLMuxQqnbVussDC9XmHs2vSv8zVfvURWH7j6BJRV9MgfClIp9jUx1TXTg27BG0aSM/Gm4IflL23qqzXjPcDU+2j3DwipTw7Kdg2J+HAJvhRv3ChaINs5rr9n0G429Ivnr6V/P6AOOkzW2DlTzvLjSuB6QcYTrUpc4WWbB2KJuVcCZcPhaB8hJz7SmhNRpSfVQWHPmNVrXH8fs4+K2Q4tiUmmH+V6RyY1 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8PR08MB4986.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(376002)(136003)(396003)(39860400002)(5660300002)(31696002)(86362001)(8936002)(8676002)(83380400001)(2906002)(66476007)(66556008)(316002)(44832011)(31686004)(4326008)(186003)(6916009)(16576012)(26005)(956004)(2616005)(6486002)(36756003)(478600001)(16526019)(54906003)(66946007)(53546011)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: Ag6gm6yPAn4JSZhdrxe7T8ihO8ZvtZO3BzaSuLzGwEhpInJoSuSn6SwyrMihWSVLoxJfxSE3JV998pjk5VSWRBFg2dIVSnPOEGc6C4U2ZyMrSkv7QGj/omPFoY84Ic9sWOstAiJtWFz7JGJ4Kr5RCTK43OcGPPlbZa6f+2p1aINDxihTUyMSHJUp5fVXX0fAn2yPB7nIk8SobPZmP9XkM7H3LJsjl8pB7J+hYzxSJ9bAptVSWKJf0rxIYbaYN6ro7k+HPPCCZD9CGUSZh3HOIOd0uUy7ELe69OtCZxDRg7K2n4Ut0U8UdHIatL7R7Z+nGuyDFCauhvzfWNJK4FH471i6jFUjfrT/bxxKS0hoPfLaxLjKFYcBE3UvYL7Mg6ew1jUPcNvomKkPeZrP4GLLH3ziRcSl2x/5hoOW1Z1yMJ+viukEc+dFir2CcOTJ95SlMjSA3qyUNfShhYVMS2Rd5j6jdapkGh9BRMMfge3Jl4EaOimLeOxUQaXifd4qSDu9YqxtOQyQEfZHrWJHEqinRICRk+mRUCom29wcYVhgWJBNTiIcJHB0N3JQd5DaZcyAofXkA3al/pHTOUNMh+nARF2YiECg0u7IIsdHqU7AG3MAvD+Z9HRnXgF8dwDfijwDhT1rT/rOE0KuwmIhPhprDA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1fa75ac6-fe63-4198-4610-08d86f9ed893 X-MS-Exchange-CrossTenant-AuthSource: DB8PR08MB4986.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2020 17:38:50.7278 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: In+LYCkSgiv8KHPF5J86ahkkRT4cJfgepw8j7m0bZz3VxE6FTdnXZUB1EWbDL5bZC6A1cc7hEcFdzgSNlEUP2g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1847 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201013_133854_861579_7281DF2D X-CRM114-Status: GOOD ( 24.83 ) 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: Catalin Marinas , nd , "will@kernel.org" , "linux-arm-kernel@lists.infradead.org" , Anshuman Khandual Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 13/10/2020 17:57, Ard Biesheuvel wrote: > On Tue, 13 Oct 2020 at 18:51, Steve Capper wrote: >> >> Hi Ard, >> >> One comment below... >> >> On 08/10/2020 16:36, Ard Biesheuvel wrote: >>> For historical reasons, the arm64 kernel VA space is configured as two >>> equally sized halves, i.e., on a 48-bit VA build, the VA space is split >>> into a 47-bit vmalloc region and a 47-bit linear region. >>> >>> When support for 52-bit virtual addressing was added, this equal split >>> was kept, resulting in a substantial waste of virtual address space in >>> the linear region: >>> >>> 48-bit VA 52-bit VA >>> 0xffff_ffff_ffff_ffff +-------------+ +-------------+ >>> | vmalloc | | vmalloc | >>> 0xffff_8000_0000_0000 +-------------+ _PAGE_END(48) +-------------+ >>> | linear | : : >>> 0xffff_0000_0000_0000 +-------------+ : : >>> : : : : >>> : : : : >>> : : : : >>> : : : currently : >>> : unusable : : : >>> : : : unused : >>> : by : : : >>> : : : : >>> : hardware : : : >>> : : : : >>> 0xfff8_0000_0000_0000 : : _PAGE_END(52) +-------------+ >>> : : | | >>> : : | | >>> : : | | >>> : : | | >>> : : | | >>> : unusable : | | >>> : : | linear | >>> : by : | | >>> : : | region | >>> : hardware : | | >>> : : | | >>> : : | | >>> : : | | >>> : : | | >>> : : | | >>> : : | | >>> 0xfff0_0000_0000_0000 +-------------+ PAGE_OFFSET +-------------+ >>> >>> As illustrated above, the 52-bit VA kernel uses 47 bits for the vmalloc >>> space (as before), to ensure that a single 64k granule kernel image can >>> support any 64k granule capable system, regardless of whether it supports >>> the 52-bit virtual addressing extension. However, due to the fact that >>> the VA space is still split in equal halves, the linear region is only >>> 2^51 bytes in size, wasting almost half of the 52-bit VA space. >>> >>> Let's fix this, by abandoning the equal split, and simply assigning all >>> VA space outside of the vmalloc region to the linear region. >>> >>> The KASAN shadow region is reconfigured so that it ends at the start of >>> the vmalloc region, and grows downwards. That way, the arrangement of >>> the vmalloc space (which contains kernel mappings, modules, BPF region, >>> the vmemmap array etc) is identical between non-KASAN and KASAN builds, >>> which aids debugging. >>> >>> Signed-off-by: Ard Biesheuvel >>> --- >>> Documentation/arm64/kasan-offsets.sh | 3 +-- >>> Documentation/arm64/memory.rst | 19 +++++++++---------- >>> arch/arm64/Kconfig | 20 ++++++++++---------- >>> arch/arm64/include/asm/memory.h | 12 +++++------- >>> arch/arm64/mm/init.c | 2 +- >>> 5 files changed, 26 insertions(+), 30 deletions(-) >>> >> >> [...] >> >>> diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst >>> index cf03b3290800..ee51eb66a578 100644 >>> --- a/Documentation/arm64/memory.rst >>> +++ b/Documentation/arm64/memory.rst >>> @@ -32,10 +32,10 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit):: >>> ----------------------------------------------------------------------- >>> 0000000000000000 0000ffffffffffff 256TB user >>> ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map >>> - ffff800000000000 ffff9fffffffffff 32TB kasan shadow region >>> - ffffa00000000000 ffffa00007ffffff 128MB bpf jit region >>> - ffffa00008000000 ffffa0000fffffff 128MB modules >>> - ffffa00010000000 fffffdffbffeffff ~93TB vmalloc >>> +[ ffff600000000000 ffff7fffffffffff ] 32TB [ kasan shadow region ] >> >> We have the KASAN shadow region intersecting with the kernel logical >> memory map now. Could this present a problem if both the KASAN and >> phys_to_virt paths land on the same VA? Or is that not possible? (Also >> what about smaller VA sizes?) >> >> If it is a problem, could carving out the appropriate memblocks (and >> warning the user) be a way forward? >> > > Hi Steve, > > This is currently taken into account in arm64_memblock_init(): > > const s64 linear_region_size = PAGE_END - _PAGE_OFFSET(vabits_actual); > > When CONFIG_KASAN=y, PAGE_END is #defined as > > (KASAN_SHADOW_END - (1UL << (vabits_actual - KASAN_SHADOW_SCALE_SHIFT))) > > and so the linear region ends where the KASAN shadow region starts. So > even if the static definitions overlap, the shared region will not be > used for mapping memory if it is needed for allocating shadow pages. > Ahhh, yes, thanks that will prevent the intersection from occurring. This looks good to me, feel free to add: Reviewed-by: Steve Capper Cheers, -- Steve _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel