About the rtc, no no idea. But to deal with the problem, aside from
major NetBSD code rewrites (the so called tickless kernel) the one
solution that should work is to run the host with HZ set a lot higher,
and leave the guest(s) at 100Hz.
For any modern host (anything you'd really want to use to run a qemu
guest in production) running with HZ=1000 will be fine (you'll never
notice the tiny extra overhead). Some of the NetBSD ports already
run at that kind of rate - alpha has been at 1024Hz forever (and these
days, alphas are slow processors - though they weren't compared to
others when that change was made). With this, the 10ms interrupts might
actually occur about 10.1 ms apart, but that much drift NTP should be
able to handle. If not, run the host with an even higher HZ rate,
even 10000 should work with a modern amd64 CPU (though I have never
tested that, nor heard of anyone who has - but 2000 should not be an issue).
If for some reason you cannot change the clock rate of the host (that is,
compile a new kernel with "options HZ=1000" in the config file) then make the
guests run with a much slower clock rate - nothing faster than 50Hz.
That should be acceptable (pdp-11's used to run at 50 or 60hz, and worked
OK) but needs to be even slower for clock drift issues. The problem
is that if the OS clock rate is too slow, it will start to impact upon
(perceived) performance, and some application capabilities.