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",
> (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.