Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753664Ab0ASNZg (ORCPT ); Tue, 19 Jan 2010 08:25:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753500Ab0ASNZe (ORCPT ); Tue, 19 Jan 2010 08:25:34 -0500 Received: from thoth.sbs.de ([192.35.17.2]:19715 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753463Ab0ASNZd (ORCPT ); Tue, 19 Jan 2010 08:25:33 -0500 Message-ID: <4B55B2B8.5090105@siemens.com> Date: Tue, 19 Jan 2010 14:25:12 +0100 From: Jan Kiszka User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Michael S. Tsirkin" CC: Davide Libenzi , Avi Kivity , kvm@vger.kernel.org, Linux Kernel Mailing List Subject: Re: [PATCH 1/2] kvm: fix spurious interrupt with irqfd References: <20100113171230.GB19798@redhat.com> In-Reply-To: <20100113171230.GB19798@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2097 Lines: 58 Michael S. Tsirkin wrote: > kvm didn't clear irqfd counter on deassign, as a result we could get a > spurious interrupt when irqfd is assigned back. this leads to poor > performance and, in theory, guest crash. > > Signed-off-by: Michael S. Tsirkin > --- > virt/kvm/eventfd.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c > index 62e4cd9..a9d3fc6 100644 > --- a/virt/kvm/eventfd.c > +++ b/virt/kvm/eventfd.c > @@ -72,12 +72,13 @@ static void > irqfd_shutdown(struct work_struct *work) > { > struct _irqfd *irqfd = container_of(work, struct _irqfd, shutdown); > + u64 cnt; > > /* > * Synchronize with the wait-queue and unhook ourselves to prevent > * further events. > */ > - remove_wait_queue(irqfd->wqh, &irqfd->wait); > + eventfd_ctx_remove_wait_queue(irqfd->eventfd, &irqfd->wait, &cnt); > > /* > * We know no new events will be scheduled at this point, so block For kvm-kmod, I'm fighting with compat support for eventfd_ctx_remove_wait_queue. I basically have a solution for kernels with CONFIG_KPROBES enabled (I need to look up unexported __wake_up_locked[_key]), but there will also be target kernels that do not have this. So there are three options for that case: - Warn the user and fall back to the old racy approach - (Somehow) disable KVM subsystems that use eventfd - Refuse to start KVM As far as I understood, irqfd is interesting for device assignment and now also for vhost, right? What about ioeventfd? I just wonder how broad the impact of a broken or non-existent eventfd subsystem for kvm-kmod is. Any thoughts welcome. Jan PS: If anyone forgot why Avi handed over this job, you should now remember why. :) -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/