ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
<maz>
as for the triplet, it depends what you are targeting. if this is Linux, something like arm-linux-gnueabihf is probably what you are looking for.
Peng_Fan has joined #armlinux
lain6141 has quit [Read error: Connection reset by peer]
<militantorc>
maz, android so yes linux
<militantorc>
but that didn't work
<militantorc>
permission denied aka wrong arch
<militantorc>
and yes i used -static --static
lain6141 has joined #armlinux
<jn>
android uses bionic instead of glibc, so you need to use that unless you link statically
<militantorc>
i did statically
<jn>
hm
<maz>
militantorc: I don't think -EPERM has anything to do with the ABI used.
<militantorc>
this same approach worked perfectly for another arm-7l phone
<militantorc>
but somehow
<militantorc>
fails on this
<jn>
how does it fail?
<militantorc>
jn, permission denied
<militantorc>
when i tried to excute it
<jn>
is the file marked executable?
<militantorc>
which from experince i know means wrong arch
<militantorc>
yes
<jn>
what does strace say?
<maz>
more likely a SELinux policy of some sort.
<militantorc>
i don't think i have strace on my phone
<militantorc>
oh
<militantorc>
i guess time to find a root i guess
<militantorc>
and disabl se linux
<militantorc>
$ cat hello.c
<militantorc>
#include <stdio.h>
<militantorc>
printf("Hello world\n");
<militantorc>
int main() {
<militantorc>
return 0;
<militantorc>
}
<Xogium>
can you please not paste more than 2 or 3 lines in the channel ?
<militantorc>
time to build a tar for this phone now
<militantorc>
since adb pull / gets stuck in symlink infinite loops
<militantorc>
after that busybox i suppose
<militantorc>
what was the string for configure host= again?
<militantorc>
>For example, if you are using arm-none-linux-gnueabi-gcc, set --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi. This will write to your makefile. Finally, generated executable will run on target. For --build this will be automatically set, no need to worry.
<militantorc>
ok
<militantorc>
is host=arm-glibc-linux-gnueabihf correct for my case?
frieder has quit [Ping timeout: 252 seconds]
<militantorc>
ugh dynamic linking issues again, time to go musl gcc i guess
misanthropos has quit [Read error: Connection reset by peer]
mvaittin has quit [Ping timeout: 260 seconds]
<militantorc>
excellent, musl-gcc did the trick, i have a working tar on my phone now
<militantorc>
hm, the phone does have a dd binary too, i;ll see later if i can put it to interestign use
frieder has joined #armlinux
<dmart>
maz: Are vCPUs hard-affined to physical CPUs under pKVM?
misanthropos has joined #armlinux
<dmart>
broonie: ^ I was trying to understand that SVE underallocation thing.
<broonie>
dmart: It's nothing to do with vCPUs, this is saving host state. The allocation currently uses the maximum usable VL for the host system to allocate for all CPUs, if the system is asymmetric some of the CPUs won't have a a big enough buffer.
<dmart>
broonie: Ah. Does the host ever use non-shared VLs? I don't think we used to allow that -- since affected threads wouldn't be migratable.
<broonie>
dmart: The hypervisor shouldn't trust the host, and Fuad decided to configure the VL to use by writing all bits 1 to the length register so it'll use whatever the maximum VL the PE supports is.
* broonie
did suggest writing a specific VL during the initial review IIRC, but that didn't happen - part of the issue is that we're now writing one VL and using a potentially different one.
<dmart>
broonie: Does pKVM never migrate vCPUs? Otherwise, letting CPU assymetries show through into the host doesn't make sense (?)
<maz>
dmart: pKVM migrates vcpu just like normal KVM.
<maz>
but the problem at hand as absolutely nothing with vcpus.
<maz>
has*
<maz>
this is all about saving the *host* state, and we obviously don't "migrate" physical CPUs.
<dmart>
maz: Right, I guess I need to look at the code again.
marc|gonzalez has joined #armlinux
<marc|gonzalez>
How does one go about submitting code written by someone else? Should the patch author be the original author, and I just add my Signed-off-by tag (meaning I checked that the licenses are OK) ? What if the original author never formally added a Signed-off-by tag?
<broonie>
If you sign something off you're saying you've checked all the licensing, if there's no signoff from the author then that's unusual and you should probably explain what's going on but it's not 100% a blocker.
<marc|gonzalez>
broonie: so, if I find an "abandoned" patch in a personal git tree, I can dust it off, cherry-pick it onto the latest kernel, and submit it with my S-o-b, explaining that the author is no longer working on this area, but I need it for $FOO ?
<broonie>
and why you're sure the licensing is OK.
<marc|gonzalez>
Licensing. Gotcha. Code includes the SPDX blurb, so that part is easy to check :)
<marc|gonzalez>
broonie: and if I need to change stuff? Should it be a patch on top of the original patch? Or if I squash, then who is the author (of the bugs I might add) ?
<broonie>
Depends on how big the updates are, at some point it's enough change to be co-authored and tagged like that.
<marc|gonzalez>
Everything you said makes sense to me. OK. Time to test this blob then.
<broonie>
Or for smaller things a note in the changelog explaining a tweak might be better.
headless has joined #armlinux
<dmart>
maz, broonie: Having looked at Fuad's patch, I get this now.
<dmart>
broonie: Do we need to be that religious about where in the state blob the SVE regs get written? That blob doesn't really have a type, regardless: we always need to know the vl is wad read/written with.
* dmart
s/is wad/it was/ (but that's what the cool kids say)
<broonie>
dmart: It's fine to lay things out with a higher VL than we actually use, using a lower VL results in corruption since the Z regs overlay the P regs.
<broonie>
Since we should change the current code (which might end up using a lower VL to lay out than the hardware has) we may as well change it to use the value programmed into the hardware which makes it clear that things are lined up.
<broonie>
Writing one VL and then using a potentially different one is a speed bump whenever the code gets looked at, even if it's all fine actually.
frieder has quit [Ping timeout: 268 seconds]
<dmart>
broonie: Maybe, but that's what the host does...
<broonie>
dmart: Hrm? The host always configures an explicit VL, it only uses max during enumeration.
<broonie>
(and never looks at the Z/P register state during enumeration)
<dmart>
broonie: Ah, I think I see what you mean.
<dmart>
broonie: Fuad's convention (fixed sve_ffr_offset() anchor irrespective of the "current" vl) is different from the one used elsewhere. There's nothing wrong with the approach, but the inconsistency is likely to confuse people sooner or later...
<dmart>
Do I have that right?
frieder has joined #armlinux
<broonie>
Yes, or at least slow people down when they're looking at things since you need to go check that everything actually lines up. We could also program the maximum VL as the VL which would make things consistent the other way.
<dmart>
broonie: Hmm. Also, is all of this just to handle the overlarge VLs configured by the host during probing? To have to allocate extra memory to store extra vector bits that are never used by the host seems a bit odd, though it maybe simpler than the alternatives.
frieder has quit [Quit: Leaving]
<broonie>
dmart: Yes, or otherwise coming along and trying to use those extra bits with some future change. It does seem like a reasonable defensive choice for the hypervisor.
<dmart>
broonie: Ack, I guess if someone builds asymmetric hardware with massively different max VL on different CPUs then that's their problem...
<broonie>
We strongly disrecommend any variation in VLs so hopefully it's theoretical.
<dmart>
broonie: Taking a step back though, is there a reason why pKVM can't just hide the problem VLs completely using ZCR_EL2?
<dmart>
broonie: (i.e., what regular KVM does)
<broonie>
Yeah, *shrug*
<broonie>
It would have seemed like the more obvious approach.
<broonie>
I'm probably missing something with pKVM there.
<dmart>
broonie: Maybe that's hard to achieve for some reason, dunno -- I'll reply to the series anyhow.
heat has joined #armlinux
mvaittin has joined #armlinux
xvmt has quit [Ping timeout: 268 seconds]
gclement1 has joined #armlinux
mvaittin has quit [Ping timeout: 256 seconds]
gclement has quit [Ping timeout: 272 seconds]
gclement1 has quit [Ping timeout: 272 seconds]
xvmt has joined #armlinux
<robher>
maz: Okay if I write the commit msg and put your Sob on your interrupt-map fix for nemo, or do you want to send me a proper patch?
monstr has quit [Remote host closed the connection]
<maz>
robher: if you have the bandwidth to handle it, that'd be great. thanks!
<robher>
maz: Really, I'd like to understand why the 2 other patches don't work, but it seems to be pulling teeth and I don't care that much...
<maz>
robher: yeah, this thread has been a waste of time, mostly. it feels like there are 3 intermediates between us and the person testing the code, and I'm sick of not getting a straightforward answer.
lain6141 has quit [Read error: Connection reset by peer]