linux-kernel - Re: [PATCH v3 5/6] vdpa/mlx5: conditionally show MTU and STATUS in config space

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: <6037e4db-43fb-253a-7036-9c10317bef45@nvidia.com>
Date:   Mon, 6 Feb 2023 08:52:41 +0200
From:   Eli Cohen <elic@...dia.com>
To:     Si-Wei Liu <si-wei.liu@...cle.com>, mst@...hat.com,
        jasowang@...hat.com, parav@...dia.com
Cc:     virtualization@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 5/6] vdpa/mlx5: conditionally show MTU and STATUS in
 config space


On 06/02/2023 6:53, Si-Wei Liu wrote:
>
>
> On 2/5/2023 1:36 AM, Eli Cohen wrote:
>>
>> On 03/02/2023 7:02, Si-Wei Liu wrote:
>>> The spec says:
>>>      mtu only exists if VIRTIO_NET_F_MTU is set
>>>      status only exists if VIRTIO_NET_F_STATUS is set
>>>
>>> We should only show MTU and STATUS conditionally depending on
>>> the feature bits.
>>>
>>> Signed-off-by: Si-Wei Liu <si-wei.liu@...cle.com>
>>> ---
>>>   drivers/vdpa/mlx5/net/mlx5_vnet.c | 22 ++++++++++++++--------
>>>   1 file changed, 14 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
>>> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>>> index 3a6dbbc6..867ac18 100644
>>> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
>>> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>>> @@ -3009,6 +3009,8 @@ static int event_handler(struct notifier_block 
>>> *nb, unsigned long event, void *p
>>>       struct mlx5_vdpa_wq_ent *wqent;
>>>         if (event == MLX5_EVENT_TYPE_PORT_CHANGE) {
>>> +        if (!(ndev->mvdev.actual_features & 
>>> BIT_ULL(VIRTIO_NET_F_STATUS)))
>>> +            return NOTIFY_DONE;
>>>           switch (eqe->sub_type) {
>>>           case MLX5_PORT_CHANGE_SUBTYPE_DOWN:
>>>           case MLX5_PORT_CHANGE_SUBTYPE_ACTIVE:
>>> @@ -3118,16 +3120,20 @@ static int mlx5_vdpa_dev_add(struct 
>>> vdpa_mgmt_dev *v_mdev, const char *name,
>>>               goto err_alloc;
>>>       }
>>>   -    err = query_mtu(mdev, &mtu);
>>> -    if (err)
>>> -        goto err_alloc;
>>> +    if (ndev->mvdev.mlx_features & BIT_ULL(VIRTIO_NET_F_MTU)) {
>>
>> VIRTIO_NET_F_MTU is offered by the device. So conditional is always 
>> true. 
> With the next patch in series that selectively provisions device 
> features to mlx5_vdpa, this conditional will not be always true. That 
> was the reason why I made patch 5 and 6 in a single commit, as this 
> conditional will only be needed until feature provisioning is 
> supported. Basically patch 5 and 6 are logically connected and 
> technically should be separated out. I'm now puzzled, what was your 
> thought then the change in patch 5 shouldn't be part of patch 6?

No, I think breaking into two patches is the right way to go.

I missed the fact the for setting MTU and MAC you need the device to 
*offer* the feature and does not depend on negotiation.

>
>> We are not done with feature negotiation at this stage so you
> 'You' are who? device, driver or guest user?
>
>> may still set a value to device mtu if MTU won't be negotiated 
>> eventually. But that is not a problem because the spec says:
>>
>>  VIRTIO_NET_F_MTU(3) Device maximum MTU reporting is supported. If 
>> offered by the device, device
>> advises driver about the value of its maximum MTU. If negotiated, the 
>> driver uses mtu as the maximum
>>
>> MTU value.
>>
>> So the driver will use whatever value is there only if negotiated.
> My understanding is that 'vdpa dev config' now displays user 
> provisioned config, or default config value advertised by the device, 
> rather than what config driver will actually use.
Reviewed-by: Eli Cohen <elic@...dia.com>
>
>>
>>> +        err = query_mtu(mdev, &mtu);
>>> +        if (err)
>>> +            goto err_alloc;
>>>   -    ndev->config.mtu = cpu_to_mlx5vdpa16(mvdev, mtu);
>>> +        ndev->config.mtu = cpu_to_mlx5vdpa16(mvdev, mtu);
>>> +    }
>>>   -    if (get_link_state(mvdev))
>>> -        ndev->config.status |= cpu_to_mlx5vdpa16(mvdev, 
>>> VIRTIO_NET_S_LINK_UP);
>>> -    else
>>> -        ndev->config.status &= cpu_to_mlx5vdpa16(mvdev, 
>>> ~VIRTIO_NET_S_LINK_UP);
>>> +    if (ndev->mvdev.mlx_features & BIT_ULL(VIRTIO_NET_F_STATUS)) {
>>> +        if (get_link_state(mvdev))
>>> +            ndev->config.status |= cpu_to_mlx5vdpa16(mvdev, 
>>> VIRTIO_NET_S_LINK_UP);
>>> +        else
>>> +            ndev->config.status &= cpu_to_mlx5vdpa16(mvdev, 
>>> ~VIRTIO_NET_S_LINK_UP);
>>> +    }
>> Same thing here. Feature negotiation is not complete yet and if
>>
>> VIRTIO_NET_F_STATUS ends up not being negotiated, the driver will 
>> ignore this value.
> See above. With feature provisioning, whether the VIRTIO_NET_F_STATUS 
> feature is advertised by device is subject to the device_features 
> value provisioned by the host admin users.
>
> -Siwei
>
>>
>>>         if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
>>>           memcpy(ndev->config.mac, add_config->net.mac, ETH_ALEN);
>