public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Simon Guo <wei.guo.simon@gmail•com>
To: Paul Mackerras <paulus@ozlabs•org>
Cc: kvm-ppc@vger•kernel.org, kvm@vger•kernel.org,
	linuxppc-dev@lists•ozlabs.org
Subject: Re: [PATCH 10/11] KVM: PPC: reconstruct LOAD_VMX/STORE_VMX instruction mmio emulation with analyse_intr() input
Date: Thu, 3 May 2018 17:43:01 +0800	[thread overview]
Message-ID: <20180503094301.GJ6755@simonLocalRHEL7.x64> (raw)
In-Reply-To: <20180503061715.GK6795@fergus.ozlabs.ibm.com>

On Thu, May 03, 2018 at 04:17:15PM +1000, Paul Mackerras wrote:
> On Wed, Apr 25, 2018 at 07:54:43PM +0800, wei.guo.simon@gmail•com wrote:
> > From: Simon Guo <wei.guo.simon@gmail•com>
> > 
> > This patch reconstructs LOAD_VMX/STORE_VMX instruction MMIO emulation with
> > analyse_intr() input. When emulating the store, the VMX reg will need to
> > be flushed so that the right reg val can be retrieved before writing to
> > IO MEM.
> > 
> > Suggested-by: Paul Mackerras <paulus@ozlabs•org>
> > Signed-off-by: Simon Guo <wei.guo.simon@gmail•com>
> 
> This looks fine for lvx and stvx, but now we are also doing something
> for the vector element loads and stores (lvebx, stvebx, lvehx, stvehx,
> etc.) without having the logic to insert or extract the correct
> element in the vector register image.  We need either to generate an
> error for the element load/store instructions, or handle them
> correctly.
Yes. I will consider that.

> 
> > diff --git a/arch/powerpc/kvm/emulate_loadstore.c b/arch/powerpc/kvm/emulate_loadstore.c
> > index 2dbdf9a..0bfee2f 100644
> > --- a/arch/powerpc/kvm/emulate_loadstore.c
> > +++ b/arch/powerpc/kvm/emulate_loadstore.c
> > @@ -160,6 +160,27 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
> >  					KVM_MMIO_REG_FPR|op.reg, size, 1);
> >  			break;
> >  #endif
> > +#ifdef CONFIG_ALTIVEC
> > +		case LOAD_VMX:
> > +			if (kvmppc_check_altivec_disabled(vcpu))
> > +				return EMULATE_DONE;
> > +
> > +			/* VMX access will need to be size aligned */
> 
> This comment isn't quite right; it isn't that the address needs to be
> size-aligned, it's that the hardware forcibly aligns it.  So I would
> say something like /* Hardware enforces alignment of VMX accesses */.
> 
I will update that.

> > +			vcpu->arch.vaddr_accessed &= ~((unsigned long)size - 1);
> > +			vcpu->arch.paddr_accessed &= ~((unsigned long)size - 1);
> > +
> > +			if (size == 16) {
> > +				vcpu->arch.mmio_vmx_copy_nums = 2;
> > +				emulated = kvmppc_handle_load128_by2x64(run,
> > +						vcpu, KVM_MMIO_REG_VMX|op.reg,
> > +						1);
> > +			} else if (size <= 8)
> > +				emulated = kvmppc_handle_load(run, vcpu,
> > +						KVM_MMIO_REG_VMX|op.reg,
> > +						size, 1);
> > +
> > +			break;
> > +#endif
> >  		case STORE:
> >  			if (op.type & UPDATE) {
> >  				vcpu->arch.mmio_ra = op.update_reg;
> > @@ -197,6 +218,36 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
> >  					VCPU_FPR(vcpu, op.reg), size, 1);
> >  			break;
> >  #endif
> > +#ifdef CONFIG_ALTIVEC
> > +		case STORE_VMX:
> > +			if (kvmppc_check_altivec_disabled(vcpu))
> > +				return EMULATE_DONE;
> > +
> > +			/* VMX access will need to be size aligned */
> > +			vcpu->arch.vaddr_accessed &= ~((unsigned long)size - 1);
> > +			vcpu->arch.paddr_accessed &= ~((unsigned long)size - 1);
> > +
> > +			/* if it is PR KVM, the FP/VEC/VSX registers need to
> > +			 * be flushed so that kvmppc_handle_store() can read
> > +			 * actual VMX vals from vcpu->arch.
> > +			 */
> > +			if (!is_kvmppc_hv_enabled(vcpu->kvm))
> 
> As before, I suggest just testing that the function pointer isn't
> NULL.
Got it.

Thanks,
- Simon

  reply	other threads:[~2018-05-03  9:43 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25 11:54 [PATCH 00/11] KVM: PPC: reconstruct mmio emulation with analyse_instr() wei.guo.simon
2018-04-25 11:54 ` [PATCH 01/11] KVM: PPC: add pt_regs into kvm_vcpu_arch and move vcpu->arch.gpr[] into it wei.guo.simon
2018-04-27  3:47   ` kbuild test robot
2018-04-27 10:21     ` Simon Guo
2018-05-03  5:34   ` Paul Mackerras
2018-05-03  7:43     ` Simon Guo
2018-04-25 11:54 ` [PATCH 02/11] KVM: PPC: mov nip/ctr/lr/xer registers to pt_regs in kvm_vcpu_arch wei.guo.simon
2018-05-03  5:46   ` Paul Mackerras
2018-05-03  7:51     ` Simon Guo
2018-04-25 11:54 ` [PATCH 03/11] KVM: PPC: Fix a mmio_host_swabbed uninitialized usage issue when VMX store wei.guo.simon
2018-05-03  5:48   ` Paul Mackerras
2018-05-03  7:52     ` Simon Guo
2018-04-25 11:54 ` [PATCH 04/11] KVM: PPC: fix incorrect element_size for stxsiwx in analyse_instr wei.guo.simon
2018-05-03  5:50   ` Paul Mackerras
2018-05-03  9:05     ` Simon Guo
2018-04-25 11:54 ` [PATCH 05/11] KVM: PPC: add GPR RA update skeleton for MMIO emulation wei.guo.simon
2018-05-03  5:58   ` Paul Mackerras
2018-05-03  8:37     ` Simon Guo
2018-04-25 11:54 ` [PATCH 06/11] KVM: PPC: add KVMPPC_VSX_COPY_WORD_LOAD_DUMP type support for mmio emulation wei.guo.simon
2018-05-03  5:59   ` Paul Mackerras
2018-04-25 11:54 ` [PATCH 07/11] KVM: PPC: reconstruct non-SIMD LOAD/STORE instruction mmio emulation with analyse_intr() input wei.guo.simon
2018-05-03  6:03   ` Paul Mackerras
2018-05-03  9:07     ` Simon Guo
2018-04-25 11:54 ` [PATCH 08/11] KVM: PPC: add giveup_ext() hook for PPC KVM ops wei.guo.simon
2018-05-03  6:08   ` Paul Mackerras
2018-05-03  9:21     ` Simon Guo
2018-04-25 11:54 ` [PATCH 09/11] KVM: PPC: reconstruct LOAD_FP/STORE_FP instruction mmio emulation with analyse_intr() input wei.guo.simon
2018-05-03  6:10   ` Paul Mackerras
2018-05-03  9:25     ` Simon Guo
2018-04-25 11:54 ` [PATCH 10/11] KVM: PPC: reconstruct LOAD_VMX/STORE_VMX " wei.guo.simon
2018-05-03  6:17   ` Paul Mackerras
2018-05-03  9:43     ` Simon Guo [this message]
2018-04-25 11:54 ` [PATCH 11/11] KVM: PPC: reconstruct LOAD_VSX/STORE_VSX " wei.guo.simon
2018-05-03  6:26   ` Paul Mackerras
2018-05-03  9:46     ` Simon Guo
2018-05-03  5:31 ` [PATCH 00/11] KVM: PPC: reconstruct mmio emulation with analyse_instr() Paul Mackerras
2018-05-03  7:41   ` Simon Guo

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=20180503094301.GJ6755@simonLocalRHEL7.x64 \
    --to=wei.guo.simon@gmail$(echo .)com \
    --cc=kvm-ppc@vger$(echo .)kernel.org \
    --cc=kvm@vger$(echo .)kernel.org \
    --cc=linuxppc-dev@lists$(echo .)ozlabs.org \
    --cc=paulus@ozlabs$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox