On 14/11/2016 19:07, Laszlo Ersek wrote: > 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?
Yes, just try 2.7 for now or disable vhost. Paolo > *** 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
