[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZBJp9qhc9UON/Z5/@Asurada-Nvidia>
Date: Wed, 15 Mar 2023 17:59:34 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: Jean-Philippe Brucker <jean-philippe@...aro.org>,
<robin.murphy@....com>, <will@...nel.org>, <eric.auger@...hat.com>,
<kevin.tian@...el.com>, <baolu.lu@...ux.intel.com>,
<joro@...tes.org>, <shameerali.kolothum.thodi@...wei.com>,
<linux-arm-kernel@...ts.infradead.org>, <iommu@...ts.linux.dev>,
<linux-kernel@...r.kernel.org>, <yi.l.liu@...el.com>
Subject: Re: [PATCH v1 02/14] iommufd: Add nesting related data structures
for ARM SMMUv3
On Fri, Mar 10, 2023 at 12:06:18PM -0400, Jason Gunthorpe wrote:
> On Thu, Mar 09, 2023 at 08:50:52PM -0800, Nicolin Chen wrote:
> > On Thu, Mar 09, 2023 at 10:48:50AM -0400, Jason Gunthorpe wrote:
> >
> > > Nicolin, I think we should tweak the uAPI here so that the
> > > invalidation opaque data has a format tagged on its own, instead of
> > > re-using the HWPT tag. Ie you can have a ARM SMMUv3 invalidate type
> > > tag and also a virtio-viommu invalidate type tag.
> >
> > The invalidation tage is shared with the hwpt allocation. Does
> > it mean that virtio-iommu won't have it's own allocation tag?
>
> We probably shouldn't assume it will
In that case, why do have need an invalidation tag/type on its
own? Can't we use an IOMMU_HWPT_TYPE_VIRTIO tag for allocation
and invalidation together for virtio?
Or did you mean that we should define a flag inside the data
structure like this?
struct iommu_hwpt_invalidate_arm_smmuv3 {
#define IOMMU_SMMUV3_CMDQ_TLBI_VA_LEAF (1 << 0)
#define IOMMU_SMMUV3_FORMAT_VIRTIO (1 << 63)
__u64 flags;
}
Thanks
Nic
Powered by blists - more mailing lists