From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] KVM: Allow host IRQ sharing for assigned PCI 2.3 devices Date: Tue, 10 Jan 2012 22:18:12 +0100 Message-ID: <4F0CAB14.8030602@web.de> References: <4F0AF394.6000205@siemens.com> <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA519BDBCFDCEF19FC5BB10C4" Cc: Avi Kivity , Marcelo Tosatti , kvm , Alex Williamson , Jesse Barnes To: "Michael S. Tsirkin" Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:42023 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752676Ab2AJVSb (ORCPT ); Tue, 10 Jan 2012 16:18:31 -0500 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate02.web.de (Postfix) with ESMTP id 9D0C71BF59934 for ; Tue, 10 Jan 2012 22:18:13 +0100 (CET) In-Reply-To: <20120110204425.GK17105@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA519BDBCFDCEF19FC5BB10C4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 obsolet= e >>>> 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. wit= h >> flags that select the type, but only implementing it for INTx for now.= >> >> Jan >> >=20 > 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? 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 --------------enigA519BDBCFDCEF19FC5BB10C4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8MqxQACgkQitSsb3rl5xTBAwCeOL5mZPdDJew++YQ2BtR3VJYb MSgAn1uixzJG78N5tGGYhIBiAPs1qhoM =jg3G -----END PGP SIGNATURE----- --------------enigA519BDBCFDCEF19FC5BB10C4--