[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YGH/jJPeG9ltT8uu@myrica>
Date: Mon, 29 Mar 2021 18:25:48 +0200
From: Jean-Philippe Brucker <jean-philippe@...aro.org>
To: Vivek Kumar Gautam <vivek.gautam@....com>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
iommu@...ts.linux-foundation.org,
virtualization@...ts.linux-foundation.org, joro@...tes.org,
will.deacon@....com, mst@...hat.com, robin.murphy@....com,
eric.auger@...hat.com, alex.williamson@...hat.com,
kevin.tian@...el.com, jacob.jun.pan@...ux.intel.com,
yi.l.liu@...el.com, lorenzo.pieralisi@....com,
shameerali.kolothum.thodi@...wei.com
Subject: Re: [PATCH RFC v1 02/15] iommu: Add a simple PASID table library
On Fri, Mar 12, 2021 at 06:17:55PM +0530, Vivek Kumar Gautam wrote:
> > Regarding the overall design, I was initially assigning page directories
> > instead of whole PASID tables, which would simplify the driver and host
> > implementation. A major complication, however, is SMMUv3 accesses PASID
> > tables using a guest-physical address, so there is a messy negotiation
> > needed between host and guest when the host needs to allocate PASID
> > tables. Plus vSMMU needs PASID table assignment, so that's what the host
> > driver will implement.
>
> By assigning the page directories, you mean setting up just the stage-1 page
> table ops, and passing that information to the host using ATTACH_TABLE?
Yes. And we can support nested translation with SMMUv2 that way. But with
SMMUv3 the guest has to manage the whole PASID table.
> Right now when using kvmtool, the struct iommu_pasid_table_config is
> populated with the correct information, and this whole memory is mapped
> between host and guest by creating a mem bank using
> kvm__for_each_mem_bank().
> Did I get you or did I fail terribly in understanding the point you are
> making here?
Makes sense
Thanks,
Jean
Powered by blists - more mailing lists