> 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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
