From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 10/10] KVM: MSI to INTx translate Date: Tue, 4 Nov 2008 20:55:13 +0800 Message-ID: <20081104125513.GA18696@yukikaze> 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> <491038C4.3040206@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sheng Yang , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from ti-out-0910.google.com ([209.85.142.189]:5259 "EHLO ti-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751915AbYKDMzS (ORCPT ); Tue, 4 Nov 2008 07:55:18 -0500 Received: by ti-out-0910.google.com with SMTP id b6so1689126tic.23 for ; Tue, 04 Nov 2008 04:55:15 -0800 (PST) Content-Disposition: inline In-Reply-To: <491038C4.3040206@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Nov 04, 2008 at 01:57:56PM +0200, Avi Kivity wrote: > 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. Yes of course. :) -- regards Yang, Sheng > -- > error compiling committee.c: too many arguments to function > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html