Re: [PATCH v1 1/3] softmmu/physmem: fallback to opening guest RAM file as readonly in a MAP_PRIVATE mapping

[David Hildenbrand <david@redhat.com>]

On 17.08.23 16:45, Daniel P. Berrangé wrote:
> 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 <david@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 <david@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.

It shouldn't but I will double check!

-- 
Cheers,

David / dhildenb