> From: Stefano Garzarella [mailto:sgarzare@xxxxxxxxxx] > > +/* Assign a transport to a socket and call the .init transport callback. > > + * > > + * Note: for stream socket this must be called when vsk->remote_addr > > +is set > > + * (e.g. during the connect() or when a connection request on a > > +listener > > + * socket is received). > > + * The vsk->remote_addr is used to decide which transport to use: > > + * - remote CID > VMADDR_CID_HOST will use host->guest transport > > + * - remote CID <= VMADDR_CID_HOST will use guest->host transport > > +*/ int vsock_assign_transport(struct vsock_sock *vsk, struct > > +vsock_sock *psk) { > > + const struct vsock_transport *new_transport; > > + struct sock *sk = sk_vsock(vsk); > > + > > + switch (sk->sk_type) { > > + case SOCK_DGRAM: > > + new_transport = transport_dgram; > > + break; > > + case SOCK_STREAM: > > + if (vsk->remote_addr.svm_cid > VMADDR_CID_HOST) > > + new_transport = transport_h2g; > > + else > > + new_transport = transport_g2h; > > I 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. As far as I can tell, we have the same issue with the current support for nested VMs in VMCI. If we have an L2 guest with the same CID as the L1 guest, we will always send to the L2 guest, and we may assign an L2 guest the same CID as L1. It should be straight forward to avoid this, though. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
