pfSense

XN driver does not support ALTQ at all though it should not be hard to implement it.

xn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether be:f5:19:d5:81:bb
inet 172.26.0.1 netmask 0xffffff00 broadcast 172.26.0.255
inet6 fe80::bcf5:19ff:fed5:81bb%xn0 prefixlen 64 scopeid 0x5
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet manual
status: active

No altq, no vlans.

Is there a way to disable xen detection while booting?
I had to remove traffic shaping from my local pfsense and now we are unable to work properly.
If there is no quick solution I have to use bare metal.

I can not update our cloud servers, because each have a virtual pfsense and are chained in vlans.

If it's come with 2.2.2 I can wait.
But if not I think 100% update success is better than 80% faster running systems and 20% waste.

The most systems I use have traffic shaping because of VoIP and other time critical services (RDP, VNC, SQL, ...).

If I understand cmb right in his post pfsense shouldn't never use xn, because it's not xen which change things it's pfsense:
https://forum.pfsense.org/index.php?topic=84255.msg462150#msg462150

Where is the source code for the changes?

Removing this would not result in 100% upgrade success, it'd result in 100% of already upgraded and fixed systems breaking when upgrading 2.2 to 2.2.1, then 100% breaking again going from 2.2.1 to 2.2.2. That's unacceptable. The big warning in the upgrade guide is there for Xen users, who should have all noted that and changed things in the process.

My post in that linked thread (I'm cmb) is opposite what you said. It's Xen's stupid behavior of changing your NIC type out from under you without any ability to control what it's presenting the OS at the root of this issue.

The source in question that makes Xen do this is in stock FreeBSD 10.1. You can remove that from the kernel config and build your own kernel. That's in tools, details for reaching it here:
https://forum.pfsense.org/index.php?topic=76132.0

You make a really good job and if XN+ALTQ is working in 2.2.2 we'll never spoke about that.

It's never xen which changes the NIC. From first days on xen gives the DomU the ability to choose the right NIC and pfsense chooses the wrong one since 2.2.

It would be better not to integrate netfront until it supports ALTQ. But now it's integrated and to remove it and integrate it again with 2.2.2 is unnecessary.
Perhaps for good will you can create an unofficial release without netfront. If you have an early 2.2.2 for testing ALTQ I would test it.

2.2.4 running, still no ALTQ...
I don't see any traffic on freebsd-xen@freebsd.org about xn, so it appears that we can't expect it to be fixed in some near or mid future.

I've been told that there has been posted a patch that will give us the switch we need:

https://svnweb.freebsd.org/base?view=revision&revision=286999
xen: allow disabling PV disks and nics

I'd love this to be included in the next 2.2.5 release.