linux-kernel - Re: [PATCH v1 15/16] iommu/arm-smmu-v3: Add viommu cache invalidation support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZsOMu3OnMn49cDXf@Asurada-Nvidia>
Date: Mon, 19 Aug 2024 11:19:39 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: <kevin.tian@...el.com>, <will@...nel.org>, <joro@...tes.org>,
	<suravee.suthikulpanit@....com>, <robin.murphy@....com>,
	<dwmw2@...radead.org>, <baolu.lu@...ux.intel.com>, <shuah@...nel.org>,
	<linux-kernel@...r.kernel.org>, <iommu@...ts.linux.dev>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH v1 15/16] iommu/arm-smmu-v3: Add viommu cache
 invalidation support

On Mon, Aug 19, 2024 at 02:36:15PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2024 at 05:50:06PM -0700, Nicolin Chen wrote:
> 
> > Though only driver would know whether it would eventually access
> > the vdev_id list, I'd like to keep things in the way of having a
> > core-managed VIOMMU object (IOMMU_VIOMMU_TYPE_DEFAULT), so the
> > viommu invalidation handler could have a lock at its top level to
> > protect any potential access to the vdev_id list.
> 
> It is a bit tortured to keep the xarray hidden. It would be better to
> find a way to expose the right struct to the driver.

Yes. I will try adding set/unset_vdev_id to the default viommu
ops.

> > > > @@ -3249,6 +3266,19 @@ arm_smmu_convert_user_cmd(struct arm_smmu_domain *s2_parent,
> > > >  		cmd->cmd[0] &= ~CMDQ_TLBI_0_VMID;
> > > >  		cmd->cmd[0] |= FIELD_PREP(CMDQ_TLBI_0_VMID, vmid);
> > > >  		break;
> > > > +	case CMDQ_OP_ATC_INV:
> > > > +	case CMDQ_OP_CFGI_CD:
> > > > +	case CMDQ_OP_CFGI_CD_ALL:
> > > 
> > > Oh, I didn't catch on that CD was needing this too.. :\
> > 
> > Well, viommu cache has a very wide range :)
> > 
> > > That makes the other op much more useless than I expected. I really
> > > wanted to break these two series apart.
> > 
> > HWPT invalidate and VIOMMU invalidate are somewhat duplicated in
> > both concept and implementation for SMMUv3. It's not a problem to
> > have both but practically I can't think of the reason why VMM not
> > simply stick to the wider VIOMMU invalidate uAPI alone..
> > 
> > > Maybe we need to drop the hwpt invalidation from the other series and
> > 
> > Yea, the hwpt invalidate is just one patch in your series, it's
> > easy to move if we want to.
> 
> > > aim to merge this all together through the iommufd tree.
> > 
> > I have been hoping for that, as you can see those driver patches
> > are included here :)
> 
> Well, this series has to go through iommufd of course
> 
> I was hoping will could take the nesting enablement and we'd do the
> viommu next window.
> 
> But nesting enablment with out viommu is alot less useful than I had
> thought :(

Actually, without viommu, the hwpt cache invalidate alone could
still support non-SVA case?

Though we still have the blocker at the msi mapping... It still
requires a solution, even for viommu series.

Thanks
Nicolin