From owner-freebsd-current@freebsd.org Fri Mar 1 13:03:04 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CE571516A5C for ; Fri, 1 Mar 2019 13:03:04 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8961E7770E; Fri, 1 Mar 2019 13:03:03 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x21D31p2061413; Fri, 1 Mar 2019 05:03:01 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x21D31Fl061412; Fri, 1 Mar 2019 05:03:01 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903011303.x21D31Fl061412@pdx.rh.CN85.dnsmgr.net> Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd In-Reply-To: To: John Baldwin Date: Fri, 1 Mar 2019 05:03:01 -0800 (PST) CC: sgk@troutmask.apl.washington.edu, Conrad Meyer , freebsd-current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 8961E7770E X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.96 / 15.00]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.85)[0.854,0]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.69)[0.688,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: pdx.rh.CN85.dnsmgr.net]; NEURAL_SPAM_LONG(0.52)[0.519,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.01)[ip: (0.06), ipnet: 69.59.192.0/19(0.03), asn: 13868(0.01), country: US(-0.07)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 13:03:04 -0000 > 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? > >> 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.) -- Rod Grimes rgrimes@freebsd.org