On 13.11.20 18:34, Andy Lutomirski wrote:
On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper <[email protected]> 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
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature

