Re: [Qemu-devel] [PATCH v8 38/54] Page request: Add MIG_RP_MSG_REQ_PAGES reverse command

[Dr. David Alan Gilbert]

* Juan Quintela (address@hidden) wrote:
> "Dr. David Alan Gilbert (git)" <address@hidden> wrote:
> > From: "Dr. David Alan Gilbert" <address@hidden>
> >
> > Add MIG_RP_MSG_REQ_PAGES command on Return path for the postcopy
> > destination to request a page from the source.
> >
> > Two versions exist:
> >    MIG_RP_MSG_REQ_PAGES_ID that includes a RAMBlock name and start/len
> >    MIG_RP_MSG_REQ_PAGES that just has start/len for use with the same
> >                         RAMBlock as a previous MIG_RP_MSG_REQ_PAGES_ID
> >
> > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> 
> 
> Reviewed-by: Juan Quintela <address@hidden>
> 
> 
> > diff --git a/migration/migration.c b/migration/migration.c
> > index 4f8ef6f..e994164 100644
> > --- a/migration/migration.c
> > +++ b/migration/migration.c
> > @@ -251,6 +251,35 @@ static void deferred_incoming_migration(Error **errp)
> >      deferred_incoming = true;
> >  }
> >  
> > +/* Request a range of pages from the source VM at the given
> > + * start address.
> > + *   rbname: Name of the RAMBlock to request the page in, if NULL it's the 
> > same
> > + *           as the last request (a name must have been given previously)
> > + *   Start: Address offset within the RB
> > + *   Len: Length in bytes required - must be a multiple of pagesize
> > + */
> > +void migrate_send_rp_req_pages(MigrationIncomingState *mis, const char 
> > *rbname,
> > +                               ram_addr_t start, size_t len)
> > +{
> > +    uint8_t bufc[12 + 1 + 255]; /* start (8), len (4), rbname upto 256 */
> > +    size_t msglen = 12; /* start + len */
> > +
> > +    *(uint64_t *)bufc = cpu_to_be64((uint64_t)start);
> > +    *(uint32_t *)(bufc + 8) = cpu_to_be32((uint32_t)len);
> 
> struct foo {
>      uint64_t start;
>      uint32_t len;
>      char msg[];
> }
> 
> As we are supposed to have the same qemu on both sides, this should
> work, no?

In principal I think it should work between opposite endian hosts;
if they are capable of running the same endian guest (untested);
similarly there's no requirement for the two qemu's to be built
with the same compiler, or I think host word size.
Using structs on a wire always makes me start worrying what
the compiler would do to the layout; I'd assume it would at least
need a 'packed' to be sure a particularly entertaining compiler
doesn't do something odd.

> Reviewed by anyways, because I am not sure that proposed solution is
> (even) better than current code.

Dave

> 
> Later, Juan.
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK