From: Bjorn Helgaas <helgaas@kernel.org>
To: David Jaundrew <david@jaundrew.com>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
linux-pci@vger.kernel.org,
"Alex Williamson" <alex.williamson@redhat.com>,
"Alexander Deucher" <Alexander.Deucher@amd.com>,
"Nehal-bakulchandra Shah" <Nehal-bakulchandra.Shah@amd.com>,
"Christian Koenig" <Christian.Koenig@amd.com>,
"Krzysztof Wilczyński" <kw@linux.com>
Subject: Re: [PATCH] Avoid FLR for AMD Starship/Matisse Cryptographic Coprocessor
Date: Tue, 28 Sep 2021 20:59:02 -0500 [thread overview]
Message-ID: <20210929015902.GA753214@bhelgaas> (raw)
In-Reply-To: <9e85bcad-a73c-cccd-4522-a45e599309d7@jaundrew.com>
[+cc Alex, Krzysztof, AMD folks]
On Tue, Sep 28, 2021 at 05:16:49PM -0700, David Jaundrew wrote:
> This patch fixes another FLR bug for the Starship/Matisse controller:
>
> AMD Starship/Matisse Cryptogrpahic Coprocessor PSPCPP
>
> This patch allows functions on the same Starship/Matisse device (such as
> USB controller,sound card) to properly pass through to a guest OS using
> vfio-pc. Without this patch, the virtual machine does not boot and
> eventually times out.
Apparently yet another AMD device that advertises FLR support, but it
doesn't work?
I don't have a problem avoiding the FLR, but I *would* like some
indication that:
- This is a known erratum and AMD has some plan to fix this in
future devices so we don't have to trip over them all
individually, and
- This is not a security issue. Part of the reason VFIO resets
pass-through devices is to avoid leaking state from one guest to
another. If reset doesn't work, that makes me wonder, especially
since this is a cryptographic coprocessor that sounds like it
might be full of secrets. So I *assume* VFIO will use a different
type of reset instead of FLR, but I'm just double-checking.
> Excerpt from lspci -nn showing crypto function on same device as USB and
> sound card (which are already listed in quirks.c):
>
> 0e:00.1 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD]
> Starship/Matisse Cryptographic Coprocessor PSPCPP [1022:1486]
> 0e:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
> Matisse USB 3.0 Host Controller [1022:149c]
> 0e:00.4 Audio device [0403]: Advanced Micro Devices, Inc. [AMD]
> Starship/Matisse HD Audio Controller [1022:1487]
>
> Fix tested successfully on an Asus ROG STRIX X570-E GAMING motherboard
> with AMD Ryzen 9 3900X.
>
> Signed-off-by: David Jaundrew <david@jaundrew.com>
The patch below still doesn't apply. Looks like maybe it was pasted
into the email and the tabs got changed to space? No worries, I can
apply it manually if appropriate.
> ---
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 6d74386eadc2..0d19e7aa219a 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -5208,6 +5208,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x443, quirk_intel_qat_vf_cap);
> /*
> * FLR may cause the following to devices to hang:
> *
> + * AMD Starship/Matisse Cryptographic Coprocessor PSPCPP 0x1486
> * AMD Starship/Matisse HD Audio Controller 0x1487
> * AMD Starship USB 3.0 Host Controller 0x148c
> * AMD Matisse USB 3.0 Host Controller 0x149c
> @@ -5219,6 +5220,7 @@ static void quirk_no_flr(struct pci_dev *dev)
> {
> dev->dev_flags |= PCI_DEV_FLAGS_NO_FLR_RESET;
> }
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1486, quirk_no_flr);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1487, quirk_no_flr);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x148c, quirk_no_flr);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x149c, quirk_no_flr);
>
next prev parent reply other threads:[~2021-09-29 1:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-31 5:17 [PATCH] Avoid FLR for AMD Starship/Matisse Cryptographic Coprocessor David Jaundrew
2021-09-28 21:45 ` Bjorn Helgaas
2021-09-29 0:16 ` David Jaundrew
2021-09-29 0:21 ` Krzysztof Wilczyński
2021-09-29 1:59 ` Bjorn Helgaas [this message]
2021-09-29 13:09 ` Deucher, Alexander
2021-09-29 18:26 ` Alex Williamson
2021-09-29 18:50 ` Bjorn Helgaas
2021-09-29 19:34 ` Alex Williamson
2021-09-29 20:07 ` Deucher, Alexander
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=20210929015902.GA753214@bhelgaas \
--to=helgaas@kernel.org \
--cc=Alexander.Deucher@amd.com \
--cc=Christian.Koenig@amd.com \
--cc=Nehal-bakulchandra.Shah@amd.com \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=david@jaundrew.com \
--cc=kw@linux.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox