Re: [PATCH v4 0/3] nvdimm: Enable sync-dax property for nvdimm

[Aneesh Kumar K.V]

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