From: Bjorn Helgaas <helgaas@kernel.org>
To: Edmund Raile <edmund.raile@proton.me>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org,
Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH] PCI: Mark LSI FW643 to avoid bus reset
Date: Mon, 26 Feb 2024 15:02:28 -0600 [thread overview]
Message-ID: <20240226210228.GA199890@bhelgaas> (raw)
In-Reply-To: <20240226102354.86757-1-edmund.raile@proton.me>
[+cc Alex]
On Mon, Feb 26, 2024 at 10:25:12AM +0000, Edmund Raile wrote:
> Using LSI / Agere FW643 with vfio-pci will issue an FLreset, causing
> a broken link only recoverable by removing power (power-off /
> suspend + rescan). Prevent this bus reset.
> With this change, the device can be assigned to VMs with VFIO.
I don't quite understand the commit log. It says Function Level
Resets cause a problem, but the patch sets PCI_DEV_FLAGS_NO_BUS_RESET,
which prevents Secondary Bus Resets, not Function Level Resets.
By default, I think we try reset methods in order of
pci_reset_fn_methods[], so the fact that we get to the end and
try pci_reset_bus_function() (where PCI_DEV_FLAGS_NO_BUS_RESET is
tested) suggests that we weren't able to use FLR or PM resets.
IIUC, vfio-pci resets devices to prevent leaking state from one VM to
another. We might be willing to accept the downside of allowing that
leakage, but I think it's worth mentioning that in the commit log.
Add blank lines between paragraphs (also in the comment below), or
rewrap into a single paragraph.
> Signed-off-by: Edmund Raile <edmund.raile@proton.me>
> ---
> Usefulness:
> The LSI FW643 PCIe->FireWire 800 interface may be EOL but it is
> the only one that does not use a PCIe->PCI bridge.
> It was used in the following Apple machines:
> MacBookPro10,1
> MacBookPro9,2
> MacBookPro6,2
> MacBookPro5,1
> Macmini6,1
> Macmini3,1
> iMac12,2
> iMac9,1
> iMac8,1
> It is reliable and enables FireWire audio interfaces to be used
> on modern machines.
> Virtualization allows for flexible access to professional audio
> software.
>
> Implementation:
> PCI_VENDOR_ID_ATT was reused as they are identical and I am
> uncertain it is correct to add another ID for LSI to pci_ids.h.
> drivers/pci/quirks.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index d797df6e5f3e..a6747e1b86da 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3765,6 +3765,15 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x003e, quirk_no_bus_reset);
> */
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CAVIUM, 0xa100, quirk_no_bus_reset);
>
> +/*
> + * Using LSI / Agere FW643 with vfio-pci will issue an FLreset, causing
> + * a broken link only recoverable by removing power (power-off /
> + * suspend + rescan). Prevent this bus reset.
> + * With this change, the device can be assigned to VMs with VFIO.
> + */
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATT, 0x5900, quirk_no_bus_reset);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATT, 0x5901, quirk_no_bus_reset);
> +
> /*
> * Some TI KeyStone C667X devices do not support bus/hot reset. The PCIESS
> * automatically disables LTSSM when Secondary Bus Reset is received and
> --
> 2.43.0
>
>
next prev parent reply other threads:[~2024-02-26 21:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 10:25 [PATCH] PCI: Mark LSI FW643 to avoid bus reset Edmund Raile
2024-02-26 21:02 ` Bjorn Helgaas [this message]
2024-02-27 13:14 ` [PATCH v2] " Edmund Raile
2024-02-29 23:00 ` Bjorn Helgaas
2024-03-25 1:21 ` Takashi Sakamoto
2024-03-25 14:41 ` Bjorn Helgaas
2024-03-26 13:18 ` Takashi Sakamoto
2024-03-27 15:01 ` Bjorn Helgaas
2024-03-28 20:42 ` Alex Williamson
2024-03-28 21:06 ` Bjorn Helgaas
2024-03-29 4:41 ` Lukas Wunner
2024-03-29 8:12 ` Takashi Sakamoto
2024-03-29 13:37 ` Lukas Wunner
2024-03-28 18:35 ` edmund.raile
2024-03-29 8:05 ` Takashi Sakamoto
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=20240226210228.GA199890@bhelgaas \
--to=helgaas@kernel.org \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=edmund.raile@proton.me \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.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.