Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT handler

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.02.13 at 17:01, Keir Fraser <keir@xxxxxxx> wrote:
> On 28/02/2013 15:41, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>>>>> On 28.02.13 at 15:42, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>> ... this must not be done when on the NMI stack (i.e. when the
>>> NMI was raised while in hypervisor context). Checking for this
>>> here would be strait forward, but I was really considering to do
>>> all of this in the assembly exit path, and I was still undecided
>>> whether we shouldn't follow Linux in skipping softirq processing
>>> (and hence scheduling) on the way out from an NMI (I don't
>>> think we'd need to do the same for MCE).
>> 
>> Like this:
>> 
>> x86: skip processing events on the NMI exit path
>> 
>> Otherwise, we may end up in the scheduler, keeping NMIs masked for a
>> possibly unbounded time (until whenever the next IRET gets executed).
> 
> 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()?

Jan


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