[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240927122051.GY9417@nvidia.com>
Date: Fri, 27 Sep 2024 09:20:51 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Yi Liu <yi.l.liu@...el.com>
Cc: Nicolin Chen <nicolinc@...dia.com>, kevin.tian@...el.com,
will@...nel.org, joro@...tes.org, suravee.suthikulpanit@....com,
robin.murphy@....com, dwmw2@...radead.org, baolu.lu@...ux.intel.com,
shuah@...nel.org, linux-kernel@...r.kernel.org,
iommu@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
linux-kselftest@...r.kernel.org, eric.auger@...hat.com,
jean-philippe@...aro.org, mdf@...nel.org, mshavit@...gle.com,
shameerali.kolothum.thodi@...wei.com, smostafa@...gle.com
Subject: Re: [PATCH v2 00/19] iommufd: Add VIOMMU infrastructure (Part-1)
On Fri, Sep 27, 2024 at 08:12:20PM +0800, Yi Liu wrote:
> > Perhaps calling it a slice sounds more accurate, as I guess all
> > the confusion comes from the name "vIOMMU" that might be thought
> > to be a user space object/instance that likely holds all virtual
> > stuff like stage-1 HWPT or so?
>
> yeah. Maybe this confusion partly comes when you start it with the
> cache invalidation as well. I failed to get why a S2 hwpt needs to
> be part of the vIOMMU obj at the first glance.
Both amd and arm have direct to VM queues for the iommu and these
queues have their DMA translated by the S2.
So their viommu HW concepts come along with a requirement that there
be a fixed translation for the VM, which we model by attaching a S2
HWPT to the VIOMMU object which get's linked into the IOMMU HW as
the translation for the queue memory.
Jason
Powered by blists - more mailing lists