14:33 <Eighth_Doctor> marcan: this might be a dumb question, but has anyone reached out to Apple about the IOMMUs thing to see if maybe a future iteration could support 4K pages?

14:34 <Eighth_Doctor> (for reference: https://twitter.com/marcan42/status/1398301935594139651)

14:35 <chadmed> i reckon they specifically did that for this reason. "an unsigned kernel, if you can keep it" type deal

14:36 <chadmed> its unlikely anyone will get any sort of official word out of apple on the matter either, this is all extremely antithetical to how they want consumers to use their devices

14:37 <sven> yeah, we shouldn't expect to get 4k iommu pages

14:38 <chadmed> everyone should just use gentoo on their macs and build their own kernels ;)

14:38 <sven> but i'll see if i can get a patch accepted that makes the iommu framework play nicely with a bigger granule once the initial DART version (+ some other important drivers) are upstream

14:39 <sven> fwiw, the current version boots on 4k kernels in bypass mode. what probably won't work for a while is thunderbolt and wifi

14:39 <chadmed> does anything good come of bypassing the IOMMU/s though?

14:40 <sven> not imho

14:40 <sven> but at least you could boot a normal distro installer that way and then switch to a custom kernel later on

14:40 <sven> might make adoption at the beginning easier

14:41 <chadmed> thats true, though i think all the messing around with m1n1 might preclude the kinds of folks that wouldnt be able to just build their own kernel anyway

14:41 <sven> the goal is to eventually have something like "boot into 1TR, open a terminal and run curl alx.sh | bash"

14:41 <chadmed> so maybe a discussion to be had once we have a very simple way for m1n1 to work without screwing around with double macos partitions and stuff

14:41 <chadmed> yeah

14:42 <sven> yeah

14:42 <sven> right now i expect everyone to use a kernel with 16k pages anyway since only the basics are upstreamed so far

14:42 <Eighth_Doctor> sure

14:43 <Eighth_Doctor> chadmed: wouldn't it be easier for Apple to offer a signing process for Linux instead?

14:43 <Eighth_Doctor> rather than using obstructions like this to break access to hardware?

14:43 <chadmed> why would they ever want to do that

14:44 <sven> they built the hardware that way because it works nicely with mac os. they don't care about anything else

14:44 <chadmed> the hardware isnt inaccessible because the kernel is unsigned anyway, its inaccessible because theres no documentation and whatever we have is from prodding at MMIO and lucky shared DNA with exynos

14:44 <sven> they're not trying to obstruct - they just have no reason to make the hw more complex

14:44 <chadmed> they will never ever ever facilitate or officially support booting anything other than macos in an apfs container

14:45 <chadmed> they only "let" you boot an unsigned kernel because the EU might have raised an eyebrow if they didnt

14:45 <sven> that's just speculation though. could've also been internal pressure from their engineers who also want linux on those machines ;)

14:46 <chadmed> that would be kinda cool if true or plausible lmao

14:47 <chadmed> revenge of the nerds, retaking silicon valley from the marketing goons

14:48 <jix> my guess is that they have a few different reasons and there isn't a single one that was the deciding factor, but I'm also just speculating

14:50 <chadmed> well yeah who knows what crazy stuff they have running on these machines in the lab

14:50 <chadmed> SGI IRIX maybe

14:50 <sven> we know that they have an internal linux port from some xnu comments

14:56 <_jannau_> the alternate kernel boot is there clearly by choice for https://twitter.com/XenoKovah/status/1370131505620652038

14:58 <_jannau_> and https://twitter.com/NikolajSchlej/status/1339792332388933632

15:04 <kettenis> Apple runs a lot of infrastructure and they might be interested in running that on ARM platforms

15:05 <kettenis> And I doubt all that infrastructure runs on MacOS ;)

16:25 <marcan> chadmed: apple isn't deliberately breaking us in any way

16:26 <marcan> they built the entire bootpolicy system so things like asahi can exist

16:26 <marcan> but they also aren't going to spend engineering effort into helping things that only we care about

16:26 <marcan> asahi isn't something they want to hinder at all

16:26 <marcan> "here's code execution, have fun" is their take

16:26 <marcan> and I'm fine with that

16:27 <marcan> macOS updates so far have made our lives *easier*, not *harder:

16:27 <marcan> they clearly aren't trying to trip us up

16:28 <marcan> if asahi gets big enough that people rely on it, I expect apple to tacitly try not to break us too badly for no good reason

16:29 <marcan> the 4K/16K page thing is how it is because it's exactly what they need

16:29 <marcan> they only care about 16K systemwide, except they needed 4K in userspace in the CPU for Rosetta. that's it.

16:29 <marcan> (and they also support it in kernelspace because not doing so would be even weird and architecture-breaking and bizarre)

16:29 <marcan> *even more

16:42 <kettenis> so as far as I can tell all devices that do DMA are cache coherent

16:42 <kettenis> which means we need to add som "dma-coherent" properties to the device tree I think

16:58 <marcan> yeah, I didn't find any noncoherence

16:59 <marcan> framebuffer is one that would be obvious if it weren't coherent

17:06 <kettenis> so we can probably put it on the "soc" node next to the "nonposted-mmio" property

17:10 <kettenis> it probably makes sense to move the "interrupt-parent" property up as well to avoid repeating it for every device

17:11 <kettenis> that one tends to go on the root node though

17:41 <sven> yeah, i didn't see any non-coherence either even when the iommus are in bypass mode