Re: [Xen-devel] [DRAFT v3] XenSock protocol design document
On Thu, 28 Jul 2016, Sander Eikelenboom wrote: > Thursday, July 28, 2016, 8:11:53 PM, you wrote: > > > ping > > Hi Stefano, > > JFYI: > Since this doesn't seem to be checked with the upstream kernel yet, > I don't know if you are aware of the opinions expressed upstream > about the proposed Hyper-V socket patches: > http://lkml.iu.edu/hypermail/linux/kernel/1607.3/01748.html > > (and if that should either influence your design or design process) Thanks Sander, I am aware of that conversation going on. However the problem they have is that hv_sock is similar to vsock (at least in purpose), and the kernel guys would like to see only one option for VM-hypervisor communications. That is understandable. The Xen community had a similar discussion when v4v was proposed (we already had vchan). This is not an inter-VM or VM-hypervisor communication protocol. It cannot be replaced with vsock. They might still dislike xensock and even nack it, but I think it will be for different reasons. On a related topic, I am thinking of renaming xensock to something more like "PVCalls". XenSock is confusing. It encourages comparisons with vsock. xensock sounds like vsock or hv_sock for xen, which is not. In fact in the future there might be a virtio version of this protocol, and still it wouldn't be able to replace virtio-vsock. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [DRAFT v3] XenSock protocol design document
Thursday, July 28, 2016, 8:11:53 PM, you wrote: > ping Hi Stefano, JFYI: Since this doesn't seem to be checked with the upstream kernel yet, I don't know if you are aware of the opinions expressed upstream about the proposed Hyper-V socket patches: http://lkml.iu.edu/hypermail/linux/kernel/1607.3/01748.html (and if that should either influence your design or design process) -- Sander > On Wed, 20 Jul 2016, Stefano Stabellini wrote: >> Hi all, >> >> This is the design document of the XenSock 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 xensock-3 >> >> To use them, make sure to enable CONFIG_XENSOCK in your kernel config >> and add "xensock=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 "xensock=1" to your DomU config >> file. >> >> Cheers, >> >> Stefano >> >> >> 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 >> >> --- >> >> >> # XenSocks Protocol v1 >> >> ## Rationale >> >> XenSocks is a paravirtualized protocol for the POSIX socket API. >> >> The purpose of XenSocks 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. >> >> XenSocks provides the following benefits: >> * guest networking works out of the box with VPNs, wireless networks and >> any other complex configurations on the host >> * guest services listen on ports bound directly to the backend domain IP >> addresses >> * localhost becomes a secure namespace for inter-VMs communications >> * full visibility of the guest behavior on the backend domain, allowing >> for inexpensive filtering and manipulation of any guest calls >> * excellent performance >> >> >> ## Design >> >> ### Xenstore >> >> The frontend and the backend connect to each other exchanging information via >> xenstore. The toolstack creates front and back nodes with state >> XenbusStateInitialising. The protocol node name is **xensock**. There can >> only >> be one XenSock frontend per domain. >> >> Frontend XenBus Nodes >> >> port >> Values: >> >> The identifier of the Xen event channel used to signal activity >> in the ring buffer. >> >> ring-ref >> Values: >> >> The Xen grant reference granting permission for the backend to map >> the sole page in a single page sized ring buffer. >> >> Backend XenBus Nodes >> >> max-dataring-page-order >> Values: >> >> The maximum supported size of the data ring in units of lb(machine >> pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages, etc.). >> >> State Machine >> >> Initialization: >> >> *Front* *Back* >> XenbusStateInitialising XenbusStateInitialising >> - Query virtual device- Query backend device >> properties. identification data. >> - Setup OS device instance. - Publish backend features >> - Allocate and initialize the and transport parameters >> request ring. | >> - Publish transport parameters | >> that will be in effect during V >> this connection.XenbusStateInitWait >> | >> | >> V >>XenbusStateInitialised >> >> - Query frontend transport >> parameters. >> - Connect to the request ring and >> event channel. >> | >> | >> V >>
Re: [Xen-devel] [DRAFT v3] XenSock protocol design document
ping On Wed, 20 Jul 2016, Stefano Stabellini wrote: > Hi all, > > This is the design document of the XenSock 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 xensock-3 > > To use them, make sure to enable CONFIG_XENSOCK in your kernel config > and add "xensock=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 "xensock=1" to your DomU config > file. > > Cheers, > > Stefano > > > 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 > > --- > > > # XenSocks Protocol v1 > > ## Rationale > > XenSocks is a paravirtualized protocol for the POSIX socket API. > > The purpose of XenSocks 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. > > XenSocks provides the following benefits: > * guest networking works out of the box with VPNs, wireless networks and > any other complex configurations on the host > * guest services listen on ports bound directly to the backend domain IP > addresses > * localhost becomes a secure namespace for inter-VMs communications > * full visibility of the guest behavior on the backend domain, allowing > for inexpensive filtering and manipulation of any guest calls > * excellent performance > > > ## Design > > ### Xenstore > > The frontend and the backend connect to each other exchanging information via > xenstore. The toolstack creates front and back nodes with state > XenbusStateInitialising. The protocol node name is **xensock**. There can only > be one XenSock frontend per domain. > > Frontend XenBus Nodes > > port > Values: > > The identifier of the Xen event channel used to signal activity > in the ring buffer. > > ring-ref > Values: > > The Xen grant reference granting permission for the backend to map > the sole page in a single page sized ring buffer. > > Backend XenBus Nodes > > max-dataring-page-order > Values: > > The maximum supported size of the data ring in units of lb(machine > pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages, etc.). > > State Machine > > Initialization: > > *Front* *Back* > XenbusStateInitialising XenbusStateInitialising > - Query virtual device- Query backend device > properties. identification data. > - Setup OS device instance. - Publish backend features > - Allocate and initialize the and transport parameters > request ring. | > - Publish transport parameters | > that will be in effect during V > this connection.XenbusStateInitWait > | > | > V >XenbusStateInitialised > > - Query frontend transport > parameters. > - Connect to the request ring and > event channel. > | > | > V > XenbusStateConnected > > - Query backend device properties. > - Finalize OS virtual device >instance. > | > | > V > XenbusStateConnected > > Once frontend and backend are connected, they have a shared page, which > will is used to exchange messages over a ring, and an event channel, > which is used to send notifications. > > Shutdown: > > *Front**Back* > XenbusStateConnected XenbusStateConnected >
[Xen-devel] [DRAFT v3] XenSock protocol design document
Hi all, This is the design document of the XenSock 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 xensock-3 To use them, make sure to enable CONFIG_XENSOCK in your kernel config and add "xensock=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 "xensock=1" to your DomU config file. Cheers, Stefano 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 --- # XenSocks Protocol v1 ## Rationale XenSocks is a paravirtualized protocol for the POSIX socket API. The purpose of XenSocks 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. XenSocks provides the following benefits: * guest networking works out of the box with VPNs, wireless networks and any other complex configurations on the host * guest services listen on ports bound directly to the backend domain IP addresses * localhost becomes a secure namespace for inter-VMs communications * full visibility of the guest behavior on the backend domain, allowing for inexpensive filtering and manipulation of any guest calls * excellent performance ## Design ### Xenstore The frontend and the backend connect to each other exchanging information via xenstore. The toolstack creates front and back nodes with state XenbusStateInitialising. The protocol node name is **xensock**. There can only be one XenSock frontend per domain. Frontend XenBus Nodes port Values: The identifier of the Xen event channel used to signal activity in the ring buffer. ring-ref Values: The Xen grant reference granting permission for the backend to map the sole page in a single page sized ring buffer. Backend XenBus Nodes max-dataring-page-order Values: The maximum supported size of the data ring in units of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages, etc.). State Machine Initialization: *Front* *Back* XenbusStateInitialising XenbusStateInitialising - Query virtual device- Query backend device properties. identification data. - Setup OS device instance. - Publish backend features - Allocate and initialize the and transport parameters request ring. | - Publish transport parameters | that will be in effect during V this connection.XenbusStateInitWait | | V XenbusStateInitialised - Query frontend transport parameters. - Connect to the request ring and event channel. | | V XenbusStateConnected - Query backend device properties. - Finalize OS virtual device instance. | | V XenbusStateConnected Once frontend and backend are connected, they have a shared page, which will is used to exchange messages over a ring, and an event channel, which is used to send notifications. Shutdown: *Front**Back* XenbusStateConnected XenbusStateConnected | | V XenbusStateClosing - Unmap grants - Unbind evtchns | |
