Re: [PATCH v7 06/27] x86, 64bit: early #PF handler set page table

2012-12-25 Thread Yinghai Lu
On Tue, Dec 25, 2012 at 3:20 AM, Borislav Petkov wrote: > On Mon, Dec 24, 2012 at 08:04:18PM -0800, Yinghai Lu wrote: >> well, I updated for-x86-boot-v7 that stop #PF handler after >> init_mem_mapping. >> >> it has fix for AMD system aka reverting far jmp to ret. > > -v7? > > You told me yesterday

Re: [PATCH v7 06/27] x86, 64bit: early #PF handler set page table

2012-12-25 Thread Borislav Petkov
On Mon, Dec 24, 2012 at 08:04:18PM -0800, Yinghai Lu wrote: > well, I updated for-x86-boot-v7 that stop #PF handler after > init_mem_mapping. > > it has fix for AMD system aka reverting far jmp to ret. -v7? You told me yesterday -v8 is the current branch. Do you have -v7 which does break KGDB and

Re: [PATCH v7 06/27] x86, 64bit: early #PF handler set page table

2012-12-24 Thread Yinghai Lu
On Mon, Dec 24, 2012 at 4:16 PM, H. Peter Anvin wrote: > On 12/20/2012 08:56 AM, Yinghai Lu wrote: >>> >>> >>> 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

Re: [PATCH v7 06/27] x86, 64bit: early #PF handler set page table

2012-12-24 Thread H. Peter Anvin
On 12/20/2012 08:56 AM, Yinghai Lu wrote: 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

Re: [PATCH v7 06/27] x86, 64bit: early #PF handler set page table

2012-12-20 Thread Yinghai Lu
On Tue, Dec 18, 2012 at 1:07 PM, H. Peter Anvin wrote: > On 12/18/2012 12:55 PM, Yinghai Lu wrote: >> On Tue, Dec 18, 2012 at 12:49 PM, H. Peter Anvin wrote: >>> On 12/18/2012 12:43 PM, Yinghai Lu wrote: >> >>> >>> That is putting the cart before the horse. What is the specific requirement >>> w

Re: [PATCH v7 06/27] x86, 64bit: early #PF handler set page table

2012-12-18 Thread H. Peter Anvin
On 12/18/2012 12:55 PM, Yinghai Lu wrote: > On Tue, Dec 18, 2012 at 12:49 PM, H. Peter Anvin 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 hav

Re: [PATCH v7 06/27] x86, 64bit: early #PF handler set page table

2012-12-18 Thread Yinghai Lu
On Tue, Dec 18, 2012 at 12:49 PM, H. Peter Anvin 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, howe

Re: [PATCH v7 06/27] x86, 64bit: early #PF handler set page table

2012-12-18 Thread H. Peter Anvin
On 12/18/2012 12:43 PM, Yinghai Lu wrote: On Mon, Dec 17, 2012 at 11:15 PM, Yinghai Lu wrote: -v8: we need to keep that handler alive until init_mem_mapping and don't let early_trap_init to trash that early #PF handler. So split early_trap_pf_init out and move it down. - Yinghai P

Re: [PATCH v7 06/27] x86, 64bit: early #PF handler set page table

2012-12-18 Thread Yinghai Lu
On Mon, Dec 17, 2012 at 11:15 PM, Yinghai Lu wrote: > -v8: we need to keep that handler alive until init_mem_mapping and don't > let early_trap_init to trash that early #PF handler. > So split early_trap_pf_init out and move it down. - Yinghai Peter, looks like moving down early_trap_i

[PATCH v7 06/27] x86, 64bit: early #PF handler set page table

2012-12-17 Thread Yinghai Lu
From: "H. Peter Anvin" two use cases: 1. We will support load and run kernel above 4G, and zero_page, ramdisk will be above 4G, too 2. need to access ramdisk early to get microcode to update that as early possible. We could use early_iomap to access them, but it will make code to messy and