From: Alex Williamson <alex.williamson@redhat.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Keith Busch <kbusch@meta.com>,
kvm@vger.kernel.org, Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH rfc] vfio-pci: Allow write combining
Date: Thu, 1 Aug 2024 11:33:44 -0600 [thread overview]
Message-ID: <20240801113344.1d5b5bfe.alex.williamson@redhat.com> (raw)
In-Reply-To: <20240801171355.GA4830@ziepe.ca>
On Thu, 1 Aug 2024 14:13:55 -0300
Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Thu, Aug 01, 2024 at 10:52:18AM -0600, Alex Williamson wrote:
> > > > vfio_region_info.flags in not currently tested for input therefore this
> > > > proposal could lead to unexpected behavior for a caller that doesn't
> > > > currently zero this field. It's intended as an output-only field.
> > >
> > > Perhaps a REGION_INFO2 then?
> > >
> > > I still think per-request is better than a global flag
> >
> > I don't understand why we'd need a REGION_INFO2, we already have
> > support for defining new regions.
>
> It is not a new region, it is a modified mmap behavior for an existing
> region.
If we're returning a different offset into the vfio device file from
which to get a WC mapping, what's the difference? A vfio "region" is
describing a region or range of the vfio device file descriptor.
Region indexes that map into the same device resource are not
fundamentally incompatible AFAICT, but it does mean that zapping user
access is not a nice contiguous single range.
> > We'd populate these new regions only for BARs that support prefetch and
> > mmap
>
> That's not the point, prefetch has nothing to do with write combining.
I was following the original proposal in this thread that added a
prefetch flag to REGION_INFO and allowed enabling WC only for
IORESOURCE_PREFETCH.
> Every BAR can be mapped writecombining, it is up to the VFIO userspace
> to understand if it can use it or not. The only use case for this
> feature would be something like in DPDK.
>
> VM side write combining is already handled by KVM allowing the VM to
> upgrade the page attributes to WC from NC.
>
> Doubling all the region indexes just for WC does not seem like a good
> idea to me...
Is the difference you see that in the REQ_WC proposal the user is
effectively asking vfio to pop a WC region into existence vs here
they're pre-populated? At the limit they're the same. We could use a
DEVICE_FEATURE to ask vfio to selectively populate WC regions after
which the user could re-enumerate additional regions, or in fact to
switch on WC for a given region if we want to go that route. Thanks,
Alex
next prev parent reply other threads:[~2024-08-01 17:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-31 15:53 [PATCH rfc] vfio-pci: Allow write combining Keith Busch
2024-08-01 14:19 ` Jason Gunthorpe
2024-08-01 15:41 ` Alex Williamson
2024-08-01 16:11 ` Jason Gunthorpe
2024-08-01 16:52 ` Alex Williamson
2024-08-01 17:13 ` Jason Gunthorpe
2024-08-01 17:33 ` Alex Williamson [this message]
2024-08-01 17:53 ` Jason Gunthorpe
2024-08-01 18:16 ` Alex Williamson
2024-08-02 11:53 ` Jason Gunthorpe
2024-08-02 17:05 ` Alex Williamson
2024-08-06 16:53 ` Jason Gunthorpe
2024-08-06 18:43 ` Alex Williamson
2024-08-07 14:19 ` Jason Gunthorpe
2024-08-07 17:46 ` Alex Williamson
2024-08-13 18:02 ` Jason Gunthorpe
2024-08-02 14:24 ` Keith Busch
2024-08-02 14:33 ` Jason Gunthorpe
2024-08-06 7:19 ` Tian, Kevin
2024-08-06 16:47 ` Jason Gunthorpe
2024-08-15 5:05 ` Christoph Hellwig
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=20240801113344.1d5b5bfe.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=jgg@ziepe.ca \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=kvm@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