Re: [Qemu-devel] E5-2620v2 - emulation stop error

[Andrey Korolyov <andrey@xdel.ru>]

On Wed, Apr 1, 2015 at 2:49 PM, Radim Krčmář <rkrcmar@redhat.com> wrote:
> 2015-03-31 21:23+0300, Andrey Korolyov:
>> On Tue, Mar 31, 2015 at 9:04 PM, Bandan Das <bsd@redhat.com> wrote:
>> > Bandan Das <bsd@redhat.com> writes:
>> >> Andrey Korolyov <andrey@xdel.ru> writes:
>> >> ...
>> >>> http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz
>> >>>
>> >>> Something a bit more interesting, but the mess is happening just
>> >>> *after* NMI firing.
>> >>
>> >> What happens if NMI is turned off on the host ?
>> >
>> > Sorry, I meant the watchdog..
>>
>> Thanks, everything goes well (as it probably should go there):
>> http://xdel.ru/downloads/kvm-e5v2-issue/apicv-enabled-nmi-disabled.dat.gz
>
> Nice revelation!
>
> KVM doesn't expect host's NMIs to look like this so it doesn't pass them
> to the host.  What was the watchdog that casually sent NMIs?
> (It worked after "nmi_watchdog=0" on the host?)
>
> (Guest's NMI should have a different result as well.  NMI_EXCEPTION is
>  an expected exit reason for guest's hard exceptions, they are then
>  differentiated by intr_info and nothing hinted that this was a NMI.)

Yes, I disabled host watchdog during runtime. Indeed guest-induced NMI
would look different and they had no reasons to be fired at this stage
inside guest. I`d suspect a hypervisor hardware misbehavior there but
have a very little idea on how APICv behavior (which is completely
microcode-dependent and CPU-dependent but decoupled from peripheral
hardware) may vary at this point, I am using 1.20140913.1 ucode
version from debian if this can matter. Will send trace suggested by
Paolo in a next couple of hours. Also it would be awesome to ask
hardware folks from Intel who can prove or disprove my abovementioned
statement (as I was unable to catch the problem on 2603v2 so far, this
hypothesis has some chance to be real).