From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.2500.1678818593750982855 for ; Tue, 14 Mar 2023 11:29:53 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=j9AuS8Uh; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 048EB618B9 for ; Tue, 14 Mar 2023 18:29:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A40DC433A0 for ; Tue, 14 Mar 2023 18:29:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678818592; bh=BN2G/nEaQ/V0X2eTBbu+zYKzJ8/YbyrCq8J7KcIDo6A=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=j9AuS8UhMkOf3nNIcE19AWmbsjsuwnE5ToH7pvO121OB3j3Ig/TLgG8WQ/38ppk/H amxRToOS+KH7gJxzSrS+QSK8zI3+EmPXenV09RxpCkOLokN+GbYGAd00O1mNjJi78g 0Q8YuXx5KkHUgMHoZyVSTNVfvpEq7WWQ3c5ihGJ0syxvt+z6fbuB6i4P15OM7Iu4Or luiUyJg9isdIHBkTlIfDApmxsw8T39GmTLPSDhReT7UjGg862/yoxPcCAr6zkNbYzS RZUmElpe5a8EDgGkEcYmfRz3NKxRJqerRGZhX8eg0ZCQg5YN3HRvOnLIV6rLNmcHoV JS5blOy78MVSQ== Received: by mail-lj1-f180.google.com with SMTP id z5so16947751ljc.8 for ; Tue, 14 Mar 2023 11:29:52 -0700 (PDT) X-Gm-Message-State: AO0yUKU4ZFxVJRygZ5ySdja3H9322SkiKqlNhVNGObbkuvInujy2dhPm ktL50GpboJbg8rGatvJnpj6GLzYawxaxIj2A20E= X-Google-Smtp-Source: AK7set87OnVTk6b3UZdIcmkgGWAe4XKdyKavqWJ0z+CI2DKxP1s3N41uYxlKc53h2265k37U1hwEjJm7qlIjJVI6Z4M= X-Received: by 2002:a05:651c:333:b0:298:a8d6:9fad with SMTP id b19-20020a05651c033300b00298a8d69fadmr36021ljp.4.1678818590445; Tue, 14 Mar 2023 11:29:50 -0700 (PDT) MIME-Version: 1.0 References: <20230313171714.3866151-1-ardb@kernel.org> <20230313171714.3866151-9-ardb@kernel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 14 Mar 2023 19:29:39 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v5 08/38] ArmPkg/ArmMmuLib: Avoid splitting block entries if possible To: devel@edk2.groups.io, quic_llindhol@quicinc.com Cc: Michael Kinney , Liming Gao , Jiewen Yao , Michael Kubacki , Sean Brogan , Rebecca Cran , Sami Mujawar , Taylor Beebe Content-Type: text/plain; charset="UTF-8" On Tue, 14 Mar 2023 at 19:13, Leif Lindholm wrote: > > On Mon, Mar 13, 2023 at 18:16:44 +0100, Ard Biesheuvel wrote: > > Currently, the ARM MMU page table logic will break down any block entry > > that overlaps with the region being mapped, even if the block entry in > > question is using the same attributes as the new region. > > > > This means that creating a non-executable mapping inside a region that > > is already mapped non-executable at a coarser granularity may trigger a > > call to AllocatePages (), which may recurse back into the page table > > code to update the attributes on the newly allocated page tables. > > > > Let's avoid this, by preserving the block entry if it already covers the > > region being mapped with the correct attributes. > > So if a later mapping is made inside the same block with conflicting > attributes? That triggers the break down at that point and because the > existing mapping did not conflict, it'll all flush out? > Indeed. The case here is simply, e.g., mapping a single page XP that is already covered by a 2 MB XP block: without this patch, we break down that 2 MB block into page mappings that all have the same attributes. If the 4k page being remapped is being allocated for a page table, we may end up with unbounded recursion. If the attributes are actually different, the split still happens. But otherwise, the block mapping is retained.