Re: [DRAFT 1] XenSock protocol design document

[Juergen Gross <jgross@suse.com>]

On 08/07/16 16:16, Stefano Stabellini wrote:
> Hi Juergen,
> 
> many thanks for the fast and very useful review!
> 
> 
> On Fri, 8 Jul 2016, Juergen Gross wrote:
>> On 08/07/16 13:23, Stefano Stabellini wrote:
>>>     #define XENSOCK_DATARING_ORDER 6
>>>     #define XENSOCK_DATARING_PAGES (1 << XENSOCK_DATARING_ORDER)
>>>     #define XENSOCK_DATARING_SIZE (XENSOCK_DATARING_PAGES << PAGE_SHIFT)
>>>     
>>>     #define XENSOCK_CONNECT        0
>>>     #define XENSOCK_RELEASE        3
>>>     #define XENSOCK_BIND           4
>>>     #define XENSOCK_LISTEN         5
>>>     #define XENSOCK_ACCEPT         6
>>>     #define XENSOCK_POLL           7
>>>     
>>>     struct xen_xensock_request {
>>>         uint32_t id;     /* private to guest, echoed in response */
>>>         uint32_t cmd;    /* command to execute */
>>>         uint64_t sockid; /* id of the socket */
>>>         union {
>>>             struct xen_xensock_connect {
>>>                 uint8_t addr[28];
>>>                 uint32_t len;
>>>                 uint32_t flags;
>>>                 grant_ref_t ref[XENSOCK_DATARING_PAGES];
>>>                 uint32_t evtchn;
>>>             } connect;
>>>             struct xen_xensock_bind {
>>>                 uint8_t addr[28]; /* ipv6 ready */
>>>                 uint32_t len;
>>>             } bind;
>>>             struct xen_xensock_accept {
>>>                 uint64_t sockid;
>>>                 grant_ref_t ref[XENSOCK_DATARING_PAGES];
>>>                 uint32_t evtchn;
>>>             } accept;
>>>         } u;
>>>     };
>>
>> Below you write the data ring is flexible and can support different
>> ring sizes. This is in contradiction to the definition above: as soon
>> as you modify the ring size you change the interface. You'd have to
>> modify all guests and the host at the same time.
> 
> Yeah, I meant at compile time (which I understand it is not useful for
> anything other than embedded use cases). But you are right that it would
> be nice to be able to choose the ring size at runtime.
> 
> 
>> The flexibility should be kept, so I suggest ring size negotiation via
>> xenstore: the backend should indicate the maximum supported size and
>> the frontend should tell which size it is using. In the beginning I'd
>> see no problem with accepting connection only if both values are
>> XENSOCK_DATARING_PAGES.
> 
> I'll look into it.
> 
> 
>> The connect and accept calls should reference only one page (possibly
>> with an offset into that page) holding the grant_ref_t array of the
>> needed size.
> 
> It would be nice to send the refs as part of the request as done here,
> but I imagine that it would be an issue with a variable number of refs
> because everything in the request struct needs to be sized up at compile
> time. That's the reason why you are suggesting to send them separatly,
> right?

Correct.

>>> The data ring format will be described in the following section.
>>>
>>> Fields:
>>>
>>> - **cmd** value: 0
>>> - additional fields:
>>>   - **addr**: address to connect to, in struct sockaddr format
>>
>> So you expect only Linux guests with the current sockaddr layout?
>> Please specify the structure in the interface.
> 
> I meant sockaddr as defined by POSIX (the Open Group standard):
> 
> http://pubs.opengroup.org/onlinepubs/7908799/xns/syssocket.h.html

Neither the size of sa_family_t nor the numeric values are defined
there.

>> Which value? I've found systems with: 57, 76, 107, 134 or 235 (just to
>> make clear that even an errno name isn't optimal).
> 
> I naively assumed that the error codes were also defined by POSIX, but
> it doesn't seem to be the case. If they are not standard, I'll have to
> include a numeric representation of those error names and possibly do
> conversions. I'll get to it in the next version. I think I makes sense
> to use the existing xen/include/public/errno.h (credits to Roger for the
> suggestion on IRC).

Sure, xen/include/public/errno.h is fine.


Juergen

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