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