From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Hanquez Subject: Re: [PATCH (V9) 2/2] xen: Add V4V implementation Date: Wed, 29 May 2013 10:56:10 +0100 Message-ID: <51A5D0BA.2060701@citrix.com> References: <1369770211-4509-1-git-send-email-ross.philipson@citrix.com> <1369770211-4509-3-git-send-email-ross.philipson@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1369770211-4509-3-git-send-email-ross.philipson@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ross Philipson Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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