> On May 18, 2018, at 4:10 PM, Dmitry Safonov <0x7f454c46@xxxxxxxxx> wrote: > Hi Andy, > 2018-05-18 23:03 GMT+01:00 Andy Lutomirski <luto@xxxxxxxxxx>: >>> On Thu, May 17, 2018 at 4:40 PM Dmitry Safonov <dima@xxxxxxxxxx> wrote: >>> Some selftests are failing, but the same way as before the patch >>> (ITOW, it's not regression): >>> [root@localhost self]# grep FAIL out >>> [FAIL] Reg 1 mismatch: requested 0x0; got 0x3 >>> [FAIL] Reg 15 mismatch: requested 0x8badf00d5aadc0de; got >>> 0xffffff425aadc0de >>> [FAIL] Reg 15 mismatch: requested 0x8badf00d5aadc0de; got >>> 0xffffff425aadc0de >>> [FAIL] Reg 15 mismatch: requested 0x8badf00d5aadc0de; got >>> 0xffffff425aadc0de >> Are you on AMD? Can you try this patch: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fixes&id=c88aa6d53840e48970c54f9ef70c79415033b32d >> and give me a Tested-by if it fixes it for you? > Sure. > I'm on Intel actually: > cpu family : 6 > model : 142 > model name : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz > But I usually test kernels in VM. So, I use virt-manager as it's > easier to manage > multiple VMs. The thing is that I've chosen "Copy host CPU configuration" > and for some reason, I don't quite follow virt-manager makes model "Opteron_G4". > I'm on Fedora 27, virt-manager 1.4.3, qemu 2.9.1(qemu-2.9.1-2.fc26). > So, cpuinfo in VM says: > cpu family : 21 > model : 1 > model name : AMD Opteron 62xx class CPU What does guest cpuinfo say for vendor_id? There are multiple potential screwups here. 1. (What I *thought* was going on) AMD CPUs have screwy IRET behavior that’s different from Intel’s, and the test case was definitely wrong. But KVM has no way to influence it. Are you sure you’re using KVM and not QEMU TCG? Anyway, the IRET thing is minor compared to your other problems, so let’s try to fix them first. 2. Compat fast syscalls are wildly different on AMD and Intel. Because of this issue, QEMU with KVM is supposed to always report the real vendor_id no matter -cpu asks for. If we get the wrong vendor_id, then we’re at the mercy of KVM’s emulation and performance will suck. On older kernels, this would cause hideous kernel crashes. On new kernels, I would expect it to merely crash 32-bit user programs or be slow. > What's worse than registers changes is that some selftests actually lead to > Oops's. The same reason for criu-ia32 fails. > I've tested so far v4.15 and v4.16 releases besides master (2c71d338bef2), > so it looks to be not a recent regression. > Full Oopses: > [ 189.100174] BUG: unable to handle kernel paging request at 00000000417bafe8 > [ 189.100174] PGD 69ed4067 P4D 69ed4067 PUD 707fc067 PMD 6c535067 PTE 6991f067 > [ 189.100174] Oops: 0001 [#3] SMP NOPTI Whoa there! 0001 means a failed *kernel* access. > [ 189.100174] Modules linked in: > [ 189.100174] CPU: 0 PID: 2443 Comm: sysret_ss_attrs Tainted: G Was this sysret_ss_attrs_32 or sysret_ss_attrs_64? > D 4.17.0-rc5+ #11 > [ 189.103187] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > BIOS 1.10.2-1.fc26 04/01/2014 > [ 189.103187] RIP: 0033:0x40085a The oops was caused from CPL 3 at what looks like a totally sensible user address. Can you disassemble the offending binary and tell me what the code at 0x40085a is? > [ 189.103187] RSP: 002b:00000000417bafe8 EFLAGS: 00000206 > [ 189.103187] RAX: 0000000000000000 RBX: 00000000000003e8 RCX: 0000000000000000 > [ 189.103187] RDX: 0000000000000000 RSI: 0000000000400830 RDI: 00000000417baff8 > [ 189.103187] RBP: 00000000417baff8 R08: 0000000000000000 R09: 0000000000000077 > [ 189.103187] R10: 0000000000000006 R11: 0000000000000000 R12: 00000000417ba000 > [ 189.103187] R13: 00007ffc05207840 R14: 0000000000000000 R15: 0000000000000000 > [ 189.103187] FS: 00007f98566ecb40(0000) GS:ffff9740ffc00000(0000) > knlGS:0000000000000000 > [ 189.103187] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CS here is the value of CS that the *kernel* has, so 0x10 is normal. > [ 189.103187] CR2: 00000000417bafe8 CR3: 0000000069dc4000 CR4: 00000000007406f0 CR2 is in user space. So the big question is: what happened here? Why did the CPU (or emulated CPU) attempt a privileged access to a user address while running user code?
