From: "Michael S. Tsirkin" <mst@redhat.com>
To: Steven Sistare <steven.sistare@oracle.com>
Cc: virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, Jason Wang <jasowang@redhat.com>,
Si-Wei Liu <si-wei.liu@oracle.com>,
Eugenio Perez Martin <eperezma@redhat.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
Dragos Tatulea <dtatulea@nvidia.com>
Subject: Re: [PATCH V2 3/7] vhost-vdpa: VHOST_NEW_OWNER
Date: Mon, 15 Jul 2024 10:38:09 -0400 [thread overview]
Message-ID: <20240715103021-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <d414f28e-8887-418f-963a-bb986dbdcaea@oracle.com>
On Mon, Jul 15, 2024 at 10:29:26AM -0400, Steven Sistare wrote:
> On 7/15/2024 5:07 AM, Michael S. Tsirkin wrote:
> > On Fri, Jul 12, 2024 at 06:18:49AM -0700, Steve Sistare wrote:
> > > Add an ioctl to transfer file descriptor ownership and pinned memory
> > > accounting from one process to another.
> > >
> > > This is more efficient than VHOST_RESET_OWNER followed by VHOST_SET_OWNER,
> > > as that would unpin all physical pages, requiring them to be repinned in
> > > the new process. That would cost multiple seconds for large memories, and
> > > be incurred during a virtual machine's pause time during live update.
> > >
> > > Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
> >
> > Please, we just need to switch to use iommufd for pinning.
> > Piling up all these hacks gets us nowhere.
>
> I am working on iommufd kernel interfaces and QEMU changes. But who is working
> on iommufd support for vdpa? If no one, or not for years, then adding these
> small interfaces to vdpa plugs a signficant gap in live update coverage.
>
> FWIW, the iommufd interfaces for live update will look much the same: change owner
> and pinned memory accounting, and update virtual addresses. So adding that to vdpa
> will not make it look like an odd duck.
>
> - Steve
I think that no one is working on it - Cindy posted some rfcs in January
("vhost-vdpa: add support for iommufd"). Feel free to pick that up.
What you described is just more of a reason not to duplicate this code.
And it's always the same: a small extension here, a small extension there.
If you can make do with existing kernel interfaces, fine,
one can argue that userspace code is useful to support existing kernels.
--
MST
next prev parent reply other threads:[~2024-07-15 14:38 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-12 13:18 [PATCH V2 0/7] vdpa live update Steve Sistare
2024-07-12 13:18 ` [PATCH V2 1/7] vhost-vdpa: count pinned memory Steve Sistare
2024-07-12 13:18 ` [PATCH V2 2/7] vhost-vdpa: pass mm to bind Steve Sistare
2024-07-12 13:18 ` [PATCH V2 3/7] vhost-vdpa: VHOST_NEW_OWNER Steve Sistare
2024-07-15 2:26 ` Jason Wang
2024-07-15 9:06 ` Michael S. Tsirkin
2024-07-15 14:27 ` Steven Sistare
2024-07-16 5:16 ` Jason Wang
2024-07-17 18:28 ` Steven Sistare
2024-07-22 7:26 ` Jason Wang
2024-07-15 9:07 ` Michael S. Tsirkin
2024-07-15 14:29 ` Steven Sistare
2024-07-15 14:38 ` Michael S. Tsirkin [this message]
2024-07-15 15:38 ` Steven Sistare
2024-07-12 13:18 ` [PATCH V2 4/7] vhost-vdpa: VHOST_BACKEND_F_NEW_OWNER Steve Sistare
2024-07-15 2:31 ` Jason Wang
2024-07-15 14:27 ` Steven Sistare
2024-07-12 13:18 ` [PATCH V2 5/7] vhost-vdpa: VHOST_IOTLB_REMAP Steve Sistare
2024-07-15 2:34 ` Jason Wang
2024-07-15 14:28 ` Steven Sistare
2024-07-16 5:28 ` Jason Wang
2024-07-17 18:29 ` Steven Sistare
2024-07-18 0:45 ` Jason Wang
2024-07-18 19:39 ` Michael S. Tsirkin
2024-07-18 20:19 ` Steven Sistare
2024-07-19 1:01 ` Jason Wang
2024-07-12 13:18 ` [PATCH V2 6/7] vhost-vdpa: VHOST_BACKEND_F_IOTLB_REMAP Steve Sistare
2024-07-12 13:18 ` [PATCH V2 7/7] vdpa/mlx5: new owner capability Steve Sistare
2024-07-12 14:06 ` [PATCH V2 0/7] vdpa live update Steven Sistare
2024-07-15 2:14 ` Jason Wang
2024-07-15 14:28 ` Steven Sistare
2024-07-16 5:30 ` Jason Wang
2024-07-17 18:29 ` Steven Sistare
2024-07-18 0:33 ` Jason Wang
2024-07-20 21:34 ` Steven Sistare
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=20240715103021-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=dtatulea@nvidia.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=si-wei.liu@oracle.com \
--cc=steven.sistare@oracle.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=xuanzhuo@linux.alibaba.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 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.