From owner-freebsd-current@freebsd.org Thu Feb 28 19:43:18 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 6D3C215159B1 for ; Thu, 28 Feb 2019 19:43:18 +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 13C3984A41; Thu, 28 Feb 2019 19:43:18 +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 84499127D4; Thu, 28 Feb 2019 19:43:17 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: sgk@troutmask.apl.washington.edu Cc: Conrad Meyer , freebsd-current References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> 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: Date: Thu, 28 Feb 2019 11:43:01 -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: <20190228183214.GA17372@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 13C3984A41 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.95 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.96)[-0.955,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: Thu, 28 Feb 2019 19:43:18 -0000 On 2/28/19 10:32 AM, Steve Kargl wrote: > On Thu, Feb 28, 2019 at 09:09:38AM -0800, John Baldwin wrote: >> You can do all your tests directly on amd64 by just adding >> "-m32" to compile i386 binaries against the libraries in /usr/lib32 >> and you will generate the same i386 binaries as if you were building >> on an i386 system. If you are a bit more paranoid, you can install >> an i386 world and chroot into it and use that to test i386. I do this >> myself (-m32) for testing i386 things. I also run i386 VMs under >> bhyve on amd64 hosts. I'm not sure your laptop's CPU can run i386 >> VMs though, and you don't need a VM to test userland-only changes >> (I'm usually trying to test kernel changes). > > Interesting. Did not know I could use -m32 with any reliability. > Setting up my testing environment may be a challenge as I use > mpfr/gmp, so would need -m32 aware versions of those libraries. > I normally install whatever the port collection offers for mpfr/gmp. > I suppose I would need to install those independently to get > multilib support. I would also need to compile 2 versions of my > testing framework (ie., additional support library). -m32 didn't used to work in early amd64 (like 6.x or maybe 7.x), but it has worked reliably for several branches now. That said, if you want to use i386 packages, I think a chroot is probably a safer route as in the chroot you can use pkg to install i386 packages just as if it was an i386 machine. > 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. >> 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. -- John Baldwin