linux-kernel - Re: [RFC v16 1/9] iommu: Introduce attach/detach_pasid

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: <20211209154046.GQ6385@nvidia.com>
Date:   Thu, 9 Dec 2021 11:40:46 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Eric Auger <eric.auger@...hat.com>
Cc:     Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Lu Baolu <baolu.lu@...ux.intel.com>,
        Joerg Roedel <joro@...tes.org>, peter.maydell@...aro.org,
        kvm@...r.kernel.org, vivek.gautam@....com,
        kvmarm@...ts.cs.columbia.edu, eric.auger.pro@...il.com,
        ashok.raj@...el.com, maz@...nel.org, vsethi@...dia.com,
        zhangfei.gao@...aro.org, kevin.tian@...el.com, will@...nel.org,
        alex.williamson@...hat.com, wangxingang5@...wei.com,
        linux-kernel@...r.kernel.org, lushenming@...wei.com,
        iommu@...ts.linux-foundation.org, robin.murphy@....com
Subject: Re: [RFC v16 1/9] iommu: Introduce attach/detach_pasid_table API

On Thu, Dec 09, 2021 at 08:50:04AM +0100, Eric Auger wrote:

> > The kernel API should accept the S1ContextPtr IPA and all the parts of
> > the STE that relate to the defining the layout of what the S1Context
> > points to an thats it.

> Yes that's exactly what is done currently. At config time the host must
> trap guest STE changes (format and S1ContextPtr) and "incorporate" those
> changes into the stage2 related STE information. The STE is owned by the
> host kernel as it contains the stage2 information (S2TTB).

[..]

> Note this series only coped with a single CD in the Context Descriptor
> Table.

I'm confused, where does this limit arise?

The kernel accepts as input all the bits in the STE that describe the
layout of the CDT owned by userspace, shouldn't userspace be able to
construct all forms of CDT with any number of CDs in them?

Or do you mean this is some qemu limitation?

Jason