Re: [PATCH v2 0/3] Put AP into safe hlt-loop code on S3 path

[Laszlo Ersek <lersek@redhat.com>]

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