On Tue, 27 Feb 2018 04:36:45 +0000 "Tan, Jianfeng" <[email protected]> wrote:
> > -----Original Message----- > > From: Igor Mammedov [mailto:[email protected]] > > Sent: Monday, February 26, 2018 8:56 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 > > > > On Sat, 24 Feb 2018 03:11:30 +0000 > > "Tan, Jianfeng" <[email protected]> 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- > > [email protected]; > > > > 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:[email protected]] > > > > > Sent: Thursday, February 8, 2018 7:30 PM > > > > > To: Tan, Jianfeng > > > > > Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu- > > > > [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 > > 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).
