Re: lpar issue for ZONE_DEVICE p2pmem in 4.14-rc

On Sat, 21 Oct 2017 15:03:29 +0000
"Stephen  Bates" [off-list ref] wrote:

quoted

I am guessing that the hotplug of ZONE_DEVICE memory was done
incorrectly as it lead to HPT resizing (the system thinking this is
normal memory). Ideally one would expect that the driver would online
ZONE_DEVICE memory and not go through the HOTPLUG path. Are you using
devm_memremap_pages() path to add these pages?
 

Thanks for the response Balbir. Yes we use devm_memremap_pages() to add these pages and it does call arch_add_memory(). We do have an alternate set of patches which still calls devm_memremap_pages() but can take a flag to indicate the memory being added is io memory and uses io_remap() rather than arch_add_memory() for that type of memory [1]. Would that be a better approach for this arch? I can try and apply this patch but __add_pages() has gone through some changes recently so it will take me a few days to get to that. 

I just double checked, for pmem you do need to come in via arch_add_memory(). I was confused
by what we do for HMM, which is call __add_pages(), but we do need a section mapping so
the interface is correct.

The following

[    3.537780] lpar: Attempting to resize HPT to shift 21
[    3.539251] Unable to resize hash page table to target order 21: -1
[    3.541079] Unable to create mapping for hot added memory 0xc000210000000000..0xc000210004000000: -2

Needs to be debugged further. For #1 above please check if your qemu supports
H_RESIZE_HPT_* hcalls? For create mapping failures, the rc is -ENOENT. Can
you help debug this further? We could do hcall tracing or enable debugging.

Balbir Singh.