From: Jason Gunthorpe <jgg@nvidia.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
alex.williamson@redhat.com, osamaabb@amazon.com,
linux-pci@vger.kernel.org, Clint Sbisa <csbisa@amazon.com>,
catalin.marinas@arm.com, maz@kernel.org
Subject: Re: VFIO (PCI) and write combine mapping of BARs
Date: Fri, 14 Jul 2023 09:37:48 -0300 [thread overview]
Message-ID: <ZLFBnACjoTbDmKuU@nvidia.com> (raw)
In-Reply-To: <ZLD1l1274hQQ54RT@lpieralisi>
On Fri, Jul 14, 2023 at 09:13:27AM +0200, Lorenzo Pieralisi wrote:
> [+Catalin, Marc, Jason]
>
> On Fri, Jul 14, 2023 at 12:32:49PM +1000, Benjamin Herrenschmidt wrote:
> > Hi Folks !
> >
> > I'd like to revive an old discussion as we (Amazon Linux) have been
> > getting asks for it.
> >
> > What's the best interface to provide the option of write combine mmap's
> > of BARs via VFIO ?
>
> There is an ongoing thread on this topic that we should use to
> bring this discussion to completion:
>
> https://lore.kernel.org/linux-arm-kernel/ZHcxHbCb439I1Uk2@arm.com
There are two topics here
1) Make ARM KVM allow the VM to select WC for its MMIO. This has
evolved in a way that is not related to VFIO
2) Allow VFIO to create mmaps with WC for non-VM use cases like DPDK.
We have a draft patch for #1, and I think a general understanding with
ARM folks that this is the right direction.
2 is more like what this email talks about - providing mmaps with
specific flags.
Benjamin, which are you interested in?
> > The problem isn't so much the low level implementation, we just have to
> > play with the pgprot, the question is more around what API to present
> > to control this.
Assuming this is for #2, I think VFIO has fallen into a bit of a trap
by allowing userspace to form the mmap offset. I've seen this happen
in other subsystems too. It seems like a good idea then you realize
you need more stuff in the mmap space and become sad.
Typically the way out is to covert the mmap offset into a cookie where
userspace issues some ioctl and then the ioctl returns an opaque mmap
offset to use.
eg in the vfio context you'd do some 'prepare region for mmap' ioctl
where you could specify flags. The kernel would encode the flags in
the cookie and then mmap would do the right thing. Adding more stuff
is done by enhancing the prepare ioctl.
Legacy mmap offsets are kept working.
> > This is still quite specific to PCI, but so is the entire regions
> > mechanism, so I don't see an easy path to something more generic at
> > this stage.
Regions are general, but the encoding of the mmap cookie has various
PCI semantics when used with the PCI interface..
We'd want the same ability with platform devices too, for instance.
Jason
next prev parent reply other threads:[~2023-07-14 12:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-14 2:32 VFIO (PCI) and write combine mapping of BARs Benjamin Herrenschmidt
2023-07-14 7:13 ` Lorenzo Pieralisi
2023-07-14 12:37 ` Jason Gunthorpe [this message]
2023-07-25 6:15 ` Benjamin Herrenschmidt
2023-07-25 11:39 ` Jason Gunthorpe
2023-07-26 1:19 ` Benjamin Herrenschmidt
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=ZLFBnACjoTbDmKuU@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=csbisa@amazon.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=maz@kernel.org \
--cc=osamaabb@amazon.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