From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E148BCAC59A for ; Thu, 18 Sep 2025 11:45:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YAwFBdszkBO6d7MbHepCgBJvepK+NBfoPcsBZLIJ4gg=; b=Z3rCEwv1K5HWDP79PPI6kuJ1dQ t+Cl0KYAePLFu1HQQRFAoyAk422WiWGtIqTnEcrCiB0rPGDKWTNLgQFWEyCooqOWNiOYOf9mBcu5s q+bzuiwZZwvUlYny2woj8qBViSpztuPbHhiGmeYsFcHBeaLaA4uryRzAuOiBt9F6wfWIUmQ+AsMry N2P96IeL9cThDTAlmxTPwtVk4r3lnZ9EcDKE1XWXcPqbWfqEDNmYVTc/INX1kk+ahguajIVWBuL1h Iewu7RlACXG0euyYXr/LTnb6zNoOaO73N6I93oVvmeI1SDS1RCJeWpJQUfJrJDs0BthGM8njtyGTR ONJJujhg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uzD4N-0000000HFhh-0ZOb; Thu, 18 Sep 2025 11:44:59 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uzD4K-0000000HFh6-1Lzb for linux-arm-kernel@lists.infradead.org; Thu, 18 Sep 2025 11:44:57 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id AFACB43BA2; Thu, 18 Sep 2025 11:44:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A819AC4CEE7; Thu, 18 Sep 2025 11:44:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1758195895; bh=QWckBIgmlhG9nD+7S9Y3qbN6qkWCXNxu5YXuWFjTx04=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=d+UYznhCrKg0d5IG5hVOnmPVAM3kvmQX3yzneTIhT9kT2rFDwt+iClT/JG9aigoVJ ka+Q/c6aRuLm6mz0qXvVxpbpamVmWa0ZV1UHZYZPOM7js43tnnjolt5OjSX5De0sPh YFinjk8aE/JyjtnM7KbTPIsvVgRYkHct5PEKTD0FdbqRZaZipqFgV+naZIwkKHAoiK vDsu40MAy2EPXPZeWRgWoM1ZMtU3hk8oACDORfPQb7oFNui70fUiJL5ZAAtuKpI4o/ IwH7xXY6T+zJ27AVcx+PHTSHIK7H3puCKUJLpV6BPRLRh/Tr+zApTBJi11+lpi+PMg 1oQ4W1AQR5uOw== Date: Thu, 18 Sep 2025 12:44:50 +0100 From: Will Deacon To: Ard Biesheuvel Cc: Ard Biesheuvel , linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Mark Rutland , Sebastian Andrzej Siewior , Peter Zijlstra , Catalin Marinas , Mark Brown Subject: Re: [PATCH v3 0/8] arm64: Make EFI calls preemptible Message-ID: References: <20250918103010.2973462-10-ardb+git@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250918_044456_402386_71C3F619 X-CRM114-Status: GOOD ( 31.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Sep 18, 2025 at 01:33:48PM +0200, Ard Biesheuvel wrote: > On Thu, 18 Sept 2025 at 12:30, Ard Biesheuvel wrote: > > > > From: Ard Biesheuvel > > > > The arm64 port permits the use of the baseline FP/SIMD register file in > > kernel mode, and no longer requires preemption to be disabled. Now that > > the EFI spec is being clarified to state that EFI runtime services may > > only use baseline FP/SIMD, the fact that EFI may code may use FP/SIMD > > registers (while executing at the same privilege level as the kernel) is > > no longer a reason to disable preemption when invoking them. > > > > This means that the only remaining reason for disabling preemption is > > the fact that the active mm is swapped out and replaced with efi_mm in a > > way that is hidden from the scheduler, and so scheduling is not > > supported currently. However, given that virtually all (*) EFI runtime > > calls are made from the efi_rts_wq workqueue, the efi_mm can simply be > > loaded into the workqueue worker kthread while the call is in progress, > > and this does not require preemption to be disabled. > > > > Note that this is only a partial solution in terms of RT guarantees, > > given that the runtime services execute at the same privilege level as > > the kernel, and can therefore disable interrupts (and therefore > > preemption) directly. But it should prevent scheduling latency spikes > > for EFI calls that simply take a long time to run to completion. > > > > Changes since v2: > > - Permit ordinary kernel mode FP/SIMD with IRQs disabled, so that the > > special EFI case only deals with invocations in hardirq or NMI context > > - Disallow EFI runtime calls in hardirq or NMI context, so that the > > special FP/SIMD handling for EFI can be dropped entirely > > - Use a mutex rather than a semaphore for the arm64 EFI runtime lock, > > now that it is never trylock()ed in IRQ or NMI context. > > > > Changes since v1/RFC: > > - Disable uaccess for SWPAN before updating the preserved TTBR0 value > > - Document why disabling migration is needed > > - Rebase onto v6.17-rc1 > > > > (*) only efi_reset_system() and EFI pstore invoke EFI runtime services > > without going through the workqueue, and the latter only when saving > > a kernel oops log to the EFI varstore > > > > Cc: Will Deacon > > Cc: Mark Rutland > > Cc: Sebastian Andrzej Siewior > > Cc: Peter Zijlstra > > Cc: Catalin Marinas > > Cc: Mark Brown > > > > Ard Biesheuvel (8): > > efi: Add missing static initializer for efi_mm::cpus_allowed_lock > > efi/runtime: Return success/failure from arch_efi_call_virt_setup() > > efi/runtime: Deal with arch_efi_call_virt_setup() returning failure > > Unless anyone objects, I am going to queue up these 3 patches ^^^ via > the EFI tree. > > > arm64/fpsimd: Permit kernel mode NEON with IRQs off > > arm64/fpsimd: Drop special handling for EFI runtime services > > arm64/efi: Use a mutex to protect the EFI stack and FP/SIMD state > > arm64/efi: Move uaccess en/disable out of efi_set_pgd() > > arm64/efi: Call EFI runtime services without disabling preemption > > > > ... so the rest can go in via the arm64 tree in the next cycle. I'm also happy to take the whole lot via arm64 this cycle, if you like? I reviewed it a while ago and was happy with it then. Up to you. Will