From: Alex Williamson <alex.williamson@redhat.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
Joerg Roedel <joro@8bytes.org>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
David Gibson <david@gibson.dropbear.id.au>,
Jason Wang <jasowang@redhat.com>,
"parav@mellanox.com" <parav@mellanox.com>,
"Enrico Weigelt, metux IT consult" <lkml@metux.net>,
Paolo Bonzini <pbonzini@redhat.com>,
Shenming Lu <lushenming@huawei.com>,
Eric Auger <eric.auger@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
"Raj, Ashok" <ashok.raj@intel.com>,
"Liu, Yi L" <yi.l.liu@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
"Jiang, Dave" <dave.jiang@intel.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
Kirti Wankhede <kwankhede@nvidia.com>,
Robin Murphy <robin.murphy@arm.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
David Woodhouse <dwmw2@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Lu Baolu <baolu.lu@linux.intel.com>
Subject: Re: Plan for /dev/ioasid RFC v2
Date: Mon, 28 Jun 2021 17:09:02 -0600 [thread overview]
Message-ID: <20210628170902.61c0aa1d.alex.williamson@redhat.com> (raw)
In-Reply-To: <20210628224818.GJ4459@nvidia.com>
On Mon, 28 Jun 2021 19:48:18 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:
> On Mon, Jun 28, 2021 at 04:31:45PM -0600, Alex Williamson wrote:
>
> > I'd expect that /dev/iommu will be used by multiple subsystems. All
> > will want to bind devices to address spaces, so shouldn't binding a
> > device to an iommufd be an ioctl on the iommufd, ie.
> > IOMMU_BIND_VFIO_DEVICE_FD. Maybe we don't even need "VFIO" in there and
> > the iommufd code can figure it out internally.
>
> It wants to be the other way around because iommu_fd is the lower
> level subsystem. We don't/can't teach iommu_fd how to convert a fd
> number to a vfio/vdpa/etc/etc, we teach all the things building on
> iommu_fd how to change a fd number to an iommu - they already
> necessarily have an inter-module linkage.
These seem like peer subsystems, like vfio and kvm. vfio shouldn't
have any hard dependencies on the iommufd module, especially so long as
we have the legacy type1 code. Likewise iommufd shouldn't have any on
vfio. As much as you dislike the symbol_get hack of the kvm-vfio
device, it would be reasonable for iommufd to reach for a vfio symbol
when an IOMMU_BIND_VFIO_DEVICE_FD ioctl is called.
> There is a certain niceness to what you are saying but it is not so
> practical without doing something bigger..
>
> > Ideally vfio would also at least be able to register a type1 IOMMU
> > backend through the existing uapi, backed by this iommu code, ie. we'd
> > create a new "iommufd" (but without the user visible fd),
>
> It would be amazing to be able to achieve this, at least for me there
> are too many details be able to tell what that would look like
> exactly. I suggested once that putting the container ioctl interface
> in the drivers/iommu code may allow for this without too much trouble..
If we can't achieve this, then type1 legacy code is going to need to
live through an extended deprecation period. I'm hoping that between
type1 and a native interface we'll have two paths into iommufd to vet
the design. Thanks,
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Jason Wang <jasowang@redhat.com>,
Kirti Wankhede <kwankhede@nvidia.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
"Jiang, Dave" <dave.jiang@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
Jonathan Corbet <corbet@lwn.net>,
"Tian, Kevin" <kevin.tian@intel.com>,
"parav@mellanox.com" <parav@mellanox.com>,
"Enrico Weigelt, metux IT consult" <lkml@metux.net>,
David Gibson <david@gibson.dropbear.id.au>,
Robin Murphy <robin.murphy@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Shenming Lu <lushenming@huawei.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
Paolo Bonzini <pbonzini@redhat.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: Plan for /dev/ioasid RFC v2
Date: Mon, 28 Jun 2021 17:09:02 -0600 [thread overview]
Message-ID: <20210628170902.61c0aa1d.alex.williamson@redhat.com> (raw)
In-Reply-To: <20210628224818.GJ4459@nvidia.com>
On Mon, 28 Jun 2021 19:48:18 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:
> On Mon, Jun 28, 2021 at 04:31:45PM -0600, Alex Williamson wrote:
>
> > I'd expect that /dev/iommu will be used by multiple subsystems. All
> > will want to bind devices to address spaces, so shouldn't binding a
> > device to an iommufd be an ioctl on the iommufd, ie.
> > IOMMU_BIND_VFIO_DEVICE_FD. Maybe we don't even need "VFIO" in there and
> > the iommufd code can figure it out internally.
>
> It wants to be the other way around because iommu_fd is the lower
> level subsystem. We don't/can't teach iommu_fd how to convert a fd
> number to a vfio/vdpa/etc/etc, we teach all the things building on
> iommu_fd how to change a fd number to an iommu - they already
> necessarily have an inter-module linkage.
These seem like peer subsystems, like vfio and kvm. vfio shouldn't
have any hard dependencies on the iommufd module, especially so long as
we have the legacy type1 code. Likewise iommufd shouldn't have any on
vfio. As much as you dislike the symbol_get hack of the kvm-vfio
device, it would be reasonable for iommufd to reach for a vfio symbol
when an IOMMU_BIND_VFIO_DEVICE_FD ioctl is called.
> There is a certain niceness to what you are saying but it is not so
> practical without doing something bigger..
>
> > Ideally vfio would also at least be able to register a type1 IOMMU
> > backend through the existing uapi, backed by this iommu code, ie. we'd
> > create a new "iommufd" (but without the user visible fd),
>
> It would be amazing to be able to achieve this, at least for me there
> are too many details be able to tell what that would look like
> exactly. I suggested once that putting the container ioctl interface
> in the drivers/iommu code may allow for this without too much trouble..
If we can't achieve this, then type1 legacy code is going to need to
live through an extended deprecation period. I'm hoping that between
type1 and a native interface we'll have two paths into iommufd to vet
the design. Thanks,
Alex
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-06-28 23:09 UTC|newest]
Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 2:58 Plan for /dev/ioasid RFC v2 Tian, Kevin
2021-06-07 2:58 ` Tian, Kevin
2021-06-09 8:14 ` Eric Auger
2021-06-09 8:14 ` Eric Auger
2021-06-09 9:37 ` Tian, Kevin
2021-06-09 9:37 ` Tian, Kevin
2021-06-09 10:14 ` Eric Auger
2021-06-09 10:14 ` Eric Auger
2021-06-09 9:01 ` Leon Romanovsky
2021-06-09 9:01 ` Leon Romanovsky
2021-06-09 9:43 ` Tian, Kevin
2021-06-09 9:43 ` Tian, Kevin
2021-06-09 12:24 ` Joerg Roedel
2021-06-09 12:24 ` Joerg Roedel
2021-06-09 12:39 ` Jason Gunthorpe
2021-06-09 12:39 ` Jason Gunthorpe
2021-06-09 13:32 ` Joerg Roedel
2021-06-09 13:32 ` Joerg Roedel
2021-06-09 15:00 ` Jason Gunthorpe
2021-06-09 15:00 ` Jason Gunthorpe
2021-06-09 15:51 ` Joerg Roedel
2021-06-09 15:51 ` Joerg Roedel
2021-06-09 16:15 ` Alex Williamson
2021-06-09 16:15 ` Alex Williamson
2021-06-09 16:27 ` Alex Williamson
2021-06-09 16:27 ` Alex Williamson
2021-06-09 18:49 ` Jason Gunthorpe
2021-06-09 18:49 ` Jason Gunthorpe
2021-06-10 15:38 ` Alex Williamson
2021-06-10 15:38 ` Alex Williamson
2021-06-11 0:58 ` Tian, Kevin
2021-06-11 0:58 ` Tian, Kevin
2021-06-11 21:38 ` Alex Williamson
2021-06-11 21:38 ` Alex Williamson
2021-06-14 3:09 ` Tian, Kevin
2021-06-14 3:09 ` Tian, Kevin
2021-06-14 3:22 ` Alex Williamson
2021-06-14 3:22 ` Alex Williamson
2021-06-15 1:05 ` Tian, Kevin
2021-06-15 1:05 ` Tian, Kevin
2021-06-14 13:38 ` Jason Gunthorpe
2021-06-14 13:38 ` Jason Gunthorpe
2021-06-15 1:21 ` Tian, Kevin
2021-06-15 1:21 ` Tian, Kevin
2021-06-15 16:56 ` Alex Williamson
2021-06-15 16:56 ` Alex Williamson
2021-06-16 6:53 ` Tian, Kevin
2021-06-16 6:53 ` Tian, Kevin
2021-06-24 4:50 ` David Gibson
2021-06-24 4:50 ` David Gibson
2021-06-11 16:45 ` Jason Gunthorpe
2021-06-11 16:45 ` Jason Gunthorpe
2021-06-11 19:38 ` Alex Williamson
2021-06-11 19:38 ` Alex Williamson
2021-06-12 1:28 ` Jason Gunthorpe
2021-06-12 1:28 ` Jason Gunthorpe
2021-06-12 16:57 ` Alex Williamson
2021-06-12 16:57 ` Alex Williamson
2021-06-14 14:07 ` Jason Gunthorpe
2021-06-14 14:07 ` Jason Gunthorpe
2021-06-14 16:28 ` Alex Williamson
2021-06-14 16:28 ` Alex Williamson
2021-06-14 19:40 ` Jason Gunthorpe
2021-06-14 19:40 ` Jason Gunthorpe
2021-06-15 2:31 ` Tian, Kevin
2021-06-15 2:31 ` Tian, Kevin
2021-06-15 16:12 ` Alex Williamson
2021-06-15 16:12 ` Alex Williamson
2021-06-16 6:43 ` Tian, Kevin
2021-06-16 6:43 ` Tian, Kevin
2021-06-16 19:39 ` Alex Williamson
2021-06-16 19:39 ` Alex Williamson
2021-06-17 3:39 ` Liu Yi L
2021-06-17 3:39 ` Liu Yi L
2021-06-17 7:31 ` Tian, Kevin
2021-06-17 7:31 ` Tian, Kevin
2021-06-17 21:14 ` Alex Williamson
2021-06-17 21:14 ` Alex Williamson
2021-06-18 0:19 ` Jason Gunthorpe
2021-06-18 0:19 ` Jason Gunthorpe
2021-06-18 16:57 ` Tian, Kevin
2021-06-18 16:57 ` Tian, Kevin
2021-06-18 18:23 ` Jason Gunthorpe
2021-06-18 18:23 ` Jason Gunthorpe
2021-06-25 10:27 ` Tian, Kevin
2021-06-25 10:27 ` Tian, Kevin
2021-06-25 14:36 ` Jason Gunthorpe
2021-06-25 14:36 ` Jason Gunthorpe
2021-06-28 1:09 ` Tian, Kevin
2021-06-28 1:09 ` Tian, Kevin
2021-06-28 22:31 ` Alex Williamson
2021-06-28 22:31 ` Alex Williamson
2021-06-28 22:48 ` Jason Gunthorpe
2021-06-28 22:48 ` Jason Gunthorpe
2021-06-28 23:09 ` Alex Williamson [this message]
2021-06-28 23:09 ` Alex Williamson
2021-06-28 23:13 ` Jason Gunthorpe
2021-06-28 23:13 ` Jason Gunthorpe
2021-06-29 0:26 ` Tian, Kevin
2021-06-29 0:26 ` Tian, Kevin
2021-06-29 0:28 ` Tian, Kevin
2021-06-29 0:28 ` Tian, Kevin
2021-06-29 0:43 ` Tian, Kevin
2021-06-29 0:43 ` Tian, Kevin
2021-06-28 2:03 ` Tian, Kevin
2021-06-28 2:03 ` Tian, Kevin
2021-06-28 14:41 ` Jason Gunthorpe
2021-06-28 14:41 ` Jason Gunthorpe
2021-06-28 6:45 ` Tian, Kevin
2021-06-28 6:45 ` Tian, Kevin
2021-06-28 16:26 ` Jason Gunthorpe
2021-06-28 16:26 ` Jason Gunthorpe
2021-06-24 4:26 ` David Gibson
2021-06-24 4:26 ` David Gibson
2021-06-24 5:59 ` Tian, Kevin
2021-06-24 5:59 ` Tian, Kevin
2021-06-24 12:22 ` Lu Baolu
2021-06-24 12:22 ` Lu Baolu
2021-06-24 4:23 ` David Gibson
2021-06-24 4:23 ` David Gibson
2021-06-18 0:52 ` Jason Gunthorpe
2021-06-18 0:52 ` Jason Gunthorpe
2021-06-18 13:47 ` Joerg Roedel
2021-06-18 13:47 ` Joerg Roedel
2021-06-18 15:15 ` Jason Gunthorpe
2021-06-18 15:15 ` Jason Gunthorpe
2021-06-18 15:37 ` Raj, Ashok
2021-06-18 15:37 ` Raj, Ashok
2021-06-18 15:51 ` Alex Williamson
2021-06-18 15:51 ` Alex Williamson
2021-06-24 4:29 ` David Gibson
2021-06-24 4:29 ` David Gibson
2021-06-24 11:56 ` Jason Gunthorpe
2021-06-24 11:56 ` Jason Gunthorpe
2021-06-18 0:10 ` Jason Gunthorpe
2021-06-18 0:10 ` Jason Gunthorpe
2021-06-17 5:29 ` David Gibson
2021-06-17 5:29 ` David Gibson
2021-06-17 5:02 ` David Gibson
2021-06-17 5:02 ` David Gibson
2021-06-17 23:04 ` Jason Gunthorpe
2021-06-17 23:04 ` Jason Gunthorpe
2021-06-24 4:37 ` David Gibson
2021-06-24 4:37 ` David Gibson
2021-06-24 11:57 ` Jason Gunthorpe
2021-06-24 11:57 ` Jason Gunthorpe
2021-06-10 5:50 ` Lu Baolu
2021-06-10 5:50 ` Lu Baolu
2021-06-17 5:22 ` David Gibson
2021-06-17 5:22 ` David Gibson
2021-06-18 5:21 ` Lu Baolu
2021-06-18 5:21 ` Lu Baolu
2021-06-24 4:03 ` David Gibson
2021-06-24 4:03 ` David Gibson
2021-06-24 13:42 ` Lu Baolu
2021-06-24 13:42 ` Lu Baolu
2021-06-17 4:45 ` David Gibson
2021-06-17 4:45 ` David Gibson
2021-06-17 23:10 ` Jason Gunthorpe
2021-06-17 23:10 ` Jason Gunthorpe
2021-06-24 4:07 ` David Gibson
2021-06-24 4:07 ` David Gibson
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=20210628170902.61c0aa1d.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=corbet@lwn.net \
--cc=dave.jiang@intel.com \
--cc=david@gibson.dropbear.id.au \
--cc=dwmw2@infradead.org \
--cc=eric.auger@redhat.com \
--cc=hao.wu@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=jasowang@redhat.com \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@metux.net \
--cc=lushenming@huawei.com \
--cc=parav@mellanox.com \
--cc=pbonzini@redhat.com \
--cc=robin.murphy@arm.com \
--cc=yi.l.liu@intel.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.