search for: svm_famili

Split the vSockets header into kernel and UAPI parts. The former gets the bits that used to be in __KERNEL__ guards, while the latter gets everything that is user-visible. Tested by compiling vsock (+transport) and a simple user-mode vSockets application. Reported-by: David Howells <dhowells at redhat.com> Acked-by: Dmitry Torokhov <dtor at vmware.com> Signed-off-by: Andy King

Split the vSockets header into kernel and UAPI parts. The former gets the bits that used to be in __KERNEL__ guards, while the latter gets everything that is user-visible. Tested by compiling vsock (+transport) and a simple user-mode vSockets application. Reported-by: David Howells <dhowells at redhat.com> Acked-by: Dmitry Torokhov <dtor at vmware.com> Signed-off-by: Andy King

The vsock_diag.ko module already has a test suite but the core AF_VSOCK functionality has no tests. This patch series adds several test cases that exercise AF_VSOCK SOCK_STREAM socket semantics (send/recv, connect/accept, half-closed connections, simultaneous connections). Stefan: Do you think we should have a single application or is better to split it in single tests (e.g.

On 10/18/19 10:39 AM, Richard W.M. Jones wrote: > This adds a new API for connecting to AF_VSOCK protocol > (https://wiki.qemu.org/Features/VirtioVsock). > > For example: > > nbd_connect_vsock (nbd, 2, 10809); > > There is no test of this feature because it only works between guest > and host. You cannot start a server and client on the host and talk > between

The vsock_diag.ko module already has a test suite but the core AF_VSOCK functionality has no tests. This patch series adds several test cases that exercise AF_VSOCK SOCK_STREAM socket semantics (send/recv, connect/accept, half-closed connections, simultaneous connections). The v1 of this series was originally sent by Stefan. v3: - Patch 6: * check the byte received in the recv_byte() * use

On Fri, Oct 18, 2019 at 10:58:43AM -0500, Eric Blake wrote: > On 10/18/19 10:39 AM, Richard W.M. Jones wrote: > >+Connect (synchronously) over the C<AF_VSOCK> protocol from a > >+virtual machine to an NBD server, usually running on the host. The > >+C<cid> and C<port> parameters specify the server address. Usually > >+C<cid> should be C<2>

This is a series of patches to libnbd and nbdkit adding AF_VSOCK support. On the host side it allows you to start an nbdkit instance which listens on a virtio-vsock socket: $ ./nbdkit -fv --vsock memory 1G ... nbdkit: debug: bound to vsock 2:10809 On the guest side you can then use libnbd to connect to the server: $ ./run nbdsh -c 'h.connect_vsock(2, 10809)' -c

From: Stefan Hajnoczi <stefanha at redhat.com> The vsock_test.c program runs a test suite of AF_VSOCK test cases. Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- v2: * Drop unnecessary includes [Stefan] * Aligned with the current SPDX [Stefano] * Set MULTICONN_NFDS to 100 [Stefano] * Change (i % 1) in (i

This adds a new API for connecting to AF_VSOCK protocol (https://wiki.qemu.org/Features/VirtioVsock). For example: nbd_connect_vsock (nbd, 2, 10809); There is no test of this feature because it only works between guest and host. You cannot start a server and client on the host and talk between them, which is what we'd need to write a sane test. --- configure.ac | 2 ++

Hi Stefan, I'm thinking about dividing this test into single applications, one for each test, do you think it makes sense? Or is it just a useless complication? Thanks, Stefano On Thu, Aug 1, 2019 at 5:27 PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > From: Stefan Hajnoczi <stefanha at redhat.com> > > The vsock_test.c program runs a test suite of AF_VSOCK

Hi Stefan, I'm thinking about dividing this test into single applications, one for each test, do you think it makes sense? Or is it just a useless complication? Thanks, Stefano On Thu, Aug 1, 2019 at 5:27 PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > From: Stefan Hajnoczi <stefanha at redhat.com> > > The vsock_test.c program runs a test suite of AF_VSOCK

On platforms which support it (only Linux currently) nbdkit can act as a vsock server. Guests running on the host see a raw NBD socket which it can connect to by opening an AF_VSOCK connection. (Although only libnbd supports this). The current limitations are: * nbdkit can only act as a host (cid == VMADDR_CID_HOST == 2). * There is no access control. Any guest which has vsock enabled can

v1 was discussed here: https://www.redhat.com/archives/libguestfs/2019-October/thread.html#00100 v2: - Bind to VMADDR_CID_ANY (instead of HOST) and update the documentation accordingly. - Don't bother with SOCK_CLOEXEC fallback path that can never be used. Rich.

This is a series of patches to libnbd and nbdkit adding AF_VSOCK support. On the host side it allows you to start an nbdkit instance which listens on a virtio-vsock socket: $ ./nbdkit -fv --vsock memory 1G ... nbdkit: debug: bound to vsock 2:10809 On the guest side you can then use libnbd to connect to the server: $ ./run nbdsh -c 'h.connect_vsock(2, 10809)' -c

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a "complex macro" in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * *

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a "complex macro" in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * *

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in

From: Andy King <acking at vmware.com> ** Introduce VM Sockets *** In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vmw_vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. Unlike previous

From: Andy King <acking at vmware.com> ** Introduce VM Sockets *** In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vmw_vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. Unlike previous