From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BFC99C433FF for ; Tue, 6 Aug 2019 09:46:46 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8DF2920679 for ; Tue, 6 Aug 2019 09:46:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="LWmFZpST" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8DF2920679 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=invisiblethingslab.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1huw2m-00061I-K0; Tue, 06 Aug 2019 09:46:12 +0000 Received: from us1-rack-dfw2.inumbo.com ([104.130.134.6]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1huw2k-00061D-SF for xen-devel@lists.xenproject.org; Tue, 06 Aug 2019 09:46:11 +0000 X-Inumbo-ID: 046d024a-b82f-11e9-8980-bc764e045a96 Received: from new4-smtp.messagingengine.com (unknown [66.111.4.230]) by us1-rack-dfw2.inumbo.com (Halon) with ESMTPS id 046d024a-b82f-11e9-8980-bc764e045a96; Tue, 06 Aug 2019 09:46:09 +0000 (UTC) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id AB76B16B7; Tue, 6 Aug 2019 05:46:08 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 06 Aug 2019 05:46:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=gdOzlA v5spwvmN+dbYAQS4RYl4bVA+hxdgh3DUguyqQ=; b=LWmFZpSTyPkz0l28b2E0sc 5ODin3LTdAanVSGPXVuyzlP4fbs+cy5i+NToz65d10tj31Yz4jSYTSoIohAoIwKg xdHijZhOuDlF1FiMc7feiY4shZYfZKgRvNINCgdnqMsvThzI76utcXHLbgf0n/iN agANy2ucnzt8cox4LiuZ2p5sWnTRNAAiKfBzKrIuCoKqzCIW/QttKEcT75crBSG6 ZdLqbZk23817EkImGIrZ8Fiqu82WxxvqdMBr4+Qne7nV/76562tcKcETS1WrgGwP 06Slr8sUSQLNh+PfIF7CjlOZicKLLI9yL/JdOS+cxMv80GTbgMqxldW2F1T7XLdg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddutddgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjfgesghdtreertderjeenucfhrhhomhepofgrrhgv khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecukfhppeeluddrieehrdefgedr feefnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisg hlvghthhhinhhgshhlrggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id D44AF8005C; Tue, 6 Aug 2019 05:46:04 -0400 (EDT) Date: Tue, 6 Aug 2019 11:46:01 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Message-ID: <20190806094601.GG1250@mail-itl> References: <20190717101843.2nmigl4dt4kekuax@Air-de-Roger.citrite.net> <20190717235426.GX1250@mail-itl> <20190718134604.owj6l4hk7rjq72es@Air-de-Roger.citrite.net> <9d0c36b7-97d3-5da8-c35b-7073c2066841@suse.com> <20190718165212.rj23yh5bphtc2cq5@Air-de-Roger.citrite.net> <20190719090202.vzeernrydawwnzan@Air-de-Roger.citrite.net> <20190805134424.GJ1549@mail-itl> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12+29 (a621eaed) (2019-06-14) Subject: Re: [Xen-devel] [PATCH v5 5/6] xen/x86: add PHYSDEVOP_msi_control X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , AndrewCooper , Ian Jackson , TimDeegan , Julien Grall , "xen-devel@lists.xenproject.org" , Daniel De Graaf , Roger Pau =?utf-8?B?TW9ubsOp?= Content-Type: multipart/mixed; boundary="===============0998472458319103732==" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --===============0998472458319103732== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5yI2NvEZ36o0Huwo" Content-Disposition: inline --5yI2NvEZ36o0Huwo Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 06, 2019 at 07:56:39AM +0000, Jan Beulich wrote: > On 05.08.2019 15:44, Marek Marczykowski-G=C3=B3recki wrote: > > On Fri, Jul 19, 2019 at 09:43:26AM +0000, Jan Beulich wrote: > >> On 19.07.2019 11:02, Roger Pau Monn=C3=A9 wrote: > >>> On Fri, Jul 19, 2019 at 08:04:45AM +0000, Jan Beulich wrote: > >>>> On 18.07.2019 18:52, Roger Pau Monn=C3=A9 wrote: > >>>>> On Thu, Jul 18, 2019 at 03:17:27PM +0000, Jan Beulich wrote: > >>>>>> On 18.07.2019 15:46, Roger Pau Monn=C3=A9 wrote: > >>>>>>> In fact I don't think INTx should be enabled when MSI(-X) is disa= bled, > >>>>>>> QEMU already traps writes to the command register, and it will ma= nage > >>>>>>> INTx enabling/disabling by itself. I think the only check require= d is > >>>>>>> that MSI(-X) cannot be enabled if INTx is also enabled. In the sa= me > >>>>>>> way both MSI caspabilities cannot be enabled simultaneously. The > >>>>>>> function should not explicitly disable any of the other capabilit= ies, > >>>>>>> and just return -EBUSY if the caller attempts for example to enab= le > >>>>>>> MSI while INTx or MSI-X is enabled. > >>>>>> > >>>>>> You do realize that pci_intx() only ever gets called for Xen > >>>>>> internally used interrupts, i.e. mainly the serial console one? > >>>>> > >>>>> You will have to bear with me because I'm not sure I understand why > >>>>> it does matter. Do you mean to point out that dom0 is the one in fu= ll > >>>>> control of INTx, and thus Xen shouldn't care of whether INTx and > >>>>> MSI(-X) are enabled at the same time? > >>>>> > >>>>> I still think that at least a warning should be printed if a caller > >>>>> tries to enable MSI(-X) while INTx is also enabled, but unless ther= e's > >>>>> a reason to have both MSI(-X) and INTx enabled at the same time (ma= ybe > >>>>> a quirk for some hardware issue?) it shouldn't be allowed on this n= ew > >>>>> interface. > >>>> > >>>> I don't mind improvements to the current situation (i.e. such a > >>>> warning may indeed make sense); I merely stated how things currently > >>>> are. INTx treatment was completely left aside when MSI support was > >>>> introduced into Xen. > >>> > >>> In order to give Marek a more concise reply, would you agree to return > >>> -EBUSY (or some error code) and print a warning message if the caller > >>> attempts to enable MSI(-X) while INTx is also enabled? > >> > >> As to returning an error - I think so, yes. I'm less sure about logging > >> a message. > >=20 > > I'm trying to get it working and it isn't clear to me what should I > > check for "INTx is also enabled". I assumed PCI_COMMAND_INTX_DISABLE > > bit, but it looks like guest has no control over this bit, even in > > permissive mode. This means enabling MSI(-X) always fails because guest > > has no way to set PCI_COMMAND_INTX_DISABLE bit before. >=20 > Well, the guest has no control, but in order to enable MSI{,-X} I'd > have expected qemu or the Dom0 kernel to set this bit up front.=20 qemu would do that, when running in dom0. But in PV stubdomain it talks to pciback, which filters it out. > If > that's not the case, then of course neither checking nor logging a > message is appropriate at this point in time. It may be worthwhile > calling out this anomaly then in the description. Ok, so I'll go back to setting PCI_COMMAND_INTX_DISABLE instead of just verification. Just to clarify: should I also clear PCI_COMMAND_INTX_DISABLE when disabling MSI? Now I think yes, because nothing else would do that otherwise, but I would like to double check. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --5yI2NvEZ36o0Huwo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl1JTFoACgkQ24/THMrX 1yzp6AgAkdWEsmgrzX0C9Eit8FegLM3n/nPK9VeStbbLfngPkuSJPQDI2GYPTbEf kQeYnS7PYmHyTWReyvIxNFl13QerYkzJEXRmM2/lM+ANA/lxt9CaswW3o9XW5309 3kKRCrZeBcJ2vyioXFFa+ImPwdBnalAitVqZGKRmIchQJxsBuC9YLkHA3k8KHfX5 pliSMdqaramclU+lw1p9/V0ilbOa9RlQC0a8V2yzg1Psl7lREYNGnRonb0jFT3EH aXKU7K4GTuTLtKAuJZ8JUxsNtffkWYeHJEcZa70fwPMj3u1v8lGdAEByM2I5Z6CK kxPoQnwGkg6bwYXfU51crsHdYAF0KQ== =/TLT -----END PGP SIGNATURE----- --5yI2NvEZ36o0Huwo-- --===============0998472458319103732== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============0998472458319103732==--