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_at_ 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_at_ has talked to some stakeholders already (including you) which has already resulted in some changes to what core_at_ is considering to propose to developers. However, it is ultimately core_at_ who makes tiering decisions. -- John BaldwinReceived on Fri Mar 01 2019 - 16:07:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC