linux-kernel - Re: [virtio-dev] Re: [PATCH] vdpa/mlx5: set

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] [day] [month] [year] [list]

Date:   Fri, 5 Mar 2021 11:01:28 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Cornelia Huck <cohuck@...hat.com>
Cc:     "Michael S. Tsirkin" <mst@...hat.com>,
        Si-Wei Liu <si-wei.liu@...cle.com>, elic@...dia.com,
        linux-kernel@...r.kernel.org,
        virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org,
        virtio-dev@...ts.oasis-open.org
Subject: Re: [virtio-dev] Re: [PATCH] vdpa/mlx5: set_features should allow
 reset to zero


On 2021/3/4 9:50 下午, Cornelia Huck wrote:
> On Thu, 4 Mar 2021 16:24:16 +0800
> Jason Wang <jasowang@...hat.com> wrote:
>
>> On 2021/3/3 4:29 下午, Cornelia Huck wrote:
>>> On Wed, 3 Mar 2021 12:01:01 +0800
>>> Jason Wang <jasowang@...hat.com> wrote:
>>>   
>>>> On 2021/3/2 8:08 下午, Cornelia Huck wrote:
>>>>> On Mon, 1 Mar 2021 11:51:08 +0800
>>>>> Jason Wang <jasowang@...hat.com> wrote:
>>>>>      
>>>>>> On 2021/3/1 5:25 上午, Michael S. Tsirkin wrote:
>>>>>>> On Fri, Feb 26, 2021 at 04:19:16PM +0800, Jason Wang wrote:
>>>>>>>> On 2021/2/26 2:53 上午, Michael S. Tsirkin wrote:
>>>>>>>>> Confused. What is wrong with the above? It never reads the
>>>>>>>>> field unless the feature has been offered by device.
>>>>>>>> So the spec said:
>>>>>>>>
>>>>>>>> "
>>>>>>>>
>>>>>>>> The following driver-read-only field, max_virtqueue_pairs only exists if
>>>>>>>> VIRTIO_NET_F_MQ is set.
>>>>>>>>
>>>>>>>> "
>>>>>>>>
>>>>>>>> If I read this correctly, there will be no max_virtqueue_pairs field if the
>>>>>>>> VIRTIO_NET_F_MQ is not offered by device? If yes the offsetof() violates
>>>>>>>> what spec said.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>> I think that's a misunderstanding. This text was never intended to
>>>>>>> imply that field offsets change beased on feature bits.
>>>>>>> We had this pain with legacy and we never wanted to go back there.
>>>>>>>
>>>>>>> This merely implies that without VIRTIO_NET_F_MQ the field
>>>>>>> should not be accessed. Exists in the sense "is accessible to driver".
>>>>>>>
>>>>>>> Let's just clarify that in the spec, job done.
>>>>>> Ok, agree. That will make things more eaiser.
>>>>> Yes, that makes much more sense.
>>>>>
>>>>> What about adding the following to the "Basic Facilities of a Virtio
>>>>> Device/Device Configuration Space" section of the spec:
>>>>>
>>>>> "If an optional configuration field does not exist, the corresponding
>>>>> space is still present, but reserved."
>>>> This became interesting after re-reading some of the qemu codes.
>>>>
>>>> E.g in virtio-net.c we had:
>>>>
>>>> *static VirtIOFeature feature_sizes[] = {
>>>>        {.flags = 1ULL << VIRTIO_NET_F_MAC,
>>>>         .end = endof(struct virtio_net_config, mac)},
>>>>        {.flags = 1ULL << VIRTIO_NET_F_STATUS,
>>>>         .end = endof(struct virtio_net_config, status)},
>>>>        {.flags = 1ULL << VIRTIO_NET_F_MQ,
>>>>         .end = endof(struct virtio_net_config, max_virtqueue_pairs)},
>>>>        {.flags = 1ULL << VIRTIO_NET_F_MTU,
>>>>         .end = endof(struct virtio_net_config, mtu)},
>>>>        {.flags = 1ULL << VIRTIO_NET_F_SPEED_DUPLEX,
>>>>         .end = endof(struct virtio_net_config, duplex)},
>>>>        {.flags = (1ULL << VIRTIO_NET_F_RSS) | (1ULL <<
>>>> VIRTIO_NET_F_HASH_REPORT),
>>>>         .end = endof(struct virtio_net_config, supported_hash_types)},
>>>>        {}
>>>> };*
>>>>
>>>> *It has a implict dependency chain. E.g MTU doesn't presnet if
>>>> DUPLEX/RSS is not offered ...
>>>> *
>>> But I think it covers everything up to the relevant field, no? So MTU
>>> is included if we have the feature bit, even if we don't have
>>> DUPLEX/RSS.
>>>
>>> Given that a config space may be shorter (but must not collapse
>>> non-existing fields), maybe a better wording would be:
>>>
>>> "If an optional configuration field does not exist, the corresponding
>>> space will still be present if it is not at the end of the
>>> configuration space (i.e., further configuration fields exist.)
>>
>> This should work but I think we need to define the end of configuration
>> space first?
> What about sidestepping this:
>
> "...the corresponding space will still be present, unless no further
> configuration fields exist."
>
> ?


It might work. (I wonder maybe we can give some example in the spec).

Thanks


>
>>> This
>>> implies that a given field, if it exists, is always at the same offset
>>> from the beginning of the configuration space."