linux-kernel - Re: [PATCH v4 02/11] iommufd: Introduce IOMMUFD_OBJ

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: <0db7401c-ca89-49a7-a9cc-502a581af66d@linux.intel.com>
Date: Wed, 23 Oct 2024 09:48:36 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: baolu.lu@...ux.intel.com, Nicolin Chen <nicolinc@...dia.com>,
 kevin.tian@...el.com, will@...nel.org, joro@...tes.org,
 suravee.suthikulpanit@....com, robin.murphy@....com, dwmw2@...radead.org,
 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, aik@....com,
 zhangfei.gao@...aro.org, patches@...ts.linux.dev
Subject: Re: [PATCH v4 02/11] iommufd: Introduce IOMMUFD_OBJ_VIOMMU and its
 related struct

On 2024/10/22 21:15, Jason Gunthorpe wrote:
> On Tue, Oct 22, 2024 at 04:59:07PM +0800, Baolu Lu wrote:
> 
>> Is it feasible to make vIOMMU object more generic, rather than strictly
>> tying it to nested translation? For example, a normal paging domain that
>> translates gPAs to hPAs could also have a vIOMMU object associated with
>> it.
>>
>> While we can only support vIOMMU object allocation uAPI for S2 paging
>> domains in the context of this series, we could consider leaving the
>> option open to associate a vIOMMU object with other normal paging
>> domains that are not a nested parent?
> Why? The nested parent flavour of the domain is basically free to
> create, what reason would be to not do that?

Above addressed my question. The software using vIOMMU should allocate a
domain of nested parent type.

> 
> If the HW doesn't support it, then does the HW really need/support a
> VIOMMU?
> 
> I suppose it could be made up to the driver, but for now I think we
> should leave it as is in the core code requiring it until we have a
> reason to relax it.

Yes. In such cases, the iommu driver could always allow nested parent
domain allocation, but fails to allocate a nested domain if the hardware
is not capable of nesting translation.

Thanks,
baolu