On Wednesday 14 April 2010 17:57:50 Avi Kivity wrote: > On 04/14/2010 12:43 PM, Sheng Yang wrote: > > On Wednesday 14 April 2010 17:20:15 Avi Kivity wrote: > >> On 04/14/2030 12:05 PM, Zhang, Yanmin wrote: > >>> Here is the new patch of V3 against tip/master of April 13th > >>> if anyone wants to try it. > >> > >> Thanks for persisting despite the flames. > >> > >> Can you please separate arch/x86/kvm part of the patch? That will make > >> for easier reviewing, and will need to go through separate trees. > >> > >> Sheng, did you make any progress with the NMI injection issue? > > > > Yes, though some other works interrupt me lately... > > > > The very first version has issue due to SELF_IPI mode can't be used to > > send NMI according to SDM. That's the reason why x2apic don't have way to > > do this. > > Yes, I see that now. Looks like others have the same questions... > > > But later I found another issue of fail to inspect inside the guest. I > > think it's due to NMI is asynchronous event, though it should be > > triggered very quickly, you can't guarantee that the handler would be > > triggered before the state(current_vcpu) is cleared with current code. > > > > Maybe just extended the "guest state" region would be fine, if the > > latency is stable enough(though I think it maybe platform depended). I am > > working on this now. > > I wouldn't like to depend on model specific behaviour. > > One option is to read all the information synchronously and store it in > a per-cpu area with atomic instructions, then queue the NMI. Another > option is to have another callback which tells us that the NMI is done, > and have a busy loop wait until the NMI is delivered. > Callback seems too heavy, may affect the performance badly. Maybe a short queue would help, though this one is more complex. But I am still curious if we extend the region, how much it would help. Would get a result soon... -- regards Yang, Sheng -- 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
