On Thu, Jun 20, 2019 at 11:48:17AM -0700, Vineet Gupta wrote: > On 6/20/19 12:01 AM, Peter Zijlstra wrote: > > > > > In particular we do not need the alignment. > > > > So what the x86 code does is: > > > > - overwrite the first byte of the instruction with a single byte trap > > instruction > > > > - machine wide IPI which synchronizes I$ > > > > At this point, any CPU that encounters this instruction will trap; and > > the trap handler will emulate the 'new' instruction -- typically a jump. > > > > - overwrite the tail of the instruction (if there is a tail) > > > > - machine wide IPI which syncrhonizes I$ > > > > At this point, nobody will execute the tail, because we'll still trap on > > that first single byte instruction, but if they were to read the > > instruction stream, the tail must be there. > > > > - overwrite the first byte of the instruction to now have a complete > > instruction. > > > > - machine wide IPI which syncrhonizes I$ > > > > At this point, any CPU will encounter the new instruction as a whole, > > irrespective of alignment. > > > > > > So the benefit of this scheme is that is works irrespective of the > > instruction fetch window size and don't need the 'funny' alignment > > stuff. > > > > Now, I've no idea if something like this is feasible on ARC; for it to > > work you need that 2 byte trap instruction -- since all instructions are > > 2 byte aligned, you can always poke that without issue. > > We do have a 2 byte TRAP_S u6 which is used for all/any trap'ing: syscalls, > software breakpoint, kprobes etc. But using it like x86 seems a bit excessive for > ARC. Given that x86 doesn't implement flush_icache_range() it must have I$ > snooping D$ and also this machine wide IPI sync I$ must be totally under the hood > all hardware affair - unlike ARC which needs on_each_cpu( I$ line range). I always forget the exact details, but we do have to execute what is called a serializing instruction to flush CPU state and force it to re-read the actual instructions -- see sync_core(). > Using TRAP_S would actually requires 2 passes (and 2 rounds of IPI) for code > patching - the last one to undo the TRAP_S itself. Correct -- we do 3, like detailed in the other email. But we figured the actual poking of text is the slow path anyway. > I do worry about the occasional alignment induced extra NOP_S instruction (2 byte) > but there doesn't seem to be an easy solution. Heck if we could use the NOP_S / > B_S in first place. While not a clean solution by any standards, could anything be > done to reduce the code path of DO_ONCE() so that unlikely code is not too far off. if one could somehow get the arch_static_branch*() things to conditionally emit either the 2 or 4 byte jump, depending on the offset (which is known there, since we stick it in the __jump_table), then we can have arch_jump_label_transform() use that same condition to switch between 2 and 4 bytes too. I just don't know if it's possible :-/ _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
