06:53 <marcan> alyssa: if it's any consolation my experience with PCIe amounts to making it run over RS-232. not exactly applicable to our use case :3

09:39 <jeffmiw> marcan: when running macos under the hypervisor, if I want to get the symbols for the extensions, I suppose I need the corresponding dSYM file ? Is there a way to load all of them at once ? will a concatenation of them in a single file will do the job ? I suppose not as the proxyclient/macho loader expects only one SYMTAB macho cmd

09:39 <marcan> I've never actually done that (symbols for extensions)

09:39 <marcan> patches welcome :-)

09:40 <marcan> haven't even looked into how that's supposed to work

09:40 <marcan> most of the early HV bringup work that benefited from backtraces was on stuff in the core kernel

09:41 <jeffmiw> ok, so I'm not missing something or doing it wrongly then :). I'll see if I can propose something useful then.

12:26 <landscape15[m]> So if asahi creates a standard EFI partition i suppose you can run every Aarch64 EFI based OS, if properly loaded with compatible drivers. Maybe also W10 on arm...

12:29 <opticron> I wonder if it would be easier to write up shims for virtual devices that W10 already understands

12:29 <opticron> otherwise W10 is going to have a hellish driver problem to deal with across the board

12:35 <landscape15[m]> opticron: Yes, but i don't think there will be a development due to copyright issues and DMCA.

12:36 <landscape15[m]> Maybe Microsoft is following marcan work :)

12:36 <marcan> landscape15[m]: windows requires kernel changes that only microsoft can do

12:36 <marcan> it will never run on these machines without either a VM or MS's help

12:36 <j_ey> can windows run under kvm?

12:37 <marcan> yes

12:37 <marcan> I don't expect any issues there

12:37 <marcan> it already works on qemu on macos, would be the same on linux

12:38 <landscape15[m]> Yeah, and nobody wants to pay Parallels to run Windows. I think qemu (also UTM) will be the future.

12:39 <jn> i suppose a linux/KVM system could be made so quiet that it _looks_ like windows booting base-metal on an M1 mac. start one VM in fullscreen, and pass through all relevant hardware (probably via emulation of a standard HW interface, rather than IOMMU-based pass-through)

12:40 <j_ey> jn: we could have done that for linux isntead of asahi :P

12:41 <jn> j_ey: but that would have taken away the fun if porting linux :)

12:41 <landscape15[m]> marcan: So basically every open source kernel can be adapted?

12:42 <marcan> sure, with effort

12:42 <j_ey> landscape15[m]: kettenis here works on OpenBSD for M1

12:42 <landscape15[m]> Ok thanks.

12:44 <landscape15[m]> Yes i found out. I don't like OpenBSD very much.

12:45 <j_ey> well the point is that you can port things to the m1 :P

12:46 <landscape15[m]> j_ey:

12:46 <landscape15[m]> Yes but i'm happier with Linux :)

12:54 <alyssa> marcan: sven: maz: El reg is onto us

12:54 <alyssa> https://www.theregister.com/2021/08/18/asahi_linux_progress_apple_silicon/

12:58 <marcan> heh

12:59 <alyssa> > "I've started using Linux on M1 as my workstation for Panfrost development, so this should have 40 hours of testing by this time next week," Panfrost being an open-source driver project for Arm Mali GPUs.

12:59 <alyssa> It's thursday morning so I can say, 24h in, nothing has broken spectacularly yet :-p

13:02 <marcan> speaking of: alyssa, sven et al: I need y'all to put together a bit of a summary of what patchsets work and you're currently using (ideally with git refs :p)

13:03 <alyssa> marcan: Ahem..

13:03 <marcan> I'm going to put together some kind of merge bot and review things

13:03 <jn> hmm, sort of a tiny linux-next for asahi

13:03 <marcan> yes

13:04 <alyssa> I've been doing that over in mu-one

13:04 <alyssa> https://github.com/mu-one/linux/commits/20210816 is my current branch (haven't done kernel stuff in a few days)

13:04 <alyssa> mu-one/linux master tracks linux-next

13:05 <alyssa> feature branches are for specific mainlining patch sets

13:05 <marcan> mu-one?

13:05 <alyssa> date branches are everything in one rebased on top of next, and are literally the kernels I'm running on a given date

13:05 <alyssa> marcan: well the plan was to do this in asahilinux but then you nak'd that pretty hard......

13:06 <marcan> what, the corellium stuff?

13:06 <alyssa> er, that too I guess

13:06 <marcan> or was there something else?

13:07 <alyssa> Uhmm

13:07 <marcan> I'm confused about what I nak'd

13:07 <alyssa> Sven and I started reviewing PRs over in asahilinux/linux with the intent of using that as the asahi-next

13:08 <marcan> oh *that*?

13:08 <alyssa> and then you started talking a merge bot and now we can't merge anything there until you added said bot and uhm

13:08 <marcan> I meant don't make a "main devel" branch with a bunch of PRs, because I intend to automate that branch and then the PRs would get in the way

13:08 <alyssa> so I opened a repo as a new downstream that I could merge with 'now'

13:09 <marcan> you can do it in feature branches and you can have your own playground branches or whatever

13:09 <alyssa> I'm not entirely sure how that would work as things evolve while upstreaming

13:09 <marcan> I never meant you couldn't use the asahi repo

13:09 <alyssa> automatable, pleasant mainlining, and single branch that never regresses -- pick 2 of 3

13:10 <alyssa> (the reason for date branches is so that things can be constantly rebased. The git history of date branches are not stable. The features should be.)

13:11 <alyssa> and, uhmm, I deal with technical issues better than personal ones. so clicking the github fork buttons on torvalds' repo was the easy way to focus on PCIe patches and not having a big ol' awkward group chat you with and sven.

13:11 <marcan> yeah that's very you

13:11 <marcan> :p

13:12 <alyssa> you love me the way i am :p

13:21 <alyssa> marcan: But to answer the original question, I'm dailydriver the linked date branch. PCIe + dwc3 device tree + pinctrl + reboot

13:21 <alyssa> driving

13:21 <alyssa> I haven't cherrypicked NVMe yet from sven since that's still undergoing rapid change

13:22 <alyssa> I have a cherrypick of sven's IOP driver and Corellium's SMC adapted for said IOP driver and mainline _np but it's not in the dtae branch since it wasn't useful to me yet

13:46 <sven> marcan: uh, i think the most interesting one is probably nvme/new. that's still heavily WIP though, but i hope to get at least the mailbox part into a sane state this evening

13:49 <sven> there's i2c/dev which i abandoned for some reason and which didn't do anything very useful except for enumerating that usb pd chip because the gpio interrupt support was missing

13:50 <sven> and there's also dart/4kpgsize which makes dart work on 4k kernels, but i still need to convince myself about one commit in there. seems to work though

14:10 <maz> alyssa: high quality stuff, I'm sure!

14:22 <alyssa> maz: just as high quality as my pcie patches ;_p