Emulate AMD SysCfg MSR in vmm(4).
Linux kernels like to poke this to check for memory encryption
settings. Return 0's on reads instead of injecting #GP. Writes
continue to be ignored.
This reduces some noise for Linux guests on boot.
ok hshoexer@, mlarkin@
Increase MAXCPUs on amd64 to 255
Now that we have larger bitmask support for more than 64 CPUs, we can increase
the max to 255. 255 is the max that xapic can support; this number can be
bumped later if we want to discriminate x2apic vs xapic.
with input from and ok deraadt. also ok kettenis
Support more than 64 bits for amd64 TLB shootdown IPI masks
The TLB shootdown code used a uint64_t to track which CPUs needed to have
their TLB remotely flushed during pmap operations. This allowed for up to
64 CPUs maximum on amd64.
This diff changes the single uint64_t mask to an array of uint8_t masks,
sized based on MAXCPUS, and utilizes the bitmask macros in param.h to
manipulate these masks.
with input from and ok deraadt. also ok kettenis
pmap functions send various TLB shootdown operations by IPI to other cpus.
A lock is grabbed to serialize this. Then recipient cpus get sent an IPI
demanding this work. The lock is reused as a counter of cpus doing the work,
and each cpu's IPI handler decrements the counter.
The local cpu can do some operations in the parallel, before verifying
the TLB operations have completed in pmap_tlb_shootwait() which spins
for the counter to reach 0. But the counter is also a lock, and 0
means other cpu can grab it. So if the latency for the local work
exceeds the latency on the recepient cpus, the "counter-lock" can be
grabbed by a different cpu for its own TLB shootdown operations. The
original cpu will now spin waiting for this second cpu's work to
finish, creating pmap function latency.
To fix this, I create per-cpu counters which are seperate from the lock.
The IPI functions written in asm now decrement this per-cpu counter, and
when it reaches 0, the shared lock is cleared allowing another cpu to
being shootdowns tracked by its own per-cpu counter. The waiting
function only spins on the correct per-cpu counter.
As a bonus, the lock (and new variable indicating the shooting cpu)
are now in cache-aligned.
[2 lines not shown]
stack.c: avoid arithmetic on pointers to void
In stack.c r1.34 I converted one 'char *' too many to 'void *', thereby
relying on a gcc/clang extension which interprets the fictional void
type as a type of size 1 (that's what the stack code wants, fortunately).
As pointed out in the link below, -Wpointer-arith would have caught this:
https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
MSVC flags this as follows:
D:\a\portable\portable\crypto\stack\stack.c(211,23): error C2036: 'const void *': unknown size [D:\a\portable\portable\build\crypto\crypto_obj.vcxproj].
Pull in workaround from the portable repo which undoes the char * -> void *
conversion.
ok jsing millert
Import wayland/wdisplays 1.1.3
wdisplays is a graphical application for configuring displays in Wayland
compositors. It should work in any compositor that implements the
wlr-output-management-unstable-v1 protocol. Compositors that are known
to support the protocol are Sway and Wayfire. The goal of this project
is to allow precise adjustment of display settings in kiosks, digital
signage, and other elaborate multi-monitor setups.
note that the graphical rendering of relative position of screens in the
left pane is broken, because it relies on mesa being linked with
wayland, which isnt the case on OpenBSD. Manually setting screen options
in the right pane works.
ok matthieu@ a while ago
Add explicit lib depends on db and jack
mlt7 dropped the dependency on jack, because synfigstudio did not set this
implicitly in LIB_DEPENDS, it is now missing (The world would be a better place
if we had implicit lists).
Spotted by tb
