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 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

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?


[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