[lkml]   [2017]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH v4 00/13] introduce the Xen PV Calls frontend
Hi all,

this series introduces the frontend for the newly introduced PV Calls

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:

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
- 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
- move the "sock->sk == NULL" check before bedata access in
- 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

 \ /
  Last update: 2017-09-16 01:00    [W:0.272 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site