nksingh (None.delete@this.none.non) on September 17, 2021 12:23 pm wrote:
> Doug S (foo.delete@this.bar.bar) on September 17, 2021 11:35 am wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 17, 2021 8:59 am wrote:
> > > The most complicated case I see does come from the "three instructions" thing: making
> > > sure it's doing everything properly if they done individually. And "done individually"
> > > happens for the "restart for exceptions or interrupts" case, even if the instructions
> > > are right next to each other in the right order in the instruction stream.
> >
> >
> > I'm curious to see the full information on these instructions when available, in particular
> > what the limit of num_bytes is and whether/how overlapping ranges are supported.
> >
> > There is clearly going to be a need to handle multiple
> > in progress mem* instructions, as the scheduler could
> > task switch a process in the middle of a instruction, the next process starts another that gets interrupted
> > and so forth. And that's even beyond having one of these
> > instructions executing in the kernel and an interrupt
> > is raised and the interrupt handler starts another. That
> > means the state information for in flight instructions
> > will have to be saved on the stack - opening another line for potential stack based attacks.
> >
> > I'm also curious if the ISA will address mem* instructions on multiple cores with overlapping range.
> > I know, that's a "doctor it hurts when I do that" scenario which can also happen if you use ordinary
> > library mem* functions, so who cares right? Imposing some sort of ISA limit on that by e.g. range
> > checking against currently in flight mem* instructions
> > might free up some longer term future implementations
> > to get clever with external blocks or logic built into cache that might otherwise be impossible.
> > A cleaner ISA that prevents more than one mem* instruction operating on the same range of memory
> > at the same time might not be a bad idea IMHO, even if it required some extra housekeeping to enforce.
> > The "three instructions" thing would seem to complicate that, though.
>
> From the exclamation points in the mnemonic description, I assume the state needed
> for resume is stored by updating the src, dst, and cnt registers. So it just looks
> like a normal instruction to the os with state in the existing registers.


I'm not familiar with ARM assembly notation (and haven't written any assembly in any language for many years) so I didn't really notice the exclamation points or understand their significance. Indeed that would make the most sense as the easiest way to handle that detail. Basically the same as if a normal was run using those registers. Thanks for the clarification!