All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Hogan <james.hogan@imgtec.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Matt Redfearn <matt.redfearn@imgtec.com>,
	Ralf Baechle <ralf@linux-mips.org>, <linux-mips@linux-mips.org>
Subject: Re: [PATCH 1/9] MIPS: traps: 64bit kernels should read CP0_EBase 64bit
Date: Thu, 6 Oct 2016 21:19:43 +0100	[thread overview]
Message-ID: <20161006201943.GI19354@jhogan-linux.le.imgtec.org> (raw)
In-Reply-To: <alpine.LFD.2.20.1610062054500.1794@eddie.linux-mips.org>

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

On Thu, Oct 06, 2016 at 08:56:50PM +0100, Maciej W. Rozycki wrote:
> On Thu, 6 Oct 2016, James Hogan wrote:
> 
> > >  ISTR a while ago we had a rather lengthy discussion as to how to detect 
> > > the presence of the upper 32 bits without triggering undefined behaviour 
> > > implied by 64-bit CP0 accesses to 32-bit CP0 registers.  As I believe we 
> > > set EBase ourselves I think we are able to make the necessary checks and 
> > > have an accurate condition here, still remembering however that it may go 
> > > back as far as MIPSr3.
> > 
> > We only set ebase under certain circumstances, otherwise leaving it as
> > already set.
> 
>  How can we install a handler then when we don't know what the upper 32 
> bits of EBase are?

Right now its assumed the default upper 32 bits are sign extension of
bit 31 in that case (i.e. thats what upper 32bits are clobbered to). I
think the only case where that might not be true would be where WG is
implemented and the bootloader has changed them to e.g. somewhere in
XKPhys, and then cleared WG. We could catch that most of the time by
detecting changed bits 31:30 (as I think you suggested before), but it
still isn't watertight (e.g. xkphys+0x80000000), so if in doubt we
should probably be sure to allocate our own exception vector instead of
guessing at the boot one. What a mess :-(.

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: James Hogan <james.hogan@imgtec.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Matt Redfearn <matt.redfearn@imgtec.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH 1/9] MIPS: traps: 64bit kernels should read CP0_EBase 64bit
Date: Thu, 6 Oct 2016 21:19:43 +0100	[thread overview]
Message-ID: <20161006201943.GI19354@jhogan-linux.le.imgtec.org> (raw)
Message-ID: <20161006201943.pbL2ub1oFuuPsHbZoXKaG7EVyULYCekWmObba0NNkVg@z> (raw)
In-Reply-To: <alpine.LFD.2.20.1610062054500.1794@eddie.linux-mips.org>

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

On Thu, Oct 06, 2016 at 08:56:50PM +0100, Maciej W. Rozycki wrote:
> On Thu, 6 Oct 2016, James Hogan wrote:
> 
> > >  ISTR a while ago we had a rather lengthy discussion as to how to detect 
> > > the presence of the upper 32 bits without triggering undefined behaviour 
> > > implied by 64-bit CP0 accesses to 32-bit CP0 registers.  As I believe we 
> > > set EBase ourselves I think we are able to make the necessary checks and 
> > > have an accurate condition here, still remembering however that it may go 
> > > back as far as MIPSr3.
> > 
> > We only set ebase under certain circumstances, otherwise leaving it as
> > already set.
> 
>  How can we install a handler then when we don't know what the upper 32 
> bits of EBase are?

Right now its assumed the default upper 32 bits are sign extension of
bit 31 in that case (i.e. thats what upper 32bits are clobbered to). I
think the only case where that might not be true would be where WG is
implemented and the bootloader has changed them to e.g. somewhere in
XKPhys, and then cleared WG. We could catch that most of the time by
detecting changed bits 31:30 (as I think you suggested before), but it
still isn't watertight (e.g. xkphys+0x80000000), so if in doubt we
should probably be sure to allocate our own exception vector instead of
guessing at the boot one. What a mess :-(.

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-10-06 20:19 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-01 16:30 [PATCH 0/9] MIPS: General EVA fixes & cleanups James Hogan
2016-09-01 16:30 ` [PATCH 1/9] MIPS: traps: 64bit kernels should read CP0_EBase 64bit James Hogan
2016-09-01 16:30   ` James Hogan
2016-09-21 13:08   ` Ralf Baechle
2016-09-21 15:01     ` Matt Redfearn
2016-09-21 15:01       ` Matt Redfearn
2016-10-02 10:30       ` Maciej W. Rozycki
2016-10-05 15:56         ` James Hogan
2016-10-05 15:56           ` James Hogan
2016-10-06 16:18           ` Maciej W. Rozycki
2016-10-06 18:05             ` James Hogan
2016-10-06 18:05               ` James Hogan
2016-10-06 19:56               ` Maciej W. Rozycki
2016-10-06 20:19                 ` James Hogan [this message]
2016-10-06 20:19                   ` James Hogan
2016-10-06 22:41                   ` Maciej W. Rozycki
2016-10-06 22:50                     ` James Hogan
2016-10-06 22:50                       ` James Hogan
2016-10-06 23:07                       ` Maciej W. Rozycki
2016-10-07 15:35             ` David Daney
2016-10-07 15:41               ` David Daney
2016-10-07 17:39                 ` Maciej W. Rozycki
2016-09-01 16:30 ` [PATCH 2/9] MIPS: traps: Convert ebase to KSeg0 James Hogan
2016-09-01 16:30   ` James Hogan
2016-09-01 16:30 ` [PATCH 3/9] MIPS: traps: Ensure full EBase is written James Hogan
2016-09-01 16:30   ` James Hogan
2016-09-21 13:19   ` Ralf Baechle
2016-09-01 16:30 ` [PATCH 4/9] MIPS: c-r4k: Drop bc_wback_inv() from icache flush James Hogan
2016-09-01 16:30   ` James Hogan
2016-09-01 16:30 ` [PATCH 5/9] MIPS: c-r4k: Split user/kernel flush_icache_range() James Hogan
2016-09-01 16:30   ` James Hogan
2016-09-01 16:30 ` [PATCH 6/9] MIPS: cacheflush: Use __flush_icache_user_range() James Hogan
2016-09-01 16:30   ` James Hogan
2016-09-01 16:30 ` [PATCH 7/9] MIPS: uprobes: Flush icache via kernel address James Hogan
2016-09-01 16:30   ` James Hogan
2016-09-21 13:26   ` Ralf Baechle
2016-09-21 18:15     ` Leonid Yegoshin
2016-09-21 18:15       ` Leonid Yegoshin
2016-09-22 21:15       ` James Hogan
2016-09-22 21:15         ` James Hogan
2016-09-22 21:38         ` Leonid Yegoshin
2016-09-22 21:38           ` Leonid Yegoshin
2016-09-22 21:42           ` Leonid Yegoshin
2016-09-22 21:42             ` Leonid Yegoshin
2016-09-22 22:13           ` James Hogan
2016-09-22 22:27             ` Leonid Yegoshin
2016-09-22 22:27               ` Leonid Yegoshin
2016-09-23  7:10               ` James Hogan
2016-09-01 16:30 ` [PATCH 8/9] MIPS: KVM: Use __local_flush_icache_user_range() James Hogan
2016-09-01 16:30 ` [PATCH 9/9] MIPS: c-r4k: Fix flush_icache_range() for EVA James Hogan
2016-09-01 16:30   ` James Hogan

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=20161006201943.GI19354@jhogan-linux.le.imgtec.org \
    --to=james.hogan@imgtec.com \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.org \
    --cc=matt.redfearn@imgtec.com \
    --cc=ralf@linux-mips.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.