Re: VMX: Host NMI triggering on NMI vmexit

["Yang, Sheng" <sheng.yang@intel.com>]

On Tuesday 23 September 2008 16:47:54 Jan Kiszka wrote:
> Yang, Sheng wrote:
> > On Monday 22 September 2008 19:00:38 Avi Kivity wrote:
> >> Jan Kiszka wrote:
> >>>> Maybe the answer is to generate the local nmi via an IPI-to-self
> >>>> command to the local apic.
> >>>
> >>> Going this way leaves me with a few questions: Will it be OK for the
> >>> related mainainers to export the required service?
> >>
> >> If we can make a case for it (I think we can), then I don't see why not.
> >>
> >> Sheng, can you confirm that 'int 2' is problematic, and that
> >> nmi-via-lapic is the best workaround?
> >
> > Just back from vacation... :)
> >
> > Jan said is true, "int 2" itself won't block subsequent NMIs. But I think
> > it's too obviously as a hardware issue when using with NMI exiting=1 in
> > vmx nonroot mode, so I have checked it with my colleague, finally found
> > these in SDM 3B 23-2:
> >
> > The following bullets detail when architectural state is and is not
> > updated in response to VM exits:
> > •   If an event causes a VM exit *directly*, it does not update
> > architectural state as it would have if it had it not caused the VM exit:
> > [...]
> > — *An NMI causes subsequent NMIs to be blocked*, but only after the VM
> > exit completes.
> >
> > So we needn't worry about that, and this shouldn't cause any trouble
> > AFAIK...
>
> Fine, problems--. :)
>
> > Jan, seems we need to do more investigating on the issues you met...
>
> Sorry, which one do you mean now?

You said 
"Only true until you have multiple unsynchronized NMI sources, e.g.
inter-CPU NMIs of kgdb + a watchdog. I just stumbled over several bugs
in kvm's and my own NMI code that were triggered by such a scenario
(sigh...)." ?

If it's not related to this one. That's fine. :)

-- 
regards
Yang, Sheng


>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux