From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, alex.williamson@redhat.com,
osamaabb@amazon.com, linux-pci@vger.kernel.org,
Clint Sbisa <csbisa@amazon.com>
Subject: VFIO (PCI) and write combine mapping of BARs
Date: Fri, 14 Jul 2023 12:32:49 +1000 [thread overview]
Message-ID: <2838d716b08c78ed24fdd3fe392e21222ee70067.camel@kernel.crashing.org> (raw)
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 ?
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.
One trivial way would be to have an ioctl to set a flag for a given
region/BAR that cause subsequent mmap's to use write-combine. We would
have to keep a bitmap for the "legacy" regions, and use a flag in
struct vfio_pci_region for the others.
One potentially better way is to make it strictly an attribute of
vfio_pci_region, along with an ioctl that creates a "subregion". The
idea here is that we would have an ioctl to create a region from an
existing region dynamically, which represents a subset of the original
region (typically a BAR), with potentially different attributes (or we
keep the attribute get/set separate).
I like the latter more because it will allow to more easily define that
portions of a BAR can need different attributes without causing
state/race issues between setting the attribute and mmap.
This will also enable other attributes than write-combine if/when the
need arises.
Any better idea ? thoughs ? objections ?
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.
Cheers,
Ben.
next reply other threads:[~2023-07-14 2:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-14 2:32 Benjamin Herrenschmidt [this message]
2023-07-14 7:13 ` VFIO (PCI) and write combine mapping of BARs Lorenzo Pieralisi
2023-07-14 12:37 ` Jason Gunthorpe
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=2838d716b08c78ed24fdd3fe392e21222ee70067.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=alex.williamson@redhat.com \
--cc=csbisa@amazon.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.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;
as well as URLs for NNTP newsgroup(s).