lkml.org 
[lkml]   [2017]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 1/2] x86/unwind: add ORC unwinder
On Thu, Aug 10, 2017 at 09:09:03AM -0500, Josh Poimboeuf wrote:
> static inline notrace unsigned long arch_local_save_flags(void)
> {
> return PVOP_CALLEE0(unsigned long, pv_irq_ops.save_fl,
> "pushfq; popq %rax", CPU_FEATURE_NATIVE,
> "call __raw_callee_save_xen_save_fl", CPU_FEATURE_XEN,
> "call __raw_callee_save_vsmp_save_fl", CPU_FEATURE_VSMP,
> "call __raw_callee_save_lguest_save_fl", CPU_FEATURE_LGUEST);
> }

Just a few clarifications on this idea:

It would probably be better to have the PVOP macros do the function name
translation, so maybe it would be something like this instead:

return PVOP_CALLEE0(unsigned long, pv_irq_ops.save_fl,
"pushfq; popq %rax", CPU_FEATURE_NATIVE,
xen_save_fl, CPU_FEATURE_XEN,
vsmp_save_fl, CPU_FEATURE_VSMP,
lguest_save_fl, CPU_FEATURE_LGUEST);

One issue is that it would fail to link if CONFIG_XEN or
CONFIG_LGUEST_GUEST isn't set. However I've seen some crazy macro magic
which lets you detect the number of variable arguments. So if we got
that to work, it could be:

return PVOP_CALLEE0(unsigned long, pv_irq_ops.save_fl,
"pushfq; popq %rax", CPU_FEATURE_NATIVE,
#ifdef CONFIG_XEN
xen_save_fl, CPU_FEATURE_XEN,
#endif
vsmp_save_fl, CPU_FEATURE_VSMP,
#ifdef CONFIG_LGUEST_GUEST
lguest_save_fl, CPU_FEATURE_LGUEST,
#endif
);

And then maybe the PVOP_CALL macros could detect the number of arguments
and call the corresponding version of ALTERNATIVE_X. Macro fun :-)

> Which would eventually translate to something like:
>
> asm volatile(ALTERNATIVE_4("call *pv_irq_ops.save_fl",
> "pushfq; popq %rax", CPU_FEATURE_NATIVE,
> "call __raw_callee_save_xen_save_fl", CPU_FEATURE_XEN,
> "call __raw_callee_save_vsmp_save_fl", CPU_FEATURE_VSMP,
> "call __raw_callee_save_lguest_save_fl", CPU_FEATURE_LGUEST
> : ... pvop clobber stuff ... );
>
> where ALTERNATIVE_4 is a logical extension of ALTERNATIVE_2 and
> CPU_FEATURE_NATIVE would always be set.
>
> It might need some more macro magic, but if it worked I think it would
> be a lot clearer than the current voodoo.
>
> Thoughts?

--
Josh

\
 
 \ /
  Last update: 2017-08-10 16:43    [W:0.273 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site