All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Kautuk Consul <kconsul@linux.vnet.ibm.com>
Cc: Fabiano Rosas <farosas@linux.ibm.com>,
	Alexey Kardashevskiy <aik@ozlabs.ru>,
	linux-kernel@vger.kernel.org,
	Sathvika Vasireddy <sv@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 2/2] arch/powerpc/kvm: kvmppc_hv_entry: remove r4 argument
Date: Thu, 16 Mar 2023 14:39:08 +1100	[thread overview]
Message-ID: <87wn3hmkkj.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <ZBFVAxAFsUJtuzEy@li-a450e7cc-27df-11b2-a85c-b5a9ac31e8ef.ibm.com>

Kautuk Consul <kconsul@linux.vnet.ibm.com> writes:
> On 2023-03-15 15:48:53, Michael Ellerman wrote:
>> Kautuk Consul <kconsul@linux.vnet.ibm.com> writes:
>> > kvmppc_hv_entry is called from only 2 locations within
>> > book3s_hv_rmhandlers.S. Both of those locations set r4
>> > as HSTATE_KVM_VCPU(r13) before calling kvmppc_hv_entry.
>> > So, shift the r4 load instruction to kvmppc_hv_entry and
>> > thus modify the calling convention of this function.
>> >
>> > Signed-off-by: Kautuk Consul <kconsul@linux.vnet.ibm.com>
>> > ---
>> >  arch/powerpc/kvm/book3s_hv_rmhandlers.S | 9 ++++-----
>> >  1 file changed, 4 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> > index b81ba4ee0521..da9a15db12fe 100644
>> > --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> > +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> > @@ -85,7 +85,7 @@ _GLOBAL_TOC(kvmppc_hv_entry_trampoline)
>> >  	RFI_TO_KERNEL
>> >  
>> >  kvmppc_call_hv_entry:
>> > -	ld	r4, HSTATE_KVM_VCPU(r13)
>> > +	/* Enter guest. */
>> >  	bl	kvmppc_hv_entry
>> >  
>> >  	/* Back from guest - restore host state and return to caller */
>> > @@ -352,9 +352,7 @@ kvm_secondary_got_guest:
>> >  	mtspr	SPRN_LDBAR, r0
>> >  	isync
>> >  63:
>> > -	/* Order load of vcpu after load of vcore */
>> > -	lwsync
>> 
>> Where did this barrier go?
>> 
>> I don't see that it's covered by any existing barriers in
>> kvmppc_hv_entry, and you don't add it back anywhere. 
>
> My concept about this is that since now the call to kvmppc_hv_entry
> is first taken before the load to r4 shouldn't the pending load in the
> pipeline of the HSTATE_KVM_VCORE as per the earlier comment be ordered anyway
> before-hand ?

No.
 
> Or do you mean to say that pending loads may not be
> cleared/flushed across the "bl <funcname>" boundary ?

Right.

The "bl" imposes no ordering on loads before or after it.

In general nothing orders two independant loads, other than a barrier.

cheers

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Kautuk Consul <kconsul@linux.vnet.ibm.com>
Cc: Nicholas Piggin <npiggin@gmail.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Sathvika Vasireddy <sv@linux.ibm.com>,
	Alexey Kardashevskiy <aik@ozlabs.ru>,
	Fabiano Rosas <farosas@linux.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] arch/powerpc/kvm: kvmppc_hv_entry: remove r4 argument
Date: Thu, 16 Mar 2023 14:39:08 +1100	[thread overview]
Message-ID: <87wn3hmkkj.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <ZBFVAxAFsUJtuzEy@li-a450e7cc-27df-11b2-a85c-b5a9ac31e8ef.ibm.com>

Kautuk Consul <kconsul@linux.vnet.ibm.com> writes:
> On 2023-03-15 15:48:53, Michael Ellerman wrote:
>> Kautuk Consul <kconsul@linux.vnet.ibm.com> writes:
>> > kvmppc_hv_entry is called from only 2 locations within
>> > book3s_hv_rmhandlers.S. Both of those locations set r4
>> > as HSTATE_KVM_VCPU(r13) before calling kvmppc_hv_entry.
>> > So, shift the r4 load instruction to kvmppc_hv_entry and
>> > thus modify the calling convention of this function.
>> >
>> > Signed-off-by: Kautuk Consul <kconsul@linux.vnet.ibm.com>
>> > ---
>> >  arch/powerpc/kvm/book3s_hv_rmhandlers.S | 9 ++++-----
>> >  1 file changed, 4 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> > index b81ba4ee0521..da9a15db12fe 100644
>> > --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> > +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> > @@ -85,7 +85,7 @@ _GLOBAL_TOC(kvmppc_hv_entry_trampoline)
>> >  	RFI_TO_KERNEL
>> >  
>> >  kvmppc_call_hv_entry:
>> > -	ld	r4, HSTATE_KVM_VCPU(r13)
>> > +	/* Enter guest. */
>> >  	bl	kvmppc_hv_entry
>> >  
>> >  	/* Back from guest - restore host state and return to caller */
>> > @@ -352,9 +352,7 @@ kvm_secondary_got_guest:
>> >  	mtspr	SPRN_LDBAR, r0
>> >  	isync
>> >  63:
>> > -	/* Order load of vcpu after load of vcore */
>> > -	lwsync
>> 
>> Where did this barrier go?
>> 
>> I don't see that it's covered by any existing barriers in
>> kvmppc_hv_entry, and you don't add it back anywhere. 
>
> My concept about this is that since now the call to kvmppc_hv_entry
> is first taken before the load to r4 shouldn't the pending load in the
> pipeline of the HSTATE_KVM_VCORE as per the earlier comment be ordered anyway
> before-hand ?

No.
 
> Or do you mean to say that pending loads may not be
> cleared/flushed across the "bl <funcname>" boundary ?

Right.

The "bl" imposes no ordering on loads before or after it.

In general nothing orders two independant loads, other than a barrier.

cheers

  parent reply	other threads:[~2023-03-16  3:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-06 12:37 [PATCH v2 0/2] Improving calls to kvmppc_hv_entry Kautuk Consul
2023-03-06 12:37 ` [PATCH v2 1/2] arch/powerpc/kvm: kvmppc_hv_entry: remove .global scope Kautuk Consul
2023-03-06 12:37 ` [PATCH v2 2/2] arch/powerpc/kvm: kvmppc_hv_entry: remove r4 argument Kautuk Consul
2023-03-15  4:48   ` Michael Ellerman
2023-03-15  5:17     ` Kautuk Consul
2023-03-15  5:17       ` Kautuk Consul
2023-03-15  5:37       ` Kautuk Consul
2023-03-15  5:37         ` Kautuk Consul
2023-03-16  3:39       ` Michael Ellerman [this message]
2023-03-16  3:39         ` Michael Ellerman
2023-03-16  3:40         ` Michael Ellerman
2023-03-16  3:40           ` Michael Ellerman
2023-03-16  3:49         ` Kautuk Consul
2023-03-16  3:49           ` Kautuk Consul
2023-03-13  5:39 ` [PATCH v2 0/2] Improving calls to kvmppc_hv_entry Kautuk Consul

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=87wn3hmkkj.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=aik@ozlabs.ru \
    --cc=farosas@linux.ibm.com \
    --cc=kconsul@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=sv@linux.ibm.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.