netdev - Re: [PATCH v3 net-next 00/14] pds

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] [day] [month] [year] [list]

Message-ID: <d25e13d9-f391-ccac-fb98-ee7c0978e97b@amd.com>
Date:   Sat, 25 Feb 2023 14:57:39 -0800
From:   Shannon Nelson <shannon.nelson@....com>
To:     netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        Jiri Pirko <jiri@...nulli.us>,
        Leon Romanovsky <leon@...nel.org>
Cc:     drivers@...sando.io, brett.creeley@....com
Subject: Re: [PATCH v3 net-next 00/14] pds_core driver

On 2/17/23 2:55 PM, Shannon Nelson wrote:
> Summary:
> --------
> This patchset implements new driver for use with the AMD/Pensando
> Distributed Services Card (DSC), intended to provide core configuration
> services through the auxiliary_bus for VFio and vDPA feature specific
> drivers.

Thank you all for your responses and commentary on this initial review 
of our PDS drivers, we appreciate the constructive input.

Obviously, the organization of our driver parts, PCI vs auxiliary and PF 
vs VF, doesn’t match what most folks were expecting to see.  The primary 
issue seems to be that the modules responsible for the VF’s functions 
(e.g. the VFio or vDPA modules) are set up to be both PCI and auxiliary 
drivers, which doesn’t match other designs, and presents potential 
coordination/locking concerns.

The expectation seems to be that the one Core module should handle both 
the VF and PF PCI driver work and from there set up the needed auxiliary 
devices, and things like vDPA modules should just be auxiliary drivers 
on one end and supply their respective features on the other end. 
Meanwhile, because the nature of VFio is to be a PCI driver, pds_vfio 
needs to have its aux stuff removed and needs to access the pds_core 
adminq directly by getting a pointer to the PF’s data, as done in other 
similar drivers.

We think this reorganization of parts will resolve the complexity, 
bind/unbind, and most other points of discussion.

I expect to get a first pass at this re-org done over the next few days 
and have an RFC for viewing sometime in the next week.

Cheers,
sln