On Tue, 2017-09-05 at 19:21 -0700, Sai Praneeth Prakhya wrote: > > I get a similar crash on Qemu with linus's master branch and the V2 > > applied on top of it. Here are the details of my test environment: > > > > 1. I use the OVMF (EDK2) EFI firmware to launch the kernel: > > edk2.git/ovmf-x64 > > > > 2. I used linus's master branch (HEAD - commit: > > b1b6f83ac938d176742c85757960dec2cf10e468) and applied your v2 on top > > of the same. > > > > 3. I use the following qemu command line to launch the test: > > > > # /usr/local/bin/qemu-system-x86_64 --version > > QEMU emulator version 2.9.50 (v2.9.0-526-g76d20ea) > > Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers > > > > # /usr/local/bin/qemu-system-x86_64 -enable-kvm -net nic -net tap -m > > $MEMSIZE -nographic -drive file=$DISK_IMAGE,if=virtio,format=qcow2 > > -vga std -boot c -cpu host -kernel $KERNEL -append > > "crashkernel=$CRASH_MEMSIZE console=ttyS0,115200n81" -initrd > > $INITRAMFS -bios $OVMF_FW_PATH > > > > And here is the crash log: > > > > [ 0.006054] general protection fault: 0000 [#1] SMP > > [ 0.006459] Modules linked in: > > [ 0.006711] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.0+ #3 > > [ 0.007000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > > BIOS 0.0.0 02/06/2015 > > [ 0.007000] task: ffffffff81e0f480 task.stack: ffffffff81e00000 > > [ 0.007000] RIP: 0010:switch_mm_irqs_off+0x1bc/0x440 > > [ 0.007000] RSP: 0000:ffffffff81e03d80 EFLAGS: 00010086 > > [ 0.007000] RAX: 800000007d084000 RBX: 0000000000000000 RCX: 000077ff80000000 > > [ 0.007000] RDX: 000000007d084000 RSI: 8000000000000000 RDI: 0000000000019a00 > > [ 0.007000] RBP: ffffffff81e03dc0 R08: 0000000000000000 R09: ffff88007d085000 > > [ 0.007000] R10: ffffffff81e03dd8 R11: 000000007d095063 R12: ffffffff81e5c6a0 > > [ 0.007000] R13: ffffffff81ed4f40 R14: 0000000000000030 R15: 0000000000000001 > > [ 0.007000] FS: 0000000000000000(0000) GS:ffff88007d400000(0000) > > knlGS:0000000000000000 > > [ 0.007000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 0.007000] CR2: ffff88007d754000 CR3: 000000000220a000 CR4: 00000000000406b0 > > [ 0.007000] Call Trace: > > [ 0.007000] switch_mm+0xd/0x20 > > [ 0.007000] ? switch_mm+0xd/0x20 > > [ 0.007000] efi_switch_mm+0x3e/0x4a > > [ 0.007000] efi_call_phys_prolog+0x28/0x1ac > > [ 0.007000] efi_enter_virtual_mode+0x35a/0x48f > > [ 0.007000] start_kernel+0x332/0x3b8 > > [ 0.007000] x86_64_start_reservations+0x2a/0x2c > > [ 0.007000] x86_64_start_kernel+0x178/0x18b > > [ 0.007000] secondary_startup_64+0xa5/0xa5 > > [ 0.007000] ? secondary_startup_64+0xa5/0xa5 > > [ 0.007000] Code: 00 00 00 80 49 03 55 50 0f 82 7f 02 00 00 48 b9 > > 00 00 00 80 ff 77 00 00 48 be 00 00 00 00 00 00 00 80 48 01 ca 48 09 > > f0 48 09 d0 <0f> 22 d8 0f 1f 44 00 00 e9 47 ff ff ff 65 8b 05 b8 87 fb > > 7e 89 > > [ 0.007000] RIP: switch_mm_irqs_off+0x1bc/0x440 RSP: ffffffff81e03d80 > > [ 0.007000] ---[ end trace bfa55bf4e4765255 ]--- > > [ 0.007000] Kernel panic - not syncing: Attempted to kill the idle task! > > [ 0.007000] ---[ end Kernel panic - not syncing: Attempted to kill > > the idle task! > > > > 4. Note though that if I use the EFI_MIXED mode (i.e. 32-bit ovmf > > firmware and 64-bit x86 kernel) with your patches, the primary kernel > > boots fine on Qemu: > > > > ovmf firmware used in this case - edk2.git/ovmf-ia32 > > > > 5. Also, if I append 'efi=old_map' to the bootargs (for the failing > > case in point 3 above), I see the primary kernel boots fine on Qemu as > > well. > > > > Regards, > > Bhupesh > > Hi Bhupesh, > > Thanks a lot for the detailed explanation. They are helpful to reproduce > the issue quickly. From my initial debug, I think that AMD SME + > efi_mm_struct patches + -cpu host (in qemu) are required to reproduce > the issue on qemu. > > I have tried the following combinations (all tests are on qemu): > On Linus's tree: > 1. With SME and efi_mm and -cpu host -> panics > 2. With SME and efi_mm and !-cpu host -> boots > 3. With SME and !efi_mm and -cpu host -> boots > 4. With SME and !efi_mm and !-cpu host -> boots > 5. With !SME and efi_mm and -cpu host -> boots > 6. With !SME and efi_mm and !-cpu host -> boots > 7. With !SME and !efi_mm and -cpu host -> boots > 8. With !SME and !efi_mm and !-cpu host -> boots > > On Matt's tree (no SME): > 1. With efi_mm and -cpu host -> boots > 2. With efi_mm and !-cpu host -> boots > 3. With !efi_mm and -cpu host -> boots > 4. With !efi_mm and !-cpu host -> boots > > Summary: > On Matt's tree (next branch), I am unable to reproduce the issue because > they don't have SME patches. > > On Linus's tree, with SME patches > (b1b6f83ac938d176742c85757960dec2cf10e468) and my patches and -cpu host > switch enabled in qemu, I was able to reproduce the issue. > > Could you please confirm if you are seeing the same behavior? > Specially on real machines (I think, this is equivalent to -cpu host on > qemu) because in earlier mails you have mentioned that you were able to > reproduce this on Matt's tree, but according to my theory it shouldn't > be the case because Matt's three doesn't have SME patches. > Did you back port (b1b6f83ac938d176742c85757960dec2cf10e468) this commit > to Matt's tree and then applied my patches? > > Your confirmation will help us in debugging the right issue. > > Regards, > Sai Sorry! I am not sure if it's the SME patches or the PCID based TLB flush patches (most likely the later because they change switch_mm() code). Both the patches along with 5-level paging were in the same pull request sent from Ingo to Linus. So, SME patches above really means this commit id (b1b6f83ac938d176742c85757960dec2cf10e468) in Linus's tree. I will debug this issue further and will send a V3 but to be sure that I am debugging the right issue, Bhupesh, Could you please update me as requested in earlier mail? Regards, Sai -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
