From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NlSdU-0003AM-5u for qemu-devel@nongnu.org; Sat, 27 Feb 2010 14:47:36 -0500 Received: from [199.232.76.173] (port=55016 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NlSdT-0003AA-Oh for qemu-devel@nongnu.org; Sat, 27 Feb 2010 14:47:35 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NlSdS-0007JV-Af for qemu-devel@nongnu.org; Sat, 27 Feb 2010 14:47:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16003) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NlSdR-0007JJ-Tn for qemu-devel@nongnu.org; Sat, 27 Feb 2010 14:47:34 -0500 Date: Sat, 27 Feb 2010 21:44:18 +0200 From: "Michael S. Tsirkin" Message-ID: <20100227194418.GB26389@redhat.com> References: <886ef6ffeb6748f6dc4fe5431f71cb12bb74edc9.1267122331.git.mst@redhat.com> <4B86D3CF.4020601@codemonkey.ws> <20100226145155.GC23359@redhat.com> <4B87E755.9000707@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B87E755.9000707@codemonkey.ws> Subject: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: amit.shah@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com On Fri, Feb 26, 2010 at 09:23:01AM -0600, Anthony Liguori wrote: > On 02/26/2010 08:51 AM, Michael S. Tsirkin wrote: >> On Thu, Feb 25, 2010 at 01:47:27PM -0600, Anthony Liguori wrote: >> >>> On 02/25/2010 12:28 PM, Michael S. Tsirkin wrote: >>> >>>> This adds vhost binary option to tap, to enable vhost net accelerator. >>>> Default is off for now, we'll be able to make default on long term >>>> when we know it's stable. >>>> >>>> vhostfd option can be used by management, to pass in the fd. Assigning >>>> vhostfd implies vhost=on. >>>> >>>> Signed-off-by: Michael S. Tsirkin >>>> >>>> >>> Since the thinking these days is that macvtap and tap is pretty much all >>> we'll ever need for vhost-net, perhaps we should revisit -net vhost vs. >>> -net tap,vhost=X? >>> >>> I think -net vhost,fd=X makes a lot more sense than -net >>> tap,vhost=on,vhostfd=X. >>> >>> Regards, >>> >>> Anthony Liguori >>> >> We'll have to duplicate all tap options. >> I think long term we will just make vhost=on the default. >> > > I don't think we can. vhost only works when using KVM Yes, default to on with KVM. > and it doesn't > support all of the features of userspace virtio. Since it's in upstream > Linux without supporting all of the virtio-net features, it's something > we're going to have to deal with for a long time. Speaking of vlan filtering etc? It's just a matter of time before it supports all interesting features. Kernel support is there in net-next already, userspace should be easy too. I should be able to code it up once I finish bothering about upstream merge (hint hint :)). > Furthermore, vhost reduces a virtual machine's security. It offers an > impressive performance boost (particularly when dealing with 10gbit+ > networking) but for a user that doesn't have such strong networking > performance requirements, I think it's reasonable for them to not want > to make a security trade off. It's hard for me to see how it reduces VM security. If it does, it's not by design and will be fixed. > One reason I like -net vhost is that it's a much less obscure syntax and > it's the sort of thing that is easy to tell users that they should use. > I understand you're argument for -net tap if you assume vhost=on will > become the default because that means that users never really have to be > aware of vhost once it becomes the default. But as I said above, I > don't think it's reasonable to make it on by default with -net tap. Not yet, but we'll get there. >> Users do not really care about vhost, it just makes tap >> go fater. So promoting it to 1st class options is wrong IMO. >> > > User's should care about vhost because it impacts the features supported > by the virtual machine and it has security ramifications. It's a great > feature and I think the most users will want to use it, but I do think > it's something that users ought to be aware of. > > Regards, > > Anthony Liguori