iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: "Liu, Yi L" <yi.l.liu@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>,
	"nicolinc@nvidia.com" <nicolinc@nvidia.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>
Subject: RE: [PATCH v2 00/11] iommufd: Add nesting infrastructure
Date: Wed, 21 Jun 2023 06:02:21 +0000	[thread overview]
Message-ID: <BN9PR11MB5276B852A32F53BE8EAA1A7D8C5DA@BN9PR11MB5276.namprd11.prod.outlook.com> (raw)
In-Reply-To: <ZJGf3sgLKr9HLZuE@nvidia.com>

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Tuesday, June 20, 2023 8:47 PM
> 
> On Tue, Jun 20, 2023 at 01:43:42AM +0000, Tian, Kevin wrote:
> > I wonder whether we have argued passed each other.
> >
> > This series adds reserved regions to S2. I challenged the necessity as
> > S2 is not directly accessed by the device.
> >
> > Then you replied that doing so still made sense to support identity
> > S1.
> 
> I think I said/ment if we attach the "s2" iommu domain as a direct
> attach for identity - eg at boot time, then the IOAS must gain the
> reserved regions. This is our normal protocol.
> 
> But when we use the "s2" iommu domain as an actual nested S2 then we
> don't gain reserved regions.

Then we're aligned.

Yi/Nicolin, please update this series to not automatically add reserved
regions to S2 in the nesting configuration.

It also implies that the user cannot rely on IOAS_IOVA_RANGES to
learn reserved regions for arranging addresses in S1.

Then we also need a new ioctl to report reserved regions per dev_id.

> 
> > Intel VT-d supports 4 configurations:
> >   - passthrough (i.e. identity mapped)
> >   - S1 only
> >   - S2 only
> >   - nested
> >
> > 'S2 only' is used when vIOMMU is configured in passthrough.
> 
> S2 only is modeled as attaching an S2 format iommu domain to the RID,
> and when this is done the IOAS should gain the reserved regions
> because it is no different behavior than attaching any other iommu
> domain to a RID.
> 
> When the S2 is replaced with a S1 nest then the IOAS should loose
> those reserved regions since it is no longer attached to a RID.

yes

> 
> > My understanding of ARM SMMU is that from host p.o.v. the CD is the
> > S1 in the nested configuration. 'identity' is one configuration in the CD
> > then it's in the business of nesting.
> 
> I think it is the same. A CD doesn't come into the picture until the
> guest installs a CD pointing STE. Until that time the S2 is being used
> as identity.
> 
> It sounds like the same basic flow.

After a CD table is installed in a STE I assume the SMMU still allows to
configure an individual CD entry as identity? e.g. while vSVA is enabled
on a device the guest can continue to keep CD#0 as identity when the
default domain of the device is set as 'passthrough'. In this case the
IOAS still needs to gain reserved regions even though S2 is not directly
attached from host p.o.v.

> 
> > My preference was that ALLOC_HWPT allows vIOMMU to opt whether
> > reserved regions of dev_id should be added to the IOAS of the parent
> > S2 hwpt.
> 
> Having an API to explicitly load reserved regions of a specific device
> to an IOAS makes some sense to me.
> 
> Jason

  reply	other threads:[~2023-06-21  6:02 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11 14:38 [PATCH v2 00/11] iommufd: Add nesting infrastructure Yi Liu
2023-05-11 14:38 ` [PATCH v2 01/11] iommu: Add new iommu op to create domains owned by userspace Yi Liu
2023-05-19  8:47   ` Tian, Kevin
2023-05-19 18:45     ` Nicolin Chen
2023-05-24  5:02       ` Tian, Kevin
2023-05-24  5:23         ` Nicolin Chen
2023-05-24  7:48           ` Tian, Kevin
2023-05-25  1:41             ` Nicolin Chen
2023-06-06 14:08               ` Jason Gunthorpe
2023-06-06 19:43                 ` Nicolin Chen
2023-06-07  0:14                   ` Jason Gunthorpe
2023-05-11 14:38 ` [PATCH v2 02/11] iommu: Add nested domain support Yi Liu
2023-05-19  8:51   ` Tian, Kevin
2023-05-19 18:49     ` Nicolin Chen
2023-05-24  5:03       ` Tian, Kevin
2023-05-24  5:28         ` Nicolin Chen
2023-05-11 14:38 ` [PATCH v2 03/11] iommufd/hw_pagetable: Use domain_alloc_user op for domain allocation Yi Liu
2023-05-19  8:56   ` Tian, Kevin
2023-05-19 18:57     ` Nicolin Chen
2023-05-24  5:04       ` Tian, Kevin
2023-05-11 14:38 ` [PATCH v2 04/11] iommufd: Pass parent hwpt and user_data to iommufd_hw_pagetable_alloc() Yi Liu
2023-05-19  9:06   ` Tian, Kevin
2023-05-19 19:09     ` Nicolin Chen
2023-05-24  5:11       ` Tian, Kevin
2023-05-24  5:31         ` Nicolin Chen
2023-05-19  9:34   ` Tian, Kevin
2023-05-19 19:12     ` Nicolin Chen
2023-05-11 14:38 ` [PATCH v2 05/11] iommufd/hw_pagetable: Do not populate user-managed hw_pagetables Yi Liu
2023-05-11 14:38 ` [PATCH v2 06/11] iommufd: IOMMU_HWPT_ALLOC allocation with user data Yi Liu
2023-05-17  3:08   ` Liu, Jingqi
2023-05-19 19:34     ` Nicolin Chen
2023-05-19  9:41   ` Tian, Kevin
2023-05-19 19:48     ` Nicolin Chen
2023-05-24  5:16       ` Tian, Kevin
2023-05-24  5:40         ` Nicolin Chen
2023-05-24  7:55           ` Tian, Kevin
2023-05-11 14:38 ` [PATCH v2 07/11] iommufd: Add IOMMU_HWPT_INVALIDATE Yi Liu
2023-05-11 14:38 ` [PATCH v2 08/11] iommufd/selftest: Add domain_alloc_user() support in iommu mock Yi Liu
2023-05-11 14:38 ` [PATCH v2 09/11] iommufd/selftest: Add coverage for IOMMU_HWPT_ALLOC with user data Yi Liu
2023-05-11 14:38 ` [PATCH v2 10/11] iommufd/selftest: Add IOMMU_TEST_OP_MD_CHECK_IOTLB test op Yi Liu
2023-05-11 14:38 ` [PATCH v2 11/11] iommufd/selftest: Add coverage for IOMMU_HWPT_INVALIDATE ioctl Yi Liu
2023-05-19  9:56 ` [PATCH v2 00/11] iommufd: Add nesting infrastructure Tian, Kevin
2023-05-19 11:49   ` Jason Gunthorpe
2023-05-24  3:48     ` Tian, Kevin
2023-06-06 14:18       ` Jason Gunthorpe
2023-06-16  2:43         ` Tian, Kevin
2023-06-19 12:37           ` Jason Gunthorpe
2023-06-20  1:43             ` Tian, Kevin
2023-06-20 12:47               ` Jason Gunthorpe
2023-06-21  6:02                 ` Tian, Kevin [this message]
2023-06-21  7:09                   ` Liu, Yi L
2023-06-21 12:04                   ` Jason Gunthorpe
2023-06-26  6:32                     ` Tian, Kevin
2023-06-21 17:13                   ` Nicolin Chen
2023-06-26  6:42                     ` Tian, Kevin
2023-06-26 13:05                       ` Jason Gunthorpe
2023-06-26 17:28                       ` Nicolin Chen
2023-06-27  6:02                         ` Tian, Kevin
2023-06-27 16:01                           ` Jason Gunthorpe
2023-06-28  2:47                             ` Tian, Kevin
2023-06-28 12:36                               ` Jason Gunthorpe
2023-06-29  2:16                                 ` Tian, Kevin
2023-06-21  8:29                 ` Duan, Zhenzhong
2023-06-21 12:07                   ` Jason Gunthorpe

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=BN9PR11MB5276B852A32F53BE8EAA1A7D8C5DA@BN9PR11MB5276.namprd11.prod.outlook.com \
    --to=kevin.tian@intel.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=joro@8bytes.org \
    --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=nicolinc@nvidia.com \
    --cc=peterx@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=suravee.suthikulpanit@amd.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 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).