Messages in this thread | | | Subject | Re: WARNING: can't access registers at asm_common_interrupt | From | Jürgen Groß <> | Date | Mon, 16 Nov 2020 12:56:32 +0100 |
| |
On 13.11.20 18:34, Andy Lutomirski wrote: > On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper > <andrew.cooper3@citrix.com> wrote: >> >> On 11/11/2020 20:15, Josh Poimboeuf wrote: >>> On Wed, Nov 11, 2020 at 09:07:30PM +0100, Peter Zijlstra wrote: >>>> On Wed, Nov 11, 2020 at 01:59:00PM -0600, Josh Poimboeuf wrote: >>>>> On Wed, Nov 11, 2020 at 08:42:06PM +0100, Peter Zijlstra wrote: >>>>>>> Would objtool have an easier time coping if this were implemented in >>>>>>> terms of a static call? >>>>>> I doubt it, the big problem is that there is no visibility into the >>>>>> actual alternative text. Runtime patching fragments into static call >>>>>> would have the exact same problem. >>>>>> >>>>>> Something that _might_ maybe work is trying to morph the immediate >>>>>> fragments into an alternative. That is, instead of this: >>>>>> >>>>>> static inline notrace unsigned long arch_local_save_flags(void) >>>>>> { >>>>>> return PVOP_CALLEE0(unsigned long, irq.save_fl); >>>>>> } >>>>>> >>>>>> Write it something like: >>>>>> >>>>>> static inline notrace unsigned long arch_local_save_flags(void) >>>>>> { >>>>>> PVOP_CALL_ARGS; >>>>>> PVOP_TEST_NULL(irq.save_fl); >>>>>> asm_inline volatile(ALTERNATIVE(paravirt_alt(PARAVIRT_CALL), >>>>>> "PUSHF; POP _ASM_AX", >>>>>> X86_FEATURE_NATIVE)
I am wondering whether we really want a new feature (basically "not XENPV). We could use ~X86_FEATURE_XENPV and teach apply_alternatives() to understand negated features (yes, this limits the number of features to 32767, but I don't think this is a real problem for quite some time).
Thoughts?
Juergen [unhandled content-type:application/pgp-keys][unhandled content-type:application/pgp-signature] | |