Re: [PATCH (V9) 2/2] xen: Add V4V implementation

[Vincent Hanquez <vincent.hanquez@citrix.com>]

On 05/28/2013 08:43 PM, Ross Philipson wrote:
> +
> +typedef struct v4v_addr
> +{
> +    uint32_t port;
> +    domid_t domain;
> +    uint16_t pad;
> +} v4v_addr_t;


> +struct v4v_ring_message_header
> +{
> +    uint32_t len;
> +    uint32_t message_type;
> +    v4v_addr_t source;
> +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> +    uint8_t data[];
> +#elif defined(__GNUC__)
> +    uint8_t data[0];
> +#endif
> +};
> +


> +/*
> + * V4VOP_sendv
> + *
> + * Sends of list of buffer contained in iov.
> + *
> + * For each iov entry send iov_len bytes of iov_base to addr.dst, giving
> + * src as the source address (xen will ignore src->domain and put your
> + * domain in the actually message), xen first looks for a ring with id.addr==dst
> + * and id.partner==sending_domain if that fails it looks for id.addr==dst and
> + * id.partner==DOMID_ANY.
> + * message_type is the 32 bit number used from the message
> + * most likely V4V_MESSAGE_DGRAM or V4V_MESSAGE_STREAM. If insufficient space exists
> + * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
> + * sufficient space becomes available
> + *
> + * do_v4v_op(V4VOP_sendv,
> + *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
> + *           XEN_GUEST_HANDLE(v4v_iov_t) iov,
> + *           uint32_t niov,
> + *           uint32_t message_type)
> + */
> +#define V4VOP_sendv		5

Instead of having the message_type part of each ring_message_header and 
in the sendv hypercall,
I wonder if this would make more sense to register the ring with a 
message type (as a "tag"),
so that ring are addressed by a 3-tuple (domain,port,message_type) 
instead of a 2-tuple (domain,port),
which make a ring only able to receive strictly one message type.

It could have the following benefits:

* v4v_addr's .pad becomes the message type.
* the message_type become less important for the hypervisor, it's just 
the same as a port.
* the message_header is 4 byte shorter and the guest doesn't have to 
sort message type itself.
* it could be useful to handle priority on rings at guest level for 
specific message type.
* guests doesn't receive message type that it doesn't expect on a ring.
* the source automatically get a connection refused if a guest is not 
handling a specific message type.
* the firewall can filter on message type as it's part of the v4v_addr.

-- 
Vincent