lkml.org 
[lkml]   [2020]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH net-next 0/3] vsock: support network namespace
On Mon, Apr 27, 2020 at 10:31:57AM -0400, Michael S. Tsirkin wrote:
> On Mon, Apr 27, 2020 at 04:25:18PM +0200, Stefano Garzarella wrote:
> > Hi David, Michael, Stefan,
> > I'm restarting to work on this topic since Kata guys are interested to
> > have that, especially on the guest side.
> >
> > While working on the v2 I had few doubts, and I'd like to have your
> > suggestions:
> >
> > 1. netns assigned to the device inside the guest
> >
> > Currently I assigned this device to 'init_net'. Maybe it is better
> > if we allow the user to decide which netns assign to the device
> > or to disable this new feature to have the same behavior as before
> > (host reachable from any netns).
> > I think we can handle this in the vsock core and not in the single
> > transports.
> >
> > The simplest way that I found, is to add a new
> > IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS to /dev/vsock to enable the feature
> > and assign the device to the same netns of the process that do the
> > ioctl(), but I'm not sure it is clean enough.
> >
> > Maybe it is better to add new rtnetlink messages, but I'm not sure if
> > it is feasible since we don't have a netdev device.
> >
> > What do you suggest?
>
> Maybe /dev/vsock-netns here too, like in the host?
>

I'm not sure I get it.

In the guest, /dev/vsock is only used to get the CID assigned to the
guest through an ioctl().

In the virtio-vsock case, the guest transport is loaded when it is discovered
on the PCI bus, so we need a way to "move" it to a netns or to specify
which netns should be used when it is probed.

>
> >
> > 2. netns assigned in the host
> >
> > As Michael suggested, I added a new /dev/vhost-vsock-netns to allow
> > userspace application to use this new feature, leaving to
> > /dev/vhost-vsock the previous behavior (guest reachable from any
> > netns).
> >
> > I like this approach, but I had these doubts:
> >
> > - I need to allocate a new minor for that device (e.g.
> > VHOST_VSOCK_NETNS_MINOR) or is there an alternative way that I can
> > use?
>
> Not that I see. I agree it's a bit annoying. I'll think about it a bit.
>

Thanks for that!
An idea that I had, was to add a new ioctl to /dev/vhost-vsock to enable
the netns support, but I'm not sure it is a clean approach.

> > - It is vhost-vsock specific, should we provide something handled in
> > the vsock core, maybe centralizing the CID allocation and adding a
> > new IOCTL or rtnetlink message like for the guest side?
> > (maybe it could be a second step, and for now we can continue with
> > the new device)
> >

Thanks,
Stefano

\
 
 \ /
  Last update: 2020-04-27 17:22    [W:0.095 / U:3.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site