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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <46d2d0ea-45a9-4179-bd1f-838c82af8d16@intel.com>
Date: Mon, 18 Nov 2024 14:10:17 +0800
From: Yi Liu <yi.l.liu@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>, Nicolin Chen <nicolinc@...dia.com>
CC: <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 2024/11/16 08:34, Jason Gunthorpe wrote:
> On Fri, Nov 15, 2024 at 02:07:41PM -0800, Nicolin Chen wrote:
>> On Thu, Nov 14, 2024 at 12:20:10PM -0400, Jason Gunthorpe wrote:
>>> On Wed, Nov 13, 2024 at 07:18:42PM -0800, Nicolin Chen wrote:
>>>>> 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.
>>>
>>> The viommu object should be tied to the VMM's vIOMMU vHW object that
>>> it is paravirtualizing toward the VM.
>>>
>>> So we shouldn't be creating viommu objects on demand, it should be
>>> created when the vIOMMU is created, and the presumably the qemu
>>> command line will describe how to link vPCI/VFIO functions to vIOMMU
>>> instances. If they kernel won't allow the user's configuration then it
>>> should fail, IMHO.
>>
>> Intel's virtual IOMMU in QEMU has one instance but could create
>> two vIOMMU objects for devices behind two different pIOMMUs. So,
>> in this case, it does the on-demand (or try-and-fail) approach?
> 
> I suspect Intel does need viommu at all, and if it ever does it will
> not be able to have one instance..

hmmm. As long as I got, the viommu_obj is a representative of the hw
IOMMU slice of resource used by the VM. It is hence instanced per hw
iommu. Based on this, one vIOMMU can have multiple or one viommu_obj.
Either should be allowed by design.

BTW. @Nic, I think the viommu_obj instance is not strictly be per hw
IOMMUs. e.g. two devices behind one hw IOMMU can have their own viommu_obj
as well. Is it? I didn't see a problem for it. So the viommu_obj is
instanced >= hw IOMMU number used by the VM.

Regards,
Yi Liu