<EmilKarlson>
does that line work for people (do you get EINVAL or hang, like one might expect)
<EmilKarlson>
nvm, I am not in group kvm so it gives me EINVAL, not EACCESS or EPERM
nsaenz has quit [Quit: Leaving]
nsaenz has joined #linux-rockchip
buzzmarshall has joined #linux-rockchip
nsaenz has quit [Quit: Leaving]
nsaenz has joined #linux-rockchip
<EmilKarlson>
hmm actually it's just random
<mmind00>
EmilKarlson: just noting ... when I was trying qemu on rk3288 (via my ATF work), it somehow always hung with _and_ without virtualization extensions
<EmilKarlson>
some people claimed rk3288 did not just work with kvm, rk3399 definitely has in the past
<EmilKarlson>
I'll try linux-5.1 later, in case this might be a regression
<EmilKarlson>
might also not be related to hw
<EmilKarlson>
also getting function graph of the failure should be fairly trivial
<EmilKarlson>
nothing in kernel log about this btw.
<EmilKarlson>
but would be interested to know, whether qemu works for others in general in recent kernels
field^Zzz1 has joined #linux-rockchip
aalm has quit [Read error: Connection reset by peer]
<EmilKarlson>
so unresolved regression count now 2, one for rockchip
<inode>
do your cores get brought up in HYP mode?
<tomeu>
mmind00: I have had good results running crosvm on regular linux on x86
<tomeu>
because it's used for crostini on rockchip chromebooks, I would expect it to work as well there with the chromeos kernels
<tomeu>
and then shouldn't be that hard to find out what's wrong in mainline
<maz>
KVM should absolutely work with mainline. if it doesn't, please let me know on the list asap, and I'll dig into it.
<maz>
EmilKarlson: I'm running VMs on kevin every day.
<maz>
if using qemu, you have to be careful that all your vcpus get created on the same physical CPU type (either A53 or A72).
<maz>
best thing to do is to taskset qemu to the cluster you want.
matthias_bgg has joined #linux-rockchip
rich0 has quit [Quit: rich0]
rich0 has joined #linux-rockchip
return0e has quit []
return0e has joined #linux-rockchip
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 268 seconds]
<EmilKarlson>
maz: ok, I was actually thinking about that, but did not know about this limitation
<EmilKarlson>
maz: is this something that has changed, because I did not notice this issue at all before
JohnDoe_71Rus has joined #linux-rockchip
<maz>
EmilKarlson: no, it was always there. that's not a KVM limitation, btw, but a QEMU sanity check. big-little is stupid enough on the host, there's no need to replicate the madness in the guest.
* maz
puts the ARM hat back on.
<maz>
of course, BL is the best thing since sliced bread!
<EmilKarlson>
hmm, this fails on ioctl(13, KVM_ARM_VCPU_INIT, 0x7fd1ee6ba8) = -1 EINVAL (Invalid argument)
<EmilKarlson>
so I don't get how it would be qemu check?
<EmilKarlson>
but indeed taskset seem to help moderately reproducibly
<EmilKarlson>
maz: is there some explanation why this could not work?
<maz>
EmilKarlson: QEMU enforce the target it got from the first CPU, if I remember well. kvmtool doesn't care.
<maz>
when you say " seem to help moderately": does it still fail?
<EmilKarlson>
doesn't fail, but I haven't run it that many times
<EmilKarlson>
maz, so are you saying I am just hitting this due to some random factors?
aalm has joined #linux-rockchip
aalm has quit [Read error: Connection reset by peer]
<maz>
also, I unfortunately have a precise idea of what this code does...
<EmilKarlson>
well mostly it did somehow work before, which can just be due to luck
<EmilKarlson>
if there is no actual cause, it must be random
<maz>
sure, let's say that.
<EmilKarlson>
I could have said that not hitting it before due to random
<EmilKarlson>
but thanks
<EmilKarlson>
maz: oh one more thing, have you gotten gui working somehow
<EmilKarlson>
IIRC I have gotten picture on the screen and usb mouse that I can control with qemu commands, but no kbd at all
<maz>
I have virtio-gpu working, keyboard and mouse.
<EmilKarlson>
also would be nice to have a pointer that does not require qemu commands to move
<EmilKarlson>
any command line you could share
<EmilKarlson>
?
<maz>
I don't have my kevin handy today, but probably tomorrow.
<maz>
ping me then.
<EmilKarlson>
thank you
<EmilKarlson>
will do
ayaka has quit [Read error: Connection reset by peer]
ayaka has joined #linux-rockchip
field^Zzz1 has quit [Ping timeout: 258 seconds]
drrty has joined #linux-rockchip
somy has quit [Read error: Connection reset by peer]
somy has joined #linux-rockchip
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #linux-rockchip
nsaenz has quit [Read error: Connection reset by peer]
nsaenz has joined #linux-rockchip
vagrantc has joined #linux-rockchip
stikonas_ has joined #linux-rockchip
norris has joined #linux-rockchip
warpme_ has joined #linux-rockchip
<norris>
EmilKarlson: ${search_engine} tells me you've been complaining here about spi_res_release() crashes on Kevin on 5.2-rc1; I just saw two such crashes on Kevin, 5.2-rc3:
<norris>
<1>[ 3445.868626] Unable to handle kernel paging request at virtual address ffffff8010f2f790
<norris>
<1>[ 3445.878087] Mem abort info:
<norris>
<1>[ 3445.881656] ESR = 0x96000007
norris has quit [Excess Flood]
<norris>
<1>[ 3445.885094] Exception class = DABT (current EL), IL = 32 bits
norris has joined #linux-rockchip
<norris>
hah, freenode doesn't like me pasting too much here. whoops