From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFuEc-0008SW-IX for qemu-devel@nongnu.org; Mon, 17 Oct 2011 16:56:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFuEb-0002IL-0a for qemu-devel@nongnu.org; Mon, 17 Oct 2011 16:56:34 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:38324) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFuEa-0002I4-MJ for qemu-devel@nongnu.org; Mon, 17 Oct 2011 16:56:32 -0400 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate03.web.de (Postfix) with ESMTP id DCB581A425769 for ; Mon, 17 Oct 2011 21:14:00 +0200 (CEST) Message-ID: <4E9C7D4A.8010107@web.de> Date: Mon, 17 Oct 2011 21:08:58 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <069dc7131dfb32467e04aad52c634f1ad2c16d06.1318843693.git.jan.kiszka@siemens.com> <20111017114055.GD4537@redhat.com> <4E9C1540.5080607@siemens.com> <20111017123902.GI4537@redhat.com> In-Reply-To: <20111017123902.GI4537@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE2FED4DD6C5FDE964DD67929" Subject: Re: [Qemu-devel] [RFC][PATCH 23/45] qemu-kvm: Rework MSI-X mask notifier to generic MSI config notifiers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Alex Williamson , Marcelo Tosatti , Avi Kivity , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE2FED4DD6C5FDE964DD67929 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-10-17 14:39, Michael S. Tsirkin wrote: > On Mon, Oct 17, 2011 at 01:45:04PM +0200, Jan Kiszka wrote: >> On 2011-10-17 13:40, Michael S. Tsirkin wrote: >>> On Mon, Oct 17, 2011 at 11:27:57AM +0200, Jan Kiszka wrote: >>>> MSI config notifiers are supposed to be triggered on every relevant >>>> configuration change of MSI vectors or if MSI is enabled/disabled. >>>> >>>> Two notifiers are established, one for vector changes and one for ge= neral >>>> enabling. The former notifier additionally passes the currently acti= ve >>>> MSI message. >>>> This will allow to update potential in-kernel IRQ routes on >>>> changes. The latter notifier is optional and will only be used by a >>>> subset of clients. >>>> >>>> These notifiers are currently only available for MSI-X but will be >>>> extended to legacy MSI as well. >>>> >>>> Signed-off-by: Jan Kiszka >>> >>> Passing message, always, does not seem to make sense: message is only= >>> valid if it is unmasked. >> >> If we go from unmasked to masked, the consumer could just ignore the >> message. >=20 > Why don't we let the consumer get the message if it needs it? Because most consumer will need and because I want to keep the API simple= =2E >=20 >>> Further, IIRC the spec requires any changes to be done while >>> message is masked. So mask notifier makes more sense to me: >>> it does the same thing using one notifier that you do >>> using two notifiers. >> >> That's in fact a possible optimization (only invoke the callback on ma= sk >> transitions). >=20 > Further, it is one that is already implemented. > So I would prefer not to add work by removing it :) Generalization to cover MSI requires some changes. Unneeded behavioral changes back and forth should and will of course be avoided. I will rework this. >=20 >> Not sure if that applies to MSI as well, probably not. >=20 > Probably not. However, if per vector masking is > supported, and while vector is masked, the address/ > data values might not make any sense. >=20 > So I think even msi users needs to know about masked state. Yes, and they get this information via the config notifier. >=20 >> To >> have common types, I would prefer to stay with vector config notifiers= >> as name then. >> >> Jan >=20 > So we pass in nonsense values and ask all users to know about MSIX rule= s. > Ugh. >=20 > I do realize msi might change the vector without masking. > We can either artificially call mask before value change > and unmask after, or use 3 notifiers: mask,unmask,config. > Add a comment that config is invoked when configuration > for an unmasked vector is changed, and that > it can only happen for msi, not msix. I see no need in complicating the API like this. MSI-X still needs the config information on unmask, so let's just consistently pass it via the unified config notifier instead of forcing the consumers to create yet two more handlers. I really do not see the benefit for the consumer. Jan --------------enigE2FED4DD6C5FDE964DD67929 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/ iEYEARECAAYFAk6cfUoACgkQitSsb3rl5xQwqQCcDAVrsos0MI15HU3+oyeZJFZA K7wAoI1qgZ2xZoJSgXh00QhewZESGKvA =twqh -----END PGP SIGNATURE----- --------------enigE2FED4DD6C5FDE964DD67929--