ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
ellyq has quit []
pb17 has quit [Ping timeout: 480 seconds]
ddxtanx has quit [Quit: Konversation terminated!]
KxCORP58940003 has quit [Quit: Bye!]
KxCORP589400034 has joined #asahi-dev
pb17 has joined #asahi-dev
nora_ has joined #asahi-dev
nora has quit [Ping timeout: 480 seconds]
gladiac has joined #asahi-dev
gladiac2 has quit [Ping timeout: 480 seconds]
gladiac is now known as gladiac2
john-cabaj has joined #asahi-dev
dcavalca85 has quit [Ping timeout: 480 seconds]
jnn has joined #asahi-dev
jn has quit [Ping timeout: 480 seconds]
dcavalca85 has joined #asahi-dev
tobhe_ has joined #asahi-dev
tobhe has quit [Ping timeout: 480 seconds]
pb17 has quit [Ping timeout: 480 seconds]
pthariensflame has joined #asahi-dev
nora has joined #asahi-dev
nora_ has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
Halian has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<maz>
in the end, the MIDR-based early override was a wrong good idea, and I addressed the problem differently.
<maz>
any can't you just treat 32bit EL0 as an erratum or something along those lines? there is no need to do it early, as the prospect of running a 32bit task is pretty far down the boot process.
<maz>
s/any/and/
<nickchan>
maz: cleaner than adding a gross a10 midr check in id_aa64pfr0_32bit_el1 in cpufeature.h
<nickchan>
right the issue is basically the core can only exec 32 bit in certain p-states
<nickchan>
high powered p-states is ok, low ones aren't
<maz>
but that's beside the point. you can only run 32bit once you reach userspace. so this doesn't need to be an early decision, like the E2H0 is.
<nickchan>
maz: was trying to edit arch/arm64/kernel/cpu_errata.c but I guess not
<maz>
nickchan: cpufeatures.c and cpu_errata.c are basically the same thing. I'm at the stage where I consider each new feature as an erratum.
<maz>
here, you're trying to disable a standard feature rather than flagging a bug that affect a couple of code paths.
<maz>
does your wonderful CPU have EL2?
Dan___ has joined #asahi-dev
Dan___ has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
<nickchan>
maz: it has EL0 and EL1
<maz>
nickchan: right. so you don't even need to hack the EL1 part, and can solely rely EL0 being hidden from the kernel, as you will never run anything AArch32 at EL1.
<nickchan>
none of Apple's arm64 chips supported aarch32 EL1 so yeah it is not needed
r0ni has quit [Ping timeout: 480 seconds]
<maz>
nickchan: that's not my point. if the kernel runs at EL1 and there is no EL2, you can't switch to AArch32 at EL1 (switching ISA is always done by a more privileged EL, Apple CPU or not).
<nickchan>
maz: has_32bit_el0() does not control availability of 32-bit execution
<nickchan>
system_supports_32bit_el0() in arch/arm64/include/asm/cpufeature.h does
<nickchan>
which reads the register value with the function id_aa64pfr0_32bit_el0() also in cpufeature.h
<nickchan>
wait no that functions just says a given pfr0 value has 32 bit el0
<nickchan>
what's needed is changing the sanitized value from the pfr0 register
<nickchan>
because of the msr emulation that does need to be changed