Re: rng padlock changes causes NetBSD to crash

[Andrius V <vezhlys%gmail.com@localhost>]

Yes, I've read that padlock design is not elegant at all and true, I
don't think so that we will see it redesigned anymore... Though I
didn't expect that it might be any difference between i386 and amd64
kernels but after your explanation it makes sense. I have a bit more
limited access to nano devices so I just used i386 kernel to all of
them when I had a chance. Thank you for the fix.

On Thu, Feb 16, 2017 at 5:04 PM, Thor Lancelot Simon <tls%panix.com@localhost> wrote:
> On Thu, Feb 16, 2017 at 01:04:33PM +0200, Andrius V wrote:
>> Hi,
>>
>> I have tested the fix.  lcr4(rcr4() | CR4_OSFXSR); helps indeed and
>> system boots but if statement seems to be not correct, at least on
>> VT-310DP board it ended up in the same error.
>
> I checked in an unconditional version of the fix.
>
> It's interesting to note (again as pointed out by jak@) 64 bit
> kernels would not have had this problem, since they enable SSE
> very early in CPU startup.
>
> The underlying hardware cause for this seems to also be why we
> must mess with the coprocessor enables in CR0 before calling
> any ACE/RNG instructions -- in Jonathan's testing, even a single
> call to xstorerng causes a coprocessor (DNA) fault if the FPU's
> off.  Unfortunate, since all that monkeying around (interrupt
> disable, turn off preemption, whack coproc regs) increases the
> cost of getting 8 random bytes by a factor of at least 10.
>
> The VIA manual suggests they intended to move PadLock out of
> the FPU in later designs but I think at this point it is
> fairly clear there won't be any of those.
>
> Thor