Re: VMX: Host NMI triggering on NMI vmexit

[Jan Kiszka <jan.kiszka@siemens.com>]

Yang, Sheng wrote:
> 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. :)

Nope, the actual issues were related to guests facing "NMI storms" (and
should be fixed by my series). That made me wonder what would happen on
the host side if int 2 wasn't safe. But it is, as we know now.

Jan

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