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
<balrog>
brinly: look at osfmk/vm, primarily vm_compressor.c
<balrog>
11.3 has some mitigations already
<brinly>
yeah I know
<brinly>
I just wanna find the exact vesion
<brinly>
so Im not looking through like 50 changes
bgb has joined #asahi
bgb has quit [Remote host closed the connection]
bgb has joined #asahi
<marcan>
I don't know the exact version
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
aquijoule__ has joined #asahi
bgb has quit [Read error: Connection reset by peer]
aquijoule_ has quit [Ping timeout: 480 seconds]
uberushaximus has quit [Quit: uberushaximus]
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
awordnot has quit [Ping timeout: 480 seconds]
SunWuKung has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
VinDuv has joined #asahi
SunWuKung has quit [Remote host closed the connection]
VinDuv has quit [Quit: Leaving.]
keenriser has joined #asahi
EER has quit [Ping timeout: 480 seconds]
rann has joined #asahi
maz has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
tardyp has quit [Read error: Connection reset by peer]
jabashque has quit [Remote host closed the connection]
jabashque has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
choozy has joined #asahi
<bgb>
marcan/sven: can the m1n1 usb function co-work with macos host?
<sven>
no
<sven>
or, well, you could give one port to Mac OS and one to m1n1
_whitelogger has joined #asahi
_whitelogger has joined #asahi
_whitelogger has joined #asahi
<sven>
I don't understand that question
<sven>
why do you want to know that?
<bgb>
well, more directly, why macos cannot co-work with the m1n1 usb function?
_whitelogger has joined #asahi
<sven>
how would that work?
<_jannau_>
HW access is exclusive. the hypervisor would need code to support sharing HW resources with mac os
<sven>
you'd have two drivers competing over a single HW block
<sven>
it's also not really required. it's possible to mux the Mac OS serial output over m1n1's usb driver together with the MMIO trace
<sven>
is there any other reason you have in mind for sharing that USB port?
_whitelogger has joined #asahi
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
<bgb_>
all right, I have missed a lot about m1n1 usb, mmiotrace etc.
<bgb_>
exit
bgb_ has quit [Quit: WeeChat 3.0.1]
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
tmbinc has joined #asahi
choozy has quit [Ping timeout: 480 seconds]
<marcan>
sven: that's what I've been doing, one port for each
<marcan>
though I'm not entirely sure if it will work properly; yesterday I disabled the other port too just in case (well, yesterday I disabled a ton of stuff)
Simonx22 has joined #asahi
eta has quit [Remote host closed the connection]
<sven>
yeah, it also wouldn't surprise me if some phy stuff is actually shared between the two ports and breaks
<sven>
though at least in theory they both also have a separate phy mmio space. but who knows what kinda of fun surprises are lurking in there
eta has joined #asahi
eta has quit [Remote host closed the connection]
<kettenis>
the i2c controller that has the type-C PD chips on it is shared
eta has joined #asahi
eta has quit [Remote host closed the connection]
eta has joined #asahi
eta has quit [Remote host closed the connection]
eta has joined #asahi
<sven>
true
<sven>
I hope that doesn't matter though since it shouldn't try to speak to the m1n1 port once it has been removed from the ADT
<sven>
but who knows :-)
eta has quit [Remote host closed the connection]
eta has joined #asahi
eta has quit []
eta has joined #asahi
eta has quit [Remote host closed the connection]
eta has joined #asahi
<pipcet[m]>
the IRQ line is shared between the two I2C chips
<marcan>
sven: sooo it dies in GXF, but it dies *completely* :D
<marcan>
the core wedges *in* the GXF exception vector
<sven>
wow :D
<sven>
like, it just stop working?
<Shiz>
rrrip
<j_ey>
stopped on a `mov`
<pipcet[m]>
marcan: that happened here (now have it working), but I thought it was because I was failing to virtualize the GXF page tables properly
<marcan>
is there a separate GXF VM TTBAR?
<pipcet[m]>
marcan; can you read the PC from another CPU core? (write 0xc5acce55 to 0x210030fb0, read 32 bits from 0x210040090 and discard, then reading 64 bits from 0x210040090 gives you the lower 49 bits of CPU0's PC)
<sven>
TTBAR?
<marcan>
yes, that's what i'm doing
<marcan>
*TTBR or whatever
<marcan>
which is how I know it's wedged in that vector
<sven>
I don't think so
<sven>
or, well, I haven't found anything like that
<sven>
from what I can tell it's always using the same pagetables
<marcan>
actually hold on
<marcan>
it's moving
<marcan>
it's not wedged
<marcan>
it's just recursively faulting or something
<pipcet[m]>
sven: are you sure? I think it uses a different top-level page table which just shares the lower levels
<sven>
pipcet[m]: what makes you think that?
<marcan>
but the interesting thing is debug_putc isn't working then
<sven>
huh.. maybe some weird permission remap thing?
<pipcet[m]>
sven: I virtualized it to get my mmiotrace working
<Shiz>
marcan: also props for an actually short stream :)
<marcan>
mmio broken for gxf maybe? let me check the perms...
<sven>
i.e. the exception vector is not marked as executable in the SPRR register or the stack isn't writable?
Shiz has quit []
Shiz has joined #asahi
<sven>
oh wait.. the SP in GXF is weird fwiw
<pipcet[m]>
sven: I had to map my injected page using the actual ttbr_el2 value read from the GXF (I think) exception vector.
<pipcet[m]>
yes.
<pipcet[m]>
it points to the beginning of the page
<pipcet[m]>
not the top
<marcan>
I set it to PERM_RW_EL0 which maps to ELrw_GLrw
<marcan>
at both EL1 and EL0 (well EL2 instead of EL1)
<marcan>
so let's see
<sven>
can you read the SP with that coresigh stuff?
<jix>
coresigh :D
<sven>
:D :D
<marcan>
not sure, it failed the debug request, need to poke around later
<marcan>
dinner first
<pipcet[m]>
sven: if you can it should go on the wiki, I haven't found a way yet :-)
<sven>
the SP was strange. iirc macOS always sets it up from TPIDR_GL1/2
<pipcet[m]>
but debug_putc doesn't use the stack
<marcan>
so mmio does work "normally" from m1n1
<pipcet[m]>
so I suspect it's trying to resolve the mmio page, failing, and faulting recursively.
<marcan>
in gl2
<marcan>
let me try in the middle of the hv in case config changes
<marcan>
yeah. still works
<pipcet[m]>
silly question, but you're using the right page table, right? As I said, I had to virtualize it separately so it probably is different from the EL2 page table.
Raqbit has joined #asahi
<sven>
marcan: did you try in the middle of the hv after xnu already enabled gxf in el1?
<sven>
it shouldn't make a difference but...
<marcan>
yes, I think so
<sven>
weird
<sven>
so it faults from GL1 to GL2 and then just hangs?
<marcan>
>>> mrs(GXF_CONFIG_EL12)
<marcan>
0x2d
<marcan>
seems enabled
<sven>
hm, yes
<sven>
with some mystery bits I don't know about
<marcan>
debug_print works from gl2 in this state
<pipcet[m]>
in my case it was faulting recursively because the injected page wasn't in the right page table
<pipcet[m]>
I injected a page into the GL2 code so it would wait for another core to actually handle the page fault, as part of virtualizing the page tables so I could have an mmiotrace.
ave has joined #asahi
<pipcet[m]>
I assume you're injecting the mapping for the uart's mmio page similarly?
<pipcet[m]>
or do you use the mapping macos set up for you?
<sven>
uh, it's a hv. he just uses two stage translations
<sven>
there's no need to inject anything into xnu's pagetables
<pipcet[m]>
I thought he was wedged in the GL2 code and couldn't get back to the HV?
<sven>
GL2 *is* the hypervisor
<sven>
GL1 is xnu
<pipcet[m]>
oh, I must have misread "debug_putc isn't working then"
<sven>
yes, debug_putc in GL2 isn't working apparently
choozy has joined #asahi
karlyeurl has joined #asahi
<marcan>
nor is any memory access, apparently
<marcan>
oh shit
<marcan>
I know what this fucking thing is
<marcan>
I've been here done this
<marcan>
goddammit
<marcan>
52823eaab
<marcan>
of course I need that for the GXF vectors too
<marcan>
cc sven
<marcan>
> !GLEXC:a!
<marcan>
and it works
<marcan>
le sigh
<marcan>
it's just a damn FIQ
<marcan>
in GL2
<sven>
lol
<sven>
glad you figured it out ;)
<kettenis>
is there a particular reason why usb_init() is only called if there is no payload?
<sven>
you probably just need usb_phy_bringup or however it's called if you want to use dwc3 in uboot/openbsd
<kettenis>
the other bits don't seem to hurt ;)
<sven>
fair enough :D
<sven>
I'm still surprised the phy bringup is also enough for host mode
<kettenis>
I'll see if I can come up with a diff that does just the clocks and usb_phy_bringup()
<marcan>
sven: okay, got to a panic on SEP bringup now
<marcan>
this is way further than it's ever gotten
<sven>
\o/
<sven>
nice
<j_ey>
marcan: sick!
<marcan>
(this of course also explains all the hideous non-deterministicness... timer FIQs in GL2, duh)
<marcan>
j_ey: no, just the general "it crashes in a different place depending on completely random changes" thing
<marcan>
like trapping more/fewer registers etc
<marcan>
oh, and this also explains why trapping the GXF registers breaks
<marcan>
because it would probably genter then trap on something, and that would hang
<marcan>
I bet trapping GXF works fine now
SunWuKung has joined #asahi
VinDuv has joined #asahi
<marcan>
j_ey: like to clarify, xnu is multitasking at this point, so non-det breadcrumbs make some sense, but what *didn't* make sense is crashing way earlier/way later depending on random configuration changes
<marcan>
it's never gotten past sec cpu bringup (possibly because for whatever reason that puts it in gl1 long enough to reliably die; large page table changes?) but it's randomly died way earlier, sometimes consistently depending on settings
<j_ey>
but wasn't the FIQ from a timer, which should have happened roughly at the same time?
<j_ey>
or was disabling some configuration just causing different things to print, so it looked like it happened at different times?
<marcan>
it's the timer firing *while* it's in GL1 that makes it go into GL2
<marcan>
the HV timer fires at 1000Hz
<marcan>
but I guess the guest spends little enough time in GL1 until that point in boot that most of the time it didn't crash
<j_ey>
aha, the guest needed to be in GL1 for it to happen!
<marcan>
but of course changing configuration settings would do things like make some operations slower, or more likely to trap while in GL1
<marcan>
yes!
<marcan>
it seems it's always EL1 -> EL2 and GL1 -> GL2
<marcan>
they basically operate in parallel, roughly identically other than the separate context registers for GLx
<marcan>
so right now I just point the GL2 VBAR at the same vectors as the EL2 VBAR, and have wrappers to read/write the context registers that pick the right one based on the current mode
<marcan>
and that just makes the whole thing work, and agnostic to whether it's in GL2 or EL2
<marcan>
eret goes back to GL1 or EL1 as required
<j_ey>
(I just watched that bit on the quick stream)
<j_ey>
in_gl2()
<marcan>
sven had already worked most of it out, but I'd been *assuming* GL1 somehow trapped to EL2 because, well, it was getting way too far for that not to be the case!
<marcan>
and because I wasn't seeing the GL2 exceptions
<marcan>
... but the PAN thing plus PPL apparently being not called into that often and running fast conspired to confuse me
<marcan>
(maybe the PPL is only half there? Apple says it's not like iPhones; clearly there's GXF in use but how much exactly?)
<marcan>
well, now that I can probably actually grap gxf registers I guess I'll find out
<marcan>
*tra@
<marcan>
*trap
Misthios has quit [Quit: Misthios]
Misthios has joined #asahi
<sven>
does apple even mention GXF anywhere?
<sven>
i thought their last update still only mentions APRR
<sven>
which didn't exist on any x86 macs :)
keenriser has quit [Remote host closed the connection]
pugguu has joined #asahi
<pugguu>
Hey marcan how far are we with the hypervisor if we were to put it as a percentage
<pugguu>
😉 ASCII 0x1E i said percentage so u do not have to do a time
<pugguu>
Dangit didnt work
<pugguu>
Tried to do strikethrough
<pugguu>
Ooooo begining and end oh well
tsida has joined #asahi
pugguu has quit [Remote host closed the connection]
pugguu has joined #asahi
<marcan>
��%
<TheLink>
hope you're not using leading zeros :P
<choozy>
Lol
Thomas___ has joined #asahi
<choozy>
Why is it necessary to write a hypervisor instead of using something like KVM on top of the current Asahi?
<agraf>
choozy: With KVM, Linux will take ownership of most underlying hardware, so you would need to create a virtual platform on top. With the m1n1 hypervisor, we can leave ownership of most hardware with macOS and then trace its access to it.
<choozy>
Ah
kubes has joined #asahi
kubes has quit []
pugguu has quit [Ping timeout: 480 seconds]
dottedmag has quit [Quit: QUIT]
dottedmag has joined #asahi
<sorear>
if it wasn't clear this is a very specialized hypervisor for hardware documentation, normal users will use KVM