virtio — archive

[Michael S. Tsirkin <david.edmondson@oracle.com>]

On Wed, Mar 08, 2023 at 02:05:01PM +0100, Jiri Pirko wrote: > 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. > > > >LIST_QUERY. What's the purpose of this? > > I think that this might be just for the sake of treating all > commands equally. > Right. There was this vague idea that blocking all commands is good to have. E.g. if you are making some drastic changes to the device? > >-- > >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 > >