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. > > 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. ~Gregory
