Michael Ellerman <m...@ellerman.id.au> writes: > Kautuk Consul <kcon...@linux.vnet.ibm.com> writes: >> On 2023-03-15 15:48:53, Michael Ellerman wrote: >>> Kautuk Consul <kcon...@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 <kcon...@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.
There's some docs on barriers here: https://www.kernel.org/doc/Documentation/memory-barriers.txt Though admittedly it is pretty dense. cheers
