the extra bytes. The PCB embeds the biggest static FPU state, but our
real FPU state may be smaller (FNSAVE), so we don't need to memcpy the
extra unused bytes.
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.
