virtio — archive

[David Edmondson <david.edmondson@oracle.com>]

Jiri Pirko <jiri@nvidia.com> writes: > Wed, Mar 08, 2023 at 01:59:10PM CET, david.edmondson@oracle.com wrote: >>"Michael S. Tsirkin" <mst@redhat.com> writes: >> >>> On Tue, Mar 07, 2023 at 11:04:33AM +0000, David Edmondson wrote: >>>> "Michael S. Tsirkin" <mst@redhat.com> writes: >>>> > +The driver MAY block use of VIRTIO_ADMIN_CMD_LIST_QUERY and >>>> > +VIRTIO_ADMIN_CMD_LIST_USE by issuing VIRTIO_ADMIN_CMD_LIST_USE >>>> > +with respective bits cleared in \field{command_specific_data}. >>>> >>>> This runs contrary to the assertion "The list of supported commands MUST >>>> NOT shrink", given that a driver is told to assume that >>>> VIRTIO_ADMIN_CMD_LIST_QUERY and VIRTIO_ADMIN_CMD_LIST_USE are the only >>>> commands initially available. >>> >>> Commands are still available just disabled, the meaning of >>> "MUST NOT shrink" is clarified by the following: >>> >>> > > +after reporting a given command as supported through >>> > > +VIRTIO_ADMIN_CMD_LIST_QUERY the device MUST NOT later report it >>> > > +as unsupported. >>> I will stick an "i.e." there to make it hopefully clearer. >> >>This puzzles me. >> >>I can see the point of blocking LIST_USE, but not of blocking > > What is that point, I'm curious. I might restrict the commands permitted by a device before handing it off to some subordinate less trusted code. > >>LIST_QUERY. What's the purpose of this? > > I think that this might be just for the sake of treating all > commands equally. > > >>-- >>Time is waiting to explain, why refuse? >> >> --------------------------------------------------------------------- >>To unsubscribe from this mail list, you must leave the OASIS TC that >>generates this mail. Follow this link to all your TCs in OASIS at: >>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> -- I used to get mad at my school, the teachers who taught me weren't cool.