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
kettenis has joined #asahi
kettenis_ has quit [Ping timeout: 480 seconds]
roxfan2 has joined #asahi
roxfan has quit [Ping timeout: 480 seconds]
adamcstephens has joined #asahi
klltkr has quit [Ping timeout: 480 seconds]
linuxgemini has quit [Ping timeout: 480 seconds]
ave has quit [Ping timeout: 480 seconds]
nepeat has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
pastly-antispam has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-15 02:03:48)]
nepeat has joined #asahi
pastly-antispam has joined #asahi
linuxgemini has joined #asahi
ave has joined #asahi
kendfinger has joined #asahi
peaklight_ has joined #asahi
peaklight has quit [Ping timeout: 480 seconds]
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
VinDuv has joined #asahi
bisko has joined #asahi
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
VinDuv has quit [Quit: Leaving.]
bisko has joined #asahi
bisko has quit [Ping timeout: 480 seconds]
bisko has joined #asahi
bgb has joined #asahi
aleasto has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
bisko has quit [Remote host closed the connection]
bisko has joined #asahi
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi
bisko has quit []
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
aleasto has quit [Remote host closed the connection]
<marcan>
I also made it a more generic base class, eyeing a different way of keeping track of mmiotrace handlers/modes
bps has joined #asahi
swb has joined #asahi
FireFox317 has joined #asahi
<FireFox317>
marcan: any idea when you will be streaming again? It's fun :D
<marcan>
FireFox317: I did one on saturday!
<marcan>
actually thought of it today, but data structures aren't the most interesting thing :p
<marcan>
possibly tomorrow, once I get to use this to build the mmiotrace/hook framework I have in my head
<FireFox317>
marcan: yeah i saw the one from saturday :) its interesting to see the overview of the HV and how it is used.
<FireFox317>
Ah looking forward to it :D
<FireFox317>
Should really buy an apple device with a M1 to do some hacking on it xd
<jannau>
marcan: first impression is good. splitting makes sense. I can look at it toninght (CEST) in more detail
JTL has quit [Remote host closed the connection]
swb has quit [Ping timeout: 480 seconds]
<j_ey>
marcan: data structues for what?
swb has joined #asahi
<jannau>
marcan: the tps irq PR is marked as draft since it doesn't work reliable. For (some) register writes it's aparently necessary to include the length byte in the length. that contradicts both tps6598x TRM and the linux driver
JTL has joined #asahi
<marcan>
j_ey: mmio/address lookups
<marcan>
though I'm going to start using more of these
<marcan>
for tracking page table modes, mmiotrace/hook modes, etc
<marcan>
that's why I made it a more generic base class
<marcan>
I just wrote ScalarRangeMap and DictRangeMap (not pushed yet)
<marcan>
one issue we have is maintaining the page tables imperatively is very flaky; I want to be able to add/remove tracers and have the page tables updated as required to the union of what is needed, with multiple modes that stack, and also be able to spare C-side virtual peripherals (e.g. never clobber vuart/the aic hook)
<marcan>
so that's why I'm kind of reworking how this is all done
<marcan>
so I have 5 modes for mapping/tracing now, RESERVED > HOOK > SYNC > UNBUF > ASYNC > NONE
<marcan>
which have priority in that order
<marcan>
RESERVED is for vuart/vaic, it just overrides everything else and means it will never touch those mappings
<marcan>
HOOK means a python-side virtual device hook (override). there can only be one user for any given address.
<marcan>
SYNC is actually the same as HOOK on the C side, but it's a synchronous mmiotrace hook. the core (or an overlying HOOK user) does the read/write synchronously and all the tracers are guaranteed to be called before the guest continues exceution
<marcan>
UNBUF and ASYNC are normal mmiotrace, UNBUF is for the thing where the hv flushes the USB buffers after every write (mostly to get the thing through when the hv dies subsequently)
<marcan>
j_ey: ah yes, thanks :)
<marcan>
so I'm going to build a class that represents a peripheral register map (similar to Register32 but one level up) which can double as both metadata for mmiotrace and a general register accessor for convenience
<marcan>
and then a tracer class that will reference a regmap, and then just defining methods like SOMEREG_r() and SOMEREG_w() gives you mmiotrace hooks, with decorators to set modes like HOOK/SYNC/UNBUF
<j_ey>
wait, whats the diff between HOOK and ASYNC?
<marcan>
HOOK is a virtual peripheral, it overrides the hardware read/write
<marcan>
we only use that for those pmgr hijacks right now
<j_ey>
ohh
<marcan>
SYNC is the same thing behind the scenes, but you don't get to override anything; it behaves like a normal trace but is synchronous since the guest is suspended until it completes
<marcan>
you can only have one HOOK but as many SYNC or lower as you want for any given address
<j_ey>
so SYNC is for tracing, but with some extra things you want to do/log
<marcan>
yes
<marcan>
so for example, trigger on a GPU command submission and be able to dump the command buffer
choozy has joined #asahi
<marcan>
I'm also going to make the hardware regmap view behave differently depending on which context you're in
<j_ey>
and the diff between HOOK and RESERVED?
<marcan>
RESERVED is a no-op
<marcan>
it's meant for when those are taken on the C side
<marcan>
like the vuart map
<marcan>
we don't manage those from python so we never want to touch them
<marcan>
it's to avoid clobbering them
<j_ey>
makes sense
<marcan>
if you're in async context, "reading" from the hardware will return values cached from previous mmiotrace data (which might be out of date, but is useful if we're doing whatever the guest did and beats nothing)
<marcan>
if you're in sync context, reading will give you current data (and update the cache, as will trace events from the guest)
<marcan>
obviously the cache is somewhat best effort but I expect it will be useful
swb has quit [Read error: Connection reset by peer]
swb has joined #asahi
roxfan2 is now known as roxfan
bgb_ has quit [Ping timeout: 480 seconds]
Namidairo has quit [Remote host closed the connection]
Namidairo has joined #asahi
CDFH has joined #asahi
<marcan>
I hope python metaclasses don't scare people off :-)
skipwich_ has joined #asahi
skipwich has quit [Remote host closed the connection]
bgb_ has joined #asahi
skipwich_ is now known as skipwich
bgb_ has quit [Ping timeout: 480 seconds]
FireFox317 has quit [Quit: Page closed]
jix has quit [Remote host closed the connection]
jix has joined #asahi
<bloom>
oh no
<bloom>
marcan: have you finished r/e'ing agx.ko yet? o:)