Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Sep 2019 14:07:10 -0000
From:      John Baldwin <jhb@FreeBSD.org>
To:        rgrimes@freebsd.org
Cc:        Conrad Meyer <cem@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys
Message-ID:  <4d6b8a14-b053-9ed1-14b2-bbc359ac9413@FreeBSD.org>
In-Reply-To: <201904162251.x3GMp2aF097103@gndrsh.dnsmgr.net>
References:  <201904162251.x3GMp2aF097103@gndrsh.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 4/16/19 3:51 PM, Rodney W. Grimes wrote:
>> On 4/15/19 11:40 AM, Conrad Meyer wrote:
>> Note that I actually often run into unseeded systems when doing development
>> using qemu for non-x86 architectures.  For example, when booting mips from
>> qemu, there is no loader, the kernel just starts, and since the endian is
>> opposite, I frequently regenerate the filesystem using makefs.
> 
> Isnt this also the case for bhyveload?  We do not go through the loader
> there when we are starting a FreeBSD guest, correct?

bhyveload is effectively the loader in this case.  It runs the normal loader
scripts and logic and so would load the guests's /boot/entropy and pass it
to the guest kernel as metadata just like the regular loader.

In addition, bhyve also supports virtio-rng which is another way to provide
entropy to guest OS's.  That's why in my reply I focused on qemu for mips
(or riscv) as for x86 hypervisors there are existing, somewhat-standarized
solutions for the hypervisor to provide entropy to the guest.

-- 
John Baldwin





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4d6b8a14-b053-9ed1-14b2-bbc359ac9413>