Messages in this thread | | | Date | Thu, 20 Dec 2012 08:56:11 -0800 | Subject | Re: [PATCH v7 06/27] x86, 64bit: early #PF handler set page table | From | Yinghai Lu <> |
| |
On Tue, Dec 18, 2012 at 1:07 PM, H. Peter Anvin <hpa@zytor.com> wrote: > On 12/18/2012 12:55 PM, Yinghai Lu wrote: >> On Tue, Dec 18, 2012 at 12:49 PM, H. Peter Anvin <hpa@zytor.com> wrote: >>> On 12/18/2012 12:43 PM, Yinghai Lu wrote: >> >>> >>> That is putting the cart before the horse. What is the specific requirement >>> with kgdb here (I didn't see any email on that, please don't have private >>> back conversations)? Either way, however, kgdb is a tool to debug the >>> kernel... having it a barrier for proper functionality of the kernel is not >>> acceptable. >> >> did not hear back from Jason or Jan. >> >> Looks like last mail in LKML from Jason is about Oct 20 >> >> looks like kgdb is want DB, BP, and PF are set at first. >> >> and just after that early_param for kgdbwait will get into to hold the kernel. >> >> then command from kgdb could dump ram etc. >> > > So in that case, kgdb is broken and will need to be fixed up. That > happens all the time with debugging tools. >
If there is a way that we can make all parties happy, we really should not break KGDB.
Please reconsider to stop #PF handler in x86_64_start_kernel. in that case 1. microcode update still can use #PF handler to find microcode in ramdisk and use it. 2. kernel that is loaded above 4G, could set mapping in C instead of set that in head_64.S and use ioremap to access zero_page 3. KGDB still can call early_trap_init early before init_mem_mapping.
I put the change in for-x86-boot-v8 branch. core patch is: http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=6fa4f1e68f0b67d0dc13d30c5ce6c3932697d08f
Thanks
Yinghai
| |