We're putting together a front/backend ring (rndfront/rndback) that will proxy entropy from dom0 directly into the guest. It'll take some time for this to percolate into the public cloud, so we'll need to do what Linux does in the meanwhile (harvest entropy from interrupt timings, attempt RDRAND, and so on).
On the other hand, I disagree that we're reinventing an ABI given that:
1) virtio isn't the supported PV interface in Xen -- rndfront/back follows the same design principles as net/blk/fb/usb/pci/console etc.
2) The Xen shared-ring interface is older than virtio, and much simpler for pure PV guests such as Mirage (no PCI emulation to worry about). I do wonder what happened to that GSoC project from a few years to add virtio support to Xen though...I don't think any patches ever appeared.
For HVM guests I hope that virtio-rng would work as-is (if it could be turned on via the control path). That's definitely worth a look.
For PV guests like Mirage I'm currently plumbing through a Xen PV analogue of virtio-serial by hijacking^Wextending the existing PV console support. Since the backend for that is in qemu already it might be possible to hook up the entropy source (with all the rate limiting etc). I think the trick would be to get the guest to recognise the frontend for what it is -- I imagine the virtio-rng device in the guest presents itself as a magic hardware PCI device and 'just works'.
The ENTROPY module type supports this sort of callback in 1.2.0: https://github.com/mirage/mirage/blob/master/types/V1.mli#L7...
(If you're interested in contributing, the entropy harvesting is in sore need of more eyes and help!)