Re: [PATCH V2 05/22] vl: memfd-alloc option

[Steven Sistare]

On 1/6/2021 3:10 PM, Paolo Bonzini wrote:
> Il mer 6 gen 2021, 17:37 Steven Sistare <steven.sistare@oracle.com 
> <mailto:steven.sistare@oracle.com>> ha scritto:
> 
>     Yes, I considered that, but there are other memory regions that cannot be 
> controlled
>     by the command line but which must be preserved, such as vram, bios, and 
> rom.  If vram
>     is not preserved, parts of the screen will be blank until the user 
> performs some action
>     which refreshes the display.  bios and rom should be preserved rather 
> than re-recreated
>     with potentially different contents from the firmware images in the 
> updated qemu package.
> 
>     However, your comment reminds me that I must add a few lines of code to 
> preserve the
>     memory-backend-memfd.
> 
> 
> A new option specific to memory is the wrong way to do this. If a special 
> mode must be specified when starting QEMU, you can make it a -machine option 
> and block the QMP commands unless it's specified. Otherwise you can use 
> "normal" migration to marshal and unmarshal across the update those memory 
> regions that aren't backed by shared memory or memfd.
> 
> Also, because of the mess that vl.c had grown into, adding new "simple" 
> options is going to be very very hard. In fact I am working on turning many 
> options like -smp or -m into syntactic sugar for -machine; at some point I 
> would like to (almost) forbid adding _any_ new option.

Will do.  Thanks for the heads up on the future of vl.c.

I defined the option independently of cpr for generality.  Do you think this 
could be useful?
If yes, I will name and define the -machine option to use memfd;
if no, I will name and define it to enable cpr, and implicitly enable memfd 
without saying so.

- Steve