On Thu, Oct 19, 2017 at 1:01 AM, Christoph Hellwig <h...@infradead.org> wrote: > On Wed, Oct 18, 2017 at 08:51:37AM -0700, Dan Williams wrote: >> This use case is not "Persistent Memory". Persistent Memory is >> something you can map and make persistent with CPU instructions. >> Anything that requires a driver call is device driver managed "Shared >> Memory". > > How is this any different than the existing nvdimm_flush()? If you > really care about the not driver thing it could easily be a write > to a doorbell page or a hypercall, but in the end that's just semantics.
The difference is that nvdimm_flush() is not mandatory, and that the platform will automatically perform the same flush at power-fail. Applications should be able to assume that if they are using MAP_SYNC that no other coordination with the kernel or the hypervisor is necessary. Advertising this as a generic Persistent Memory range to the guest means that the guest could theoretically use it with device-dax where there is no driver or filesystem sync interface. The hypervisor will be waiting for flush notifications and the guest will just issue cache flushes and sfence instructions. So, as far as I can see we need to differentiate this virtio-model from standard "Persistent Memory" to the guest and remove the possibility of guests/applications making the wrong assumption. Non-ODP RDMA in a guest comes to mind...
