On Tue, May 30, 2017 at 2:20 AM, Daniel P. Berrange <berra...@redhat.com> wrote: > On Fri, May 26, 2017 at 08:25:20AM -0700, Dan Williams wrote: >> On Fri, May 26, 2017 at 7:38 AM, Daniel P. Berrange <berra...@redhat.com> >> wrote: >> > On Thu, May 25, 2017 at 08:34:23PM -0700, Dan Williams wrote: >> >> On Thu, May 25, 2017 at 7:32 PM, Haozhong Zhang >> >> <haozhong.zh...@intel.com> wrote: >> >> > Applications in Linux guest that use device-dax never trigger flush >> >> > that can be trapped by KVM/QEMU. Meanwhile, if the host backend is not >> >> > device-dax, QEMU cannot guarantee the persistence of guest writes. >> >> > Before solving this flushing problem, QEMU should warn users if the >> >> > host backend is not device-dax. >> >> >> >> I think this needs to be stronger than a "warn" it needs to be >> >> explicitly forbidden when it is known to be unsafe. >> > >> > I think users should have the choice in what they want to do - >> > QEMU should not artifically block it. There are plenty of things >> > in QEMU that are potentially unsafe in some usage scenarios, but >> > we just document how to use them in a safe manner & any caveats >> > that apply. Higher level applications above QEMU can then consider >> > how they want to apply a usage policy to meet the needs of their >> > usage scenario. >> > >> > Having an emulated DAX device that doesn't guarantee persistence >> > is no different to having an emulated disk device that never flushes >> > to underlying host storage. >> > >> >> It is different in the sense that the contract of when the guest >> should assume persistence is specified by when the write completes to >> the virtual disk. In the case of the virtual NFIT we are currently >> lying to the guest about that platform persistence guarantee even if >> the hypervisor is emulating pmem with volatile memory. > > We equally lie to the guest about persistence of disks, when the > disk is run with certain cache= settings, or when the disk backing file > is on tmpfs. It is simply a choice the mgmt application makes about > whether to provide backing storage that is capable of satsifying the > guarantees implied by the guest device model. So I'm still not seeing > a compelling reason to artifically block this with DAX.
Agreed, artificially blocking is not a good path, but for completeness we still need a way to control the ACPI "not armed" health state flag and a sane default for that parameter.
