Re: [PATCH] x86: add 'runtime constant' infrastructure

[Ard Biesheuvel]

On Sun, 9 Jun 2024 at 05:11, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Sat, 8 Jun 2024 at 13:55, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Think of this patch mostly as a "look, adding another architecture
> > isn't *that* hard - even if the constant value is spread out in the
> > instructions".
>
> .. and here's a version that actually works. It wasn't that bad.
>
> Or rather, it wouldn't have been that bad had I not spent *ages*
> debugging a stupid cut-and-paste error where I instead of writing
> words 0..3 of the 64-bit large constant generation, wrote words 0..2
> and then overwrote word 2 (again) with the data that should have gone
> into word 3. Causing the top 32 bits to be all wonky. Oops. Literally.
>
> That stupid typo caused like two hours of wasted time.
>
> But anyway, this patch actually works for me. It still doesn't do any
> I$/D$ flushing, because it's not needed in practice, but it *should*
> probably do that.
>

arm64 already has so-called 'callback' alternatives that allow the
patching logic for a particular alternative sequence to be implemented
by the user of the API.

A callback implementation to patch a movz/movk sequence already
exists, in arch/arm64/kvm/va_layout.c, used by
kvm_get_kimage_voffset() and kvm_compute_final_ctr_el0().

>From inline asm, it gets called like this

static inline size_t __invalidate_icache_max_range(void)
{
  u8 iminline;
  u64 ctr;

  asm(ALTERNATIVE_CB("movz %0, #0\n"
                     "movk %0, #0, lsl #16\n"
                     "movk %0, #0, lsl #32\n"
                     "movk %0, #0, lsl #48\n",
                     ARM64_ALWAYS_SYSTEM,
                     kvm_compute_final_ctr_el0)
      : "=r" (ctr));

  iminline = SYS_FIELD_GET(CTR_EL0, IminLine, ctr) + 2;
  return MAX_DVM_OPS << iminline;
}

This one gets patched after SMP bringup, but they can be updated
earlier if needed.

Doing the same for the immediate field in a single ALU instruction
should be straight-forward, although this particular example doesn't
even bother, and just masks and shifts the result of the movz/movk
sequence.