From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Cc: "Juergen Gross" <jgross@suse.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Oleksandr Tyshchenko" <oleksandr_tyshchenko@epam.com>,
"moderated list:XEN HYPERVISOR INTERFACE"
<xen-devel@lists.xenproject.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] xen-pciback: Consider MSI-X enabled only when MASKALL bit is cleared
Date: Thu, 17 Nov 2022 14:43:01 +0100 [thread overview]
Message-ID: <1d3324da-16d2-2230-2fb4-433ef6acfc3e@suse.com> (raw)
In-Reply-To: <e606aa11-aeb7-fcaa-d699-380be4adc1ac@citrix.com>
On 17.11.2022 13:28, Andrew Cooper wrote:
> On 17/11/2022 11:41, Marek Marczykowski-Górecki wrote:
>> Linux enables MSI-X before disabling INTx, but keeps MSI-X masked until
>> the table is filled. Then it disables INTx just before clearing MASKALL
>> bit. Currently this approach is rejected by xen-pciback.
>> Allow setting PCI_MSIX_FLAGS_ENABLE while INTx is still enabled as long
>> as PCI_MSIX_FLAGS_MASKALL is set too.
>>
>> Fixes: 5e29500eba2a ("xen-pciback: Allow setting PCI_MSIX_FLAGS_MASKALL too")
>> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
>
> The PCI spec states that devices are not permitted to use INTx when MSI
> or MSI-X is enabled. The mask status has no legitimate bearing on irq type.
>
> INTx_DISABLE exists as a bodge to mean "INTx not permitted even when
> neither MSI nor MSI-X are enabled", and exists because in some case,
> transiently disabling MSI is the only safe way to update the descriptor.
>
>
> I can believe that this change fixes a an issue, but the logic surely
> cannot be correct overall.
Question then is - what can we do without altering the sequence of steps
Linux (and likely other OSes) take? Imo Marek's proposal is the least
bad option, because everything else would be more intrusive or wouldn't
take effect for existing released kernel versions running in guests.
Jan
next prev parent reply other threads:[~2022-11-17 13:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 11:41 [PATCH] xen-pciback: Consider MSI-X enabled only when MASKALL bit is cleared Marek Marczykowski-Górecki
2022-11-17 12:28 ` Andrew Cooper
2022-11-17 13:43 ` Jan Beulich [this message]
2022-11-17 12:54 ` David Vrabel
2022-11-17 13:13 ` Marek Marczykowski-Górecki
2022-11-17 13:33 ` Jan Beulich
2022-11-17 14:32 ` Marek Marczykowski-Górecki
2022-11-17 13:50 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d3324da-16d2-2230-2fb4-433ef6acfc3e@suse.com \
--to=jbeulich@suse.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marmarek@invisiblethingslab.com \
--cc=oleksandr_tyshchenko@epam.com \
--cc=sstabellini@kernel.org \
--cc=tglx@linutronix.de \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.