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

[Aneesh Kumar K.V]

On 5/4/21 11:13 AM, Pankaj Gupta wrote:
....

> > What this patch series did was to express that property via a device
> > tree node and guest driver enables a hypercall based flush mechanism to
> > ensure persistence.
>
> Would VIRTIO (entirely asynchronous, no trap at host side) based
> mechanism is better
> than hyper-call based? Registering memory can be done any way. We
> implemented virtio-pmem
> flush mechanisms with below considerations:
>
> - Proper semantic for guest flush requests.
> - Efficient mechanism for performance pov.

sure, virio-pmem can be used as an alternative.

> I am just asking myself if we have platform agnostic mechanism already
> there, maybe
> we can extend it to suit our needs? Maybe I am missing some points here.

What is being attempted in this series is to indicate to the guest OS 
that the backing device/file used for emulated nvdimm device cannot 
guarantee the persistence via cpu cache flush instructions.


> > > > On PPC, the default is "sync-dax=writeback" - so the ND_REGION_ASYNC
> > > >
> > > > is set for the region and the guest makes hcalls to issue fsync on the host.
> > > >
> > > >
> > > > Are you suggesting me to keep it "unsafe" as default for all architectures
> > > >
> > > > including PPC and a user can set it to "writeback" if desired.
> > >
> > > No, I am suggesting that "sync-dax" is insufficient to convey this
> > > property. This behavior warrants its own device type, not an ambiguous
> > > property of the memory-backend-file with implicit architecture
> > > assumptions attached.
> >
> > Why is it insufficient?  Is it because other architectures don't have an
> > ability express this detail to guest OS? Isn't that an arch limitations?

-aneesh