Make sure we select the deepest possible C-state during suspend-to-idle.

ok deraadt@, guenther@, mlarkin@, jsg@

Implement wakeup interrupts on amd64. Provide a dummy implementation for
i386 such that we can call the necessary hooks in the suspend/resume code
without adding #ifdefs. Tweak the arm64 implementa

Implement wakeup interrupts on amd64. Provide a dummy implementation for
i386 such that we can call the necessary hooks in the suspend/resume code
without adding #ifdefs. Tweak the arm64 implementation such that we can
call the hooks earlier as this is necessary to mask MSI and MSI-X
interrupts on arm64.

ok deraadt@, mlarkin@

show more ...

remove unused global vars
ok deraadt@ miod@

all platforms: separate cpu_initclocks() from cpu_startclock()

To give the primary CPU an opportunity to perform clock interrupt
preparation in a machine-independent manner we need to separate the
"

all platforms: separate cpu_initclocks() from cpu_startclock()

To give the primary CPU an opportunity to perform clock interrupt
preparation in a machine-independent manner we need to separate the
"initialization" parts of cpu_initclocks() from the "start the clock
interrupt" parts. Currently, cpu_initclocks() does everything all at
once, so there is no space for this MI setup.

Many platforms have more-or-less already done this separation by
implementing a separate routine named "cpu_startclock()". This patch
promotes cpu_startclock() from de facto standard to mandatory API.

- Prototype cpu_startclock() in sys/systm.h alongside cpu_initclocks().
The separation of responsibility between the two routines is a bit
fuzzy but the basic guidelines are as follows:

+ cpu_initclocks() must initialize hz, stathz, and profhz, and call
clockintr_init().

+ cpu_startclock() must call clockintr_cpu_init() and start the clock
interrupt cycle on the calling CPU.

These guidelines will shift in the future, but that's the way things
stand as of *this* commit.

- In initclocks(): first call cpu_initclocks(), then do MI setup, and
last call cpu_startclock().

- On platforms where cpu_startclock() already exists: don't call
cpu_startclock() from cpu_initclocks() anymore.

- On platforms where cpu_startclock() doesn't yet exist: implement it.
Usually this is as simple as dividing cpu_initclocks() in two.

Tested on amd64 (i8254, lapic), arm64, i386 (i8254, lapic), macppc,
mips64/octeon, and sparc64. Tested on arm/armv7 (agtimer(4)) by
phessler@ and jmatthew@. Tested on m88k/luna88k by aoyama@. Tested
on powerpc64 by gkoehler@ and mlarkin@. Tested on riscv64 by
jmatthew@.

Thread: https://marc.info/?l=openbsd-tech&m=169195251322149&w=2

show more ...

avoid bios sign msr on intel family < 6
the pentium msr list in the sdm does not include it

avoid patch level msr on amd families < 0fh

Paul de Weerd reported it isn't implemented on ALIX with
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 499 MHz, 05-0a-02

the

avoid patch level msr on amd families < 0fh

Paul de Weerd reported it isn't implemented on ALIX with
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 499 MHz, 05-0a-02

the earliest amd microcode update files I can find are for family 0fh (K8)

ok guenther@

show more ...

show x86 cpu patch level in dmesg
ok guenther@ deraadt@

Some hypervisors (such as Hertzner) allow msr read of DE_CFG (which does
not indicate bit 9 set, but they could have a firmware fix) but then block
a msr write to bit 9 (which disables enough AVX opt

Some hypervisors (such as Hertzner) allow msr read of DE_CFG (which does
not indicate bit 9 set, but they could have a firmware fix) but then block
a msr write to bit 9 (which disables enough AVX optimizations
to prevent the exfiltration of data), with a fault. So let's also check
the HV bit before we decide to modify the bit. hypervisors are expected
to set that bit. tested by lucas at sexy dot is.
with jsg, ok mlarkin

show more ...

Set DE_CFG[9] -- a chickenbit which stops Zenbleed. The chickenbit may
have other side-effects (not disclosed by AMD), and firmwares fixes may
be better (and have other side-effects, same story). N

Set DE_CFG[9] -- a chickenbit which stops Zenbleed. The chickenbit may
have other side-effects (not disclosed by AMD), and firmwares fixes may
be better (and have other side-effects, same story). Newer processors
will probably be validated more carefully by AMD.
Issue found by Tavis Ormandy.
This is errata 7.2/033_amdcpu.patch.sig and 7.3/011_amdcpu.patch.sig
Zenbleed also blocked on select cpus by using errata
7.3/012_amdfirmware.patch.sig + 7.3/013_amdcpufirmware.patch /
7.2/034_amdfirmware.patch.sig + 7.2/035_amdcpufirmware.patch.sig
which load AMD cpu firmwares (firmware.openbsd.org is updated often to
contain the best firmwares)
ok jsg

show more ...

remove unneeded includes in arch/i386
ok krw@ miod@

i386/machdep.c: revert revisions 1.659 and 1.660

"put it back" kettenis@

Hide WAITPKG cpu feature from vmm(4) guests.

Alder Lake and similar-era Intel platforms introduced new userland
wait instructions. Since vmm was passing this cpuid bit into guests,
some would attemp

Hide WAITPKG cpu feature from vmm(4) guests.

Alder Lake and similar-era Intel platforms introduced new userland
wait instructions. Since vmm was passing this cpuid bit into guests,
some would attempt TPAUSE instructions and trigger invalid instruction
exceptions because VMX requires additional configuration to support
emulation.

This also adds WAITPKG to i386 and amd64 cpu feature identification.

Input from anton@, cheloha@, and guenther@. Tested by jmatthew@.

OK deraadt.

show more ...

i386: identifycpu(): only calibrate_cyclecounter() on primary CPU

On i386 during identifycpu(), we call calibrate_cyclecounter() for every
CPU in the system. This is pointless: every new call clobb

i386: identifycpu(): only calibrate_cyclecounter() on primary CPU

On i386 during identifycpu(), we call calibrate_cyclecounter() for every
CPU in the system. This is pointless: every new call clobbers the cpuspeed
measured during the prior call. It is also extremely slow: every call to
calibrate_cyclecounter() takes about 1 second.

Instead, let's only call calibrate_cyclecounter() once, on the primary CPU.
Multiprocessor i386 machines will now boot much faster.

ok deraadt@

show more ...

i386: identifycpu(): don't print cpuspeed after calibrate_cyclecounter()

The cpuspeed set during calibrate_cyclecounter() is a bogomips measurement.
It isn't an authoritative (nominal) frequency, so

i386: identifycpu(): don't print cpuspeed after calibrate_cyclecounter()

The cpuspeed set during calibrate_cyclecounter() is a bogomips measurement.
It isn't an authoritative (nominal) frequency, so we shouldn't print it out
when identifying each CPU. As an added bonus, this also removes some noise
when diffing i386 dmesgs.

ok deraadt@

show more ...

i386: add delay_fini()

Not all of the clocks with a delay(9) implementation necessarily keep
ticking across suspend/resume. We need a clean way to reverse
delay_init() during suspend when those clo

i386: add delay_fini()

Not all of the clocks with a delay(9) implementation necessarily keep
ticking across suspend/resume. We need a clean way to reverse
delay_init() during suspend when those clocks stop ticking.

Hence, delay_fini(). delay_fini() resets delay_func() to
i8254_delay() if the given function pointer is the active delay(9)
implementation.

ok mlarkin@

show more ...

Simplfity setregs() by passing it the ps_strings and switching
sys_execve() to return EJUSTRETURN.

setregs() is the MD routine used by sys_execve() to set up the
thread's trapframe and PCB such that

Simplfity setregs() by passing it the ps_strings and switching
sys_execve() to return EJUSTRETURN.

setregs() is the MD routine used by sys_execve() to set up the
thread's trapframe and PCB such that, on 'return' to userspace, it
has the register values defined by the ABI and otherwise zero. It
had to set the syscall retval[] values previously because the normal
syscall return path overwrites a couple registers with the retval[]
values. By instead returning EJUSTRETURN that and some complexity
with program-counter handling on m88k and sparc64 goes away.

Also, give setregs() add a 'struct ps_strings *arginfo' argument
so powerpc, powerpc64, and sh can directly get argc/argv/envp
values for registers instead of copyin()ing the one in userspace.

Improvements from miod@ and millert@
Testing assistance miod@, kettenis@, and aoyama@
ok miod@ kettenis@

show more ...

amd64, i386: add delay_init(): basic delay(9) implementation management

Because the clock situation on x86 and amd64 is a terminal
clusterfuck, there are many different ways to delay(9). We need a

amd64, i386: add delay_init(): basic delay(9) implementation management

Because the clock situation on x86 and amd64 is a terminal
clusterfuck, there are many different ways to delay(9). We need a
rudimentary mechanism for gracefully switching to progressively better
delay(9) implementations as they become available during boot without
riddling the code with ifdefs and function pointer comparisons.

This patch adds delay_init() to both amd64 and i386. If the quality
value passed to delay_init() exceeds the quality value of the current
delay_func, delay_init() changes delay_func to the given function
pointer and updates the quality value. Both platforms start with
delay_func set to i8254_delay() and a quality value of zero: all other
delay(9) implementations are preferable.

Idea and patch provided by jsg@. With tons of input, research, and
advice from jsg@.

Link: https://marc.info/?l=openbsd-tech&m=166053729104923&w=2

ok mlarkin@ jsg@

show more ...

remove cpu var from i386; removed from amd64 in 2015
ok daniel@

drop detection code for Cyrix CPUs older than the Cyrix M2

The 486DLC is a 486-class CPU which we no longer support on i386.

The 6x86 (also known as the M1) did not support CPUID by default[*]
so e

drop detection code for Cyrix CPUs older than the Cyrix M2

The 486DLC is a 486-class CPU which we no longer support on i386.

The 6x86 (also known as the M1) did not support CPUID by default[*]
so extra support code is needed to differentiate between these early
Cyrix processors in order to apply some errata that the M1 needs.
However the 6x86 doesn't implement the RDTSC instruction so we can
remove support code for this CPU at this point.

Cyrix implemented RDTSC in the 6x86MX (also known as the M2). So
this is likely the earliest Cyrix CPU that we can support on i386.

We keep the support code in "cyrix6x86_cpu_setup" because early
6x86MX CPUs would continue to benefit from this fixup code.

[*]: CPUID can be enabled on the Cyrix 6x86 by setting bit 7 of
CCR4

ok mlarkin@, jsg@

show more ...

repair printing of cpu class after machdep.c 1.652
ok daniel@ mlarkin@

drop detection code for 386sx/386dx CPUs

OpenBSD/i386 doesn't actually support running on 386sx or 386dx CPUs
so we don't need to test whether we're running on one of these CPUs
anymore.

The 486 (w

drop detection code for 386sx/386dx CPUs

OpenBSD/i386 doesn't actually support running on 386sx or 386dx CPUs
so we don't need to test whether we're running on one of these CPUs
anymore.

The 486 (which was launched in 1989) added a few new features over
the 386:
- an alignment check flag in EFLAGS
- 3 new userland instructions: bswap / cmpxchg / xadd
- 3 new kernel mode instructions: invd / wbinvd / invlpg
- new bits in CR0 (386 CPUs did not support ring0 write protection)
- new bits in CR3

In this diff, we remove the code that checks for the alignment check
flag as we've only supported Pentium (or newer) CPUs for some time.

The rest of the diff is about updating comments related to pre-486
CPUs. 2 files under arch/amd64 are updated to keep them in sync
with the arch/i386 updates.

ok mlarkin@, jsg@; tweak from miod@

show more ...

retire Rise CPU identification code

The Rise mp6 was an x86 compatible CPU that was available for about
a year from 1998 to 1999. Only the Kirin core was ever available
while the Lynx core did not m

retire Rise CPU identification code

The Rise mp6 was an x86 compatible CPU that was available for about
a year from 1998 to 1999. Only the Kirin core was ever available
while the Lynx core did not make it to market. Shortly after this
CPU was released, SiS acquired Rise's technology and integrated it
into their SiS55x SoC which used a different vendor string.

Given how uncommon Rise CPUs are and given that we don't do anything
if we detect such a CPU, remove the small amount of code used to
identify them. OpenBSD should continue to run on these CPUs, they
just won't be recognized as Rise CPUs explicitly.

It is suspected that in the current code, a Rise CPU would not show
CX8 in the dmesg despite supporting the CMPXCHG8B instruction. The
Rise datasheet says that this cpuid feature bit is set to 0 to
"circumvent a reported bug in Windows NT". This is only a cosmetic
issue though as our kernel does not use CMPXCHG8B and our toolchain
assumes it exists (we default to -march=i586).

An interesting writeup on this topic is available here:

https://www.geoffchappell.com/studies/windows/km/cpu/cx8.htm

ok mlarkin@, deraadt@, jsg@

show more ...

remove cache parts of struct cpu_info which were used by vmm

retire NexGen CPU identification code

On OpenBSD/i386 we only support Pentium compatible CPUs with an FPU.
The NexGen CPUs probably don't meet this requirement so remove the
small amount of support

retire NexGen CPU identification code

On OpenBSD/i386 we only support Pentium compatible CPUs with an FPU.
The NexGen CPUs probably don't meet this requirement so remove the
small amount of support code to identify this brand of CPU.

The Nx586 "P" models did not include an FPU as they were expected
to be paired with an Nx587 FPU (which was never officially released).

The Nx586 "FP" models did include an FPU, but even these are allegedly
386 clones and not Pentium compatible. According to some websites,
486 instructions were emulated via hypercode. However the 486
instruction emulation was only enough to run applications and wasn't
good enough to run an OS that needs newer 486 and Pentium instructions.

Finally, while our current code references the "Processor Recognition
Application Note", we only implement the half of the documented
algorithm to detect NexGen CPUs. We don't implement the second half
of the algorithm to check for the vendor string "NexGenDriven" on NexGen
CPUs that support the CPUID instruction (like the Nx586-P120 and Nx586-P133).

ok jsg@

show more ...

An old hack skips use of memory regions < 1MB size, because some machines
put BIOS objects into there, and rely upon them. We are shocked, SHOCKED,
to find a machine that does so in a large object (

An old hack skips use of memory regions < 1MB size, because some machines
put BIOS objects into there, and rely upon them. We are shocked, SHOCKED,
to find a machine that does so in a large object (Supermicro 5019D-FTN4).
So now we need to ignore memory regions < 32MB in size. If we put this
memory into use, the zerothread will soon clear it, and on this particular
case the machine resets because something in AML or SMI gets unhappy.
Other machines with similar problems may exhibit other misbehaviours, so
this could fix heisenbugs. Sadly I expect products to get worse.
ok kettenis, miod

show more ...