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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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?


[Index of Archives]     [KVM Development]     [KVM ARM]     [KVM ia64]     [Linux Virtualization]     [Linux USB Devel]     [Linux Video]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux