On 1/29/21 4:32 PM, Pavel Tatashin wrote:

On Fri, Jan 29, 2021 at 9:51 AM Joao Martins [off-list ref] wrote:

quoted

Hey Pavel,

On 1/29/21 1:50 PM, Pavel Tatashin wrote:

quoted

quoted

Since we last talked about this the enabling for EFI "Special Purpose"
/ Soft Reserved Memory has gone upstream and instantiates device-dax
instances for address ranges marked with EFI_MEMORY_SP attribute.
Critically this way of declaring device-dax removes the consideration
of it as persistent memory and as such no metadata reservation. So, if
you are willing to maintain the metadata external to the device (which
seems reasonable for your environment) and have your platform firmware
/ kernel command line mark it as EFI_CONVENTIONAL_MEMORY +
EFI_MEMORY_SP, then these reserve-free dax-devices will surface.

Hi Dan,

This is cool. Does it allow conversion between devdax and fsdax so DAX
aware filesystem can be installed and data can be put there to be
preserved across the reboot?

fwiw wrt to the 'preserved across kexec' part, you are going to need
something conceptually similar to snippet below the scissors mark.
Alternatively, we could fix kexec userspace to add conventional memory
ranges (without the SP attribute part) when it sees a Soft-Reserved region.
But can't tell which one is the right thing to do.

Hi Joao,

Is not it just a matter of appending arguments to the kernel parameter
during kexec reboot with Soft-Reserved region specified, or am I
missing something? I understand with fileload kexec syscall we might
accidently load segments onto reserved region, but with the original
kexec syscall, where we can specify destinations for each segment that
should not be a problem with today's kexec tools.

efi_fake_mem only works with EFI_MEMMAP conventional memory ranges, thus
not having a EFI_MEMMAP with RAM ranges means it's a nop for the soft-reserved
regions. Unless, you trying to suggest something like:

	memmap=<start>%<size>+0xefffffff

... To mark soft reserved on top an existing RAM? Sadly don't know if there's
an equivalent for ARM.

I agree that preserving it automatically as you are proposing, would
make more sense, instead of fiddling with kernel parameters and
segment destinations.

Thank you,
Pasha

quoted

At the moment, HMAT ranges (or those defined with efi_fake_mem=) aren't
preserved not because of anything special with HMAT, but simply because
the EFI memmap conventional ram ranges are not preserved (only runtime
services). And HMAT/efi_fake_mem expects these to based on EFI memmap.

[snip]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel