[EMAIL PROTECTED] wrote: >>> Could you be more specific on whats left to be done? From >>> what I could read in the doc, this seemed complete. >>> >> >> This is a good start, and we also need to add a vmexit handler to >> handle exit reason 8, NMI pending. > > Ah, yes. Thank you for finding that. > >> And the major issue, I think, is how guest uses NMI, although from >> virtualization view, we should not think from that, but we need make >> sure all possible guest NMI usage model works well. > > Note that the guest can (and does) use NMI today independent > of this patch and it works fine. In fact, some version of > linux do this on a regular basis (they map LINT0 to NMI). > > This patch only affects whether NMIs are injected using the > standard event-injection (INTR_TYPE_EXT_INTR) technique on > vector 2, or using the VNMI facility (INTR_TYPE_NMI) instead. > My impression is that the guest dispatches the IRQ-2 to the > IDT in the same way in either case. The only difference is > that VNMI method allows the event to be injected even if > RFLAGS.IF is masking normal interrupts, thus more closely > modeling the real world counterpart. > NMI can be injected even RFLAGS.IF=0, but it can be blocked by previous NMI. If we want to handle NMI in this patch, we need to add the logic of NMI block and unblock. Like you said, this needs new hardware support and may not in your box yet :-( BTW, We have a close to workable patch for NMI support in Xen now, but still debug on that, I would image we can reuse that patch in KVM easily, so maybe temply remove it is a good idea :-) Eddie
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
