From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH] KVM: Allow host IRQ sharing for assigned PCI 2.3 devices Date: Tue, 10 Jan 2012 23:36:10 +0200 Message-ID: <20120110213609.GA20988@redhat.com> References: <20120110161748.GB17105@redhat.com> <4F0C758F.1060606@siemens.com> <20120110181014.GE17105@redhat.com> <4F0C818D.9@siemens.com> <20120110183143.GG17105@redhat.com> <4F0C86D8.3070007@siemens.com> <20120110190425.GH17105@redhat.com> <4F0C944B.7040101@web.de> <20120110204425.GK17105@redhat.com> <4F0CAB14.8030602@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Marcelo Tosatti , kvm , Alex Williamson , Jesse Barnes To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:1283 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752676Ab2AJVeD (ORCPT ); Tue, 10 Jan 2012 16:34:03 -0500 Content-Disposition: inline In-Reply-To: <4F0CAB14.8030602@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Jan 10, 2012 at 10:18:12PM +0100, Jan Kiszka wrote: > On 2012-01-10 21:44, Michael S. Tsirkin wrote: > > On Tue, Jan 10, 2012 at 08:40:59PM +0100, Jan Kiszka wrote: > >> On 2012-01-10 20:04, Michael S. Tsirkin wrote: > >>>>> But IMO this > >>>>> shows it is a more generic interface. > >>>> > >>>> I'm worried about adding something new that will soon become obsolete > >>>> again. That's wasted effort IMHO unless we say today that there will be > >>>> no in-kernel MSI-X support. > >>>> > >>>> Jan > >>> > >>> Yes. But as we are adding a new interface maybe it's better to add a > >>> more generic one? I don't insist as I don't have a specific proposal, > >>> just something to consider. > >> > >> I could imagine defining an extensible IRQ masking interface, e.g. with > >> flags that select the type, but only implementing it for INTx for now. > >> > >> Jan > >> > > > > I guess if we pass in the IRQ# the type can be inferred and does not > > need to be passed in. > > What kind of number, a GSI? We do not yet track what is behind a GSI, do we? > > Hmm, I think this requires more careful thoughts. What should be the > semantic of "mask" for the addressed device behind the IRQ? For assigned > legacy IRQ it's clear: mask at config space level. For assigned MSI-X it > should be masking at vector level. What about assigned MSI? > What about > irqfds? How to deal with future IRQ sources? For correctness, it is enough to mask in host kernel. Masking at device level is an optimization: e.g. you don't mask immediately either. > No, I think it is better to directly associate the masking feature > directly with the source instead of doing this via some handle, > potentially addressing the whole world. If there is a need for > KVM_IRQFD_MASK, then let's introduce it. As a separate API. > > Jan > That's an option too. -- MST