From: Christoffer Dall <christoffer.dall@linaro.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] arm64: kvm: upgrade csselr and ccsidr to 64-bit values
Date: Tue, 24 Jan 2017 12:02:01 +0100 [thread overview]
Message-ID: <20170124110201.GN15850@cbox> (raw)
In-Reply-To: <de64fbcb-8e0d-b2b9-38b4-59f033a6cf6b@arm.com>
On Tue, Jan 24, 2017 at 10:55:24AM +0000, Sudeep Holla wrote:
>
>
> On 24/01/17 10:30, Christoffer Dall wrote:
> > On Tue, Jan 24, 2017 at 10:15:38AM +0000, Sudeep Holla wrote:
> >>
> >>
> >> On 23/01/17 21:08, Christoffer Dall wrote:
> >>> On Fri, Jan 20, 2017 at 10:50:10AM +0000, Sudeep Holla wrote:
> >>>> csselr and ccsidr are treated as 64-bit values already elsewhere in the
> >>>> kernel. It also aligns well with the architecture extensions that allow
> >>>> 64-bit format for ccsidr.
> >>>>
> >>>> This patch upgrades the existing accesses to csselr and ccsidr from
> >>>> 32-bit to 64-bit in preparation to add support to those extensions.
> >>>>
> >>>> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> >>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
> >>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> >>>> ---
> >>>> arch/arm64/kvm/sys_regs.c | 18 +++++++++---------
> >>>> 1 file changed, 9 insertions(+), 9 deletions(-)
> >>>>
> >>>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> >>>> index 5dca1f10340f..a3559a8a2b0c 100644
> >>>> --- a/arch/arm64/kvm/sys_regs.c
> >>>> +++ b/arch/arm64/kvm/sys_regs.c
> >>
> >> [..]
> >>
> >>>> @@ -2004,8 +2004,8 @@ static int demux_c15_get(u64 id, void __user *uaddr)
> >>>>
> >>>> static int demux_c15_set(u64 id, void __user *uaddr)
> >>>> {
> >>>> - u32 val, newval;
> >>>> - u32 __user *uval = uaddr;
> >>>> + u64 val, newval;
> >>>> + u64 __user *uval = uaddr;
> >>>
> >>> Doesn't converting these uval pointers to u64 cause us to break the ABI
> >>> as we'll now be reading/writing 64-bit values to userspace with the
> >>> get_user and put_user following the declarations?
> >>>
> >>
> >> Yes, I too have similar concern. IIUC it is always read via kvm_one_reg
> >> structure. I could not find any specific user for this register to cross
> >> check.
> >>
> >
> > Not sure it matters which interface we get the userspace pointer from?
> >
>
> Agreed.
>
> > This patch is definitely changing the write from a 32-bit write to a
> > 64-bit write and there's a specific check prior to the put_user() call
> > which checks that userspace intended a 32-bit value and presumably
> > provided a 32-bit pointer.
> >
>
> I see you point, I missed to see that check(just to be sure KVM_REG_SIZE
> check right ?).
yes.
>
> > So I think the only way to return 64-bit AArch32 system register values
> > to userspace (if that is the intention) is to define a new ID for 64-bit
> > CCSIDR registers and handle them separately.
> >
>
> I will add KVM_REG_ARM_DEMUX_ID_CCSIDR_64B or something similar.
> Thanks for the review.
>
Cool, thanks.
-Christoffer
WARNING: multiple messages have this Message-ID (diff)
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] arm64: kvm: upgrade csselr and ccsidr to 64-bit values
Date: Tue, 24 Jan 2017 12:02:01 +0100 [thread overview]
Message-ID: <20170124110201.GN15850@cbox> (raw)
In-Reply-To: <de64fbcb-8e0d-b2b9-38b4-59f033a6cf6b@arm.com>
On Tue, Jan 24, 2017 at 10:55:24AM +0000, Sudeep Holla wrote:
>
>
> On 24/01/17 10:30, Christoffer Dall wrote:
> > On Tue, Jan 24, 2017 at 10:15:38AM +0000, Sudeep Holla wrote:
> >>
> >>
> >> On 23/01/17 21:08, Christoffer Dall wrote:
> >>> On Fri, Jan 20, 2017 at 10:50:10AM +0000, Sudeep Holla wrote:
> >>>> csselr and ccsidr are treated as 64-bit values already elsewhere in the
> >>>> kernel. It also aligns well with the architecture extensions that allow
> >>>> 64-bit format for ccsidr.
> >>>>
> >>>> This patch upgrades the existing accesses to csselr and ccsidr from
> >>>> 32-bit to 64-bit in preparation to add support to those extensions.
> >>>>
> >>>> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> >>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
> >>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> >>>> ---
> >>>> arch/arm64/kvm/sys_regs.c | 18 +++++++++---------
> >>>> 1 file changed, 9 insertions(+), 9 deletions(-)
> >>>>
> >>>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> >>>> index 5dca1f10340f..a3559a8a2b0c 100644
> >>>> --- a/arch/arm64/kvm/sys_regs.c
> >>>> +++ b/arch/arm64/kvm/sys_regs.c
> >>
> >> [..]
> >>
> >>>> @@ -2004,8 +2004,8 @@ static int demux_c15_get(u64 id, void __user *uaddr)
> >>>>
> >>>> static int demux_c15_set(u64 id, void __user *uaddr)
> >>>> {
> >>>> - u32 val, newval;
> >>>> - u32 __user *uval = uaddr;
> >>>> + u64 val, newval;
> >>>> + u64 __user *uval = uaddr;
> >>>
> >>> Doesn't converting these uval pointers to u64 cause us to break the ABI
> >>> as we'll now be reading/writing 64-bit values to userspace with the
> >>> get_user and put_user following the declarations?
> >>>
> >>
> >> Yes, I too have similar concern. IIUC it is always read via kvm_one_reg
> >> structure. I could not find any specific user for this register to cross
> >> check.
> >>
> >
> > Not sure it matters which interface we get the userspace pointer from?
> >
>
> Agreed.
>
> > This patch is definitely changing the write from a 32-bit write to a
> > 64-bit write and there's a specific check prior to the put_user() call
> > which checks that userspace intended a 32-bit value and presumably
> > provided a 32-bit pointer.
> >
>
> I see you point, I missed to see that check(just to be sure KVM_REG_SIZE
> check right ?).
yes.
>
> > So I think the only way to return 64-bit AArch32 system register values
> > to userspace (if that is the intention) is to define a new ID for 64-bit
> > CCSIDR registers and handle them separately.
> >
>
> I will add KVM_REG_ARM_DEMUX_ID_CCSIDR_64B or something similar.
> Thanks for the review.
>
Cool, thanks.
-Christoffer
next prev parent reply other threads:[~2017-01-24 11:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-20 10:50 [PATCH 1/2] arm64: kvm: reuse existing cache type/info related macros Sudeep Holla
2017-01-20 10:50 ` Sudeep Holla
2017-01-20 10:50 ` [PATCH 2/2] arm64: kvm: upgrade csselr and ccsidr to 64-bit values Sudeep Holla
2017-01-20 10:50 ` Sudeep Holla
2017-01-23 21:08 ` Christoffer Dall
2017-01-23 21:08 ` Christoffer Dall
2017-01-24 10:15 ` Sudeep Holla
2017-01-24 10:15 ` Sudeep Holla
2017-01-24 10:30 ` Christoffer Dall
2017-01-24 10:30 ` Christoffer Dall
2017-01-24 10:55 ` Sudeep Holla
2017-01-24 10:55 ` Sudeep Holla
2017-01-24 11:02 ` Christoffer Dall [this message]
2017-01-24 11:02 ` Christoffer Dall
2017-01-23 18:17 ` [PATCH 1/2] arm64: kvm: reuse existing cache type/info related macros Will Deacon
2017-01-23 18:17 ` Will Deacon
2017-01-23 21:05 ` Christoffer Dall
2017-01-23 21:05 ` Christoffer Dall
2017-01-24 10:04 ` Sudeep Holla
2017-01-24 10:04 ` Sudeep Holla
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=20170124110201.GN15850@cbox \
--to=christoffer.dall@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=sudeep.holla@arm.com \
--cc=will.deacon@arm.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.