from NetBSD

survived a make release

Things like the manufacturer or design capacity aren't going to
change after boot, so don't bother updating them every poll cycle.

if ACPI_DEBUG is defined but acpi_debug is set to 0, nothing should
print anything

Turn fan off at boot, turn it back on during shutdown

Adjustable with sysctl machdep.hwp

This makes it more like macOS which only gives 1/4 space to the
right-click button

cst_stats can be retrieved through pstat but that requires
kern.allowkmem=1, and this is just easier to monitor though
obviously not real-time data.

This version passes a flag to kprintf to avoid printing timestamps
from ttyinfo().

It also forces tc_ticktock() to update the timecounters from
hardware during boot, otherwise the entire kernel log until
multiuser has a timestamp of 0.

Split it into a bad_list case for all those duplicate attr checks and
a bad_ibuf case that is used when the parsing hits a general issue.

OK sthen@

ok deraadt@, stsp@

ok stsp@

Copy-paste bug which was introduced with rev 1.128.
Causes the parent to SIGSEGV on config reloads when mrt dumps are used.

Fix for CID 501585

ok yasuoka

EncapContentInfo_it was renamed to ContentInfo_it in ccr.c rev 1.31
ok claudio@

When SEV guest userland issues a vmmcall instruction, a #VC exception
with code SVM_VMEXIT_VMMCALL will be raised in the guest kernel.
For now we do not allow vmmcalls from guest userland, thus terminate
the userland process with SIGILL.

This is similar to the non-SEV case.

ok mlarkin@

SEV guest userland processes are allowed to issue the vmgexit
instruction. However, guest userland has no access to the GHCB.

VMEXITs with exit reason SVM_VMEXIT_VMGEXIT initiated by the guest
kernel will always provide a valid GHCB request.

Moreover, as the guest kernel makes sure, that the GHCB contains
no request when guest userland is running, a rouge guest userland
process can only force repeated VMEXITs with an empty GHCB.

Therefore, in vmm(4)'s vmgexit handler inject #UD when the exit
reason is not updated with data from the GHCB and stays on
SVM_VMEXIT_VMGEXIT.

ok mlarkin@

The GHCB valid bitmap indicates wether the GHCB contains a request
or not. When no bits are set, ignore the GHCB and do not sync with
vCPU state.

To clear/invalidate the GHCB just zero out the valid bitmap instead
of the full GHCB.

ok mlarkin@

For communication with the parent the missing presence of a filter_set
is cause for a panic. This should just never happen. For messages from
bgpctl that are forwarded by the session engine things are more complex.
Make sure the filter_set was sent and only execute the command that
wraps this filter_set is present. If it is not there it may have been
filtered out because it is invalid and then the command depending on
this data should not be executed.

OK tb@

On AMD/SVM the hypervisor will inject #UD when userland tries to
execute the vmmcall instruction. Same holds for vmgexit which is
encode as "rep vmmcall".

On Intel/VMX vmmcall and vmgexit are invalid instructions, so the
CPU will raise #UD.

ok mlarkin@

On Intel/VMX the hypervisor will inject #UD when userland tries to
execute the vmcall instruction.

On AMD/SVM vmcall is an invalid instruction, so the CPU will raise

ok mlarkin@

While there fix typo in a debug printf.

ok mlarkin@

ok mlarkin@

tested by stsp@ as part of a larger diff
ok dlg@

ok jsg