linux-kernel - RE: [PATCH v2 04/19] iommufd: Allow pt_id to carry viommu_id for IOMMU_HWPT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB52761E58692F05D741DAF2758C6B2@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Fri, 27 Sep 2024 02:23:16 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Nicolin Chen <nicolinc@...dia.com>
CC: "Liu, Yi L" <yi.l.liu@...el.com>, "jgg@...dia.com" <jgg@...dia.com>,
	"will@...nel.org" <will@...nel.org>, "joro@...tes.org" <joro@...tes.org>,
	"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
	"robin.murphy@....com" <robin.murphy@....com>, "dwmw2@...radead.org"
	<dwmw2@...radead.org>, "baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
	"shuah@...nel.org" <shuah@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "iommu@...ts.linux.dev"
	<iommu@...ts.linux.dev>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kselftest@...r.kernel.org"
	<linux-kselftest@...r.kernel.org>, "eric.auger@...hat.com"
	<eric.auger@...hat.com>, "jean-philippe@...aro.org"
	<jean-philippe@...aro.org>, "mdf@...nel.org" <mdf@...nel.org>,
	"mshavit@...gle.com" <mshavit@...gle.com>,
	"shameerali.kolothum.thodi@...wei.com"
	<shameerali.kolothum.thodi@...wei.com>, "smostafa@...gle.com"
	<smostafa@...gle.com>
Subject: RE: [PATCH v2 04/19] iommufd: Allow pt_id to carry viommu_id for
 IOMMU_HWPT_ALLOC

> From: Nicolin Chen <nicolinc@...dia.com>
> Sent: Friday, September 27, 2024 9:26 AM
> 
> On Fri, Sep 27, 2024 at 12:43:16AM +0000, Tian, Kevin wrote:
> > > From: Nicolin Chen <nicolinc@...dia.com>
> > > Sent: Friday, September 27, 2024 4:11 AM
> > >
> > > On Thu, Sep 26, 2024 at 04:50:46PM +0800, Yi Liu wrote:
> > > > On 2024/8/28 00:59, Nicolin Chen wrote:
> > > > > Now a VIOMMU can wrap a shareable nested parent HWPT. So, it can
> act
> > > like
> > > > > a nested parent HWPT to allocate a nested HWPT.
> > > > >
> > > > > Support that in the IOMMU_HWPT_ALLOC ioctl handler, and update
> its
> > > kdoc.
> > > > >
> > > > > Also, associate a viommu to an allocating nested HWPT.
> > > >
> > > > it still not quite clear to me what vIOMMU obj stands for. Here, it is a
> > > > wrapper of s2 hpwt IIUC. But in the cover letter, vIOMMU obj can
> instanced
> > > > per the vIOMMU units in VM.
> > >
> > > Yea, the implementation in this version is merely a wrapper. I
> > > had a general introduction of vIOMMU in the other reply. And I
> > > will put something similar in the next version of the series,
> > > so the idea would be bigger than a wrapper.
> > >
> > > > Does it mean each vIOMMU of VM can only have
> > > > one s2 HWPT?
> > >
> > > Giving some examples here:
> > >  - If a VM has 1 vIOMMU, there will be 1 vIOMMU object in the
> > >    kernel holding one S2 HWPT.
> > >  - If a VM has 2 vIOMMUs, there will be 2 vIOMMU objects in the
> > >    kernel that can hold two different S2 HWPTs, or share one S2
> > >    HWPT (saving memory).
> > >
> >
> > this is not consistent with previous discussion.
> >
> > even for 1 vIOMMU per VM there could be multiple vIOMMU objects
> > created in the kernel in case the devices connected to the VM-visible
> > vIOMMU locate behind different physical SMMUs.
> >
> > we don't expect one vIOMMU object to span multiple physical ones.
> 
> I think it's consistent, yet we had different perspectives for a
> virtual IOMMU instance in the VM: Jason's suggested design for a
> VM is to have 1-to-1 mapping between virtual IOMMU instances and
> physical IOMMU instances. So, one vIOMMU is backed by one pIOMMU
> only, i.e. one vIOMMU object in the kernel.
> 
> Your case seems to be the model where a VM has one giant virtual
> IOMMU instance backed by multiple physical IOMMUs, in which case
> all the passthrough devices, regardless their associated pIOMMUs,
> are connected to this shared virtual IOMMU. And yes, this shared
> virtual IOMMU can have multiple vIOMMU objects.

yes.

sorry that I should not use "inconsistent" in the last reply. It's more
about completeness for what the design allows. 😊

> 
> Regarding these two models, I had listed their pros/cons at (2):
> https://lore.kernel.org/qemu-
> devel/cover.1719361174.git.nicolinc@...dia.com/
> 
> (Not 100% sure) VT-d might not have something like vCMDQ, so it
> can stay in the shared model to simplify certain things, though
> I feel it may face some similar situation like mapping multiple
> physical MMIO regions to a single virtual region (undoable!) if
> some day intel has some similar HW-accelerated feature?
> 

yes if VT-d has hw acceleration then it'd be similar to SMMU.