One last addendum, and then I'm going to bang my head against a wall
or something.


mycroft@MIT.EDU (Charles M. Hannum) writes:

> 
> Using the RF flag, though, we could also fix the BSDI hack to not have
> the original caveats.  If RF is set, we know that a particular
> instruction caused the fault, and we can always decode it to decide
> what to do:

Actually, that isn't quite true.  RF is always set when we get the
page fault.  It turns out there's no way to distinguish a real trace
trap from an INT 1 or ICEBP/INT01, and that full decoding of the BOUND
instruction is not necessary because the saved PC points to the BOUND
instruction itself.  Incorporating only these two changes, the
processing rules I suggested would be more correctly stated as:

* If the page fault was outside the IDT, or was due to user mode
access to the IDT (i.e. the U bit is set in the error code), process
it as a normal page fault.

* If the page fault was for vector 1, turn off the RF flag, and enter
the trace trap handler.

* If the page fault occured at an INT instruction:

  * If we're in VM86 mode, enter the protection fault handler.  (This
  should never happen, since we should have gotten a protection fault
  from the hardware.)

  * If the page fault was for vectors 3, 4 or 5, or came from kernel
  space, advance the PC (always 2 bytes + prefixes) past the
  instruction, turn off the RF flag, and enter the handler for that
  exception.

  * If the page fault was for vectors 0, 2 or 6, and came from user
  space, enter the protection fault handler.

* If the page fault occured at a different instruction:

  * If the page fault was for vectors 3 or 4, advance the PC (always 1
  byte + prefixes) past the instruction, turn off the RF flag, and
  enter the handler for that exception.

  * If the page fault was for vectors 0, 2, 5 or 6, enter the handler
  for that exception.

This leaves two semantic differences when the workaround is active,
neither of which is serious:

* INT 1 and ICEBP/INT01 will cause a trace fault (*not* a trace trap)
rather than a protection fault.

* In a SMP system, it's possible that the instruction could be
modified while it's being inspected by the page fault handler.  In
this event, the code may do the wrong fixup, causing the wrong type of
exception to be delivered.

Note that the code that scans the instruction prefixes and looks for
the first byte of the instruction needs to be careful to check for the
end of the segment and limit how far it searches; otherwise it might
be possible for another processor in a SMP system to modify the
instruction sequence in such a way that the processor that took the
original page fault gets stuck in a loop or runs off the end of a
segment.