On Wed, Feb 20, 2019 at 7:37 AM Stefan Hajnoczi <stefa...@gmail.com> wrote: > > On Fri, Feb 15, 2019 at 05:09:31PM +0000, bipin.tomar--- via Qemu-devel wrote: > > Text from "docs/nvdimm.txt" says: > > Guest Data Persistence > > ---------------------- > > > > Though QEMU supports multiple types of vNVDIMM backends on Linux, > > currently the only one that can guarantee the guest write persistence > > is the device DAX on the real NVDIMM device (e.g., /dev/dax0.0), to > > which all guest access do not involve any host-side kernel cache. > > > > I think here "host-side kernel cache" imply "page cache". Why does fsdax > > NOT have the same persistence guarantees as devdax for vNVDIMM? > > Both the modes avoid using page cache then why is devdax explicitly called > > out? > > File systems may require msync(2)/fsync(2) to guarantee persistence even > with DAX (just a cache flush instruction may not be enough!). Emulated > NVDIMM devices lack an fsync interface so guests are unable to fsync the > host file system. > > This is not an issue with devdax since there is no host file system. > > virtio-pmem is an effort to add a paravirtualized fsync-style interface > and should solve this problem in the future: > https://lkml.org/lkml/2019/1/9/541
A para-virtualized flush is only necessary if the host implements caches and dirty-metadata that cannot be coordinated / flushed by MAP_SYNC. virtio-pmem is not a solution to a problem, virtio-pmem is a non-DAX alternative implementation of persistent memory that requires the guest to coordinate metadata and host page cache flushing.
