On Sat, 21 Oct 2017 15:03:29 +0000 "Stephen Bates" <sba...@raithlin.com> wrote:
> > 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.
