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: <de6b9dc1-dedd-4a3d-9db7-cb4b8e281697@redhat.com>
Date: Wed, 29 Jan 2025 15:54:48 +0100
From: Eric Auger <eric.auger@...hat.com>
To: Jason Gunthorpe <jgg@...dia.com>,
 Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>
Cc: 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/23/25 2:24 PM, Jason Gunthorpe wrote:
> On Thu, Jan 23, 2025 at 09:06:49AM +0000, Shameerali Kolothum Thodi wrote:
>
>> One confusion I have about the above text is, do we still plan to support the
>> approach -1( Using RMR in Qemu)
> Yes, it remains an option. The VMM would use the
> IOMMU_OPTION_SW_MSI_START/SIZE ioctls to tell the kernel where it
> wants to put the RMR region then it would send the RMR into the VM
> through ACPI.
>
> The kernel side promises that the RMR region will have a consistent
> (but unpredictable!) layout of ITS pages (however many are required)
> within that RMR space, regardless of what devices/domain are attached.
>
> I would like to start with patches up to #10 for this part as it
> solves two of the three problems here.
>
>> 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?
>
> The VMM will capture the MSI writes and use
> VFIO_IRQ_SET_ACTION_PREPARE to convey the guests's S1 translation to
> the IRQ subsystem.
>
> 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?

Eric


>
> Jason
>