<mal>
bamse: how strict is the kernel rule of not breaking existing compatibility strings, while adding msm8974 iommu support I noticed the current qcom_iommu is really v2 not v1 like it's now named, that existing driver was made for msm8916 which uses v2 in downstream and msm8974 uses v1, the differences are not that big though, not sure how to handle adding the needed things to the driver when the naming is
<aka_[m]>
out of flat i cannot even find what kind of design is that mmu
<aka_[m]>
8916/fam-b ones are MMU500 with some HYP hacks
<aka_[m]>
uh 8974 layout is pretty smillar to 8953
<aka_[m]>
so maybe also some mmu500 stuff
<Mis012[m]>
mal: pretty sure they're all standard arm design with different register groups blocked from being accessed by Linux courtest of the hyp progrramming the XPUs in such way
<Mis012[m]>
*courtesy
<aka_[m]>
<Mis012[m]> "mal: pretty sure they're all..." <- now how to defeat it and use smmu-v2 driver
<aka_[m]>
besides "just swap soc bro"
<Mis012[m]>
if you want to use the generic smmu driver, you need code exec in hyp
<Mis012[m]>
which some SoCs do have
<Mis012[m]>
I mean some SoCs do have vulnerable fw available
<aka_[m]>
but still you need custom stub or something?
<Mis012[m]>
I mean... putting privilege escalation in Linux seems meh
<Mis012[m]>
could probably get it into u-boot though
<Mis012[m]>
what you will need to do is manage all the stuff that the hyp normally manages from Linux
<Mis012[m]>
wrt the smmu
<Mis012[m]>
smmus I guess
<mal>
I have that qcom_iommu working on msm8974 but it just needs some things disabled and some things added to get it working, just wondering how to handle those
<aka_[m]>
if v2 iommu is marked as v1 then you can mark v1 as v0 xD
<Mis012[m]>
it's it fun when fw-dependent magic needs more different drivers compared to one driver for the base hw
<aka_[m]>
and its not marked as v0 iommu byt as apq8064
<mal>
yeah
<Mis012[m]>
like it's SoC-dependent and not fw-dependent...
<mal>
aka_[m]: in msm8916 kernel they just took the v1 driver and changes it a bit and renamed the compatible string but still kept v1 in the driver filename so that makes it even more comnfusing
<aka_[m]>
maybe it would be easier to call it v0 and just provide some docs which will explain that both iommus are based on mmu500 design and how they map to downstream
<aka_[m]>
mal: there are bit more hacks later to this
<mal>
probably yeah
<Mis012[m]>
they're not "based on mmu500"
<minecrell>
aka_[m]: no, the 8916 smmu is destroyed by TZ and not hyp
<aka_[m]>
msm8916 appears to work fine but 8976 have secure contexts which are bombs
<Mis012[m]>
they're literal mmu500 where you're not allowed to touch parts of it
<aka_[m]>
im bit lost on structure of secure world
<Mis012[m]>
which is however a matter of sw configuration
<aka_[m]>
ah right Hypervisor is different EL than TZ firmware
<aka_[m]>
mal: in theory i was able to just not define these untouchable context banks and it works fine with v1
<mal>
hmm
<Mis012[m]>
aka_: well, the way qcom architectured the XPUs etc, HLOS, TZ and HYP are in many cases treated the same as entirely different cpu cores
<Mis012[m]>
so what goes in HYP and what goes in TZ is again a matter of sw configuration
<minecrell>
Mis012[m]: the 8974 smmu isn't a MMU-500
<minecrell>
it seems to be something implementing SMMUv1 spec only, not SMMUv2
<Mis012[m]>
minecrell: ok, not *that* one
<minecrell>
so either some other ARM MMU-XYZ or custom qcom thing
* Mis012[m]
doubts it's qcom thing
<Mis012[m]>
what's the address?
<minecrell>
Mis012[m]: qcom implementing ARM specs is not unprecedented, they did that for GICv2
<Mis012[m]>
so a NIH copy of MMU-XYZ?
<Mis012[m]>
what would be the benefit there
<minecrell>
dunno what "NIH" means
<aka_[m]>
acronym for "not invented here"
<minecrell>
ah
<aka_[m]>
minecrell: so mmu specs describe what kind of things have to be implemented and then vendors can go and do whatever they like and implement their own stuff?
<aka_[m]>
so in theory some fields will always be same across different mmus
<minecrell>
There is SMMUv2 -> MMU-500. GICv2 -> GIC-400. ARMv8.0 -> Cortex-A53
<mal>
also intesresting that in mainline for msm8916 the non-secure iommu init is not implemented at all
<aka_[m]>
its missleading, because smmuv2 can sound just like qsmmu-v2
<mal>
ah, wait, all the iommus are secure in msm8916
<aka_[m]>
mal: well qcom_iommu driver does not touch global register space
<Mis012[m]>
on existing msm8916 TZ fw
<Mis012[m]>
hm, SMMU_IMPLDEF is a thing
<mal>
aka_[m]: I implemented non-secure init for msm8974
<Mis012[m]>
SMMU_IMPLDEF_...
<Mis012[m]>
maybe it's some custom qcom thing after all
<aka_[m]>
this thing also appears on smmu-v2
<Mis012[m]>
the ARM one?
<aka_[m]>
i mean qcom mmu500 impl
<Mis012[m]>
mmu500 is already an implementation
<aka_[m]>
8953 have this binding but noone writes it and it still works
<mal>
in downstream it seems mmu-500 is separated from v2 in some ways, the is "qcom,msm-mmu-500" compatible string which changes some things in the driver
<mal>
and msm8916 is not using that
<aka_[m]>
<mal> "in downstream it seems mmu-500..." <- as i said before
<aka_[m]>
"its complicated"
<aka_[m]>
mmu-500 is driver for recent implementations
<minecrell>
mal: you shouldn't put too much thought into those compatibles as they're likely just chosen randomly for a particular combination of "hardware + firmware + software"
<aka_[m]>
so ones covered by qcom-smmu-v2 on mainline
<minecrell>
it may sound like it just represents the hardware but it most probably covers the combination of HW+FW+SW
<minecrell>
since 8916 definitely has a MMU-500
<mal>
aka_[m]: that mmu-500 seems to be in arm-smmu-qcom.c in mainline
<mal>
minecrell: ok, I'll then probably use the ugly naming and use v0 for this, or platform based compatibles for some of the special things
<mal>
as it seems mainly msm8226 and msm8974 use the old code, not sure how many other old 32-bit platforms are supported in mainline with this iommu
<aka_[m]>
uh i doubt that there are many 32bit qcom socs in mainline
<aka_[m]>
apq8064/msm8974/msm8226 and that should be all
<minecrell>
honestly I'd probably just use "qcom,msm8974-iommu" for simplicity, something similar is already used for the probably actual v0, "qcom,apq8064-iommu" in the msm_iommu.c driver
<aka_[m]>
v1/v2 just appears to be MMU500 based
<aka_[m]>
v0 is some different beast
<minecrell>
aka_[m]: msm8960? msm8660? msm8909?
<aka_[m]>
uh
<minecrell>
someone was working on msm8210 as well
<aka_[m]>
8909 isnt cut 8916?
<minecrell>
yes but it's still 32-bit
<minecrell>
it's like msm8916 with Cortex-A7 and some other simplifications
<aka_[m]>
well 8953 doesnt have 64bit iommu either...
<aka_[m]>
atleast on old firmwares
<aka_[m]>
for APSS
<aka_[m]>
minecrell: ah wait its A7
<aka_[m]>
so soc alone can't be 64bit
<minecrell>
tbh I wouldn't be surprised if the MMU-500 in 8909 can do 64-bit page tables
<mal>
aka_[m]: minecrell: msm8210/msm8610 uses v0 not v1
<mal>
and msm8909 uses v2 so looks like only msm8226, msm8974 and msm8994 might be using v1
<minecrell>
wuut v0
<mal>
v0 in downstream naming so that msm_iommu.c in mainline
<minecrell>
mal: have you checked if v0 looks similar to the msm_iommu.c in mainline? it was a half guess tbh
<minecrell>
yeah the code seems similar
<minecrell>
mal: apq8084 seems v1 as well
<mal>
yes but isn't that pretty much msm8974 anyway
<minecrell>
well
<mal>
not quite but reasonably close maybe
<minecrell>
I guess you could argue 8226, 8974, 8084, 8994 are all pretty similar :p
<mal>
8226 and 8974 use quite many same things at least
<mal>
so I'll then use msm8974 compatible for the special things for now instead of v0
<Mis012[m]>
minecrell: mhm, so APPS_TCU on sdm845 is MMU500 @ 15000000
<Mis012[m]>
on 8974 I can't find anything for APPS that fits MMU
<Mis012[m]>
*matches
<mal>
what do you mean?
<aka_[m]>
<Mis012[m]> "on 8974 I can't find anything..." <- no apps mmu
<aka_[m]>
MM_MMU
<aka_[m]>
in flat
<Mis012[m]>
MM sounds like MultiMedia
<aka_[m]>
yea
<Mis012[m]>
well, it isn't really named after an arm IP block :(
<Mis012[m]>
or after anything
<Mis012[m]>
8916: `smmu500`
<Mis012[m]>
8974: `src`
<Mis012[m]>
well played...
<Mis012[m]>
inb4 the people writing that directory name had no idea what exact mmu it is either :P
<Mis012[m]>
845 tz seems to distinguish between MMU500 and QSMMUv2
<Mis012[m]>
so I guess it's possible that the other thing is QSMMUv1?
<Mis012[m]>
or indeed v0
<Mis012[m]>
so I guess the drivers are named after the hw after all
<Mis012[m]>
except they don't distinguish between hw quirks and (intended) fw quirks
<Mis012[m]>
and except 8916 uses MMU500 and yet is handled by the other compatible
<Mis012[m]>
fun
<minecrell>
Mis012[m]: um, 8974 doesn't have "apps smmu"
<minecrell>
those still have many separate ones
<Mis012[m]>
minecrell: yeah, I recall now
<Mis012[m]>
but it's news to me that qsmmuv2 is actually qcom's hw implementation of smmuv2 and not just a name for the messed up thing you get after it gets locked down
<Mis012[m]>
I don't recall if the qsmmuv2 is named helpfully in the FLAT, but on 8974 it just says SMMU :/
<Mis012[m]>
MMU500 is definitely always named properly
<aka_[m]>
Mis012: you can take a look into 660
<aka_[m]>
it has qsmmu
<konradybcio>
msm iommu v0 -> 8960/8064 fam
<konradybcio>
msm iommu v1 -> msm8974/94
<konradybcio>
smmu-v2 / qciommu-500 -> 8916/53/76
<konradybcio>
newer socs implement a less flawed-by-fw version of arm-smmu-v2 and arm mmu-500
<minecrell>
doesn't really look that way if you look at arm-smmu-qcom.c :p
<konradybcio>
well
<konradybcio>
it's really not that terrible compared to nvidia and friends
<konradybcio>
until you start looking at adreno..
<Mis012[m]>
konradybcio: how about you separate out the hw and the fw
<konradybcio>
you can wipe the fw
<konradybcio>
and get a soc booting to pbl
<konradybcio>
rejecting the image
<konradybcio>
and killing itself
<konradybcio>
perfect boot flow
<Mis012[m]>
1. there are ownership-enabled devices with those SoCs
<Mis012[m]>
2. it's literally FUCKING INCORRECT to conflate hw and fw
<Mis012[m]>
3. iirc the FSF has a conspiracy theory word "firmware" by itself is separate from the word "software" so that people are more willing to accept the "prentend it's hw" game, and it seems it worked on you...?
<Mis012[m]>
*theory that the word
<Mis012[m]>
minecrell: I mean, he conflates smmu-v2 and mmu500 in addition to calling mmu500 qciommu500... so I'm not at all sure what the source is for those claims
<Mis012[m]>
I'd assume downstream, but you're saying not even that?
<minecrell>
who is "he" here?
<minecrell>
and which claims
<Mis012[m]>
`smmu-v2 / qciommu-500 -> 8916/53/76`
<minecrell>
well konradybcio was just clarifying which SoCs belong to what in qcom terminology
<minecrell>
there were no claims made that this naming makes sense
<Mis012[m]>
it's debatable whether bringing it up isn't already implicitly overstating it's usefulness
<konradybcio>
or we can all run msm-3.10 in "peace" and forget about ever getting mainline on 99.99999% of snapdragon devices
<konradybcio>
some cuts have to be made
<Mis012[m]>
like pretending fw and hw are not separate?
<Mis012[m]>
I don't think that's necessaray
<Mis012[m]>
s/necessaray/necessary/
<konradybcio>
they are not on the aforementioned 99.99999%
<konradybcio>
the fact that you have a special device does not mean everybody else does
<Mis012[m]>
-_-
<Mis012[m]>
they are separate
<Mis012[m]>
maybe they are not separable
<Mis012[m]>
but they are fucking separate
<Mis012[m]>
and mainline unlike downstream should take pride in having proper topology
<minecrell>
Mis012[m]: link to your patch?
<minecrell>
or comment on existing patch
<minecrell>
Complaining here certainly won't change anything :)
<Mis012[m]>
minecrell: currently I'm busy having the femtophy unfuck tested
<minecrell>
Mis012[m]: I'd argue possibly the same thing applies there, it's probably better if you send a patch
<Mis012[m]>
and I'm really not looking forward to upstream noticing that a mysterious femtophyv2 driver has appeared in the meantime
<minecrell>
and waiting is a good activity for staying busy
<Mis012[m]>
which seems to be suspiciously similar to the unfucked v1 driver
<Mis012[m]>
minecrell: it's just that preparing proper patches for hw which I don't have takes a lot more time than if I managed to convince other developers to not do ugly shit in the first place
<minecrell>
Mis012[m]: you can reply to patches on the mailing lists?
<Mis012[m]>
well, it's clearly hard enough to convince konradybcio that conflating hw and fw is bad on irc...
<Mis012[m]>
can't imagine it being easier over e-mail
<minecrell>
Mis012[m]: the problem is that you just complained so far, without suggesting realistic alternatives
<Mis012[m]>
minecrell: I'm investigating the mess at the same time
<Mis012[m]>
and it's sad
<Mis012[m]>
qcom correctly calls MMU500 as MMU500 in FLATs
<minecrell>
and fact is that there is existing code using "conflated hw/fw" to some extend so you cannot expect konradybcio to refactor all the existing stuff for you
<Mis012[m]>
but I can expect him to stop implying that if most devices use qcom singed fw tjat somehow makes conflating fw and hw correct
<Mis012[m]>
minecrell: it would seem the QSMMUv2 for the GPU in 845 just says "SMMU"
<Mis012[m]>
just like the ??? in 8974
<Mis012[m]>
`GPU_SMMU_NSTLBGSYNC` etc etc
<Mis012[m]>
resp. MM_SMMU_... in 8974
<minecrell>
Mis012[m]: so you're saying 8974 and 845 have the same hw?
<Mis012[m]>
no, I'm saying that it's possible that everything that doesn't say what it is in the module or regiseter names might be some version of qsmmu
<minecrell>
Mis012[m]: how about a new layer of questions, maybe it's like kryo, a modified ARM design :P
<Mis012[m]>
well, I'm sure someone in this room knows the answer to that
<Mis012[m]>
and qcom's NDAs are such bullshit that they can't even say if that guess is correct
<Mis012[m]>
is ARM's design public?
<Mis012[m]>
minecrell: btw the only reason I know that femtophy is the IP used by the SoCs which the femtophy driver supports is literally the driver name
<Mis012[m]>
that's the single fucking clue
<Mis012[m]>
which is sad
<Mis012[m]>
and since we know that qcom uses some random qsmmu driver for the mmu500 on 8916...
<Mis012[m]>
clearly that can't be trusted
<Mis012[m]>
I would hope that the hyp code would be correct in calling something qsmmuv2
<Mis012[m]>
since it's accessing it directly
<Mis012[m]>
but /shrug
<Mis012[m]>
fwiw I'd assume that in order to be smmuv1 or smmuv2 compliant, it already has to look similar to the arm desigb
<Mis012[m]>
minecrell[m]: so I'd say it's not based on MMU500
<minecrell>
Mis012[m]: which one
<Mis012[m]>
the QSMMUv2 one in sdm845
<Mis012[m]>
used for GPU
<minecrell>
ah
<Mis012[m]>
an MMU500 one is used for APSS
<Mis012[m]>
it also says RPM uses XPUs :P
<Mis012[m]>
it says SSC uses SMMU but said smmu is not in the list with APSS and GPU ones
<bamse>
mal: propose your change and argue for why it's worth breaking backwards compatibility
<Mis012[m]>
bamse: would you happen to know the story of the qsmmu?
<Mis012[m]>
it seems that qcom doesn't bother to mention which SMMU they're using in the module name, unless it's MMU500
<bamse>
Mis012[m]: which smmu are you referring to?
<Mis012[m]>
basically every SMMU register set that I see in the FLATs other than MMU500 lacks any indication whatsoever of what SMMU it is
<Mis012[m]>
I've found in sdm845 TZ elf that it uses MMU500 for APPS (the FLAT does mention MMU500 in the module name)
<Mis012[m]>
and that it uses QSMMUv2 for GPU
<Mis012[m]>
(the FLAT calls that thing simply "GPU_SMMU" and never mentions qsmmu)
<Mis012[m]>
sorry, s/tz/hyp/
<Mis012[m]>
I'm inclined to trust the hyp that it's talking about the hw and not about the fw mess since the fw mess is in the hyp itself :P
<Mis012[m]>
it would seem that the qsmmuv2 for the gpu is not based on mmu500, didn't compare register set with other arm designs yet
<Mis012[m]>
and downstream/mainline driver names can't be trusted since they use qsmmuv1 for 8916 which definitely has an MMU500
pevik_ has quit [Ping timeout: 480 seconds]
<Mis012[m]>
bamse: so I wonder how qsmmu came to be, what it's based on if anything and which SoCs use which versions
<Mis012[m]>
I guess that if the register set is different if and only if the smmu version is different, I could maybe just compare with other SoCs
<Mis012[m]>
bamse: if it's qcom original design, it sure is suspicious that it lacks version registers
<bamse>
Mis012[m]: i unfortunatly don't know the details about those older ip blocks, or the desire to cripple the register interface presented to the kernel
<Mis012[m]>
bamse: what does qcom do now?
<Mis012[m]>
pretend Linux is a vm host?
<Mis012[m]>
guess there's the VFE version of that
<Mis012[m]>
but I'm sure they messed with the other smmus as well