From: Jan Beulich <jbeulich@suse.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
Paul Durrant <paul@xen.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH 3/3] x86/vmsi: tolerate unsupported MSI address/data fields
Date: Tue, 26 Jan 2021 16:17:59 +0100 [thread overview]
Message-ID: <3fead705-5d36-72df-981f-04d0c47175c3@suse.com> (raw)
In-Reply-To: <20210126110606.21741-4-roger.pau@citrix.com>
On 26.01.2021 12:06, Roger Pau Monne wrote:
> Plain MSI doesn't allow caching the MSI address and data fields while
> the capability is enabled and not masked, hence we need to allow any
> changes to those fields to update the binding of the interrupt. For
> reference, the same doesn't apply to MSI-X that is allowed to cache
> the data and address fields while the entry is unmasked, see section
> 6.8.3.5 of the PCI Local Bus Specification 3.0.
>
> Allowing such updates means that a guest can write an invalid address
> (ie: all zeros) and then a valid one, so the PIRQs shouldn't be
> unmapped when the interrupt cannot be bound to the guest, since
> further updates to the address or data fields can result in the
> binding succeeding.
IOW the breakage from the other patch was because rubbish was
written first, and suitable data was written later on? I didn't
think core PCI code in Linux would do such, which would make me
suspect a driver having custom MSI handling code ...
> Modify the vPCI MSI arch helpers to track whether the interrupt is
> bound, and make failures in vpci_msi_update not unmap the PIRQ, so
> that further calls can attempt to bind the PIRQ again.
>
> Note this requires some modifications to the MSI-X handlers, but there
> shouldn't be any functional changes in that area.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Am I understanding correctly that this change is independent of
the initial 2 patches (where I have reservations), and hence
it could go in ahead of them (or all alone)?
Jan
next prev parent reply other threads:[~2021-01-26 15:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-26 11:06 [PATCH 0/3] x86/intr: interrupt related fixes Roger Pau Monne
2021-01-26 11:06 ` [PATCH 1/3] x86/irq: remove duplicated clear_domain_irq_pirq calls Roger Pau Monne
2021-01-26 14:38 ` Jan Beulich
2021-01-26 16:08 ` Roger Pau Monné
2021-01-26 16:13 ` Jan Beulich
2021-01-26 11:06 ` [PATCH 2/3] x86/irq: don't disable domain MSI IRQ on force unbind Roger Pau Monne
2021-01-26 14:52 ` Jan Beulich
2021-01-26 16:21 ` Roger Pau Monné
2021-01-27 8:59 ` Jan Beulich
2021-01-26 11:06 ` [PATCH 3/3] x86/vmsi: tolerate unsupported MSI address/data fields Roger Pau Monne
2021-01-26 15:17 ` Jan Beulich [this message]
2021-01-26 15:57 ` Roger Pau Monné
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=3fead705-5d36-72df-981f-04d0c47175c3@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=paul@xen.org \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).