netdev - Re: [PATCH v8 net-next 10/14] pds_core: add auxiliary

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:   Sat, 1 Apr 2023 13:15:03 -0700
From:   Shannon Nelson <shannon.nelson@....com>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     brett.creeley@....com, davem@...emloft.net, netdev@...r.kernel.org,
        kuba@...nel.org, drivers@...sando.io, jiri@...nulli.us
Subject: Re: [PATCH v8 net-next 10/14] pds_core: add auxiliary_bus devices

On 4/1/23 11:27 AM, Leon Romanovsky wrote:
> 
> On Thu, Mar 30, 2023 at 04:46:24PM -0700, Shannon Nelson wrote:
>> An auxiliary_bus device is created for each vDPA type VF at VF probe
>> and destroyed at VF remove.  The VFs are always removed on PF remove, so
>> there should be no issues with VFs trying to access missing PF structures.
>>
>> Signed-off-by: Shannon Nelson <shannon.nelson@....com>
>> ---
>>   drivers/net/ethernet/amd/pds_core/Makefile |   1 +
>>   drivers/net/ethernet/amd/pds_core/auxbus.c | 142 +++++++++++++++++++++
>>   drivers/net/ethernet/amd/pds_core/core.h   |   6 +
>>   drivers/net/ethernet/amd/pds_core/main.c   |  36 +++++-
>>   include/linux/pds/pds_auxbus.h             |  16 +++
>>   include/linux/pds/pds_common.h             |   1 +
>>   6 files changed, 200 insertions(+), 2 deletions(-)
>>   create mode 100644 drivers/net/ethernet/amd/pds_core/auxbus.c
>>   create mode 100644 include/linux/pds/pds_auxbus.h
> 
> I feel that this auxbus usage is still not correct.
> 
> The idea of auxiliary devices is to partition physical device (for
> example PCI device) to different sub-devices, where every sub-device
> belongs to different sub-system. It is not intended to create per-VF
> devices.
> 
> In your case, you should create XXX vDPA auxiliary devices which are
> connected in one-to-one scheme to their PCI VF counterpart.

I don't understand - first I read
     "It is not intended to create per-VF devices"
and then
     "you should create XXX vDPA auxiliary devices which are
     connected in one-to-one scheme to their PCI VF counterpart."
These seem at first to be directly contradictory statements, so maybe 
I'm missing some nuance.

We have a PF device that has an adminq, VF devices that don't have an 
adminq, and the adminq is needed for some basic setup before the rest of 
the vDPA driver can use the VF.  To access the PF's adminq we set up an 
auxiliary device per feature in each VF - but currently only offer one 
feature (vDPA) and no sub-devices yet.  We're trying to plan for the future.

Is it that we only have one feature per VF so far is what is causing the 
discomfort?

sln