On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich <jbeul...@suse.com> wrote: [..] >> I think we can do the similar for Xen, like to lay another pseudo >> device on /dev/pmem and do the reservation, like 2. in my previous >> reply. > > Well, my opinion certainly doesn't count much here, but I continue to > consider this a bad idea. For entities like drivers it may well be > appropriate, but I think there ought to be an independent concept > of "OS reserved", and in the Xen case this could then be shared > between hypervisor and Dom0 kernel. Or if we were to consider Dom0 > "just a guest", things should even be the other way around: Xen gets > all of the OS reserved space, and Dom0 needs something custom.
You haven't made the case why Xen is special and other applications of persistent memory are not. The current struct page reservation supports fundamental address-ability of persistent memory namespaces for the rest of the kernel. The Xen reservation is application specific. XFS, EXT4, and DM also have application specific usages of persistent memory and consume metadata space out of a block device. If we don't need an XFS-mode nvdimm device, why do we need Xen-mode? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
