From: Jason Gunthorpe <jgg@ziepe.ca>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: David Hildenbrand <david@redhat.com>,
lizhe.67@bytedance.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, muchun.song@linux.dev
Subject: Re: [PATCH v3] vfio/type1: optimize vfio_pin_pages_remote() for huge folio
Date: Wed, 28 May 2025 21:51:47 -0300 [thread overview]
Message-ID: <20250529005147.GC192517@ziepe.ca> (raw)
In-Reply-To: <20250528140941.151b2f70.alex.williamson@redhat.com>
On Wed, May 28, 2025 at 02:09:41PM -0600, Alex Williamson wrote:
> To be fair to libvirt, we'd really like libvirt to make use of iommufd
> whenever it's available, but without feature parity this would break
> users.
If people ask there should be no issue with making API functionality
discoverable with a query command of some kind. Alot of new stuff is
already discoverable by invoking an ioctl with bogus arguments and
checking for EOPNOTSUPP/ENOTTY.
But most likely P2P will use the same ioctl as memfd so it will not
work that way.
So for now libvirt could assume no P2P support in iommufd. A simple
algorithm would be to look for more than 1 VFIO device. Or add an xml
"disable P2P" which is a useful thing anyhow.
> Zhe, so if you have no dependencies on P2P DMA within your device
> assignment VMs, the options above may be useful or at least a data
> point for comparison of type1 vs IOMMUFD performance. Thanks,
Even if Zhe does have P2P DMA I have a feeling the OOT P2P patch may
be workable <shrug>
Jason
next prev parent reply other threads:[~2025-05-29 0:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-20 7:00 [PATCH v3] vfio/type1: optimize vfio_pin_pages_remote() for huge folio lizhe.67
2025-05-20 14:07 ` Alex Williamson
2025-05-20 16:59 ` Peter Xu
2025-05-20 17:41 ` David Hildenbrand
2025-05-20 21:56 ` Alex Williamson
2025-05-21 3:34 ` lizhe.67
2025-05-20 17:38 ` David Hildenbrand
2025-05-20 22:21 ` Alex Williamson
2025-05-21 6:35 ` David Hildenbrand
2025-05-21 15:40 ` Peter Xu
2025-05-21 16:02 ` David Hildenbrand
2025-05-21 16:55 ` Alex Williamson
2025-05-26 20:19 ` Jason Gunthorpe
2025-05-27 19:52 ` Alex Williamson
2025-05-27 23:46 ` Jason Gunthorpe
2025-05-28 20:09 ` Alex Williamson
2025-05-29 0:51 ` Jason Gunthorpe [this message]
2025-05-29 2:58 ` Alex Williamson
2025-05-29 4:31 ` lizhe.67
2025-05-21 3:45 ` lizhe.67
2025-05-20 23:37 ` kernel test robot
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=20250529005147.GC192517@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=alex.williamson@redhat.com \
--cc=david@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizhe.67@bytedance.com \
--cc=muchun.song@linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.