Re: pvclock (kvm_clock) support: where to attach

[Emile 'iMil' Heitor <imil%home.imil.net@localhost>]

On 12/31/23 15:17, Taylor R Campbell wrote:
> https://nxr.netbsd.org/xref/src/sys/arch/xen/xen/xen_clock.c

oh.

> Unless there's a compelling reason that the pvclock and xenclock
> interfaces are different enough to warrant having multiple copies of
> the logic in src, I think we should adapt the existing code to work in
> both settings.  I put a lot of work into the xen_clock.c driver to
> record useful diagnostics about when the host's time is not behaving
> right (vs when NetBSD itself has done something wrong), which we've
> seen in practice on various hosts, and it would be a shame to lose
> that.

Ok, the point is to have an interface that is able to expose
kvm_clock, which is used by Firecracker, I guess this could be
added without much pain into this existing Xen code.

> If not, I think long-term we should introduce a new sys/dev/pv or
> something, move the bulk of xen_clock.c to that (other than the
> Xen-specific parts), and have both the Firecracker code and the Xen
> code use it.

Actually that's what OpenBSD does, they do have a sys/dev/pv with a
pvbus and it's honestly a classy way of dealing with various
hypervisors.

On a side note:

I'm not used to this clock/rtc mechanisms, but something puzzles me,
when the virtual machine is started without MC146818 RTC support, it
hangs at todr_gettime_ymdhms, which is mapped to rtc_get_ymdhms in
sys/arch/x86/isa/rtc.c, which at the end of the day calls
mc146818_read(). Shouldn't sys/arch/x86/isa/clock.c:startrtclock()
return when mc146818_read() fails? There seem to have nothing but
MC146818 for RTC in x86.

--
------------------------------------------------------------------------
Emile `iMil' Heitor <imil@{home.imil.net,NetBSD.org}> | https://imil.net