Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

[Michael S. Tsirkin]

On Tue, May 28, 2013 at 02:09:21PM +0200, Julian Stecklina wrote:
> On 05/28/2013 01:53 PM, Michael S. Tsirkin wrote:
> > Implementing out of process device logic would absolutely be useful for
> > qemu, for security.
> > 
> > Don't expect it to be zero overhead though, latency overhead
> > of bouncing each packet through multiple processes would
> > be especially painful.
> 
> Currently, latency for vhost is also quite bad compared to what it could
> be, because for VM-to-VM packets usually 4 CPUs are involved. The CPU
> that VM A's vcpu thread runs on, the CPU its vhost thread in the kernel
> runs on, the CPU VM B's vhost thread runs on and finally the CPU VM B's
> vcpu thread runs on.
> 
> It is possible to change the vhost implementation in the kernel to
> handle packet transmission to local VMs in a single thread, but it is
> rather hard. I have a hacky patch that implements that (that
> unfortunately I cannot make public :( ) and it improves latency and CPU
> utlization.

Yes - and it's not new. Shirley Ma sent such prototype patches,
and in fact that was how vhost worked originally.
There were some issues to be fixed before it worked
without issues, but we do plan to go back to that I think.

And that's only for guest to guest. While important it is
not the most common case. Guest to external is.
For that we need to do things like process packets in softirq context.
People are looking into all this now.

> I would suppose a userspace implementation of this is way
> simpler and still give most of the performance benefits. It also removes
> the virtio implementation in the kernel (vhost) from the trusted
> computing base of other stuff in the system.
> 
> IMHO implementing device emulation in the kernel is plain wrong from a
> security perspective.
> 
> Julian

It would be, yes.

But vhost is not a device emulation. emulation is in qemu.  vhost is
an asynchronous kernel/userspace interface.

kvm has support for ioeventfd/irqfd, which creates a fastpath way to
signal host kernel directly from guest, bypassing qemu.

But it's not a vhost feature, and anyway people are using vhost without
it, so it's not a must.

-- 
MST