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

From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>, Igor Mammedov <imammedo@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
Date: Tue, 27 Feb 2018 04:55:37 +0000	[thread overview]
Message-ID: <ED26CBA2FAD1BF48A8719AEF02201E36514530D8@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <bfe718ca-3251-a87d-00e7-60a1dfa2da82@redhat.com>

> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: Monday, February 26, 2018 10:43 PM
> To: Igor Mammedov; Tan, Jianfeng
> Cc: Jason Wang; Maxime Coquelin; qemu-devel@nongnu.org; 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