linux-kernel - Re: [PATCH v5 0/5] iommu aux-domain APIs extensions

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] [day] [month] [year] [list]

Message-ID: <71f1fa5e-f468-0498-1ab4-1c2af9424d2d@linux.intel.com>
Date:   Fri, 25 Sep 2020 09:09:54 +0800
From:   Lu Baolu <baolu.lu@...ux.intel.com>
To:     Joerg Roedel <joro@...tes.org>
Cc:     baolu.lu@...ux.intel.com,
        Alex Williamson <alex.williamson@...hat.com>,
        Robin Murphy <robin.murphy@....com>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Cornelia Huck <cohuck@...hat.com>,
        Kevin Tian <kevin.tian@...el.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Liu Yi L <yi.l.liu@...el.com>, Zeng Xin <xin.zeng@...el.com>,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Subject: Re: [PATCH v5 0/5] iommu aux-domain APIs extensions

Hi Joerg,

On 9/24/20 5:55 PM, Joerg Roedel wrote:
> On Tue, Sep 22, 2020 at 02:10:37PM +0800, Lu Baolu wrote:
>> Hi Jorge and Alex,
>>
>> A description of this patch series could be found here.
>>
>> https://lore.kernel.org/linux-iommu/20200901033422.22249-1-baolu.lu@linux.intel.com/
> 
> Hmm, I am wondering if we can avoid all this hassle and special APIs by
> making the mdev framework more visible outside of the vfio code. There
> is an underlying bus implementation for mdevs, so is there a reason
> those can't use the standard iommu-core code to setup IOMMU mappings?

The original purpose of this series is to enable the device driver to
retrieve the aux-domain through iommu core after iommu
ops.aux_attach_dev().

The domain was allocated in vfio/mdev, but it's also needed by the
device driver in mediated callbacks. The idea of this patch series is to
extend the aux-API so that the domain could be saved in group->domain
and get by the mediated driver through the existing
iommu_get_domain_for_dev().

Back when we were developing the aux-domain, I proposed to keep the
domain in vfio/mdev.

https://lore.kernel.org/linux-iommu/20181105073408.21815-7-baolu.lu@linux.intel.com/

It wasn't discussed at that time due to the lack of real consumer. Intel
is now adding aux-domain support in idxd (DMA streaming accelerator)
driver which becomes the first real consumer. So this problem is brought
back to the table.

> 
> What speaks against doing:
> 
> 	- IOMMU drivers capable of handling mdevs register iommu-ops
> 	  for the mdev_bus.
> 
> 	- iommu_domain_alloc() takes bus_type as parameter, so there can
> 	  be special domains be allocated for mdevs.
> 
> 	- Group creation and domain allocation will happen
> 	  automatically in the iommu-core when a new mdev is registered
> 	  through device-driver core code.
> 
> 	- There should be no need for special iommu_aux_* APIs, as one
> 	  can attach a domain directly to &mdev->dev with
> 	  iommu_attach_device(domain, &mdev->dev).
> 
> Doing it this way will probably also keep the mdev-special code in VFIO
> small.

Fully understand now. Thanks for guide.

> 
> Regards,
> 
> 	Joerg
> 

Best regards,
baolu