On 11/14/16 13:00, Paolo Bonzini wrote: > > > On 14/11/2016 12:27, Laszlo Ersek wrote: >> Well... >> >> http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05658.html >> http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg00125.html >> http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg00563.html >> >> Are you suggesting that I resurrect this patch? That would be my >> pleasure. Please say yes. > > It's hard to say no when someone has written the code already. :)
Thanks. I refreshed both patches (OVMF and QEMU -- no code changes just more precise commit messages). Unfortunately, quite a few things seem broken, although these patches worked a year ago. My QEMU base commit is current master 83c83f9a5266. My host kernel is 3.10.0-514.el7.x86_64. *** So, when I test these two patches, based on edk2 master (no on-list patches), Ia32 target, my boot hangs (spins) with the log ending in: > SmmInstallProtocolInterface: [EdkiiSmmExitBootServicesProtocol] 0 That is, MpInitChangeApLoopCallback() is entered, but it never finishes. "info cpus" prints: * CPU #0: pc=0x000000007f1f7763 thread_id=17395 CPU #1: pc=0x000000007f2ce01e (halted) thread_id=17396 CPU #2: pc=0x000000007f2ce01e (halted) thread_id=17397 CPU #3: pc=0x00000000fffffff0 thread_id=17398 and I've also seen a case where all the APs were stuck at the reset vector (0x00000000fffffff0), *not* halted, like VCPU#3 above. They don't spin, they're just stuck. The spinning comes from CPU#0, apparently in MpInitChangeApLoopCallback. *** I flipped the AP sync mode to traditional (considering the relaxed mode shouldn't be required with the broadcast SMIs). This time the log ends with: > SmmInstallProtocolInterface: [EdkiiSmmExitBootServicesProtocol] 0 > MpInitChangeApLoopCallback() done! but then QEMU abort()s: > kvm_io_ioeventfd_add: error adding ioeventfd: File exists > 2016-11-14 17:00:41.405+0000: shutting down, reason=crashed I see some ioeventfd stuff in the recent QEMU history; do you think it's related? *** My last attempt was even more strange. I applied Jeff's v2 (this series), returned to the relaxed (= currently in-tree) sync mode, and (of course) the broadcast SMI patches on both sides. This time I didn't even boot an OS, I just entered the setup TUI, and selected the Reset option. QEMU crashed again with: > kvm_io_ioeventfd_add: error adding ioeventfd: File exists > 2016-11-14 17:00:41.405+0000: shutting down, reason=crashed I don't know what to look at, honestly. I think I'll check the reflog for my local QEMU master branch, and return to one of my earlier pulls, or else use v2.7.0 for testing. FWIW, the broadcast SMIs work just fine as long as I'm in the firmware (not booting an OS and not resetting, just browsing around); I verified with GDB that the broadcast SMI branch was taken in QEMU repeatedly. Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
