Received-SPF: pass (google.com: domain of linux-kernel+bounces-208137-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240608193504.429644-2-torvalds@linux-foundation.org>
 <CAHk-=wjiJvGW70_A93oN_f48J0pn4MeVbWVmBPBiTh2XiSpwpg@mail.gmail.com> <CAHk-=wiPSnaCczHp3Jy=kFjfqJa7MTQg6jht_FwZCxOnpsi4Vw@mail.gmail.com>
In-Reply-To: <CAHk-=wiPSnaCczHp3Jy=kFjfqJa7MTQg6jht_FwZCxOnpsi4Vw@mail.gmail.com>
From: Ard Biesheuvel <ardb@kernel.org>
Date: Mon, 10 Jun 2024 14:10:59 +0200
Message-ID: <CAMj1kXHyhv=J0v9eZKOgLd0xySrZmvnzmD=Oz398C5KS2=48Kw@mail.gmail.com>
Subject: Re: [PATCH] x86: add 'runtime constant' infrastructure
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, 
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-arch <linux-arch@vger.kernel.org>, 
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Content-Type: text/plain; charset="UTF-8"

On Sun, 9 Jun 2024 at 05:11, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sat, 8 Jun 2024 at 13:55, Linus Torvalds
> <torvalds@linux-foundation.org> 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.