From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM64: TTY: hvc_dcc: Add support for ARM64 dcc
Date: Tue, 30 Jun 2015 14:51:54 +0100 [thread overview]
Message-ID: <20150630135153.GJ27725@arm.com> (raw)
In-Reply-To: <558B0EEC.9040504@codeaurora.org>
On Wed, Jun 24, 2015 at 09:11:24PM +0100, Timur Tabi wrote:
> On 06/22/2015 08:12 AM, Will Deacon wrote:
> > I still think we should be disabling userspace access to the DCC if the
> > kernel is using it as its console.
>
> I still need help with this. I know you said a year ago that
> MDSCR_EL1.TDCC needs to be set to disable userspace access. Where and
> how should I do this? I can do this:
Well, it's up to you to figure out the details, but I'd start by adding
some static inlines to the arch-specific header files for enabling/disabling
userspace access.
>From there, I think I'd get the architecture init code to reset the thing
to "disabled" (so it's disabled regardless of whether we build the hvc_dcc
driver) and then if you wanted to go all-out, we could have a sysfs entry
provided by the driver to toggle it on and off.
> static int __init hvc_dcc_console_init(void)
> {
> #ifdef CONFIG_ARM64
> u32 val;
>
> asm("msr mdscr_el1, %0 "
> "orr %0, %0, #4096 " /* TDCC */
> "msr %0, mdscr_el1 "
> : "=r" (val));
> #endif
>
> But this seems clunky.
Yeah, that's super ugly.
> I am concerned about KVM, though. There appears to be code in KVM in
> hyp.s and sys_regs.c that touches and/or emulates MDSCR_EL1.
>
> On a side note, it does not appear that ARM32 blocks userspace DCC. I
> don't see where DBGDSCR.UDCCdis is set.
That's a bug imo.
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Timur Tabi <timur@codeaurora.org>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
"abhimany@codeaurora.org" <abhimany@codeaurora.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"sboyd@codeaurora.org" <sboyd@codeaurora.org>
Subject: Re: [PATCH] ARM64: TTY: hvc_dcc: Add support for ARM64 dcc
Date: Tue, 30 Jun 2015 14:51:54 +0100 [thread overview]
Message-ID: <20150630135153.GJ27725@arm.com> (raw)
In-Reply-To: <558B0EEC.9040504@codeaurora.org>
On Wed, Jun 24, 2015 at 09:11:24PM +0100, Timur Tabi wrote:
> On 06/22/2015 08:12 AM, Will Deacon wrote:
> > I still think we should be disabling userspace access to the DCC if the
> > kernel is using it as its console.
>
> I still need help with this. I know you said a year ago that
> MDSCR_EL1.TDCC needs to be set to disable userspace access. Where and
> how should I do this? I can do this:
Well, it's up to you to figure out the details, but I'd start by adding
some static inlines to the arch-specific header files for enabling/disabling
userspace access.
>From there, I think I'd get the architecture init code to reset the thing
to "disabled" (so it's disabled regardless of whether we build the hvc_dcc
driver) and then if you wanted to go all-out, we could have a sysfs entry
provided by the driver to toggle it on and off.
> static int __init hvc_dcc_console_init(void)
> {
> #ifdef CONFIG_ARM64
> u32 val;
>
> asm("msr mdscr_el1, %0 "
> "orr %0, %0, #4096 " /* TDCC */
> "msr %0, mdscr_el1 "
> : "=r" (val));
> #endif
>
> But this seems clunky.
Yeah, that's super ugly.
> I am concerned about KVM, though. There appears to be code in KVM in
> hyp.s and sys_regs.c that touches and/or emulates MDSCR_EL1.
>
> On a side note, it does not appear that ARM32 blocks userspace DCC. I
> don't see where DBGDSCR.UDCCdis is set.
That's a bug imo.
Will
next prev parent reply other threads:[~2015-06-30 13:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 22:08 [PATCH] ARM64: TTY: hvc_dcc: Add support for ARM64 dcc Timur Tabi
2015-06-19 22:08 ` Timur Tabi
2015-06-22 13:12 ` Will Deacon
2015-06-22 13:12 ` Will Deacon
2015-06-22 13:16 ` Timur Tabi
2015-06-22 13:16 ` Timur Tabi
2015-06-24 20:11 ` Timur Tabi
2015-06-24 20:11 ` Timur Tabi
2015-06-30 13:51 ` Will Deacon [this message]
2015-06-30 13:51 ` Will Deacon
2015-06-30 13:58 ` Timur Tabi
2015-06-30 13:58 ` Timur Tabi
-- strict thread matches above, loose matches on Subject: below --
2014-06-16 22:29 Abhimanyu Kapur
2014-06-16 22:29 ` Abhimanyu Kapur
2014-06-17 9:51 ` Will Deacon
2014-06-17 9:51 ` Will Deacon
2015-06-05 18:35 ` Timur Tabi
2015-06-05 18:35 ` Timur Tabi
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=20150630135153.GJ27725@arm.com \
--to=will.deacon@arm.com \
--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.