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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f6e93350-e0ee-649a-bf97-314398481fc8@redhat.com>
Date:   Thu, 9 Dec 2021 17:37:58 +0100
From:   Eric Auger <eric.auger@...hat.com>
To:     Jason Gunthorpe <jgg@...dia.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

Hi Jason,

On 12/9/21 4:40 PM, Jason Gunthorpe wrote:
> 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?
The upstream vSMMUv3 emulation does not support multiple CDs at the
moment and since I have no proper means to validate the vSVA case I am
rejecting any attempt from user space to inject guest configs featuring
mutliple PASIDs. Also PASID cache invalidation must be added to this series.

Nevertheless those limitations were tackled and overcomed by others in
CC so I don't think there is any blocking issue.

Thanks

Eric
>
> Jason
>