linux-kernel - Re: [PATCH RFCv2 00/13] iommu: Add MSI mapping support with nested SMMU

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: <8e4c21b5-3b79-4f0b-b920-59b825c2fb81@redhat.com>
Date: Wed, 29 Jan 2025 18:46:20 +0100
From: Eric Auger <eric.auger@...hat.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>,
 Nicolin Chen <nicolinc@...dia.com>, "will@...nel.org" <will@...nel.org>,
 "robin.murphy@....com" <robin.murphy@....com>,
 "kevin.tian@...el.com" <kevin.tian@...el.com>,
 "tglx@...utronix.de" <tglx@...utronix.de>, "maz@...nel.org"
 <maz@...nel.org>, "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
 "joro@...tes.org" <joro@...tes.org>, "shuah@...nel.org" <shuah@...nel.org>,
 "reinette.chatre@...el.com" <reinette.chatre@...el.com>,
 "yebin (H)" <yebin10@...wei.com>,
 "apatel@...tanamicro.com" <apatel@...tanamicro.com>,
 "shivamurthy.shastri@...utronix.de" <shivamurthy.shastri@...utronix.de>,
 "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
 "anna-maria@...utronix.de" <anna-maria@...utronix.de>,
 "yury.norov@...il.com" <yury.norov@...il.com>,
 "nipun.gupta@....com" <nipun.gupta@....com>,
 "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
 "patches@...ts.linux.dev" <patches@...ts.linux.dev>,
 "jean-philippe@...aro.org" <jean-philippe@...aro.org>,
 "mdf@...nel.org" <mdf@...nel.org>, "mshavit@...gle.com"
 <mshavit@...gle.com>, "smostafa@...gle.com" <smostafa@...gle.com>,
 "ddutile@...hat.com" <ddutile@...hat.com>
Subject: Re: [PATCH RFCv2 00/13] iommu: Add MSI mapping support with nested
 SMMU




On 1/29/25 4:04 PM, Jason Gunthorpe wrote:
> On Wed, Jan 29, 2025 at 03:54:48PM +0100, Eric Auger wrote:
>>>> or you are just mentioning it here because
>>>> it is still possible to make use of that. I think from previous discussions the
>>>> argument was to adopt a more dedicated MSI pass-through model which I
>>>> think is  approach-2 here.  
>>> The basic flow of the pass through model is shown in the last two
>>> patches, it is not fully complete but is testable. It assumes a single
>>> ITS page. The VM would use IOMMU_OPTION_SW_MSI_START/SIZE to put the
>>> ITS page at the correct S2 location and then describe it in the ACPI
>>> as an ITS page not a RMR.
>> This is a nice to have feature but not mandated in the first place,
>> is it?
> Not mandated. It just sort of happens because of the design. IMHO
> nothing should use it because there is no way for userspace to
> discover how many ITS pages there may be.
>
>>> This missing peice is cleaning up the ITS mapping to allow for
>>> multiple ITS pages. I've imagined that kvm would someone give iommufd
>>> a FD that holds the specific ITS pages instead of the
>>> IOMMU_OPTION_SW_MSI_START/SIZE flow.
>> That's what I don't get: at the moment you only pass the gIOVA. With
>> technique 2, how can you build the nested mapping, ie.
>>
>>          S1           S2
>> gIOVA    ->    gDB    ->    hDB
>>
>> without passing the full gIOVA/gDB S1 mapping to the host?
> The nested S2 mapping is already setup before the VM boots:
>
>  - The VMM puts the ITS page (hDB) into the S2 at a fixed address (gDB)
Ah OK. Your gDB has nothing to do with the actual S1 guest gDB, right?
It is computed in iommufd_sw_msi_get_map() from the sw_msi_start pool.
Is that correct? In
https://lore.kernel.org/all/20210411111228.14386-9-eric.auger@redhat.com/
I was passing both the gIOVA and the "true" gDB Eric
>  - The ACPI tells the VM that the GIC has an ITS page at the S2's
>    address (hDB)
>  - The VM sets up its S1 with a gIOVA that points to the S2's ITS 
>    page (gDB). The S2 already has gDB -> hDB.
>  - The VMM traps the gIOVA write to the MSI-X table. Both the S1 and
>    S2 are populated at this moment.
>
> If you have multiple ITS pages then the ACPI has to tell the guest GIC
> about them, what their gDB address is, and what devices use which ITS.
>
> Jason
>