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

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

Message-ID: <cb087202-3a64-428c-bba2-196a3612e5ff@redhat.com>
Date: Tue, 4 Feb 2025 13:55:01 +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

Hi Jason,


On 1/29/25 9:13 PM, Jason Gunthorpe wrote:
> On Wed, Jan 29, 2025 at 06:46:20PM +0100, Eric Auger wrote:
>>>>> 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?
> I'm not totally sure what you mean by gDB? The above diagram suggests
> it is the ITS page address in the S2? Ie the guest physical address of
> the ITS.
Yes this is what I meant, ie. the guest ITS doorbell GPA
>
> Within the VM, when it goes to call iommu_dma_prepare_msi(), it will
> provide the gDB adress as the phys_addr_t msi_addr.
>
> This happens because the GIC driver will have been informed of the ITS
> page at the gDB address, and it will use
> iommu_dma_prepare_msi(). Exactly the same as bare metal.

understood this is the standard MSI binding scheme.
>
>> It is computed in iommufd_sw_msi_get_map() from the sw_msi_start pool.
>> Is that correct?
> Yes, for a single ITS page it will reliably be put at sw_msi_start.
> Since the VMM can provide sw_msi_start through the OPTION, the VMM can
> place the ITS page where it wants and then program the ACPI to tell
> the VM to call iommu_dma_prepare_msi(). (don't use this flow, it
> doesn't work for multi ITS, for testing only)
OK so you need to set host sw_msi_start to the guest doorbell GPA which
is currently set, in qemu, at
GITS_TRANSLATER 0x08080000 + 0x10000

In my original integration, I passed pairs of S1 gIOVA/gDB used by the
guest and this gDB was directly reused for mapping hDB.

I think I get it now.

Eric
>
>> https://lore.kernel.org/all/20210411111228.14386-9-eric.auger@redhat.com/
>> I was passing both the gIOVA and the "true" gDB Eric
> If I understand this right, it still had the hypervisor dynamically
> setting up the S2, here it is pre-set and static?
>
> Jason
>