All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Yi Liu <yi.l.liu@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
	"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
	"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"shameerali.kolothum.thodi@huawei.com"
	<shameerali.kolothum.thodi@huawei.com>,
	"lulu@redhat.com" <lulu@redhat.com>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
	"joao.m.martins@oracle.com" <joao.m.martins@oracle.com>,
	"Zeng, Xin" <xin.zeng@intel.com>,
	"Zhao, Yan Y" <yan.y.zhao@intel.com>
Subject: Re: [PATCH v7 1/3] iommufd: Add data structure for Intel VT-d stage-1 cache invalidation
Date: Wed, 3 Jan 2024 08:48:46 -0800	[thread overview]
Message-ID: <ZZWP7iBqUtbTRb3s@Asurada-Nvidia> (raw)
In-Reply-To: <20240103160108.GP50406@nvidia.com>

On Wed, Jan 03, 2024 at 12:01:08PM -0400, Jason Gunthorpe wrote:
> On Wed, Jan 03, 2024 at 10:24:42AM +0800, Yi Liu wrote:
> > On 2024/1/3 07:38, Jason Gunthorpe wrote:
> > > On Fri, Dec 15, 2023 at 12:01:19PM +0800, Yi Liu wrote:
> > > > > I think I misread Yi's narrative: dev_id is a working approach
> > > > > for VMM to convert to a vRID, while he is asking for a better
> > > > > alternative :)
> > > > 
> > > > In concept, dev_id works, but in reality we have problem to get a dev_id
> > > > for a given device in intel iommu driver, hence I'm asking for help here. :)
> > > 
> > > I think we just need to solve this one way or another.. Even if you
> > > use a viommu object you still end up having difficult coupling to
> > > iommufd
> > > 
> > > Some:
> > >    iommufd_get_dev_id(struct iommufd_ctx *ictx, struct device *dev)
> > > 
> > > Callable by a driver (using the driver-callable function
> > > infrastructure we made for dirty tracking) Is really all that is
> > > needed here.
> > 
> > yep, I noticed IOMMUFD_DRIVER was selected by intel iommu driver when
> > IOMMUFD is configed. Maybe such an API could be compiled when
> > IOMMUFD_DRIVER is enabled as well. This does address my concern on making
> > intel iommu driver depending on iommufd. But still need a way to pass in
> > the iommufd_ctx pointer to intel iommu driver, and store it. Hence intel
> > iommu driver could call the above iommufd_get_dev_id(). One possible way is
> > passing it when attaching device to domain and clear it in detach. However,
> > this seems not ideal as iommufd_ctx information should be static between
> > bind_iommufd and unbind. But we don't call into intel iommu driver in the
> > bind and unbind operations. May need to add new iommu op. Any suggestion
> > here?
> 
> You can pass the ctx to the invalidate op, it is already implied
> because the passed iommu_domain is linked to a single iommufd ctx.

The device virtual id lookup API needs something similar, yet it
likely needs a viommu pointer (or its id) instead? As the table
is attached to a viommu while an ictx can have multiple viommus,
right?

Thanks
Nic

  reply	other threads:[~2024-01-03 16:49 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-17 13:18 [PATCH v7 0/3] Add Intel VT-d nested translation (part 2/2) Yi Liu
2023-11-17 13:18 ` [PATCH v7 1/3] iommufd: Add data structure for Intel VT-d stage-1 cache invalidation Yi Liu
2023-11-20  8:26   ` Tian, Kevin
2023-11-20 23:04     ` Jason Gunthorpe
2023-11-21  2:54       ` Tian, Kevin
2023-11-21 12:17         ` Jason Gunthorpe
2023-11-22  2:32           ` Baolu Lu
2023-11-22  3:52             ` Yi Liu
2023-11-22  4:58           ` Tian, Kevin
2023-11-22 13:25             ` Jason Gunthorpe
2023-11-24  3:00               ` Tian, Kevin
2023-11-24 13:46                 ` Jason Gunthorpe
2023-12-14 11:26   ` Yi Liu
2023-12-15  1:50     ` Tian, Kevin
2023-12-15  2:28       ` Nicolin Chen
2023-12-15  3:04         ` Tian, Kevin
2023-12-15  3:32           ` Nicolin Chen
2023-12-15  4:01             ` Yi Liu
2023-12-16 18:49               ` Nicolin Chen
2023-12-17 23:28                 ` Tian, Kevin
2024-01-02 23:38               ` Jason Gunthorpe
2024-01-03  2:24                 ` Yi Liu
2024-01-03 16:01                   ` Jason Gunthorpe
2024-01-03 16:48                     ` Nicolin Chen [this message]
2024-01-03 16:58                       ` Jason Gunthorpe
2024-01-03 17:06                         ` Nicolin Chen
2024-01-03 17:52                           ` Jason Gunthorpe
2024-01-03 20:18                             ` Nicolin Chen
2024-01-04  0:02                               ` Jason Gunthorpe
2024-01-05  7:38                                 ` Nicolin Chen
2024-01-05 15:46                                   ` Jason Gunthorpe
2024-01-02 17:46       ` Jason Gunthorpe
2024-01-04 14:36     ` Jason Gunthorpe
2024-01-05  2:16       ` Tian, Kevin
2024-01-05  2:52       ` Tian, Kevin
2024-01-05 14:45         ` Jason Gunthorpe
2024-01-08  4:07           ` Tian, Kevin
2024-01-08 13:51             ` Jason Gunthorpe
2024-01-09  6:00             ` Yi Liu
2023-11-17 13:18 ` [PATCH v7 2/3] iommu/vt-d: Make iotlb flush helpers to be extern Yi Liu
2023-11-17 13:18 ` [PATCH v7 3/3] iommu/vt-d: Add iotlb flush for nested domain Yi Liu
2023-11-20  8:32   ` Tian, Kevin
2023-12-12  3:58     ` Yi Liu
2023-12-06 18:56   ` Jason Gunthorpe
2023-12-12  3:59     ` Yi Liu

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=ZZWP7iBqUtbTRb3s@Asurada-Nvidia \
    --to=nicolinc@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jasowang@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=joao.m.martins@oracle.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=peterx@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=xin.zeng@intel.com \
    --cc=yan.y.zhao@intel.com \
    --cc=yi.l.liu@intel.com \
    --cc=yi.y.sun@linux.intel.com \
    --cc=zhenzhong.duan@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.