On 5/1/21 12:44 AM, Dan Williams wrote:
Some corrections to terminology confusion below...
.......
file on the host in case of file backed v-nvdimms. This is addressed by
virtio-pmem in case of x86_64 by making explicit flushes translating to
fsync at qemu.
Note that virtio-pmem was a proposal for a specific optimization of
allowing guests to share page cache. The virtio-pmem approach is not
to be confused with actual persistent memory.
.....
A new device property sync-dax is added to the nvdimm device. When the
sync-dax is 'writeback'(default for PPC), device property
"hcall-flush-required" is set, and the guest makes hcall H_SCM_FLUSH
requesting for an explicit flush.
I'm not sure "sync-dax" is a suitable name for the property of the
guest persistent memory. There is no requirement that the
memory-backend file for a guest be a dax-capable file. It's also
implementation specific what hypercall needs to be invoked for a given
occurrence of "sync-dax". What does that map to on non-PPC platforms
for example? It seems to me that an "nvdimm" device presents the
synchronous usage model and a whole other device type implements an
async-hypercall setup that the guest happens to service with its
nvdimm stack, but it's not an "nvdimm" anymore at that point.
What is attempted here is to use the same guest driver papr_scm.ko
support the usecase of sharing page cache from the host instead of
depending on a new guest driver virtio-pmem. This also try to correctly
indicate to the guest that an usage like
-object memory-backend-file,id=memnvdimm1,mem-path=file_name
-device nvdimm,memdev=memnvdimm1
correctly indicate to the guest that we are indeed sharing page cache
and not really emulating a persistent memory.
W.r.t non ppc platforms, it was discussed earlier and one of the
suggestion there was to mark that as "unsafe".
Any suggestion for an alternate property name than "sync-dax"?
sync-dax is "unsafe" on all other platforms(x86, ARM) and old pseries machines
prior to 5.2 on PPC. sync-dax="writeback" on ARM and x86_64 is prevented
now as the flush semantics are unimplemented.
"sync-dax" has no meaning on its own, I think this needs an explicit
mechanism to convey both the "not-sync" property *and* the callback
method, it shouldn't be inferred by arch type.
Won't a non-sync property imply that guest needs to do a callback to
ensure persistence? Hence they are related?
-aneesh
