From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
sami.mujawar@arm.com, aneesh.kumar@kernel.org,
steven.price@arm.com, linux-kernel@vger.kernel.org,
sudeep.holla@arm.com
Subject: Re: [PATCH 3/3] arm64: acpi: Enable ACPI CCEL support
Date: Fri, 25 Jul 2025 12:09:04 +0100 [thread overview]
Message-ID: <9765ba29-91e1-42bd-bb46-14fdce7284fe@arm.com> (raw)
In-Reply-To: <aHZsgzNYwfCljX-G@willie-the-truck>
Hi Will
On 15/07/2025 15:58, Will Deacon wrote:
> On Tue, Jul 15, 2025 at 03:38:41PM +0100, Suzuki K Poulose wrote:
>> On 15/07/2025 14:56, Will Deacon wrote:
>>> On Fri, Jun 13, 2025 at 12:11:53PM +0100, Suzuki K Poulose wrote:
>>>> ACPI CCEL memory area is reported as Non-Volatile storage area. Map it as
>>>> PAGE_KERNEL.
>>>
>>> It would be helpful to have a citation for that. I've tried digging it
>>> out of the ACPI spec, but that pointed me to the Intel TDX site and I
>>> got lost in whitepapers :/
>>>
>>
>> https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#cc-event-log-acpi-table
>
> Thanks, but I still can't spot where it specifies the memory attributes.
> I think we should be able to refer to that as justification for ignoring
> the attributes specified by EFI.
Here is the description for the Efi memory types.
https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#memory-type-usage-before-exitbootservices
From that I gather that OS must map the area as read only.
>
>>>> Cc: Sami Mujawar <sami.mujawar@arm.com>
>>>> Cc: Will Deacon <will@kernel.org>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
>>>> Cc: Steven Price <steven.price@arm.com>
>>>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> ---
>>>> arch/arm64/kernel/acpi.c | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>>> index b9a66fc146c9..f52439d411a0 100644
>>>> --- a/arch/arm64/kernel/acpi.c
>>>> +++ b/arch/arm64/kernel/acpi.c
>>>> @@ -356,6 +356,11 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
>>>> prot = PAGE_KERNEL_RO;
>>>> break;
>>>> + case EFI_ACPI_MEMORY_NVS:
>>>> + /* Non-volatile storage, required for CCEL */
>>>> + prot = PAGE_KERNEL;
>>>
>>> By "storage" you just mean memory, right?
>>
>> Yep, it is just memory. I will drop the "NV storage" and simply mention,
>> CCEL.
>
> Thanks. Also, why don't we check against memblock_is_map_memory() for
> this, like we do for all the other types apart from
> EFI_RUNTIME_SERVICES_CODE?
As per the spec, the NVS type must be reserved and we do that in the
kernel. For the other types, you mentioned, they are usable by
general OS and in Linux we only reserve them, if they are have
WB attribute (See is_usable_memory()). Thus we do extra checks to
make sure, if it is in use and mark them as RO.
So, NVS is by default reserved and doesn't have to do extra checks.
That said, I will fix the prot to PAGE_KERNEL_RO to make sure
the OS doesn't write to it.
Thanks
Suzuki
>
> Will
next prev parent reply other threads:[~2025-07-25 11:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-13 11:11 [PATCH 0/3] arm64: realm: Add support for encrypted data from firmware Suzuki K Poulose
2025-06-13 11:11 ` [PATCH 1/3] arm64: realm: ioremap: Allow mapping memory as encrypted Suzuki K Poulose
2025-06-18 15:02 ` Steven Price
2025-06-30 1:33 ` Gavin Shan
2025-06-13 11:11 ` [PATCH 2/3] arm64: Enable EFI secret area Securityfs support Suzuki K Poulose
2025-06-30 1:34 ` Gavin Shan
2025-06-13 11:11 ` [PATCH 3/3] arm64: acpi: Enable ACPI CCEL support Suzuki K Poulose
2025-06-30 1:34 ` Gavin Shan
2025-07-15 13:56 ` Will Deacon
2025-07-15 14:38 ` Suzuki K Poulose
2025-07-15 14:58 ` Will Deacon
2025-07-25 11:09 ` Suzuki K Poulose [this message]
2025-06-16 11:15 ` [PATCH 0/3] arm64: realm: Add support for encrypted data from firmware Suzuki K Poulose
2025-06-17 9:20 ` Sami Mujawar
2025-07-09 12:53 ` Suzuki K Poulose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9765ba29-91e1-42bd-bb46-14fdce7284fe@arm.com \
--to=suzuki.poulose@arm.com \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sami.mujawar@arm.com \
--cc=steven.price@arm.com \
--cc=sudeep.holla@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®