virtio — archive

[PATCH v10 00/10] Introduce device group and device management

From: Jiri Pirko <[email protected]>
To: [email protected]
Date: Wed, 08 Mar 2023 12:42:00 -0000

Wed, Mar 08, 2023 at 12:54:52PM CET, [email protected] wrote: >On Mon, Mar 06, 2023 at 01:22:30PM +0100, Jiri Pirko wrote: >> Thu, Mar 02, 2023 at 02:05:22PM CET, [email protected] wrote: >> >Add commands to find out which commands does each group support, >> >as well as enable their use by driver. >> >This will be especially useful once we have multiple group types. >> > >> >An alternative is per-type VQs. This is possible but will >> >require more per-transport work. Discovery through the vq >> >helps keep things contained. >> > >> >Signed-off-by: Max Gurtovoy <[email protected]> >> >Signed-off-by: Michael S. Tsirkin <[email protected]> >> >> [...] >> >> >> >+ >> >+The driver issues the command VIRTIO_ADMIN_CMD_LIST_QUERY to >> >+query the list of commands valid for this group and before sending >> >+any commands for any member of a group. >> >+ >> >+The driver then enables use of some of the opcodes by sending to >> >+the device the command VIRTIO_ADMIN_CMD_LIST_USE with a subset >> >+of the list returned by VIRTIO_ADMIN_CMD_LIST_QUERY that is >> >+both understood and used by the driver. >> >> To my untrained ear, this sounds somewhat similar to the feature >> negotiantion mechanism. Why the fact that device/driver supports some >> command can't be covered by just another feature? Looks like unnecassary >> complexicity to negotiate supported commands like this. > >Absolutely, it is similar. The issue is that a single device can >be an owner for multiple group types. >For example, I think an SRIOV PF itself can have subfunctions with SIOV >as well as virtual functions with SRIOV. >And the set of supported commands might differ. > >We thus need a command that is kind of like features but per group type. I see. But that does not mean it can't be done using existing features: _F_SRIOV_CMD1 _F_SRIOV_CMD2 .. _F_SIOV_CMD1 _F_SIOV_CMD2 ... > >As a small bonus as we are building this from scratch, I added >something which was requested for a long time from features >which is blocking access to commands not allowed by features. >With standard virtio features we trust the driver not to send >commands before enabling a feature and this was considered >a maintainance/security problem. I understand. Is it unfixable for features not to break buggy drivers? > > >-- >MST >