Re: hppa lazy FPU switching and QEMU bugs
Thor Lancelot Simon <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.crypto |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Aug 05, 2026 at 10:34:13AM +0200, Martin Husemann wrote: > > Is the "assisted emulation" just an optimization and we could fall back > to completely disabling FPU if running under qemu? No, we disable the FPU after context switch as a way to implement lazy FPU switching _on hardware_, too. When the next process tries to use the FPU, we get a trap and save the FPU state. Obviously if the architecture didn't consider any use of the FP regs to be "use of the FPU" this would be totally unsafe, but it does. Unfortunately QEMU lies - it claims to support coprocessor disable but it never checks and never generates the trap. So processes get their FP regs switched with each other, and since *integer* multiply uses the FP regs on PA, that's even worse than you'd expect. The right fix is to eagerly switch the FP regs. I have a 150 line change with a bunch of comments that probes to see if the trap works, and if not, always saves/restores the regs on context switch. But it is Claude-authored and our policy does not presently allow committing such code, so, I need to strip it down to the comments and rewrite. It will take me some time to do that, particularly as using the FP regs in the kernel on HPPA involves some trickery with GCC as we tell it we are not using the FPU when we compile. If someone else wants this sooner, I can strip the code, leaving the comments, and you can do the black-box exercise I would have done. -- Thor Lancelot Simon [email protected] "Indeed, someone who is a citizen in a democracy is often not one in an oligarchy." - Aristotle, Politics III.1