On Tue, Aug 08, 2017 at 01:09:08PM -0700, Andy Lutomirski wrote: > >> c) just add ORC data for the alternative statically and _unconditionally_. > >> > >> No runtime registration. Just an unconditional entry for the > >> particular IP that comes after the "pushfq". It cannot match the > >> "callq" instruction, since it would be in the middle of that > >> instruction. > >> > >> Basically, just do a "union" of the ORC data for all the alternatives. > >> > >> Now, objtool should still verify that the instruction pointers for > >> alternatives are unique - or that they share the same ORC unwinder > >> information if they are not. > >> > >> But in cases like this, when the instruction boundaires are different, > >> things should "just work", with no need for any special cases. > >> > >> Hmm? > > > > Yeah, that might work. Objtool already knows about alternatives, so it > > might not be too hard. I'll try it. > > But this one's not an actual alternative, right? It's a pv op. Ah, right. Objtool doesn't know about paravirt patching, unfortunately. > I would advocate that we make it an alternative after all. I frickin' > hate the PV irq ops. It would like roughly like this: > > ALTERNATIVE "pushfq; popq %rax", "callq *pv_irq_ops.save_fl", > X86_FEATURE_GODDAMN_PV_IRQ_OPS > > (The obvious syntax error and the naming should probably be fixed. > Also, this needs to live in an #ifdef because it needs to build on > kernels with pv support. It should also properly register itself as a > pv patch site.) Yeah, that would be really nice, assuming it's possible. Otherwise I'll need to teach objtool about the paravirt patches. -- Josh -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
