marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
brandas has joined #asahi
brandas has quit [Remote host closed the connection]
brandas has joined #asahi
brandas has quit [Quit: quit]
brandas has joined #asahi
stemnic5 has joined #asahi
brandas has quit [Client Quit]
stemnic has quit [Read error: Connection reset by peer]
Standemonium[m] has quit [Quit: Idle for 30+ days]
LeonardJanisRobe has quit [Quit: Idle for 30+ days]
scubasteve1 has quit [Quit: Idle for 30+ days]
baryluk has joined #asahi
raster has joined #asahi
qyousef has quit [Ping timeout: 240 seconds]
jato has joined #asahi
amw has quit [Ping timeout: 258 seconds]
amw has joined #asahi
amw has quit [Ping timeout: 246 seconds]
sbingner has quit [Ping timeout: 260 seconds]
sbingner has joined #asahi
sbingner has quit [Ping timeout: 258 seconds]
amw has joined #asahi
Axenntio has joined #asahi
Axenntio has quit [Remote host closed the connection]
Axenntio has joined #asahi
Axenntio has quit [Client Quit]
acelogic has joined #asahi
amw has quit [Ping timeout: 264 seconds]
<modwizcode>
marcan: how did you figure out the interrupt config register changes for the UART? I see in AIC test you messing with flags including a set called crash?
<marcan>
it was... confusing and complicated
<marcan>
since I was trying to debug this using the serial itself for communications
<marcan>
eventually, as you can see, I resorted to blobs of asm to do things locally and capture register values before returning control to python
<modwizcode>
yeah. But was there any method to what you chose to poke?
Axenntio has joined #asahi
Axenntio has quit [Read error: Connection reset by peer]
<marcan>
just try random bits, all, none, binary search manually to see which ones break things...
<marcan>
that kind of stuff
Axenntio has joined #asahi
<modwizcode>
also I've been a bit confused by the IPI handling, you say the AIC supports too (so called self and other), but i dont see register definitions for two, nor see the distinction
Axenntio has quit [Remote host closed the connection]
<modwizcode>
You have the virtual IPIs but thats not important to non-linux code (neat idea tho)
<modwizcode>
Did the config for the UART just become kinda obvious once you poked at it a bit?
<marcan>
the "self" IPI is 0x80000000 in the trigger and status registers
<marcan>
the "other" IPI is 1<<cpu in the trigger register, and 1 in the status/mask registers
Calchan has quit [Ping timeout: 264 seconds]
<marcan>
they are not symmetric in how you trigger them, but they are otherwise basically the same thing
<modwizcode>
0x80000000!? that's not part of the AIC?
<marcan>
that's the *value*
<marcan>
the top bit is "self", all the other bits are "IPI another CPU"
<modwizcode>
alao theres some IPI macros using 0x5000+something that are unused in the lnux driverr
<modwizcode>
ohhh
<modwizcode>
that seems weirdly specific but i guess its easy
<marcan>
and yes, 5000+x gives you another CPU's view of the registers
<modwizcode>
I thought it was two true IPIs
<marcan>
so you can "self" another CPU, which isn't self any more
<modwizcode>
ohhh
<marcan>
which is why they are really just two IPIs
<marcan>
but clearly "self" is intended as self
<marcan>
it's two *per-cpu* IPIs
<marcan>
I mean how would two true IPIs work
<modwizcode>
thats very strange but yeah clearly a self IPI
<marcan>
you need at least 8 targets
<marcan>
:)
<modwizcode>
right right
<modwizcode>
curiously why does linux need more?
<marcan>
linux sends 7 different messages via IPIs
<marcan>
and I guess this is the first arm64 platform that can't do that in hardware
<modwizcode>
the AIC is so nive and simple compared to the GIC
<marcan>
yeah
<marcan>
I really like it
<marcan>
it's so beautifully simple
<modwizcode>
its perfect lol
<marcan>
bbl, dinner :)
<modwizcode>
The GICv3 appeara to move more into system registers ehich is weird... luckily I don't have to use it :)
<modwizcode>
kay later
Axenntio has joined #asahi
Axenntio has quit [Remote host closed the connection]
<maz>
modwizcode: sysregs are a lot more better than MMIO in a number of cases.
<maz>
s/more//
<modwizcode>
I'm sure its useful but ARM insists on using both which I find to be the worat option
<maz>
and it allows the whole thing to scale to an insanely large number of CPUs, which you can't really do with the AIC scheme.
<maz>
ARM doesn't *insist*, and that's the main problem.
<maz>
ARM let you fuck up your system as much as you want!
<opticron>
the issue I have with system registers is that the compiler either has to be made aware of them or you have to sprinkle raw instructions into your code
<maz>
no, you don't. you write wrappers once, and you use them consistently.
<modwizcode>
the issue I have is the decompiler has to know about them or life sucks
<maz>
and you have similar issues with MMIO. do I need a barrier? what memory typoe?
<modwizcode>
Also ARM organizes them in an annpying way
<modwizcode>
you still need barriers with sysreg's generally from most arm docs ive seen
<maz>
of course you need barriers. it's just not different from using MMIO.
Tokamak has joined #asahi
acelogic has quit [Ping timeout: 272 seconds]
roxfan2 has joined #asahi
roxfan has quit [Ping timeout: 265 seconds]
Guest14662 has joined #asahi
Guest14662 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
acelogic has joined #asahi
<davidrysk[m]>
why do I keep getting panics on macOS shutdown, with the AIC in the backtrace....
<jannau>
nice, xz decompression in m1n1 works. 20% faster kernel loading. no direct support for Image.xz in the kernel though
<modwizcode>
davidrysk[m]: I wonder if it somehow accidentally removes the interrupt handling code before it kills all interrupts
mechpilotace has joined #asahi
Calchan has joined #asahi
dwhatley[m] has quit [Quit: Idle for 30+ days]
josiahmendes[m] has quit [Quit: Idle for 30+ days]
mcnight[m] has quit [Quit: Idle for 30+ days]
mofux[m] has quit [Quit: Idle for 30+ days]
vimal has quit [Remote host closed the connection]
marvin24 has quit [Ping timeout: 258 seconds]
marvin24 has joined #asahi
mofux[m] has joined #asahi
<modwizcode>
One nice thing about system registers vs. MMIO is that when defining handlers you have access to the CPU state itself. Meaning if you have local CPU versions of an MMIO register things seem painful...
Tokamak has quit [Ping timeout: 246 seconds]
<modwizcode>
I'm just going to do this wrong intentionally until I decide on a correct way that doesn't suck.
Axenntio has joined #asahi
<opticron>
modwizcode, yeah, instead of figuring out which block of the MMIO applies to the current CPU...
Tokamak has joined #asahi
<maz>
another crutial thing is that it allows trapping without messing with the page tables.
<modwizcode>
The issue is things like the interrupt reason register are a constant address but will have to behave different for each core since multiple cores can take an interrupt (reading it is also the ack, a decision I dislike overall too)
Axenntio has quit [Client Quit]
<opticron>
the read is an implicit ack on AIC?
<maz>
GICv2 solved that by having a set of banked register, but that was a huge pain to implement, and required early address decoding inside the CPU. terrible idea.
<modwizcode>
opticron: yes it seems so
<opticron>
ew
<modwizcode>
I'm looking at the qemu GICv3 code (v1 and v2 are basically the same code and are... not helpful to look at) and it solves this problem in a way I dislike also
Axenntio has joined #asahi
Axenntio has quit [Client Quit]
<opticron>
yeah, I've written a GICv3 driver
<opticron>
it's an interesting mashup of sysreg and mmio
roxfan has joined #asahi
<modwizcode>
It has a seperate struct for per-cpu state which is obvious. But it initializes it by creating it during construction of the parent GIC device then looping through the CPU count in QEMU and grabbing them from qemu_get_cpu and using that to assign their CPU reference.
<modwizcode>
It's a horrible way of doing things imo, because it precludes things like having an ARM system with a GIC and also having another type of CPU running too. Not sure if other things preclude that also but it's icky
roxfan2 has quit [Ping timeout: 276 seconds]
josiahmendes[m] has joined #asahi
<marcan>
modwizcode: this is why AIC knows the current CPU and displays it its registers
<marcan>
I wonder how that's done in hardware
<marcan>
I suspect they may be abusing the top address lines for this, though I'm not sure
<marcan>
opticron: yeah, there is a single "reason" register that returns the lowest firing irq number when read, and simultaneously masks it
<marcan>
well, there is one per CPU, and one special address that maps to your CPU
<modwizcode>
Yeah
<modwizcode>
I'm pretty sure that the way I'd do it is that each core has a set of local registers, and there's an arbiter or something that lets you also access them via the bus. But of course I don't design cores really so who knows
<marcan>
I think AIC really is just a global block
<marcan>
actually let me try something silly...
<modwizcode>
That is however, what I think my solution in QEMU is going to be. A special function you can use to wire up each CPU to it. Makes more sense for the SoC to drive the connections rather than the interrupt controller. It's a generic peripheral (I guss GIC gets a bit of a pass since with CP registers it's definitely ARM specific), but AIC is nice enough that I could see someone using this in other ways :)
<modwizcode>
I suppose another way is to wire it up with aliases such that each CPU's view of the AIC is wired up with an alias over the per-cpu registers pointing to it's CPU specific memory region. I've seen other code do something like that and that might be cleaner actually
Axenntio has joined #asahi
Axenntio has quit [Remote host closed the connection]
irl25519 has joined #asahi
<marcan>
oh this is a fun quirk
<marcan>
maz: you know how I was talking earlier about the timers? and how guest timer FIQs get masked somewhere and only delivered once, and that mask sticks when you turn on TGE?
<marcan>
turns out it sticks by accident. an isb makes it fire a FIQ again (and FIQ storm if not handled, as you would expect from TGE=1 mode)
<marcan>
needs the isb though, running a bunch of code does nothing. so isb "kicks" something into re-evaluating that FIQ state in light of the new TGE setting
<marcan>
this is really sounding like those timers are wired deep into the instruction pipeline...
<maz>
marcan: right. so we definitely need to find a way to mask the bloody interrupt before it is injected into the guest.
<marcan>
oh in guest mode it masks itself
<marcan>
it's just that the way that mask "stuck" when I flipped TGE seemed to be a quirk of the instruction pipeline
<modwizcode>
A lot of arm stuff requires isb before cp writes are considered to be visible
<marcan>
anyway, I'll look for that mask register
<marcan>
it's just interesting that isb kicked the fiq into working again
<modwizcode>
Did it kick the fiq or did it kick the TGE?
<maz>
flipping TGE definitely needs some heavy handed sync. usually, it is followed by an exception return, so you get that for free...
<marcan>
modwizcode: good question...
<marcan>
maz: that would make sense
<maz>
we only from it back when reaching the host on exit, and there is a metric butload of isb there...
<maz>
s/from/flip/
<modwizcode>
TGE confuses me greatly. I can read all the docs to see how the virtualization features *work* but how I'm intended to use most of them is a mystery. Especially when combined with VHE (is that the right name?)
<marcan>
this is why m1n1 is fun, it's so dumb and simple you get to experience the wonders if "no barriers, anywhere" :)
<modwizcode>
re: barriers, see my github issue :p
<marcan>
(except for places where I've already seem the CPU speculate stuff into madness, and had to add them)
<winocm>
miini
<modwizcode>
My favorite thing was earlier when I was testing and didn't realize the board I was using had smp setup, so all the cores started running m1n1 and I got like m11nn11
<maz>
modwizcode: it's actually pretty simple. E2H+TGE makes EL1 disappear. Most sysregs in _EL1 become _EL2.
<maz>
so you can run EL1 code at EL2 transparently.
<modwizcode>
Yes but why do I need E2H *and* TGE?
<maz>
you get extra accessors to fish out EL1 sysregs from EL2.
<maz>
because ARMv8.0 doesn't have VHE, so you need to be able to run non-VHE.
<winocm>
you’d have to access some of them using _EL12 to get the unbanked register
<maz>
and TGE has its own meaning when !VHE.
<modwizcode>
Right but what's the problem with E2H implying TGE
<maz>
of course M1 is violating the architecture by not implementing E2H==0.
<modwizcode>
It doesn't implement E2H==0?
<maz>
if E2H implies TGE, how do you enter a guest?
<marcan>
TGE is so that guests can go EL0-EL1
<modwizcode>
ohhhhhhhh
<modwizcode>
See this is the confusing part of having register descriptions with no conception of how they're used.
<marcan>
the "problem" with ARM virtualization is that EL0 is used by *both* the level 2 HV *and* the guest
<marcan>
so how do you know which EL0 is which
<winocm>
EL0&2 versus EL0&1 translation regimes
<modwizcode>
ARM virtualization makes x86 virtualization look sane from what I've seen. Although I don't understand x86 virtualization well enough to say that :p
<maz>
well, it's not x86's flavour of virtualisation.
<winocm>
er, the other way around EL2&0, I misremembered
<maz>
anyway, the design goal for VHE was to take an unmodified EL1 OS, and run it at EL2.
<maz>
obviously, that goal complicates the hypervisor.
<maz>
specially if that hypervisor has to handle nVHE as well.
<marcan>
the timers confuse me now though, because... okay, so we have HYP and non-HYP timers, non-HYP do this automasking thing... but not with TGE=1... so now with TGE=1 the hypervisor "owns" all timers and has to deal with them?
<marcan>
which would mean when context switching to TGE=1 we need to take over the timers and save state (or at least mask them)
<marcan>
I guess you need to do that to context switch VMs anyway...
<maz>
you always need to save/restore the timer state on context switych.
<marcan>
even on VM->HV-EL0 userspace context switch?
<maz>
you could detect that particular case, but that's pretty rare, and hard to identify.
<maz>
KVM saves everything on preemption.
<maz>
I had a prototype doing some lazy stuff a la FPSIMD, but it was complicated for no real performance benefit.
<marcan>
in this case we wouldn't be able to do that case without saving the timers for this reason
<marcan>
but yeah
<marcan>
anyway, sleep :)
<marcan>
I'll test your patch tomorrow
<maz>
thanks, and good night!
VinDuv has joined #asahi
irl25519 has quit [Quit: irl25519]
poppoppenguin has joined #asahi
sbingner has joined #asahi
vimal has joined #asahi
sbingner has quit [Excess Flood]
sbingner has joined #asahi
mndza has quit [Ping timeout: 265 seconds]
raster has quit [Quit: Gettin' stinky!]
dagb has quit [Remote host closed the connection]
Axenntio has joined #asahi
Axenntio has quit [Client Quit]
mxw39 has quit [Read error: Connection reset by peer]
mxw39 has joined #asahi
sbingner has quit [Ping timeout: 258 seconds]
sbingner has joined #asahi
<Glanzmann>
Is there anything better on macbook pro than the air other than the crippled keyboard?
<Glanzmann>
Or is it the same hardware?
<davidrysk[m]>
Glanzmann: better audio, better cooling, base model of air has 1 fewer GPU core
<davidrysk[m]>
regarding the keyboard, they did put the physical esc key back
<bastilian>
same hardware, minus the fan. which seems to make all the difference. there are few videos on youtube of people putting in thermal pads to make the bottom a heatsink for the CPU and it seems to be able to push as hard as the pro like that.
<davidrysk[m]>
yeah, though the base gets significantly hotter when you do that.
<davidrysk[m]>
there's threads on macrumors about it
<Glanzmann>
davidrysk[m]: What is better with the audio? Better speaker? I come from a lenovo t490, everything is better. :-)
<davidrysk[m]>
"high dynamic range" speakers, and "studio quality" microphones
<bastilian>
oh, yeah, i think they said ~60C
<Glanzmann>
I see. I don't know about you guys, but my macbook air (I use it now for 6 weeks) never gets hot.
<davidrysk[m]>
a macbook air will throttle after 10 minutes at full tilt.
<Glanzmann>
Unless I start qemu. And one other programm I don't recall.
<Glanzmann>
davidrysk[m]: Oh I see, I don't need that.
<davidrysk[m]>
if I'm compiling a large project at -j9, or use qemu or something similar, it will get hot and eventually throttle
<davidrysk[m]>
(or in my case, fans spin up)
<Glanzmann>
I see,
<Glanzmann>
Mini also has a fan, hasn't it?
<krbtgt>
yup
<krbtgt>
too bad the battery life on the mac mini is non-existent
<Glanzmann>
Perfect.
<krbtgt>
you unplug the power cable and it turns off, so much for M1 battery efficiency!
<Glanzmann>
:-)
<Glanzmann>
Have you guys already tried the corelliumhq kernel? Have you benchmarked the power consumption? I gave it yesterday a spin. No audio, but you can perfectly work with it. But I had it on a power cord.
acelogic has quit [Ping timeout: 258 seconds]
<roxfan>
does it do any power management?
<Glanzmann>
I saw soemthing, but I'm not really sure.