Re: [Xen-devel] Crash of guest with nested vmx with Unknown nested vmexit reason 80000021.

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Jeroen Groenewegen van der Weyden wrote on 2014-10-10:
> Hi all,
> 
> Any input from my side necessary to keep this rolling?

Sorry for the later reply. Yes, this is a known issue to me but I didn't have 
time to cook a patch fix it. As Jan pointed out, the NMI handling logic is 
wrong in current nested logic. But it is not a trivial task to fix them. I will 
do it once I have the time or if you are interesting in it, a patch from you is 
welcome.

> 
> BR,
> Jeroen.
> 
> Tian, Kevin schreef op 7-10-2014 om 21:56:
>> Add Yang as the nested vmx owner.
>> 
>>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>>> Sent: Tuesday, October 07, 2014 12:59 AM
>>> 
>>>>>> On 30.09.14 at 17:55, <groen692@xxxxxxxxx> wrote:
>>>> Recently I updated my openSuse box from 12.3 to 13.1. On this box
>>>> I run xen with several guests. One of these guests is an appliance
>>>> that has 4 kvm guests running.
>>>> When I start this appliance with the nested vmx feature the
>>>> appliance crashes either immediately or after a few minutes.
>>>> 
>>>> This same guest was running without a problem on opensuse releases
>>>> 11.4 until 12.3 [...] ==== outup xl demsg
>>>> (XEN) vvmx.c:2459:d5 Unknown nested vmexit reason 80000021.
>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid
>>>> guest state (0).
>>>> (XEN) ************* VMCS Area ************** [...]
>>> So the problem here is that
>>> 
>>>> (XEN) Interruptibility=0008 ActivityState=0000
>>> VMX_INTR_SHADOW_NMI is set while
>>> 
>>>> (XEN) PinBased=0000003f CPUBased=b6b9e5fa SecondaryExec=000004eb
>>> PIN_BASED_VIRTUAL_NMIS is active and
>>> 
>>>> (XEN) VMEntry: intr_info=80000202 errcode=5d021101 ilen=00000003
>>>> (XEN) VMExit: intr_info=00000000 errcode=00000000 ilen=00000003
>>>> (XEN)         reason=80000021 qualification=00000000
>>>> (XEN) IDTVectoring: info=80000202 errcode=00000000
>>> an NMI is being injected. This case is explicitly mentioned in Vol
>>> 3 section 31.7.1.2 (Resuming Guest Software after Handling an
>>> Exception). Either there needs to be extra code in vvmx.c to clear
>>> VMX_INTR_SHADOW_NMI (as the second sub-bullet point of the last
>>> bullet point says), or the second half of vmx_idtv_reinject() needs
>>> to be done without regard to nestedhvm_vcpu_in_guestmode(v) (and
>>> maybe also without regard to EXIT_REASON_TASK_SWITCH).
>>> 
>>> Speaking of SDM sections: There are quite a few references in the
>>> code that name just section numbers (in the case here, several
>>> references to sections 25.7.1.* exist). These numbers become stale
>>> quite quickly (here they're now 31.7.1.*), so in order to help
>>> digging through issues like the one here, can I please ask one of
>>> you to go through and replace (or at least amend) these numbers
>>> with the sections' titles (which I hope won't get altered that quickly)?
>>> 
>>> Jan
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel
>>


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel