From: "Michael S. Tsirkin" <mst@redhat.com>
To: Robin Voetter <robin@streamhpc.com>
Cc: qemu-devel@nongnu.org,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH 0/1] pcie: Allow atomic completion on PCIE root port
Date: Thu, 18 May 2023 16:03:07 -0400 [thread overview]
Message-ID: <20230518160043-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <5330c419-bcdb-8577-4ed0-88a483f461e8@streamhpc.com>
On Fri, Apr 21, 2023 at 06:06:49PM +0200, Robin Voetter wrote:
>
>
> On 4/21/23 10:22, Michael S. Tsirkin wrote:
> > On Thu, Apr 20, 2023 at 05:38:39PM +0200, robin@streamhpc.com wrote:
> >> From: Robin Voetter <robin@streamhpc.com>
> >>
> >> The ROCm driver for Linux uses PCIe atomics to schedule work and
> >> generally communicate between the host and the device. This does not
> >> currently work in QEMU with regular vfio-pci passthrough, because the
> >> pcie-root-port does not advertise the PCIe atomic completer
> >> capabilities. When initializing the GPU from the Linux driver, it
> >> queries whether the PCIe connection from the CPU to GPU supports the
> >> required capabilities[1] in the pci_enable_atomic_ops_to_root
> >> function[2]. Currently the only part where this fails is checking the
> >> atomic completer capabilities (32 and 64 bits) on the root port[3]. In
> >> this case, the driver determines that PCIe atomics are not supported at
> >> all, and this causes ROCm programs to misbehave. (While AMD advertises
> >> that there is some support for ROCm without PCIe atomics, I have never
> >> actually gotten that working...)
> >>
> >> This patch allows ROCm to properly function by introducing an
> >> additional experimental property to the pcie-root-port,
> >> x-atomic-completion.
> >
> > so what exactly makes it experimental? from this description
> > it looks like it actually has to be enabled for things to work?
>
> I was not sure which would be appropriate, but I'm fine with making it a
> non-experimental option.
So I guess the real thing to do is to query this from vfio right?
Unfortunately we don't have access to vfio when we
are creating the root port, but I think the thing to do would
be to check at the time when vfio is attached, and if
atomic is set but not supported, fail attaching vfio.
Right?
--
MST
next prev parent reply other threads:[~2023-05-18 20:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-20 15:38 [PATCH 0/1] pcie: Allow atomic completion on PCIE root port robin
2023-04-20 15:38 ` [PATCH 1/1] pcie: Allow generic PCIE root port to enable atomic completion robin
2023-04-21 8:22 ` [PATCH 0/1] pcie: Allow atomic completion on PCIE root port Michael S. Tsirkin
2023-04-21 16:06 ` Robin Voetter
2023-05-18 20:03 ` Michael S. Tsirkin [this message]
2023-05-18 22:13 ` Alex Williamson
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=20230518160043-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=robin@streamhpc.com \
/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).