Gregory Price <gourry@xxxxxxxxxx> writes: > On Wed, Jul 31, 2024 at 09:22:32AM +0800, Huang, Ying wrote: >> Gregory Price <gourry@xxxxxxxxxx> writes: >> >> > This presumes driver configured devices, which is not always the case. >> > >> > kmem.c will set MEMTIER_DEFAULT_DAX_ADISTANCE >> > >> > but if BIOS/EFI has set up the node instead, you get the default of >> > MEMTIER_ADISTANCE_DRAM if HMAT is not present or otherwise not sane. >> >> "efi_fake_mem=" kernel parameter can be used to add "EFI_MEMORY_SP" flag >> to the memory range, so that kmem.c can manage it. >> > > In this case, the system is configured explicitly so that kmem does not > manage it. In fact, some systems still cannot be managed with > EFI_MEMORY_SP due to hpa!=spa issues that the driver cannot manage. Sorry, I don't understand. IIUC, kmem.c can manage almost any memory range via drivers/dax/hmem. Please check drivers/dax/hmem/device.c drivers/dax/hmem/hmem.c Could you elaborate why kmem.c doesn't work for some memory range? >> > Not everyone is going to have the ability to get a platform vendor to >> > fix a BIOS bug, and I've seen this in production. >> >> So, some vendor build a machine with broken/missing HMAT/CDAT and wants >> users to use CXL memory devices in it? Have the vendor tested whether >> CXL memory devices work? >> > > As I mentioned, the broken aspect is being fixed, however there are > existing production hardware which do not have HMAT entries. > >> > But the first step here would be creating two modes. HMAT-is-sane and >> > CPU/Non-CPU seems reasonable to me but open to opinions. >> >> IMHO, we should reduce user configurable knobs unless we can prove it >> is really necessary. >> > > That's fair and valid. > > But I think a feature that worked in 5.x should work in 6.x, and right > now the change in node placement breaks hardware that worked with 5.x > which happened to have broken or missing HMAT. -- Best Regards, Huang, Ying
