On 24/02/15 15:09, Richard W.M. Jones wrote:
>> On 24/02/15 14:36, Richard W.M. Jones wrote:
>>> I can probably bisect this given time, but I'm going to try putting
>>> some debug into the userspace process to find out which system call
>>> fails first.
>
> Perhaps not surprisingly, it's the init_module syscall which causes
> the failure, ie. this line of code:
>
> https://github.com/libguestfs/supermin/blob/master/src/init.c#L436
>
> I've no idea why that code would call copy_to_user. It should be
> copying the other way ...
>
> It also fails on the first call to init_module, so the fact that it's
> loading crc32-arm64.ko may just be a coincidence.
>
> There are no other userspace processes running, but just to be sure
> that it's not some other process in the guest, I also added a sleep
> before the call to init_module, but same result as above.
>
> I also looked at the implementation of init_module in glibc, but
> AFAICT init_module is a straight syscall and glibc is not involved.
>
> I also looked to see if I was calling init_module correctly on aarch64
> (in case it has a different # of arguments of something) but it's
> called in the same way in the libkmod code, so I think we're OK.
>
> Next up, I will have a go at bisecting the guest kernel.
After some quick debug, here's the backtrace:
[ 13.276501] [<fffffe00003da0bc>] __copy_to_user+0x2c/0x60
[ 13.276734] [<fffffe0000099f08>] __aarch64_insn_write+0x94/0xf8
[ 13.276971] [<fffffe000009a0a0>] aarch64_insn_patch_text_nosync+0x18/0x58
[ 13.277245] [<fffffe000009c4b0>] ftrace_make_nop+0x54/0x84
[ 13.277457] [<fffffe0000164400>] ftrace_process_locs+0x3d0/0x5c8
[ 13.277694] [<fffffe00001661ac>] ftrace_module_init+0x28/0x34
[ 13.277968] [<fffffe0000135128>] load_module+0xbb8/0xfc4
[ 13.278142] [<fffffe00001356f4>] SyS_finit_module+0x94/0xc4
Either ftrace or the patching code is buggy. Need to investigate.
BTW, if you want to be able to get that kind of trace:
diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
index 5d3bfc0..5b23917 100644
--- a/arch/arm/kvm/mmio.c
+++ b/arch/arm/kvm/mmio.c
@@ -183,7 +183,9 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
return ret;
} else {
kvm_err("load/store instruction decoding not implemented\n");
- return -ENOSYS;
+ kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));
+ return 1;
+ //return -ENOSYS;
}
rt = vcpu->arch.mmio_decode.rt;
Now trying to understand how we got there...
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
