Hi Igor and all, > -----Original Message----- > From: Igor Mammedov [mailto:imamm...@redhat.com] > Sent: Thursday, February 8, 2018 7:30 PM > To: Tan, Jianfeng > Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-devel@nongnu.org; > Michael S . Tsirkin > Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as > migration > [...] > > > It could be solved by adding memdev option to machine, > > > which would allow to specify backend object. And then on > > > top make -mem-path alias new option to clean thing up. > > > > Do you mean? > > > > src vm: -m xG > > dst vm: -m xG,memdev=pc.ram -object > > memory-backend-file,id=pc.ram,size=xG,mem-path=xxx,share=on ... > Yep, I've meant something like it > > src vm: -m xG,memdev=SHARED_RAM -object > memory-backend-file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on > dst vm: -m xG,memdev=SHARED_RAM -object > memory-backend-file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
After a second thought, I find adding a backend for nonnuma pc RAM is roundabout way. And we actually have an existing way to add a file-backed RAM: commit c902760fb25f ("Add option to use file backed guest memory"). Basically, this commit adds two options, --mem-path and --mem-prealloc, without specify a backend explicitly. So how about just adding a new option --mem-share to decide if that's a private memory or shared memory? That seems much straightforward way to me; after this change we can migrate like: src vm: -m xG dst vm: -m xG --mem-path xxx --mem-share Thanks, Jianfeng > > or it could be -machine FOO,inital_ram_memdev=... > maybe making -M optional in this case as size is specified by backend > > PS: > it's not a good idea to use QEMU's internal id 'pc.ram' > for user specified objects as it might cause problems.