On 31/05/2019 12:18, YOUNG, MICHAEL A. wrote: > On Tue, 16 Apr 2019, M A Young wrote: > >> On Tue, 16 Apr 2019, Andrew Cooper wrote: >> >>> From the log: >>> >>> traps: modprobe[48] trap invalid opcode ip:7f797dc7bb95 sp:7ffe3099cdb8 erro >>> r:0 in ld-2.29.so[7f797dc61000+21000] >>> >>> >>> Can you disassemble ld-2.29.so and find out what that instruction is? It is >>> almost certainly a related factor. >> I get lines like >> [ 1.384356] traps: modprobe[36] trap invalid opcode ip:7f57448af179 >> sp:7fff8fc3a938 error:0 in ld-2.29.so[7f5744895000+20000] >> >> I am guessing the right place to look in ld-2.29.so is >> 0x7f57448af179-0x7f57448950000-20000 = 86873 in which case I get >> (gdb) x/10i 86873 >> 0x15359 <_dl_close_worker+3593>: mov (%rsi,%rcx,8),%r8 >> 0x1535d <_dl_close_worker+3597>: testb $0x20,0x31d(%r8) >> 0x15365 <_dl_close_worker+3605>: jne 0x15375 >> <_dl_close_worker+3621> >> 0x15367 <_dl_close_worker+3607>: cmp %ecx,%edx >> 0x15369 <_dl_close_worker+3609>: je 0x15372 >> <_dl_close_worker+3618> >> 0x1536b <_dl_close_worker+3611>: mov %edx,%r9d >> 0x1536e <_dl_close_worker+3614>: mov %r8,(%rsi,%r9,8) >> 0x15372 <_dl_close_worker+3618>: add $0x1,%edx >> 0x15375 <_dl_close_worker+3621>: add $0x1,%rcx >> 0x15379 <_dl_close_worker+3625>: cmp %ecx,%eax >> >> Some more lines like this are >> [ 1.571479] traps: modprobe[41] trap invalid opcode ip:7f3e3628d179 >> sp:7ffc86abbe08 error:0 in ld-2.29.so[7f3e36273000+20000] >> [ 1.630562] traps: modprobe[43] trap invalid opcode ip:7f227b39a179 >> sp:7ffdfd943198 error:0 in ld-2.29.so[7f227b380000+20000] >> which all seem to get to the same place. Is this useful or am I looking in >> the wrong place? > I did a bisect on this issue, and it identified the first bad commit as > fd32dcfe4c9a539f8e5d26ff4c5ca50ee54556b2 > x86/vmx: Don't leak EFER.NXE into guest context
Aah - this will be a harpertown core. You need e28c0ee3356f52f589bbae54e89aaed25c1f599d from staging, which has been backported to staging-4.12 (8457c15b981ba04c0709e6f25af3b76beb34cafa) two weeks ago. This but accidentally resulted in the SYSCALL instruction being disabled behind the back of the guest, which broke all userspace system calls. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
