[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH v4 00/13] introduce the Xen PV Calls frontend
Hi all, this series introduces the frontend for the newly introduced PV Calls procotol. PV Calls is a paravirtualized protocol that allows the implementation of a set of POSIX functions in a different domain. The PV Calls frontend sends POSIX function calls to the backend, which implements them and returns a value to the frontend and acts on the function call. For more information about PV Calls, please read: https://xenbits.xen.org/docs/unstable/misc/pvcalls.html This patch series only implements the frontend driver. It doesn't attempt to redirect POSIX calls to it. The functions exported in pvcalls-front.h are meant to be used for that. A separate patch series will be sent to use them and hook them into the system. Changes in v4: In this version of the series I introduced a global refcount to keep track of outstanding users of the pvcalls functions. refcount is increased on entering a pvcalls frontend function and is decreased on returning from it. This is necessary to figure out the right time to deallocate pvcalls frontend resources in pvcalls_front_remove. A similar, more limited, issue affects pvcalls_front_release: it needs to find out the right time to free a single active socket mapping. The outstanding users are sendmsg and recvmsg. Instead of adding another refcount, I am reusing the existing in_mutex and out_mutex to find out if there are outstanding users of the socket mapping. It is safe because we know that there cannot be any new sendmsg and recvmsg callers not already waiting for one of the two mutexes. - introduce pvcalls_refcount to avoid removing data structs that are still in-use - set pvcalls_front_dev to NULL first in pvcalls_front_remove - use mutex_trylock to check the state of in_mutex and out_mutex before freeing a map in pvcalls_front_release - rename pvcallss_lock to socket_lock - add a comment on XENBUS_FUNCTIONS_CALLS - fix the irq check to >= 0 - initialize socket_mappings in pvcalls_front_probe so that pvcalls_front_remove can deal with it properly - use IPPROTO_IP - free new mapping in pvcalls_front_socket in case of errors - no need to zero map->active.ring twice - use PVCALLS_RING_ORDER instead of map->active.ring->ring_order - set *evtchn to -1 at the beginning of create_active - don't free map in create_active in case of errors, it should be freed by a release command - add reviewed-bys - free map2 in case of errors in pvcalls_front_accept - properly unlock in error paths in pvcalls_front_accept - make pvcalls_front_write_todo return bool - move the error check before the barrier in __write_ring - add a check "len >= INT_MAX" in pvcalls_front_sendmsg - make the len parameter of __write_ring an int - don't initialize sent in pvcalls_front_sendmsg - make the error value for sk_send_head being zero consistent - don't initialize ret in pvcalls_front_recvmsg - unbind_from_irqhandler before doing anything else in pvcalls_front_free_map - move the "sock->sk == NULL" check before bedata access in pvcalls_front_release - no need to use READ/WRITE_ONCE to access sk_send_head Stefano Stabellini (13): xen/pvcalls: introduce the pvcalls xenbus frontend xen/pvcalls: implement frontend disconnect xen/pvcalls: connect to the backend xen/pvcalls: implement socket command and handle events xen/pvcalls: implement connect command xen/pvcalls: implement bind command xen/pvcalls: implement listen command xen/pvcalls: implement accept command xen/pvcalls: implement sendmsg xen/pvcalls: implement recvmsg xen/pvcalls: implement poll command xen/pvcalls: implement release command xen: introduce a Kconfig option to enable the pvcalls frontend drivers/xen/Kconfig | 9 + drivers/xen/Makefile | 1 + drivers/xen/pvcalls-front.c | 1273 +++++++++++++++++++++++++++++++++++++++++++ drivers/xen/pvcalls-front.h | 28 + 4 files changed, 1311 insertions(+) create mode 100644 drivers/xen/pvcalls-front.c create mode 100644 drivers/xen/pvcalls-front.h _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |