linux-kernel - Re: Programming PASID in IMS entries

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]

Date:   Thu, 08 Jul 2021 15:00:42 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Raj\, Ashok" <ashok.raj@...el.com>
Cc:     "Dey\, Megha" <megha.dey@...el.com>, linux-kernel@...r.kernel.org,
        "Jiang\, Dave" <dave.jiang@...el.com>,
        "Tian\, Kevin" <kevin.tian@...el.com>,
        "Pan\, Jacob jun" <jacob.jun.pan@...el.com>,
        "Liu\, Yi L" <yi.l.liu@...el.com>, jgg@...lanox.com,
        "Kumar\, Sanjay K" <sanjay.k.kumar@...el.com>,
        "Van De Ven\, Arjan" <arjan.van.de.ven@...el.com>,
        "Williams\, Dan J" <dan.j.williams@...el.com>,
        "Shankar\, Ravi V" <ravi.v.shankar@...el.com>,
        Ashok Raj <ashok.raj@...el.com>
Subject: Re: Programming PASID in IMS entries

Ashok,

On Wed, Jul 07 2021 at 15:12, Ashok Raj wrote:
> On Wed, Jul 07, 2021 at 10:50:52AM +0200, Thomas Gleixner wrote:
>> On Wed, Jul 07 2021 at 09:49, Megha Dey wrote:
>> > Per your suggestions during the last meeting, we wanted to confirm the 
>> > sequence to program the PASID into the IMS entries:
>> >
>> > 1. Add a PASID member to struct msi_desc (Add as part of a union. Other 
>> > source-id's such as Jason's vm-id can be added to it)
>> 
>> Yes. Though we also discussed storing the default PASID in struct device
>> to begin with which is then copied to the msi_desc entries during
>> allocation.
>
> Using default PASID in struct device will work for sub-devices until the
> guest needs to enable ENQCMD support. Since the guest kernel can ask for an
> interrupt by specifying something in the descriptor submitted via ENQCMD.
> Using the PASID in struct device won't be sufficient.

I'm well aware of that, but can we solve step 1 before step 2 please?

>> > In order to make IMS dynamic, we were thinking of the following 
>> > enhancements to the IMS core:
>> >
>> > 1. Device Driver specifies maximum number of interrupts the sub device 
>> > is allowed to request, while creating the dev-msi domain. E.g. in the 
>> > case of DSA, Driver can specify that each mdev created can have upto X
>> 
>> Why would this be mdev specific? IIRC the sub devices can be used on
>> bare metal as well.
>
> I guess so. I thought for bare metal we don't need to play these games
> since native abstraction is provided with things like uaccel for e.g. For
> things like SRIOV its much different.
>
> What the above limit accomplishes is telling the guest, you can request
> upto the limit, but you aren't guaranteed to get them. This avoids the
> static partitioning and becomes best effort by the host driver.

That's fine.

> Ideally we want to tell the guest it can have upto say 1k interrupts, but
> unlike MSIx where resources are commited in HW, we want to allow guest
> allocations to fail. 

Which as discussed requires a hypercall because silent fail is not an
option.

Thanks,

        tglx