On Wed, Mar 22 2023, Parav Pandit <[email protected]> wrote: >> From: Cornelia Huck <[email protected]> >> Sent: Wednesday, March 22, 2023 12:37 PM >> >> On Wed, Mar 22 2023, Parav Pandit <[email protected]> wrote: >> >> >> From: Cornelia Huck <[email protected]> >> >> Sent: Wednesday, March 22, 2023 11:21 AM >> >> >> >> On Wed, Mar 22 2023, Heng Qi <[email protected]> wrote: >> >> >> >> > +The driver MUST NOT set \field{vqn} to any value other than an >> >> > +enabled >> >> transmit or receive virtqueue number. >> >> >> > Why do you suggest a negative statement here? >> > How is it better than, >> > The driver MUST set ... >> >> So make it >> >> "The driver MUST set \field{vqn} to the virtqueue number of an enabled >> transmit or receive virtqueue." ? >> > Looks good. > >> > The device will anyway have to check and apply the parameter to the right >> virtqueue. >> > And if the vq is not enabled or vq is not tx or rx vq, it needs to fail the >> command. >> >> Well, I think we want to avoid having to add a normative statement for the >> device, so we need to be strict with what the driver is allowed to do. > Drivers are untrusted entities. > device normative statement is needed, it will do the checks anyway where it > is applying the config.
But isn't that implementation specific? I.e. if the driver sends junk, the device needs to be able to deal with it in any case. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
