09:31 <j_ey> jannau: do you understand the sizes of the gpio/pinctrl controllers? they seem way bigger than anything that looks like it is accessed

09:33 <sven> that's pretty common in the ADT fwiw

09:33 <sven> there's also one DART that has a size of 0x20000 or so but is really just the same 16k repeated over and over

09:34 <j_ey> as in accessing reg + 0 is the same as reg + 16k?

09:34 <sven> yeah

09:36 <j_ey> this has size 0x100000, that's 1mb, waste of ram!!

09:39 <sven> what probably happens internally is that the address decoding/muxing logic uses the upper $whatever bits and some of the lower address lines either just aren't connected or are ignored by the gpio/pinctrl hw block

09:39 <j_ey> sven: is there any reason to use that size though?

09:39 <j_ey> or can we just map 1 page for it

09:40 <sven> you can just map a single page

09:40 <j_ey> (also I assume if I put 0x1000 there, it's rounded up to PAGE_SIZ)

09:40 <sven> it'll certainly map the size rounded up to the next PAGE_SIZE, but accessing anything past 0x1000 is probably undefined then :)

09:45 <pipcet[m]> so our theory is the ADT contains the entire decoded range, not the actually accessible range? That makes sense from a HW POV, I guess...

10:40 <marcan> it's not consistent

10:40 <marcan> the ADT is written by humans

10:40 <marcan> we should try to be more consistent than them and declare only the real ranges

10:40 <marcan> no mirrors

10:40 <j_ey> marcan: is this wrong: python3.9 proxyclient/tools/run_guest.py -m proxyclient/m1n1/trace/gpio.py m1n1-payload.macho ?

10:41 <j_ey> I'm getting 'ImportError: attempted relative import with no known parent package'

10:41 <marcan> sounds like it should work

10:41 <marcan> uhm

10:42 <marcan> where?

10:42 <j_ey> File "proxyclient/m1n1/trace/gpio.py", line 3, in <module>

10:42 <j_ey> from ..hv import TraceMode

10:42 <marcan> oh wait

10:42 <marcan> hv/trace_gpio.py, not m1n1/trace/gpio.py

10:42 <marcan> the hv scripts are all in hv/

10:44 <j_ey> thanks, that works!

11:02 <cgv[m]> has anyone played with perf counters in M1? I'm trying to use m1n1 to run microbenchmarks (setting up the counters and env from python), but I'm having some issues. e.g. evt=0x1 (retired uops) only seem to work in PMC1, I'm not able to set it up in PMC2, but evt=0x2 (cycle count) works well with any PMC

11:14 <dougall> heh, yeah, i have

11:16 <cgv[m]> dougall: i saw your repo :) did you experience anything like the above? just to be sure whether it's expected or if i'm doing something stupid

11:17 <cgv[m]> probably the later, since i don't seem to be able to observe many events :(

11:19 <dougall> so, I'm a little confused as I didn't think PMC1 was configurable? but yes - there are a number of events that only work on a subset of PMCs, e.g. retired uops (1) I can only use on PMC7

11:20 <cgv[m]> no, it's not, but i was trying to count the same event with another counter; ok, that make sense, i will check what-works-where, thx

11:25 <dougall> yeah - I've been working on that a bit - the difficulty is finding ways to trigger the events so I can see which PMCs support them, but I had some luck. Let me know if there's anything specific you're wondering about, or I'll try to put together some updated notes soon. For the officially documented ones /usr/share/kpep/a14.plist has the info

11:27 <dougall> (no idea if you're a mac user, but i use `plutil -convert json -o - /usr/share/kpep/a14.plist` to get it as json, and the "counters_mask" has bit (1<<n) set for PMCn iirc)

11:29 <cgv[m]> thanks, I'll start from that and see if I manage to count more events

11:56 <cgv[m]> event and PMCs where I observe changes (i'm not yet exercising all of them)

12:12 <dougall> nice! can i ask what you're working on/towards? just exploring? (there is a fun edge-case to watch out for with inst_int_store (0x96) and INST_LDST (0x9b) counting fused AMX instructions differently on PMC7, which counts instructions, vs PMC5/6, which count fused ops)

12:58 <cgv[m]> just exploring, i want to get a nice low-noise environment to quickly run snippets in different contexts, after that i guess some idea will popup

13:00 <cgv[m]> at some point i was tempted to port nanobench to arm, maybe m1n1 could be a good env for that?

13:01 <pipcet[m]> cgv: rr support for M1 would be really nice, or at least evaluating whether it's possible (https://github.com/rr-debugger/rr)

13:13 <dougall> sounds gret :) yeah - last i heard m1n1 doesn't do frequency scaling, so it'd be convenient in that respect - I haven't got around to setting it up myself, but I've been meaning to do that and try to reproduce something like Sushi Roll (https://gamozolabs.github.io/metrology/2019/08/19/sushi_roll.html) at some point

13:18 <cgv[m]> that would be super cool

13:19 <milek7> rr doesn't work on arm

13:21 <pipcet[m]> there's some aarch64 code in the tree now, only recalled that...

13:24 <pipcet[m]> https://github.com/rr-debugger/rr/releases/tag/5.4.0

13:26 <milek7> ah, I didn't know it

19:36 <sven> uh... i just realized something weird about the nvme iommu. so the normal io queue is created using an admin io queue command with the dma specified in one of the fields. that dma address is whitelisted using the nvmmu. so far so good

19:37 <sven> but then the nvmmu entry is deleted but ANS can still access the io queue dma buffer just fine. so where exactly is it still whitelisted?!

19:37 <alyssa> dougall: there's a cpufreq driving floating around, dunno if it's functional

19:38 <alyssa> sven: 🤔

20:03 <sven> and weird, the shutdown process looks like a normal nvme shutdown process. so why doesn't it complain about an uncleanReboot only when macOS does it? :.

20:03 <sven> *:/

20:08 <alyssa> sven: Any side channel interactions (e.g. with SMC)?

20:11 <sven> nothing on the ANS mailbox, but i should also trace the SMC mailbox.

20:11 <alyssa> nod

20:12 <roxfan> differential debugging

20:13 <sven> i'm still confuse about the io queue dma buffer :/

20:14 <sven> i'd claim that what we call NVMMU actually isn't an IOMMU-like block, but it's handled inside PPL which is usually reserve for stuff like iommus

20:14 <roxfan> aren't we all

20:14 <sven> *reserved

20:20 <alyssa> sven: where does the name NVMMU come from?

20:22 <roxfan> from nvme?