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

[Stefano Stabellini <stefano@xxxxxxxxxxx>]

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.


> Actually, rather than this bunch of structs that assume a System V ABI, maybe 
> we need a spec. more along the lines of the (ancient) TPI doc. 
> http://pubs.opengroup.org/onlinepubs/009618999/toc.htm. After all, like TPI, 
> this is a message passing protocol.

The C struct was supposed to be only descriptive: I wrote the binary
layouts too. In fact the C struct doesn't even have to be part of the
spec, I included it because I find it more intuitive. I'll make the
wording clearer on this point. However it is true that the layouts don't
cover stuff generated by DEFINE_RING_TYPES.

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