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
