Date: Tue, 03 Sep 2019 14:07:52 -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>