Re: More on the pentium workaround - the gotchas

Hans Lermen (
Mon, 17 Nov 1997 19:27:16 +0100 (MET)

On Mon, 17 Nov 1997, Ingo Molnar wrote:

> disassemble _one byte_ without extreme prejudice. Mark's solution really
hmm, I obviously missed this information.
Could you please FWD it to me ? (private mail)

> seems to be the most robust one, with the small extension that 'trap #1'
> (hw debug trap) _has_ to point to after the trapping instruction as well

Well, this doesn't hurt us atall: you need _not_ to fixup eip for that
(hence interpretation of the code isn't necessary), because:

The trap #1 can be triggered for the following cases:

- Instruction breakpoint fault (DRx caused)

without F00F-fix: pointing _to_ the instruction.
_with_ F00F-fix: dito

What we should eventually fiddle with is just the RF flag,
but as the processor does the handling of this on _return_ of
of the exception, we have not to handle this _before_ calling

- Data memory and I/O breakpoints (DRx caused)

without F00F-fix: pointing _after_ the instruction, that caused
the exception.
_with_ F00F-fix: The exception is scheduled _after_ the instruction
and therefore the page fault too (fortunately).
hence: just what we need, no fixup needed.

- General detect fault (DRx caused)

We can skip that, because its only used in conjunction with
in-circuit emulators.

- Singe step trap (the 'classic' INT1)

In both cases (with or without the F00F fix) the exception happens
_after_ the instruction that was executed with TF set in eflags.
Hence no fixup needed.

- Task switch trap. ( caused by T-bit in the TSS )

Along my knowledge of the kernel, this won't happen, because we are
not using machine type taskswitches to switch context
(correct me if I'm wrong). Atleast, I did not find the places in the
kernel were we fiddle with the T bit of the TSS (Linus ?).
... and we should, if this is of concern.