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