linux-kernel - Re: [PATCH 3/4] iommu: Introduce IOMMU call-back for processing struct KVM assigned to VFIO

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: <b366355b-1f63-ee5d-28d7-9269cb699d0e@arm.com>
Date:   Tue, 17 Jan 2023 12:51:03 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     "Suthikulpanit, Suravee" <suravee.suthikulpanit@....com>,
        linux-kernel@...r.kernel.org, iommu@...ts.linux.dev
Cc:     joro@...tes.org, ashish.kalra@....com, thomas.lendacky@....com,
        vasant.hegde@....com, jon.grimm@....com
Subject: Re: [PATCH 3/4] iommu: Introduce IOMMU call-back for processing
 struct KVM assigned to VFIO

On 2023-01-17 04:20, Suthikulpanit, Suravee wrote:
> Hi Robin,
> 
> On 1/10/2023 10:11 PM, Robin Murphy wrote:
>> On 2023-01-10 14:31, Suravee Suthikulpanit wrote:
>>> Currently, VFIO provide an kvm_vfio_file_set_kvm() interface for 
>>> assigning
>>> a KVM structure to a VFIO group. The information in struct KVM is also
>>> useful for IOMMU drivers when setting up VFIO domain.
>>>
>>> Introduce struct iommu_domain_ops.set_kvm call-back function to allow
>>> IOMMU drivers to provide call-back to process the struct KVM assigned.
>>
>> Hmm, it sounds like this has quite some overlap of intent with the 
>> existing "enable_nesting" op, and my gut feeling is that it's not 
>> great to have two completely different "this is a VFIO domain" 
>> mechanisms... :/
>>
>> Robin.
> 
> Actually, the intention is to communicate KVM information, which is 
> already available to the VFIO down to the AMD IOMMU driver layer. I am 
> not sure if the enable_nesting() has enough information or the same 
> intention since that only communicates VFIO domain information.

Sure, but from the high level view, we have on the one hand an API for 
"I want to use this domain in a VM (with nested paging)" and on other an 
API for "I want to use nested paging in this domain (for a VM)", so 
clearly it would be most sensible to converge on a single API for what 
is ultimately one single overarching use-case.

I'm not claiming that the existing enable_nesting op is anywhere near 
the right design either; in fact I'm pretty sure it isn't, if the Arm 
SMMU drivers ever want to contemplate sharing stage 2 pagetables with 
KVM also.

Cheers,
Robin.