On Wed, Nov 23, 2022 at 11:09:26AM +0100, Cornelia Huck wrote:
> On Wed, Nov 23 2022, "Michael S. Tsirkin" <m...@redhat.com> wrote:
> 
> > On Wed, Nov 23, 2022 at 10:51:31AM +0100, Cornelia Huck wrote:
> >> On Tue, Nov 22 2022, "Michael S. Tsirkin" <m...@redhat.com> wrote:
> >> 
> >> > On Tue, Nov 22, 2022 at 04:25:23PM +0100, Cornelia Huck wrote:
> >> >> On Sun, Nov 20 2022, "Michael S. Tsirkin" <m...@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?

-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org

Reply via email to