From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hollis Blanchard <hollisb@us.ibm.com>
Date: Wed, 23 Jan 2008 23:31:35 +0000
Subject: Re: [kvm-ppc-devel] [PATCH] Add Interrupt handling to kvm power
Message-Id: <1201131095.22329.78.camel@basalt>
List-Id: <kvm-ppc.vger.kernel.org>
References: <7398b53dfa146c5d6931.1201042735@thinkpad>
In-Reply-To: <7398b53dfa146c5d6931.1201042735@thinkpad>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: kvm-ppc@vger.kernel.org

I'm concerned about taking two interrupts at once, which would clobber
SRR0/1. Consider this case (all within a single exit):

        PC = foo (somewhere in guest)
        <external interrupt>
        SRR0 = foo
        PC = 0x500
        <decrementer interrupt>
        SRR0 = 0x500
        PC = 0x900
        resume guest

Now you can never get back to PC=foo, since SRR0 was overwritten.

So we should probably only deliver an interrupt when considering all
pending interrupts. In other words, extend the test at the bottom of
kvm_handle_exit() that checks pending_dec.

We probably need to remove all callers of kvmppc_sync_interrupt() and
instead set the appropriate flag in a "pending" mask. Then, just before
returning to the guest, do something like this:

        can_deliver(vcpu, priority) {
                return vcpu->arch.msr & priority_enabled[priority];
        }

        priority = find_first_bit(vcpu->arch.pending);
        while (priority) {
                if (can_deliver(vcpu, priority)) {
                        interrupt = priority_to_interrupt[priority];
                        kvmppc_deliver_interrupt(interrupt);
                        break;
                }
                        
                priority = find_next_bit(vcpu->arch.pending, priority);
        }
        
"arch.pending" would need to be in priority order. According to the
architecture, when there are multiple exceptions pending (e.g. program
interrupt and decrementer and external all fire at the same time), there
is a well-defined list of priorities. Of course, we'd also need a table
of MSR masks to check, since you can disable all these things in the
MSR.

(Rename kvmppc_sync_interrupt() to kvmppc_deliver_interrupt(), since I
was wrong in thinking that we could handle synchronous interrupts
immediately and only defer asynchronous ones.)

Once you do that, kvm_vcpu_ioctl_interrupt() just becomes
        vcpu->arch.pending |= PRIORITY_EXTERNAL;
and all the magic happens on the subsequent KVM_RUN command. Well, I
guess we'd need to insert similar magic on the RUN path (the above was
on the "handle exit" path).

-- 
Hollis Blanchard
IBM Linux Technology Center



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel