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 23:50:24 +0100 [thread overview] Message-ID: <20161006225024.GJ19354@jhogan-linux.le.imgtec.org> (raw) In-Reply-To: <alpine.LFD.2.20.1610062335410.1794@eddie.linux-mips.org> [-- Attachment #1: Type: text/plain, Size: 1994 bytes --] On Thu, Oct 06, 2016 at 11:41:40PM +0100, Maciej W. Rozycki wrote: > On Thu, 6 Oct 2016, James Hogan wrote: > > > > 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 :-(. > > Does it really matter in reality though? Good question. The whole thing is based on paranoia really. > > By keeping EBase unchanged we try to install exception handlers in memory > assigned by the firmware. This may not necessarily be safe. I think we > actually ought to set EBase ourselves, perhaps on a CPU by CPU basis in an > MP system, pointing to memory we know we can use at will. If this is > going to consume say a page of memory per CPU, then still I don't think > it's a huge waste, and any firmware memory safe to reclaim after boostrap > we can use for other purposes. > > Have I missed anything? I don't particularly object to always allocating our own vector when EBase is present. It'd probably break KVM, but that's KVM's fault for not emulating EBase properly yet. I suppose there is also an advantage to keeping the bootloader exception vector as alive as possible at least until Linux has set up its own one, as it allows early bugs to be caught by the bootloader, which can dump registers etc and even return to the bootloader prompt. 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 23:50:24 +0100 [thread overview] Message-ID: <20161006225024.GJ19354@jhogan-linux.le.imgtec.org> (raw) Message-ID: <20161006225024.-HeLzo2JwhiK6S4EiShORUDg3m3eGdz3FZ-FJUz5qZY@z> (raw) In-Reply-To: <alpine.LFD.2.20.1610062335410.1794@eddie.linux-mips.org> [-- Attachment #1: Type: text/plain, Size: 1994 bytes --] On Thu, Oct 06, 2016 at 11:41:40PM +0100, Maciej W. Rozycki wrote: > On Thu, 6 Oct 2016, James Hogan wrote: > > > > 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 :-(. > > Does it really matter in reality though? Good question. The whole thing is based on paranoia really. > > By keeping EBase unchanged we try to install exception handlers in memory > assigned by the firmware. This may not necessarily be safe. I think we > actually ought to set EBase ourselves, perhaps on a CPU by CPU basis in an > MP system, pointing to memory we know we can use at will. If this is > going to consume say a page of memory per CPU, then still I don't think > it's a huge waste, and any firmware memory safe to reclaim after boostrap > we can use for other purposes. > > Have I missed anything? I don't particularly object to always allocating our own vector when EBase is present. It'd probably break KVM, but that's KVM's fault for not emulating EBase properly yet. I suppose there is also an advantage to keeping the bootloader exception vector as alive as possible at least until Linux has set up its own one, as it allows early bugs to be caught by the bootloader, which can dump registers etc and even return to the bootloader prompt. Cheers James [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-10-06 22:50 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 2016-10-06 20:19 ` James Hogan 2016-10-06 22:41 ` Maciej W. Rozycki 2016-10-06 22:50 ` James Hogan [this message] 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=20161006225024.GJ19354@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: linkBe 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.