From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: ankita@nvidia.com, aniketa@nvidia.com, cjia@nvidia.com,
kwankhede@nvidia.com, targupta@nvidia.com, vsethi@nvidia.com,
acurrid@nvidia.com, apopple@nvidia.com, jhubbard@nvidia.com,
danw@nvidia.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/1] vfio/nvgpu: Add vfio pci variant module for grace hopper
Date: Wed, 14 Jun 2023 14:55:28 -0300 [thread overview]
Message-ID: <ZIn/EHnCg444LJ3i@nvidia.com> (raw)
In-Reply-To: <20230613132402.2765b6cb.alex.williamson@redhat.com>
On Tue, Jun 13, 2023 at 01:24:02PM -0600, Alex Williamson wrote:
> I'd even forgotten about the sparse mmap solution here, that's even
> better than trying to do something clever with the mmap.
Okay, Ankit please try this, it sounds good
> > You may be right, I think this patch is trying to make things
> > automatic for user, but a dedicated machine type might make more
> > sense.
>
> Juan and I discussed this with Ankit last week, there are a lot of down
> sides with another machine type, but the automatic manipulation of the
> machine is still problematic. Another option we have is to use QEMU
> command line options for each feature. For example we already support
> NUMA VM configurations and loading command line ACPI tables, hopefully
> also associating devices to nodes. Do we end up with just a
> configuration spec for the VM to satisfy the in-guest drivers?
> Potentially guest driver requirements may changes over time, so a hard
> coded recipe built-in to QEMU might not be the best solution anyway.
Let's have those discussions settle then, I know there are a few
different ideas here people are looking at.
> I think NVIDIA might have an interest in enabling Atomic Ops support in
> VMs as well, so please comment in the series thread if there are
> concerns here or if anyone can definitively says that another guest OS
> we might care about does cache root port capability bits. Thanks,
I expect we do - I haven't heard of atomic ops specifically yet
though.
We just did a big exercise on relaxed ordering which is similarly
troubled.
Here we deciced to just not use the VM's config space at all. The
device itself knows if it can do relaxed ordering and it just reports
this directly to the driver.
In many ways I would prefer to do the same for atomic.. I haven't
checked fully but I think we do this anyhow as you can see mlx5 simply
tries to enable PCI atomics but doesn't appear to do anything with the
result of it. I expect the actual success/fail is looped back through
the device interface itself.
So, for mlx5, it probably already works in most real cases. Passing a
PF might not work I guess.
It is not a satisfying answer from a VMM design perspective..
Some qemu command line to say what root ports with what atomic caps to
create seems like a reasonable thing to do.
Jason
next prev parent reply other threads:[~2023-06-14 17:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 2:53 [PATCH v3 1/1] vfio/nvgpu: Add vfio pci variant module for grace hopper ankita
2023-06-06 14:32 ` Alex Williamson
2023-06-06 15:32 ` Jason Gunthorpe
2023-06-06 17:05 ` Alex Williamson
2023-06-06 17:16 ` Jason Gunthorpe
2023-06-06 18:13 ` Alex Williamson
2023-06-06 19:05 ` Jason Gunthorpe
2023-06-06 21:30 ` Alex Williamson
2023-06-07 0:14 ` Jason Gunthorpe
2023-06-07 18:23 ` Alex Williamson
2023-06-13 14:35 ` Jason Gunthorpe
2023-06-13 19:24 ` Alex Williamson
2023-06-14 17:55 ` Jason Gunthorpe [this message]
2023-06-14 19:20 ` Alex Williamson
2023-06-14 19:32 ` Jason Gunthorpe
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=ZIn/EHnCg444LJ3i@nvidia.com \
--to=jgg@nvidia.com \
--cc=acurrid@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=aniketa@nvidia.com \
--cc=ankita@nvidia.com \
--cc=apopple@nvidia.com \
--cc=cjia@nvidia.com \
--cc=danw@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=targupta@nvidia.com \
--cc=vsethi@nvidia.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