Meanwhile, domUs have plenty of other shared-memory protocols with dom0 kernel and root processes. It just needs some care to make sure the interface is sufficiently narrow and arguments are well checked. Burning 100% CPU is not considered a successful attack (although it would of course be annoying!). You can detect it and fix it up without rebooting the system, for example.
Indeed, that one is very easy to guard against in the code, too. Simply making the iopage handler loop on <= instead of != would do it, although it's probably better to just insert a sanity before entering the loop, and printing a warning to the log that the iopage may have been corrupted if bad values are detected.
In any case, the current "qemu-dm in dom0" device model is unlikely to live forever. Both the two future alternatives I've seen discussed - the stub domain and the "reflection" one suggested earlier this month - would do away with any concerns I have. With the "reflection" model, the device emulation would actually run inside the HVM, in which case the io pages should certainly be owned by the domU, and in the stub domain case, I suppose it wouldn't matter as much whether the domU or the stub domain owned the pages in any case.
All your other patches are in except the smsw one.
I'm looking at that now.
I apologize to your eyes, and hope it won't ruin your weekend. ;)
That one shouldn't go in in its current state, at least.