From: "Michael S. Tsirkin" <mst@redhat.com>
To: Julian Stecklina <jsteckli@os.inf.tu-dresden.de>
Cc: "snabb-devel@googlegroups.com" <snabb-devel@googlegroups.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O
Date: Tue, 28 May 2013 16:56:17 +0300 [thread overview]
Message-ID: <20130528135617.GA22608@redhat.com> (raw)
In-Reply-To: <51A49E71.7030908@os.inf.tu-dresden.de>
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
next prev parent reply other threads:[~2013-05-28 13:56 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-26 9:32 [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O Luke Gorrie
2013-05-27 9:34 ` Stefan Hajnoczi
2013-05-27 15:18 ` Michael S. Tsirkin
2013-05-27 15:43 ` Paolo Bonzini
2013-05-27 16:18 ` Anthony Liguori
2013-05-27 16:18 ` Paolo Bonzini
2013-05-27 17:01 ` Anthony Liguori
2013-05-27 17:13 ` Michael S. Tsirkin
2013-05-27 18:31 ` Anthony Liguori
2013-05-28 10:39 ` Luke Gorrie
2013-05-28 10:10 ` Luke Gorrie
2013-05-28 10:35 ` Stefan Hajnoczi
2013-05-28 11:36 ` Julian Stecklina
2013-05-28 11:53 ` Michael S. Tsirkin
2013-05-28 12:09 ` Julian Stecklina
2013-05-28 13:56 ` Michael S. Tsirkin [this message]
2013-05-28 15:35 ` Julian Stecklina
2013-05-28 15:44 ` Michael S. Tsirkin
2013-05-28 12:48 ` [Qemu-devel] [snabb-devel:276] " Luke Gorrie
2013-05-28 13:12 ` Julian Stecklina
2013-05-28 13:42 ` [Qemu-devel] [snabb-devel:280] " Luke Gorrie
2013-05-28 14:42 ` [Qemu-devel] [snabb-devel:276] " Luke Gorrie
2013-05-28 15:33 ` Julian Stecklina
2013-05-28 17:00 ` [Qemu-devel] " Anthony Liguori
2013-05-28 17:17 ` Michael S. Tsirkin
2013-05-28 18:55 ` Anthony Liguori
2013-05-29 10:31 ` Stefano Stabellini
2013-05-29 12:25 ` Michael S. Tsirkin
2013-05-29 13:04 ` Stefano Stabellini
2013-06-04 12:19 ` [Qemu-devel] [snabb-devel:300] " Luke Gorrie
2013-06-04 12:49 ` Julian Stecklina
2013-06-04 20:09 ` [Qemu-devel] [snabb-devel:326] " Luke Gorrie
2013-06-04 12:56 ` [Qemu-devel] [snabb-devel:300] " Michael S. Tsirkin
2013-06-05 6:09 ` [Qemu-devel] [snabb-devel:327] " Luke Gorrie
2013-05-29 7:49 ` [Qemu-devel] " Stefan Hajnoczi
2013-05-29 9:08 ` Michael S. Tsirkin
2013-05-29 14:21 ` Stefan Hajnoczi
2013-05-29 14:48 ` Michael S. Tsirkin
2013-05-29 16:02 ` Julian Stecklina
2013-05-30 2:35 ` ronnie sahlberg
2013-05-30 6:46 ` Stefan Hajnoczi
2013-05-30 6:55 ` Michael S. Tsirkin
2013-05-30 7:11 ` [Qemu-devel] [snabb-devel:308] " Luke Gorrie
2013-05-30 8:08 ` [Qemu-devel] " Julian Stecklina
2013-05-29 12:32 ` Julian Stecklina
2013-05-29 14:31 ` Stefan Hajnoczi
2013-05-29 15:59 ` Julian Stecklina
2013-05-28 11:58 ` Stefan Hajnoczi
2013-10-21 10:29 ` Luke Gorrie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130528135617.GA22608@redhat.com \
--to=mst@redhat.com \
--cc=jsteckli@os.inf.tu-dresden.de \
--cc=qemu-devel@nongnu.org \
--cc=snabb-devel@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).