On Thu, Jun 08, 2017 at 03:56:42PM +0300, Michael S. Tsirkin wrote: > On Tue, Jun 06, 2017 at 03:22:28PM +0800, Haozhong Zhang wrote: > > If a vNVDIMM device is not backed by a DAX device and its "restrict" > > option is enabled, bit 3 of state flags in its region mapping > > structure will be set, in order to notify the guest of the lack of > > write persistence guarantee. Once this bit is set, the guest OS may > > mark the vNVDIMM device as read-only. > > > > This option is disabled by default for backwards compatibility. It's > > recommended to enable for the formal usage. > > > > Signed-off-by: Haozhong Zhang <haozhong.zh...@intel.com> > > Seems wrong to me. E.g. it won't work in a nested > virt setup. What if backend is dax but is not armed? > Can't the armed bit of the backing device be tested? > Name "restrict" is also confusing. Can we reuse cache= > options? E.g. cache=unsafe etc.
The -drive cache= options (writeback, writethrough, none, directsync, unsafe) are confusing and considered legacy options. The new options are -drive cache.writeback=on|off,cache.direct=on|off,cache.no-flush=on|off. I suggested to call the option -device nvdimm,armed=auto|on|off in another email. "Armed" is the term used by the NVDIMM/NFIT specification and it has an NVDIMM-specific meaning. Stefan
signature.asc
Description: PGP signature
