On Tue, Feb 19, 2019 at 9:22 AM [email protected] <[email protected]> wrote: > > I haven't heard from anyone on qemu-devel. There are a lot of vNVDIMM > experts here and I'm hoping that someone here may throw some light.
Answers inline below: > ----- Forwarded Message ----- From: [email protected] > <[email protected]>To: [email protected] <[email protected]>Sent: > Friday, February 15, 2019, 12:09:31 PM ESTSubject: Why only devdax guarantees > guest data persistence ? > 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? As long as the mapping is established with the MAP_SYNC facility then the persistence guarantees are the same as the host. You may be thinking of the pre-MAP_SYNC days where there was no facility to coordinate the synchronization of host metadata. I will note that device-passthrough is disabled for fsdax because there is no facility to coordinate host truncation events vs guest-device-initiated DMA, but that's a separate issue from persistence guarantees. VFIO will simply fail to register devices in this case. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
