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?

See efi_fake_mem for how to apply that range to existing
EFI_CONVENTIONAL_MEMORY ranges, it requires CONFIG_EFI_SOFT_RESERVE=y.

I will look at this, but because the machine on which we are using
this is device-tree based it would require more changes for support. I
think a new device tree node is required that would set IORESOURCE_MEM
/  IORES_DESC_SOFT_RESERVED properties.

Thank you,
Pasha

The daxctl utility has grown mechanisms to subdivide such ranges.

   daxctl create-device

...starting with v71.

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