Re: [virtio] Re: [virtio-comment] [PATCH v10 09/10] admin: conformance clauses

[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.