| Message ID | 20201201152505.19445-1-andraprs@amazon.com |
|---|---|
| Headers | show |
| Series | vsock: Add flag field in the vsock address | expand |
Hi Andra, On Tue, Dec 01, 2020 at 05:25:02PM +0200, Andra Paraschiv wrote: >vsock enables communication between virtual machines and the host they are >running on. Nested VMs can be setup to use vsock channels, as the multi >transport support has been available in the mainline since the v5.5 Linux kernel >has been released. > >Implicitly, if no host->guest vsock transport is loaded, all the vsock packets >are forwarded to the host. This behavior can be used to setup communication >channels between sibling VMs that are running on the same host. One example can >be the vsock channels that can be established within AWS Nitro Enclaves >(see Documentation/virt/ne_overview.rst). > >To be able to explicitly mark a connection as being used for a certain use case, >add a flag field in the vsock address data structure. The "svm_reserved1" field >has been repurposed to be the flag field. The value of the flag will then be >taken into consideration when the vsock transport is assigned. > >This way can distinguish between nested VMs / local communication and sibling >VMs use cases. And can also setup one or more types of communication at the same >time. Thanks to work on this, I've left you a few comments, but I think this is the right way to support nested and sibling communication together. Thank you, Stefano
On 01/12/2020 18:27, Stefano Garzarella wrote: > > > Hi Andra, > > On Tue, Dec 01, 2020 at 05:25:02PM +0200, Andra Paraschiv wrote: >> vsock enables communication between virtual machines and the host >> they are >> running on. Nested VMs can be setup to use vsock channels, as the multi >> transport support has been available in the mainline since the v5.5 >> Linux kernel >> has been released. >> >> Implicitly, if no host->guest vsock transport is loaded, all the >> vsock packets >> are forwarded to the host. This behavior can be used to setup >> communication >> channels between sibling VMs that are running on the same host. One >> example can >> be the vsock channels that can be established within AWS Nitro Enclaves >> (see Documentation/virt/ne_overview.rst). >> >> To be able to explicitly mark a connection as being used for a >> certain use case, >> add a flag field in the vsock address data structure. The >> "svm_reserved1" field >> has been repurposed to be the flag field. The value of the flag will >> then be >> taken into consideration when the vsock transport is assigned. >> >> This way can distinguish between nested VMs / local communication and >> sibling >> VMs use cases. And can also setup one or more types of communication >> at the same >> time. > > Thanks to work on this, I've left you a few comments, but I think this > is the right way to support nested and sibling communication together. Hi Stefano, Thanks also for taking time to review and both you and Stefan for sharing an overview of this proposed option. I'm going through the comments and will send out the v2 of the patch series as I have the changes done and validated. Thanks, Andra Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
Hi Andra, On Tue, Dec 01, 2020 at 05:25:02PM +0200, Andra Paraschiv wrote: >vsock enables communication between virtual machines and the host they are >running on. Nested VMs can be setup to use vsock channels, as the multi >transport support has been available in the mainline since the v5.5 Linux kernel >has been released. > >Implicitly, if no host->guest vsock transport is loaded, all the vsock packets >are forwarded to the host. This behavior can be used to setup communication >channels between sibling VMs that are running on the same host. One example can >be the vsock channels that can be established within AWS Nitro Enclaves >(see Documentation/virt/ne_overview.rst). > >To be able to explicitly mark a connection as being used for a certain use case, >add a flag field in the vsock address data structure. The "svm_reserved1" field >has been repurposed to be the flag field. The value of the flag will then be >taken into consideration when the vsock transport is assigned. > >This way can distinguish between nested VMs / local communication and sibling >VMs use cases. And can also setup one or more types of communication at the same >time. > Another thing worth mentioning is that for now it is not supported in vhost-vsock, since we are discarding every packet not addressed to the host. What we should do would be: - add a new IOCTL to vhost-vsock to enable sibling communication, by default I'd like to leave it disabled - allow sibling forwarding only if both guests have sibling communication enabled and we should implement some kind of filtering or network namespace support to allow the communication only between a subset of VMs Do you have plans to work on it? Otherwise I put it in my to-do list and hope I have time to do it (maybe next month). Thanks, Stefano
On 02/12/2020 15:37, Stefano Garzarella wrote: > > Hi Andra, > > On Tue, Dec 01, 2020 at 05:25:02PM +0200, Andra Paraschiv wrote: >> vsock enables communication between virtual machines and the host >> they are >> running on. Nested VMs can be setup to use vsock channels, as the multi >> transport support has been available in the mainline since the v5.5 >> Linux kernel >> has been released. >> >> Implicitly, if no host->guest vsock transport is loaded, all the >> vsock packets >> are forwarded to the host. This behavior can be used to setup >> communication >> channels between sibling VMs that are running on the same host. One >> example can >> be the vsock channels that can be established within AWS Nitro Enclaves >> (see Documentation/virt/ne_overview.rst). >> >> To be able to explicitly mark a connection as being used for a >> certain use case, >> add a flag field in the vsock address data structure. The >> "svm_reserved1" field >> has been repurposed to be the flag field. The value of the flag will >> then be >> taken into consideration when the vsock transport is assigned. >> >> This way can distinguish between nested VMs / local communication and >> sibling >> VMs use cases. And can also setup one or more types of communication >> at the same >> time. >> > > Another thing worth mentioning is that for now it is not supported in > vhost-vsock, since we are discarding every packet not addressed to the > host. Right, thanks for the follow-up. > > What we should do would be: > - add a new IOCTL to vhost-vsock to enable sibling communication, by > default I'd like to leave it disabled > > - allow sibling forwarding only if both guests have sibling > communication enabled and we should implement some kind of filtering > or network namespace support to allow the communication only between a > subset of VMs > > > Do you have plans to work on it? Nope, not yet. But I can take some time in the second part of December / beginning of January for this. And we can catch up in the meantime if there is something blocking or more clarifications are needed to make it work. Thanks, Andra > > > Otherwise I put it in my to-do list and hope I have time to do it (maybe > next month). > > Thanks, > Stefano > Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
On Wed, Dec 02, 2020 at 06:18:15PM +0200, Paraschiv, Andra-Irina wrote: > > >On 02/12/2020 15:37, Stefano Garzarella wrote: >> >>Hi Andra, >> >>On Tue, Dec 01, 2020 at 05:25:02PM +0200, Andra Paraschiv wrote: >>>vsock enables communication between virtual machines and the host >>>they are >>>running on. Nested VMs can be setup to use vsock channels, as the multi >>>transport support has been available in the mainline since the >>>v5.5 Linux kernel >>>has been released. >>> >>>Implicitly, if no host->guest vsock transport is loaded, all the >>>vsock packets >>>are forwarded to the host. This behavior can be used to setup >>>communication >>>channels between sibling VMs that are running on the same host. >>>One example can >>>be the vsock channels that can be established within AWS Nitro Enclaves >>>(see Documentation/virt/ne_overview.rst). >>> >>>To be able to explicitly mark a connection as being used for a >>>certain use case, >>>add a flag field in the vsock address data structure. The >>>"svm_reserved1" field >>>has been repurposed to be the flag field. The value of the flag >>>will then be >>>taken into consideration when the vsock transport is assigned. >>> >>>This way can distinguish between nested VMs / local communication >>>and sibling >>>VMs use cases. And can also setup one or more types of >>>communication at the same >>>time. >>> >> >>Another thing worth mentioning is that for now it is not supported in >>vhost-vsock, since we are discarding every packet not addressed to the >>host. > >Right, thanks for the follow-up. > >> >>What we should do would be: >>- add a new IOCTL to vhost-vsock to enable sibling communication, by >> default I'd like to leave it disabled >> >>- allow sibling forwarding only if both guests have sibling >> communication enabled and we should implement some kind of filtering >> or network namespace support to allow the communication only between a >> subset of VMs >> >> >>Do you have plans to work on it? > >Nope, not yet. But I can take some time in the second part of December >/ beginning of January for this. And we can catch up in the meantime >if there is something blocking or more clarifications are needed to >make it work. > Good, it will be great! Thanks, Stefano
vsock enables communication between virtual machines and the host they are running on. Nested VMs can be setup to use vsock channels, as the multi transport support has been available in the mainline since the v5.5 Linux kernel has been released. Implicitly, if no host->guest vsock transport is loaded, all the vsock packets are forwarded to the host. This behavior can be used to setup communication channels between sibling VMs that are running on the same host. One example can be the vsock channels that can be established within AWS Nitro Enclaves (see Documentation/virt/ne_overview.rst). To be able to explicitly mark a connection as being used for a certain use case, add a flag field in the vsock address data structure. The "svm_reserved1" field has been repurposed to be the flag field. The value of the flag will then be taken into consideration when the vsock transport is assigned. This way can distinguish between nested VMs / local communication and sibling VMs use cases. And can also setup one or more types of communication at the same time. Thank you. Andra --- Patch Series Changelog The patch series is built on top of v5.10-rc6. GitHub repo branch for the latest version of the patch series: * https://github.com/andraprs/linux/tree/vsock-flag-sibling-comm-v1 --- Andra Paraschiv (3): vm_sockets: Include flag field in the vsock address data structure virtio_transport_common: Set sibling VMs flag on the receive path af_vsock: Assign the vsock transport considering the vsock address flag include/uapi/linux/vm_sockets.h | 18 +++++++++++++++++- net/vmw_vsock/af_vsock.c | 15 +++++++++++---- net/vmw_vsock/virtio_transport_common.c | 8 ++++++++ 3 files changed, 36 insertions(+), 5 deletions(-)