All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	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>,
	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: Tue, 13 Jul 2021 20:22:44 -0300	[thread overview]
Message-ID: <20210713232244.GJ136586@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB54331F80DA135AF3EAD025998C149@BN9PR11MB5433.namprd11.prod.outlook.com>

On Tue, Jul 13, 2021 at 11:20:12PM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Wednesday, July 14, 2021 7:03 AM
> > 
> > On Tue, Jul 13, 2021 at 10:48:38PM +0000, Tian, Kevin wrote:
> > 
> > > We can still bind to the parent with cookie, but with
> > > iommu_register_ sw_device() IOMMU fd knows that this binding doesn't
> > > need to establish any security context via IOMMU API.
> > 
> > AFAIK there is no reason to involve the parent PCI or other device in
> > SW mode. The iommufd doesn't need to be aware of anything there.
> > 
> 
> Yes. but does it makes sense to have an unified model in IOMMU fd
> which always have a [struct device, cookie] with flags to indicate whether 
> the binding/attaching should be specially handled for sw mdev? Or
> are you suggesting that lacking of struct device is actually the indicator
> for such trick?

I think you've veered into such micro implementation details that it
is better to wait and see how things look.

The important point here is that whatever physical device is under a
SW mdev does not need to be passed to the iommufd because there is
nothing it can do with that information.

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.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>,
	"parav@mellanox.com" <parav@mellanox.com>,
	Alex Williamson <alex.williamson@redhat.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: [RFC v2] /dev/iommu uAPI proposal
Date: Tue, 13 Jul 2021 20:22:44 -0300	[thread overview]
Message-ID: <20210713232244.GJ136586@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB54331F80DA135AF3EAD025998C149@BN9PR11MB5433.namprd11.prod.outlook.com>

On Tue, Jul 13, 2021 at 11:20:12PM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Wednesday, July 14, 2021 7:03 AM
> > 
> > On Tue, Jul 13, 2021 at 10:48:38PM +0000, Tian, Kevin wrote:
> > 
> > > We can still bind to the parent with cookie, but with
> > > iommu_register_ sw_device() IOMMU fd knows that this binding doesn't
> > > need to establish any security context via IOMMU API.
> > 
> > AFAIK there is no reason to involve the parent PCI or other device in
> > SW mode. The iommufd doesn't need to be aware of anything there.
> > 
> 
> Yes. but does it makes sense to have an unified model in IOMMU fd
> which always have a [struct device, cookie] with flags to indicate whether 
> the binding/attaching should be specially handled for sw mdev? Or
> are you suggesting that lacking of struct device is actually the indicator
> for such trick?

I think you've veered into such micro implementation details that it
is better to wait and see how things look.

The important point here is that whatever physical device is under a
SW mdev does not need to be passed to the iommufd because there is
nothing it can do with that information.

Jason
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2021-07-13 23:22 UTC|newest]

Thread overview: 120+ 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  7:48 ` Tian, Kevin
2021-07-09 21:50 ` Alex Williamson
2021-07-09 21:50   ` Alex Williamson
2021-07-12  1:22   ` Tian, Kevin
2021-07-12  1:22     ` Tian, Kevin
2021-07-12 18:41     ` Alex Williamson
2021-07-12 18:41       ` Alex Williamson
2021-07-12 23:41       ` Tian, Kevin
2021-07-12 23:41         ` Tian, Kevin
2021-07-12 23:56       ` Tian, Kevin
2021-07-12 23:56         ` Tian, Kevin
2021-07-13 12:55         ` Jason Gunthorpe
2021-07-13 12:55           ` Jason Gunthorpe
2021-07-13 16:26           ` Alex Williamson
2021-07-13 16:26             ` Alex Williamson
2021-07-13 16:32             ` Jason Gunthorpe
2021-07-13 16:32               ` Jason Gunthorpe
2021-07-13 22:48               ` Tian, Kevin
2021-07-13 22:48                 ` Tian, Kevin
2021-07-13 23:02                 ` Jason Gunthorpe
2021-07-13 23:02                   ` Jason Gunthorpe
2021-07-13 23:20                   ` Tian, Kevin
2021-07-13 23:20                     ` Tian, Kevin
2021-07-13 23:22                     ` Jason Gunthorpe [this message]
2021-07-13 23:22                       ` Jason Gunthorpe
2021-07-13 23:24                       ` Tian, Kevin
2021-07-13 23:24                         ` Tian, Kevin
2021-07-15  3:20 ` Shenming Lu
2021-07-15  3:20   ` Shenming Lu
2021-07-15  3:55   ` Tian, Kevin
2021-07-15  3:55     ` Tian, Kevin
2021-07-15  6:29     ` Shenming Lu
2021-07-15  6:29       ` Shenming Lu
2021-07-15  6:49       ` Tian, Kevin
2021-07-15  6:49         ` Tian, Kevin
2021-07-15  8:14         ` Shenming Lu
2021-07-15  8:14           ` Shenming Lu
2021-07-15 12:48         ` Jason Gunthorpe
2021-07-15 12:48           ` Jason Gunthorpe via iommu
2021-07-15 13:57           ` Raj, Ashok
2021-07-15 13:57             ` Raj, Ashok
2021-07-15 15:23             ` Jason Gunthorpe
2021-07-15 15:23               ` Jason Gunthorpe via iommu
2021-07-15 16:21               ` Raj, Ashok
2021-07-15 16:21                 ` Raj, Ashok
2021-07-15 17:18                 ` Jason Gunthorpe
2021-07-15 17:18                   ` Jason Gunthorpe via iommu
2021-07-15 17:48                   ` Raj, Ashok
2021-07-15 17:48                     ` Raj, Ashok
2021-07-15 17:53                     ` Jason Gunthorpe
2021-07-15 17:53                       ` Jason Gunthorpe via iommu
2021-07-15 18:05                       ` Raj, Ashok
2021-07-15 18:05                         ` Raj, Ashok
2021-07-15 18:13                         ` Jason Gunthorpe
2021-07-15 18:13                           ` Jason Gunthorpe via iommu
2021-07-16  1:20                           ` Tian, Kevin
2021-07-16  1:20                             ` Tian, Kevin
2021-07-16 12:20                             ` Shenming Lu
2021-07-16 12:20                               ` Shenming Lu
2021-07-21  2:13                               ` Tian, Kevin
2021-07-21  2:13                                 ` Tian, Kevin
2021-07-22 16:30                                 ` Jason Gunthorpe
2021-07-22 16:30                                   ` Jason Gunthorpe via iommu
2021-07-16 18:30                             ` Jason Gunthorpe
2021-07-16 18:30                               ` Jason Gunthorpe via iommu
2021-07-21  2:11                               ` Tian, Kevin
2021-07-21  2:11                                 ` Tian, Kevin
2021-07-26  4:50 ` David Gibson
2021-07-26  4:50   ` David Gibson
2021-07-28  4:04   ` Tian, Kevin
2021-07-28  4:04     ` Tian, Kevin
2021-08-03  1:50     ` David Gibson
2021-08-03  1:50       ` David Gibson
2021-08-03  3:19       ` Tian, Kevin
2021-08-03  3:19         ` Tian, Kevin
2021-08-06  4:45         ` David Gibson
2021-08-06  4:45           ` David Gibson
2021-08-06 12:32           ` Jason Gunthorpe
2021-08-06 12:32             ` Jason Gunthorpe via iommu
2021-08-10  6:10             ` David Gibson
2021-08-10  6:10               ` David Gibson
2021-08-09  8:34           ` Tian, Kevin
2021-08-09  8:34             ` Tian, Kevin
2021-08-10  4:47             ` David Gibson
2021-08-10  4:47               ` David Gibson
2021-08-10  6:04               ` Tian, Kevin
2021-08-10  6:04                 ` Tian, Kevin
2021-07-30 14:51   ` Jason Gunthorpe
2021-07-30 14:51     ` Jason Gunthorpe via iommu
2021-08-02  2:49     ` Tian, Kevin
2021-08-02  2:49       ` Tian, Kevin
2021-08-04 14:04       ` Jason Gunthorpe
2021-08-04 14:04         ` Jason Gunthorpe via iommu
2021-08-04 22:59         ` Tian, Kevin
2021-08-04 22:59           ` Tian, Kevin
2021-08-05 11:27           ` Jason Gunthorpe
2021-08-05 11:27             ` Jason Gunthorpe via iommu
2021-08-05 22:44             ` Tian, Kevin
2021-08-05 22:44               ` Tian, Kevin
2021-08-06  4:47         ` David Gibson
2021-08-06  4:47           ` David Gibson
2021-08-03  1:58     ` David Gibson
2021-08-03  1:58       ` David Gibson
2021-08-04 14:07       ` Jason Gunthorpe
2021-08-04 14:07         ` Jason Gunthorpe via iommu
2021-08-06  4:24         ` David Gibson
2021-08-06  4:24           ` David Gibson
2021-07-26  8:14 ` Jean-Philippe Brucker
2021-07-26  8:14   ` Jean-Philippe Brucker
2021-07-28  4:05   ` Tian, Kevin
2021-07-28  4:05     ` Tian, Kevin
2021-08-04 15:59 ` Eric Auger
2021-08-04 15:59   ` Eric Auger
2021-08-05  0:36   ` Tian, Kevin
2021-08-05  0:36     ` Tian, Kevin
2021-08-10  7:17     ` Eric Auger
2021-08-10  7:17       ` Eric Auger
2021-08-10  9:00       ` Tian, Kevin
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=20210713232244.GJ136586@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.