* Igor Mammedov (imamm...@redhat.com) wrote:
> On Mon, 5 Feb 2018 17:19:09 +0100
> Paolo Bonzini <pbonz...@redhat.com> wrote:
>
> > On 05/02/2018 17:12, Tan, Jianfeng wrote:
> > > Hi Paolo,
> > >
> > > On 2/5/2018 11:53 PM, Paolo Bonzini wrote:
> > >> On 05/02/2018 15:58, Jianfeng Tan wrote:
> > >>> Here are some options to fix this:
> > >>>
> > >>> 1. When we do ram name comparison, we truncate the prefix as this
> > >>> patch shows.
> > >>> It cannot cover the corner case: the source VM could have two ram blocks
> > >>> with name of "pc.ram" and "/object/pc.ram".
> > >> That shouldn't happen ("pc.ram" exists even in the "-numa
> > >> node,memdev=..." case, but it has no RAM block).
> > >
> > > Suppose we have a VM started with "-m xG", and then hot plugged with a
> > > ram block:
> > > (qemu) object_add
> > > memory-backend-file,id=pc.ram,size=1G,mem-path=/dev/hugepages
> > > (qemu) device_add pc-dimm,id=pc.ram,memdev=pc.ram
> > >
> > > 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
>
That's probably not a bad idea; I thought I'd hit a simpliar problem a
while ago; I'd ended up (through a different problem) of having
RAMBlocks with empty names and ended up with two of them.
Dave
> >
> > >> However, note that
> > >>
> > >> -m xG -numa node,memdev=pc.ram \
> > >> -object memory-backend-file,id=pc.ram,...
> > >>
> > >> works for both vhost-kernel and vhost-user, so I'd rather consider this
> > >> a configuration problem and not do anything.
> > >
> > > That configuration indeed works for both. But in the production env,
> > > lots of VMs are already started with previous mem config. If we do
> > > nothing, it will take a long time (shutdown/start for each VM) to
> > > migrate to the new setup. This patch is to make this process more smooth
> > > without any bad effect if possible.
> >
> > I understand. However it's not as bad as "there's no possibility at all
> > to migrate from vhost-kernel to vhost-user". There are cases that are
> > more problematic: for example, there's no possibility at all to add
> > memory NUMA policy during a live migration, unless -object
> > memory-backend-* was used on the source.
> >
> > Paolo
> >
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
