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.6775.1678951194312594043 for ; Thu, 16 Mar 2023 00:19:54 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=rls9ZHl6; 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 BDA1961F35 for ; Thu, 16 Mar 2023 07:19:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 333CFC433A0 for ; Thu, 16 Mar 2023 07:19:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678951193; bh=G3tYnI5xiWV5bhSfKO8lw1vPOWHs0SNHBCg2YJKnoZ0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=rls9ZHl6FReFpE9g8bBm1c9seUKFkmH8fXHTrZpBsbc3ziV3f+6BHw00b1hUtPGYc +PylTCAqBA6seNlHWsIxgQ+rSRVoE/1H3zJcgKEZ72aZ5zWbSCAhwTPcUHMsIEMjAF EhTl2/2SjvHhThCv7XhhymTnfRiOST2CXoWd0u6x7fy2quNg3z+e2qPix77oXSi8xI PBzVFiyj/jwjdSu5BWIwbqpj1sGXUvGyRez8wyDnRMPLwbP5VrhjPBAy79wc9cQaNs b8tjc9s4t4oQk6TqBrd5Qd5eO4qU60rs+sL+UxGRywMjWAAUWIVjaGDrei4IehZfmL xzyRvAMsZi05g== Received: by mail-lj1-f171.google.com with SMTP id y14so645340ljq.4 for ; Thu, 16 Mar 2023 00:19:53 -0700 (PDT) X-Gm-Message-State: AO0yUKU/oszIHHx+JgFjo60qRIFz/K0X7lCu+UIV2p5mq0cX3ZPTjdun gW+o13Ma17kQt5ckNBzaAoVBTghOD7MPIPTJcJo= X-Google-Smtp-Source: AK7set81YNlZ3XmQk/HZ/88NIz5K1CSWAUoL/ZAmrgRrngjuKnmCRxhmgj38VH7pu3uIGtquG4SUqB72Ze60DHjRA38= X-Received: by 2002:a2e:720c:0:b0:298:afbd:5aef with SMTP id n12-20020a2e720c000000b00298afbd5aefmr1525974ljc.2.1678951191190; Thu, 16 Mar 2023 00:19:51 -0700 (PDT) MIME-Version: 1.0 References: <20230313171714.3866151-1-ardb@kernel.org> <20230313171714.3866151-12-ardb@kernel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Thu, 16 Mar 2023 08:19:39 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v5 11/38] ArmPkg/CpuDxe: Implement EFI memory attributes protocol 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 Wed, 15 Mar 2023 at 19:31, Leif Lindholm wrote: > > On Mon, Mar 13, 2023 at 18:16:47 +0100, Ard Biesheuvel wrote: > > Expose the protocol introduced in v2.10 that permits the caller to > > manage mapping permissions in the page tables. > > Nitpicks and a question: > > > Signed-off-by: Ard Biesheuvel > > --- > > ArmPkg/Drivers/CpuDxe/CpuDxe.c | 2 + > > ArmPkg/Drivers/CpuDxe/CpuDxe.h | 3 + > > ArmPkg/Drivers/CpuDxe/CpuDxe.inf | 2 + > > ArmPkg/Drivers/CpuDxe/MemoryAttribute.c | 271 ++++++++++++++++++++ > > 4 files changed, 278 insertions(+) > > > > diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.c b/ArmPkg/Drivers/CpuDxe/CpuDxe.c > > index e6742f0a25fc..d04958e79e52 100644 > > --- a/ArmPkg/Drivers/CpuDxe/CpuDxe.c > > +++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.c > > @@ -244,6 +244,8 @@ CpuDxeInitialize ( > > &mCpuHandle, > > &gEfiCpuArchProtocolGuid, > > &mCpu, > > + &gEfiMemoryAttributeProtocolGuid, > > + &mMemoryAttribute, > > NULL > > ); > > > > diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.h b/ArmPkg/Drivers/CpuDxe/CpuDxe.h > > index 8cb105dcc841..ce2981361aca 100644 > > --- a/ArmPkg/Drivers/CpuDxe/CpuDxe.h > > +++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.h > > @@ -30,9 +30,12 @@ > > #include > > #include > > #include > > +#include > > > > extern BOOLEAN mIsFlushingGCD; > > > > +extern EFI_MEMORY_ATTRIBUTE_PROTOCOL mMemoryAttribute; > > + > > /** > > This function registers and enables the handler specified by InterruptHandler for a processor > > interrupt or exception type specified by InterruptType. If InterruptHandler is NULL, then the > > diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.inf b/ArmPkg/Drivers/CpuDxe/CpuDxe.inf > > index 10792b393fc8..e732e21cb94a 100644 > > --- a/ArmPkg/Drivers/CpuDxe/CpuDxe.inf > > +++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.inf > > @@ -23,6 +23,7 @@ [Sources.Common] > > CpuDxe.h > > CpuMmuCommon.c > > Exception.c > > + MemoryAttribute.c > > > > [Sources.ARM] > > Arm/Mmu.c > > @@ -53,6 +54,7 @@ [LibraryClasses] > > > > [Protocols] > > gEfiCpuArchProtocolGuid > > + gEfiMemoryAttributeProtocolGuid > > > > [Guids] > > gEfiDebugImageInfoTableGuid > > diff --git a/ArmPkg/Drivers/CpuDxe/MemoryAttribute.c b/ArmPkg/Drivers/CpuDxe/MemoryAttribute.c > > new file mode 100644 > > index 000000000000..b47464c0269e > > --- /dev/null > > +++ b/ArmPkg/Drivers/CpuDxe/MemoryAttribute.c > > @@ -0,0 +1,271 @@ > > +/** @file > > + > > + Copyright (c) 2023, Google LLC. All rights reserved. > > + > > + SPDX-License-Identifier: BSD-2-Clause-Patent > > + > > +**/ > > + > > +#include "CpuDxe.h" > > + > > +/** > > + This function retrieves the attributes of the memory region specified by > > + BaseAddress and Length. If different attributes are got from different part > > "from different part" -> "for different parts"? > Yeah. this is copy/paste from the protocol definition, which prose I didn't write. I'll fix up both instances. > > + of the memory region, EFI_NO_MAPPING will be returned. > > + > > + @param This The EFI_MEMORY_ATTRIBUTE_PROTOCOL instance. > > + @param BaseAddress The physical address that is the start address of > > + a memory region. > > + @param Length The size in bytes of the memory region. > > + @param Attributes Pointer to attributes returned. > > + > > + @retval EFI_SUCCESS The attributes got for the memory region. > > + @retval EFI_INVALID_PARAMETER Length is zero. > > + Attributes is NULL. > > + @retval EFI_NO_MAPPING Attributes are not consistent cross the memory > > + region. > > + @retval EFI_UNSUPPORTED The processor does not support one or more > > + bytes of the memory resource range specified > > + by BaseAddress and Length. > > Question: this implementation never returns EFI_UNSUPPORTED. > Is this seen as a "some architectures may have some restricted ranges > not configurable by MMU" which simply does not apply for ARM* - > i.e. the operation is considered "supported" even if on a region not > backed by anything? > Yeah, good point. The UEFI spec does not really reason about this at all in the specification of the protocol, but I guess it would make a lot of sense to only allow this to be used on regions that are marked as system memory in the GCD memory map. I'll have a stab at implementing it like that.