| ec2ba064 | 03-Jul-2021 |
Aaron LI <aly@aaronly.me> |
Revert "libnvmm: Fix mmap() failure with 'permission denied'"
Because libnvmm no longer calls mmap() to map the VCPU comm page, revert
to the original code to distinguish root owner (open '/dev/nvmm
Revert "libnvmm: Fix mmap() failure with 'permission denied'"
Because libnvmm no longer calls mmap() to map the VCPU comm page, revert
to the original code to distinguish root owner (open '/dev/nvmm' with
O_WRONLY) vs. non-root owner (open with O_RDONLY).
show more ...
|
| 9aa070ef | 03-Jul-2021 |
Aaron LI <aly@aaronly.me> |
nvmm: Create comm page in nvmm_vcpu_create() rather than via mmap()
Create the VCPU comm page in nvmm_vcpu_create() in kernel, rather than
via mmap() in userland. With this change, the 'mmap' opera
nvmm: Create comm page in nvmm_vcpu_create() rather than via mmap()
Create the VCPU comm page in nvmm_vcpu_create() in kernel, rather than
via mmap() in userland. With this change, the 'mmap' operation support
is no longer needed by the '/dev/nvmm' device.
This change breaks ABI, so bump NVMM_KERN_VERSION accordingly.
No API change.
show more ...
|
| 23b2397d | 03-Jul-2021 |
Aaron LI <aly@aaronly.me> |
nvmm: Make FPU state more OS-indenpendent
* Introduce an OS-indenpendent 'nvmm_x64_state_fpu' structure, derived
from NetBSD's current FPU implementation.
* Also introduce the 'nvmm_x86_xsave' str
nvmm: Make FPU state more OS-indenpendent
* Introduce an OS-indenpendent 'nvmm_x64_state_fpu' structure, derived
from NetBSD's current FPU implementation.
* Also introduce the 'nvmm_x86_xsave' structure, containing the FPU area
and the XSAVE header.
* Add the 'nvmm_x86_xsave_size()' that determines the XSAVE area size to
simplify the code.
* Rename gfpu -> gxsave, for clarity.
* Define 'CTASSERT' because 'nvmm.h' and 'nvmm_x86.h' headers will
be used by libnvmm(3), but <sys/cdefs.h> only defines 'CTASSERT' for
kernel.
* Update libnvmm.3 man page accordingly.
show more ...
|
| 7f94978c | 30-May-2021 |
Aaron LI <aly@aaronly.me> |
libnvmm: Fix mmap() failure with 'permission denied'
The mmap() in nvmm_vcpu_create() was always failing with the EACCES
(permission denied) error code. It was because mmap() was requesting
prot =
libnvmm: Fix mmap() failure with 'permission denied'
The mmap() in nvmm_vcpu_create() was always failing with the EACCES
(permission denied) error code. It was because mmap() was requesting
prot = PROT_READ|PROT_WRITE and flags = MAP_SHARED, but the fd was
opened with O_RDONLY (or O_WRONLY in nvmm_root_init()) and thus
disallowed such a mmap request.
Fix this issue by opening the nvmm fd with O_RDWR flag. This also
requires to change the mode of '/dev/nvmm' from 0640 to 0660.
However, this makes root owner distinguishing in nvmm kernel module
useless. So change to identify root owner by checking whether the
caller has root privilege.
In addition, refactor nvmm_root_init() to also check for root privilege
first and then call nvmm_init().
show more ...
|
| fe440732 | 07-Jul-2021 |
Sascha Wildner <saw@online.de> |
mknod(2): Allow for the creation of fifos with mknod() to satisfy POSIX.
Calling mknod() and mknodat() with S_IFIFO shall be equivalent to
calling mkfifo() and mkfifoat().
Note that we ignore 'dev'
mknod(2): Allow for the creation of fifos with mknod() to satisfy POSIX.
Calling mknod() and mknodat() with S_IFIFO shall be equivalent to
calling mkfifo() and mkfifoat().
Note that we ignore 'dev' if S_IFIFO is passed, like Linux does, but
different from what {Free,Net,Open}BSD do, which require it to be 0.
It's true that the standard leaves anything but 0 undefined for this
case but also note the standard's example which does indeed pass a
'dev' arg and doesn't take any precautions of initializing it:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/mknod.html#tag_16_328_06
I don't think it makes any difference in practice, though.
Reported-by: DanDan
While here, fix the manual page's HISTORY a bit (taken from FreeBSD).
show more ...
|
| feaf0601 | 27-Jun-2021 |
Sascha Wildner <saw@online.de> |
libdevinfo: Remove enum devinfo_state (duplicate of enum device_state).
For maintenance reasons, use <sys/bus.h> defintions.
Taken-from: FreeBSD
While here, adjust the manual page to show the corr
libdevinfo: Remove enum devinfo_state (duplicate of enum device_state).
For maintenance reasons, use <sys/bus.h> defintions.
Taken-from: FreeBSD
While here, adjust the manual page to show the correct type of dd_state.
show more ...
|
| 8afbe037 | 24-Jun-2021 |
Matthew Dillon <dillon@apollo.backplane.com> |
pthreads - Improve low level lock performance when heavily contested
* The low-level __thr_umtx_lock()/unlock and related primitives are
used by pthreads, but have very poor performance when heavi
pthreads - Improve low level lock performance when heavily contested
* The low-level __thr_umtx_lock()/unlock and related primitives are
used by pthreads, but have very poor performance when heavily contested:
* Calling sched_yield() just doesn't work well.
* Attempts to sleep too quickly, which costs a great deal of
system overhead.
* And issues broadcast wakeups for waiters, causing excessive IPIs.
* Stop calling sched_yield() in the loop. Let the userland scheduler's
dynamic priority deal with it.
* Scale the spin count up significantly, and then further based on
the number of pthreads in the application. If the program is stupid
enough to cause excessive contention, then the penalty for making that
perform well is going to be more cpu time.
* Issue a wakeup1() equivalent on unlock if there are any waiters,
significantly reducing system IPIs.
To make this work reliably, the primary lock loop, when it sleeps,
will now always do so with a 1mS timeout, then loop/recheck. If
an API timeout is specified in excess of 1mS, the timo variable
is reduced on each loop and proper timeout handling occurs on
the last call.
* Running qemu w/ 32-cores specified (on a 64/128 threadripper host),
with nvmm, reduces build-all time from 9:10 to 8:20, relative to
a native host build time (usched restricted to 32 cores) of 6:11.
So this is a significant improvement.
(currently qemi-6.0.0 w/nvmm has some significant contention when a
high cpu count is configured, due to the implementation).
show more ...
|