[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 5/6] xen/x86: add PHYSDEVOP_msi_control

  • To: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <JBeulich@xxxxxxxx>
  • Date: Tue, 6 Aug 2019 07:56:39 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=suse.com;dmarc=pass action=none header.from=suse.com;dkim=pass header.d=suse.com;arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+5BxLNhQzYYpa2Ahtr8qII4Ei4zjp+1rQUQwLMw6+7I=; b=El9JKVAug4uKfwbxir4MwaO84bmUPZnyc8FOIOQVjgmo+oYDgXUb7StMi3efleUf/4CcrwmoV2XV+W6CWpUP1MzCDuM/riuwj60czyGSRTXmp5T853q1gDvhN1pjV89UamQXy7jbXFH2PNnrpJEQxS6QFoaqeTwZgirIG9RaE5Ai6LS9FGmQkXC+2f7ev2FQcX3GG7go1HDXVG+dgI9vAmPt5Mc4eXfQem9iHYl6Kyk2fvMPEAU8kI1mftsnjdjFttpth7AHaHI77C18vFiQ8Ak1b8QAg3OsBCfe+PMuLNnduqSN2pULr4GsWxcllFVR6vH+OYVlYLByt5QdmNPReg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ganwmF/lMEBiA4Mb4LEUctFUnJvQ9srrXKAg4s/0enXRvCCIIaG0z6DG9ajZBYEEJVm5cZMgD3XtXPOK/XBdP8qHjsKOXj2g7PZQsf3Q9hqt0AKgUS/enxZBNaKThMQVGwlej6gf09oVHX7kBpgUP1QT1MSq0E6SZKeAYQMF1U5kYKHe2/ACJQhlcM2TV9Qq2f5SRf0jhxIHSSfHtEuKumqyE6TVttZA6wkg+wrRlV6v5yMKxUClmPSvM2C2lwhuKdlPEaDUAzJMg7U4FLwiRpEa5lvuDKcJjMb2i7l0kbeI4O3PzkVLlypKlsSnjL7DVQddxpB1UeZhUgF7q7ZPKg==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, AndrewCooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, TimDeegan <tim@xxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Tue, 06 Aug 2019 07:57:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVPW85l6TypzCOPUKKzJbbmldm3qbQfOwAgAAauduAAP6xgIAAEDIrgAALaYCAGvscGIABMQMA
  • Thread-topic: [PATCH v5 5/6] xen/x86: add PHYSDEVOP_msi_control

On 05.08.2019 15:44, Marek Marczykowski-Górecki  wrote:
> On Fri, Jul 19, 2019 at 09:43:26AM +0000, Jan Beulich wrote:
>> On 19.07.2019 11:02, Roger Pau Monné  wrote:
>>> On Fri, Jul 19, 2019 at 08:04:45AM +0000, Jan Beulich wrote:
>>>> On 18.07.2019 18:52, Roger Pau Monné  wrote:
>>>>> On Thu, Jul 18, 2019 at 03:17:27PM +0000, Jan Beulich wrote:
>>>>>> On 18.07.2019 15:46, Roger Pau Monné  wrote:
>>>>>>> In fact I don't think INTx should be enabled when MSI(-X) is disabled,
>>>>>>> QEMU already traps writes to the command register, and it will manage
>>>>>>> INTx enabling/disabling by itself. I think the only check required is
>>>>>>> that MSI(-X) cannot be enabled if INTx is also enabled. In the same
>>>>>>> way both MSI caspabilities cannot be enabled simultaneously. The
>>>>>>> function should not explicitly disable any of the other capabilities,
>>>>>>> and just return -EBUSY if the caller attempts for example to enable
>>>>>>> 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 full
>>>>> 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 there's
>>>>> a reason to have both MSI(-X) and INTx enabled at the same time (maybe
>>>>> a quirk for some hardware issue?) it shouldn't be allowed on this new
>>>>> 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.
> 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.

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. 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.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.