Re: [PATCH v8 8/9] admin: command list discovery

[Cornelia Huck <cohuck@redhat.com>]

On Wed, Nov 23 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Wed, Nov 23, 2022 at 11:09:26AM +0100, Cornelia Huck wrote:
>> On Wed, Nov 23 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> 
>> > On Wed, Nov 23, 2022 at 10:51:31AM +0100, Cornelia Huck wrote:
>> >> On Tue, Nov 22 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> 
>> >> > On Tue, Nov 22, 2022 at 04:25:23PM +0100, Cornelia Huck wrote:
>> >> >> On Sun, Nov 20 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> >> > +When \field{status} is VIRTIO_ADMIN_STATUS_EINVAL,
>> >> >> > +the following table describes possible \field{status_qialifier} values:
>> >> >> > +\begin{tabular}{|l|l|l|}
>> >> >> > +\hline
>> >> >> > +Status & Name & Description \\
>> >> >> > +\hline \hline
>> >> >> > +00h   & VIRTIO_ADMIN_STATUS_Q_INVALID_COMMAND   & command error: no additional information  \\
>> >> >> 
>> >> >> Either 0x00, or decimal (which one is better?)
>> >> >
>> >> > I think I prefer 0x here. And maybe I will add status values in both hex
>> >> > and decimal (I used decimal to be consistent with linux headers but
>> >> > fundamentally what we use most of the time is hex).
>> >> 
>> >> Ok.
>> >> 
>> >> >
>> >> >> > +\hline
>> >> >> > +01h   & VIRTIO_ADMIN_STATUS_Q_INVALID_OPCODE    & unsupported or invalid \field{opcode}  \\
>> >> >> > +\hline
>> >> >> > +02h   & VIRTIO_ADMIN_STATUS_Q_INVALID_FIELD    & unsupported or invalid field within \field{command_specific_data}  \\
>> >> >> > +\hline
>> >> >> > +03h   & VIRTIO_ADMIN_STATUS_Q_INVALID_GROUP    & unsupported or invalid \field{group_type} was set  \\
>> >> >> 
>> >> >> s/was set//
>> >> >> 
>> >> >> > +\hline
>> >> >> > +04h   & VIRTIO_ADMIN_STATUS_Q_INVALID_MEM    & unsupported or invalid \field{group_member_id} was set  \\
>> >> >> 
>> >> >> s/was set//
>> >> >> 
>> >> >> > +\hline
>> >> >> > +other   & -    & group administration command error  \\
>> >> >> 
>> >> >> Again the question whether this is something that can be defined per
>> >> >> group type.
>> >> >
>> >> > probably - above ones are generic, let's see if we need specific ones.
>> >> > if yes will be easy to add.
>> >> 
>> >> I think we want to distinguish between "reserved" (not defined yet, may
>> >> get a meaning later on) and "group type specific" (a group type may use
>> >> it, don't reuse for generic stuff). If we need group type specific
>> >> errors (and don't want a free-for-all), we could go with eg.
>> >> 
>> >> 0x05 & VIRTIO_ADMIN_STATUS_Q_GROUP_ERR_0 & group type specific error \\
>> >> 
>> >> or so? Do we see any need for that yet?
>> >
>> > Not yet.
>> 
>> Then maybe let's make the last line
>> 
>> 0x05 - & - & reserved for future use \\
>> 
>> ?
>
> Hmm 5 is reserved but anything else is a generic error. I'm not sure
> what the difference is. Could you clarify? E.g. how will driver handle
> such an error if it gets it? Is it an error to get a reserved error
> value?

Oh, I meant 0x05 - ... (i.e. 0x05 or higher)

Getting a reserved error code basically means that either (a) the device
implements a newer version of the standard, or (b) the device is buggy
and doesn't conform to the standard. It's probably best to handle that
the same as error 0x00 (no additional information.)