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... Jan, seems we need to do more investigating on the issues you met... -- regards Yang, Sheng > > And is it safe to > > assume VMX == LAPIC available and usable? > > Yes. > > > However, this is how it would look like. > > I'd define a send_nmi_self() instead, to allow the implementation to > change (x2apic/etc). > > > Yet untested, /me has to > > replace his host kernel first... > > You could test it in a VM, if someone implements nested vmx :) > > btw, looks like svm is not affected by this. > > -- > error compiling committee.c: too many arguments to function -- 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
