The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Will Deacon <will@kernel.org>, Kevin Tian <kevin.tian@intel.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	Joerg Roedel <joro@8bytes.org>, Shuah Khan <shuah@kernel.org>,
	Pranjal Shrivastava <praan@google.com>,
	Kees Cook <kees@kernel.org>, Yi Liu <yi.l.liu@intel.com>,
	Eric Auger <eric.auger@redhat.com>,
	<linux-arm-kernel@lists.infradead.org>, <iommu@lists.linux.dev>,
	<linux-kernel@vger.kernel.org>, <linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH v1 4/4] iommu/arm-smmu-v3: Process vIOMMU invalidations in batches
Date: Fri, 12 Jun 2026 12:11:10 -0700	[thread overview]
Message-ID: <aixZzvVWmAFEDQZI@nvidia.com> (raw)
In-Reply-To: <20260612135409.GI1962447@nvidia.com>

On Fri, Jun 12, 2026 at 10:54:09AM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 03, 2026 at 02:26:56PM -0700, Nicolin Chen wrote:
> > +int arm_vsmmu_cache_invalidate(struct iommufd_viommu *viommu,
> > +			       struct iommu_user_data_array *array)
> > +{
> > +	struct arm_vsmmu *vsmmu = container_of(viommu, struct arm_vsmmu, core);
> > +	u32 issued = 0;
> > +	int ret = 0;
> > +
> > +	if (array->type != IOMMU_VIOMMU_INVALIDATE_DATA_ARM_SMMUV3) {
> > +		array->entry_num = 0;
> > +		return -EINVAL;
> > +	}
> > +
> > +	while (issued != array->entry_num) {
> > +		/* Process and issue the command(s) in batch */
> > +		ret = arm_vsmmu_cache_invalidate_batch(vsmmu, array, &issued);
> > +		if (ret)
> > +			break;
> > +	}
> > +
> > +	array->entry_num = issued;
> >  	return ret;
> 
> I think every driver will have this same problem, how about lifting
> this loop to the core code?

Sure. I think that makes things a bit cleaner. I'll try that. Then,
this would become another iommufd series.

> Also not sure I like the validation flow, I think it will be easier to
> understand for everything if either num is 0 and nothing was done with
> an error code
> 
> Or num is non zero and no error code.
> 
> Like it doesn't make sense to fail immediately if zero pad is nonzero
> in iommu_copy_struct_from_full_user_array() but then to try to
> partially continue if arm_vsmmu_convert_user_cmd() finds illegal data
> in the very same buffer. Be consistent, validate the user buffer, if
> it is not valid fail immeidately. Then execute a fully valid user buffer.

I don't think fully validating the user buffer is correct..

VMM would have to know which command failed, to flag it in the CONS
register, indicating: a) commands prior to the CONS are issued, and
b) command pointed by the CONS is illegal.

Then, guest kernel reads the CONS register to pinpoint this illegal
command and swap it with a CMD_SYNC (__arm_smmu_cmdq_skip_err).

E.g., if the 16th command in a 64-command array is illegal, kernel
should issue the first 15 commands, returns -EIO; then, VMM should
flag illegal at CONS pointing to the 16th command.

The design in this patch is implemented in this way. And arguably,
I think the nonzero-padding case is VMM violating the ABI, in which
case the return code would be different than -EIO. And VMM should
fix itself instead of flagging illegal in the CONS register.

Do you agree?

Thanks
Nicolin

  reply	other threads:[~2026-06-12 19:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-03 21:26 [PATCH v1 0/4] iommufd: Cache invalidation hardening and SMMUv3 batching rework Nicolin Chen
2026-06-03 21:26 ` [PATCH v1 1/4] iommufd: Set upper bounds on cache invalidation entry_num and entry_len Nicolin Chen
2026-06-10  3:16   ` Baolu Lu
2026-06-03 21:26 ` [PATCH v1 2/4] iommufd/selftest: Add invalidation entry_num and entry_len boundary tests Nicolin Chen
2026-06-10  3:18   ` Baolu Lu
2026-06-03 21:26 ` [PATCH v1 4/4] iommu/arm-smmu-v3: Process vIOMMU invalidations in batches Nicolin Chen
2026-06-12 13:54   ` Jason Gunthorpe
2026-06-12 19:11     ` Nicolin Chen [this message]
     [not found] ` <6c9eca4ff584cb977661e97799ac6fe934e7f51c.1780521606.git.nicolinc@nvidia.com>
2026-06-10  3:21   ` [PATCH v1 3/4] iommu: Avoid copying the user array twice in the full-array copy helper Baolu Lu
2026-06-12 13:54 ` [PATCH v1 0/4] iommufd: Cache invalidation hardening and SMMUv3 batching rework 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=aixZzvVWmAFEDQZI@nvidia.com \
    --to=nicolinc@nvidia.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kees@kernel.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=praan@google.com \
    --cc=robin.murphy@arm.com \
    --cc=shuah@kernel.org \
    --cc=will@kernel.org \
    --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