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