linux-kernel - Re: [PATCH v7 13/13] Documentation: userspace-api: iommufd: Update vIOMMU

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ZzVsEmzc1UyDdi//@Asurada-Nvidia>
Date: Wed, 13 Nov 2024 19:18:42 -0800
From: Nicolin Chen <nicolinc@...dia.com>
To: Yi Liu <yi.l.liu@...el.com>
CC: <jgg@...dia.com>, <kevin.tian@...el.com>, <corbet@....net>,
	<joro@...tes.org>, <suravee.suthikulpanit@....com>, <will@...nel.org>,
	<robin.murphy@....com>, <dwmw2@...radead.org>, <shuah@...nel.org>,
	<iommu@...ts.linux.dev>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
	<baolu.lu@...ux.intel.com>, <eric.auger@...hat.com>,
	<jean-philippe@...aro.org>, <mdf@...nel.org>, <mshavit@...gle.com>,
	<shameerali.kolothum.thodi@...wei.com>, <smostafa@...gle.com>, <aik@....com>,
	<zhangfei.gao@...aro.org>, <patches@...ts.linux.dev>
Subject: Re: [PATCH v7 13/13] Documentation: userspace-api: iommufd: Update
 vIOMMU

On Thu, Nov 14, 2024 at 11:13:00AM +0800, Yi Liu wrote:
> On 2024/11/14 08:18, Nicolin Chen wrote:
> > On Tue, Nov 12, 2024 at 09:15:02PM +0800, Yi Liu wrote:
> > > On 2024/11/6 04:04, Nicolin Chen wrote:
> > > > +5. IOMMUFD_OBJ_VIOMMU can be only manually created via the IOMMU_VIOMMU_ALLOC
> > > > +   uAPI, provided a dev_id (for the device's physical IOMMU to back the vIOMMU)
> > > > +   and an hwpt_id (to associate the vIOMMU to a nesting parent HWPT_PAGING). The
> > > > +   iommufd core will link the vIOMMU object to the struct iommu_device that the
> > > > +   struct device is behind.
> > > 
> > > It looks to be reasonable to share the viommu_obj between devices behind
> > > the same physical IOMMU. This design seems no enforcement for it. So it's
> > > all up to userspace from what I got. :)
> > 
> > It enforces at the vDEVICE allocation:
> > 	if (viommu->iommu_dev != __iommu_get_iommu_dev(idev->dev)) {
> > 		return -EINVAL;
> 
> this matches the device and the viommu.

And viommu has a hard relationship with physical instance.

> > 
> > Yet, assuming you are referring to creating two vIOMMUs per VM for
> > two devices behind the same IOMMU (?), there is no enforcement..
> 
> right, but not limited to two vIOMMUs as the viommu_obj is not instanced
> per vIOMMUs.

It doesn't make a lot of sense to create two. But it doesn't seem
to be something that we can limit here. VMM can create the first
vIOMMU using the first device and create the second vIOMMU using
the second device, though both devices are behind the same IOMMU
and passed to the same VM. Thing is that kernel doesn't know if
they are passed to the same VM.

> > The suggested way for VMM, just like two devices sharing the same
> > s2 parent hwpt, is to share the vIOMMU object.
> 
> so the user would try to create vDevices with a given viommu_obj until
> failure, then it would allocate another viommu_obj for the failed device.
> is it? sounds reasonable.

Yes. It is the same as previously dealing with a nesting parent:
test and allocate if fails. The virtual IOMMU driver in VMM can
keep a list of the vIOMMU objects for each device to test.

Thanks
Nic