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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
