Linux Virtualization - Jan 2020 - [PATCH v2] virtio_net: CTRL_GUEST_OFFLOADS depends on CTRL_VQ

On Mon, Jan 06, 2020 at 10:47:35AM +0800, Jason Wang
wrote:
> 
> On 2020/1/5 ??9:22, Michael S. Tsirkin wrote:
> > The only way for guest to control offloads (as enabled by
> > VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) is by sending commands
> > through CTRL_VQ. So it does not make sense to
> > acknowledge VIRTIO_NET_F_CTRL_GUEST_OFFLOADS without
> > VIRTIO_NET_F_CTRL_VQ.
> > 
> > The spec does not outlaw devices with such a configuration, so we have
> > to support it. Simply clear VIRTIO_NET_F_CTRL_GUEST_OFFLOADS.
> > Note that Linux is still crashing if it tries to
> > change the offloads when there's no control vq.
> > That needs to be fixed by another patch.
> > 
> > Reported-by: Alistair Delva <adelva at google.com>
> > Reported-by: Willem de Bruijn <willemdebruijn.kernel at
gmail.com>
> > Fixes: 3f93522ffab2 ("virtio-net: switch off offloads on demand
if possible on XDP set")
> > Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
> > ---
> > 
> > Same patch as v1 but update documentation so it's clear it's
not
> > enough to fix the crash.
> > 
> >   drivers/net/virtio_net.c | 9 +++++++++
> >   1 file changed, 9 insertions(+)
> > 
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 4d7d5434cc5d..7b8805b47f0d 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -2971,6 +2971,15 @@ static int virtnet_validate(struct
virtio_device *vdev)
> >   	if (!virtnet_validate_features(vdev))
> >   		return -EINVAL;
> > +	/* VIRTIO_NET_F_CTRL_GUEST_OFFLOADS does not work without
> > +	 * VIRTIO_NET_F_CTRL_VQ. Unfortunately spec forgot to
> > +	 * specify that VIRTIO_NET_F_CTRL_GUEST_OFFLOADS depends
> > +	 * on VIRTIO_NET_F_CTRL_VQ so devices can set the later but
> > +	 * not the former.
> > +	 */
> > +	if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
> > +			__virtio_clear_bit(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS);
> 
> 
> If it's just because a bug of spec, should we simply fix the bug and
fail
> the negotiation in virtnet_validate_feature()?
One man's bug is another man's feature: arguably leaving the features
independent in the spec might allow reuse of the feature bit without
breaking guests.

And even if we say it's a bug we can't simply fix the bug in the
spec: changing the text for a future version does not change the fact
that devices behaving according to the spec exist.
> Otherwise there would be inconsistency in handling feature dependencies for
> ctrl vq.
> 
> Thanks
That's a cosmetic problem ATM. It might be a good idea to generally
change our handling of dependencies, and clear feature bits instead of
failing probe on a mismatch. It's worth thinking  - at the spec level -
how we can best make the configuration extensible.
But that's not something spec should worry about.

> 
> > +
> >   	if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
> >   		int mtu = virtio_cread16(vdev,
> >   					 offsetof(struct virtio_net_config,

On 2020/1/6 ??8:54, Michael S. Tsirkin wrote:
> On Mon, Jan 06, 2020 at 10:47:35AM +0800, Jason Wang wrote:
>> On 2020/1/5 ??9:22, Michael S. Tsirkin wrote:
>>> The only way for guest to control offloads (as enabled by
>>> VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) is by sending commands
>>> through CTRL_VQ. So it does not make sense to
>>> acknowledge VIRTIO_NET_F_CTRL_GUEST_OFFLOADS without
>>> VIRTIO_NET_F_CTRL_VQ.
>>>
>>> The spec does not outlaw devices with such a configuration, so we
have
>>> to support it. Simply clear VIRTIO_NET_F_CTRL_GUEST_OFFLOADS.
>>> Note that Linux is still crashing if it tries to
>>> change the offloads when there's no control vq.
>>> That needs to be fixed by another patch.
>>>
>>> Reported-by: Alistair Delva <adelva at google.com>
>>> Reported-by: Willem de Bruijn <willemdebruijn.kernel at
gmail.com>
>>> Fixes: 3f93522ffab2 ("virtio-net: switch off offloads on
demand if possible on XDP set")
>>> Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
>>> ---
>>>
>>> Same patch as v1 but update documentation so it's clear
it's not
>>> enough to fix the crash.
>>>
>>>    drivers/net/virtio_net.c | 9 +++++++++
>>>    1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>> index 4d7d5434cc5d..7b8805b47f0d 100644
>>> --- a/drivers/net/virtio_net.c
>>> +++ b/drivers/net/virtio_net.c
>>> @@ -2971,6 +2971,15 @@ static int virtnet_validate(struct
virtio_device *vdev)
>>>    	if (!virtnet_validate_features(vdev))
>>>    		return -EINVAL;
>>> +	/* VIRTIO_NET_F_CTRL_GUEST_OFFLOADS does not work without
>>> +	 * VIRTIO_NET_F_CTRL_VQ. Unfortunately spec forgot to
>>> +	 * specify that VIRTIO_NET_F_CTRL_GUEST_OFFLOADS depends
>>> +	 * on VIRTIO_NET_F_CTRL_VQ so devices can set the later but
>>> +	 * not the former.
>>> +	 */
>>> +	if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
>>> +			__virtio_clear_bit(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS);
>>
>> If it's just because a bug of spec, should we simply fix the bug
and fail
>> the negotiation in virtnet_validate_feature()?
> One man's bug is another man's feature: arguably leaving the
features
> independent in the spec might allow reuse of the feature bit without
> breaking guests.
>
> And even if we say it's a bug we can't simply fix the bug in the
> spec: changing the text for a future version does not change the fact
> that devices behaving according to the spec exist.
>
>> Otherwise there would be inconsistency in handling feature dependencies
for
>> ctrl vq.
>>
>> Thanks
> That's a cosmetic problem ATM. It might be a good idea to generally
> change our handling of dependencies, and clear feature bits instead of
> failing probe on a mismatch.

Something like I proposed in the past ? [1]

[1] https://lore.kernel.org/patchwork/patch/519074/

>   It's worth thinking  - at the spec level -
> how we can best make the configuration extensible.
> But that's not something spec should worry about.
>
>
>>> +
>>>    	if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
>>>    		int mtu = virtio_cread16(vdev,
>>>    					 offsetof(struct virtio_net_config,

On Tue, Jan 07, 2020 at 10:29:08AM +0800, Jason Wang
wrote:
> 
> On 2020/1/6 ??8:54, Michael S. Tsirkin wrote:
> > On Mon, Jan 06, 2020 at 10:47:35AM +0800, Jason Wang wrote:
> > > On 2020/1/5 ??9:22, Michael S. Tsirkin wrote:
> > > > The only way for guest to control offloads (as enabled by
> > > > VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) is by sending commands
> > > > through CTRL_VQ. So it does not make sense to
> > > > acknowledge VIRTIO_NET_F_CTRL_GUEST_OFFLOADS without
> > > > VIRTIO_NET_F_CTRL_VQ.
> > > > 
> > > > The spec does not outlaw devices with such a configuration,
so we have
> > > > to support it. Simply clear
VIRTIO_NET_F_CTRL_GUEST_OFFLOADS.
> > > > Note that Linux is still crashing if it tries to
> > > > change the offloads when there's no control vq.
> > > > That needs to be fixed by another patch.
> > > > 
> > > > Reported-by: Alistair Delva <adelva at google.com>
> > > > Reported-by: Willem de Bruijn <willemdebruijn.kernel at
gmail.com>
> > > > Fixes: 3f93522ffab2 ("virtio-net: switch off offloads
on demand if possible on XDP set")
> > > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
> > > > ---
> > > > 
> > > > Same patch as v1 but update documentation so it's clear
it's not
> > > > enough to fix the crash.
> > > > 
> > > >    drivers/net/virtio_net.c | 9 +++++++++
> > > >    1 file changed, 9 insertions(+)
> > > > 
> > > > diff --git a/drivers/net/virtio_net.c
b/drivers/net/virtio_net.c
> > > > index 4d7d5434cc5d..7b8805b47f0d 100644
> > > > --- a/drivers/net/virtio_net.c
> > > > +++ b/drivers/net/virtio_net.c
> > > > @@ -2971,6 +2971,15 @@ static int virtnet_validate(struct
virtio_device *vdev)
> > > >    	if (!virtnet_validate_features(vdev))
> > > >    		return -EINVAL;
> > > > +	/* VIRTIO_NET_F_CTRL_GUEST_OFFLOADS does not work without
> > > > +	 * VIRTIO_NET_F_CTRL_VQ. Unfortunately spec forgot to
> > > > +	 * specify that VIRTIO_NET_F_CTRL_GUEST_OFFLOADS depends
> > > > +	 * on VIRTIO_NET_F_CTRL_VQ so devices can set the later
but
> > > > +	 * not the former.
> > > > +	 */
> > > > +	if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
> > > > +			__virtio_clear_bit(vdev,
VIRTIO_NET_F_CTRL_GUEST_OFFLOADS);
> > > 
> > > If it's just because a bug of spec, should we simply fix the
bug and fail
> > > the negotiation in virtnet_validate_feature()?
> > One man's bug is another man's feature: arguably leaving the
features
> > independent in the spec might allow reuse of the feature bit without
> > breaking guests.
> > 
> > And even if we say it's a bug we can't simply fix the bug in
the
> > spec: changing the text for a future version does not change the fact
> > that devices behaving according to the spec exist.
> > 
> > > Otherwise there would be inconsistency in handling feature
dependencies for
> > > ctrl vq.
> > > 
> > > Thanks
> > That's a cosmetic problem ATM. It might be a good idea to
generally
> > change our handling of dependencies, and clear feature bits instead of
> > failing probe on a mismatch.
> 
> 
> Something like I proposed in the past ? [1]
> 
> [1] https://lore.kernel.org/patchwork/patch/519074/

No that still fails probe.

I am asking whether it's more future proof to fail probe
on feature combinations disallowed by spec, or to clear bits
to get to an expected combination.

In any case, we should probably document in the spec how
drivers behave on such combinations.

> 
> >   It's worth thinking  - at the spec level -
> > how we can best make the configuration extensible.
> > But that's not something spec should worry about.
> > 
> > 
> > > > +
> > > >    	if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
> > > >    		int mtu = virtio_cread16(vdev,
> > > >    					 offsetof(struct virtio_net_config,