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: <20170726090240.GD30429@8bytes.org>
Date:   Wed, 26 Jul 2017 11:02:40 +0200
From:   Joerg Roedel <joro@...tes.org>
To:     "Tian, Kevin" <kevin.tian@...el.com>
Cc:     Jean-Philippe Brucker <jean-philippe.brucker@....com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        "Lan, Tianyu" <tianyu.lan@...el.com>,
        "Liu, Yi L" <yi.l.liu@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        Jean Delvare <khali@...ux-fr.org>,
        David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 3/9] iommu: Introduce iommu do invalidate API function

On Wed, Jul 05, 2017 at 07:57:57AM +0000, Tian, Kevin wrote:
> > > struct tlb_invalidate_info
> > > {
> > >         __u32   model;  /* Vendor number */

I don't like to have a model-specifier here, as I don't think its
needed.

> > >         __u8 granularity
> > > #define DEVICE_SELECTVIE_INV    (1 << 0)
> > > #define PAGE_SELECTIVE_INV      (1 << 0)
> > > #define PASID_SELECTIVE_INV     (1 << 1)
> > >         __u32 pasid;
> > >         __u64 addr;
> > >         __u64 size;
> > >
> > >         /* Since IOMMU format has already been validated for this table,
> > >            the IOMMU driver knows that the following structure is in a
> > >            format it knows */
> > >         __u8 opaque[];
> > > };
> > >
> 
> I just gave some information in another thread:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00853.html
> 
> Below summarizes all the invalidation capabilities supported by Intel VTd:
> 
> Scope: All PASIDs, single PASID
> for each PASID:
>         all mappings, or page-selective mappings (addr, size)
> invalidation target:
>         IOTLB entries (leaf)
>         paging structure cache (non-leaf)
>         PASID cache (pasid->cr3)
> invalidation hint:
>         whether global pages are included
>         drain reads/writes

The AMD IOMMU for example supports similar flushing capabilities. They
are all based on a IOMMU-independent PCI standards (PASID, PRI, ATS),
and the interface can be designed around those standards instead of
IOMMU hardware implementations.

If a given hardware implementation does not support all of the above
flushing modes, it is always free to flush more than requested as
supported by its capabilities.

Regards,

	Joerg

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ