From owner-freebsd-current@freebsd.org Fri Mar 1 17:07:08 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 0C8DE151E223 for ; Fri, 1 Mar 2019 17:07:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A318188DB4; Fri, 1 Mar 2019 17:07:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 2858F1B367; Fri, 1 Mar 2019 17:07:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: "Rodney W. Grimes" Cc: sgk@troutmask.apl.washington.edu, Conrad Meyer , freebsd-current References: <201903011303.x21D31Fl061412@pdx.rh.CN85.dnsmgr.net> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <96826e2a-030d-fa09-6739-13897e2834a4@FreeBSD.org> Date: Fri, 1 Mar 2019 09:06:44 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <201903011303.x21D31Fl061412@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A318188DB4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.94 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_SHORT(-0.94)[-0.938,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] 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 17:07:08 -0000 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