On Fri, Mar 6, 2020 at 12:07 PM Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: > > Dan Williams <dan.j.williams@xxxxxxxxx> writes: > > > Given the current dearth of systems that supply an ACPI HMAT table, and > > the utility of being able to manually define device-dax "hmem" instances > > via the efi_fake_mem= option, relax the requirements for creating these > > devices. Specifically, add an option (numa=nohmat) to optionally disable > > consideration of the HMAT and update efi_fake_mem= to behave like > > memmap=nn!ss in terms of delimiting device boundaries. > > So, am I correct in deducing that your primary motivation is testing > without hardware/firmware support? My primary motivation is making the dax_kmem facility useful to shipping platforms that have performance differentiated memory, but may not have EFI-defined soft-reservations / HMAT (or non-EFI-ACPI-platform equivalent). I'm anticipating HMAT enabled platforms where the platform firmware policy for what is soft-reserved, or not, is not the policy the system owner would pick. I'd also highlight Joao's work [1] (see the TODO section) as an indication of the demand for custom carving memory resources and applying the device-dax memory management interface. > This looks like a bit of a hack to > me, and I think maybe it would be better to just emulate the HMAT using > qemu. I don't have a strong objection, though. Yeah, qemu emulation does not help when you, the system owner, have a different use case than what the bare-metal platform-firmware envisioned for "specific-purpose memory". [1]: https://lore.kernel.org/lkml/20200110190313.17144-1-joao.m.martins@xxxxxxxxxx/
