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 kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
