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: <fc39973a-3f57-87d0-ff46-15a09e9b5f58@amd.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ