[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Crash of guest with nested vmx with Unknown nested vmexit reason 80000021.
> -----Original Message----- > From: Zhang, Yang Z > Sent: Thursday, October 16, 2014 2:18 PM > To: Jeroen Groenewegen van der Weyden; Tian, Kevin; Jan Beulich; Dong, Eddie; > Nakajima, Jun > Cc: xen-devel@xxxxxxxxxxxxx > Subject: RE: [Xen-devel] Crash of guest with nested vmx with Unknown nested > vmexit reason 80000021. > > 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. You can find the previous discussion here: http://www.gossamer-threads.com/lists/xen/devel/322693?do=post_view_threaded > > > > > 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 > --- Begin Message --- _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |