> 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
