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? 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
