netdev - Re: [patch net-next v2 1/6] virtio: add debugfs infrastructure to allow to debug virtio features

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zh94zX-oQs96tuKk@nanopsycho>
Date: Wed, 17 Apr 2024 09:22:53 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jason Wang <jasowang@...hat.com>
Cc: netdev@...r.kernel.org, kuba@...nel.org, pabeni@...hat.com,
	davem@...emloft.net, edumazet@...gle.com, parav@...dia.com,
	mst@...hat.com, xuanzhuo@...ux.alibaba.com, shuah@...nel.org,
	petrm@...dia.com, liuhangbin@...il.com, vladimir.oltean@....com,
	bpoirier@...dia.com, idosch@...dia.com,
	virtualization@...ts.linux.dev
Subject: Re: [patch net-next v2 1/6] virtio: add debugfs infrastructure to
 allow to debug virtio features

Wed, Apr 17, 2024 at 06:37:30AM CEST, jasowang@...hat.com wrote:
>On Tue, Apr 16, 2024 at 5:37 PM Jiri Pirko <jiri@...nulli.us> wrote:
>>
>> Tue, Apr 16, 2024 at 05:52:41AM CEST, jasowang@...hat.com wrote:
>> >On Tue, Apr 16, 2024 at 12:25 AM Jiri Pirko <jiri@...nulli.us> wrote:
>> >>
>> >> From: Jiri Pirko <jiri@...dia.com>
>> >>
>> >> Currently there is no way for user to set what features the driver
>> >> should obey or not, it is hard wired in the code.
>> >>
>> >> In order to be able to debug the device behavior in case some feature is
>> >> disabled, introduce a debugfs infrastructure with couple of files
>> >> allowing user to see what features the device advertises and
>> >> to set filter for features used by driver.
>> >>
>> >> Example:
>> >> $cat /sys/bus/virtio/devices/virtio0/features
>> >> 1110010111111111111101010000110010000000100000000000000000000000
>> >> $ echo "5" >/sys/kernel/debug/virtio/virtio0/filter_feature_add
>> >> $ cat /sys/kernel/debug/virtio/virtio0/filter_features
>> >> 5
>> >> $ echo "virtio0" > /sys/bus/virtio/drivers/virtio_net/unbind
>> >> $ echo "virtio0" > /sys/bus/virtio/drivers/virtio_net/bind
>> >> $ cat /sys/bus/virtio/devices/virtio0/features
>> >> 1110000111111111111101010000110010000000100000000000000000000000
>> >>
>> >> Note that sysfs "features" know already exists, this patch does not
>> >> touch it.
>> >>
>> >> Signed-off-by: Jiri Pirko <jiri@...dia.com>
>> >> ---
>> >
>> >Note that this can be done already with vp_vdpa feature provisioning:
>> >
>> >commit c1ca352d371f724f7fb40f016abdb563aa85fe55
>> >Author: Jason Wang <jasowang@...hat.com>
>> >Date:   Tue Sep 27 15:48:10 2022 +0800
>> >
>> >    vp_vdpa: support feature provisioning
>> >
>> >For example:
>> >
>> >vdpa dev add name dev1 mgmtdev pci/0000:02:00.0 device_features 0x300020000
>>
>> Sure. My intension was to make the testing possible on any virtio
>> device.
>
>It did that actually, vp_vdpa bridge virtio-pci device into vDPA bus
>with mediation layer (like feature filtering etc). So it can only run
>on top of standard virtio-pci device.
>
>> Narrowing the testing for vpda would be limitting.
>
>Unless you want to use other transport like virtio-mmio.

Also, the goal is to test virtio_net emulated devices. There are couple
of implementation. Non-vdpa.


>
>Thanks
>
>>
>>
>> >
>> >Thanks
>> >
>>
>