From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lithops.sigma-star.at (mailout.nod.at [116.203.167.152]) (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 79DD92AF00 for ; Sun, 16 Aug 2026 19:46:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=116.203.167.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786909596; cv=none; b=U4R5veuyNsQK4kcHVQq+7SYAtNBWIYaTbU/qtcbDIJI32OFTLOTWkAcUn4HbiFt1rXNlKACxk6SLdzvQd9GvQhDS92Ens/XTNG7TX3uvjocYiHw3eJ2gXVl7vm5FubPqy5phTEIeCzfGS+iHeL5WeCf1Bat6c+t6yZqf+H0D6f0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786909596; c=relaxed/simple; bh=a6e3YNo215N5/Y9Ml2E8UZgAoJkiDVQFDRWK60lC39I=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=UqlQavEUhQeaqog5v23XkqPv6PqhWNLdCg+MjKZ2CUwCYHtb0YFt+ssgCZgLfHOnEDP85BwvwOSP+SGgP9edi1h1Jck5KREk/xSNyN8n+2aJpa3MaxyKK7KewmQM/qXOcU7Rh/R/LWQfRgVXDithcTMwEfWRyOjTyO28nHq4Sl8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at; spf=fail smtp.mailfrom=nod.at; arc=none smtp.client-ip=116.203.167.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nod.at Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 465262698F9; Sun, 16 Aug 2026 21:46:24 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id bh5QazcZrNNR; Sun, 16 Aug 2026 21:46:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id BE8882698FA; Sun, 16 Aug 2026 21:46:23 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xuMQ8NcWvSU7; Sun, 16 Aug 2026 21:46:23 +0200 (CEST) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id 9C5442698F8; Sun, 16 Aug 2026 21:46:23 +0200 (CEST) Date: Sun, 16 Aug 2026 21:46:23 +0200 (CEST) From: Richard Weinberger To: contact@zalexdev.com Cc: anton ivanov , Johannes Berg , linux-kernel , linux-um Message-ID: <1076510330.148098.1786909583435.JavaMail.zimbra@nod.at> In-Reply-To: References: Subject: Re: [RFC] um: an arm64 subarch for User Mode Linux Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF153 (Linux)/8.8.12_GA_3809) Thread-Topic: an arm64 subarch for User Mode Linux Thread-Index: 8eghKM0bfQMwyYhQH8j0R3/QLDuMNw== ----- Urspr=C3=BCngliche Mail ----- > Von: contact@zalexdev.com > I have ARCH=3Dum SUBARCH=3Darm64 working -- 33 patches on uml/next. Befor= e > sending that many to the list I would like to know if it is wanted, and > in > what shape. >=20 > https://github.com/zalexdev/linux-um-arm64 (branch um-arm64) >=20 > Boots Alpine and Debian at 4K and 16K pages, SECCOMP and ptrace > userspace, > loadable modules. Nice. :-) =20 > 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. Well, it's reasonable to require a non-ancient host kernel. > 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. >=20 > 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: >=20 > syscall 9.841 -> 1.987 us > openat 20.223 -> 4.501 us > fault 24.592 -> 11.076 us >=20 > 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. >=20 > 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. >=20 > 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. Patches are welcome, but don't expect others to do the hard work. Thanks, //richard