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

["Tan, Jianfeng" <jianfeng.tan@intel.com>]

On 2/7/2018 8:06 PM, Igor Mammedov wrote:
> On Wed, 7 Feb 2018 07:49:58 +0000
> "Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
>
>>> -----Original Message-----
>>> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
>>> Sent: Tuesday, February 6, 2018 1:32 AM
>>> To: Igor Mammedov
>>> Cc: Tan, Jianfeng; qemu-devel@nongnu.org; Jason Wang; Maxime Coquelin;
>>> Michael S . Tsirkin
>>> Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
>>> migration
>>>
>>> On 05/02/2018 18:15, Igor Mammedov wrote:
>>>>>> Then we would have both ram block named pc.ram:
>>>>>>                Block Name    PSize
>>>>>>                        pc.ram     4 KiB
>>>>>>        /objects/pc.ram    2 MiB
>>>>>>
>>>>>> But I assume it's a corner case which not really happen.
>>>>> Yeah, you're right. :/  I hadn't thought of hotplug.  It can happen indeed.
>>>> perhaps we should fail object_add memory-backend-foo if it resulted
>>>> in creating ramblock with duplicate id
>>> Note that it would only be duplicated with Jianfeng's patch.  So I'm
>>> worried that his patch is worse than what we have now, because it may
>>> create conflicts with system RAMBlock names are not necessarily
>>> predictable.  Right now, -object creates RAMBlock names that are nicely
>>> constrained within /object/.
>> So we are trading off between the benefit it takes and the bad effect it brings.
>>
>> I'm wondering if the above example is the only failed case this patch leads to, i.e, only there is a ram named "pc.ram" and "/object/pc.ram" in the src VM?
>>
>> Please also consider the second option, that adding an alias name for RAMBlock; I'm not a big fan for that one, as it just pushes the problem to OpenStack/Libvirt.
> looking at provided CLI examples it's configuration issue on src and dst,
> one shall not mix numa and non numa variants.

Aha, that's another thing we also want to change. We now add numa at dst 
node, only because without -numa, we cannot set up the file-baked memory 
with share=on.

For example, "-m xG -mem-path xxx" can set up a file-baked memory, but 
the file is not share-able.

>
>> Or any other suggestions?
> Fix configuration, namely dst side of it (i.e. use the same -m only variant
> without -numa as it's on src).
>
> BTW, what are you trying to achieve adding -numa on dst?

See above reply.

Thanks,
Jianfeng