From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field Date: Thu, 10 Jun 2010 08:33:28 -0600 Message-ID: <1276180408.2992.12.camel@x201> References: <20100608191447.4451.47795.stgit@localhost.localdomain> <201006091318.49556.paul@codesourcery.com> <1276101449.3079.74.camel@x201> <201006092136.38569.paul@codesourcery.com> <4C10A106.1050108@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Paul Brook , Anthony Liguori , qemu-devel@nongnu.org, chrisw@redhat.com, kvm@vger.kernel.org, quintela@redhat.com To: Gerd Hoffmann Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53531 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758780Ab0FJOdm (ORCPT ); Thu, 10 Jun 2010 10:33:42 -0400 In-Reply-To: <4C10A106.1050108@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 2010-06-10 at 10:23 +0200, Gerd Hoffmann wrote: > > I may have been a bit misleading here. What we really want to do is use the > > same matching algorithm as is used by the rest of the device state. Currently > > this is a vmstate name and [arbitrary] numeric id. I don't remember whether > > there's a convenient link from a device to its associated vmstate - if there > > isn't there probably should be. > > DeviceState->info->vmsd->name for the name. > Dunno about the numeric id, I think savevm.c doesn't export it. Ok, we can certainly do name>.instance>\. It seems like this highlights a deficiency in the vmstate matching though. If on the source we do: > pci_add addr=4 nic model=e1000 > pci_add addr=3 nic model=e1000 Then we start the target, ordering the nics sequentially, are we going to store the vmstate into the opposite nics? AIUI, libvirt does this correctly today, but I don't like the idea of being required to remember the history of a vm to migrate it. Alex