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
