On 12/09/2011 09:26 AM, Alexander Graf wrote: > When entering the guest, we want to make sure we're not getting preempted > away, so let's disable preemption on entry, but enable it again while handling > guest exits. > > Reported-by: Jörg Sommer <[email protected]> > Signed-off-by: Alexander Graf <[email protected]> > --- > arch/powerpc/kvm/book3s_pr.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c > index 726512b..8e4f800 100644 > --- a/arch/powerpc/kvm/book3s_pr.c > +++ b/arch/powerpc/kvm/book3s_pr.c > @@ -519,6 +519,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct > kvm_vcpu *vcpu, > run->ready_for_interrupt_injection = 1; > > trace_kvm_book3s_exit(exit_nr, vcpu); > + preempt_enable(); > kvm_resched(vcpu); > switch (exit_nr) { > case BOOK3S_INTERRUPT_INST_STORAGE: > @@ -763,6 +764,8 @@ program_interrupt: > run->exit_reason = KVM_EXIT_INTR; > r = -EINTR; > } else { > + preempt_disable(); > + > /* In case an interrupt came in that was triggered > * from userspace (like DEC), we need to check what > * to inject now! */
Shouldn't you really have interrupts disabled here, as booke does? Otherwise an interrupt (including an IPI kick) could send you a signal or guest exception after you check. Likewise for other guest entry points. -Scott -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
