Re: regression: UFO removal breaks kvm live migration

From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jason Wang <jasowang@redhat.com>
Cc: David Miller <davem@davemloft.net>,
	Michal Kubecek <mkubecek@suse.cz>,
	Network Development <netdev@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Vlad Yasevic <vyasevic@redhat.com>
Subject: Re: regression: UFO removal breaks kvm live migration
Date: Wed, 8 Nov 2017 17:08:35 +0900	[thread overview]
Message-ID: <CAF=yD-J9OZJDk_j6XmU7vUqR3UBiKC6U51kF0PJfPkgtXs9SiA@mail.gmail.com> (raw)
In-Reply-To: <dc9af6e2-a886-3fc6-8f34-70d87a7a0d01@redhat.com>

On Wed, Nov 8, 2017 at 4:49 PM, Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2017年11月08日 15:26, David Miller wrote:
>>
>> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
>> Date: Wed, 8 Nov 2017 12:36:26 +0900
>>
>>> On Tue, Nov 7, 2017 at 5:02 PM, Michal Kubecek <mkubecek@suse.cz> wrote:
>>>>
>>>> I didn't have time to think it through yet but perhaps we could allow
>>>> setting TUN_F_UFO and ignore its value.
>>>
>>> If the feature is enabled guests may try to send UFO packets, which
>>> the host is no longer able to fragment.
>>>
>>> virtio_net_hdr_to_skb will drop the packets immediately based on
>>> gso_type and tun_get_user will return EINVAL.
>>>
>>> Still, perhaps that's preferable as migration will succeed and most
>>> guests won't ever try to send those packets in the first place.
>>
>> However, this would create the situation where there is no way
>> to properly probe for the actual presence of UFO support.
>
>
> I think we should not have any assumption on how guest will use the feature.
> So I could not come a better than bring it back partially for TAP, looks
> like we only need segment them in tun_get_user().

Live migration essentially expects that features can never be removed [1],
as feature bits are not renegotiated after migration. In the short term we'll
have to work around that, but in the long term that does not seem practical.

There already exist interfaces to renegotiate guest/host state at runtime,
including for offloads [2][3]. For newer guests, we should support a trigger
from the host to renegotiate offloads.

That won't help in the short term. I'm still reading up to see if there are
any other options besides reimplement or advertise-but-drop, such as
an implicit trigger that would make the guest renegotiate. It's unlikely, but
worth a look..

[1] https://lists.linuxfoundation.org/pipermail/virtualization/2014-November/028126.html
[2] https://lists.linuxfoundation.org/pipermail/virtualization/2013-April/023818.html
[3] https://patchwork.kernel.org/patch/9850785/