Sorry, this is completely wrong FUD. Paolo Bonzini and I work at Red Hat and there is constant review of the QEMU codebase, both for code quality and security issues. Furthermore devices in RHEL are whitelisted. TCG ("cross-platform emulation") is not involved at all when you're using KVM. A newly written emulator would just have a new set of vulnerabilities. When you don't know what you're talking about, please just don't.
I'm glad to hear that! When did you implement fuzzing coverage? After the 2016 Qemu mailing list article I read where they're asking someone to look into applying to Google's oss fuzzing project? And how does your whitelisted set compare to Xen's stripped-down qemu support?
I'm actually fuzzing qemu's block device layer as we speak.
From the latest run:
│ run time : 11 days, 23 hrs, 12 min, 49 sec │ cycles done : 0 │
│ last new path : 0 days, 12 hrs, 55 min, 7 sec │ total paths : 364 │
│ last uniq crash : none seen yet │ uniq crashes : 0 │
│ last uniq hang : 0 days, 4 hrs, 4 min, 36 sec │ uniq hangs : 2 │
Xen uses a stripped-down QEMU to boot unpatched guest OSes. However, even Xen doesn't test its qemu-xen components extensively. Writing a new purpose-built emulator (assuming you know what you're doing) is a better idea.
edit: Or use PV guests, and skip all potential QEMU flaws.