[virtio-dev] Re: [virtio-comment] RE: [PATCH v13] virtio-net: support the virtqueue coalescing moderation

[Cornelia Huck <cohuck@redhat.com>]

On Wed, Mar 22 2023, Parav Pandit <parav@nvidia.com> wrote:

>> From: Cornelia Huck <cohuck@redhat.com>
>> Sent: Wednesday, March 22, 2023 12:37 PM
>> 
>> On Wed, Mar 22 2023, Parav Pandit <parav@nvidia.com> wrote:
>> 
>> >> From: Cornelia Huck <cohuck@redhat.com>
>> >> Sent: Wednesday, March 22, 2023 11:21 AM
>> >>
>> >> On Wed, Mar 22 2023, Heng Qi <hengqi@linux.alibaba.com> 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: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org