On 一, 2018-06-11 at 19:55 -0700, Dan Williams wrote: > On Mon, Jun 11, 2018 at 9:26 AM, Stefan Hajnoczi <[email protected] > > wrote: > > > > On Mon, Jun 11, 2018 at 06:54:25PM +0800, Zhang Yi wrote: > > > > > > Nvdimm driver use Memory hot-plug APIs to map it's pmem resource, > > > which at a section granularity. > > > > > > When QEMU emulated the vNVDIMM device, decrease the label- > > > storage, > > > QEMU will put the vNVDIMMs directly next to one another in > > > physical > > > address space, which means that the boundary between them won't > > > align to the 128 MB memory section size. > > I'm having a hard time parsing this. > > > > Where does the "128 MB memory section size" come from? ACPI? > > A chipset-specific value? > > > The devm_memremap_pages() implementation use the memory hotplug core > to allocate the 'struct page' array/map for persistent memory. Memory > hotplug can only be performed in terms of sections, 128MB on x86_64. > There is some limited support for allowing devm_memremap_pages() to > overlap 'System RAM' within a given section, but it does not > currently > support multiple devm_memremap_pages() calls overlapping within the > same section. There is currently a kernel bug where we do not handle > this unsupported configuration gracefully. The fix will cause > configurations configurations that try to overlap 2 persistent memory > ranges in the same section to fail. > > The proposed fix is trying to make sure that QEMU does not run afoul > of this constraint. > > There is currently no line of sight to reduce the minimum memory > hotplug alignment size to less than 128M. Also, as other > architectures > outside of x86_64 add devm_memremap_pages() support, the minimum > section alignment constraint might change and is a property of a > guest > OS. My understanding is that some guest OSes might expect an even > larger persistent memory minimum alignment. > Thanks Dan's explanation, I still have a question that why we overlapping the un-align area instead of drop it? and let it align to the next section.
_______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
