On Thursday 15 April 2010 18:44:15 Avi Kivity wrote: > On 04/15/2010 01:40 PM, Joerg Roedel wrote: > >> That means an NMI that happens outside guest code (for example, in the > >> mmu, or during the exit itself) would be counted as if in guest code. > > > > Hmm, true. The same is true for an NMI that happens between VMSAVE and > > STGI but that window is smaller. Anyway, I think we don't need the > > busy-wait loop. The NMI should be executed at a well defined point and > > we set the cpu_var back to NULL after that point. > > The point is not well defined. Considering there are already at least > two implementations svm, I don't want to rely on implementation details. After more investigating, I realized that I had interpreted the SDM wrong. Sorry. There is *no* risk with the original method of calling "int $2". According to the SDM 24.1: > The following bullets detail when architectural state is and is not updated in response to VM exits: [...] > - An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes. So the truth is, after NMI directly caused VMExit, the following NMIs would be blocked, until encountered next "iret". So execute "int $2" is safe in vmx_complete_interrupts(), no risk in causing nested NMI. And it would unblock the following NMIs as well due to "iret" it executed. So there is unnecessary to make change to avoid "potential nested NMI". Sorry for the mistake and caused confusing. -- regards Yang, Sheng > > We could tune the position of the loop so that zero iterations are > executed on the implementations we know about. > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
