linux-kernel - Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension

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: <cf961f69-c559-eaf0-e168-b014779a1519@huawei.com>
Date:   Wed, 2 Jun 2021 10:24:11 +0800
From:   Yunsheng Lin <linyunsheng@...wei.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     moyufeng <moyufeng@...wei.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Parav Pandit <parav@...lanox.com>,
        Or Gerlitz <gerlitz.or@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "michal.lkml@...kovi.net" <michal.lkml@...kovi.net>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Jiri Pirko <jiri@...lanox.com>,
        Salil Mehta <salil.mehta@...wei.com>,
        "lipeng (Y)" <lipeng321@...wei.com>,
        Guangbin Huang <huangguangbin2@...wei.com>,
        <shenjian15@...wei.com>, "chenhao (DY)" <chenhao288@...ilicon.com>,
        Jiaran Zhang <zhangjiaran@...wei.com>
Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension

On 2021/6/2 5:34, Jakub Kicinski wrote:
> On Tue, 1 Jun 2021 15:33:09 +0800 Yunsheng Lin wrote:
>> On 2021/6/1 13:37, Jakub Kicinski wrote:
>>> On Mon, 31 May 2021 18:36:12 +0800 moyufeng wrote:  
>>>> Hi, Jiri & Jakub
>>>>
>>>>     Generally, a devlink instance is created for each PF/VF. This
>>>> facilitates the query and configuration of the settings of each
>>>> function. But if some common objects, like the health status of
>>>> the entire ASIC, the data read by those instances will be duplicate.
>>>>
>>>>     So I wonder do I just need to apply a public devlink instance for the
>>>> entire ASIC to avoid reading the same data? If so, then I can't set
>>>> parameters for each function individually. Or is there a better suggestion
>>>> to implement it?  
>>>
>>> I don't think there is a great way to solve this today. In my mind
>>> devlink instances should be per ASIC, but I never had to solve this
>>> problem for a multi-function ASIC.   
>>
>> Is there a reason why it didn't have to be solved yet?
>> Is it because the devices currently supporting devlink do not have
>> this kind of problem, like single-function ASIC or multi-function
>> ASIC without sharing common resource?
> 
> I'm not 100% sure, my guess is multi-function devices supporting
> devlink are simple enough for the problem not to matter all that much.
> 
>> Was there a discussion how to solved it in the past?
> 
> Not really, we floated an idea of creating aliases for devlink
> instances so a single devlink instance could answer to multiple 
> bus identifiers. But nothing concrete.

What does it mean by "answer to multiple bus identifiers"? I
suppose it means user provides the bus identifiers when setting or
getting something, and devlink instance uses that bus identifiers
to differentiate different PF in the same ASIC?

can devlink port be used to indicate different PF in the same ASIC,
which already has the bus identifiers in it? It seems we need a
extra identifier to indicate the ASIC?

$ devlink port show
...
pci/0000:03:00.0/61: type eth netdev sw1p1s0 split_group 0

> 
>>> Can you assume all functions are in the same control domain? Can they
>>> trust each other?  
>>
>> "same control domain" means if it is controlled by a single host, not
>> by multi hosts, right?
>>
>> If the PF is not passed through to a vm using VFIO and other PF is still
>> in the host, then I think we can say it is controlled by a single host.
>>
>> And each PF is trusted with each other right now, at least at the driver
>> level, but not between VF.
> 
> Right, the challenge AFAIU is how to match up multiple functions into 
> a single devlink instance, when driver has to probe them one by one.

Does it make sense if the PF first probed creates a auxiliary device,
and the auxiliary device driver creates the devlink instance? And
the PF probed later can connect/register to that devlink instance?

> If there is no requirement that different functions are securely
> isolated it becomes a lot simpler (e.g. just compare device serial
> numbers).

Is there any known requirement if the different functions are not
securely isolated?

> 
> .
>