On Tue, 2010-06-08 at 13:54 -0700, Chris Wright wrote:
> * Alex Williamson (alex.williamson@xxxxxxxxxx) 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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
