Messages in this thread | ![/](/images/icornerl.gif) | | From | Eric Curtin <> | Date | Sat, 20 Apr 2024 13:15:45 +0100 | Subject | Re: [PATCH 0/4] arm64: Support the TSO memory model |
| |
On Sat, 20 Apr 2024 at 13:13, Eric Curtin <ecurtin@redhat.com> wrote: > > On Fri, 19 Apr 2024 at 18:08, Will Deacon <will@kernel.org> 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 > >
| ![\](/images/icornerr.gif) |