From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 10/10] KVM: MSI to INTx translate Date: Tue, 04 Nov 2008 13:57:56 +0200 Message-ID: <491038C4.3040206@redhat.com> References: <1225428647-27614-1-git-send-email-sheng@linux.intel.com> <1225428647-27614-11-git-send-email-sheng@linux.intel.com> <4910312E.6030309@redhat.com> <200811041940.07596.sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Sheng Yang Return-path: Received: from mx2.redhat.com ([66.187.237.31]:45245 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750987AbYKDL57 (ORCPT ); Tue, 4 Nov 2008 06:57:59 -0500 In-Reply-To: <200811041940.07596.sheng@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Sheng Yang wrote: > Yes, in theory, we got a little trouble, but not that much. > > The mechanism based on a assumption: every time guest got a interrupt, it > would deassert the interrupt source sooner or later. So we take the Ack action > as the same as deassert the IRQ line here (unmasked the IRQ). > > So the biggest known issue is, after guest got the interrupt, rather than > deassert it, guest driver took the advantage of level triggered interrupt, and > just want to deassert after it receive it for e.g. 10 times. Then we would got > the trouble. But it's so tricky and we don't know any device by now take this > way yet. Of course they can, so we also suggest to use a whitelist/blacklist > for this approach. But this should work in most condition. > > Yeah, it's aggressive, but we think it's reasonable, and tested OK (in my > limited environment). Also I heard that Hyper-V or Vmware did this. > > Any more concerns? Hope we didn't neglect something. > Please add a module parameter to disable msi->pciirq conversion in that case. So if someone runs into trouble, we can try out the alternative. -- error compiling committee.c: too many arguments to function