Re: [Xen-devel] [DRAFT v4] PV Calls protocol design document (former XenSock)

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Aug 02, 2016 at 05:35:08PM -0700, Stefano Stabellini wrote:
> Hi all,
> 
> This is the design document of the PV Calls protocol. You can find
> prototypes of the Linux frontend and backend drivers here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-4
> 
> To use them, make sure to enable CONFIG_PVCALLS in your kernel config
> and add "pvcalls=1" to the command line of your DomU Linux kernel. You
> also need the toolstack to create the initial xenstore nodes for the
> protocol. To do that, please apply the attached patch to libxl (the
> patch is based on Xen 4.7.0-rc3) and add "pvcalls=1" to your DomU config
> file.
> 
> Note that previous versions of the protocols were named XenSock. It has
> been renamed for clarity of scope and to avoid confusion with hv_sock
> and vsock, which are used for inter-VMs communications.
> 
> Cheers,
> 
> Stefano
> 
> Changes in v4:
> - rename xensock to pvcalls
> 
> Changes in v3:
> - add a dummy element to struct xen_xensock_request to make sure the
>   size of the struct is the same on both x86_32 and x86_64
> 
> Changes in v2:
> - add max-dataring-page-order
> - add "Publish backend features and transport parameters" to backend
>   xenbus workflow
> - update new cmd values
> - update xen_xensock_request
> - add backlog parameter to listen and binary layout
> - add description of new data ring format (interface+data)
> - modify connect and accept to reflect new data ring format
> - add link to POSIX docs
> - add error numbers
> - add address format section and relevant numeric definitions
> - add explicit mention of unimplemented commands
> - add protocol node name
> - add xenbus shutdown diagram
> - add socket operation
> 
> ---
> 
> # PV Calls Protocol
> 
> ## Rationale
> 
> PV Calls is a paravirtualized protocol for the POSIX socket API.
> 
> The purpose of PV Calls is to allow the implementation of a specific set
> of POSIX functions to be done in a domain other than your own. It allows
> connect, accept, bind, release, listen, poll, recvmsg and sendmsg to be
> implemented in another domain.
> 

The wording isn't really clear here. This design document as-is would
inevitably make people start to compare PV Calls to various HV socks I'm
afraid.

Is PV Calls going to cover other stuff other than socket API? If it
targets POSIX interfaces, maybe call it PV POSIX?

But then, if you extend the scope to cover POSIX APIs, I think you might
want some discovery mechanism to see what APIs are paravirtualised?

Wei.

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