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.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,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 4429DC433E7 for ; Tue, 13 Oct 2020 16:53:06 +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 B99FF252EA for ; Tue, 13 Oct 2020 16:53:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KcFmOm0y"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=armh.onmicrosoft.com header.i=@armh.onmicrosoft.com header.b="ZxfRoYmp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B99FF252EA 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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Content-ID:In-Reply-To:References: Message-ID:Date:Subject:To:From:Reply-To:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=J+ftcDXD4GLh4wpil3KIlG1WJB0O+Z0ix4zbiT7j2FU=; b=KcFmOm0yWq1ohws7uuVsTFGnN 0n9KpfmKB8QJ9qj4mn9kka6pc/RZRobFZ1CtuiSfeTeMZGhIlK4fCfr9AJetP/hxhJ3xGOl7qHeEq btifPtZ3hLSJ/1iMnVD7AK0Pvyaw1EPmISjcrpHzYev5sEAAzD2Y/nHhZYWdZP3+UvjnUsTS9/0Jp VsJTBWek8WXR2/Y5s5esm/rQfMjQ496AMHs2D1Au15wEpIpy22Z7YdP2LdQBtq18OP2uaVspJhtd4 1wSpmMj3g+HPcv2zq9g85Qb3mWQCwCAGVUMvzkp8szHOJNtTfMGWdZun4WZo+GG1egRrjvjN026CJ sYP84NefA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSNWb-0006wK-N9; Tue, 13 Oct 2020 16:51:45 +0000 Received: from mail-eopbgr60060.outbound.protection.outlook.com ([40.107.6.60] helo=EUR04-DB3-obe.outbound.protection.outlook.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSNWZ-0006vX-7V for linux-arm-kernel@lists.infradead.org; Tue, 13 Oct 2020 16:51:44 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qp7npZuPcPgnJADRHk8U/EjblNImYw5ssSiKMkWJHgIdSUUcZ9P1QY1J7BbGaliUW9X8lqhDukb3F1QG38e32nfGtjvpQZ71lWjA58hfK+WVBh+TQUkl+xXUYul8IxaHN6jjjS1xYwhBvmOD3iHn/Tpt5LaXI2lhEyYN7ebneDrdLjxZpBomkOyWCiX99SvCNL286xgvwXl87yC2AkALOp9bQ47q+WrgHyDDugCXJy9g7x9cIsbOSS3p55LbGgdosBv07DukK7YNapGY7kWp9ZxtAbe6wZfbxBaly8V0dxYW1xK31e7l+Ux32NA+FSQRmULxTL6zHjcqQOuCWAwsPQ== 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=MVN2bqvOdZw+7VEP50sOSAqhSMCmPvxUFEEFVFFPOSI=; b=en2uKvfu01bF8yHKHq+ANRj3H+Dpif7vQdZJynJr2xRr4wt7w3fpeYchdUZlEEiz9kTpYVZgdoU/G6e8L42vSAhwJlDDeKXv0f08HoFZRzdziwN+wcbAznv+S6wv28U1Ekrqbk3l9RQUnjhCoUDQu63JJmzyPQdPMqkgoVCLd/fJhOYSlBGtG5AhmNaDnQcA9K4I1jow6bWpDD2wY4ZhScQdhUZyBtEiQiXyWEniELOBnfbMiCsXouppozbFnB8+LLzvXm17D1AS/P+jMU5VjRFfoZ2QGzVWbczCmNcQcdu7I/KqrzE3lPzRVje0t9FaHCDnFwqOzwp42QoRjz7zzw== 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=MVN2bqvOdZw+7VEP50sOSAqhSMCmPvxUFEEFVFFPOSI=; b=ZxfRoYmprr4FZFOWHJNRp20Pj6AsYTpIc44twYA730At6wR4DLdLWWx8sDmke8FOE1L7esBZPppBEoHcKRKDHo31fpVP2+ORM0pfbvneWhyRWaDoPuZ5cZIsL6fYi41wSvlgN6PL2/Xfg/HzMvJAh+c0E0TpVRsxTytEvk8RYlE= Received: from DB8PR08MB4986.eurprd08.prod.outlook.com (2603:10a6:10:e0::18) by DBBPR08MB6171.eurprd08.prod.outlook.com (2603:10a6:10:20f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.20; Tue, 13 Oct 2020 16:51:39 +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 16:51:39 +0000 From: Steve Capper To: Ard Biesheuvel , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v2 2/4] arm64: mm: extend linear region for 52-bit VA configurations Thread-Topic: [PATCH v2 2/4] arm64: mm: extend linear region for 52-bit VA configurations Thread-Index: AQHWnYjcg03wak7aO0+EibAj6XFb3KmVzKqA Date: Tue, 13 Oct 2020 16:51:39 +0000 Message-ID: <68c0ac2b-e622-ee29-138b-1415cb80becb@arm.com> References: <20201008153602.9467-1-ardb@kernel.org> <20201008153602.9467-3-ardb@kernel.org> In-Reply-To: <20201008153602.9467-3-ardb@kernel.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 x-ms-exchange-imapappendstamp: DB8PR08MB4986.eurprd08.prod.outlook.com (15.20.3455.030) x-account-key: account4 x-mozilla-draft-info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0; attachmentreminder=0; deliveryformat=4 x-identity-key: id2 fcc: imap://steve.capper%40arm.com@outlook.office365.com/Sent authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.20.144.136] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: db39e849-5b90-4782-04a2-08d86f984153 x-ms-traffictypediagnostic: DBBPR08MB6171: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:1850; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ij1jaqYmh2rnKFbTdm1Z5GAobsp53A01CPSbClLvFrg6TskIVsxm/cBp+zW/nesEi8gD6DvWa62sJsitliPtDm91RZwiY05+BE3edbR/QgXM8a/R8+NptqW7UBgWI5XivPKUOnenZMLWvF9ONRtpzQkKhaaBTGoPpMYuG0b+WwHy89YfoUIq1BJUuNKoAYoeI6RMo/vvpZB14SsHIN7REPntfNr0h0A7bFX29qetDqsXJHblINC4dw72ofEDt+oIRCyGPk4WEsvTYV27u3S9vI1wc3OiqT7TcGkmnR6JC2jDQe/ex73FdLCp5PWR972PJbXSkOzgN2XSWiM88zo4uTLRXGTTmj1LXdS2TBgIptFWJF7/R6K0fkz6KDYzZ1Uw 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)(396003)(136003)(39860400002)(376002)(346002)(6486002)(6506007)(8676002)(76116006)(6512007)(53546011)(316002)(2616005)(26005)(31696002)(186003)(66476007)(64756008)(66556008)(66946007)(66446008)(2906002)(8936002)(31686004)(5660300002)(71200400001)(36756003)(4326008)(83380400001)(478600001)(110136005)(86362001)(54906003)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: gNeEC6Q81kLOKFbAoy/NWiIY8OnjHM4yfUwncwaIL/uHeGJZlbUmR9EkB3GeOZTX5HOO2PFL/28Dj68iaWBxyV8LOuOtNxhzXcPbMYx02PRNH6W1HjbacJcsVa/KNLL5r0Iwkjc30KIi0bV4G0S+ab453n6YdJY5JusC2NILZZnDKICRDd8oJQ/+mHRWJPFAANiBV9GPH3nPgKixNKUnNClgxiIw/N3nP7ayS56Tu7EvesbCb3+TmRQ+QdWPIYzLWw06lD+qhYPZ2jDczvA7Hyj609xE9UXqhQJHIDDYLnqcTJEEIPsjh6aKX0Dgr2oKtdkLjGFJudlGX9JMMq8keufO2SM3aMW7bHsCiY57N2gZ4oDRlUd4ifORhUBuOJyxPMGDvYi2UKqGIUExWVaRKGFgA1+9Vv6TyVDYUJPRls+hcWW0/LjyTmobhzs5eQX63+pq/isK9nihPrareS56hEl8+Ss9tvRWn7lXm1lK37nfGxzQkBVcziyaJssbBbweG8LZ4EpXMnR7dWD2vr6JrZv5KuwCLn77VaeTYIQ9PQ6gpYD8l+l7Cx44qldTDDSIMa0qhl3Wi2ZrzVTm6VUieqEPFC3G6ZhDkK2hU1FcndPayQWkKa4lO+pVKfu1qu0oY0UtJPS/yh9YUkOVDZzH3A== Content-ID: <9C275C0BA2DA6642ADD4230F836B1C00@arm.com> MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB8PR08MB4986.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: db39e849-5b90-4782-04a2-08d86f984153 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2020 16:51:39.3307 (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: xxUHnk44eR3fwg1u/6FPLO62mklecYO2kgoNbfCtBsmmwza3NRso/vm31RPUaHdraBtbQm9Pgp2hVdERT6+tNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6171 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201013_125143_275329_0EC7D6E8 X-CRM114-Status: GOOD ( 20.06 ) 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" , Anshuman Khandual 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 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? Cheers, -- Steve _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel