ry-backend=pc.ram
>Only then, can a memory backend with the id "pc.ram" be created
>manually.
>
>Let's improve the error message.
>
>Unfortuantely, we cannot use error_append_hint(), because the caller
>passes &error_fatal.
>
>Suggested-by: ThinerLogo
At 2023-08-23 20:43:48, "David Hildenbrand" wrote:
>>> +The ``rom`` option specifies whether to create Read Only Memory
>>> (ROM)
>>> +that cannot be modified by the VM. If set to ``on``, the VM cannot
>>> +modify the memory. If set to ``off``, the VM can modify the memory
Hello,
At 2023-08-22 19:44:51, "David Hildenbrand" wrote:
>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.
>
>Especially for VM templating, "share=off" is a common use case. However,
Hello,
At 2023-08-22 19:44:56, "David Hildenbrand" wrote:
>"-mem-path" corresponds to "memory-backend-file,share=off" and,
>therefore, creates a private COW mapping of the file. For multi-proces
>QEMU, we need proper shared file-backed memory.
>
>Let's make that clearer.
>
>Signed-off-by: David H
Hello,
At 2023-08-22 19:44:50, "David Hildenbrand" wrote:
>There is a difference between how we open a file and how we mmap it,
>and we want to support writable private mappings of readonly files. Let's
>define RAM_READONLY and RAM_READONLY_FD flags, to replace the single
>"readonly" parameter fo
At 2023-08-11 22:31:36, "Peter Xu" wrote:
>On Fri, Aug 11, 2023 at 01:49:52PM +0800, ThinerLogoer wrote:
>> At 2023-08-11 05:24:43, "Peter Xu" wrote:
>> >On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
>> >> >I thi
At 2023-08-12 03:00:54, "David Hildenbrand" wrote:
>On 11.08.23 07:49, ThinerLogoer wrote:
>> At 2023-08-11 05:24:43, "Peter Xu" wrote:
>>> On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
>>>>> I think we have the following op
At 2023-08-11 05:24:43, "Peter Xu" wrote:
>On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
>> >I think we have the following options (there might be more)
>> >
>> >1) This patch.
>> >
>> >2) New flag for memory-backend-file.
At 2023-08-10 22:19:45, "David Hildenbrand" wrote:
>>> Most importantly, we won't be corrupting/touching the original file in any
>>> case, because it is R/O.
>>>
>>> If we really want to be careful, we could clue that behavior to compat
>>> machines. I'm not really sure yet if we really have to g
At 2023-08-10 19:11:03, "Philippe Mathieu-Daudé" wrote:
>Hi,
>
>On 8/8/23 19:26, ThinerLogoer wrote:
>>
>> At 2023-08-08 03:07:31, "David Hildenbrand" wrote:
>
>>> Instead of handling it inside file_ram_open(), handle it in the caller
>&
At 2023-08-09 05:01:17, "Peter Xu" wrote:
>On Mon, Aug 07, 2023 at 09:07:32PM +0200, David Hildenbrand wrote:
>> From: Thiner Logoer
>>
>> Users may specify
>> * "-mem-path" or
>> * "-object memory-backend-file,share=off,readonly=off"
>> and expect such COW (MAP_PRIVATE) mappings to work, even i
At 2023-08-08 03:07:31, "David Hildenbrand" wrote:
>Patch #1 is the result of the discussion of:
>"[PATCH v2] softmmu/physmem: try opening file readonly before failure
> in file_ram_open" [1]
>
>Instead of handling it inside file_ram_open(), handle it in the caller
>and only fallback to r
At 2023-07-28 18:45:20, "David Hildenbrand" wrote:
>
>
>Whatever you prefer! If I resend the patch, I would keep you the author
>and only add my Co-authored-by: Signed-off-by:.
>
>Just let me know.
>
Hello,
I wonder whether you have planned to resubmit the current patch anytime soon,
or is it
At 2023-07-28 18:45:20, "David Hildenbrand" wrote:
>>> Quick untested attempt to move retry handling to the caller:
>>>
>>> diff --git a/softmmu/physmem.c b/softmmu/physmem.c
>>> index 3df73542e1..c826bb78fc 100644
>>> --- a/softmmu/physmem.c
>>> +++ b/softmmu/physmem.c
>>> @@ -1289,8 +1289,7 @@ s
Sorry my mail agent just have a bug
At 2023-07-28 02:30:09, "David Hildenbrand" wrote:
>On 27.07.23 17:20, ThinerLogoer wrote:
>>
>> At 2023-07-27 21:18:44, "David Hildenbrand" wrote:
>>> On 26.07.23 16:59, Thiner Logoer wrote:
>>>> Us
At 2023-07-28 02:30:09, "David Hildenbrand" wrote:
>On 27.07.23 17:20, ThinerLogoer wrote:
>>
>> At 2023-07-27 21:18:44, "David Hildenbrand" wrote:
>>> On 26.07.23 16:59, Thiner Logoer wrote:
>>>> Users may give "-mem
At 2023-07-27 21:18:44, "David Hildenbrand" wrote:
>On 26.07.23 16:59, Thiner Logoer wrote:
>> Users may give "-mem-path" a read only file and expect the file
>> to be mapped read-write privately. Allow this but give a warning
>> since other users may surprise when the ram file is readonly and
>>
At 2023-07-26 16:11:44, "David Hildenbrand" wrote:
>
>> though the file never gets written. (the actual memory file & guest state
>> file require
>> separated hacking)
>>
>> And at least the patch provided here have been the solution to this last
>> problem for me
>> for a while.
>>
>> By the
At 2023-07-25 19:42:30, "David Hildenbrand" wrote:
>Hi,
>
>patch subject should start with "softmmu/physmem: Open ..."
Sorry I am newbie to the patch submission part. I will resubmit a version of
patch if the
final acceptable patch after discussion is mostly the same. (For example, if
this pat
19 matches
Mail list logo
