[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZxslrakslZbphayO@Asurada-Nvidia>
Date: Thu, 24 Oct 2024 21:59:25 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Alexey Kardashevskiy <aik@....com>
CC: <jgg@...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>, <yi.l.liu@...el.com>, <zhangfei.gao@...aro.org>,
<patches@...ts.linux.dev>
Subject: Re: [PATCH v4 00/14] iommufd: Add vIOMMU infrastructure (Part-2:
vDEVICE)
On Fri, Oct 25, 2024 at 03:54:44PM +1100, Alexey Kardashevskiy wrote:
> On 22/10/24 11:20, Nicolin Chen wrote:
> > Following the previous vIOMMU series, this adds another vDEVICE structure,
> > representing the association from an iommufd_device to an iommufd_viommu.
> > This gives the whole architecture a new "v" layer:
> > _______________________________________________________________________
> > | iommufd (with vIOMMU/vDEVICE) |
> > | _____________ _____________ |
> > | | | | | |
> > | |----------------| vIOMMU |<---| vDEVICE |<------| |
> > | | | | |_____________| | |
> > | | ______ | | _____________ ___|____ |
> > | | | | | | | | | | |
> > | | | IOAS |<---|(HWPT_PAGING)|<---| HWPT_NESTED |<--| DEVICE | |
> > | | |______| |_____________| |_____________| |________| |
> > |______|________|______________|__________________|_______________|_____|
> > | | | | |
> > ______v_____ | ______v_____ ______v_____ ___v__
> > | struct | | PFN | (paging) | | (nested) | |struct|
> > |iommu_device| |------>|iommu_domain|<----|iommu_domain|<----|device|
> > |____________| storage|____________| |____________| |______|
> >
> > This vDEVICE object is used to collect and store all vIOMMU-related device
> > information/attributes in a VM. As an initial series for vDEVICE, add only
> > the virt_id to the vDEVICE, which is a vIOMMU specific device ID in a VM:
> > e.g. vSID of ARM SMMUv3, vDeviceID of AMD IOMMU, and vID of Intel VT-d to
> > a Context Table. This virt_id helps IOMMU drivers to link the vID to a pID
> > of the device against the physical IOMMU instance. This is essential for a
> > vIOMMU-based invalidation, where the request contains a device's vID for a
> > device cache flush, e.g. ATC invalidation.
> >
> > Therefore, with this vDEVICE object, support a vIOMMU-based invalidation,
> > by reusing IOMMUFD_CMD_HWPT_INVALIDATE for a vIOMMU object to flush cache
> > with a given driver data.
> >
> > As for the implementation of the series, add driver support in ARM SMMUv3
> > for a real world use case.
> >
> > This series is on Github:
> > https://github.com/nicolinc/iommufd/commits/iommufd_viommu_p2-v4
> >
> > For testing, try this "with-rmr" branch:
> > https://github.com/nicolinc/iommufd/commits/iommufd_viommu_p2-v4-with-rmr
>
> Is there any real example of a .vdevice_alloc hook, besides the
> selftests? It is not in iommufd_viommu_p2-v4-with-rmr, hence the
> question. I am trying to sketch something with this new machinery and
> less guessing would be nice. Thanks,
No, I am actually dropping that one, and moving the vdevice struct
to the private header, as there seems to be no use case:
https://lore.kernel.org/linux-iommu/ZxsSYbK3gqyC84U7@Asurada-Nvidia/
https://lore.kernel.org/linux-iommu/ZxsTAANTTuQzQ9HR@Asurada-Nvidia/
Do you need vdevice_alloc in the driver for your sketch?
Thanks
Nicolin
Powered by blists - more mailing lists