On 10/21/15 12:27, Paolo Bonzini wrote: > > > On 21/10/2015 12:22, Laszlo Ersek wrote: >> On 10/21/15 11:51, Paolo Bonzini wrote: >>> >>> >>> On 20/10/2015 12:08, Laszlo Ersek wrote: >>>>>> >>>>>> 64 KVM >=1 "KVM: entry failed, hardware error 0x80000021" >>>>>> while guest in SMBASE relocation >>>> Tracing KVM shows the following: >>>> >>>> qemu-system-x86-3236 [001] 10586.857752: kvm_enter_smm: vcpu 1: >>>> entering SMM, smbase 0x30000 >>>> ... >>>> qemu-system-x86-3236 [001] 10586.857863: kvm_enter_smm: vcpu 1: >>>> leaving SMM, smbase 0x0 >>>> qemu-system-x86-3236 [001] 10586.857865: kvm_entry: vcpu 1 >>>> qemu-system-x86-3236 [001] 10586.857866: kvm_exit: reason >>>> UNKNOWN rip 0x0 info 0 80000306 >>>> qemu-system-x86-3236 [001] 10586.857909: kvm_userspace_exit: reason >>>> KVM_EXIT_FAIL_ENTRY (9) >>> >>> This seems like you do not have this patch: >>> https://lkml.org/lkml/2015/10/14/462 >> >> That's right, I don't have it; but in the guest I do have your >> >> UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode >> http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3023 >> >> My understanding was that either of those two patches was sufficient. > > No, this one fixes return _from_ 64-bit mode. The kernel patch fixes > return _to_ 64-bit mode and will be in 4.3. > >> IIRC you asked me to keep the guest patch around in my branch for ease >> of testing, until the above KVM patch is released with Linux 4.4. Is >> that correct? > > This will be the kernel fix for return _from_ 64-bit mode.
I can confirm that the patch you referenced makes the above failure go away. Meaning, with >= 2 VCPUs, the failure is replaced with the infinite loop that is also seen in the 32-bit case. (In other words, with this host patch in place, the 32-bit and 64-bit cases, KVM, >= 2 VCPU, behave identically.) With 1 VCPU, "Fedora-Live-Xfce-x86_64-21-5.iso" boots, but then panics with: [ 0.003008] ACPI: Core revision 20140724 [ 0.004328] ACPI: All ACPI Tables successfully acquired [ 0.005418] PANIC: double fault, error_code: 0x0 [ 0.005895] CPU: 0 PID: 0 Comm: (null) Not tainted 3.17.4-301.fc21.x86_64 #1 [ 0.006000] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [ 0.006000] task: (null) ti: ffffffffffffc028 task.ti: (null) [ 0.006000] RIP: 0008:[<000000007ffc0955>] [<000000007ffc0955>] 0x7ffc0955 [ 0.006000] RSP: 0020:000000007ffaadf0 EFLAGS: 00010002 [ 0.006000] RAX: 0000000000000800 RBX: 0000000000000033 RCX: 00000000c0000080 [ 0.006000] RDX: 0000000000000000 RSI: ffffffff81c03d60 RDI: 000000007ffa3000 [ 0.006000] RBP: ffffffff81c03c90 R08: 0000000000000000 R09: 0000000000000000 [ 0.006000] R10: 000000007febb010 R11: 0000000000000007 R12: ffffffff81c03ed0 [ 0.006000] R13: 0000000000000007 R14: 0000000000000000 R15: 000000000009c000 [ 0.006000] FS: 0000000000000000(0020) GS:0000000000000000(0020) knlGS:0000000000000000 [ 0.006000] CS: 0010 DS: 0020 ES: 0020 CR0: 0000000080050033 [ 0.006000] CR2: 000000007ffaade8 CR3: 000000000009c000 CR4: 00000000000006b0 [ 0.006000] Stack: The RIP looks suspiciously close (interpreted as a phys address) to the SMRAM range, but that's just a wild guess. Anyway, we got proof that I had been missing this host kernel patch. Thanks! Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
