search for: vmaddr_cid_local

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Tuesday, November 19, 2019 12:01 PM > > The VMADDR_CID_RESERVED (1) was used by VMCI, but now it is not > used anymore, so we can reuse it for local communication > (loopback) adding the new well-know CID: VMADDR_CID_LOCAL. > > Cc: Jorgen Hansen <jhansen at vmware.com> > Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> > --- > include/uapi/linux/vm_sockets.h | 8 +++++--- > net/vmw_vsock/vmci_transport.c | 2 +- > 2 files changed, 6 insertions(+), 4 deletions(-) > &gt...

...his behavior, > but only in the guest. > We are moving the loopback handling in a new transport, because it > might be useful to provide this feature also in the host or when > no H2G/G2H transports (hyperv, virtio, vmci) are loaded. > > The user can use the loopback with the new VMADDR_CID_LOCAL (that > replaces VMADDR_CID_RESERVED) in any condition. > Otherwise, if the G2H transport is loaded, it can also use the guest > local CID as previously supported by vmci and virtio transports. > If G2H transport is not loaded, the user can also use VMADDR_CID_HOST > for local commun...

...his behavior, > but only in the guest. > We are moving the loopback handling in a new transport, because it > might be useful to provide this feature also in the host or when > no H2G/G2H transports (hyperv, virtio, vmci) are loaded. > > The user can use the loopback with the new VMADDR_CID_LOCAL (that > replaces VMADDR_CID_RESERVED) in any condition. > Otherwise, if the G2H transport is loaded, it can also use the guest > local CID as previously supported by vmci and virtio transports. > If G2H transport is not loaded, the user can also use VMADDR_CID_HOST > for local commun...

...his behavior, > but only in the guest. > We are moving the loopback handling in a new transport, because it > might be useful to provide this feature also in the host or when > no H2G/G2H transports (hyperv, virtio, vmci) are loaded. > > The user can use the loopback with the new VMADDR_CID_LOCAL (that > replaces VMADDR_CID_RESERVED) in any condition. > Otherwise, if the G2H transport is loaded, it can also use the guest > local CID as previously supported by vmci and virtio transports. > If G2H transport is not loaded, the user can also use VMADDR_CID_HOST > for local commun...

v2: - style fixes [Dave] - removed RCU sync and changed 'the_vsock_loopback' in a global static variable [Stefan] - use G2H transport when local transport is not loaded and remote cid is VMADDR_CID_LOCAL [Stefan] - rebased on net-next v1: https://patchwork.kernel.org/cover/11251735/ This series introduces a new transport (vsock_loopback) to handle local communication. This could be useful to test vsock core itself and to allow developers to test their applications without launching a VM. Before...

...ly in the guest. > > We are moving the loopback handling in a new transport, because it > > might be useful to provide this feature also in the host or when > > no H2G/G2H transports (hyperv, virtio, vmci) are loaded. > > > > The user can use the loopback with the new VMADDR_CID_LOCAL (that > > replaces VMADDR_CID_RESERVED) in any condition. > > Otherwise, if the G2H transport is loaded, it can also use the guest > > local CID as previously supported by vmci and virtio transports. > > If G2H transport is not loaded, the user can also use VMADDR_CID_HOST &...

...nbd, and I can > report that it appears to work fine. > > https://github.com/libguestfs/nbdkit/commit/5e4745641bb4676f607fdb3f8750dbf6e9516877 > I'm happy that it works and it is useful :-) Thanks again for the suggestion! Just a note, Linux >= 5.6 supports a new special cid (VMADDR_CID_LOCAL = 1) to use the loopback mode in any condition (host, guest, nested guest). Cheers, Stefano

...t; I've tried, and it seems not. Only for datagrams - not for stream sockets. > Also vhost-vsock doesn't support it, but virtio-vsock does. > > > > > > > Since several people asked about this feature at the KVM Forum, I would > like > > > to add a new VMADDR_CID_LOCAL (i.e. using the reserved 1) and > implement > > > loopback in the core. > > > > > > What do you think? > > > > What kind of use cases are mentioned in the KVM forum for loopback? > One concern > > is that we have to maintain yet another interproces...

...are in a nested > VM environment we are in trouble. If both src and dst CID are CID_HOST, we should be fairly sure that this Is host loopback, no? If src is anything else, we would do G2H. > > Since several people asked about this feature at the KVM Forum, I would like > to add a new VMADDR_CID_LOCAL (i.e. using the reserved 1) and implement > loopback in the core. > > What do you think? What kind of use cases are mentioned in the KVM forum for loopback? One concern is that we have to maintain yet another interprocess communication mechanism, even though other choices exist already...

...are in a nested > VM environment we are in trouble. If both src and dst CID are CID_HOST, we should be fairly sure that this Is host loopback, no? If src is anything else, we would do G2H. > > Since several people asked about this feature at the KVM Forum, I would like > to add a new VMADDR_CID_LOCAL (i.e. using the reserved 1) and implement > loopback in the core. > > What do you think? What kind of use cases are mentioned in the KVM forum for loopback? One concern is that we have to maintain yet another interprocess communication mechanism, even though other choices exist already...

...rs to work fine. > > > > https://github.com/libguestfs/nbdkit/commit/5e4745641bb4676f607fdb3f8750dbf6e9516877 > > > > I'm happy that it works and it is useful :-) > Thanks again for the suggestion! > > Just a note, Linux >= 5.6 supports a new special cid (VMADDR_CID_LOCAL = 1) > to use the loopback mode in any condition (host, guest, nested guest). Good idea - fixed in the following commit. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists...

The AF_VSOCK protocol added in Linux 5.6 uses a 32 bit port number. For NBD we map this to simple URIs[1] like nbd+vsock://CID:PORT (where CID is a number that acts a bit like a hostname and PORT is a 32 bit port number). eg: nbd+vsock://1:1000000000/ would be port 10^9 on the loopback address VMADDR_CID_LOCAL (== 1). The problem is that libxml2 arbitrarily limits port numbers to 999,999,999. I don't see any support for this limit in RFC 3986 [2]. Here is the code: https://github.com/GNOME/libxml2/blob/46837d47d59c7b8c9bd1d08a6a717a90a7f1ceb6/uri.c#L333 It doesn't even return an error, jus...

...ck.sh @@ -57,16 +57,25 @@ files="vsock.pid" rm -f $files cleanup_fn rm -f $files -# Run nbdkit. -start_nbdkit -P vsock.pid --vsock --port $port memory 1M - -export port -nbdsh -c - <<'EOF' +# An nbdsh script for connecting to vsock +export connect=' import os # 1 = VMADDR_CID_LOCAL h.connect_vsock (1, int (os.environ["port"])) +' +export check=' size = h.get_size () assert size == 1048576 -EOF +' + +# Run nbdkit. +start_nbdkit -P vsock.pid --vsock --port $port memory 1M + +export port +nbdsh -c "$connect" -c "$check" + +# Repeat o...

...host could also do loopback. IIUC we don't support loopback in the host, because in this case the application will use the CID_HOST as address, but if we are in a nested VM environment we are in trouble. Since several people asked about this feature at the KVM Forum, I would like to add a new VMADDR_CID_LOCAL (i.e. using the reserved 1) and implement loopback in the core. What do you think? > If we select transport during bind to a specific CID, this comment Also in this case, are you talking about the peer that will call connect()? > Isn't relevant, but otherwise, we should look at the lo...

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Wednesday, October 23, 2019 11:56 AM Thanks a lot for working on this! > With the multi-transports support, we can use vsock with nested VMs (using > also different hypervisors) loading both guest->host and > host->guest transports at the same time. > > Major changes: > - vsock core module can be

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Wednesday, October 23, 2019 11:56 AM Thanks a lot for working on this! > With the multi-transports support, we can use vsock with nested VMs (using > also different hypervisors) loading both guest->host and > host->guest transports at the same time. > > Major changes: > - vsock core module can be

...in the man page. But I have a question: Does vmci support the host loopback? I've tried, and it seems not. Also vhost-vsock doesn't support it, but virtio-vsock does. > > > > Since several people asked about this feature at the KVM Forum, I would like > > to add a new VMADDR_CID_LOCAL (i.e. using the reserved 1) and implement > > loopback in the core. > > > > What do you think? > > What kind of use cases are mentioned in the KVM forum for loopback? One concern > is that we have to maintain yet another interprocess communication mechanism, > even t...

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