[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.