extend the uint64_t's when building it, so we're leaking 48 bits of kernel
stack to userland.
Having said that, it appears that I unintentionally fixed most of this
issue in locore.S::rev1.127 - by building the frame with interrupts
disabled, we are implicitly guaranteeing that the structure doesn't get
overwritten by the kernel. Which means, we are leaking to userland data
that comes from userland anyway.
(still other places with this issue, but I'll fix them differently)
confusion in the code - in part introduced by myself -, and clearly this
place is not supposed to handle 32bit LWPs.
Right now we're returning EINVAL, but verily we would need to redirect
these calls to their netbsd32 counterparts.
code duplication, and reducing the size of /bin/sh by a trivial amount.
NFCI.
This is being done now as there are two other changes forthcoming, both
of which benefit - one would result in even more code duplication without
this, the other might need to alter how this is done, and doing it after this
means there's just one place to change (if required).
- when disabling an interrupt, disable it on the HT PIC as well
- when establishing an interrupt, don't enable it right away
- program IRQs 0-3 as level, like freebsd does
Now svwsata is almost usable. We still get an interrupt storm but it doesn't
eat up all CPU cycles anymore.
actually work (but just happen to, today, and in some cases, even
that trusts to some luck.)
It has been recently pointed out to me that the man page (ie: this
file) doesn't give any real guidance to what is really acceptable,
and what is not.
The CAVEATS section does note that the grammar is ambiguous, but then
just says that test(1) implements what POSIX requires, and refers
readers to the relevant section of the POSIX standard for more details.
That is probably asking too much of the average reader...
So, add some extra information in the CAVEATS with what is defined to work,
and what should be avoided. Not all of the POSIX rules are here, but this
might hopefully help script authors avoid some of the pitfalls.
process the interrupt when the flag is set - this fixes spurious interrupt
during post-reset drive setup in wdc_ata_bio_start(), and wdc_atapi_start()
while those functions set WDCTL_IDS, this seems to be ignored by certain
(maybe all) PCI-IDE controllers; usually the implicit KERNEL_LOCK() would
prevent the interrupt anyway, but not when the start routine is started
from the atabus thread, which doesn't take it
fixes 'panic: wdc_ata_bio_intr: bad state' reported on current-users
by Chavdar Ivanov
syscall. Then, don't clear PSL_D and PSL_AC in the syscall entry point,
they are now both cleared by the cpu (faster). However they still need to
be manually cleared in the interrupt/trap entry points.
PSL_AC is cleared from %rflags in each kernel entry point. In the copy
sections, a copy window is opened and the kernel can touch userland
pages. This window is closed when the kernel is done, either at the end
of the copy sections or in the fault-recover functions.
This implementation is not optimized yet, due to the fact that INTRENTRY
is a macro, and we can't hotpatch macros.
Sent on tech-kern@ a month or two ago, tested on a Kabylake.
before deciding vmt_probe has succeeded.
qemu supports GET_VERSION but not the RPC protocol so the probe succeeds
but the attach fails, resulting in "vmt0: failed to open backdoor RPC
channel (TCLO protocol)". All known versions of vmware support GET_SPEED
and no known qemu versions do, so this prevents it from attempting to
attach (and failing) on qemu while still working on vmware.
stop checking vmt_type to avoid having to adapt this code.
- Taken from openbsd
There is a race here, as seen on arm with FPU:
LWP L is running but not on CPU, has its FPU state on CPU2 which
has not been released yet, so fpexc still has VFP_FPEXC_EN set in the PCB copy.
LWP L is scheduled on CPU1, CPU1 calls cpu_switchto() for L in mi_switch().
cpu_switchto() will set VFP_FPEXC_EN in the FPU's fpexc register per the
PCB fpexc copy.
Before CPU1 calls pcu_switchpoint() for L, CPU2 calls
pcu_do_op(PCU_CMD_SAVE | PCU_CMD_RELEASE) for L because it still holds its
FPU state and wants to load another lwp. This cause VFP_FPEXC_EN to
be cleared in the PCB copy, but not in CPU1's register. L's l_pcu_cpu is
set to NULL.
When CPU1 calls pcu_switchpoint() for L it see l_pcu_cpu is NULL, and doesn't
call the release callback.
Now CPU1 has its FPU enabled but with the wrong FPU state.
Fix by releasing the PCU even if l_pcu_cpu is NULL.
maxv