This just moves the timer-arming logic from xen_initclocks into
xen_resumeclocks so that it runs on resume too.
I hypothesize that this is necessary for Xen to resume. Otherwise,
how could the one-shot timer possibly by rearmed? On the other hand,
it is conceivable that something automatically rearms it.
This also reorders the initialization so that we establish a timer
interrupt handler first, and _then_ arm the timer. If the order
matters, it is hard to imagine that the other way is correct:
conceivably, the interrupt could arrive before we've established the
handler, and then there's nothing to rearm it.
Whether this is _sufficient_ for Xen to resume, I don't know.
Symptoms recently reported in
<https://mail-index.netbsd.org/port-xen/2018/06/15/msg009207.html>
look different from how I would expect this to manifest, which is as
a system wedged because there's no no hardclock activity.
ok cherry
Compile-tested only -- kernel still runs but I haven't exercised this
code path.
By code inspection, this change or something like it is obviously
_necessary_ for Xen MP suspend/resume -- otherwise there's no logic
to suspend/resume the clocks on any CPU except the one that actually
triggers sysctl -w machdep.xen.suspend=1.
Whether this change is _sufficient_ for Xen MP suspend/resume to
work, I don't know.
ok cherry
instead of just the current pass. Fixes an issue where a driver with a
lower match number and early pass number will attach instead of a better
match on a later pass.
With this change, the Xen timecounter should now be globally
monotonic, as every timecounter is supposed to be. Should also fix a
litany of races in the timecounter logic.
Proposed last year; see mailing list for further details:
https://mail-index.netbsd.org/port-xen/2017/10/31/msg009112.html
ok cherry
pinned.
Because if it is, the fpu state of the lwp we are context-switching to
is already installed on the current cpu, so no point re-installing it.
Or, it isn't, and in this case we don't want to install it.
This wrong re-installation can occur when we leave a softint.
It may fix bugs in places that call fpusave_lwp with spl != IPL_HIGH,
and that expect the fpu state to stay in memory. As far as I can tell
only cpu_lwp_free meets these conditions, and as far as I can tell
again, there it's harmless.
Should help PR/53399.
tables into common header files shared by both drivers.
- Fix some register and bit definitions, from OpenBSD and verified against
the vendor driver.
- Add some additional register / descriptor defnitions, from OpenBSD.
