DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 47D0521EAD
Date: Fri, 15 Sep 2017 16:00:29 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: xen-devel@lists.xen.org
cc: linux-kernel@vger.kernel.org, sstabellini@kernel.org, jgross@suse.com,
        boris.ostrovsky@oracle.com
Subject: [PATCH v4 00/13] introduce the Xen PV Calls frontend
Message-ID: <alpine.DEB.2.10.1709121550270.9439@sstabellini-ThinkPad-X260>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4051
Lines: 93

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