Some people asked about getting involved with vhost. Here's a short list of projects. vhost-net driver projects - profiling would be very helpful, I have not done any yet - tap support - working on it now - merged buffers - working on it now - scalability/fairness for large # of guests - working on it now - logging support with dirty page tracking in kernel - working on it now - indirect buffers - worth it? - vm exit mitigation for TX (worth it? naive implementation does not seem to help) - interrupt mitigation for RX - level triggered interrupts - what's the best thing to do here? qemu projects - migration support - level triggered interrupts - what's the best thing to do here? - upstream support for injecting interrupts from kernel, from qemu-kvm.git to qemu.git (this is a vhost dependency, without it vhost can't be upstreamed, or it can, but without real benefit) - general cleanup and upstreaming projects involing networking stack - export socket from tap so vhost can use it - working on it now - extend raw sockets to support GSO/checksum offloading, and teach vhost to use that capability [one way to do this: virtio net header support] will allow working with e.g. macvlan long term projects - multiqueue (involves all of vhost, qemu, virtio, networking stack) - More testing is always good -- MST
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:> vhost-net driver projectsI still think that list should include - UDP multicast socket support - TCP socket support - raw packet socket support for qemu (from Or Gerlitz) if we have those, plus the tap support that is already on your list, we can use vhost-net as a generic offload for the host networking in qemu.> projects involing networking stack > - export socket from tap so vhost can use it - working on it now > - extend raw sockets to support GSO/checksum offloading, > and teach vhost to use that capability > [one way to do this: virtio net header support] > will allow working with e.g. macvlanOne thing I'm planning to work on is bridge support in macvlan, together with VEPA compliant operation, i.e. not sending back multicast frames to the origin. I'll also keep looking into macvtap, though that will be less important once you get the tap socket support running. Arnd <><
On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote:> On Wednesday 16 September 2009, Michael S. Tsirkin wrote: > > > Also, I might not want to allow the user to open a > > > random random raw socket, but only one on a specific downstream > > > port of a macvlan interface, so I can filter out the data from > > > that respective MAC address in an external switch. > > > > I agree. Maybe we can fix that for raw sockets, want me to > > add it to the list? :) > > So far, I could not find any theoretical solution how to fix this,What if socket had a LOCKBIND ioctl after which you can not bind it to any other device? Then someone with RAW capability can open the socket, bind to device and hand it to you. You can send packets but not switch to another device.> but if you think it can be done, it would be good to have it on the > list somewhere. > > Arnd <><
On Thursday 17 September 2009, Michael S. Tsirkin wrote:> On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote: > > On Wednesday 16 September 2009, Michael S. Tsirkin wrote: > > > > Also, I might not want to allow the user to open a > > > > random random raw socket, but only one on a specific downstream > > > > port of a macvlan interface, so I can filter out the data from > > > > that respective MAC address in an external switch. > > > > > > I agree. Maybe we can fix that for raw sockets, want me to > > > add it to the list? :) > > > > So far, I could not find any theoretical solution how to fix this, > > What if socket had a LOCKBIND ioctl after which you can not bind it to > any other device? Then someone with RAW capability can open the socket, > bind to device and hand it to you. You can send packets but not > switch to another device.Could work, though I was hoping for a solution that does not depend on a priviledged task at run time to open the socket, as you have with persistant tap devices or chardevs like macvtap that can have their persissions set by udev. Arnd <><
On Thu, Sep 17, 2009 at 02:14:06PM +0200, Arnd Bergmann wrote:> On Thursday 17 September 2009, Michael S. Tsirkin wrote: > > On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote: > > > On Wednesday 16 September 2009, Michael S. Tsirkin wrote: > > > > > Also, I might not want to allow the user to open a > > > > > random random raw socket, but only one on a specific downstream > > > > > port of a macvlan interface, so I can filter out the data from > > > > > that respective MAC address in an external switch. > > > > > > > > I agree. Maybe we can fix that for raw sockets, want me to > > > > add it to the list? :) > > > > > > So far, I could not find any theoretical solution how to fix this, > > > > What if socket had a LOCKBIND ioctl after which you can not bind it to > > any other device? Then someone with RAW capability can open the socket, > > bind to device and hand it to you. You can send packets but not > > switch to another device. > > Could work, though I was hoping for a solution that does not depend > on a priviledged task at run time to open the socket, as you have with > persistant tap devices or chardevs like macvtap that can have their > persissions set by udev. > > > Arnd <><Well, we could have a char device with an ioctl that gives you back a socket, or maybe even have it give you back a socket when you open it. Will that make you happy? -- MST