search for: vsock_find_cid

...just noticed that this break the loopback in the guest. As a fix, we should use 'transport_g2h' when remote_cid <= VMADDR_CID_HOST or remote_cid is the id of 'transport_g2h'. To do that we also need to avoid that L2 guests can have the same CID of L1. For vhost_vsock I can call vsock_find_cid() in vhost_vsock_set_cid() @Jorgen: for vmci we need to do the same? or it is guaranteed, since it's already support nested VMs, that a L2 guests cannot have the same CID as the L1. I'll send a v2 with this fix, but I'll wait a bit for other comments. Thanks, Stefano

...just noticed that this break the loopback in the guest. As a fix, we should use 'transport_g2h' when remote_cid <= VMADDR_CID_HOST or remote_cid is the id of 'transport_g2h'. To do that we also need to avoid that L2 guests can have the same CID of L1. For vhost_vsock I can call vsock_find_cid() in vhost_vsock_set_cid() @Jorgen: for vmci we need to do the same? or it is guaranteed, since it's already support nested VMs, that a L2 guests cannot have the same CID as the L1. I'll send a v2 with this fix, but I'll wait a bit for other comments. Thanks, Stefano

...reak the loopback in the guest. > As a fix, we should use 'transport_g2h' when remote_cid <= > VMADDR_CID_HOST or remote_cid is the id of 'transport_g2h'. > > To do that we also need to avoid that L2 guests can have the same CID of L1. > For vhost_vsock I can call vsock_find_cid() in vhost_vsock_set_cid() > > @Jorgen: for vmci we need to do the same? or it is guaranteed, since it's > already support nested VMs, that a L2 guests cannot have the same CID as > the L1. As far as I can tell, we have the same issue with the current support for nested VMs in VMC...

...k); > + vsk->transport->destruct(vsk); > + } > + > + if (!new_transport) > + return -ENODEV; > + > + vsk->transport = new_transport; > + > + return vsk->transport->init(vsk, psk); } > +EXPORT_SYMBOL_GPL(vsock_assign_transport); > + > +static bool vsock_find_cid(unsigned int cid) { > + if (transport_g2h && cid == transport_g2h->get_local_cid()) > + return true; > + > + if (transport_h2g && cid == VMADDR_CID_HOST) > + return true; > + > + return false; > +} > + > static struct sock *vsock_dequeue_accept(st...

...k); > + vsk->transport->destruct(vsk); > + } > + > + if (!new_transport) > + return -ENODEV; > + > + vsk->transport = new_transport; > + > + return vsk->transport->init(vsk, psk); } > +EXPORT_SYMBOL_GPL(vsock_assign_transport); > + > +static bool vsock_find_cid(unsigned int cid) { > + if (transport_g2h && cid == transport_g2h->get_local_cid()) > + return true; > + > + if (transport_h2g && cid == VMADDR_CID_HOST) > + return true; > + > + return false; > +} > + > static struct sock *vsock_dequeue_accept(st...

...->remote_addr.svm_cid > VMADDR_CID_HOST) { vsk->transport = transport_h2g; - else + if (!vsk->transport) + vsk->transport = transport_hg; + } else { vsk->transport = transport_g2h; + } break; default: return -ESOCKTNOSUPPORT; @@ -423,7 +428,7 @@ static bool vsock_find_cid(unsigned int cid) if (transport_g2h && cid == transport_g2h->get_local_cid()) return true; - if (transport_h2g && cid == VMADDR_CID_HOST) + if ((transport_h2g || transport_hg) && cid == VMADDR_CID_HOST) return true; return false; @@ -1997,6 +2002,8 @@ static...

Hi, now that we have multi-transport upstream, I started to take a look to support network namespace (netns) in vsock. As we partially discussed in the multi-transport proposal [1], it could be nice to support network namespace in vsock to reach the following goals: - isolate host applications from guest applications using the same ports with CID_ANY - assign the same CID of VMs running in

Hi, now that we have multi-transport upstream, I started to take a look to support network namespace (netns) in vsock. As we partially discussed in the multi-transport proposal [1], it could be nice to support network namespace in vsock to reach the following goals: - isolate host applications from guest applications using the same ports with CID_ANY - assign the same CID of VMs running in

...t;init(vsk, psk); } EXPORT_SYMBOL_GPL(vsock_assign_transport); +static void vsock_deassign_transport(struct vsock_sock *vsk) +{ + if (!vsk->transport) + return; + + vsk->transport->destruct(vsk); + module_put(vsk->transport->module); + vsk->transport = NULL; +} + static bool vsock_find_cid(unsigned int cid) { if (transport_g2h && cid == transport_g2h->get_local_cid()) @@ -728,8 +743,7 @@ static void vsock_sk_destruct(struct sock *sk) { struct vsock_sock *vsk = vsock_sk(sk); - if (vsk->transport) - vsk->transport->destruct(vsk); + vsock_deassign_transport(...

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

...nsport) + return 0; + + vsk->transport->release(vsk); + vsk->transport->destruct(vsk); + } + + if (!new_transport) + return -ENODEV; + + vsk->transport = new_transport; + + return vsk->transport->init(vsk, psk); +} +EXPORT_SYMBOL_GPL(vsock_assign_transport); + +static bool vsock_find_cid(unsigned int cid) +{ + if (transport_g2h && cid == transport_g2h->get_local_cid()) + return true; + + if (transport_h2g && cid == VMADDR_CID_HOST) + return true; + + return false; +} + static struct sock *vsock_dequeue_accept(struct sock *listener) { struct vsock_sock *vlis...

...T) + vsk->transport = transport_h2g; + else + vsk->transport = transport_g2h; + break; + default: + return -ESOCKTNOSUPPORT; + } + + if (!vsk->transport) + return -ENODEV; + + return vsk->transport->init(vsk, psk); +} +EXPORT_SYMBOL_GPL(vsock_assign_transport); + +static bool vsock_find_cid(unsigned int cid) +{ + if (transport_g2h && cid == transport_g2h->get_local_cid()) + return true; + + if (transport_h2g && cid == VMADDR_CID_HOST) + return true; + + return false; +} + static struct sock *vsock_dequeue_accept(struct sock *listener) { struct vsock_sock *vlis...

...gt; + } > > + > > + if (!new_transport) > > + return -ENODEV; > > + > > + vsk->transport = new_transport; > > + > > + return vsk->transport->init(vsk, psk); } > > +EXPORT_SYMBOL_GPL(vsock_assign_transport); > > + > > +static bool vsock_find_cid(unsigned int cid) { > > + if (transport_g2h && cid == transport_g2h->get_local_cid()) > > + return true; > > + > > + if (transport_h2g && cid == VMADDR_CID_HOST) > > + return true; > > + > > + return false; > > +} > > + >...

Most of the patches are reviewed by Dexuan, Stefan, and Jorgen. The following patches need reviews: - [11/15] vsock: add multi-transports support - [12/15] vsock/vmci: register vmci_transport only when VMCI guest/host are active - [15/15] vhost/vsock: refuse CID assigned to the guest->host transport RFC: https://patchwork.ozlabs.org/cover/1168442/ v1:

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html 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. Before this series, vmci-transport supported this behavior but only using

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html 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. Before this series, vmci-transport supported this behavior but only using

..._transport) > > > + return -ENODEV; > > > + > > > + vsk->transport = new_transport; > > > + > > > + return vsk->transport->init(vsk, psk); } > > > +EXPORT_SYMBOL_GPL(vsock_assign_transport); > > > + > > > +static bool vsock_find_cid(unsigned int cid) { > > > + if (transport_g2h && cid == transport_g2h->get_local_cid()) > > > + return true; > > > + > > > + if (transport_h2g && cid == VMADDR_CID_HOST) > > > + return true; > > > + > > > + return f...

..._transport) > > > + return -ENODEV; > > > + > > > + vsk->transport = new_transport; > > > + > > > + return vsk->transport->init(vsk, psk); } > > > +EXPORT_SYMBOL_GPL(vsock_assign_transport); > > > + > > > +static bool vsock_find_cid(unsigned int cid) { > > > + if (transport_g2h && cid == transport_g2h->get_local_cid()) > > > + return true; > > > + > > > + if (transport_h2g && cid == VMADDR_CID_HOST) > > > + return true; > > > + > > > + return f...

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html 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. Before this series, vmci-transport supported this behavior but only using VMware

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html 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. Before this series, vmci-transport supported this behavior but only using VMware