Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

From: John Baldwin <jhb_at_FreeBSD.org>
Date: Fri, 1 Mar 2019 09:06:44 -0800
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 Baldwin
Received 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