RE: [PATCH V2 0/3] Use mm_struct and switch_mm() instead of manually
From: Prakhya, Sai Praneeth
Date: Wed Sep 06 2017 - 05:00:23 EST
> -----Original Message-----
> From: Sai Praneeth Prakhya [mailto:sai.praneeth.prakhya@xxxxxxxxx]
> Sent: Tuesday, September 5, 2017 7:43 PM
> To: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
> Cc: linux-efi@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Matt Fleming
> <matt@xxxxxxxxxxxxxxxxxxx>; Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>;
> jlee@xxxxxxxx; Borislav Petkov <bp@xxxxxxxxx>; Luck, Tony
> <tony.luck@xxxxxxxxx>; luto@xxxxxxxxxx; mst@xxxxxxxxxx; Neri, Ricardo
> <ricardo.neri@xxxxxxxxx>; Shankar, Ravi V <ravi.v.shankar@xxxxxxxxx>
> Subject: Re: [PATCH V2 0/3] Use mm_struct and switch_mm() instead of
> manually
>
> 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
Hi Bhupesh,
Could you please append "nopcid" to kernel command line parameters and see if the issue goes away (on both qemu and real machines)?
Regards,
Sai