Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration

[Tan, Jianfeng]

Hi Igor and all,

> -----Original Message-----
> From: Igor Mammedov [mailto:address@hidden
> Sent: Thursday, February 8, 2018 7:30 PM
> To: Tan, Jianfeng
> Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; address@hidden;
> 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.