On Thu, Aug 17, 2023 at 04:37:52PM +0200, David Hildenbrand wrote: > On 17.08.23 16:37, Daniel P. Berrangé wrote: > > On Thu, Aug 17, 2023 at 04:30:16PM +0200, David Hildenbrand wrote: > > > > > > > @Stefan, do you have any concern when we would do 1) ? > > > > > > > > As far as I can tell, we have to set the nvdimm to "unarmed=on" either > > > > way: > > > > > > > > + "unarmed" controls the ACPI NFIT NVDIMM Region Mapping Structure > > > > "NVDIMM > > > > + State Flags" Bit 3 indicating that the device is "unarmed" and > > > > cannot accept > > > > + persistent writes. Linux guest drivers set the device to read-only > > > > when this > > > > + bit is present. Set unarmed to on when the memdev has readonly=on. > > > > > > > > So changing the behavior would not really break the nvdimm use case. > > > > > > Looking into the details, this seems to be the right thing to do. > > > > > > This is what I have now as patch description, that also highlights how > > > libvirt > > > doesn't even make use of readonly=true. > > > > > > > > > From 42f272ace68e0cd660a8448adb5aefb3b9dd7005 Mon Sep 17 00:00:00 2001 > > > From: David Hildenbrand <da...@redhat.com> > > > Date: Thu, 17 Aug 2023 12:09:07 +0200 > > > Subject: [PATCH v2 2/4] backends/hostmem-file: Make share=off,readonly=on > > > result in RAM instead of ROM > > > > > > For now, "share=off,readonly=on" would always result in us opening the > > > file R/O and mmap'ing the opened file MAP_PRIVATE R/O -- effectively > > > turning it into ROM. > > > > > > As documented, readonly only specifies that we want to open the file R/O: > > > > > > @readonly: if true, the backing file is opened read-only; if false, > > > it is opened read-write. (default: false) > > > > > > Especially for VM templating, "share=off" is a common use case. However, > > > that use case is impossible with files that lack write permissions, > > > because "share=off,readonly=off" will fail opening the file, and > > > "share=off,readonly=on" will give us ROM instead of RAM. > > > > > > With MAP_PRIVATE we can easily open the file R/O and mmap it R/W, to > > > turn it into COW RAM: private changes don't affect the file after all and > > > don't require write permissions. > > > > > > This implies that we only get ROM now via "share=on,readonly=on". > > > "share=off,readonly=on" will give us RAM. > > > > > > The sole user of ROM via memory-backend-file are R/O NVDIMMs. They > > > also require "unarmed=on" to be set for the nvdimm device. > > > > > > With this change, R/O NVDIMMs will continue working even if > > > "share=off,readonly=on" was specified similar to when simply > > > providing ordinary RAM to the nvdimm device and setting "unarmed=on". > > > > > > Note that libvirt seems to default for a "readonly" nvdimm to > > > * -object memory-backend-file,share=off (implying readonly=off) > > > * -device nvdimm,unarmed=on > > > And never seems to even set "readonly=on" for memory-backend-file. So > > > this change won't affect libvirt, they already always get COW RAM -- not > > > modifying the underlying file but opening it R/O. > > > > > > If someone really wants ROM, they can just use "share=on,readonly=on". > > > After all, there is not relevant difference between a R/O MAP_SHARED > > > file mapping and a R/O MAP_PRIVATE file mapping. > > > > > > Signed-off-by: David Hildenbrand <da...@redhat.com> > > > > This still leaves the patch having a warn_report() which I think is > > undesirable to emit in a valid / supported use case. > > No warning. > > Please elaborate on "valid/supported use case".
The usage scenario that this patch aims to enable. IIUC, it will follow the codepath that leads to the warn_report() call in this patch. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
