Re: [Qemu-devel] [PATCH v4 14/47] Return path: Control commands

[Paolo Bonzini]

On 10/23/2014 06:23 PM, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (address@hidden) wrote:
>> Il 03/10/2014 19:47, Dr. David Alan Gilbert (git) ha scritto:
>>>      QEMU_VM_CMD_INVALID = 0,   /* Must be 0 */
>>> +    QEMU_VM_CMD_OPENRP,        /* Tell the dest to open the Return path */
>>
>> OPEN_RETURN_PATH?
>>
>>> +    QEMU_VM_CMD_REQACK,        /* Request an ACK on the RP */
>>
>> SEND_ACK or ACK_REQUESTED?
>>
>>>      QEMU_VM_CMD_AFTERLASTVALID
>>
>> Pleaseseparatewords.  Is this enum actually used at all?
>>
>> Please avoid the difference between QEMU_VM_CMD and MIG_RPCOMM_.
>>
>> Perhaps MIG_CMD and MIG_RPCMD_?
> 
> Almost, I went with:
> 
>     MIG_CMD_INVALID = 0,       /* Must be 0 */
>     MIG_CMD_OPEN_RETURN_PATH,  /* Tell the dest to open the Return path */
>     MIG_CMD_SEND_ACK,          /* Request an ACK on the RP */
>     MIG_CMD_PACKAGED,          /* Send a wrapped stream within this stream */
> 
>     MIG_CMD_POSTCOPY_ADVISE = 20,  /* Prior to any page transfers, just
>                                       warn we might want to do PC */
>     MIG_CMD_POSTCOPY_LISTEN,       /* Start listening for incoming
>                                       pages as it's running. */
>     MIG_CMD_POSTCOPY_RUN,          /* Start execution */
>     MIG_CMD_POSTCOPY_END,          /* Postcopy is finished. */
> 
>     MIG_CMD_POSTCOPY_RAM_DISCARD,  /* A list of pages to discard that
>                                       were previously sent during
>                                       precopy but are dirty. */
> 
> and
>     MIG_RP_CMD_INVALID = 0,  /* Must be 0 */
>     MIG_RP_CMD_SHUT,         /* sibling will not send any more RP messages */
>     MIG_RP_CMD_ACK,          /* data (seq: be32 ) */
>     MIG_RP_CMD_REQ_PAGES,    /* data (start: be64, len: be64) */
> 
> the only oddity I get from that is from the 'SEND_ACK' you suggested;
> since all my functions to send commands are send_  I currently have
>  'qemu_savevm_send_send_ack'  which while consistent looks a bit odd.

Perhaps ping/pong?

Paolo