All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Jason Andryuk" <jandryuk@gmail.com>,
	"Paul Durrant" <paul@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 3/3] x86/msi: clear initial MSI-X state on boot
Date: Tue, 28 Mar 2023 15:04:28 +0200	[thread overview]
Message-ID: <ZCLl3ePLgrmFTViV@mail-itl> (raw)
In-Reply-To: <5cfcfb7a-df50-fbe4-89e6-611a83991790@suse.com>

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

On Tue, Mar 28, 2023 at 02:54:38PM +0200, Jan Beulich wrote:
> On 25.03.2023 03:49, Marek Marczykowski-Górecki wrote:
> > Some firmware/devices are found to not reset MSI-X properly, leaving
> > MASKALL set. Xen relies on initial state being both disabled.
> > Especially, pci_reset_msix_state() assumes if MASKALL is set, it was Xen
> > setting it due to msix->host_maskall or msix->guest_maskall. Clearing
> > just MASKALL might be unsafe if ENABLE is set, so clear them both.
> 
> But pci_reset_msix_state() comes into play only when assigning a device
> to a DomU. If the tool stack doing a reset doesn't properly clear the
> bit, how would it be cleared the next time round (i.e. after the guest
> stopped and then possibly was started again)? It feels like the issue
> wants dealing with elsewhere, possibly in the tool stack.

I may be misremembering some details, but AFAIR Xen intercepts
toolstack's (or more generally: accesses from dom0) attempt to clean
this up and once it enters an inconsistent state (or rather: starts with
such at the start of the day), there was no way to clean it up.

I have considered changing pci_reset_msix_state() to not choke on
MASKALL being set, but I'm a bit afraid of doing it, as there it seems
there is a lot of assumptions all over the place and I may miss some.

> 
> > --- a/xen/drivers/passthrough/msi.c
> > +++ b/xen/drivers/passthrough/msi.c
> > @@ -48,6 +48,13 @@ int pdev_msi_init(struct pci_dev *pdev)
> >          ctrl = pci_conf_read16(pdev->sbdf, msix_control_reg(pos));
> >          msix->nr_entries = msix_table_size(ctrl);
> >  
> > +        /*
> > +         * Clear both ENABLE and MASKALL, pci_reset_msix_state() relies on this
> > +         * initial state.
> > +         */
> 
> Please can comments be accurate at least at the time of writing?
> pci_reset_msix_state() doesn't care about ENABLE at all.
> 
> Jan

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2023-03-28 13:04 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-25  2:49 [PATCH v2 1/3] x86/msi: passthrough all MSI-X vector ctrl writes to device model Marek Marczykowski-Górecki
2023-03-25  2:49 ` [PATCH v2 2/3] x86/hvm: Allow writes to registers on the same page as MSI-X table Marek Marczykowski-Górecki
2023-03-27 10:47   ` Andrew Cooper
2023-03-28 11:28   ` Roger Pau Monné
2023-03-28 12:05     ` Marek Marczykowski-Górecki
2023-03-28 12:34       ` Jan Beulich
2023-03-28 12:52         ` Marek Marczykowski-Górecki
2023-03-28 13:03           ` Jan Beulich
2023-03-28 13:22             ` Roger Pau Monné
2023-04-03  4:21             ` Marek Marczykowski-Górecki
2023-04-03 11:09               ` Jan Beulich
2023-03-28 12:52       ` Roger Pau Monné
2023-03-25  2:49 ` [PATCH v2 3/3] x86/msi: clear initial MSI-X state on boot Marek Marczykowski-Górecki
2023-03-28 11:37   ` Roger Pau Monné
2023-03-28 12:07     ` Marek Marczykowski-Górecki
2023-03-28 12:38       ` Jan Beulich
2023-03-28 12:54   ` Jan Beulich
2023-03-28 13:04     ` Marek Marczykowski-Górecki [this message]
2023-03-28 13:17       ` Jason Andryuk
2023-03-28 17:38         ` Jason Andryuk
2023-03-28 13:23       ` Jan Beulich
2023-03-28 13:27         ` Roger Pau Monné
2023-03-28 13:32           ` Jason Andryuk
2023-03-28 13:35             ` Jan Beulich
2023-03-28 13:43               ` Jason Andryuk
2023-03-28 13:54                 ` Jan Beulich
2023-03-28 15:08                   ` Jason Andryuk
2023-03-28 15:39                     ` Jan Beulich
2023-03-27 10:12 ` [PATCH v2 1/3] x86/msi: passthrough all MSI-X vector ctrl writes to device model Roger Pau Monné
2023-03-27 10:26   ` Marek Marczykowski-Górecki
2023-03-27 10:51     ` Roger Pau Monné
2023-03-27 11:34       ` Marek Marczykowski-Górecki
2023-03-27 13:29         ` Roger Pau Monné
2023-03-27 14:20           ` Marek Marczykowski-Górecki
2023-03-27 14:37             ` Roger Pau Monné
2023-03-27 15:32   ` Jan Beulich
2023-03-27 15:42     ` 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=ZCLl3ePLgrmFTViV@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=jandryuk@gmail.com \
    --cc=jbeulich@suse.com \
    --cc=paul@xen.org \
    --cc=roger.pau@citrix.com \
    --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.