From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=49586 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OM6GC-0004Ct-41
	for qemu-devel@nongnu.org; Tue, 08 Jun 2010 17:23:01 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <alex.williamson@redhat.com>) id 1OM6GB-0006TA-3I
	for qemu-devel@nongnu.org; Tue, 08 Jun 2010 17:23:00 -0400
Received: from mx1.redhat.com ([209.132.183.28]:6849)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <alex.williamson@redhat.com>) id 1OM6GA-0006T5-SX
	for qemu-devel@nongnu.org; Tue, 08 Jun 2010 17:22:59 -0400
From: Alex Williamson <alex.williamson@redhat.com>
In-Reply-To: <20100608205447.GP28492@x200.localdomain>
References: <20100608191447.4451.47795.stgit@localhost.localdomain>
	<20100608191633.4451.59848.stgit@localhost.localdomain>
	<20100608205447.GP28492@x200.localdomain>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 08 Jun 2010 15:22:53 -0600
Message-ID: <1276032173.3079.12.camel@x201>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [RFC PATCH 5/6] savevm: Migrate RAM based on
	name/offset
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Chris Wright <chrisw@redhat.com>
Cc: quintela@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org

On Tue, 2010-06-08 at 13:54 -0700, Chris Wright wrote:
> * Alex Williamson (alex.williamson@redhat.com) wrote:
> > @@ -257,7 +272,7 @@ int ram_load(QEMUFile *f, void *opaque, int version_id)
> >      ram_addr_t addr;
> >      int flags;
> >  
> > -    if (version_id != 3) {
> > +    if (version_id < 3) {
> >          return -EINVAL;
> 
> Should we clamp to 3 and 4?

Yep, definitely a good idea.

> >      }
> >  
> > @@ -268,23 +283,89 @@ int ram_load(QEMUFile *f, void *opaque, int version_id)
> >          addr &= TARGET_PAGE_MASK;
> >  
> >          if (flags & RAM_SAVE_FLAG_MEM_SIZE) {
> 
> Does it simplify anything to simply add a new flag?

Not that I can see.  Appending it to this existing flag conveniently
lets the receiving side know when it's done since SUM(block->length)
equals MEM_SIZE.  Let me know if I'm missing an optimization or use case
you're thinking of.

> > +                    QLIST_FOREACH(block, &ram.blocks, next) {
> > +                        if (!strncmp(name, block->name, sizeof(name))) {
> > +                            if (block->length != length)
> > +                                return -EINVAL;
> > +                            break;
> > +                        }
> > +                    }
> > +
> > +                    if (!block) {
> > +                        if (!qemu_ram_alloc(name, length))
> > +                            return -ENOMEM;
> 
> Is there any use to finding blocks in stream such that we simply allocate
> them all dynamically?

Maybe.  It seems like we'd be doing a lot of reallocs as we go though.
I think we're pretty locked down once the migration starts, so nothing
should be changing on the source once we get started.  If that's the
case (someone correct me if it's not), sending the block list layout
first seems more efficient.  Thanks,

Alex