Adjust IPLs to give us more interrupt vectors for IPL_NET. That is where
we need them most since multi-queue NICs seem to be a thing now.

ok patrick@, mlarkin@, jan@

vmm(4): add ipi for vmclear, unlock kernel

On Intel VMX hosts, when a guest migrates cpus, VMCS state needs
to be flushed to physical memory before being reloaded on the new
cpu. This diff adds a ne

vmm(4): add ipi for vmclear, unlock kernel

On Intel VMX hosts, when a guest migrates cpus, VMCS state needs
to be flushed to physical memory before being reloaded on the new
cpu. This diff adds a new ipi to allow a guest resuming on a new
cpu to signal to the old that it needs to vmclear.

To better surface the potential race conditions, unlock the kernel
after handling the ioctl to vmm and simplify the run loops for both
vmx and svm. This requires a new vcpu lock.

Tested by some on tech@. "go for it" @mlarkin

show more ...

add an ipi for wbinvd and a linux style wbinvd_on_all_cpus() function

ok kettenis@ deraadt@

Fix pctr(4) issues with MP and suspend:
- use an IPI to notify other CPUs toi update CR4 and the MSRs
- use the cpu(4) resume callback to restore the pctr(4) settings after
suspend/hibernate

ok

Fix pctr(4) issues with MP and suspend:
- use an IPI to notify other CPUs toi update CR4 and the MSRs
- use the cpu(4) resume callback to restore the pctr(4) settings after
suspend/hibernate

ok kettenis@ deraadt@

show more ...

X86_IPI_NAMES's only use was #if 0'ed out; delete both

ok kettenis@ deraadt@

Switch from lazy FPU switching to semi-eager FPU switching: track whether
curproc's xstate ("extended state") is loaded in the CPU or not.
- context switch, sendsig(), vmm, and doing CPU crypto in t

Switch from lazy FPU switching to semi-eager FPU switching: track whether
curproc's xstate ("extended state") is loaded in the CPU or not.
- context switch, sendsig(), vmm, and doing CPU crypto in the kernel all
check the flag and, if set, save the old thread's state to the PCB,
clear the flag, and then load the _blank_ state
- when returning to userspace, if the flag is clear then set it and restore
the thread's state

This simpler tracking also fixes the restoring of FPU state after nested
signal handlers.

With this, %cr0's TS flag is never set, the FPU #DNA trap can no
longer happen, and IPIs are no longer necessary for flushing or
syncing FPU state; on the other hand, restoring xstate while returning
to userspace means we have to handle xrstor faulting if we could
be loading an altered state. If that happens, reset the state,
fake a #GP fault (SIGBUS), and recheck for ASTs.

While here, regularize fxsave/fxrstor vs xsave/xrstor handling, by
using codepatching to switch to xsave/xrstor when present in the
CPU. In addition, code patch in use of xsaveopt in most places
when the CPU supports that. Use the 64bit-wide variants of the
instructions in all cases so that x87 instruction fault IPs are
reported correctly.

This change has three motivations:
1) with modern clang, SSE registers are used even in rcrt0.o, making
lazy FPU switching a smaller benefit vs trap costs
2) the Intel SDM warns that lazy FPU switching may increase power costs
3) post-Spectre rumors suggest that the %cr0 TS flag might not block
speculation, permitting leaking of information about FPU state
(AES keys?) across protection boundaries.

tested by many in snaps; prodding from deraadt@

show more ...

Define and use IPL_MPFLOOR in our common mutex implementation.

ok kettenis@, visa@

Setup Hyper-V hypercall page and an IDT vector.

ok mlarkin, kettenis, deraadt

Set up an IDT vector for Xen callbacks

This adds support for delivering the combined Xen interrupt
that later fans out into event port specific (device specific)
interrupts via an IDT of a guest sys

Set up an IDT vector for Xen callbacks

This adds support for delivering the combined Xen interrupt
that later fans out into event port specific (device specific)
interrupts via an IDT of a guest system.

The Xen IDT vector is set to be the first of the IPL_NET group
and is implemented the same way LAPIC timer and IPIs are done.
The additional machinery is there to be able to mask it via
standard mechanisms (e.g. splnet).

Discussed with kettenis@, OK mlarkin, reyk

show more ...

vmm(4) kernel code

circulated on hackers@, no objections. Disabled by default.

Remove a #define for an ipi removed last year. No functional change.

Fixes a hibernate issue wherein we locked the kernel lock while hatching
but then parked ourselves in real mode without completing acquisition of
said lock. Also removes the park routine from i386 si

Fixes a hibernate issue wherein we locked the kernel lock while hatching
but then parked ourselves in real mode without completing acquisition of
said lock. Also removes the park routine from i386 since we don't need it
(the APs are already parked at the time we start unpack).

discussed with and ok kettenis@, also ok deraadt@

show more ...

Introduce a new amd64 IPI, x86_ipi_halt_realmode to park CPUS into real
mode and halt them. Needed for hibernate.

ok deraadt@ kettenis@ "there's no risk there"

Implement a mechanism to establish interrupt handlers that don't grab the
kernel lock upon entry through a new IPL_MPSAFE flag/level.

ok mikeb@, mpi@

Raise the number of interrupt sources per CPU from 32 to 64. This effectively
triples the number of interrupt vectors that can be handled by the primary
CPU. Important for MSI, but could also fix s

Raise the number of interrupt sources per CPU from 32 to 64. This effectively
triples the number of interrupt vectors that can be handled by the primary
CPU. Important for MSI, but could also fix some issues with large machines
loaded with a lot of devices.

tested by many; ok deraadt@, marco@

show more ...

Switch from TSS-per-process to TSS-per-CPU, placing the TSS right
next to the cpu's GDT, also making the double-fault stack per-CPU,
leaving it at the top of the page of the CPU's idle process. Inli

Switch from TSS-per-process to TSS-per-CPU, placing the TSS right
next to the cpu's GDT, also making the double-fault stack per-CPU,
leaving it at the top of the page of the CPU's idle process. Inline
pmap_activate() and pmap_deactivate() into the asm cpu_switchto
routine, adding a check for the new pmap already being marked as
active on the CPU. Garbage collect the hasn't-been-used-in-years
GDT update IPI.

Tested by many; ok mikeb@, kettenis@

show more ...

this is amd64, not i386, and the protection was all busted

Rename IPL_SOFTSERIAL to IPL_SOFTTY and rename the associated symbols.
Remove IPL_SERIAL since it is unused.

ok krw@, weingart@, deraadt@

Add the mp setperf mechanism to AMD64, like its i386 counterpart it allows
all cpus in a system supporting frequency and voltage scaling to be scaled
by the same amount corresponding to the user (or

Add the mp setperf mechanism to AMD64, like its i386 counterpart it allows
all cpus in a system supporting frequency and voltage scaling to be scaled
by the same amount corresponding to the user (or apmd on their behalf)
performance level.

This diff also teaches amd64 about acpi_hasprocfvs (ACPI has processor
frequency and voltage scaling).

It also moves initilization of the underlying setperf mechanism such
as powernow to mainbus from the cpu indentification and initilization
code inspired by similar changes dim@ made to i386 durring h2k6. This
is necessary to implement the AMD recommended method for retreiving
p_state data from the ACPI _PSS object (a diff comming soon). It will
also simplify the potential addition of enhanced speedstep as found
on newer intel processors with EMT64 capable of running OpenBSD/amd64.

MP setperf functionality verifed by myself and Johan M:son Lindman <tybolt
AT solace DOT miun DOT se> on opteron 265 and 270 systems respectively.
General testing done by many others thanks!

ok tedu, dim

show more ...

Rename the MICROSET IPI we inherited from NetBSD to simply NOP since
it doesn't do anything (other than poking into the kernel a processing
ASTs).

remove IPL_IMP and splimp().

'machine cpuinfo' and 'machine ddbcpu' in ddb for amd64

an amd64 arch support.
hacked by art@ from netbsd sources and then later debugged
by me into the shape where it can host itself.
no bootloader yet as needs redoing from the
recent advanced i386 sourc

an amd64 arch support.
hacked by art@ from netbsd sources and then later debugged
by me into the shape where it can host itself.
no bootloader yet as needs redoing from the
recent advanced i386 sources (anyone? ;)

show more ...