S/G insn interruptibility

[Beulich__Jan]

Hello,

the instruction pages for these insns talk about "suspension by an exception" and delivery of possible traps/interrupts "in lieu of the exception". In a strict reading of the wording, this suggests to me that without any exception these instructions aren't interruptible. But the way they work, I wouldn't rule this out. My questions therefore are

1) If there's no exception on any element, can e.g. an external interrupt be serviced half way through the execution of such an instruction (as it's restartable in general)?

2) I can see how delivery of interrupts in lieu of an exception on a "later" element could happen, but I'm having difficulty understanding the trap part of that sentence: Traps are exceptions which occur after an instruction has completed, and hence should strictly occur only after any faults, and with RIP already pointing at the next insn. Taking the example of single step traps, would that mean that prior to the delivery of e.g. #GP or #PF on a "later" element, #DB would occur (and then for the instruction as a whole perhaps up to number-of-elements minus one times too often)?

Thanks, Jan

[MarkC_Intel]

Hi Jan, S/G = Scatter/Gather for the uninformed. The instructions are restartable for page faults but not interruptable. They could be interruptable, but they are not on current implementations. 

We believe your #2 understanding is correct. #DB are reported before the next pagefault if any.

[Beulich__Jan]

But a #DB trap would have to be reported with an already advanced RIP (or else it wouldn't be a trap). Are you saying data breakpoints can be faults instead of traps in this specific case? If so, other parts of the SDM should probably call this out as exceptions as well.

It's also not clear to me whether you meant your reply to also apply to the single step case.

As to interruptability: If it's permissible for an implementation to allow interruption of these insns, could this be clarified on the instruction pages? It being permissible would allow me to leave the insn emulator in Xen unchanged, whereas with the current SDM wording I'd have to make non-trivial changes to it.

[MarkC_Intel]

Technically the #DB does not have to advance the RIP to the next instruction.  The definition of trap just says "The return address for the trap handler points to the instruction to be executed after the trapping instruction" --  And "after"  in this case is the same RIP as the instruction that took the #DB.  Yes, the Fault definition is a little more stretched since we are modifying registers (and memory for scatters): "the processor restores the machine state to the state prior to the beginning of execution of the faulting instruction." ... well we don't do that since we modify the destination register and mask register (for gathers)  or memory (for scatters). The special case is described in the instruction page description. The REP string ops would have to behave similarly, I think.  Single step is different; that occurs at the real end of the instruction execution. 

I don't fully understand your question/issue about interruptability.

[Beulich__Jan]

Comparing with REP string-ops is a little odd, because it is clear that REP means "repeated invocation of the given insn", and it is written down somewhere that there are insn boundaries between (some of) the iterations, but yes, I see what you're saying.

As to interruptability, perhaps I did add too much Xen context and hence managed to obfuscate the question. Earlier on you've said "They could be interruptable, but they are not on current implementations." My question is whether this statement could, in a suitable form, be added to the respective insn pages in the SDM. The way it's described there right now I don't think it really says this. It was really me reading more interruptability into it than it really says, and then basing our emulator implementation on this too wide interpretation of mine. But given your earlier reply I've got the impression that maybe the text could be relaxed to match my earlier interpretation.