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
| ||
|
Date: Wed, 22 Sep 2021 13:44:55 +0000 From: "Tian, Kevin" <kevin.tian@...el.com> To: Jason Gunthorpe <jgg@...dia.com> CC: "Liu, Yi L" <yi.l.liu@...el.com>, "alex.williamson@...hat.com" <alex.williamson@...hat.com>, "hch@....de" <hch@....de>, "jasowang@...hat.com" <jasowang@...hat.com>, "joro@...tes.org" <joro@...tes.org>, "jean-philippe@...aro.org" <jean-philippe@...aro.org>, "parav@...lanox.com" <parav@...lanox.com>, "lkml@...ux.net" <lkml@...ux.net>, "pbonzini@...hat.com" <pbonzini@...hat.com>, "lushenming@...wei.com" <lushenming@...wei.com>, "eric.auger@...hat.com" <eric.auger@...hat.com>, "corbet@....net" <corbet@....net>, "Raj, Ashok" <ashok.raj@...el.com>, "yi.l.liu@...ux.intel.com" <yi.l.liu@...ux.intel.com>, "Tian, Jun J" <jun.j.tian@...el.com>, "Wu, Hao" <hao.wu@...el.com>, "Jiang, Dave" <dave.jiang@...el.com>, "jacob.jun.pan@...ux.intel.com" <jacob.jun.pan@...ux.intel.com>, "kwankhede@...dia.com" <kwankhede@...dia.com>, "robin.murphy@....com" <robin.murphy@....com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>, "dwmw2@...radead.org" <dwmw2@...radead.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>, "david@...son.dropbear.id.au" <david@...son.dropbear.id.au>, "nicolinc@...dia.com" <nicolinc@...dia.com> Subject: RE: [RFC 03/20] vfio: Add vfio_[un]register_device() > From: Jason Gunthorpe <jgg@...dia.com> > Sent: Wednesday, September 22, 2021 8:23 PM > > On Wed, Sep 22, 2021 at 09:23:34AM +0000, Tian, Kevin wrote: > > > > Providing an ioctl to bind to a normal VFIO container or group might > > > allow a reasonable fallback in userspace.. > > > > I didn't get this point though. An error in binding already allows the > > user to fall back to the group path. Why do we need introduce another > > ioctl to explicitly bind to container via the nongroup interface? > > New userspace still needs a fallback path if it hits the 'try and > fail'. Keeping the device FD open and just using a different ioctl to > bind to a container/group FD, which new userspace can then obtain as a > fallback, might be OK. > > Hard to see without going through the qemu parts, so maybe just keep > it in mind > sure. will figure it out when working on the qemu part.
Powered by blists - more mailing lists