linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"Alex Williamson (alex.williamson@redhat.com)" 
	<alex.williamson@redhat.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	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>,
	Joerg Roedel <joro@8bytes.org>,
	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: [RFC v2] /dev/iommu uAPI proposal
Date: Fri, 6 Aug 2021 09:32:11 -0300	[thread overview]
Message-ID: <20210806123211.GR1721383@nvidia.com> (raw)
In-Reply-To: <YQy+ZsCab6Ni/sN7@yekko>

On Fri, Aug 06, 2021 at 02:45:26PM +1000, David Gibson wrote:

> Well, that's kind of what I'm doing.  PCI currently has the notion of
> "default" address space for a RID, but there's no guarantee that other
> buses (or even future PCI extensions) will.  The idea is that
> "endpoint" means exactly the (RID, PASID) or (SID, SSID) or whatever
> future variations are on that.

This is already happening in this proposal, it is why I insisted that
the driver facing API has to be very explicit. That API specifies
exactly what the device silicon is doing.

However, that is placed at the IOASID level. There is no reason to
create endpoint objects that are 1:1 with IOASID objects, eg for
PASID.

We need to have clear software layers and responsibilities, I think
this is where the VFIO container design has fallen behind.

The device driver is responsible to delcare what TLPs the device it
controls will issue

The system layer is responsible to determine how those TLPs can be
matched to IO page tables, if at all

The IO page table layer is responsible to map the TLPs to physical
memory.

Each must stay in its box and we should not create objects that smush
together, say, the device and system layers because it will only make
a mess of the software design.

Since the system layer doesn't have any concrete objects in our
environment (which is based on devices and IO page tables) it has to
exist as metadata attached to the other two objects.

Jason

  reply	other threads:[~2021-08-06 12:32 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-09  7:48 [RFC v2] /dev/iommu uAPI proposal Tian, Kevin
2021-07-09 21:50 ` Alex Williamson
2021-07-12  1:22   ` Tian, Kevin
2021-07-12 18:41     ` Alex Williamson
2021-07-12 23:41       ` Tian, Kevin
2021-07-12 23:56       ` Tian, Kevin
2021-07-13 12:55         ` Jason Gunthorpe
2021-07-13 16:26           ` Alex Williamson
2021-07-13 16:32             ` Jason Gunthorpe
2021-07-13 22:48               ` Tian, Kevin
2021-07-13 23:02                 ` Jason Gunthorpe
2021-07-13 23:20                   ` Tian, Kevin
2021-07-13 23:22                     ` Jason Gunthorpe
2021-07-13 23:24                       ` Tian, Kevin
2021-07-15  3:20 ` Shenming Lu
2021-07-15  3:55   ` Tian, Kevin
2021-07-15  6:29     ` Shenming Lu
2021-07-15  6:49       ` Tian, Kevin
2021-07-15  8:14         ` Shenming Lu
2021-07-15 12:48         ` Jason Gunthorpe
2021-07-15 13:57           ` Raj, Ashok
2021-07-15 15:23             ` Jason Gunthorpe
2021-07-15 16:21               ` Raj, Ashok
2021-07-15 17:18                 ` Jason Gunthorpe
2021-07-15 17:48                   ` Raj, Ashok
2021-07-15 17:53                     ` Jason Gunthorpe
2021-07-15 18:05                       ` Raj, Ashok
2021-07-15 18:13                         ` Jason Gunthorpe
2021-07-16  1:20                           ` Tian, Kevin
2021-07-16 12:20                             ` Shenming Lu
2021-07-21  2:13                               ` Tian, Kevin
2021-07-22 16:30                                 ` Jason Gunthorpe
2021-07-16 18:30                             ` Jason Gunthorpe
2021-07-21  2:11                               ` Tian, Kevin
2021-07-26  4:50 ` David Gibson
2021-07-28  4:04   ` Tian, Kevin
2021-08-03  1:50     ` David Gibson
2021-08-03  3:19       ` Tian, Kevin
2021-08-06  4:45         ` David Gibson
2021-08-06 12:32           ` Jason Gunthorpe [this message]
2021-08-10  6:10             ` David Gibson
2021-08-09  8:34           ` Tian, Kevin
2021-08-10  4:47             ` David Gibson
2021-08-10  6:04               ` Tian, Kevin
2021-07-30 14:51   ` Jason Gunthorpe
2021-08-02  2:49     ` Tian, Kevin
2021-08-04 14:04       ` Jason Gunthorpe
2021-08-04 22:59         ` Tian, Kevin
2021-08-05 11:27           ` Jason Gunthorpe
2021-08-05 22:44             ` Tian, Kevin
2021-08-06  4:47         ` David Gibson
2021-08-03  1:58     ` David Gibson
2021-08-04 14:07       ` Jason Gunthorpe
2021-08-06  4:24         ` David Gibson
2021-07-26  8:14 ` Jean-Philippe Brucker
2021-07-28  4:05   ` Tian, Kevin
2021-08-04 15:59 ` Eric Auger
2021-08-05  0:36   ` Tian, Kevin
2021-08-10  7:17     ` Eric Auger
2021-08-10  9:00       ` Tian, Kevin

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=20210806123211.GR1721383@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).