All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabiano Rosas <farosas@linux.ibm.com>
To: Nicholas Piggin <npiggin@gmail.com>, linuxppc-dev@lists.ozlabs.org
Cc: "Cédric Le Goater" <clg@kaod.org>, "Nicholas Piggin" <npiggin@gmail.com>
Subject: Re: [PATCH 3/6] KVM: PPC: Book3S HV P9: Move cede logic out of XIVE escalation rearming
Date: Wed, 09 Mar 2022 11:41:30 -0300	[thread overview]
Message-ID: <878rtjb339.fsf@linux.ibm.com> (raw)
In-Reply-To: <20220303053315.1056880-4-npiggin@gmail.com>

Nicholas Piggin <npiggin@gmail.com> writes:

> Move the cede abort logic out of xive escalation rearming and into
> the caller to prepare for handling a similar case with nested guest
> entry.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
>  arch/powerpc/include/asm/kvm_ppc.h |  4 ++--
>  arch/powerpc/kvm/book3s_hv.c       | 10 ++++++++--
>  arch/powerpc/kvm/book3s_xive.c     |  9 ++++++---
>  3 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index a14dbcd1b8ce..94fa5f246657 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -671,7 +671,7 @@ extern int kvmppc_xive_set_irq(struct kvm *kvm, int irq_source_id, u32 irq,
>  			       int level, bool line_status);
>  extern void kvmppc_xive_push_vcpu(struct kvm_vcpu *vcpu);
>  extern void kvmppc_xive_pull_vcpu(struct kvm_vcpu *vcpu);
> -extern void kvmppc_xive_rearm_escalation(struct kvm_vcpu *vcpu);
> +extern bool kvmppc_xive_rearm_escalation(struct kvm_vcpu *vcpu);
>
>  static inline int kvmppc_xive_enabled(struct kvm_vcpu *vcpu)
>  {
> @@ -709,7 +709,7 @@ static inline int kvmppc_xive_set_irq(struct kvm *kvm, int irq_source_id, u32 ir
>  				      int level, bool line_status) { return -ENODEV; }
>  static inline void kvmppc_xive_push_vcpu(struct kvm_vcpu *vcpu) { }
>  static inline void kvmppc_xive_pull_vcpu(struct kvm_vcpu *vcpu) { }
> -static inline void kvmppc_xive_rearm_escalation(struct kvm_vcpu *vcpu) { }
> +static inline bool kvmppc_xive_rearm_escalation(struct kvm_vcpu *vcpu) { return true; }
>
>  static inline int kvmppc_xive_enabled(struct kvm_vcpu *vcpu)
>  	{ return 0; }
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 5df359053147..a0b674d3a2da 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -4073,10 +4073,16 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit,
>  		    !(vcpu->arch.shregs.msr & MSR_PR)) {
>  			unsigned long req = kvmppc_get_gpr(vcpu, 3);
>
> -			/* H_CEDE has to be handled now, not later */
> +			/* H_CEDE has to be handled now */
>  			if (req == H_CEDE) {
>  				kvmppc_cede(vcpu);
> -				kvmppc_xive_rearm_escalation(vcpu); /* may un-cede */
> +				if (!kvmppc_xive_rearm_escalation(vcpu)) {
> +					/*
> +					 * Pending escalation so abort
> +					 * the cede.
> +					 */
> +					vcpu->arch.ceded = 0;

This was moved after the mb() in kvmppc_xive_rearm_escalation, so I
think a concurrent H_PROD might continue to see tvcpu->arch.ceded = 1
after the escalation has been set. Is this an issue?

> +				}
>  				kvmppc_set_gpr(vcpu, 3, 0);
>  				trap = 0;
>
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index e216c068075d..7b513e14cada 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -179,12 +179,13 @@ void kvmppc_xive_pull_vcpu(struct kvm_vcpu *vcpu)
>  }
>  EXPORT_SYMBOL_GPL(kvmppc_xive_pull_vcpu);
>
> -void kvmppc_xive_rearm_escalation(struct kvm_vcpu *vcpu)
> +bool kvmppc_xive_rearm_escalation(struct kvm_vcpu *vcpu)
>  {
>  	void __iomem *esc_vaddr = (void __iomem *)vcpu->arch.xive_esc_vaddr;
> +	bool ret = true;
>
>  	if (!esc_vaddr)
> -		return;
> +		return ret;
>
>  	/* we are using XIVE with single escalation */
>
> @@ -197,7 +198,7 @@ void kvmppc_xive_rearm_escalation(struct kvm_vcpu *vcpu)
>  		 * we also don't want to set xive_esc_on to 1 here in
>  		 * case we race with xive_esc_irq().
>  		 */
> -		vcpu->arch.ceded = 0;
> +		ret = false;
>  		/*
>  		 * The escalation interrupts are special as we don't EOI them.
>  		 * There is no need to use the load-after-store ordering offset
> @@ -210,6 +211,8 @@ void kvmppc_xive_rearm_escalation(struct kvm_vcpu *vcpu)
>  		__raw_readq(esc_vaddr + XIVE_ESB_SET_PQ_00);
>  	}
>  	mb();
> +
> +	return ret;
>  }
>  EXPORT_SYMBOL_GPL(kvmppc_xive_rearm_escalation);

  parent reply	other threads:[~2022-03-09 14:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-03  5:33 [PATCH 0/6] KVM: PPC: Book3S HV interrupt fixes Nicholas Piggin
2022-03-03  5:33 ` [PATCH 1/6] KVM: PPC: Book3S HV P9: Fix "lost kick" race Nicholas Piggin
2022-03-09 13:07   ` Fabiano Rosas
2022-03-03  5:33 ` [PATCH 2/6] KVM: PPC: Book3S HV P9: Inject pending xive interrupts at guest entry Nicholas Piggin
2022-03-07 23:19   ` Fabiano Rosas
2022-03-03  5:33 ` [PATCH 3/6] KVM: PPC: Book3S HV P9: Move cede logic out of XIVE escalation rearming Nicholas Piggin
2022-03-09 13:55   ` Cédric Le Goater
2022-03-09 14:41   ` Fabiano Rosas [this message]
2022-03-03  5:33 ` [PATCH 4/6] KVM: PPC: Book3S HV P9: Split !nested case out from guest entry Nicholas Piggin
2022-03-09 17:17   ` Fabiano Rosas
2022-03-03  5:33 ` [PATCH 5/6] KVM: PPC: Book3S HV Nested: L2 must not run with L1 xive context Nicholas Piggin
2022-03-03  5:33 ` [PATCH 6/6] KVM: PPC: Book3S HV Nested: L2 LPCR should inherit L1 LPES setting Nicholas Piggin
2022-03-09 19:49   ` Fabiano Rosas
2022-05-24 10:51 ` [PATCH 0/6] KVM: PPC: Book3S HV interrupt fixes Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878rtjb339.fsf@linux.ibm.com \
    --to=farosas@linux.ibm.com \
    --cc=clg@kaod.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.