Yes, I happened to upgrade right at the release of 3.3 (great work, and thanks to the devs), but ran into this problem. I use pfSense and other FreeBSD VMs heavily and was dismayed to see idle VMs hit 10-15% of two allocated CPU cores.
For me, this only seems to affect FreeBSD version 8. Current pfSense 2.1.5 is based on FreeBSD 8.3 so it's affected. I have an 8.x VM that has this problem, and booting the 8.4 release ISO also shows it. I booted the 9.1, 9.3, 10.0, and 10.1-BETA release ISOs, and they seem to work just fine and do NOT show the problem. I only tried amd64; have no idea how i386 behaves.
Note that disabling the tablet pointer in the VM options tab seems to reduce CPU usage by a noticeable 2-3% regardless of FreeBSD version, so that's low hanging fruit to hit first.
After a lot of trial and error, it seems like we have to resort to some "old" tricks like setting kern.hz to 100 instead of the default 1000. I added the following in my /boot/loader.conf.local (in addition to the virtio lines) on one of my pfSense VMs and will run it for a while before upgrading other hosts to Proxmox 3.3.
Code:
hint.apic.0.clock=0
kern.hz=100
You can find some other options at the bottom of this well known thread. Up to you to test and see what works best.
https://communities.vmware.com/thread/87794
Note that changing the CPU type, number of cores, virtio vs. non-virtio devices, etc. didn't seem to have much effect for me. YMMV.
And finally, I don't mean this as a complaint, but as a general observation, that FBSD support on Proxmox/KVM has been a lot more fragile than I would like to see for production systems. I count at least three major problems in the last ~two years that have been addressed (or not) in varying amounts of time.
There was that SeaBIOS issue, which had a published workaround within a day, the Ivy Bridge/Haswell CPU issue, which AFAIK still requires using a non-default kernel (read a report that the 3.10 non-OpenVZ kernel fixes this?), and now this idle CPU regression.