From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 08/10] Move IO APIC to its own lock. Date: Sun, 09 Aug 2009 18:10:07 +0300 Message-ID: <4A7EE6CF.1050405@redhat.com> References: <1249821671-32356-1-git-send-email-gleb@redhat.com> <1249821671-32356-9-git-send-email-gleb@redhat.com> <4A7EE326.9050300@redhat.com> <20090809145739.GS4764@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from mx2.redhat.com ([66.187.237.31]:60593 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750885AbZHIPEL (ORCPT ); Sun, 9 Aug 2009 11:04:11 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n79F4CLa000542 for ; Sun, 9 Aug 2009 11:04:12 -0400 In-Reply-To: <20090809145739.GS4764@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/09/2009 05:57 PM, Gleb Natapov wrote: > On Sun, Aug 09, 2009 at 05:54:30PM +0300, Avi Kivity wrote: > >> On 08/09/2009 03:41 PM, Gleb Natapov wrote: >> >>> Introduce new function kvm_notifier_set_irq() that should be used >>> to change irq line level from irq notifiers. When irq notifier >>> change irq line level it calls into irq chip code recursively. The >>> function avoids taking a lock recursively. >>> >>> >> This looks really horrible. I don't have an alternative yet, but I'll >> think of one. >> > I agree this is not nice. This is needed only for device assignment > case. That explains why I don't like device assignment :) Well, implementation problems can be fixed. Other issues with device assignment cannot. > The problem > is that the only communication channel from guest to assigned device that > goes through the host is interrupt injection/acknowledgement, so we try to > do things (lowering IRQ) on this path that usually are done somewhere else. > You can queue the injection somehow (work struct? special purpose queue examined after unlock?) and avoid the recursive locking. -- error compiling committee.c: too many arguments to function