linux-kernel - RE: [PATCH V3 2/4] misc: vop: do not allocate and reassign the used ring

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, 29 Oct 2020 02:42:35 +0000
From:   Sherry Sun <sherry.sun@....com>
To:     Arnd Bergmann <arnd@...nel.org>
CC:     "Dutt, Sudeep" <sudeep.dutt@...el.com>,
        "vincent.whitchurch@...s.com" <vincent.whitchurch@...s.com>,
        dl-linux-imx <linux-imx@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "hch@...radead.org" <hch@...radead.org>,
        "kishon@...com" <kishon@...com>,
        "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "Dixit, Ashutosh" <ashutosh.dixit@...el.com>
Subject: RE: [PATCH V3 2/4] misc: vop: do not allocate and reassign the used
 ring

Hi Arnd,

> Subject: Re: [PATCH V3 2/4] misc: vop: do not allocate and reassign the used
> ring
> 
> (resending from the kernel.org address after getting bounces again)
> 
> On Wed, Oct 28, 2020 at 7:29 AM Sherry Sun <sherry.sun@....com> wrote:
> > > Subject: Re: [PATCH V3 2/4] misc: vop: do not allocate and reassign
> > > the used
> > >
> > > Both Ashutosh and I have moved on to other projects. The MIC devices
> > > have been discontinued. I have just sent across a patch to remove
> > > the MIC drivers from the kernel tree.
> > >
> > > We are very glad to see that Sherry is able to reuse some of the VOP
> > > logic and it is working well. It is best if the MIC drivers are
> > > removed so Sherry can add the specific VOP logic required for imx8qm
> > > subsequently without having to worry about other driver dependencies.
> > > Hoping this results in a cleaner imx8qm driver moving forward.
> >
> > I'm ok with your patch.
> > Since you have deprecated the MIC related code, may I ask do you have
> > a better solution instead of vop/scif?
> 
> I think we should try to do something on top of the PCIe endpoint subsystem
> to make it work across arbitrary combinations of host and device
> implementations, and provide a superset of what the MIC driver, (out-of-
> tree) Bluefield endpoint driver, and the NTB subsystem as well as a couple of
> others used to do, each of them tunneling block/network/serial/... over a
> PCIe link of some sort, usually with virtio.
> 
> At the moment, there is only one driver for the endpoint framework in the
> kernel, in drivers/pci/endpoint/functions/pci-epf-test.c, but I think this can
> serve as a starting point.
> 

Thanks for your detailed reply.
Yes, the PCIe endpoint subsystem is the base code, actually we have implemented a set of pci endpoint code similar to pci-epf-test.c, combine with vop (Virtio Over PCIe).

But now the vop code is going to be removed, we planned to change to NTB framework, I saw Kishon has done some jobs based on NTB and PCIe endpoint subsystem, will get a deep look. Maybe it is a good solution.

Best regards
Sherry

> The PCI endpoint subsystem already uses configfs for configuring the
> available devices, and this seems like a good fit for making it work in general.
> However, there are a number of use cases that have somewhat conflicting
> requirements, so the first step would be to figure out what everyone actually
> needs for virtio communication.
> 
> These are some of the main differences that I have noticed in the
> past:
> 
> - The simple case would be to use one PCIe endpoint device
>   for each virtio device, but I think this needs to be multiplexed
>   so that hardware that only supports a single PCIe endpoint
>   can still have multiple virtio devices tunneled through it.
> 
> - While sometimes the configuration is hardcoded in the driver, ideally
>   the type of virtio device(s) that is tunneled over the PCIe link should
>   be configurable. The configuration of the endpoint device itself is
>   done on the machine running on the endpoint side, but for the
>   virtio devices, this might be either on the host or the endpoint.
>   Not sure if one of the two ways is common enough, or we have to
>   allow both.
> 
> - When the link is configured, you still need one side to provide a
>   virtio device host implementation, while the other side would
>   run the normal virtio device driver. Again, these could be done
>   either way, and it is independent of which side has configured
>   the link, and we might want to only allow one of the two options,
>   or do both, or tie it to who configures it (e.g. the side that creates
>   the device must be the virtio device host, while the other side
>   just sees the device pop up and uses a virtio driver).
> 
>        Arnd