On 1/6/2021 3:10 PM, Paolo Bonzini wrote: > Il mer 6 gen 2021, 17:37 Steven Sistare <steven.sist...@oracle.com > <mailto:steven.sist...@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