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

[Paolo Bonzini <pbonzini@redhat.com>]

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
>