From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT handler Date: Thu, 28 Feb 2013 19:02:04 +0000 Message-ID: References: <512F913902000078000C222A@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <512F913902000078000C222A@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Tim Deegan Cc: Andrew Cooper , Malcolm Crossley , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 28/02/2013 16:17, "Jan Beulich" wrote: >> Is this alternative that we might not process events for an unbounded time? >> No, I guess not -- either we would interrupt the notifying IPI and we will >> be IRETing into that IPI's handler, or the notifying IPI is delayed until >> the NMI handler's IRET. >> >> What about if the NMI handler itself raises an event (eg softirq)? Perhaps >> there are no very essential ones of those? > > We do raise PCI_SERR_SOFTIRQ, and the possibly injected NMI > (to Dom0) might get slightly deferred too. The latter seems of > little concern (Dom0 will get the event eventually). For the > former, we might want to explicitly send a self-IPI with > EVENT_CHECK_VECTOR following the raise_softirq()? Or perhaps self-IPI on the NMI exit path if softirq_pending is non-zero? Conservative but more generic. -- Keir