From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from hostch02.fornex.host (hostch02.fornex.host [91.192.102.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6DB62202F71 for ; Sat, 15 Aug 2026 22:10:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.192.102.107 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786831839; cv=none; b=DbMAaArmENoXuc/ZTxrUOSrCrlfxoNxCF7WCgqtQfia3DEvv5VNjDuieH4VSLSPPo5T+CWMa3TiUVighiISN9tAGAVMzn581gXCewpzbLVP02Ej/xEuYMxuVIIZwspE/CbCbYotk6r0fFrEbU9slWCI7ph5+CK4b4eq9Z5EuMe0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786831839; c=relaxed/simple; bh=yFJ+vQKkW6vx7OhSauzxDO6fqaJIFDD9PbzJxWiNgJs=; h=MIME-Version:Date:From:To:Cc:Subject:Message-ID:Content-Type; b=VJhDU1anLNNe7HSNg6WOvhBG9FDytV7foyGu9QSDfVprnWQL/6BHg/FuNUmkTb8MhgLWKZR9lbUmi4i0ZaMaoFHBh8gAXLHMRj9zOaOXEGwW6YyrP1pFwTvuT5VcwBMz3smfc3mIVvW4OzvzM6o0nxDZbsLxg+VobINC5Ajp9/o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=zalexdev.com; spf=none smtp.mailfrom=zalexdev.com; arc=none smtp.client-ip=91.192.102.107 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=zalexdev.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=zalexdev.com Received: from [::1] (port=38340 helo=hostch02.fornex.host) by hostch02.fornex.host with esmtpa (Exim 4.99.2) (envelope-from ) id 1wvM8e-000000007fk-2GvZ; Sat, 15 Aug 2026 21:42:00 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Sat, 15 Aug 2026 21:42:00 +0000 From: contact@zalexdev.com To: richard@nod.at, anton.ivanov@cambridgegreys.com, johannes@sipsolutions.net Cc: linux-kernel@vger.kernel.org Subject: [RFC] um: an arm64 subarch for User Mode Linux User-Agent: Roundcube Webmail/1.6.15 Message-ID: X-Sender: contact@zalexdev.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hostch02.fornex.host X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zalexdev.com X-Get-Message-Sender-Via: hostch02.fornex.host: authenticated_id: contact@zalexdev.com X-Authenticated-Sender: hostch02.fornex.host: contact@zalexdev.com X-Source: X-Source-Args: X-Source-Dir: Hi, I have ARCH=um SUBARCH=arm64 working -- 33 patches on uml/next. Before sending that many to the list I would like to know if it is wanted, and in what shape. https://github.com/zalexdev/linux-um-arm64 (branch um-arm64) Boots Alpine and Debian at 4K and 16K pages, SECCOMP and ptrace userspace, loadable modules. The part I want an opinion on is syscall interception on hosts without PTRACE_SYSEMU, since 5.3 is a recent floor for arm64 and phones ship 4.19. There the guest syscall is cancelled by writing -1 to NT_ARM_SYSTEM_CALL at a PTRACE_SYSCALL stop. That fails under a seccomp filter, though: arm64 reports the ptrace stop before running seccomp, so the filter sees the -1 and an Android app sandbox kills the tracee. So the third path substitutes getppid(2) for the guest's call -- the call still does not run, but a syscall does execute on the guest's behalf. Is that acceptable? nosysemu and nocancel select the fallbacks on any host, so they are testable without a 4.19 machine. Modules reuse arch/arm64/kernel/module.c and module-plts.c instead of a second copy, the way arch/x86/um does. That does mean pulling two files out of arch/arm64. Two changes are performance only. The stub handoff skips FUTEX_WAKE when nobody is parked and spins against CNTVCT_EL0 before parking; anonymous faults are batched onto the handoff that was happening anyway. Snapdragon 870, SECCOMP mode, medians of 7 interleaved rounds: syscall 9.841 -> 1.987 us openat 20.223 -> 4.501 us fault 24.592 -> 11.076 us Known problems: no 32-bit compat, UP only, and "BUG: Bad rss-counter state ... type:MM_FILEPAGES val:1" once per exiting process under Debian but not under Alpine on the same kernel. I have not found that one and would not expect it merged as is. About a third of the patches are not arm64 -- generic um/ fixes and two x86 ones, including a missing 32-bit stub_seccomp_save_state -- but they sit on top of the subarch commit and do not apply alone. I can rebase them into a separate series first if that is more useful. I cannot commit to maintaining this long-term. Happy to respin or split it however you want; say the word and I will send the series with git send-email. Thanks, Oleksii