> -----Original Message----- > From: Paolo Bonzini [mailto:[email protected]] > Sent: Monday, February 26, 2018 10:43 PM > To: Igor Mammedov; Tan, Jianfeng > Cc: Jason Wang; Maxime Coquelin; [email protected]; Michael S . > Tsirkin > Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as > migration > > On 26/02/2018 13:55, Igor Mammedov wrote: > >>> 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. > > More precisely, we have added "-object memory-backend-file" to avoid > proliferation of options related to memory. Besides unifying the cases > of 1 and >1 NUMA node, using -object also has the advantage of > supporting memory hotplug. > > You wrote "I find adding a backend for nonnuma pc RAM is roundabout way" > but basically the command line says "this VM has only one NUMA node, > backed by this memory object" which is a precise description of what the > VM memory looks like. > > > So just add 'memdev' property to machine and reuse memory-backend-file > > with it instead of duplicating functionality in the legacy code. > > That would however also have a different RAMBlock id, effectively > producing the same output as "-numa node,memdev=...".
Is it possible that we force that RAMBlock id to be "pc.ram"? > > I think this should be solved at the libvirt level. Libvirt should > write in the migration XML cookie whether the VM is using -object or > -mem-path to declare its memory, and newly-started VMs should always use > -object. This won't fix the problem for VMs that are already running, > but it will fix it the next time they are started. In this case, we return to the start point :-) Thanks, Jianfeng
