From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 5/7] ARM: KVM: one_reg coproc set and get BE fixes
Date: Wed, 19 Mar 2014 20:01:23 -0700 [thread overview]
Message-ID: <20140320030123.GN1297@cbox> (raw)
In-Reply-To: <CAA3XUr2GT3M=-q2wnBBGmj+bYpoo1akKoiGdDqhPoYFsPmiebQ@mail.gmail.com>
On Wed, Mar 19, 2014 at 06:48:07PM -0700, Victor Kamensky wrote:
> Hi Christoffer,
>
> Appreciate your time and review comments.
> Please see response inline.
>
> On 19 March 2014 18:11, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> > On Tue, Feb 11, 2014 at 09:41:31PM -0800, 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_user64 - reads register from user-land to kernel 'u64 *val'
> >> address; register size could be 4 or 8 bytes
> >> reg_from_user32 - reads register(s) from user-land to kernel 'u32 *val'
> >> address; note it could be one or two 4 bytes registers
> >> reg_to_user64 - writes reigster from kernel 'u64 *val' address to
> >
> > s/reigster/register/
> >
> >> user-land register memory; register size could be
> >> 4 or 8 bytes
> >> ret_to_user32 - writes register(s) from kernel 'u32 *val' address to
> >> user-land register(s) memory; note it could be
> >> one or two 4 bytes registers
> >
> > If we are really going to keep this scheme, then please add these
> > comments to functions themselves.
> >
> >>
> >> All places where reg_from_user, reg_to_user functions were used, were changed
> >> to use either corresponding 64 or 32 bit variant of functions depending on
> >> type of source/target kernel memory variable.
> >>
> >> In case of 'u64 *val' and register size equals 4 bytes, reg_from_user64
> >> and reg_to_user64 work only with least siginificant word of target/source
> >> kernel value.
> >>
> >> Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
> >> ---
> >> arch/arm/kvm/coproc.c | 94 +++++++++++++++++++++++++++++++++++++--------------
> >> 1 file changed, 69 insertions(+), 25 deletions(-)
> >>
> >> diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
> >> index 78c0885..64b2b94 100644
> >> --- a/arch/arm/kvm/coproc.c
> >> +++ b/arch/arm/kvm/coproc.c
> >> @@ -634,17 +634,61 @@ 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)
> >> +static int reg_from_user64(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;
> >> +}
> >
> > instead of allowing this 'packing 32 bit values in 64 bit values and
> > packing two 32 bit values in 64 bit values' kernel implementation'y
> > stuff to be passed to these user-space ABI catering function, I really
> > think you want to make reg_from_user64 deal with 64-bit registers, that
> > is, BUG_ON(KVM_REG_SIZE(id) != 8.
> >
> > If the kernel stores what user space sees as a 32-bit register in a
> > 64-bit register, then let the caller deal with this mess.
> >
> > If the kernel stores what user space sees as a 64-bit register in two
> > 32-bit registers, then let the caller deal with that mess.
> >
> > Imagine someone who hasn't been through the development of this code
> > seeing these two functions for the first time without having read your
> > commit message, I think the margin for error here is too large.
> >
> > If you can share these functions like Alex suggests, then that would
> > make for a much cleaner function API as well.
>
> During LCA14 I had discussion with Alex about changing and sharing
> one_reg endianness functions with ppc code and with V8 side as well ...
> Alex outlined how it should be done and showed me ppc side of this
> code. He asked me to check with you before I start moving into this
> direction. I could not catch you during remaining LCA14 days. But
> now it looks you are on the same page ...
yeah, sorry, lots of stuff happening at Linaro Connect always. I am all
for sharing this code.
>
> Let me try to rework code along Alex's suggestion and see how
> it will look like. I will take in account your above suggestions and will
> try to clean 64/32 bit overload. Since it will have bigger scope and
> shared with ppc side I wonder maybe I should pull this patch out of
> this series and handle it as later additions.
>
I think you should have that as a preparatory patch series on which this
series depends.
Thanks,
-Christoffer
next prev parent reply other threads:[~2014-03-20 3:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-12 5:41 [PATCH v2 0/7] armv7 BE kvm support Victor Kamensky
2014-02-12 5:41 ` [PATCH v2 1/7] ARM: KVM: switch hypervisor into BE mode in case of BE host Victor Kamensky
2014-03-18 22:23 ` Christoffer Dall
2014-03-19 0:52 ` Victor Kamensky
2014-03-19 3:03 ` Christoffer Dall
2014-02-12 5:41 ` [PATCH v2 2/7] ARM: KVM: fix vgic V7 assembler code to work in BE image Victor Kamensky
2014-03-20 1:10 ` Christoffer Dall
2014-02-12 5:41 ` [PATCH v2 3/7] ARM: KVM: handle 64bit values passed to mrcc or from mcrr instructions in BE case Victor Kamensky
2014-03-20 1:11 ` Christoffer Dall
2014-02-12 5:41 ` [PATCH v2 4/7] ARM: KVM: __kvm_vcpu_run function return result fix " Victor Kamensky
2014-03-20 1:11 ` Christoffer Dall
2014-02-12 5:41 ` [PATCH v2 5/7] ARM: KVM: one_reg coproc set and get BE fixes Victor Kamensky
2014-02-12 7:07 ` Alexander Graf
2014-03-20 1:11 ` Christoffer Dall
2014-03-20 1:48 ` Victor Kamensky
2014-03-20 3:01 ` Christoffer Dall [this message]
2014-05-13 20:11 ` Victor Kamensky
2014-05-25 19:09 ` Christoffer Dall
2014-02-12 5:41 ` [PATCH v2 6/7] ARM: KVM: vgic mmio should hold data as LE bytes array in BE case Victor Kamensky
2014-03-20 1:12 ` Christoffer Dall
2014-02-12 5:41 ` [PATCH v2 7/7] ARM: KVM: MMIO support BE host running LE code Victor Kamensky
2014-03-20 1: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=20140320030123.GN1297@cbox \
--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 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.