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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Mar 22, 2023 at 05:44:27PM +0100, Cornelia Huck wrote:
> 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.

I agree with Cornelia here. Yes if devices do not want to trust drivers
then they will validate input but what exactly happens then is
currently up to device.
If we want to try and specify devices in all cases of out of spec
input that's a big project, certainly doable but I would rather
not connect it to this, rather boutique, feature.


-- 
MST