From patchwork Thu Jan 20 16:07:18 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Michael S. Tsirkin" X-Patchwork-Id: 79713 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 6B0AEB70E4 for ; Fri, 21 Jan 2011 03:08:58 +1100 (EST) Received: from localhost ([127.0.0.1]:35446 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pfx4B-0000Ew-N2 for incoming@patchwork.ozlabs.org; Thu, 20 Jan 2011 11:08:55 -0500 Received: from [140.186.70.92] (port=54925 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pfx2y-0008H4-W6 for qemu-devel@nongnu.org; Thu, 20 Jan 2011 11:07:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pfx2v-0005YV-59 for qemu-devel@nongnu.org; Thu, 20 Jan 2011 11:07:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pfx2u-0005YP-TX for qemu-devel@nongnu.org; Thu, 20 Jan 2011 11:07:37 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0KG7YwX000788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jan 2011 11:07:34 -0500 Received: from redhat.com (vpn-200-44.tlv.redhat.com [10.35.200.44]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP id p0KG7UE4004108; Thu, 20 Jan 2011 11:07:31 -0500 Date: Thu, 20 Jan 2011 18:07:18 +0200 From: "Michael S. Tsirkin" To: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH] vhost: force vhost off for non-MSI guests Message-ID: <20110120160718.GA24652@redhat.com> References: <20110120153521.GA24357@redhat.com> <4D38583D.9010602@codemonkey.ws> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4D38583D.9010602@codemonkey.ws> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. Cc: kvm@vger.kernel.org, Juan Quintela , Jes.Sorensen@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org, Alex Williamson X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Thu, Jan 20, 2011 at 09:43:57AM -0600, Anthony Liguori wrote: > On 01/20/2011 09:35 AM, Michael S. Tsirkin wrote: > >When MSI is off, each interrupt needs to be bounced through the io > >thread when it's set/cleared, so vhost-net causes more context switches and > >higher CPU utilization than userspace virtio which handles networking in > >the same thread. > > > >We'll need to fix this by adding level irq support in kvm irqfd, > >for now disable vhost-net in these configurations. > > > >Signed-off-by: Michael S. Tsirkin > > I actually think this should be a terminal error. The user asks for > vhost-net, if we cannot enable it, we should exit. > > Or we should warn the user that they should expect bad performance. > Silently doing something that the user has explicitly asked us not > to do is not a good behavior. > > Regards, > > Anthony Liguori The issue is that user has no control of the guest, and can not know whether the guest enables MSI. So what you ask for will just make some guests fail, and others fail sometimes. The user also has no way to know that version X of kvm does not expose a way to inject level interrupts with irqfd. We could have *another* flag that says "use vhost where it helps" but then I think this is what everyone wants to do, anyway, and libvirt already sets vhost=on so I prefer redefining the meaning of an existing flag. Maybe this is best handled by a documentation update? We always said: " use vhost=on to enable experimental in kernel accelerator\n" note 'enable' not 'require'. This is similar to how we specify nvectors : you can not make guest use the feature. How about this: diff --git a/qemu-options.hx b/qemu-options.hx index 898561d..3c937c1 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -1061,6 +1061,7 @@ DEF("net", HAS_ARG, QEMU_OPTION_net, " use vnet_hdr=off to avoid enabling the IFF_VNET_HDR tap flag\n" " use vnet_hdr=on to make the lack of IFF_VNET_HDR support an error condition\n" " use vhost=on to enable experimental in kernel accelerator\n" + " (note: vhost=on has no effect unless guest uses MSI-X)\n" " use 'vhostfd=h' to connect to an already opened vhost net device\n" #endif "-net socket[,vlan=n][,name=str][,fd=h][,listen=[host]:port][,connect=host:port]\n"