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: <BN9PR11MB5276EBE887402EBE22630BAB8C099@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Tue, 8 Mar 2022 08:11:11 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Alex Williamson <alex.williamson@...hat.com>,
        Shameerali Kolothum Thodi 
        <shameerali.kolothum.thodi@...wei.com>
CC:     Jason Gunthorpe <jgg@...dia.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "cohuck@...hat.com" <cohuck@...hat.com>,
        "mgurtovoy@...dia.com" <mgurtovoy@...dia.com>,
        "yishaih@...dia.com" <yishaih@...dia.com>,
        Linuxarm <linuxarm@...wei.com>,
        liulongfang <liulongfang@...wei.com>,
        "Zengtao (B)" <prime.zeng@...ilicon.com>,
        "Jonathan Cameron" <jonathan.cameron@...wei.com>,
        "Wangzhou (B)" <wangzhou1@...ilicon.com>,
        Xu Zaibo <xuzaibo@...wei.com>
Subject: RE: [PATCH v8 8/9] hisi_acc_vfio_pci: Add support for VFIO live
 migration

> From: Alex Williamson <alex.williamson@...hat.com>
> Sent: Tuesday, March 8, 2022 3:53 AM
> >
> > > I think we still require acks from Bjorn and Zaibo for select patches
> > > in this series.
> >
> > I checked with Ziabo. He moved projects and is no longer looking into
> crypto stuff.
> > Wangzhou and LiuLongfang now take care of this. Received acks from
> Wangzhou
> > already and I will request Longfang to provide his. Hope that's ok.
> 
> Maybe a good time to have them update MAINTAINERS as well.  Thanks,
> 

I have one question here (similar to what we discussed for mdev before).

Now we are adding vendor specific drivers under /drivers/vfio. Two drivers
on radar and more will come. Then what would be the criteria for 
accepting such a driver? Do we prefer to a model in which the author should
provide enough background for vfio community to understand how it works 
or as done here just rely on the PF driver owner to cover device specific
code?

If the former we may need document some process for what information
is necessary and also need secure increased review bandwidth from key
reviewers in vfio community.

If the latter then how can we guarantee no corner case overlooked by both
sides (i.e. how to know the coverage of total reviews)? Another open is who
from the PF driver sub-system should be considered as the one to give the
green signal. If the sub-system maintainer trusts the PF driver owner and
just pulls commits from him then having the r-b from the PF driver owner is
sufficient. But if the sub-system maintainer wants to review detail change
in every underlying driver then we probably also want to get the ack from
the maintainer.

Overall I didn't mean to slow down the progress of this series. But above
does be some puzzle occurred in my review. 😊

Thanks
Kevin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ