linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 07/14] ARM: KVM: one_reg coproc set and get BE fixes
Date: Sun, 25 May 2014 21:14:26 +0200	[thread overview]
Message-ID: <20140525191426.GA23912@lvm> (raw)
In-Reply-To: <1399997646-4716-8-git-send-email-victor.kamensky@linaro.org>

On Tue, May 13, 2014 at 09:13:59AM -0700, Victor Kamensky wrote:
> Fix code that handles KVM_SET_ONE_REG, KVM_GET_ONE_REG ioctls to work in BE
> image. Before this fix get/set_one_reg functions worked correctly only in
> LE case - reg_from_user was taking 'void *' kernel address that actually could
> be target/source memory of either 4 bytes size or 8 bytes size, and code copied
> from/to user memory that could hold either 4 bytes register, 8 byte register
> or pair of 4 bytes registers.
> 
> For example note that there was a case when 4 bytes register was read from
> user-land to kernel target address of 8 bytes value. Because it was working
> in LE, least significant word was memcpy(ied) and it just worked. In BE code
> with 'void *' as target/source 'val' type it is impossible to tell whether
> 4 bytes register from user-land should be copied to 'val' address itself
> (4 bytes target) or it should be copied to 'val' + 4 (least significant word
> of 8 bytes value). So first change was to introduce strongly typed
> functions, where type of target/source 'val' is strongly defined:
> 
> reg_from_user_to_u64 - reads register from user-land to kernel 'u64 *val'
>                   address; register size could be 4 or 8 bytes
> reg_from_user_to_u32 - reads register(s) from user-land to kernel 'u32 *val'
>                   address; note it could be one or two 4 bytes registers
> reg_to_user_from_u64 - writes register from kernel 'u64 *val' address to
>                   user-land register memory; register size could be
>                   4 or 8 bytes
> ret_to_user_from_u32 - writes register(s) from kernel 'u32 *val' address to
>                   user-land register(s) memory; note it could be
>                   one or two 4 bytes registers
> 
> All places where reg_from_user, reg_to_user functions were used, were changed
> to use either corresponding u64 or u32 variants of functions depending on
> type of source/target kernel memory variable.
> 
> In case of 'u64 *val' and register size equals 4 bytes, reg_from_user_to_u64
> and reg_to_user_from_u64 work only with least siginificant word of
> target/source kernel value. It would be nice to deal only with u32 kernel
> values in _u32 functions and with u64 kernel values in _u64 functions,
> however it is not always possible because functions like set_invariant_cp15
> get_invariant_cp15 store values in u64 types but registers are 32bit.
> 
> Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
> ---
>  arch/arm/kvm/coproc.c | 118 +++++++++++++++++++++++++++++++++++++++-----------
>  1 file changed, 92 insertions(+), 26 deletions(-)
> 
> diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
> index c58a351..5ca6582 100644
> --- a/arch/arm/kvm/coproc.c
> +++ b/arch/arm/kvm/coproc.c
> @@ -682,17 +682,83 @@ static struct coproc_reg invariant_cp15[] = {
>  	{ CRn( 0), CRm( 0), Op1( 1), Op2( 7), is32, NULL, get_AIDR },
>  };
>  
> -static int reg_from_user(void *val, const void __user *uaddr, u64 id)
> +/*
> + * Reads register value from user-land uaddr address into kernel u64 value
> + * given by val address. Note register size could be 4 bytes, so user-land
> + * 4 bytes value will be copied into least significant word. Or register
> + * size could be 8 bytes, so function works as regular copy.
> + */

Reads a register value from a userspace address to a kernel u64
variable.  Note that the id may still encode a register size of 4 bytes,
in which case only 4 bytes will be copied from userspace into the least
significant word of *val.

> +static int reg_from_user_to_u64(u64 *val, const void __user *uaddr, u64 id)
> +{
> +	unsigned long regsize = KVM_REG_SIZE(id);
> +	union {
> +		u32	word;
> +		u64	dword;
> +	} tmp = {0};
> +
> +	if (copy_from_user(&tmp, uaddr, regsize) != 0)
> +		return -EFAULT;
> +
> +	switch (regsize) {
> +	case 4:
> +		*val = tmp.word;
> +		break;
> +	case 8:
> +		*val = tmp.dword;
> +		break;
> +	}
> +	return 0;
> +}
> +
> +/*
> + * Reads register value from user-land uaddr address to kernel u32 value
> + * or array of two u32 values. I.e. it may really copy two u32 registers
> + * when used with register which size is 8 bytes (for example V7 64
> + * bit registers like TTBR0/TTBR1).
> + */

Reads a register value from a userspace address to a kernel u32 variable
or a kernel array of two u32 values.  That is, it may really copy two
u32 registers when used with registers defined by the ABI to be 8 bytes
long (e.g. TTBR0/TTBR1).

> +static int reg_from_user_to_u32(u32 *val, const void __user *uaddr, u64 id)
>  {
> -	/* This Just Works because we are little endian. */
>  	if (copy_from_user(val, uaddr, KVM_REG_SIZE(id)) != 0)
>  		return -EFAULT;
>  	return 0;
>  }
>  
> -static int reg_to_user(void __user *uaddr, const void *val, u64 id)
> +/*
> + * Writes register value to user-land uaddr address from kernel u64 value
> + * given by val address. Note register size could be 4 bytes, so only 4
> + * bytes from least significant word will by copied into uaddr address.
> + * In case of 8 bytes sized register it works as regular copy. 
> + */

Writes a register value to a userspace address from a kernel u64 value.
Note that the register size could be only 4 bytes, in which case only
the least significant 4 bytes will be copied into to the userspace
address.

> +static int reg_to_user_from_u64(void __user *uaddr, const u64 *val, u64 id)
> +{
> +	unsigned long regsize = KVM_REG_SIZE(id);
> +	union {
> +		u32	word;
> +		u64	dword;
> +	} tmp;
> +
> +	switch (regsize) {
> +	case 4:
> +		tmp.word = *val;
> +		break;
> +	case 8:
> +		tmp.dword = *val;
> +		break;
> +	}
> +
> +	if (copy_to_user(uaddr, &tmp, regsize) != 0)
> +		return -EFAULT;
> +	return 0;
> +}
> +
> +/*
> + * Writes register value to user-land uaddr address from kernel u32 value
> + * or arra of two u32 values. I.e it may really copy two u32 registers
> + * when used with register which size is 8 bytes (for example V7 64
> + * bit registers like TTBR0/TTBR1).
> + */

Writes a register value to a userspace address from a kernel u32 variable
or a kernel array of two u32 values.  That is, it may really copy two
u32 registers when used with registers defined by the ABI to be 8 bytes
long (e.g. TTBR0/TTBR1).

> +static int reg_to_user_from_u32(void __user *uaddr, const u32 *val, u64 id)
>  {
> -	/* This Just Works because we are little endian. */
>  	if (copy_to_user(uaddr, val, KVM_REG_SIZE(id)) != 0)
>  		return -EFAULT;
>  	return 0;
> @@ -710,7 +776,7 @@ static int get_invariant_cp15(u64 id, void __user *uaddr)
>  	if (!r)
>  		return -ENOENT;
>  
> -	return reg_to_user(uaddr, &r->val, id);
> +	return reg_to_user_from_u64(uaddr, &r->val, id);
>  }
>  
>  static int set_invariant_cp15(u64 id, void __user *uaddr)
> @@ -726,7 +792,7 @@ static int set_invariant_cp15(u64 id, void __user *uaddr)
>  	if (!r)
>  		return -ENOENT;
>  
> -	err = reg_from_user(&val, uaddr, id);
> +	err = reg_from_user_to_u64(&val, uaddr, id);
>  	if (err)
>  		return err;
>  
> @@ -894,8 +960,8 @@ static int vfp_get_reg(const struct kvm_vcpu *vcpu, u64 id, void __user *uaddr)
>  	if (vfpid < num_fp_regs()) {
>  		if (KVM_REG_SIZE(id) != 8)
>  			return -ENOENT;
> -		return reg_to_user(uaddr, &vcpu->arch.vfp_guest.fpregs[vfpid],
> -				   id);
> +		return reg_to_user_from_u64(uaddr, &vcpu->arch.vfp_guest.fpregs[vfpid],
> +					    id);
>  	}
>  
>  	/* FP control registers are all 32 bit. */
> @@ -904,22 +970,22 @@ static int vfp_get_reg(const struct kvm_vcpu *vcpu, u64 id, void __user *uaddr)
>  
>  	switch (vfpid) {
>  	case KVM_REG_ARM_VFP_FPEXC:
> -		return reg_to_user(uaddr, &vcpu->arch.vfp_guest.fpexc, id);
> +		return reg_to_user_from_u32(uaddr, &vcpu->arch.vfp_guest.fpexc, id);
>  	case KVM_REG_ARM_VFP_FPSCR:
> -		return reg_to_user(uaddr, &vcpu->arch.vfp_guest.fpscr, id);
> +		return reg_to_user_from_u32(uaddr, &vcpu->arch.vfp_guest.fpscr, id);
>  	case KVM_REG_ARM_VFP_FPINST:
> -		return reg_to_user(uaddr, &vcpu->arch.vfp_guest.fpinst, id);
> +		return reg_to_user_from_u32(uaddr, &vcpu->arch.vfp_guest.fpinst, id);
>  	case KVM_REG_ARM_VFP_FPINST2:
> -		return reg_to_user(uaddr, &vcpu->arch.vfp_guest.fpinst2, id);
> +		return reg_to_user_from_u32(uaddr, &vcpu->arch.vfp_guest.fpinst2, id);
>  	case KVM_REG_ARM_VFP_MVFR0:
>  		val = fmrx(MVFR0);
> -		return reg_to_user(uaddr, &val, id);
> +		return reg_to_user_from_u32(uaddr, &val, id);
>  	case KVM_REG_ARM_VFP_MVFR1:
>  		val = fmrx(MVFR1);
> -		return reg_to_user(uaddr, &val, id);
> +		return reg_to_user_from_u32(uaddr, &val, id);
>  	case KVM_REG_ARM_VFP_FPSID:
>  		val = fmrx(FPSID);
> -		return reg_to_user(uaddr, &val, id);
> +		return reg_to_user_from_u32(uaddr, &val, id);
>  	default:
>  		return -ENOENT;
>  	}
> @@ -938,8 +1004,8 @@ static int vfp_set_reg(struct kvm_vcpu *vcpu, u64 id, const void __user *uaddr)
>  	if (vfpid < num_fp_regs()) {
>  		if (KVM_REG_SIZE(id) != 8)
>  			return -ENOENT;
> -		return reg_from_user(&vcpu->arch.vfp_guest.fpregs[vfpid],
> -				     uaddr, id);
> +		return reg_from_user_to_u64(&vcpu->arch.vfp_guest.fpregs[vfpid],
> +					    uaddr, id);
>  	}
>  
>  	/* FP control registers are all 32 bit. */
> @@ -948,28 +1014,28 @@ static int vfp_set_reg(struct kvm_vcpu *vcpu, u64 id, const void __user *uaddr)
>  
>  	switch (vfpid) {
>  	case KVM_REG_ARM_VFP_FPEXC:
> -		return reg_from_user(&vcpu->arch.vfp_guest.fpexc, uaddr, id);
> +		return reg_from_user_to_u32(&vcpu->arch.vfp_guest.fpexc, uaddr, id);
>  	case KVM_REG_ARM_VFP_FPSCR:
> -		return reg_from_user(&vcpu->arch.vfp_guest.fpscr, uaddr, id);
> +		return reg_from_user_to_u32(&vcpu->arch.vfp_guest.fpscr, uaddr, id);
>  	case KVM_REG_ARM_VFP_FPINST:
> -		return reg_from_user(&vcpu->arch.vfp_guest.fpinst, uaddr, id);
> +		return reg_from_user_to_u32(&vcpu->arch.vfp_guest.fpinst, uaddr, id);
>  	case KVM_REG_ARM_VFP_FPINST2:
> -		return reg_from_user(&vcpu->arch.vfp_guest.fpinst2, uaddr, id);
> +		return reg_from_user_to_u32(&vcpu->arch.vfp_guest.fpinst2, uaddr, id);
>  	/* These are invariant. */
>  	case KVM_REG_ARM_VFP_MVFR0:
> -		if (reg_from_user(&val, uaddr, id))
> +		if (reg_from_user_to_u32(&val, uaddr, id))
>  			return -EFAULT;
>  		if (val != fmrx(MVFR0))
>  			return -EINVAL;
>  		return 0;
>  	case KVM_REG_ARM_VFP_MVFR1:
> -		if (reg_from_user(&val, uaddr, id))
> +		if (reg_from_user_to_u32(&val, uaddr, id))
>  			return -EFAULT;
>  		if (val != fmrx(MVFR1))
>  			return -EINVAL;
>  		return 0;
>  	case KVM_REG_ARM_VFP_FPSID:
> -		if (reg_from_user(&val, uaddr, id))
> +		if (reg_from_user_to_u32(&val, uaddr, id))
>  			return -EFAULT;
>  		if (val != fmrx(FPSID))
>  			return -EINVAL;
> @@ -1016,7 +1082,7 @@ int kvm_arm_coproc_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>  		return get_invariant_cp15(reg->id, uaddr);
>  
>  	/* Note: copies two regs if size is 64 bit. */
> -	return reg_to_user(uaddr, &vcpu->arch.cp15[r->reg], reg->id);
> +	return reg_to_user_from_u32(uaddr, &vcpu->arch.cp15[r->reg], reg->id);
>  }
>  
>  int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> @@ -1035,7 +1101,7 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>  		return set_invariant_cp15(reg->id, uaddr);
>  
>  	/* Note: copies two regs if size is 64 bit */
> -	return reg_from_user(&vcpu->arch.cp15[r->reg], uaddr, reg->id);
> +	return reg_from_user_to_u32(&vcpu->arch.cp15[r->reg], uaddr, reg->id);
>  }
>  
>  static unsigned int num_demux_regs(void)
> -- 
> 1.8.1.4
> 

It's definitely an improvement with the new naming, and I do appreciate
you taking the time to write comments.  (Apologies for suggesting a raw
rewrite, but there were a number of language issues with the proposed
versions and it felt overly burdensome on you to ask you to address all
of them).

However, I'm still not crazy about this overall approach (see separate
mail on the old thread).

I'm curious, how many special cases are there really, and how many
places would we have to introduce a conditional on the calling side?

Thanks,
-Christoffer

  reply	other threads:[~2014-05-25 19:14 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 16:13 [PATCH v3 00/14] ARM/ARM64: KVM: big endian host support Victor Kamensky
2014-05-13 16:13 ` [PATCH v3 01/14] ARM: KVM: switch hypervisor into BE mode in case of BE host Victor Kamensky
2014-05-27 14:23   ` Marc Zyngier
2014-05-13 16:13 ` [PATCH v3 02/14] ARM: KVM: fix vgic V7 assembler code to work in BE image Victor Kamensky
2014-05-27 14:24   ` Marc Zyngier
2014-05-13 16:13 ` [PATCH v3 03/14] ARM: KVM: handle 64bit values passed to mrcc or from mcrr instructions in BE case Victor Kamensky
2014-05-26 15:28   ` Christoffer Dall
2014-05-28  6:09     ` Victor Kamensky
2014-05-27 14:30   ` Marc Zyngier
2014-05-13 16:13 ` [PATCH v3 04/14] ARM: KVM: __kvm_vcpu_run function return result fix " Victor Kamensky
2014-05-27 15:02   ` Marc Zyngier
2014-05-28  6:10     ` Victor Kamensky
2014-05-13 16:13 ` [PATCH v3 05/14] ARM: KVM: vgic mmio should hold data as LE bytes array " Victor Kamensky
2014-05-27 15:07   ` Marc Zyngier
2014-05-13 16:13 ` [PATCH v3 06/14] ARM: KVM: MMIO support BE host running LE code Victor Kamensky
2014-05-27 15:49   ` Marc Zyngier
2014-05-13 16:13 ` [PATCH v3 07/14] ARM: KVM: one_reg coproc set and get BE fixes Victor Kamensky
2014-05-25 19:14   ` Christoffer Dall [this message]
2014-05-28  6:19     ` Victor Kamensky
2014-05-28  8:03       ` Christoffer Dall
2014-05-27 18:22   ` Marc Zyngier
2014-05-28  6:23     ` Victor Kamensky
2014-05-13 16:14 ` [PATCH v3 08/14] ARM: KVM: enable KVM in Kconfig on big-endian systems Victor Kamensky
2014-05-13 16:14 ` [PATCH v3 09/14] ARM64: KVM: MMIO support BE host running LE code Victor Kamensky
2014-05-27 18:25   ` Marc Zyngier
2014-05-13 16:14 ` [PATCH v3 10/14] ARM64: KVM: store kvm_vcpu_fault_info est_el2 as word Victor Kamensky
2014-05-27 18:34   ` Marc Zyngier
2014-05-13 16:14 ` [PATCH v3 11/14] ARM64: KVM: fix vgic_bitmap_get_reg function for BE 64bit case Victor Kamensky
2014-05-26 15:49   ` Christoffer Dall
2014-05-13 16:14 ` [PATCH v3 12/14] ARM64: KVM: vgic_elrsr and vgic_eisr need to be byteswapped in BE case Victor Kamensky
2014-05-26 17:35   ` Christoffer Dall
2014-05-27 19:11     ` Marc Zyngier
2014-05-13 16:14 ` [PATCH v3 13/14] ARM64: KVM: set and get of sys registers " Victor Kamensky
2014-05-14  8:45   ` Marc Zyngier
2014-05-14 14:18     ` Victor Kamensky
2014-05-25 18:26       ` Christoffer Dall
2014-05-13 16:14 ` [PATCH v3 14/14] ARM64: KVM: fix big endian issue in access_vm_reg for 32bit guest Victor Kamensky
2014-05-26 17:52   ` Christoffer Dall
2014-05-28  6:11     ` Victor Kamensky
2014-05-28  9:14       ` Christoffer Dall
2014-05-28 13:56         ` Victor Kamensky
2014-05-28 14:09           ` Christoffer Dall
2014-05-28 14:20             ` Marc Zyngier
2014-05-26 15:49 ` [PATCH v3 00/14] ARM/ARM64: KVM: big endian host support Christoffer Dall
2014-05-28  6:31   ` Victor Kamensky
2014-05-28  8:12     ` Christoffer Dall

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=20140525191426.GA23912@lvm \
    --to=christoffer.dall@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).