From: Yunsheng Lin linyunsheng@huawei.com Sent: Thursday, June 10, 2021 12:34 PM
On 2021/6/9 21:45, Parav Pandit wrote:
From: Yunsheng Lin linyunsheng@huawei.com Sent: Wednesday, June 9, 2021 6:00 PM
On 2021/6/9 19:59, Parav Pandit wrote:
From: Yunsheng Lin linyunsheng@huawei.com Sent: Wednesday, June 9, 2021 4:35 PM
On 2021/6/9 17:38, Parav Pandit wrote:
> From: Yunsheng Lin linyunsheng@huawei.com > Sent: Wednesday, June 9, 2021 2:46 PM > [..]
>>> Is there any reason why VF use its own devlink instance? >> >> Primary use case for VFs is virtual environments where guest >> isn't trusted, so tying the VF to the main devlink instance, >> over which guest should have no control is counter productive. > > The security is mainly about VF using in container case, right? > Because VF using in VM, it is different host, it means a > different devlink instance for VF, so there is no security issue > for VF using in VM
case?
> But it might not be the case for VF using in container? Devlink instance has net namespace attached to it controlled using devlink
reload command.
So a VF devlink instance can be assigned to a container/process running in a
specific net namespace.
$ ip netns add n1 $ devlink dev reload pci/0000:06:00.4 netns n1 ^^^^^^^^^^^^^ PCI VF/PF/SF.
Could we create another devlink instance when the net namespace of devlink port instance is changed?
Net namespace of (a) netdevice (b) rdma device (c) devlink instance can be
changed.
Net namespace of devlink port cannot be changed.
Yes, net namespace is changed based on the devlink instance, not devlink port instance, *right now*.
It may seems we need to change the net namespace based on devlink port instance instead of devlink instance. This way container case seems be similiar to the VM case?
I mostly do not understand the topology you have in mind or if you
explained previously I missed the thread.
In your case what is the flavour of a devlink port?
flavour of the devlink port instance is FLAVOUR_PHYSICAL or FLAVOUR_VIRTUAL.
The reason I suggest to change the net namespace on devlink port instance instead of devlink instance is： I proposed that all the PF and VF in the same ASIC are registered to the same devlink instance as flavour FLAVOUR_PHYSICAL or FLAVOUR_VIRTUAL when there are in the same host and in the same net
namespace.
If a VF's devlink port instance is unregistered from old devlink instance in the old net namespace and registered to new devlink instance in the new net namespace(create a new devlink instance if needed) when devlink port instance's net namespace is changed, then the security mentioned by jakub is not a issue any more?
It seems that devlink instance of VF is not needed in your case, and if so
what is the motivation to even have VIRTUAL port attach to the PF?
The devlink instance is mainly used to hold the devlink port instance of VF if there is only one VF in vm, we might still need to have param/health specific to the VF to registered to the devlink port instance of that VF.
This will cover things uniformly with/without container or VM.
If only netdevice of the VF is of interest, it can be assigned to net
namespace directly.
I think that is another option, if there is nothing in the devlink port instance specific to VF that need exposing to the user in another net namespace.
Yes. no need for devlink instance or devlink port.
It doesn’t make sense to me to create new devlink instance in new net
namespace, that also needs to be deleted when net ns is deleted.
And pre_exit() routine will mostly deadlock holding global devlink_mutex.
Would you be more specific why there is deadlock?
Net namespace exit routine cannot invoke a devlink API that demands acquiring devlink global mutex.