05:47 <Jamie[m]1> Is there a known thing I need to do to avoid kernel panics under the hypervisor on modern macos versions?

05:48 <Jamie[m]1> I'm running the stock 12.3 kernel copied out of my /System/Volumes/Preboot and extracted with img4tool, booted with "debug=0x14e serial=3 apcie=0xfffffffe -enable-kprintf-spam wdt=-1" and no tracing

05:48 <Jamie[m]1> not pausing it either

05:49 <Jamie[m]1> but it dies roughly 10 minutes after boot (not long enough to install the xcode developer tools, i can say for certain :)

05:49 <Jamie[m]1> https://paste.hotplate.co.nz/7PjivdwxUK#+BhBalIexwKZQ7Lznj8U6g

05:53 <Jamie[m]1> (t6000 j316)

05:58 <Jamie[m]1> hmm, maybe it's actually caused by installing the xcode command line tools...

06:11 <jannau> Jamie[m]1: I haven't on t6001, panics either on boot or on suspend but I'm also not using macos extensively under the HV. mostly short sessions to trace kbd or dcp

06:12 <jannau> the panic reason ("AMCC2 PLANE3 UNEXP_RT_HIT_DIR error: ...") looks like it could be caused by something m1n1 did

06:12 <Jamie[m]1> hmm, looks like this time it's still alive after 29 minutes and has successfully installed the tools, so i guess it's something that happens somewhat at random

06:19 <rqou_> i regularly get panics on t6001 if i pause for too long

06:19 <Jamie[m]1> yeah, no pausing in this case

06:19 <rqou_> but synchronous tracing seems "fine" for short sessions, like jannau said

06:20 <rqou_> not pausing seems to have worked for me, but the hv is definitely not super reliable

06:20 <rqou_> works for very basic tracing

06:20 <Jamie[m]1> oh, i suppose i can use chainload.py to boot macos directly, while i'm getting set up for tracing

06:21 <Jamie[m]1> that seems smarter :)

06:23 <Jamie[m]1> hmm, or can i

06:24 <rqou_> i don't have xcode installed on my hacking partition

06:24 <jannau> rqou_: I think macos just auto-suspends/sleeps after a certain amount of inactivity. supporting that properly with the HV is probably not worth the effort. I haven't bothered to check if it goes away if macos is configured to stay on

06:24 <rqou_> i just copy binaries from my real macos install

06:24 <rqou_> jannau: it definitely panics, idk if that's related to suspend or not

06:25 <jannau> the panics I looked at after inactivity were caused by suspend

16:46 <jannau> marcan: have you done any work on the m1 ultra? if not I can work on a m1n1 merge request and fix HV+macos

16:49 <marcan> jannau: go for it :)

16:49 <marcan> was going to maybe do something in the next couple of days, if you want to put that together I'll wait a bit more and clear out my inbox instead

16:50 <marcan> (sorry for being a bit slow the past few days, had to take a bit of a rest after a hectic month)

16:51 <j`ey> there's the 10Gbe m1n1 change too

16:52 <jannau> I'll work on it over the weekend and post what I get done until sunday

16:54 <jannau> no problem. what we have right now works and was good enough to get the first user going

17:22 <marcan> Jamie[m]1, jannau: that panic reason means something like a framebuffer cache line ended up in the CPU cache, which if it happens after initial boot could mean it was randomly caused by speculation in HV code

17:23 <marcan> I'm... not entirely sure what the right fix for that would be. maybe map all guest RAM as noncacheable in the HV stage1 PTEs, since we can't know where framebuffers land? and maybe also all the carveouts in general?

17:25 <marcan> tbh, given we know those cache lines don't actually *break* anything at least the vast majority of the time, I'd first look for a xnu bootarg to turn off those panics

17:25 <marcan> I bet there is one, and if there isn't maybe we can just hook that to disable it at the hardware level

17:27 <marcan> incidentally, those exceptions don't exist on t8103 (or don't get enabled)

23:57 <rqou_> sven: i found an unexpected (to me) limitation of your 4k iommu patch -- it breaks vfio-pci (i promise i have a not-entirely-terrible reason for wanting this)

23:58 <rqou_> notably it fails on vfio_set_iommu, before attempting to map any memory

23:58 <rqou_> as for the reason i was trying this, i was hoping i would be able to prototype something that pokes at the bluetooth hardware from linux userspace