On 5/4/21 1:11 AM, Dan Williams wrote:
On Mon, May 3, 2021 at 7:06 AM Shivaprasad G Bhat <sbhat@xxxxxxxxxxxxx> wrote:
.....
The proposal that "sync-dax=unsafe" for non-PPC architectures, is a
fundamental misrepresentation of how this is supposed to work. Rather
than make "sync-dax" a first class citizen of the device-description
interface I'm proposing that you make this a separate device-type.
This also solves the problem that "sync-dax" with an implicit
architecture backend assumption is not precise, but a new "non-nvdimm"
device type would make it explicit what the host is advertising to the
guest.
Currently, users can use a virtualized nvdimm support in Qemu to share
host page cache to the guest via the below command
-object memory-backend-file,id=memnvdimm1,mem-path=file_name_in_host_fs
-device nvdimm,memdev=memnvdimm1
Such usage can results in wrong application behavior because there is no
hint to the application/guest OS that a cpu cache flush is not
sufficient to ensure persistence.
I understand that virio-pmem is suggested as an alternative for that.
But why not fix virtualized nvdimm if platforms can express the details.
ie, can ACPI indicate to the guest OS that the device need a flush
mechanism to ensure persistence in the above case?
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.
....
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
