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

[Igor Mammedov <imammedo@redhat.com>]

On Tue, 27 Feb 2018 04:36:45 +0000
"Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:

> > -----Original Message-----
> > From: Igor Mammedov [mailto:imammedo@redhat.com]
> > Sent: Monday, February 26, 2018 8:56 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
> > 
> > On Sat, 24 Feb 2018 03:11:30 +0000
> > "Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
> >   
> > > > -----Original Message-----
> > > > From: Tan, Jianfeng
> > > > Sent: Saturday, February 24, 2018 11:08 AM
> > > > To: 'Igor Mammedov'
> > > > 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
> > > >
> > > > Hi Igor and all,
> > > >  
> > > > > -----Original Message-----
> > > > > From: Igor Mammedov [mailto:imammedo@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
> > Above options are legacy (which we can't remove for compat reasons),
> > their replacement is 'memory-backend-file' backend which has all of
> > the above including 'share' property.  
> 
> OK, such options are legacy. I've no idea of that. Thanks! That makes sense.
> 
> > 
> > So just add 'memdev' property to machine and reuse memory-backend-file
> > with it instead of duplicating functionality in the legacy code.  
> 
> To "-m" or "-machine"?
"-machine", I plan to convert -m to machine options as well (it's somewhere on my TODO list)

but as Paolo pointed out that will help only to avoid using -numa
and won't help with your case, which should be solved at upper layer
(i.e. starting QEMU on src with shared memory from the begging).