Age | Commit message (Collapse) | Author |
|
than uvm_km_valloc(9).
ok kettenis@
|
|
|
|
|
|
is just too different from GENERIC or GENERIC.MP
pointed out by jsg
|
|
The 'nominal core crystal clock frequency' from cpuid 0x15 is 0 on
Intel model 0xa5 (CML-H CML-S62 CML-S102) and 0xa6 (CML-U62). So act as
if 24 MHz was reported like we do on other Skylake/Kaby Lake variants.
Comet Lake processors with model 0x8e (CML-U42 CML-Y42) use the same model
number used by Kaby Lake and many other parts which was already handled.
While we could approximate the crystal frequency with 'Processor Base
Frequency' from cpuid 0x16 eax like FreeBSD and Linux do, kettenis@ couldn't
get ntpd to sync a clock on a Skylake machine with:
CPUID 0x15: eax=2, ebx=134, khz=0
CPUID 0x16: eax=1600, ebx=1600, ecx=100, edx=0
with reported crystal frequency changing from 24000 kHz to 23880 kHz
(cpuid 0x16 eax * 1000 * cpuid 0x15 eax / cpuid 0x15 ebx) and
TSC frequency changing from 1608000000 to 1599960000.
Cannon Lake, Ice Lake, and Tiger Lake are known to return non-zero
frequency in cpuid 0x15 so hopefully no other model ids have to be added.
James Cook reported hangs on bsd.rd with i7-10710U 06-a6-00 (CML-U62)
(which does not have acpihpet) but not with bsd.mp (which does) and has
confirmed that both approaches fixed the problem.
|
|
>= zen 2 based amd processors return a value of 9 for l3 cache assoc
via cpuid 0x80000006. As that is a reserved value we end up incorrectly
claiming the l3 cache is disabled. While it is possible to get l3 cache
information via cpuid 0x8000001d when TOPEXT is advertised that will
instead give information about the l3 cache available to the core
complex (CCX) that the cpu belongs to where previously the amount of l3
available to all core complexes was shown.
As we don't detail topology in dmesg or show the mapping of cores to
core complexes just stop displaying l3 information. It already isn't
shown on intel.
ok gkoehler@
|
|
acpi disabled, no real mpbios hardware in sight.
ok kettenis@
|
|
variable. Make PG_PVLIST panics consistent and print more values.
OK mpi@
|
|
ok gkoehler@
|
|
At a minimum, amd64/i386 should now boot from 4TB GPT formatted disks.
More daddr32_t terminations with extreme prejudice to follow.
Tested by various, in snaps for a few days.
ok deraadt@
|
|
ok mpi@
|
|
Avoids the situation where FP code ran out of the amdgpu attachhook
would sometimes trigger SSE FP exception traps because precision
exceptions were not masked in mxcsr.
feedback from and ok kettenis@
|
|
need to explicitly call wbinvd() in wbinvd_on_all_cpus().
ok jsg@, deraadt@
|
|
ok jca@
|
|
PCHs. With help from James Hastings.
ok deraadt@
|
|
while TC_TSS and TC_FLAGMASK have _never_ been used
ok kettenis@
|
|
|
|
slots but rather go directly from the iretq frame to an intrframe.
This saves 22 bytes in each of the 148 interrupt entry points.
ok mpi@
|
|
No effect on object code, just symbol table accuracy
ok mpi@
|
|
Simplify MD code and reduce the amount of recursion into the signal code
which helps when dealing with locks.
ok cheloha@, deraadt@
|
|
ok mpi@
|
|
|
|
The Meltdown mitigation work ran right across the previous abstractions;
draw slightly different lines and use separate macros for interrupts
vs traps vs syscall.
The generated ASM for traps and general interrupts is completely
unchanged; the ASM for the four directly routed interrupts is brought
into line with the general interrupts; the ASM for syscalls is
changed to delay reenabling interrupts until after all registers
are saved and cleared.
ok mpi@
|
|
Note that the first 16MB of the block are currently unused since
we link our kernels at physical address 0x01000000. Therefore
32MB is no longer enough to load a kernel that is now larger than
16MB.
Fixes the "entry point at 0x10010000" hang that people have reported
on some machines.
ok patrick@, naddy@, deraadt@
|
|
it shouldn't optimise across them.
ok kettenis@
|
|
This creates separate domains for each PCI device and can provide protection
against invalid memory access. Needed for Passthrough PCI from vmd.
ok deraadt@, kettenis@
: ----------------------------------------------------------------------
|
|
PDP pool and use the single page allocator for the PDP pool. This makes
pmap_destroy(9) mpsafe while preventing additional pressure on the
interrupt-safe kernel map.
ok mpi@
|
|
minor refactorings to narrow KERNEL_LOCK just around uvm_fault()
ok kettenis
|
|
floating-point control modes are properly restored by longjmp(3).
ok guenther@
|
|
into trapsignal()
discussed with kettenis
|
|
This is a similar translation as i386, and matches the idea that SIGBUS
signals refer to problems with the underlying object rather than the
mapping.
ok kettenis
|
|
|
|
checking of variables and avoid the KERNEL_LOCK in more cases. Much
discussion with kettenis led up to this.
ok kettenis
|
|
ok kettenis
|
|
ok mpi@, kettenis@, patrick@
|
|
dead variables, present from the fork from i386 but unused since the
interrupt code on amd64 managed to divorce its ISA heritage
ok deraadt@
|
|
ok deraadt@
|
|
This should be sufficient for identifying pivoted ROP. Doing so for other
traps is at best opportunistic for finding a straight-running ROP chain,
but the added (and rare) sleeping point has proven to be dangerous.
Discussed at length with kettenis and mortimer.
ok mortimer kettenis mpi
|
|
Apple machines. The driver attaches through acpi(4) when the HID
'APP0002' is found.
Thanks to kettenis@ for helping me sorting out the PCI bits.
ok kettenis@
|
|
The fault address is read from cr2 in pageflttrap() which
gets called after this check and if the check sleeps, cr2 is likely to
be clobbered by a page fault in another process.
Fix this by reading cr2 early and pass it to pageflttrap().
ok mpi@, semarie@, deraadt@
|
|
with this we can revert the recent coherency workaround in mesa
ok deraadt@ kettenis@
|
|
ok kettenis@ deraadt@
|
|
|
|
Now that asmc(4) attaches through acpi(4), other than with isa(4), acpi(4)
could attach multiple SMC chips in theory, even though in practice there
will be only one SMC chip per machine.
Suggested and ok kettenis@
|
|
This e.g. makes the driver also work on iMac11,2.
ok kettenis@, jung@
|
|
The header is being pulled via db_machdep.h -> uvm_extern.h -> uvm_map.h
|
|
from jordan@
|
|
In preparation for running the lapic timer in oneshot mode on amd64 we
need a replacement for lapic_delay().
Using the lapic timer itself to implement delay(9) when the timer is
not running in periodic mode is complicated if not outright impossible.
Meanwhile, the i8254 provides our only other amd64 delay(9) implementation
and it is an extremely slow clock. On my 2GHz machine, gettick() takes
~20 microseconds to complete *without* mutex contention. On a VM it is
even slower, as you must exit the VM for each inb() and outb().
So, add tsc_delay() and use it when we have a constant/invariant TSC.
The TSC is a 64-bit "up-counter" so the implementation is simple.
Given how slow the i8254 is on modern machines, we may want to add an
HPET delay(9) implementation as a fallback for machines where the TSC
drifts. The HPET itself is pretty slow, but not as slow as the i8254.
Discussed with kettenis@, Mike Larkin, and naddy@.
Tweaked by kettenis@.
ok kettenis@
|
|
We reprogram the lapic timer by hand in three separate places.
This is error-prone and difficult to read.
To clean things up, introduce routines for reprogramming the lapic
timer in a given mode. lapic_timer_oneshot() starts a oneshot
countdown. lapic_timer_periodic() starts a repeating countdown.
Both of these routines call lapic_timer_start(), wherein we actually
write the lapic registers.
With input from dlg@.
Earlier version eyeballed by mlarkin@.
Suspend/resume tested by gnezdo@.
|
|
at the beginning of the loop. We need to use cr3 at the start of each
iteration for the top level page directory.
From and ok sf@
|