When pmap_enter(9) is asked to enter a mapping that already exists, we
should avoid removing the existing mapping otherwise we can trigger a
scenario where multiple threads of a process will continously fault
on a single page.
ok jca@, miod@, mlarkin@
refcnt_shared can be a macro around refcnt_read.
they're basically the same code except refcnt_shared checks if the
read value was > 1. the caller is going to check it anyway, so get rid
of the duplicate code.
AMD SEV-ES guest: In vctrap() allow only CPUID from userspace.
CPUID is the only instruction we allow to raise a #VC exception
also from user space. All other instructions are limited to raise
#VC from kernel space only.
With respect to rdmsr/wrmsr, this is an additional safe-guard, as
these two instructions will raise a #GP anyway when the CPL is
greater than 0.
With respect to in/out, userland could be allowed to access IO
ports. However, our SEV-ES guest do not support this for now.
from hshoexer@; OK mlarkin@
fix build with libc++ 19 (From FreeBSD)
As noted in the libc++ 19 release notes [1], std::char_traits<> is now
only provided for char, char8_t, char16_t, char32_t and wchar_t, and any
instantiation for other types will fail.
[1] https://libcxx.llvm.org/ReleaseNotes/19.html#deprecations-and-removal
fix build with libc++ 19 (From FreeBSD)
As noted in the libc++ 19 release notes [1], std::char_traits<> is now
only provided for char, char8_t, char16_t, char32_t and wchar_t, and any
instantiation for other types will fail.
[1] https://libcxx.llvm.org/ReleaseNotes/19.html#deprecations-and-removals
Patch gnulib/fseeko.c. gnulib is doing this to make fflush() behaivour
to match what they expect. It accesses internal of __sFILE to change
behavior of fseeko(), but we are hiding internal of __sFILE and our
fseeko() is compatible with what gnulib expects already. Then the
patch is to just use our fseeko().
feedbacks from tb guenther beck
ok sthen
