Any updates on this? This version is working great for me.

In D55538#1281960, @royger wrote:

Attempt to fix the QEMU segfault.

In D55538#1281533, @royger wrote:

Can you paste the contents of /var/log/xen/qemu-<domain name>.log?

Another test on FreeBSD 15-RELENG:

FreeBSD xen1.my.domain 15.0-STABLE FreeBSD 15.0-STABLE stable/15-45b0c46d1c0b GENERIC amd64

It seems the information of distinfo for emulator/xen-kernel needs to be updated again:

===>   xen-kernel-4.21.0.20260212 depends on file: /usr/local/sbin/pkg - found
=> xen/4.21.0.20260212/xen-project-xen-afaf4e7b503ad3e79602b39064e58d6488d10f3d_GL0.tar.gz is not in /usr/ports/emulators/xen-kernel/distinfo.
=> Either /usr/ports/emulators/xen-kernel/distinfo is out of date, or
=> xen/4.21.0.20260212/xen-project-xen-afaf4e7b503ad3e79602b39064e58d6488d10f3d_GL0.tar.gz is spelled incorrectly.
*** Error code 1

In D51631#1195661, @dsl wrote:

Updated to 0.1.4

Some porters don't mind support (e.g. https://gitlab.fechner.net/mfechner/Gitlab-docu/blob/master/install/16.10-freebsd.md#support-me ). However, we won't know how good these changes are without hands-on experimentation.

The patch works like a charm! This fixes the case I described here (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235556#c2), the stats are now correct: https://www.bsdstore.ru/trash/racct.png
Tested on: FreeBSD 14.0-CURRENT #0 main-n247127-1976e079544-dirty

In D26209#656625, @khng wrote:

In D26209#633596, @c.koehne_beckhoff.com wrote:

• fix compiling

Broken for FreeBSD 13.0-ALPHA2:

--- all_subdir_usr.sbin ---
        uint64_t cpu_maxphysaddr, pci_emul_memresv64;
                                  ^
/usr/jails/src/src_13/src/usr.sbin/bhyve/pci_emul.c:1256:8: error: unused variable 'regs' [-Werror,-Wunused-variable]
        u_int regs[4];
              ^
/usr/jails/src/src_13/src/usr.sbin/bhyve/pci_emul.c:1255:11: error: unused variable 'cpu_maxphysaddr' [-Werror,-Wunused-variable]
        uint64_t cpu_maxphysaddr, pci_emul_memresv64;
                 ^
3 errors generated.

Hi, Checked the vether module for a month under high load ( 13-CURRENT ). I can say that at present this is the only stable way to interact with traffic inside the VALE switch from the host system. if_epair is extremely unstable. It would be very helpful to see the movement of this work.

@novel I checked this patch on my system and it looks good for me.

Probably a good idea to make it tunable and also, it would be nice if the system checks the amount of firmware and noticed message about limit exceed, instead of 'Invalid argument'