Re: Implement generic double fault generation mechanism

[Gleb Natapov <gleb@redhat.com>]

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.