On Thu, Nov 23, 2017 at 03:36:16PM +1100, Benjamin Herrenschmidt wrote: > This works on top of the single escalation support. When in single > escalation, with this change, we will keep the escalation interrupt > disabled unless the VCPU is in H_CEDE (idle). In any other case, we > know the VCPU will be rescheduled and thus there is no need to take > escalation interrupts in the host whenever a guest interrupt fires. Some comments below... > @@ -2705,7 +2740,32 @@ kvm_cede_prodded: > /* we've ceded but we want to give control to the host */ > kvm_cede_exit: > ld r9, HSTATE_KVM_VCPU(r13) > - b guest_exit_cont > +#ifdef CONFIG_KVM_XICS > + /* Abort if we still have a pending escalation */ This comment might be clearer if you say "Cancel cede" rather than "Abort". > diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c > index eef9ccafdc09..7a047bc88f11 100644 > --- a/arch/powerpc/kvm/book3s_xive.c > +++ b/arch/powerpc/kvm/book3s_xive.c > @@ -89,6 +89,17 @@ static irqreturn_t xive_esc_irq(int irq, void *data) > if (vcpu->arch.ceded) > kvmppc_fast_vcpu_kick(vcpu); > > + /* Since we have the no-EOI flag, the interrupt is effectively > + * disabled now. Clearing xive_esc_on means we won't bother > + * doing so on the next entry. > + * > + * This also allows the entry code to know that if a PQ combination > + * of 10 is observed while xive_esc_on is true, it means the queue > + * contains an unprocessed escalation interrupt. We don't make use of > + * that knowledge today but might (see comment in book3s_hv_rmhandler.S) Is "We don't make use of that knowledge" actually true? I thought we did make use of it in the assembly code in book3s_hv_rmhandlers.S (in the code that this patch adds). In what way don't we make use of it? Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
