Re: [Xen-devel] [DRAFT v2] XenSock protocol design document

[Stefano Stabellini <stefano@xxxxxxxxxxx>]

On Wed, 20 Jul 2016, Juergen Gross wrote:
> On 20/07/16 00:38, Stefano Stabellini wrote:
> > On Fri, 15 Jul 2016, Paul Durrant wrote:
> >>> -----Original Message-----
> >>> From: Juergen Gross [mailto:jgross@xxxxxxxx]
> >>> Sent: 15 July 2016 12:37
> >>> To: Stefano Stabellini; xen-devel@xxxxxxxxxxxxxxxxxxxx
> >>> Cc: joao.m.martins@xxxxxxxxxx; Wei Liu; Roger Pau Monne; Lars Kurth;
> >>> boris.ostrovsky@xxxxxxxxxx; Paul Durrant
> >>> Subject: Re: [DRAFT v2] XenSock protocol design document
> >>>
> >>> On 13/07/16 17:47, Stefano Stabellini wrote:
> >>>> Hi all,
> >>>>
> >>>> This is the design document of the XenSock protocol. You can find
> >>>> prototypes of the Linux frontend and backend drivers here:
> >>> ...
> >>>> ### Commands Ring
> >>>>
> >>>> The shared ring is used by the frontend to forward socket API calls to 
> >>>> the
> >>>> backend. I'll refer to this ring as **commands ring** to distinguish it 
> >>>> from
> >>>> other rings which will be created later in the lifecycle of the protocol 
> >>>> (data
> >>>> rings). The ring format is defined using the familiar `DEFINE_RING_TYPES`
> >>> macro
> >>>> (`xen/include/public/io/ring.h`). Frontend requests are allocated on the
> >>> ring
> >>>> using the `RING_GET_REQUEST` macro.
> >>>>
> >>>> The format is defined as follows:
> >>>>
> >>>>     #define XENSOCK_SOCKET         0
> >>>>     #define XENSOCK_CONNECT        1
> >>>>     #define XENSOCK_RELEASE        2
> >>>>     #define XENSOCK_BIND           3
> >>>>     #define XENSOCK_LISTEN         4
> >>>>     #define XENSOCK_ACCEPT         5
> >>>>     #define XENSOCK_POLL           6
> >>>>
> >>>>     struct xen_xensock_request {
> >>>>          uint32_t id; /* private to guest, echoed in response */
> >>>>          uint32_t cmd; /* command to execute */
> >>>>          uint64_t sockid;
> >>>>          union {
> >>>>                  struct xen_xensock_socket {
> >>>>                          uint32_t domain;
> >>>>                          uint32_t type;
> >>>>                          uint32_t protocol;
> >>>>                  } socket;
> >>>>                  struct xen_xensock_connect {
> >>>>                          uint8_t addr[28];
> >>>>                          uint32_t len;
> >>>>                          uint32_t flags;
> >>>>                          grant_ref_t ref;
> >>>>                          uint32_t evtchn;
> >>>>                  } connect;
> >>>>                  struct xen_xensock_bind {
> >>>>                          uint8_t addr[28];
> >>>>                          uint32_t len;
> >>>>                  } bind;
> >>>>                  struct xen_xensock_listen {
> >>>>                          uint32_t backlog;
> >>>>                  } listen;
> >>>>                  struct xen_xensock_accept {
> >>>>                          uint64_t sockid;
> >>>>                          grant_ref_t ref;
> >>>>                          uint32_t evtchn;
> >>>>                  } accept;
> >>>>          } u;
> >>>>     };
> >>>
> >>> Please add padding at the end (or a dummy union member) to make sure
> >>> 32- and 64-bit variants have the same size (I believe now the size will
> >>> be 60 bytes on 32-bit system and 64 bytes on 64-bit).
> > 
> > Well spotted! You have a point, I think you are right, even though it
> > makes the struct a bit awkward.
> 
> Why awkward? just add a "uint8_t dummy[48];" to u.

That's what I have done. I'll send an update soon.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel