Comment 6 for bug 1812822

We now need to find out what the difference is:
a) your test case is slightly different and you can trigger it on the same SW levels it works for me, then we need to report that to upstream as those are the very latest versions
b) your test is good once you use the more recent SW levels, in that case we need to drill down into your crash and identify the fix (that must be in between qemu 2.11 and 3.1 somewhere) to consider backporting it.
c) This would be arch dependent (I tested x86), but we would find that further down the road as you'd report (a) to happen. After all TUNSETVNETLE is for setting big/little endian operations for linux tap/macvtap so it could be s390x only after all.

I can't re-deploy the system to use Bionic level components that you use at the moment and that also would only answer (b) but not (a).
Therefore to differentiate between the above I'd want to ask you if you could re-run your test on Ubuntu 19.04 with Proposed enabled [1] as the new openvswitch still is in proposed for now.

Report back if you can still trigger the issue, but then I'll most likely encourage you to report it upstream and I'd then participate in the discussion there - probably building test PPAs for you as needed.

Also report back if this SW stack works for you as well, in that case I'd wonder if you get an actual crash in /var/crash that would help where in the qemu code we would look for
  TUNSETVNETLE ioctl() failed: File descriptor in bad state.
I'd assume net/tap-linux.c in tap_fd_set_vnet_le, but let's be sure.

[1]: https://wiki.ubuntu.com/Testing/EnableProposed