> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Monday, July 31, 2023 9:16 PM
>
> On Mon, Jul 31, 2023 at 06:31:20AM +0000, Tian, Kevin wrote:
> > > From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> > > Sent: Saturday, July 29, 2023 1:56 AM
> > >
> > > On Mon, Jul 24, 2023 at 04:03:57AM -0700, Yi Liu wrote:
> > >
> > > > + switch (pt_obj->type) {
> > > > + case IOMMUFD_OBJ_IOAS:
> > > > + ioas = container_of(pt_obj, struct iommufd_ioas, obj);
> > > > + break;
> > > > + case IOMMUFD_OBJ_HW_PAGETABLE:
> > > > + /* pt_id points HWPT only when hwpt_type
> > > is !IOMMU_HWPT_TYPE_DEFAULT */
> > > > + if (cmd->hwpt_type == IOMMU_HWPT_TYPE_DEFAULT) {
> > > > + rc = -EINVAL;
> > > > + goto out_put_pt;
> > > > + }
> > > > +
> > > > + parent = container_of(pt_obj, struct iommufd_hw_pagetable,
> > > obj);
> > > > + /*
> > > > + * Cannot allocate user-managed hwpt linking to
> > > auto_created
> > > > + * hwpt. If the parent hwpt is already a user-managed hwpt,
> > > > + * don't allocate another user-managed hwpt linking to it.
> > > > + */
> > > > + if (parent->auto_domain || parent->parent) {
> > > > + rc = -EINVAL;
> > > > + goto out_put_pt;
> > > > + }
> > > > + ioas = parent->ioas;
> > >
> > > Why do we set ioas here? I would think it should be NULL.
> > >
> > > I think it is looking like a mistake to try and re-use
> > > iommufd_hw_pagetable_alloc() directly for the nested case. It should
> > > not have a IOAS argument, it should not do enforce_cc, or iopt_*
> > > functions
> >
> > enforce_cc is still required since it's about memory accesses post
> > page table walking (no matter the walked table is single stage or
> > nested).
>
> enforce_cc only has meaning if the kernel owns the IOPTEs, and if we
> are creating a nest it does not. The guest has to set any necessary
> IOPTE bits.
>
> enforce_cc will be done on the parent of the nest as normal.
Ah, yes. What I described is the final behavior but in concept it's
done for the parent.
>
> > Ideally expanding uAPI structure size should come with new flag bits.
>
> Flags or some kind of 'zero is the same behavior as a smaller struct'
> scheme.
>
> This patch is doing the zero option:
>
> __u32 __reserved;
> + __u32 hwpt_type;
> + __u32 data_len;
> + __aligned_u64 data_uptr;
> };
>
> hwpt_type == 0 means default type
> data_len == 0 means no data
> data_uptr is ignored (zero is safe)
>
> So there is no need to change it
>
Make sense
