Re: regression: UFO removal breaks kvm live migration

On Wed, Nov 8, 2017 at 9:53 PM, Jason Wang [off-list ref] wrote:

On 2017年11月08日 20:32, David Miller wrote:

quoted

From: Jason Wang <redacted>
Date: Wed, 8 Nov 2017 17:25:48 +0900

quoted

On 2017年11月08日 17:08, Willem de Bruijn wrote:

quoted

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..

Yes, this looks hard. And even if we can manage to do this, it looks
an overkill since it will impact all guest after migration.

Like Willem I would much prefer "advertise-but-drop" if it works.

This makes migration work but all guest UFO traffic will stall.

quoted

In the long term feature renegotiation triggers are a must.

There is no way for us to remove features otherwise.

We can remove if we don't break userspace(guest).

quoted

In my opinion
this will even make migrations more powerful.

But this does not help for guest running old version of kernel which still
think UFO work.

Indeed, if we have to support live migration of arbitrary old guests
without any expectations on hypervisor version either, features can
simply never be reverted, even if a negotiation interface exists.

At least for upcoming features and devices, guest code should not
have this expectation, but from the start allow renegation such as
CTRL_GUEST_OFFLOADS [1] based on a host trigger. But for
tuntap TUNSETOFFLOAD it seems that ship has sailed.

Okay, I will send a patch to reinstate UFO for this use case (only). There
is some related work in tap_handle_frame and packet_direct_xmit to
segment directly in the device. I will be traveling the next few days, so
it won't be in time for 4.14 (but can go in stable later, of course).

[1] https://patchwork.kernel.org/patch/9850785/