[Qemu-devel] Re: [RFC PATCH 5/6] savevm: Migrate RAM based on name/offset

[Alex Williamson]

On Tue, 2010-06-08 at 13:54 -0700, Chris Wright wrote:
> * Alex Williamson (address@hidden) 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