On Tue, Sep 13, 2016 at 09:36:14AM +0100, Ard Biesheuvel wrote:
> On 7 September 2016 at 11:07, Mark Rutland <mark.rutl...@arm.com> wrote:
> > In some cases, one side of an alternative sequence is simply a number of
> > NOPs used to balance the other side. Keeping track of this manually is
> > tedious, and the presence of large chains of NOPs makes the code more
> > painful to read than necessary.
> >
> > To ameliorate matters, this patch adds a new alternative_else_nop_endif,
> > which automatically balances an alternative sequence with a trivial NOP
> > sled.
> >
> > In many cases, we would like a NOP-sled in the default case, and
> > instructions patched in in the presence of a feature. To enable the NOPs
> > to be generated automatically for this case, this patch also adds a new
> > alternative_if, and updates alternative_else and alternative_endif to
> > work with either alternative_if or alternative_endif.

[...]

> > +/*
> > + * Begin an alternative code sequence.
> >   */
> >  .macro alternative_if_not cap
> > +       .set .Lasm_alt_mode, 0
> 
> Given that only a single copy of this symbol will exist in an object
> file, is it still possible to use both variants in a single
> compilation/assembly unit?

Yes.

GAS allows the symbol to be set multiple times (so long as the
assignments are constant values). The last assignment "wins" when it
comes to output, but assembler macros are evaluated before this, and use
the most recent assignment.

In testing I hacked __kvm_call_hyp to use both:

        ENTRY(__kvm_call_hyp)
        alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
                str     lr, [sp, #-16]!
                hvc     #0
                ldr     lr, [sp], #16
                ret
        alternative_else_nop_endif
        alternative_if ARM64_HAS_VIRT_HOST_EXTN
                hvc     #0x539
        alternative_else_nop_endif
                b       __vhe_hyp_call
        ENDPROC(__kvm_call_hyp)

Which, according to objdump gives me the expected result:

        Disassembly of section .text:

        0000000000000000 <__kvm_call_hyp>:
           0:   f81f0ffe        str     x30, [sp,#-16]!
           4:   d4000002        hvc     #0x0
           8:   f84107fe        ldr     x30, [sp],#16
           c:   d65f03c0        ret
          10:   d503201f        nop
          14:   14000000        b       0 <__vhe_hyp_call>

        Disassembly of section .altinstr_replacement:

        0000000000000000 <.altinstr_replacement>:
           0:   d503201f        nop
           4:   d503201f        nop
           8:   d503201f        nop
           c:   d503201f        nop
          10:   d400a722        hvc     #0x539

Thanks,
Mark.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Reply via email to