linux-kernel - Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

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: <20171011095126.GD30803@8bytes.org>
Date:   Wed, 11 Oct 2017 11:51:26 +0200
From:   Joerg Roedel <joro@...tes.org>
To:     "Liu, Yi L" <yi.l.liu@...el.com>
Cc:     Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
        Jean-Philippe Brucker <jean-philippe.brucker@....com>,
        "Lan, Tianyu" <tianyu.lan@...el.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        "Liu, Yi L" <yi.l.liu@...ux.intel.com>,
        "Liu@...tes.org" <Liu@...tes.org>
Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

On Wed, Oct 11, 2017 at 07:54:32AM +0000, Liu, Yi L wrote:
> I agree that iommu_invalidate() is too generic. Additionally, also
> better to avoid making it svm specific.

I also don't like to name the functions after the Intel feature, but I
failed to come up with a better alternative so far. The only one I can
come up with for now would be 'iovm', so the function name would be
iommu_iovm_invalidate().

On the other side, the ARM guys also already call the feature set
'SVM', despite it being ambiguous and Intel specific. I don't have a
strong opinion on the naming.

> The reason we introduce this API is in vSVM case is that guest owns
> the first level page table(vtd). If we use similar mechanism for
> vIOVA, then we also need to passdown guest's vIOVA tlb flush.
> 
> Since it is to expose an API for iommu tlb flushes requests from
> userspace/guest which is out of iommu. How about naming it as
> iommu_tlb_external_invalidate()?

If you only read the function name, 'external' could mean everything. It
is not clear from the name when to use this function. So something like
iommu_iovm_invalidate() is better.


	Joerg