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
irradiated_lemmi has joined #asahi
<irradiated_lemmi>
hello, just want to let the team know that i just accidentally deleted (then reverted, thankfully) the "developer quickstart" wiki page. Just wanted to let the devs know in case theres an interest in taking measures to avoid this again
<irradiated_lemmi>
* hello, just want to let the team know that i just accidentally deleted (then reverted, thankfully) the "developer quickstart" wiki page. Just wanted to let the devs know in case theres an interest in taking measures to prevent this happening again
<irradiated_lemmi>
* hello, just want to let the team know that i just accidentally deleted (then reverted, thankfully) the "developer quickstart" wiki page. Just wanted to let the devs know in case theres an interest in taking measures to prevent this happening
<irradiated_lemmi>
* hello, just want to let the team know that i just accidentally deleted (then reverted, thankfully) the "developer quickstart" wiki page. Just wanted to let the devs know in case theres an interest in taking measures to prevent this happening in future
sven- has joined #asahi
riker77_ has joined #asahi
riker77 has quit [Ping timeout: 260 seconds]
riker77_ is now known as riker77
BaughnLogBot has quit [Quit: ZNC 1.6.2+deb1 - http://znc.in]
BaughnLogBot has joined #asahi
BaughnLogBot has joined #asahi
BaughnLogBot has quit [Client Quit]
ky0ko has joined #asahi
el1x has quit [Read error: Connection reset by peer]
<marcan>
irradiated_lemmi: the wiki is deliberately open; if abuse becomes a problem we'll figure out what to do about it
ky0ko has quit [Remote host closed the connection]
delogips[m] has joined #asahi
marvin24 has quit [Ping timeout: 240 seconds]
marvin24 has joined #asahi
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
danilonc has joined #asahi
VinDuv has joined #asahi
ephe_meral has joined #asahi
ephe_meral has quit [Ping timeout: 272 seconds]
VinDuv has quit [Quit: Leaving.]
nyx_o has quit [Ping timeout: 265 seconds]
nyx_o has joined #asahi
<Glanzmann>
https://pbot.rmdir.de/LBauZT4TdjswTDVa-q6tyw so macos shuts down the nvme when they don't need it? Otherwise I can't explain the 22 hours. Because I use the laptop a lot in the last 3 months.
<marcan>
Glanzmann: it's probably sleep mode, yes
<marcan>
the way mobile devices get non-terrible battery life is by aggressively putting everything into low power mode when not in use
<marcan>
though 216 power cycles seems low for that
<marcan>
but maybe certain sleep modes do not count towards power on hours, but do not count as a power cycle
<marcan>
it's also possible the thing is literally counting integer hours
<marcan>
and so usage periods <1hr before a sleep event are not counted
<marcan>
that would make sense I'd say - it powers on the nvme when you wake up the computer, and powers it down when it goes into sleep mode, and short wakes do not count
danilonc has quit [Quit: Connection closed for inactivity]
<jix>
marcan: "but maybe certain sleep modes do not count towards power on hours, but do not count as a power cycle" that's the only way I can explain the numbers I see on my samsung nvme SSD here (in a non-apple desktop)
<marcan>
I have a bunch of ideas but nothing concrete written down, so a lot of the beginning will be sketching out the details of the architecture and specific parts used
<marcan>
cc rwhitby :)
<j`ey>
so about 13h from now
lutzio2000 has joined #asahi
lutzio2000 has quit [Client Quit]
qyousef has quit [Ping timeout: 264 seconds]
qyousef has joined #asahi
robinp_ has joined #asahi
robinp has quit [Ping timeout: 260 seconds]
<modwizcode>
Sounds fun
Tokamak_ has joined #asahi
Tokamak has quit [Ping timeout: 240 seconds]
<never_released>
marcan: I did remember something
<never_released>
you can't just detect CPU implementer ID and enable FIQ
<never_released>
because
<never_released>
you'll break VMs
<never_released>
when doing that
<never_released>
(for those who expose the host CPU implementer/model)
<maz>
never_released: only if these VMs get a FIQ injected, which shouldn't happen if they keep their Group-0 disabled.
<j`ey>
why would it break VMs?
<never_released>
maz: yeah, but that's still a divergence
<never_released>
compared to what it should be
<maz>
never_released: what difference? VM asks for a group-0 interrupt, VM gets a group-0 interrupt...
<never_released>
it would convert a panic to a non-panic
<never_released>
which shouldn't happen in a regular scenario anyway
<maz>
never_released: well, it would turn a panic in a livelock, but this is a pretty theoretical case. it is likely that we'll do without all of that anyway.
<never_released>
and remember that Asahi will not be the only boot path for this
<never_released>
think that I'll add ACPI bindings eventually - for the Windows-booting firmware
<never_released>
which has the downside of no EL2 for guest with current approach
<marcan>
A VM would be using GIC anyway, so if it asks for a group-0 interrupt, it would get one... and end up at the handler anyway... but it wouldn't ask for one...
<marcan>
this is all pretty hypothetical :)
<never_released>
I mean
<never_released>
that applies to $EVERY_ARM64_SYSTEM
<marcan>
yeah, but the panic on fiq thing is presumably largely there so we find out when some system is delivering FIQs when it shouldn't; the specific case of a GIC-based VM on M1 is a pretty small subset of that :)
<marcan>
either way, as maz said we're probably changing this anyway
<marcan>
and also, given the way FIQs work on these things, you'd better implement them if you're going to claim you're these CPUs by ID
<marcan>
since there's a bunch of proprietary stuff in system registers which is arguably tied to the CPU type
<marcan>
this needs more discussion and I don't know what specific policy there is here for kvm but... on the face of it, if you're going to claim to be an M1, you ought to be implementing all the M1 vendor regs; at the *very* least all the userspace-visible ones, and PMCs can be made userspace-visible, and those can deliver FIQs, soooo :-)
<never_released>
marcan: makes me wonder
<never_released>
how will macOS VMs officially work on this
<marcan>
probably vGIC, given that they have one, but I wonder too
<marcan>
also probably, with a pile of hacks
<marcan>
we know they're not allergic to those
<marcan>
if they cared about sensible design they'd have had a damn FIQ status/mask register
<maz>
KVM only presents architectural features to guest.
<maz>
so there will be no PMU for M1 guests under KVM.
<modwizcode>
Are you positive it doesn't have an FIQ status/mask reg at all by this point?
<marcan>
maz: what's the policy for MIDR values for kvm guests?
<marcan>
modwizcode: I brute-forced all the registers, found nothing
<modwizcode>
maz: That seems like a rather arbitrary limitation? Isn't there benefit for having that
<modwizcode>
that sucks marcan
<maz>
marcan: they see the real MIDR value to be able to apply workarounds.
<maz>
modwizcode: it's a deliberate choice.
<maz>
modwizcode: the spectrum of the architecture is wide enough to avoid adding silly implementors' hacks.
<marcan>
hmm... in that case I guess we're back to looking at the apple,arm-platform compatible for any non-DT-instantiated proprietary stuff, if we want to make kvm's life easy
<marcan>
assuming there aren't feature bits
<marcan>
which is another story, Apple *does* have feature bits, but... good luck guessing what they are unless existing code uses them
<never_released>
Apple-specific features
<never_released>
are in the Apple features register
<never_released>
by convention
<marcan>
yes
<marcan>
but we can't easily know what any given bit means unless it's either documented or tested for in some obvious piece of code
<never_released>
know however that there is two kinds of Apple features
<never_released>
the ones that you can expose
<marcan>
and given that Apple kernels are linux-old-arm32-style #ifdef land, well, they don't often test for anything
<never_released>
and the ones that make a whole new register file appear
<never_released>
marcan: read the refactoring doc file (in the XNU tree)
<never_released>
they're progressively changing this
<marcan>
I don't see any calls to ml_feature_supported in 11.0.1 / 11.1 / 11.2, you mean pre-big sur?
<never_released>
I meant that XNU doesn't even use those features
<never_released>
at all
<never_released>
anymore
<never_released>
(well, open-source XNU)
<never_released>
even APRR disappeared... so chances of seeing ml_feature_supported used are slim
<j`ey>
so theyre changing to not use #ifdef, by removing all that code from open source XNU!
<never_released>
you can put it that way
<modwizcode>
How are they removing the APRR stuff from the core of XNU? or is it still in there but stripped out before release? APRR seems pretty low level
<marcan>
they have these preprocessors that strip out specific blocks of #ifdef