From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC][PATCH 23/45] qemu-kvm: Rework MSI-X mask notifier to generic MSI config notifiers Date: Mon, 17 Oct 2011 21:08:58 +0200 Message-ID: <4E9C7D4A.8010107@web.de> References: <069dc7131dfb32467e04aad52c634f1ad2c16d06.1318843693.git.jan.kiszka@siemens.com> <20111017114055.GD4537@redhat.com> <4E9C1540.5080607@siemens.com> <20111017123902.GI4537@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE2FED4DD6C5FDE964DD67929" Cc: Alex Williamson , Marcelo Tosatti , Avi Kivity , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" To: "Michael S. Tsirkin" Return-path: In-Reply-To: <20111017123902.GI4537@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.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--