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
