At 2023-08-11 05:24:43, "Peter Xu" <pet...@redhat.com> 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. We already have "readonly" and
>> >"share=". I'm having a hard time coming up with a good name that really
>> >describes the subtle difference.
>> >
>> >3) Glue behavior to the QEMU machine
>> >
>>
>> 4) '-deny-private-discard' argv, or environment variable, or both
>
>I'd personally vote for (2). How about "fdperm"? To describe when we want
>to use different rw permissions on the file (besides the access permission
>of the memory we already provided with "readonly"=XXX). IIUC the only sane
>value will be ro/rw/default, where "default" should just use the same rw
>permission as the memory ("readonly"=XXX).
>
>Would that be relatively clean and also work in this use case?
>
>(the other thing I'd wish we don't have that fallback is, as long as we
> have any of that "fallback" we'll need to be compatible with it since
> then, and for ever...)
If it must be (2), I would vote (2) + (4), with (4) adjust the default behavior
of said `fdperm`.
Mainly because (private+discard) is itself not a good practice and (4) serves
as a good tool to help catch existing (private+discard) problems.
Actually (readonly+private) is more reasonable than (private+discard), so I
want at least one room for a default (readonly+private) behavior.
Also in my case I kind of have to use "-mem-path" despite it being considered
to be close to deprecated. Only with this I can avoid knowledge of memory
backend before migration. Actually there seems to be no equivalent working
after-migration
setup of "-object memory-backend-file,... -machine q35,mem=..." that can match
before-migration setup of "-machine q35" (specifying nothing). Therefore
I must make a plan and choose a migration method BEFORE I boot the
machine and prepare to migrate, reducing the operation freedom.
Considering that, I have to use "-mem-path" which keeps the freedom but
has no configurable argument and I have to rely on default config.
Are there any "-object memory-backend-file..." setup equivalent to "-machine
q35"
that can migrate from and to each other? If there is, I want to try it out.
By the way "-object memory-backend-file,id=pc.ram" has just been killed by an
earlier
commit.
Either (4) or fixing this should help my config. Hope you can consider this
deeper and figure out a more systematic solution that helps more user?
--
Regards,
logoerthiner
