linux-kernel - RE: [PATCH 3/4] ACPI/MRRM: Add "node" symlink to /sys/devices/system/memory/rangeX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <SJ1PR11MB60836038251DD6AD5866E631FCFF2@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Thu, 13 Feb 2025 19:05:50 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: David Hildenbrand <david@...hat.com>, Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>
CC: "Moore, Robert" <robert.moore@...el.com>, "Wysocki, Rafael J"
	<rafael.j.wysocki@...el.com>, Len Brown <lenb@...nel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"acpica-devel@...ts.linux.dev" <acpica-devel@...ts.linux.dev>, "Thomas
 Gleixner" <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "Borislav
 Petkov" <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
	"x86@...nel.org" <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, "Oscar
 Salvador" <osalvador@...e.de>, Danilo Krummrich <dakr@...nel.org>, "Andrew
 Morton" <akpm@...ux-foundation.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 3/4] ACPI/MRRM: Add "node" symlink to
 /sys/devices/system/memory/rangeX

> A couple of questions:
>
> a) How volatile is that information at runtime? Can ranges / IDs change?
>     I read above that user space might in the future be able to
>     reconfigure the ranges.

Initial implementation has BIOS making all the choices. When there
is a system that supports OS changes I envision making the "local_region_id"
and "remote_region_id" files writeable for the sysadmin to make changes.

Note that the address ranges are fixed (and this isn't going to change).

> b) How is hotplug/unplug handled?

I'm looking for answers to this very good question. Plausibly systems
might reserve address ranges for later hotplug. Those ranges could be
enumerated in the MRRM table. But that is just a guess.

> c) How are memory ranges not managed by Linux handled?

It appears that all system memory is included in the range information.
so access by BIOS to reserved memory ranges would be counted
and controlled (unless SMI were to disable on entry). I'll ask this
question.

> It might make sense to expose what you need in a more specialized,
> acpi/MRRM/perf specific form, and not as generic as you currently
> envision it.

Agreed. The only thing going for /sys/devices/system/memory is the name.
The actual semantics of everything below there don't match well with this
usage.

Rafael: How do you feel about this (not implemented yet, just looking for
a new spot to expose this)?

$ cd /sys/firmware/acpi
$ tree memory_ranges/
memory_ranges/
├── range0
│   ├── base
│   ├── length
│   ├── local_region_id
│   └── remote_region_id
├── range1
│   ├── base
│   ├── length
│   ├── local_region_id
│   └── remote_region_id
└── range2
    ├── base
    ├── length
    ├── local_region_id
    └── remote_region_id

4 directories, 12 files

-Tony