into cpu_info directly. This concerns only {i386, Xen-i386, Xen-amd64},
because amd64 already has a direct map that is way faster than that.
There are two major issues with the global array: maxcpus entries are
allocated while it is unlikely that common i386 machines have so many
cpus, and the base VA of these entries is not cache-line-aligned, which
mostly guarantees cache-line-thrashing each time the VAs are entered.
Now the number of tmp VAs allocated is proportionate to the number of CPUs
attached (which therefore reduces memory consumption), and the base is
properly aligned.
On my 3-core AMD, the number of DC_refills_L2 events triggered when
performing 5x10^6 calls to pmap_zero_page on two dedicated cores is on
average divided by two with this patch.
Discussed on tech-kern a little.
The last known microcode to work is 2.4. Version 3.0 changes
the header signature and fails with "block too big for NPE memory".
Provide a backup download URL since intel removed version < 3.0.
system with the available segments.
High memory systems may have more than VM_PHYSSEG_MAX segments; it is
better to truncate the memory and allow the system to work rather than
just panicking. The user can still increase VM_PHYSSEG_MAX (or ask us to).
Fixes issues such as PR/47093.
Note: the warning is logged but does not appear in dmesg, this too needs
to be fixed for the rest of the bootstrap procedure.
discard the associated bootinfo entry. Otherwise the machine faults and
reboots immediately.
I spotted this bug more than a year ago, but I recently saw that there is
already PR/42645 (7 years old), so just fix it. The size has been increased
in the meantime, so the limit is unlikely to be reached anyway.
are several structural differences. At least two issues here: segment
registers that could fault in kernel mode with userland TLS, and a non-
canonical %eip on iret.
Not even tested, but just obvious. By the way, I believe this function is
still buggy since we don't call cpu_fsgs_reload while %fs/%gs could have
been reloaded.
in kernel mode but simply cause a signal to be sent to userland. The thing
is, in this case %gs is not restored when entering the trap routine, which
means the kernel uses userland's TLS instead of using its own. Which in
short makes it easy to escalate privileges.
Currently, this bug is triggered only in one place, which I am about to
fix too.
Specifically, it has been commanded that unused-functions is a warning,
and, as all should know, all warnings be errors.
Hence, since XEN kernels do not call set_sys_gdt(), that function
may not be included (and the XEN kernel saves a few tens of bytes.)
An alternate fix would be to just remove "static" - but that would be
the equivalent to just giving the compiler the finger ... hmm, maybe
that would have been a better fix...
LDT is set; just check the permission without checking the location (which
may change).
In valid_user_selector, don't check the length of the LDT. This is racy
because pm_ldt_len could be updated by another thread, and useless since
the length is already referenced in ldtr (ldt_alloc), which means that any
overflow will fault in userland.
Also, don't check the permission of the segment pointed to; this too is
racy, and we don't care either since the permissions are checked earlier
in x86_set_ldt1.
Pass 1/2.
