NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
port-xen/53267: XEN amd64 DomU (Dom0??) NetBSD current USERMODE() fails
>Number: 53267
>Category: port-xen
>Synopsis: XEN amd64 DomU (Dom0??) NetBSD current USERMODE() fails
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: port-xen-maintainer
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon May 07 12:30:00 +0000 2018
>Originator: Robert Elz
>Release: NetBSD 8.99.14 (and later, probably earlier too).
>Organization:
>Environment:
System: NetBSD netbsd.noi.kre.to 8.99.16 NetBSD 8.99.16 (MUNNARI-DomU) #312: Mon May 7 18:38:30 ICT 2018 kre%onyx.coe.psu.ac.th@localhost:/usr/obj/testing/kernels/amd64/MUNNARI-DomU amd64
Architecture: x86_64
Machine: amd64
>Description:
Bear with me if I get the technical details slightly incorrect...
The USERMODE() macro is used to determine whether a trap
frame (the saved state from before the trap) represents
user or system mode.
Among other things, it is used (via CLKF_USERMODE()) to
decide whether to attribute ticks to user time or system
time.
On Xen DomU (on NetBSD current, 8.0_RC1 is OK) USERMODE()
always returns false, so all ticks are counted as system
time.
Aside from simply being wrong, one thing this affects is
cgdconfig -g which increases the amount of work is required
for key generation until it takes (what it considers to be)
a reasonable time - it does this by measuring the CPU time
used (in user mode) for each test, and while it is
insufficient, increase the amount of work, and try again.
Since (after the first tick) the user mode time is always
zero on Xen DomU, this loops forever (doing more and more
work on each iteration.) I guess it would eventually
run out of RAM or something, but that would take a long
time to happen, so "forever" is close enough...
>How-To-Repeat:
On a NetBSD current (amd64 at least, probably i386 as well)
DomU try
cgdconfig -g -o /tmp/whatever aes-cbc 192
(which is, aside from the output file name, the
canonical first step when configuring a new CGD).
Don't expect to be patient enough to wait for it to
finish (it is safe, no problem killing it with SIGINT
or other ways, it is just doing more and more CPU calcs,
and checking usage.)
>Fix:
???
Home |
Main Index |
Thread Index |
Old Index