From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 A46F88C10 for ; Sat, 20 Apr 2024 12:16:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713615388; cv=none; b=LwwCau4XMDAt0vjzjRqoCOv0PiVFGe4h3X28J1XaXdmblxPeBpjyru9MkdBxKGUW1ZnjzbmKWGZ717KC+Xk0l1p+2L8yTTvw7VQmUKLtEvn2sEzTUskcrvRE3tdS15rltUK/J3TEUAh32KxhlBf9nhRSi8MXF06d4lHvTY8HlG4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713615388; c=relaxed/simple; bh=jpvBQEYsS25X1VkRv0g/8AyCht/4twbVITvDjtY2aY8=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=E/8YnceFwiTZ85MWleRUcSo2xpaySfphawPqOKbelI5PB5mWa+22ZTUIMA3OcHu3cKSrSTl9tuG6KJQWQinN5s2njejPlF7cYEwKUySNjtzEwPi5J0nrsMN8ZjbCnI61/RhQYb+G90bkC4kH8Y3LZVm4YLedK1Jfkg1lOJ7mGw0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=PO0vQcN0; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="PO0vQcN0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713615384; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YXJtiOIsyahYNFLD4DF8SJnvbOfVydqND2Xt4V5K7UE=; b=PO0vQcN0iSH5emFEyqrZsS4Lwz+54lV+wPX0RVR6MDioM8pvjXtmeKisIkh8vmg5OF0KBP Ws4cb44ddgZd4S3Q/avyokm+cGOLdfd5mOmvT1reNelYMWJR9lHtS5/Xgzd5CmuyKw1f2k Ze9EYrwOdfoe8B9HOyHPKjZhOaPF0Kg= Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-365-l7ZI3c77OuaCwZ35Tt17BQ-1; Sat, 20 Apr 2024 08:16:22 -0400 X-MC-Unique: l7ZI3c77OuaCwZ35Tt17BQ-1 Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-2a2f7048a7fso3247101a91.2 for ; Sat, 20 Apr 2024 05:16:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713615381; x=1714220181; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YXJtiOIsyahYNFLD4DF8SJnvbOfVydqND2Xt4V5K7UE=; b=FswIosSefL9Roy+Dwdf76tdvLJLx2YU2BjwQNRFXbXFd3VEMdIpQ11KyZC0r/oE67C ikyHYdPGUB4U0l0j/Kd3LZGDYKg6I/PyJbDw0GFZc1ZWJWRo6RsceqSQwyFdI+2p65Qe MDBkyjzuSL9tGt2l7ucVSQ4yS/DXOkJytsCcdT+DWsW49bVPOZx3m8scOWDUXx9xKov5 KAbVQDBThbiR6gdcmezAEP++qKFoL+Mq5dUJmY/bMeUyArlk7V4hW7ukUhTW0Y2fLTYr Tbo0lNSHjGdLGcB+notHzL+o/t0EUcJsPv5BygXy6HG84sN1zbh86wpSjVMjvXadHAaE es8Q== X-Forwarded-Encrypted: i=1; AJvYcCUBAhjQUJEIJ6bd3MAiWL+SXH7ELOd03AVZKL7gNPwnEJLX+WfCCyAxYyeFZIhoLneuPbdDj39OpwktrmAEV+24dGjCGZlT5d30noRo X-Gm-Message-State: AOJu0YwMid0Ekvonl8pkzQlVVXm08THp6zBR+bH/+NSJtRs5XA0FzH/Q bY5w4K+REsdIvga+xEsBT64wfCb6LuqOUIEJ338JiEa30JzJZuJXaox5Cu3MRnZguL1LejuThBH mDVEZ3CJsvrhFuIw3nz3TAMMwycpsBfo485VLr1CdVxJrQTo9w+6itrlxQRocoRt68999wrCrPs dISwOsKvBMOHA3ai6wnOWP2AOzFPiXZvPJVIFo X-Received: by 2002:a17:90a:c502:b0:2a4:6c87:7c81 with SMTP id k2-20020a17090ac50200b002a46c877c81mr4272050pjt.22.1713615381373; Sat, 20 Apr 2024 05:16:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGKewKKOvUWevO6z3GOo8wxJQ6pDHl0v2ODALKgpUBkx51EEZTP4p4zzk7PzkTer6ppIiIbwHCT++nxr+HDdls= X-Received: by 2002:a17:90a:c502:b0:2a4:6c87:7c81 with SMTP id k2-20020a17090ac50200b002a46c877c81mr4272008pjt.22.1713615381009; Sat, 20 Apr 2024 05:16:21 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240411-tso-v1-0-754f11abfbff@marcan.st> <20240411132853.GA26481@willie-the-truck> <28ab55b3-e699-4487-b332-f1f20a6b22a1@marcan.st> <20240419165809.GA4020@willie-the-truck> In-Reply-To: From: Eric Curtin Date: Sat, 20 Apr 2024 13:15:45 +0100 Message-ID: Subject: Re: [PATCH 0/4] arm64: Support the TSO memory model To: Will Deacon Cc: Hector Martin , Catalin Marinas , Marc Zyngier , Mark Rutland , Zayd Qumsieh , Justin Lu , Ryan Houdek , Mark Brown , Ard Biesheuvel , Mateusz Guzik , Anshuman Khandual , Oliver Upton , Miguel Luis , Joey Gouly , Christoph Paasch , Kees Cook , Sami Tolvanen , Baoquan He , Joel Granados , Dawei Li , Andrew Morton , Florent Revest , David Hildenbrand , Stefan Roesch , Andy Chiu , Josh Triplett , Oleg Nesterov , Helge Deller , Zev Weiss , Ondrej Mosnacek , Miguel Ojeda , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Asahi Linux , Sergio Lopez Pascual Content-Type: text/plain; charset="UTF-8" On Sat, 20 Apr 2024 at 13:13, Eric Curtin wrote: > > On Fri, 19 Apr 2024 at 18:08, Will Deacon wrote: > > > > On Thu, Apr 11, 2024 at 11:19:13PM +0900, Hector Martin wrote: > > > On 2024/04/11 22:28, Will Deacon wrote: > > > > * Some binaries in a distribution exhibit instability which goes away > > > > in TSO mode, so a taskset-like program is used to run them with TSO > > > > enabled. > > > > > > Since the flag is cleared on execve, this third one isn't generally > > > possible as far as I know. > > > > Ah ok, I'd missed that. Thanks. > > > > > > In all these cases, we end up with native arm64 applications that will > > > > either fail to load or will crash in subtle ways on CPUs without the TSO > > > > feature. Assuming that the application cannot be fixed, a better > > > > approach would be to recompile using stronger instructions (e.g. > > > > LDAR/STLR) so that at least the resulting binary is portable. Now, it's > > > > true that some existing CPUs are TSO by design (this is a perfectly > > > > valid implementation of the arm64 memory model), but I think there's a > > > > big difference between quietly providing more ordering guarantees than > > > > software may be relying on and providing a mechanism to discover, > > > > request and ultimately rely upon the stronger behaviour. > > > > > > The problem is "just" using stronger instructions is much more > > > expensive, as emulators have demonstrated. If TSO didn't serve a > > > practical purpose I wouldn't be submitting this, but it does. This is > > > basically non-negotiable for x86 emulation; if this is rejected > > > upstream, it will forever live as a downstream patch used by the entire > > > gaming-on-Mac-Linux ecosystem (and this is an ecosystem we are very > > > explicitly targeting, given our efforts with microVMs for 4K page size > > > support and the upcoming Vulkan drivers). > > > > These microVMs sound quite interesting. What exactly are they? Are you > > running them under KVM? > > It's the magic of libkrun. This is one of the git repos in the family > of libkrun, it has a wide array of use cases, which I personally won't > do much justice explaining all then, this is just one > repo/tool/usecases: > > https://github.com/containers/krunvm > > https://sinrega.org/running-microvms-on-m1/ Sorry for the double post, meant to share this one for the Asahi emulator usecase. Sergio's blogs are great in general: https://sinrega.org/2023-10-06-using-microvms-for-gaming-on-fedora-asahi/ Is mise le meas/Regards, Eric Curtin > > CC'ing @Sergio Lopez Pascual the lead of krun in general. > > Is mise le meas/Regards, > > Eric Curtin > > > > > Ignoring the mechanism for the time being, would it solve your problem > > if you were able to run specific microVMs in TSO mode, or do you *really* > > need the VM to have finer-grained control than that? If the whole VM is > > running in TSO mode, then my concerns largely disappear, as that's > > indistinguishable from running on a hardware implementation that happens > > to be TSO. > > > > > That said, I have a pragmatic proposal here. The "fixed TSO" part of the > > > implementation should be harmless, since those CPUs would correctly run > > > poorly-written applications anyway so the API is moot. That leaves Apple > > > Silicon. Our native kernels are and likely always will be 16K page size, > > > due to a bunch of pain around 16K-only IOMMUs (4K kernels do boot > > > natively but with very broken functionality including no GPU > > > acceleration) plus performance differences that favor 16K. How about we > > > gate the TSO functionality to only be supported on 4K kernel builds? > > > This would make them only work in 4K VMs on Asahi Linux. We are very > > > explicitly discouraging people from trying to use the microVMs to work > > > around page size problems (which they can already do, another > > > fragmentation problem, anyway); any application which requires the 4K VM > > > to run that isn't an emulator is already clearly broken and advertising > > > that fact openly. So, adding TSO to this should be only a marginal risk > > > of further fragmentation, and it wouldn't allow apps to "sneakily" "just > > > work" on Apple machines by abusing TSO. > > > > I appreciate that you're trying to be constructive here, but I don't think > > we should tie this to the page size. It's an artifical limitation and I > > don't think it really addresses the underlying concerns that I have. > > > > Will > > 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 09F98C4345F for ; Sat, 20 Apr 2024 12:16:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VVEua4X44wNpL032mxuOG3GK/n6ZCDyY7zQJ+xhN+N4=; b=OFI5LNozF3pRuL 4jUejLux6NDtdHBRiJp++YhYpO5eCwdy99r397ffaBltXFMmjawlaqSc27TFujSOeKs7bYRebLHpz F9o7xhZvBvOH9Z69q8khIq+z8Jcte8GOou/Km30V5NjFWYBlwDQoTiHip9R70TSU3zwUizHrL3VgW F6CQ39/IVDHnGwnEHPQwAVkpdkof+0SHRu3SYr9mGbDkxeFcgx054fcjyQ/UnwbmlPA1o99qlJAwK w0ThRvaRQLSk6ytrHp2yhmg44RzUt0ZHrUzIRNhF1GTu31/M+l50zjmdcAn44C2BAHcIeKECpEnFY tdhC6hjYoy5iaVquwmtw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ry9du-00000008S7O-35p3; Sat, 20 Apr 2024 12:16:30 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1ry9dr-00000008S6H-3TO0 for linux-arm-kernel@lists.infradead.org; Sat, 20 Apr 2024 12:16:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713615384; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YXJtiOIsyahYNFLD4DF8SJnvbOfVydqND2Xt4V5K7UE=; b=PO0vQcN0iSH5emFEyqrZsS4Lwz+54lV+wPX0RVR6MDioM8pvjXtmeKisIkh8vmg5OF0KBP Ws4cb44ddgZd4S3Q/avyokm+cGOLdfd5mOmvT1reNelYMWJR9lHtS5/Xgzd5CmuyKw1f2k Ze9EYrwOdfoe8B9HOyHPKjZhOaPF0Kg= Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-281-YDjNPLgzPZWNjqxyAotKPg-1; Sat, 20 Apr 2024 08:16:22 -0400 X-MC-Unique: YDjNPLgzPZWNjqxyAotKPg-1 Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-2a6f2c7c1b8so3255444a91.1 for ; Sat, 20 Apr 2024 05:16:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713615381; x=1714220181; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YXJtiOIsyahYNFLD4DF8SJnvbOfVydqND2Xt4V5K7UE=; b=mJ2Gxa5Fae7P05coGjuXB8mnes01pXNxfVx0fqwobpiYU97iXBV8el/6OmAVN4Zv8+ cyodYbjVNubLCq+4ZueFjt44zgjoRtpjU+3ArFNjR3UoPxK3v2xLdKHef4MKaZlSachX Ss8+xhIu9r3SEkJbK/mrzuC4sNRFVp9EdzqXHuYyDFBcc6aJCOBWe7pMqZVhTgm9Qlpb HhsoukD9truZ54Jrb5pUzcfA1wnS7pjPokqMzY77Sjo0pwCr1xRzCbz3z95TgTJ9EVPJ 8W8SKe/OiXvpB3bI9FieC6AEC6X/wzuKlr/Mi5OW7ctl+MUbl7ykJGkX65V6O+354FqI lBoQ== X-Forwarded-Encrypted: i=1; AJvYcCWd1uWY9lMrMb5ROjIJPjgaxofynSWu+AE6/RI2ghzjGGS7BDXGH6lXlMJHVgYDyGVjQ9kTiw6fKJGIACwadseYBRpCCxP4D95v3zgPEIQoClQckj0= X-Gm-Message-State: AOJu0YymOcB0Gxk/adanOR6iBTsN+QD0C94NyAZqMyTxj8UqQfroC1b/ A3W/H+vWcpDav5NZz6DjIIUSikkiO0EfD519zJ9U3qxb5v00tu/+r4ruRacX85v3SgzNmA83oCn nPUrRqmqnpzwXo9QLKvAhCvwvtnF6eZzQkKogsyrl6dLyb018H6Ydap1LdWQ9rsbBsxYA2ULEK8 FBDYbsmuWIQhfJCKMdlUk95PB28pvANnpY0cmaYToZtucHLWI= X-Received: by 2002:a17:90a:c502:b0:2a4:6c87:7c81 with SMTP id k2-20020a17090ac50200b002a46c877c81mr4272028pjt.22.1713615381368; Sat, 20 Apr 2024 05:16:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGKewKKOvUWevO6z3GOo8wxJQ6pDHl0v2ODALKgpUBkx51EEZTP4p4zzk7PzkTer6ppIiIbwHCT++nxr+HDdls= X-Received: by 2002:a17:90a:c502:b0:2a4:6c87:7c81 with SMTP id k2-20020a17090ac50200b002a46c877c81mr4272008pjt.22.1713615381009; Sat, 20 Apr 2024 05:16:21 -0700 (PDT) MIME-Version: 1.0 References: <20240411-tso-v1-0-754f11abfbff@marcan.st> <20240411132853.GA26481@willie-the-truck> <28ab55b3-e699-4487-b332-f1f20a6b22a1@marcan.st> <20240419165809.GA4020@willie-the-truck> In-Reply-To: From: Eric Curtin Date: Sat, 20 Apr 2024 13:15:45 +0100 Message-ID: Subject: Re: [PATCH 0/4] arm64: Support the TSO memory model To: Will Deacon Cc: Hector Martin , Catalin Marinas , Marc Zyngier , Mark Rutland , Zayd Qumsieh , Justin Lu , Ryan Houdek , Mark Brown , Ard Biesheuvel , Mateusz Guzik , Anshuman Khandual , Oliver Upton , Miguel Luis , Joey Gouly , Christoph Paasch , Kees Cook , Sami Tolvanen , Baoquan He , Joel Granados , Dawei Li , Andrew Morton , Florent Revest , David Hildenbrand , Stefan Roesch , Andy Chiu , Josh Triplett , Oleg Nesterov , Helge Deller , Zev Weiss , Ondrej Mosnacek , Miguel Ojeda , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Asahi Linux , Sergio Lopez Pascual X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240420_051628_056073_AE45F62D X-CRM114-Status: GOOD ( 42.85 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, 20 Apr 2024 at 13:13, Eric Curtin wrote: > > On Fri, 19 Apr 2024 at 18:08, Will Deacon wrote: > > > > On Thu, Apr 11, 2024 at 11:19:13PM +0900, Hector Martin wrote: > > > On 2024/04/11 22:28, Will Deacon wrote: > > > > * Some binaries in a distribution exhibit instability which goes away > > > > in TSO mode, so a taskset-like program is used to run them with TSO > > > > enabled. > > > > > > Since the flag is cleared on execve, this third one isn't generally > > > possible as far as I know. > > > > Ah ok, I'd missed that. Thanks. > > > > > > In all these cases, we end up with native arm64 applications that will > > > > either fail to load or will crash in subtle ways on CPUs without the TSO > > > > feature. Assuming that the application cannot be fixed, a better > > > > approach would be to recompile using stronger instructions (e.g. > > > > LDAR/STLR) so that at least the resulting binary is portable. Now, it's > > > > true that some existing CPUs are TSO by design (this is a perfectly > > > > valid implementation of the arm64 memory model), but I think there's a > > > > big difference between quietly providing more ordering guarantees than > > > > software may be relying on and providing a mechanism to discover, > > > > request and ultimately rely upon the stronger behaviour. > > > > > > The problem is "just" using stronger instructions is much more > > > expensive, as emulators have demonstrated. If TSO didn't serve a > > > practical purpose I wouldn't be submitting this, but it does. This is > > > basically non-negotiable for x86 emulation; if this is rejected > > > upstream, it will forever live as a downstream patch used by the entire > > > gaming-on-Mac-Linux ecosystem (and this is an ecosystem we are very > > > explicitly targeting, given our efforts with microVMs for 4K page size > > > support and the upcoming Vulkan drivers). > > > > These microVMs sound quite interesting. What exactly are they? Are you > > running them under KVM? > > It's the magic of libkrun. This is one of the git repos in the family > of libkrun, it has a wide array of use cases, which I personally won't > do much justice explaining all then, this is just one > repo/tool/usecases: > > https://github.com/containers/krunvm > > https://sinrega.org/running-microvms-on-m1/ Sorry for the double post, meant to share this one for the Asahi emulator usecase. Sergio's blogs are great in general: https://sinrega.org/2023-10-06-using-microvms-for-gaming-on-fedora-asahi/ Is mise le meas/Regards, Eric Curtin > > CC'ing @Sergio Lopez Pascual the lead of krun in general. > > Is mise le meas/Regards, > > Eric Curtin > > > > > Ignoring the mechanism for the time being, would it solve your problem > > if you were able to run specific microVMs in TSO mode, or do you *really* > > need the VM to have finer-grained control than that? If the whole VM is > > running in TSO mode, then my concerns largely disappear, as that's > > indistinguishable from running on a hardware implementation that happens > > to be TSO. > > > > > That said, I have a pragmatic proposal here. The "fixed TSO" part of the > > > implementation should be harmless, since those CPUs would correctly run > > > poorly-written applications anyway so the API is moot. That leaves Apple > > > Silicon. Our native kernels are and likely always will be 16K page size, > > > due to a bunch of pain around 16K-only IOMMUs (4K kernels do boot > > > natively but with very broken functionality including no GPU > > > acceleration) plus performance differences that favor 16K. How about we > > > gate the TSO functionality to only be supported on 4K kernel builds? > > > This would make them only work in 4K VMs on Asahi Linux. We are very > > > explicitly discouraging people from trying to use the microVMs to work > > > around page size problems (which they can already do, another > > > fragmentation problem, anyway); any application which requires the 4K VM > > > to run that isn't an emulator is already clearly broken and advertising > > > that fact openly. So, adding TSO to this should be only a marginal risk > > > of further fragmentation, and it wouldn't allow apps to "sneakily" "just > > > work" on Apple machines by abusing TSO. > > > > I appreciate that you're trying to be constructive here, but I don't think > > we should tie this to the page size. It's an artifical limitation and I > > don't think it really addresses the underlying concerns that I have. > > > > Will > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel