Date: Fri, 1 Mar 2019 09:06:44 -0800 From: John Baldwin <jhb@FreeBSD.org> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: sgk@troutmask.apl.washington.edu, Conrad Meyer <cem@freebsd.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd Message-ID: <96826e2a-030d-fa09-6739-13897e2834a4@FreeBSD.org> In-Reply-To: <201903011303.x21D31Fl061412@pdx.rh.CN85.dnsmgr.net> References: <201903011303.x21D31Fl061412@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/1/19 5:03 AM, Rodney W. Grimes wrote: >> On 2/28/19 10:32 AM, Steve Kargl wrote: > ( ... trimmed ... ) > >>> The BIOS does have a enable/disable button for virtualization. >>> During the great drm-legacy-kmod event of the last month, enabling >>> virtualization locks up a i386 FreeBSD kernel very quickly. >>> Perhaps, virtualization works under amd64. Guess I'll burn >>> an image onto a memstick an d give it a whirl. >> >> bhyve is definitely amd64-only. We don't have any support for bhyve on i386 >> kernels and likely never will. However, if an i386 chroot works, it's probably >> faster than an i386 VM anyway. > > bhyve/vmm.ko does not come into play here at all, the real question > is why does our i386 kernel "lock up" simply because a newer CPU > feature appears, it should not do that, as far as I am aware turing > VT-x on does not or should not in anyway change the "i386" behavior > or a machine. What am I missing? I think we don't know enough about this bug report to know what causes the hang. >>>> However, an amd64 kernel is going to be a more stable, better >>>> supported kernel for running i386 binaries than an i386 kernel >>>> at this point, and that will become even more true in the future. >>> >>> This is interesting as well. Does this mean that amd64 is now >>> the only tier 1 platform and all other architectures are after >>> thoughts? >> >> i386 is still marked as tier 1. However, it's becoming increasingly harder to >> maintain that level of support for the kernel. core@ is currently exploring >> some ideas about how to make our tiering for i386 more closely reflect what we >> as a project are able to provide. Originally we were considering a proposal to >> demote all of i386 to tier 2, but after some initial conversations we think a >> better model is to keep the i386 user ABI as tier 1 and only demote the i386 >> kernel. However, we still need to think about what that looks like and update >> our tiering language to reflect what that looks like. I think the short version >> is that we might no longer guarantee i386-specific fixes for kernel SAs, but >> there are probably additional wrinkles that will arise as that is fleshed out >> further. > > Is core talking to the stake holders about this issue? IMHO this topic > should be an open discussion some place with all parties involved, not > just core deciding what is or is not a tier 1 and/or how to fix our > tier 1 situation with i386 (which I do agree needs to change, but > to what I have not a solid idea.) As you are well aware, core@ has talked to some stakeholders already (including you) which has already resulted in some changes to what core@ is considering to propose to developers. However, it is ultimately core@ who makes tiering decisions. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?96826e2a-030d-fa09-6739-13897e2834a4>