ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
<eiln>
marcan: created a pull in m1n1 with the ane tunables
zkrx has quit [Remote host closed the connection]
zkrx has joined #asahi-dev
mini0n has joined #asahi-dev
barrett has quit [Ping timeout: 480 seconds]
zef_ has joined #asahi-dev
zef has quit [Ping timeout: 480 seconds]
sirn has quit [Read error: Connection reset by peer]
sirn has joined #asahi-dev
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #asahi-dev
barrett has joined #asahi-dev
<marcan>
eiln: saw that, might wait until the current crop of kernel issues/release is sorted before merging new stuff though
<amarioguy>
should be sufficient, poke me if you need anything else tested, testing config was t6002 Mac Studio in m1n1 console
nsklaus has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<maz>
amarioguy: cool, thanks. one question I have is whether there is a control that allows the IMPDEF PMU to count at EL1&0 with HCR_EL2.{E2H,TGE}={1,0}. From what I've seen, it normally doesn't count when running a guest.
<maz>
given that the KVM virtual PMU is backed by perf counters, we would need the PMU to be able to count whilst running the guest.
<maz>
I'm very reluctant to make things up.
<marcan>
asahi-6.2-7 pushed de-mailboxed
<amarioguy>
maz: got it, there should be smth that allows that given apple's official virt solution needs that to work
<marcan>
not as much of a perf improvement as I'd hoped, but the diffstat is ~-50 lines of code vs upstream and might have fixed the reboot issues and obsoletes a pile of downstream mailbox patches we had trouble upstreaming that fixed various broken stuff
<maz>
amarioguy: I'd hope so. the alternative is to snapshot the cycle counter on each entry/exit of the guest, and only expose that.
<maz>
also, when you say that PMMIR_EL1 is not trapped: does it mean it undefs at EL1? or is always readable from EL1?
<amarioguy>
maz: not trapped as in it's undefined
<maz>
amarioguy: OK, so they don't pretend to have PMUv3p4. I guess that leaves us with PMUv3p1 at best.
<maz>
marcan: out of morbid curiosity, what was the issue with mailbox?
<maz>
amarioguy: in your description, you're saying "Apple specific PMU control reg writes still permitted when bit 56 is set (because the apple specific controls for PMCs/Uncore PMCs are independently trapped by bits 57-58)"
<amarioguy>
maz: that was mainly to clarify that this bit does not affect read/write of the impdef stuff since that's controlled by separate bits
<amarioguy>
think you mentioned wanting to know the effects of this on that?
<maz>
they still honour HCR_EL2.TIDCP, right?
<maz>
if they don't, we have a bigger p[roblem...
<amarioguy>
the impdef pmus?
<maz>
yup
<amarioguy>
testing that now
<maz>
they should trap irrespective of the IMPDEF bits if HCR_EL2.TIDCP is set.
<maz>
(and I mean when accessed from EL1, of course)
<amarioguy>
maz: good news, when HCR_EL2.TIDCP = 1, all the impdef PMU regs i tested reads/writes from EL1 with, trap to EL2
<amarioguy>
ESR_EL1 = 0x6239fc11
<amarioguy>
marcan: quick feature request, can we please get an "bit set/bit clear" msr command in m1n1, would make bit twiddling much easier :P
<amarioguy>
(sorta joking but you know would be nice)
<amarioguy>
(test results are serious - that is the behavior i see, and the same is true of the Uncore PMCs too)
<marcan>
amarioguy: hint: s3_1_c15_c7_2 has the same layout as PMCR1_EL1, it's probably PMCR1_EL12 (and then s3_1_c15_c6_2 is probably PMCR1_EL2)
<marcan>
there's probably a whole set of parallel impdef PMC registers for {E2H,TGE}={1,0}, as there is for most apple impdef stuff
<amarioguy>
ahhhh crap
<amarioguy>
gotta redo some test then
<amarioguy>
wait my tests were with bit 27 = 0
<amarioguy>
just double checked
<marcan>
amarioguy: the PMCs definitely count for me in EL1 with those bits set, and possibly others (checking)
<marcan>
confirmed, that seems to be all you need to get them to count in EL1
<marcan>
also s3_1_c15_c11_0 is some kind of global enable, if that is 0 the PMCs don't count (but it's 0xfffff by default)
<marcan>
maz: re mailbox, it's just bad. atomic mode bugs, a fixed-size queue that errors out if full instead of blocking, missing a way to set up the mailbox and *then* enable reception once everything is set up, etc.
<marcan>
and it doesn't *do* anything for us, there is no useful common functionality whatsoever
<amarioguy>
marcan: ah thanks for checking
<marcan>
I literally took the mailbox driver, ripped out the parts that talk to the subsystem, and just made rtkit call into it directly
<marcan>
now it's faster and has fewer bugs and nonsense
<amarioguy>
still not the best at MSR bit twiddling :D
<sven>
still a pity that you didn't get much performance improvements
<marcan>
yeah, oh well
<marcan>
maybe the old driver would've gotten more actually
<marcan>
the synchronous one
<marcan>
with the async one the CPU is less in the way
<sven>
i would've expected those two or three context switches for each send to matter more but I guess the CPU is just too fast
<marcan>
it's quite possible some benchmarks will notice more
<marcan>
actually I should've tested sync mode...
<marcan>
okaaay terrain 147 -> 166 in sync mode
<marcan>
that's 13% faster
<sven>
dcp will full debug spew probably also won't overflow it anymore now
<marcan>
wait no I got it backwards, it's faster with mailbox lol
<marcan>
this is dumb
<marcan>
maybe it's just because it slightly multithreads where it otherwise wouldn't?
<sven>
huh
<marcan>
OTOH if actually hitting the hardware is the bottleneck, then my dedup thing should help in normal mode once I implement it
<jannau>
terrain fps results weren't that stable for me over multiple runs
<sven>
you could also try to convert that threaded recv irq to a real irq handler
<sven>
iirc it was threaded because the original rtkit implementation used that as a hack
<sven>
though I guess that helps both versions :)
<marcan>
oh I don't think we need that any more
<marcan>
rtkit already has a workqueue
<sven>
yeah
<sven>
even the initial submission I did had that
<sven>
I just forgot to remove it from mailbox
<amarioguy>
sounds like this mailbox subsystem is... """interesting"""
<sven>
the DT abstractions are nice and in theory the idea of mailbox also makes sense. it's just that there are >10 different hw implementations that make different assumptions about the API
<sven>
and the API was really built for very simple and dumb mailboxes
<sven>
it would be nice to improve that api ofc but the last tries weren't very successful *shrug*
darkapex has joined #asahi-dev
darkapex1 has quit [Ping timeout: 480 seconds]
darkapex1 has joined #asahi-dev
barrett has joined #asahi-dev
barrett has quit [Remote host closed the connection]
darkapex has quit [Ping timeout: 480 seconds]
Bey0ndB1nary has joined #asahi-dev
darkapex1 has quit []
darkapex has joined #asahi-dev
j`ey_ is now known as j`ey
kujeger has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
kujeger has joined #asahi-dev
balrog has quit [Quit: Bye]
nsklaus has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nsklaus has joined #asahi-dev
darkapex1 has joined #asahi-dev
darkapex has quit [Ping timeout: 480 seconds]
eiln has quit [Remote host closed the connection]
balrog has joined #asahi-dev
<jannau>
something strange: with mbox, rtkit, sart and nvme built-in the nvme probes only after other rtkit drivers (those start probing after waiting 10s on the root device)
<jannau>
shouldn't APPLE_RTKIT select APPLE_MBOX?
<marcan>
it doesn't?
<marcan>
oh wait this is the DT thing isn't it. ugh.
<marcan>
argh.
<marcan>
dammit.
<marcan>
okay fine I'll make it a real driver
<jannau>
Kconfig for mbox and rtkit is fine, I was surprised that could deselect APPLE_MBOX. That seems to be caused by ASAHI selecting RTKIT. Kconfig documentation warns about this
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
<jannau>
I guess the short term fix is that RUST_APPLE_RTKIT needs to slect APPLE_MBOX
<marcan>
would be nice to have someone with the ISO layout on that one
<marcan>
then I'm just missing ANSI M2 Pro
<marcan>
but I think that's 0?
bluetail4 has joined #asahi-dev
<axboe>
I'll get my m2 installed as soon as it's in the installer...
<jannau>
japanese air has Keyboard type 8?
<marcan>
yes
<jannau>
axboe: not yet speaking about the m2 pro/max models
<marcan>
that's where the %3 guess came from, and the assumption that there was a model they scrapped between those two (or out of order)
<marcan>
but it looks like the ordering doesn't follow a neat pattern like that
<axboe>
jannau: oh...
nsklaus has joined #asahi-dev
nsklaus has quit []
nsklaus has joined #asahi-dev
nsklaus has quit []
* maz
holds off buying another M2 until there is something that actually boots.
bluetail has quit [Ping timeout: 480 seconds]
<jannau>
maybe we should just use kblang-calibration, we still have to make a distinction between different iso layouts in hid-apple
bluetail4 has quit [Ping timeout: 480 seconds]
<marcan>
yes, the problem is that doesn't map 1:1 to the HID codes IIRC
<marcan>
though we can map it N:1 of course
<marcan>
jannau: does hid-apple actually need to know more than iso/ansi/jis? I thought it only checked that (it can only check that, those are the only three types ever exposed in hid->country)
psykose has quit [Remote host closed the connection]
psykose has joined #asahi-dev
veeyee has quit [Quit: Leaving.]
<marcan>
OTOH using kblang-calibration would mean we don't need to touch the driver for new devices...
<marcan>
anyway, the table so far pushed to bits/090-spi-hid and asahi-wip (no tag for now)
<marcan>
I should sleep :p
<marcan>
also -asahi10 package in asahi-dev now
<jannau>
hid.country=iso is unfortunately not enough information, there are apple iso layouts which have KEY_GRAVE on KEY_102ND and others not
<jannau>
good night
<marcan>
jannau: I thought that flag was for iso vs non-iso, implying that all ISO layouts needed the quirk by default
<jannau>
I orginally tought so too but it differs between iso english international and german (and a other european languages)
<jannau>
I now suspect it's original intention was to make apple's iso international layout similar to the PC us international layout