Re: Fwd: newb question : list of elligible computers to debian-68k

[Brad Boyer <flar@allandria.com>]

On Thu, Oct 16, 2008 at 06:54:46PM +1100, Finn Thain wrote:
> On Wed, 15 Oct 2008, Brad Boyer wrote:
> > I will note that this bug is known to affect the line-A trap that the 
> > classic Mac system uses for system calls. Apple had a workaround for 
> > this bug for line-A but not for FPU emulation.
> 
> I wonder why. Is it not possible to distinguish a false ATC fault from an 
> unimplemented FP instruction exception?

We definitely know what type of fault happened. The only reason I can
come up with that the A-line trap would be easier to fixup is that the
exception frame for that is simpler than the unimplemented FP
instruction exception frame. However, it's possible that Apple just
didn't fix it because they didn't care. They recommended that any
software detect the presence of the FPU and only use real FP opcodes
if the chip had real hardware. There was a software floating point
library that was to be used instead of opcode emulation.

I guess what Apple does is detect this special case of ATC fault, then
if the bad instruction is one it knows how to fixup it manually creates
the instruction emulation stack frame and does the emulation followed
by the page fault code for the missing page. I believe an ATC fault
would normally just cause the next page to be loaded.

> > ...it should cause both the emulation trap and the page fault on a good 
> > CPU. If you miss one, it's a broken CPU. It would most likely need to be 
> > done in an isolated thread to be safe.
> 
> I think we could just create a special initrd for the purpose and let the 
> ATC fault kill the box. Not sure how to arrange for the correct page to be 
> non-resident when you do this from userspace (is demand paging always done 
> one page at-a-time?). But if you use an FPU op to generate the fault, and 
> run it under an FPU emulation, it shouldn't kill any interesting boxes 
> (i.e. no bug, bug + FPU).

That should work for investigation. Ideally we would have a runtime test
that we could add to the kernel the way the x86 kernel tests for all the
various intel bugs like the F00F bug and the Pentium fdiv bug.

I think the demand paging is one page at a time, but I don't understand
the memory management code well enough to be sure. Perhaps someone else
can comment on that.

	Brad Boyer
	flar@allandria.com