linux-kernel - RE: vPASID capability for VF

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: <BN9PR11MB5276AE43183A3AA6AB806A398C749@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Thu, 11 May 2023 07:42:45 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>
CC:     Alex Williamson <alex.williamson@...hat.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Liu, Yi L" <yi.l.liu@...el.com>,
        "Nicolin Chen" <nicolinc@...dia.com>,
        "Lu, Baolu" <baolu.lu@...el.com>
Subject: RE: vPASID capability for VF

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Thursday, May 11, 2023 4:39 AM
> 
> On Wed, May 10, 2023 at 02:16:05AM +0000, Tian, Kevin wrote:
> 
> > We don't have a control knob to hide/unhide a specific PCI cap
> > today. It's hardcoded with proper virtualization policy in vfio-pci.
> >
> > Following current convention once vfio-pci adds the support for the
> > PASID cap it will be exposed if present (for VF it's the presence in PF).
> 
> We probably shouldn't do this - the PASID cap should only exist if the
> VMM is actualy able to handle PASID throughout, and currently no VMM
> does this.
> 
> So we can't just have the kernel unconditionally add the cap. There
> needs to be a negotiation with the VMM
> 

emmm. if that is the case probably we want to convey the cap to
userspace in a separate interface. I don't think it's a good idea to
give the user inconsistent vconfig layout before and after the user
negotiates.

Probably a device feature? The VMM calls device feature ioctl to
query whether PASID is supported (together with the pasid bits)
and to enable/disable it.

This also allows the user to opt whether it wants to manage PASIDs
itself or go to a simple scheme to get them from the kernel.

The VMM is responsible for finding an offset in vconfig space, e.g.
adopting your suggestion to find a gap between caps and block hidden
registers on a device if vPASID is favored and add quirks otherwise.