From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.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: Thu, 17 Jun 2021 21:19:56 -0300 [thread overview]
Message-ID: <20210618001956.GA1987166@nvidia.com> (raw)
In-Reply-To: <20210617151452.08beadae.alex.williamson@redhat.com>
On Thu, Jun 17, 2021 at 03:14:52PM -0600, Alex Williamson wrote:
> I've referred to this as a limitation of type1, that we can't put
> devices within the same group into different address spaces, such as
> behind separate vRoot-Ports in a vIOMMU config, but really, who cares?
> As isolation support improves we see fewer multi-device groups, this
> scenario becomes the exception. Buy better hardware to use the devices
> independently.
This is basically my thinking too, but my conclusion is that we should
not continue to make groups central to the API.
As I've explained to David this is actually causing functional
problems and mess - and I don't see a clean way to keep groups central
but still have the device in control of what is happening. We need
this device <-> iommu connection to be direct to robustly model all
the things that are in the RFC.
To keep groups central someone needs to sketch out how to solve
today's mdev SW page table and mdev PASID issues in a clean
way. Device centric is my suggestion on how to make it clean, but I
haven't heard an alternative??
So, I view the purpose of this discussion to scope out what a
device-centric world looks like and then if we can securely fit in the
legacy non-isolated world on top of that clean future oriented
API. Then decide if it is work worth doing or not.
To my mind it looks like it is not so bad, granted not every detail is
clear, and no code has be sketched, but I don't see a big scary
blocker emerging. An extra ioctl or two, some special logic that
activates for >1 device groups that looks a lot like VFIO's current
logic..
At some level I would be perfectly fine if we made the group FD part
of the API for >1 device groups - except that complexifies every user
space implementation to deal with that. It doesn't feel like a good
trade off.
Jason
(I've been off this week so I didn't try to read/answer absolutely
everything, just a few things - though it looks like this is settling
down into 'kevin make a specific proposal' kind of situation..)
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.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: Thu, 17 Jun 2021 21:19:56 -0300 [thread overview]
Message-ID: <20210618001956.GA1987166@nvidia.com> (raw)
In-Reply-To: <20210617151452.08beadae.alex.williamson@redhat.com>
On Thu, Jun 17, 2021 at 03:14:52PM -0600, Alex Williamson wrote:
> I've referred to this as a limitation of type1, that we can't put
> devices within the same group into different address spaces, such as
> behind separate vRoot-Ports in a vIOMMU config, but really, who cares?
> As isolation support improves we see fewer multi-device groups, this
> scenario becomes the exception. Buy better hardware to use the devices
> independently.
This is basically my thinking too, but my conclusion is that we should
not continue to make groups central to the API.
As I've explained to David this is actually causing functional
problems and mess - and I don't see a clean way to keep groups central
but still have the device in control of what is happening. We need
this device <-> iommu connection to be direct to robustly model all
the things that are in the RFC.
To keep groups central someone needs to sketch out how to solve
today's mdev SW page table and mdev PASID issues in a clean
way. Device centric is my suggestion on how to make it clean, but I
haven't heard an alternative??
So, I view the purpose of this discussion to scope out what a
device-centric world looks like and then if we can securely fit in the
legacy non-isolated world on top of that clean future oriented
API. Then decide if it is work worth doing or not.
To my mind it looks like it is not so bad, granted not every detail is
clear, and no code has be sketched, but I don't see a big scary
blocker emerging. An extra ioctl or two, some special logic that
activates for >1 device groups that looks a lot like VFIO's current
logic..
At some level I would be perfectly fine if we made the group FD part
of the API for >1 device groups - except that complexifies every user
space implementation to deal with that. It doesn't feel like a good
trade off.
Jason
(I've been off this week so I didn't try to read/answer absolutely
everything, just a few things - though it looks like this is settling
down into 'kevin make a specific proposal' kind of situation..)
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-06-18 0:20 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 [this message]
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
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=20210618001956.GA1987166@nvidia.com \
--to=jgg@nvidia.com \
--cc=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=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.