In the original clockintr(9) proposal, Scott mentioned allowing
timeout(9) to steer the clock interrupt so userspace could block
for less than one tick, specifically noting vmm/vmd timing
problems.

Is that still the intended direction for timeout(9), or was there
a technical problem with that design that prevented it from being
implemented?

I am debugging the i8253 emulation in -current and found that vmd
guests that programs PIT channel 0 for deadlines between roughly
0.1 and 10ms receives IRQ0 around 17-20ms later.

Diagnostics from 9front show, for example:

	- requested PIT divisor avg: 2743 (~2.3ms)
	- maximum requested:         11927 (10.0ms)
	- actual IRQ0 average:       17.44ms
	- 80% of IRQs:               >18ms

The path appears to be:
	kevent_timeout
	  ->msleep_nsec
	  ->timeout_add_nsec
	  ->hardclock/tick resolution

I would like to work on fixing this, but before writing a diff, I
want to know whether making clock-based timeouts steer clockintr
is still the preferred architecture, and whether there are issues
that stopped the earlier work.