Date: Mon, 13 Sep 2021 06:21:15 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 254513] virtio_random: random_harvestq spinning on a CPU with Q35 virtio random device Message-ID: <bug-254513-27103-yOgv16C79D@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-254513-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-254513-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254513 Kyle Evans <kevans@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bryanv@FreeBSD.org, | |cem@freebsd.org, | |jmg@FreeBSD.org, | |jrtc27@freebsd.org, | |kevans@freebsd.org, | |markm@FreeBSD.org --- Comment #17 from Kyle Evans <kevans@freebsd.org> --- (In reply to Chris Collins from comment #16) Can you provide details on the host here? I'm a little curious if qemu is configure to use a non-default backend for entropy, and what kernel version it's running. According to https://wiki.qemu.org/Features/VirtIORNG, the default is /dev/random which may block until more recent linux releases. I'm wondering= if we're depleting the host's /dev/random with our (10hz?) polling, frequently leaving us stuck in a tight spin here: https://cgit.freebsd.org/src/tree/sys/dev/virtio/virtqueue.c?h=3Dreleng/13.= 0#n605 -- CC'ing some csprng@ folks and some virtio folks. I wonder if it would make sense to add an optional timeout parameter to virtqueue_poll() so that rng doesn't get stuck if vtrnd can't currently contribute to the pool. --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-254513-27103-yOgv16C79D>