On Fri, May 08, 2009 at 11:00:51PM +0800, Dong, Eddie wrote: > Gleb Natapov wrote: > > On Fri, May 08, 2009 at 06:46:14PM +0800, Dong, Eddie wrote: > >> Dong, Eddie wrote: > >>> ction will be re-executed. > >>>>> > >>>>> Do you want it to be covered for now? For exception, it is easy > >>>>> but for IRQ, it needs to be pushed back. > >>>>> > >>>> Yes I want it to be covered now otherwise any serial exception > >>>> generates flood of "Exception happens serially" messages. This > >>>> function does not handle IRQ so no problem there. > >>> > >>> But we soon will let this function cove IRQ as well per SDM. > >>> Why not do that a little bit later? > >>> > >>> BTW, this issue exist in original code as well. > >>> > >>> Eddie > >> > >> Actually this is already addressed in current patch too: Just keep > >> the former exception. If you mean the prink should be removed, I am > >> fine. > > Keeping the former exception is not the right thing to do. It can't be > > delivered because delivering it cause another exception and handler > > that may fix the situation is not called since you drop last > > exception and keep re-injecting the one that can't be handled. > > > >> BTW, this case doesn't happen in reality. > >> > > Then why do you write all this code then? :) I can easily write test > > I am fixing the potential #DF bug existing in current code which only handle > PF on PF. > For those sequential exception, it is WARN_ON in current code. > Can your describe real life scenario that needs this fix? I am all for fixing code and be as close as possible to SDM, but if you do it do it right. > > case that will do that (actually I did) and if not handled properly it > > just loops taking 100% cpu trying to reinject exception that cannot be > > handled. > > Are u sure current code is dead loop in WARN_ON with your test code? Yes. > I don't see it will never happen and thus why printk it, but shouldn't exist I have the code that triggers this path. Good enough for me. > in current guest that KVM can support. > > See original kvm_queue_exception in case you ignored the code. > There is not point referring to current code. Current code does not handle serial exceptions properly. So fix it in your patch otherwise I propose to use my patch that fixes current code (http://patchwork.kernel.org/patch/21829/). > void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr) > { > WARN_ON(vcpu->arch.exception.pending); > vcpu->arch.exception.pending = true; > vcpu->arch.exception.has_error_code = false; > vcpu->arch.exception.nr = nr; > } > > Any comments from Avi? > > Thx, eddie > -- Gleb. -- 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
