Re: [Qemu-devel] [PATCH v5 11/45] Return path: Send responses from destination to source

[Dr. David Alan Gilbert]

* David Gibson (address@hidden) wrote:
> On Tue, Mar 10, 2015 at 02:34:03PM +0000, Dr. David Alan Gilbert wrote:
> > * David Gibson (address@hidden) wrote:
> > > On Wed, Feb 25, 2015 at 04:51:34PM +0000, Dr. David Alan Gilbert (git) 
> > > wrote:
> > > > From: "Dr. David Alan Gilbert" <address@hidden>
> > > > 
> > > > Add migrate_send_rp_message to send a message from destination to 
> > > > source along the return path.
> > > >   (It uses a mutex to let it be called from multiple threads)
> > > > Add migrate_send_rp_shut to send a 'shut' message to indicate
> > > >   the destination is finished with the RP.
> > > > Add migrate_send_rp_ack to send a 'PONG' message in response to a PING
> > > >   Use it in the CMD_PING handler
> > > > 
> > > > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> > > > ---
> > > >  include/migration/migration.h | 17 ++++++++++++++++
> > > >  migration/migration.c         | 45 
> > > > +++++++++++++++++++++++++++++++++++++++++++
> > > >  savevm.c                      |  2 +-
> > > >  trace-events                  |  1 +
> > > >  4 files changed, 64 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/include/migration/migration.h 
> > > > b/include/migration/migration.h
> > > > index c514dd4..6775747 100644
> > > > --- a/include/migration/migration.h
> > > > +++ b/include/migration/migration.h
> > > > @@ -41,6 +41,13 @@ struct MigrationParams {
> > > >      bool shared;
> > > >  };
> > > >  
> > > > +/* Commands sent on the return path from destination to source*/
> > > > +enum mig_rpcomm_cmd {
> > > 
> > > "command" doesn't seem like quite the right description for these rp
> > > messages.
> > 
> > Would you prefer 'message' ?
> 
> Perhaps "message type" to distinguish from the the blob including both
> tag and data.

OK, done:

/* Messages sent on the return path from destination to source */
enum mig_rp_message_type {
    MIG_RP_MSG_INVALID = 0,  /* Must be 0 */

<snip>

> > > > +/*
> > > > + * Send a 'PONG' message on the return channel with the given value
> > > > + * (normally in response to a 'PING')
> > > > + */
> > > > +void migrate_send_rp_pong(MigrationIncomingState *mis,
> > > > +                          uint32_t value)
> > > > +{
> > > > +    uint32_t buf;
> > > > +
> > > > +    buf = cpu_to_be32(value);
> > > > +    migrate_send_rp_message(mis, MIG_RP_CMD_PONG, 4, (uint8_t *)&buf);
> > > 
> > > It occurs to me that you could define PONG as returning the whole
> > > buffer that PING sends, instead of just 4-bytes.  Might allow for some
> > > more testing of variable sized messages.
> > 
> > Yes; although it would complicate things a lot if I made it fully generic
> > because I'd have to worry about allocating a buffer etc and I'm not
> > making vast use of the 4 bytes I've already got.
> 
> Couldn't migrate_send_rp_pong just take a buf pointer and length, then
> you can point that directly at the buffer in the ping message you've
> received.

The buffer is a few levels down at that point, so it's non-trivial
to do that, where as it's currently very very simple to just pass
that fixed length value; and it's only a bit of debug.

Dave

> 
> -- 
> David Gibson                  | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au        | minimalist, thank you.  NOT _the_ 
> _other_
>                               | _way_ _around_!
> http://www.ozlabs.org/~dgibson


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