* [Patch 0/2] Kexec/Kdump support POWER6 @ 2007-05-22 12:22 Sachin P. Sant 2007-05-22 12:24 ` [Patch 1/2] " Sachin P. Sant 0 siblings, 1 reply; 18+ messages in thread From: Sachin P. Sant @ 2007-05-22 12:22 UTC (permalink / raw) To: linuxppc-dev; +Cc: Milton Miller II, ellerman Here are a set of patches which adds kdump support for Power6. The first patch reads VRMA page size from device tree. Second patch adds Kexec/Kdump support for Power6 processor. On Power machines supporting VRMA, Kexec/Kdump does not work. Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables. This patch makes sure these hpte entries are left untouched. Comments are welcome. Thanks -Sachin Signed-off-by : Sachin Sant <sachinp@in.ibm.com> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com> --- ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Patch 1/2] Kexec/Kdump support POWER6 2007-05-22 12:22 [Patch 0/2] Kexec/Kdump support POWER6 Sachin P. Sant @ 2007-05-22 12:24 ` Sachin P. Sant 2007-05-22 12:26 ` [Patch 2/2] " Sachin P. Sant 0 siblings, 1 reply; 18+ messages in thread From: Sachin P. Sant @ 2007-05-22 12:24 UTC (permalink / raw) To: linuxppc-dev; +Cc: Milton Miller II, ellerman [-- Attachment #1: Type: text/plain, Size: 66 bytes --] Read supported VRMA page size from device tree. Thanks -Sachin [-- Attachment #2: detect-vrma-page-size --] [-- Type: text/plain, Size: 2009 bytes --] * Read supported VRMA page size from device tree. Signed-Off-By : Sachin Sant <sachinp@in.ibm.com> Signed-Off-By : Mohan Kumar M <mohan@in.ibm.com> --- diff -Naurp linux-2.6.22-rc2/arch/powerpc/kernel/setup_64.c linux-2.6.22-rc2-vrma/arch/powerpc/kernel/setup_64.c --- linux-2.6.22-rc2/arch/powerpc/kernel/setup_64.c 2007-05-19 09:36:17.000000000 +0530 +++ linux-2.6.22-rc2-vrma/arch/powerpc/kernel/setup_64.c 2007-05-21 15:15:30.000000000 +0530 @@ -73,6 +73,10 @@ int have_of = 1; int boot_cpuid = 0; u64 ppc64_pft_size; +/* For VRMA */ +u64 ppc64_vrma_page_size; +int have_vrma = 0; + /* Pick defaults since we might want to patch instructions * before we've read this from the device tree. */ diff -Naurp linux-2.6.22-rc2/arch/powerpc/mm/hash_utils_64.c linux-2.6.22-rc2-vrma/arch/powerpc/mm/hash_utils_64.c --- linux-2.6.22-rc2/arch/powerpc/mm/hash_utils_64.c 2007-05-19 09:36:17.000000000 +0530 +++ linux-2.6.22-rc2-vrma/arch/powerpc/mm/hash_utils_64.c 2007-05-21 15:18:10.000000000 +0530 @@ -199,6 +199,13 @@ static int __init htab_dt_scan_page_size if (type == NULL || strcmp(type, "cpu") != 0) return 0; + prop = (u32 *)of_get_flat_dt_prop(node, "ibm,vrma-page-sizes", &size); + if (prop != NULL) { + DBG("VRMA Page size from device-tree:\n"); + ppc64_vrma_page_size = prop[0]; + have_vrma = 1; + } + prop = (u32 *)of_get_flat_dt_prop(node, "ibm,segment-page-sizes", &size); if (prop != NULL) { diff -Naurp linux-2.6.22-rc2/include/asm-powerpc/page_64.h linux-2.6.22-rc2-vrma/include/asm-powerpc/page_64.h --- linux-2.6.22-rc2/include/asm-powerpc/page_64.h 2007-05-19 09:36:17.000000000 +0530 +++ linux-2.6.22-rc2-vrma/include/asm-powerpc/page_64.h 2007-05-21 15:15:30.000000000 +0530 @@ -76,6 +76,10 @@ static inline void copy_page(void *to, v /* Log 2 of page table size */ extern u64 ppc64_pft_size; +/* For VRMA */ +extern u64 ppc64_vrma_page_size; +extern int have_vrma; + /* Large pages size */ #ifdef CONFIG_HUGETLB_PAGE extern unsigned int HPAGE_SHIFT; ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Patch 2/2] Kexec/Kdump support POWER6 2007-05-22 12:24 ` [Patch 1/2] " Sachin P. Sant @ 2007-05-22 12:26 ` Sachin P. Sant 2007-05-22 15:34 ` Olof Johansson 0 siblings, 1 reply; 18+ messages in thread From: Sachin P. Sant @ 2007-05-22 12:26 UTC (permalink / raw) To: linuxppc-dev; +Cc: Milton Miller II, ellerman [-- Attachment #1: Type: text/plain, Size: 201 bytes --] On Power machines supporting VRMA, Kexec/Kdump does not work. Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables. Make sure these hpte entries are left untouched. Thanks -Sachin [-- Attachment #2: kexec-kdump-support-for-POWRE6 --] [-- Type: text/plain, Size: 4218 bytes --] * On Power machines supporting VRMA, Kexec/Kdump does not work. * Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables. * Make sure these hpte entries are left untouched. Signed-off-by : Sachin Sant <sachinp@in.ibm.com> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com> --- diff -Naurp linux-2.6.22-rc2-vrma/arch/powerpc/kernel/machine_kexec_64.c linux-2.6.22-rc2-p6/arch/powerpc/kernel/machine_kexec_64.c --- linux-2.6.22-rc2-vrma/arch/powerpc/kernel/machine_kexec_64.c 2007-05-21 15:14:58.000000000 +0530 +++ linux-2.6.22-rc2-p6/arch/powerpc/kernel/machine_kexec_64.c 2007-05-21 15:19:14.000000000 +0530 @@ -279,6 +279,9 @@ void default_machine_kexec(struct kimage kexec_stack.thread_info.task = current_thread_info()->task; kexec_stack.thread_info.flags = 0; + if (have_vrma) + pSeries_find_hpte_vrma(); + /* Some things are best done in assembly. Finding globals with * a toc is easier in C, so pass in what we can. */ diff -Naurp linux-2.6.22-rc2-vrma/arch/powerpc/platforms/pseries/lpar.c linux-2.6.22-rc2-p6/arch/powerpc/platforms/pseries/lpar.c --- linux-2.6.22-rc2-vrma/arch/powerpc/platforms/pseries/lpar.c 2007-05-21 15:14:57.000000000 +0530 +++ linux-2.6.22-rc2-p6/arch/powerpc/platforms/pseries/lpar.c 2007-05-22 15:53:11.000000000 +0530 @@ -369,6 +369,56 @@ static long pSeries_lpar_hpte_remove(uns return -1; } +unsigned long hpte_vrma_slots[HPTE_V_RMA_NUM]; +unsigned int num_hpte_vrma_slots = 0; + +void pSeries_find_hpte_vrma(void) +{ + unsigned int step; + unsigned long hash, slot, vaddr; + unsigned long dword0, dummy1, rma_size; + long lpar_rc; + int i; + + /* Get the RMA size */ + rma_size = lmb.rmo_size; + + /* Get the VRMA page size */ + step = 1 << ppc64_vrma_page_size; + + vaddr = HPTE_V_RMA_VPN + rma_size; + + /* Find hpte's with VRMA mappings */ + for (; vaddr >= HPTE_V_RMA_VPN; vaddr -= step) { + hash = hpt_hash(vaddr, mmu_psize_defs[MMU_PAGE_16M].shift); + slot = ((hash & htab_hash_mask) * HPTES_PER_GROUP); + + for (i = 0; i < HPTES_PER_GROUP; i++) { + lpar_rc = plpar_pte_read(0, slot, + &dword0, &dummy1); + if (!lpar_rc && dword0 && + ((dword0 & HPTE_V_MASK) == MAGIC_SKIP_HPTE)) { + /* store the hpte */ + hpte_vrma_slots[num_hpte_vrma_slots++] = slot; + break; + } + slot++; + } + } +} + +static inline int check_vrma_slot(int slot) +{ + int j; + + for (j = 0; j < num_hpte_vrma_slots; j++) + if (hpte_vrma_slots[j] == slot) + return 1; + + return 0; + +} + static void pSeries_lpar_hptab_clear(void) { unsigned long size_bytes = 1UL << ppc64_pft_size; @@ -377,8 +427,12 @@ static void pSeries_lpar_hptab_clear(voi int i; /* TODO: Use bulk call */ - for (i = 0; i < hpte_count; i++) + for (i = 0; i < hpte_count; i++) { + if (have_vrma && check_vrma_slot(i)) + /* You don't want to remove this hpte */ + continue; plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); + } } /* diff -Naurp linux-2.6.22-rc2-vrma/include/asm-powerpc/kexec.h linux-2.6.22-rc2-p6/include/asm-powerpc/kexec.h --- linux-2.6.22-rc2-vrma/include/asm-powerpc/kexec.h 2007-05-21 15:14:55.000000000 +0530 +++ linux-2.6.22-rc2-p6/include/asm-powerpc/kexec.h 2007-05-21 15:19:14.000000000 +0530 @@ -24,6 +24,8 @@ #define KEXEC_CONTROL_CODE_SIZE 4096 +extern void pSeries_find_hpte_vrma(void); + /* The native architecture */ #ifdef __powerpc64__ #define KEXEC_ARCH KEXEC_ARCH_PPC64 diff -Naurp linux-2.6.22-rc2-vrma/include/asm-powerpc/mmu-hash64.h linux-2.6.22-rc2-p6/include/asm-powerpc/mmu-hash64.h --- linux-2.6.22-rc2-vrma/include/asm-powerpc/mmu-hash64.h 2007-05-21 15:14:55.000000000 +0530 +++ linux-2.6.22-rc2-p6/include/asm-powerpc/mmu-hash64.h 2007-05-21 15:23:31.000000000 +0530 @@ -94,6 +94,11 @@ extern char initial_stab[]; #define HPTE_R_C ASM_CONST(0x0000000000000080) #define HPTE_R_R ASM_CONST(0x0000000000000100) +#define HPTE_V_RMA_VPN ASM_CONST(0x001FFFFFF0000000) +#define HPTE_V_MASK ASM_CONST(0xc000000000000000) +#define MAGIC_SKIP_HPTE ASM_CONST(0x4000000000000000) +#define HPTE_V_RMA_NUM 16 + /* Values for PP (assumes Ks=0, Kp=1) */ /* pp0 will always be 0 for linux */ #define PP_RWXX 0 /* Supervisor read/write, User none */ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] Kexec/Kdump support POWER6 2007-05-22 12:26 ` [Patch 2/2] " Sachin P. Sant @ 2007-05-22 15:34 ` Olof Johansson 2007-05-23 5:13 ` Sachin P. Sant ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Olof Johansson @ 2007-05-22 15:34 UTC (permalink / raw) To: Sachin P. Sant; +Cc: linuxppc-dev, ellerman, Milton Miller II Hi, On Tue, May 22, 2007 at 05:56:36PM +0530, Sachin P. Sant wrote: > On Power machines supporting VRMA, Kexec/Kdump does not work. > Hypervisor stores VRMA mapping used by the OS, in the hpte hash > tables. Make sure these hpte entries are left untouched. > diff -Naurp linux-2.6.22-rc2-vrma/arch/powerpc/kernel/machine_kexec_64.c linux-2.6.22-rc2-p6/arch/powerpc/kernel/machine_kexec_64.c > --- linux-2.6.22-rc2-vrma/arch/powerpc/kernel/machine_kexec_64.c 2007-05-21 15:14:58.000000000 +0530 > +++ linux-2.6.22-rc2-p6/arch/powerpc/kernel/machine_kexec_64.c 2007-05-21 15:19:14.000000000 +0530 > @@ -279,6 +279,9 @@ void default_machine_kexec(struct kimage > kexec_stack.thread_info.task = current_thread_info()->task; > kexec_stack.thread_info.flags = 0; > > + if (have_vrma) > + pSeries_find_hpte_vrma(); > + This will break kexec builds on non-pseries. It's referring to platform code that might not be built. > /* Some things are best done in assembly. Finding globals with > * a toc is easier in C, so pass in what we can. > */ > diff -Naurp linux-2.6.22-rc2-vrma/arch/powerpc/platforms/pseries/lpar.c linux-2.6.22-rc2-p6/arch/powerpc/platforms/pseries/lpar.c > --- linux-2.6.22-rc2-vrma/arch/powerpc/platforms/pseries/lpar.c 2007-05-21 15:14:57.000000000 +0530 > +++ linux-2.6.22-rc2-p6/arch/powerpc/platforms/pseries/lpar.c 2007-05-22 15:53:11.000000000 +0530 > @@ -369,6 +369,56 @@ static long pSeries_lpar_hpte_remove(uns > return -1; > } > > +unsigned long hpte_vrma_slots[HPTE_V_RMA_NUM]; > +unsigned int num_hpte_vrma_slots = 0; > + > +void pSeries_find_hpte_vrma(void) Does this function find the vrma, or save it away? Seems like the name is misleading. > +{ > + unsigned int step; > + unsigned long hash, slot, vaddr; > + unsigned long dword0, dummy1, rma_size; > + long lpar_rc; > + int i; > + > + /* Get the RMA size */ > + rma_size = lmb.rmo_size; > + > + /* Get the VRMA page size */ > + step = 1 << ppc64_vrma_page_size; Is ppc64_vrma_page_size really the size, or the shift? Above would indicate that it's really a shift value. > + > + vaddr = HPTE_V_RMA_VPN + rma_size; > + > + /* Find hpte's with VRMA mappings */ > + for (; vaddr >= HPTE_V_RMA_VPN; vaddr -= step) { > + hash = hpt_hash(vaddr, mmu_psize_defs[MMU_PAGE_16M].shift); Why is 16M hardcoded here, when you're taking such great care to read out the pagesize earlier? > + slot = ((hash & htab_hash_mask) * HPTES_PER_GROUP); > + > + for (i = 0; i < HPTES_PER_GROUP; i++) { > + lpar_rc = plpar_pte_read(0, slot, > + &dword0, &dummy1); > + if (!lpar_rc && dword0 && > + ((dword0 & HPTE_V_MASK) == MAGIC_SKIP_HPTE)) { Indentation > + /* store the hpte */ > + hpte_vrma_slots[num_hpte_vrma_slots++] = slot; Here you rely on global exported state (num_hpte_vrma_slots), increasing it without checking for limits. What happens if this function is ever called twice? Should you set it to 0 in the beginning of the function and check it against the size of the hpte_vrma_slots array instead? > + break; > + } > + slot++; > + } > + } > +} > + > +static inline int check_vrma_slot(int slot) > +{ > + int j; > + > + for (j = 0; j < num_hpte_vrma_slots; j++) > + if (hpte_vrma_slots[j] == slot) > + return 1; > + > + return 0; > + > +} > + > static void pSeries_lpar_hptab_clear(void) > { > unsigned long size_bytes = 1UL << ppc64_pft_size; > @@ -377,8 +427,12 @@ static void pSeries_lpar_hptab_clear(voi > int i; > > /* TODO: Use bulk call */ > - for (i = 0; i < hpte_count; i++) > + for (i = 0; i < hpte_count; i++) { > + if (have_vrma && check_vrma_slot(i)) > + /* You don't want to remove this hpte */ > + continue; > plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); > + } > } > > /* > diff -Naurp linux-2.6.22-rc2-vrma/include/asm-powerpc/kexec.h linux-2.6.22-rc2-p6/include/asm-powerpc/kexec.h > --- linux-2.6.22-rc2-vrma/include/asm-powerpc/kexec.h 2007-05-21 15:14:55.000000000 +0530 > +++ linux-2.6.22-rc2-p6/include/asm-powerpc/kexec.h 2007-05-21 15:19:14.000000000 +0530 > @@ -24,6 +24,8 @@ > > #define KEXEC_CONTROL_CODE_SIZE 4096 > > +extern void pSeries_find_hpte_vrma(void); > + Same comment as above: This isn't a kexec function as much as a pseries function, so it should be defined in some other header instead. > /* The native architecture */ > #ifdef __powerpc64__ > #define KEXEC_ARCH KEXEC_ARCH_PPC64 > diff -Naurp linux-2.6.22-rc2-vrma/include/asm-powerpc/mmu-hash64.h linux-2.6.22-rc2-p6/include/asm-powerpc/mmu-hash64.h > --- linux-2.6.22-rc2-vrma/include/asm-powerpc/mmu-hash64.h 2007-05-21 15:14:55.000000000 +0530 > +++ linux-2.6.22-rc2-p6/include/asm-powerpc/mmu-hash64.h 2007-05-21 15:23:31.000000000 +0530 > @@ -94,6 +94,11 @@ extern char initial_stab[]; > #define HPTE_R_C ASM_CONST(0x0000000000000080) > #define HPTE_R_R ASM_CONST(0x0000000000000100) > > +#define HPTE_V_RMA_VPN ASM_CONST(0x001FFFFFF0000000) > +#define HPTE_V_MASK ASM_CONST(0xc000000000000000) > +#define MAGIC_SKIP_HPTE ASM_CONST(0x4000000000000000) > +#define HPTE_V_RMA_NUM 16 "MAGIC_SKIP_HPTE"? I'm sure there's a proper name for this field in the PAPR, isn't there? Also, HPTE_V_RMA_NUM isn't a HPTE_V field, it shouldn't have that prefix. It's not a property of the mmu in the first place. These should maybe be local defines in the pseries lpar code instead, since it's more of a lpar<->phyp interface than mmu programming interface. -Olof ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] Kexec/Kdump support POWER6 2007-05-22 15:34 ` Olof Johansson @ 2007-05-23 5:13 ` Sachin P. Sant 2007-05-23 5:14 ` Sachin P. Sant 2007-05-23 9:37 ` [Patch 2/2] Kexec/Kdump support - POWER6 Sachin P. Sant 2 siblings, 0 replies; 18+ messages in thread From: Sachin P. Sant @ 2007-05-23 5:13 UTC (permalink / raw) To: Olof Johansson; +Cc: linuxppc-dev, ellerman, Milton Miller II Hi Olaf, thanks for the review. >> + if (have_vrma) >> + pSeries_find_hpte_vrma(); >> + >> > > This will break kexec builds on non-pseries. It's referring to platform > code that might not be built. > > Ok. Will call this function from lpar.c instead of default_machine_kexec(). > Does this function find the vrma, or save it away? Seems like the name > is misleading. > > Well it finds a vrma entry and saves it. I thought of pSeries_find_save_hpte_vrma(), but decided against it. I could change it to pSeries_save_hpte_vrma(). > Is ppc64_vrma_page_size really the size, or the shift? Above would > indicate that it's really a shift value. > > It is a shift. I will change it to ppc64_vrma_page_shift. > Why is 16M hardcoded here, when you're taking such great care to read > out the pagesize earlier? > > Hrmm. Ok will use the vrma_page_shift value. >> + ((dword0 & HPTE_V_MASK) == MAGIC_SKIP_HPTE)) { >> > Indentation > Done. >> + /* store the hpte */ >> + hpte_vrma_slots[num_hpte_vrma_slots++] = slot; >> > > Here you rely on global exported state (num_hpte_vrma_slots), increasing it without > checking for limits. What happens if this function is ever called twice? Should you > set it to 0 in the beginning of the function and check it against the size of the > hpte_vrma_slots array instead? > Will add proper checks for num_hpte_vrma_slots variable value. >> +extern void pSeries_find_hpte_vrma(void); >> >> > Same comment as above: This isn't a kexec function as much as a pseries function, so > it should be defined in some other header instead. > >> >> +#define HPTE_V_RMA_VPN ASM_CONST(0x001FFFFFF0000000) >> +#define HPTE_V_MASK ASM_CONST(0xc000000000000000) >> +#define MAGIC_SKIP_HPTE ASM_CONST(0x4000000000000000) >> +#define HPTE_V_RMA_NUM 16 >> > > "MAGIC_SKIP_HPTE"? I'm sure there's a proper name for this field in the > PAPR, isn't there? Also, HPTE_V_RMA_NUM isn't a HPTE_V field, it shouldn't > have that prefix. It's not a property of the mmu in the first place. > > These should maybe be local defines in the pseries lpar code instead, since it's > more of a lpar<->phyp interface than mmu programming interface. > Will move them to pseries lpar code. Updated patch on its way. Thanks -Sachin ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] Kexec/Kdump support POWER6 2007-05-22 15:34 ` Olof Johansson 2007-05-23 5:13 ` Sachin P. Sant @ 2007-05-23 5:14 ` Sachin P. Sant 2007-05-23 9:37 ` [Patch 2/2] Kexec/Kdump support - POWER6 Sachin P. Sant 2 siblings, 0 replies; 18+ messages in thread From: Sachin P. Sant @ 2007-05-23 5:14 UTC (permalink / raw) To: Olof Johansson; +Cc: linuxppc-dev, ellerman, Milton Miller II Hi Olof, thanks for the review. >> + if (have_vrma) >> + pSeries_find_hpte_vrma(); >> + >> > > This will break kexec builds on non-pseries. It's referring to platform > code that might not be built. > > Ok. Will call this function from lpar.c instead of default_machine_kexec(). > Does this function find the vrma, or save it away? Seems like the name > is misleading. > > Well it finds a vrma entry and saves it. I thought of pSeries_find_save_hpte_vrma(), but decided against it. I could change it to pSeries_save_hpte_vrma(). > Is ppc64_vrma_page_size really the size, or the shift? Above would > indicate that it's really a shift value. > > It is a shift. I will change it to ppc64_vrma_page_shift. > Why is 16M hardcoded here, when you're taking such great care to read > out the pagesize earlier? > > Hrmm. Ok will use the vrma_page_shift value. >> + ((dword0 & HPTE_V_MASK) == MAGIC_SKIP_HPTE)) { >> > Indentation > Done. >> + /* store the hpte */ >> + hpte_vrma_slots[num_hpte_vrma_slots++] = slot; >> > > Here you rely on global exported state (num_hpte_vrma_slots), increasing it without > checking for limits. What happens if this function is ever called twice? Should you > set it to 0 in the beginning of the function and check it against the size of the > hpte_vrma_slots array instead? > Will add proper checks for num_hpte_vrma_slots variable value. >> +extern void pSeries_find_hpte_vrma(void); >> >> > Same comment as above: This isn't a kexec function as much as a pseries function, so > it should be defined in some other header instead. > >> >> +#define HPTE_V_RMA_VPN ASM_CONST(0x001FFFFFF0000000) >> +#define HPTE_V_MASK ASM_CONST(0xc000000000000000) >> +#define MAGIC_SKIP_HPTE ASM_CONST(0x4000000000000000) >> +#define HPTE_V_RMA_NUM 16 >> > > "MAGIC_SKIP_HPTE"? I'm sure there's a proper name for this field in the > PAPR, isn't there? Also, HPTE_V_RMA_NUM isn't a HPTE_V field, it shouldn't > have that prefix. It's not a property of the mmu in the first place. > > These should maybe be local defines in the pseries lpar code instead, since it's > more of a lpar<->phyp interface than mmu programming interface. > Will move them to pseries lpar code. Updated patch on its way. Thanks -Sachin ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Patch 2/2] Kexec/Kdump support - POWER6 2007-05-22 15:34 ` Olof Johansson 2007-05-23 5:13 ` Sachin P. Sant 2007-05-23 5:14 ` Sachin P. Sant @ 2007-05-23 9:37 ` Sachin P. Sant 2007-05-23 10:55 ` Paul Mackerras 2 siblings, 1 reply; 18+ messages in thread From: Sachin P. Sant @ 2007-05-23 9:37 UTC (permalink / raw) To: Olof Johansson, Paul Mackerras; +Cc: linuxppc-dev, ellerman, Milton Miller II [-- Attachment #1: Type: text/plain, Size: 287 bytes --] On Power machines supporting VRMA, Kexec/Kdump does not work. Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables. Make sure these hpte entries are left untouched. This patch also adds plpar_pte_read_raw() on the lines of plpar_pte_remove_raw(). Thanks -Sachin [-- Attachment #2: kexec-kdump-support-on-POWER6 --] [-- Type: text/plain, Size: 3525 bytes --] * On Power machines supporting VRMA, Kexec/Kdump does not work. * Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables. * Make sure these hpte entries are left untouched. Signed-off-by : Sachin Sant <sachinp@in.ibm.com> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com> --- diff -Naurp linux-2.6.22-rc2-vrma/arch/powerpc/platforms/pseries/lpar.c linux-2.6.22-rc2-kexec/arch/powerpc/platforms/pseries/lpar.c --- linux-2.6.22-rc2-vrma/arch/powerpc/platforms/pseries/lpar.c 2007-05-19 09:36:17.000000000 +0530 +++ linux-2.6.22-rc2-kexec/arch/powerpc/platforms/pseries/lpar.c 2007-05-23 13:47:54.000000000 +0530 @@ -369,6 +369,62 @@ static long pSeries_lpar_hpte_remove(uns return -1; } +#define VRMA_VPN ASM_CONST(0x001FFFFFF0000000) +#define VRMA_MASK ASM_CONST(0xc000000000000000) +#define VRMA_HPTE_B_1TB ASM_CONST(0x4000000000000000) +#define VRMA_NUM 16 + +unsigned long hpte_vrma_slots[VRMA_NUM]; +unsigned int num_hpte_vrma_slots = 0; + +static void pSeries_save_hpte_vrma(void) +{ + unsigned int step; + unsigned long hash, slot, vaddr; + unsigned long dword0, dummy1, rma_size; + long lpar_rc; + int i; + + /* Get the RMA size */ + rma_size = lmb.rmo_size; + + /* Get the VRMA page size */ + step = 1 << ppc64_vrma_page_shift; + + vaddr = VRMA_VPN + rma_size; + + /* Find hpte's with VRMA mappings */ + for (; vaddr >= VRMA_VPN; vaddr -= step) { + hash = hpt_hash(vaddr, ppc64_vrma_page_shift); + slot = ((hash & htab_hash_mask) * HPTES_PER_GROUP); + + for (i = 0; i < HPTES_PER_GROUP; i++) { + lpar_rc = plpar_pte_read_raw(0, slot, + &dword0, &dummy1); + if (!lpar_rc && dword0 && + ((dword0 & VRMA_MASK) == VRMA_HPTE_B_1TB) && + (num_hpte_vrma_slots < VRMA_NUM)) { + /* store the hpte */ + hpte_vrma_slots[num_hpte_vrma_slots++] = slot; + break; + } + slot++; + } + } +} + +static inline int check_vrma_slot(int slot) +{ + int j; + + for (j = 0; j < num_hpte_vrma_slots; j++) + if (hpte_vrma_slots[j] == slot) + return 1; + + return 0; + +} + static void pSeries_lpar_hptab_clear(void) { unsigned long size_bytes = 1UL << ppc64_pft_size; @@ -376,9 +432,16 @@ static void pSeries_lpar_hptab_clear(voi unsigned long dummy1, dummy2; int i; + if (have_vrma) + pSeries_save_hpte_vrma(); + /* TODO: Use bulk call */ - for (i = 0; i < hpte_count; i++) + for (i = 0; i < hpte_count; i++) { + if (have_vrma && check_vrma_slot(i)) + /* You don't want to remove this hpte */ + continue; plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); + } } /* diff -Naurp linux-2.6.22-rc2-vrma/arch/powerpc/platforms/pseries/plpar_wrappers.h linux-2.6.22-rc2-kexec/arch/powerpc/platforms/pseries/plpar_wrappers.h --- linux-2.6.22-rc2-vrma/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-19 09:36:17.000000000 +0530 +++ linux-2.6.22-rc2-kexec/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-23 11:38:12.000000000 +0530 @@ -108,6 +108,21 @@ static inline long plpar_pte_read(unsign return rc; } +/* plpar_pte_read_raw can be called in real mode. It calls plpar_hcall_raw */ +static inline long plpar_pte_read_raw(unsigned long flags, unsigned long ptex, + unsigned long *old_pteh_ret, unsigned long *old_ptel_ret) +{ + long rc; + unsigned long retbuf[PLPAR_HCALL_BUFSIZE]; + + rc = plpar_hcall_raw(H_READ, retbuf, flags, ptex); + + *old_pteh_ret = retbuf[0]; + *old_ptel_ret = retbuf[1]; + + return rc; +} + static inline long plpar_pte_protect(unsigned long flags, unsigned long ptex, unsigned long avpn) { ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] Kexec/Kdump support - POWER6 2007-05-23 9:37 ` [Patch 2/2] Kexec/Kdump support - POWER6 Sachin P. Sant @ 2007-05-23 10:55 ` Paul Mackerras 2007-05-24 12:17 ` Mohan Kumar M 0 siblings, 1 reply; 18+ messages in thread From: Paul Mackerras @ 2007-05-23 10:55 UTC (permalink / raw) To: sachinp; +Cc: Olof Johansson, linuxppc-dev, ellerman, Milton Miller II Sachin P. Sant writes: > On Power machines supporting VRMA, Kexec/Kdump does not work. > Hypervisor stores VRMA mapping used by the OS, in the hpte hash > tables. Make sure these hpte entries are left untouched. Surely all we need to do is to avoid clearing the VRMA entries. We can do this by not clearing any HPTE where the top 40 bits of the first dword are 0x4001ffffff (B=1 for a 1TB segment and the 0x0001ffffff special VSID). In fact we can avoid having to read each entry by doing the H_REMOVEs with H_ANDCOND and the bolted bit when we clear the hash table, and only reading the HPTEs for which the H_REMOVE returns an error. Paul. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] Kexec/Kdump support - POWER6 2007-05-23 10:55 ` Paul Mackerras @ 2007-05-24 12:17 ` Mohan Kumar M 2007-05-24 14:21 ` Olof Johansson 0 siblings, 1 reply; 18+ messages in thread From: Mohan Kumar M @ 2007-05-24 12:17 UTC (permalink / raw) To: Paul Mackerras Cc: Milton Miller II, kexec, linuxppc-dev, Olof Johansson, ellerman On Wed, May 23, 2007 at 08:55:00PM +1000, Paul Mackerras wrote: > Sachin P. Sant writes: > > > On Power machines supporting VRMA, Kexec/Kdump does not work. > > Hypervisor stores VRMA mapping used by the OS, in the hpte hash > > tables. Make sure these hpte entries are left untouched. > > Surely all we need to do is to avoid clearing the VRMA entries. We > can do this by not clearing any HPTE where the top 40 bits of the > first dword are 0x4001ffffff (B=1 for a 1TB segment and the > 0x0001ffffff special VSID). In fact we can avoid having to read each > entry by doing the H_REMOVEs with H_ANDCOND and the bolted bit when we > clear the hash table, and only reading the HPTEs for which the > H_REMOVE returns an error. > Paul, Thanks for your suggestion. But we can not use 0x4001fffff for H_ANDCOND flag since AND'ing 0x4001ffff value with most of the HPTEs results in non-zero and most of the HPTE entries are not removed. >From POWER ISA 2.04 document page 425, "Programming Note: Software should specify PTE(B) = 0b01 for all Page Table Entries that map the VRMA in order to be consistent with the values in Figure 14." So I tried 0x4000000000000000 as AVPN parameter and using that it removes all hpte entries other than VRMA(ie non 1TB segment size PTE entries). Tested on POWER6/POWER5 machines. ======================== Starting from POWER5+, hypervisor stores VRMA entries in the HPTE tables and these entries are need by OS and they should not be cleared. These VRMA entries will be of segment size 1TB. Using H_ANDCOND flag for H_REMOVE hypervisor call it is made sure that we will not remove any PTE whose size is 1TB(ie VRMA entries) Signed-off-by: Sachin Sant <sachinp@in.ibm.com> Signed-off-by: Mohan Kumar M <mohan@in.ibm.com> --- arch/powerpc/platforms/pseries/lpar.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) Index: linux-2.6.21.1/arch/powerpc/platforms/pseries/lpar.c =================================================================== --- linux-2.6.21.1.orig/arch/powerpc/platforms/pseries/lpar.c +++ linux-2.6.21.1/arch/powerpc/platforms/pseries/lpar.c @@ -369,6 +369,8 @@ static long pSeries_lpar_hpte_remove(uns return -1; } +#define VRMA_HPTE_B_1TB ASM_CONST(0x4000000000000000) + static void pSeries_lpar_hptab_clear(void) { unsigned long size_bytes = 1UL << ppc64_pft_size; @@ -378,7 +380,9 @@ static void pSeries_lpar_hptab_clear(voi /* TODO: Use bulk call */ for (i = 0; i < hpte_count; i++) - plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); + /* dont remove HPTEs of segments size 1TB (VRMA entries) */ + plpar_pte_remove_raw(H_ANDCOND, i, VRMA_HPTE_B_1TB, + &dummy1, &dummy2); } /* ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch 2/2] Kexec/Kdump support - POWER6 2007-05-24 12:17 ` Mohan Kumar M @ 2007-05-24 14:21 ` Olof Johansson 2007-05-25 8:55 ` [Patch ] " Sachin P. Sant 0 siblings, 1 reply; 18+ messages in thread From: Olof Johansson @ 2007-05-24 14:21 UTC (permalink / raw) To: Mohan Kumar M Cc: Milton Miller II, kexec, linuxppc-dev, Paul Mackerras, ellerman On Thu, May 24, 2007 at 05:47:51PM +0530, Mohan Kumar M wrote: > On Wed, May 23, 2007 at 08:55:00PM +1000, Paul Mackerras wrote: > > Sachin P. Sant writes: > > > > > On Power machines supporting VRMA, Kexec/Kdump does not work. > > > Hypervisor stores VRMA mapping used by the OS, in the hpte hash > > > tables. Make sure these hpte entries are left untouched. > > > > Surely all we need to do is to avoid clearing the VRMA entries. We > > can do this by not clearing any HPTE where the top 40 bits of the > > first dword are 0x4001ffffff (B=1 for a 1TB segment and the > > 0x0001ffffff special VSID). In fact we can avoid having to read each > > entry by doing the H_REMOVEs with H_ANDCOND and the bolted bit when we > > clear the hash table, and only reading the HPTEs for which the > > H_REMOVE returns an error. > > So I tried 0x4000000000000000 as AVPN parameter and using that it > removes all hpte entries other than VRMA(ie non 1TB segment size PTE > entries). > > Tested on POWER6/POWER5 machines. Hi, As Paul says above, you need to check for failures and compare the VSID and possibly unhash it anyway in case of non-match. Otherwise if the kernel ever starts using 1TB segments for regular use, those pages will never be unhashed. I don't see your code doing that now. -Olof ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Patch ] Kexec/Kdump support - POWER6 2007-05-24 14:21 ` Olof Johansson @ 2007-05-25 8:55 ` Sachin P. Sant 2007-05-25 22:43 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 18+ messages in thread From: Sachin P. Sant @ 2007-05-25 8:55 UTC (permalink / raw) To: Olof Johansson, Paul Mackerras; +Cc: linuxppc-dev, kexec, Milton Miller II [-- Attachment #1: Type: text/plain, Size: 460 bytes --] Olof Johansson wrote: > As Paul says above, you need to check for failures and compare the VSID > and possibly unhash it anyway in case of non-match. Otherwise if the > kernel ever starts using 1TB segments for regular use, those pages will > never be unhashed. I don't see your code doing that now. > > How about the following patch ? Thanks -Sachin Signed-off-by : Sachin Sant <sachinp@in.ibm.com> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com> --- [-- Attachment #2: kexec-kdump-support-on-POWER6 --] [-- Type: text/plain, Size: 2524 bytes --] * On Power machines supporting VRMA, Kexec/Kdump does not work. * Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables. * Make sure these hpte entries are left untouched. * * This patch also adds plpar_pte_read_raw() on the lines of * plpar_pte_remove_raw(). Signed-off-by : Sachin Sant <sachinp@in.ibm.com> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com> --- diff -Naurp a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c --- a/arch/powerpc/platforms/pseries/lpar.c 2007-05-19 09:36:17.000000000 +0530 +++ b/arch/powerpc/platforms/pseries/lpar.c 2007-05-25 14:09:59.000000000 +0530 @@ -369,16 +369,30 @@ static long pSeries_lpar_hpte_remove(uns return -1; } +#define VRMA_HPTE_B_1TB ASM_CONST(0x4000000000000000) +#define VRMA_MASK ASM_CONST(0x4001ffffff) + static void pSeries_lpar_hptab_clear(void) { unsigned long size_bytes = 1UL << ppc64_pft_size; unsigned long hpte_count = size_bytes >> 4; - unsigned long dummy1, dummy2; + unsigned long dummy1, dummy2, dword0; + long lpar_rc; int i; /* TODO: Use bulk call */ - for (i = 0; i < hpte_count; i++) - plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); + for (i = 0; i < hpte_count; i++) { + /* dont remove HPTEs with VRMA mappings */ + lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, VRMA_HPTE_B_1TB, + &dummy1, &dummy2); + if (lpar_rc == H_NOT_FOUND) { + lpar_rc = plpar_pte_read_raw(0, i, &dword0, &dummy1); + if (!lpar_rc && + (((dword0 >> 24) & VRMA_MASK) != VRMA_MASK)) + /* Can be hpte for 1TB Seg. So remove it */ + plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); + } + } } /* diff -Naurp a/arch/powerpc/platforms/pseries/plpar_wrappers.h b/arch/powerpc/platforms/pseries/plpar_wrappers.h --- a/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-19 09:36:17.000000000 +0530 +++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-25 12:20:38.000000000 +0530 @@ -108,6 +108,21 @@ static inline long plpar_pte_read(unsign return rc; } +/* plpar_pte_read_raw can be called in real mode. It calls plpar_hcall_raw */ +static inline long plpar_pte_read_raw(unsigned long flags, unsigned long ptex, + unsigned long *old_pteh_ret, unsigned long *old_ptel_ret) +{ + long rc; + unsigned long retbuf[PLPAR_HCALL_BUFSIZE]; + + rc = plpar_hcall_raw(H_READ, retbuf, flags, ptex); + + *old_pteh_ret = retbuf[0]; + *old_ptel_ret = retbuf[1]; + + return rc; +} + static inline long plpar_pte_protect(unsigned long flags, unsigned long ptex, unsigned long avpn) { ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch ] Kexec/Kdump support - POWER6 2007-05-25 8:55 ` [Patch ] " Sachin P. Sant @ 2007-05-25 22:43 ` Benjamin Herrenschmidt 2007-05-28 11:40 ` Sachin P. Sant 0 siblings, 1 reply; 18+ messages in thread From: Benjamin Herrenschmidt @ 2007-05-25 22:43 UTC (permalink / raw) To: sachinp Cc: Olof Johansson, linuxppc-dev, Paul Mackerras, kexec, Milton Miller II > > /* TODO: Use bulk call */ > - for (i = 0; i < hpte_count; i++) > - plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); > + for (i = 0; i < hpte_count; i++) { > + /* dont remove HPTEs with VRMA mappings */ > + lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, VRMA_HPTE_B_1TB, > + &dummy1, &dummy2); If you're going to use the B (1T segment) bit instead of the bolted bit, at least define a proper constant in line with the existing naming of the hash table constants in mmu-hash64.h. I would suggest doing the same with the VRMA_MASK/VALUE thing and calling it HPTE_V_VRMA_MASK or something similar. > + if (lpar_rc == H_NOT_FOUND) { > + lpar_rc = plpar_pte_read_raw(0, i, &dword0, &dummy1); > + if (!lpar_rc && > + (((dword0 >> 24) & VRMA_MASK) != VRMA_MASK)) > + /* Can be hpte for 1TB Seg. So remove it */ > + plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); > + } > + } > } In addition, I would recommend following Michael's advice and using using the bulk remove Hcall whenever possible. Cheers, Ben. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Patch ] Kexec/Kdump support - POWER6 2007-05-25 22:43 ` Benjamin Herrenschmidt @ 2007-05-28 11:40 ` Sachin P. Sant 2007-05-28 21:31 ` Benjamin Herrenschmidt 2007-05-29 10:14 ` Michael Ellerman 0 siblings, 2 replies; 18+ messages in thread From: Sachin P. Sant @ 2007-05-28 11:40 UTC (permalink / raw) To: Paul Mackerras; +Cc: Milton Miller II, kexec, linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 807 bytes --] Benjamin Herrenschmidt wrote: > If you're going to use the B (1T segment) bit instead of the bolted bit, > at least define a proper constant in line with the existing naming of > the hash table constants in mmu-hash64.h. I would suggest doing the same > with the VRMA_MASK/VALUE thing and calling it HPTE_V_VRMA_MASK or > something similar. > Well i had used them properly in my previous patches. Don't know why i changed it in this patch :-( Here is the updated patch. >> + } >> } >> > In addition, I would recommend following Michael's advice and using > using the bulk remove Hcall whenever possible. > Yes will send out a separate patch to use bulk remove Hcall. Thanks -Sachin Signed-off-by : Sachin Sant <sachinp@in.ibm.com> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com> --- [-- Attachment #2: kexec-kdump-support-on-POWER6 --] [-- Type: text/plain, Size: 2541 bytes --] * On Power machines supporting VRMA, Kexec/Kdump does not work. * Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables. * Make sure these hpte entries are left untouched. * * This patch also adds plpar_pte_read_raw() on the lines of * plpar_pte_remove_raw(). Signed-off-by : Sachin Sant <sachinp@in.ibm.com> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com> --- diff -Naurp a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c --- a/arch/powerpc/platforms/pseries/lpar.c 2007-05-19 09:36:17.000000000 +0530 +++ b/arch/powerpc/platforms/pseries/lpar.c 2007-05-28 16:49:46.000000000 +0530 @@ -369,16 +369,30 @@ static long pSeries_lpar_hpte_remove(uns return -1; } +#define HPTE_V_1TB_SEG ASM_CONST(0x4000000000000000) +#define HPTE_V_VRMA_MASK ASM_CONST(0x4001ffffff) + static void pSeries_lpar_hptab_clear(void) { unsigned long size_bytes = 1UL << ppc64_pft_size; unsigned long hpte_count = size_bytes >> 4; - unsigned long dummy1, dummy2; + unsigned long dummy1, dummy2, dword0; + long lpar_rc; int i; /* TODO: Use bulk call */ - for (i = 0; i < hpte_count; i++) - plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); + for (i = 0; i < hpte_count; i++) { + /* dont remove HPTEs with VRMA mappings */ + lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, HPTE_V_1TB_SEG, + &dummy1, &dummy2); + if (lpar_rc == H_NOT_FOUND) { + lpar_rc = plpar_pte_read_raw(0, i, &dword0, &dummy1); + if (!lpar_rc && (((dword0 >> 24) & HPTE_V_VRMA_MASK) + != HPTE_V_VRMA_MASK)) + /* Can be hpte for 1TB Seg. So remove it */ + plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); + } + } } /* diff -Naurp a/arch/powerpc/platforms/pseries/plpar_wrappers.h b/arch/powerpc/platforms/pseries/plpar_wrappers.h --- a/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-19 09:36:17.000000000 +0530 +++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-25 12:20:38.000000000 +0530 @@ -108,6 +108,21 @@ static inline long plpar_pte_read(unsign return rc; } +/* plpar_pte_read_raw can be called in real mode. It calls plpar_hcall_raw */ +static inline long plpar_pte_read_raw(unsigned long flags, unsigned long ptex, + unsigned long *old_pteh_ret, unsigned long *old_ptel_ret) +{ + long rc; + unsigned long retbuf[PLPAR_HCALL_BUFSIZE]; + + rc = plpar_hcall_raw(H_READ, retbuf, flags, ptex); + + *old_pteh_ret = retbuf[0]; + *old_ptel_ret = retbuf[1]; + + return rc; +} + static inline long plpar_pte_protect(unsigned long flags, unsigned long ptex, unsigned long avpn) { ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch ] Kexec/Kdump support - POWER6 2007-05-28 11:40 ` Sachin P. Sant @ 2007-05-28 21:31 ` Benjamin Herrenschmidt 2007-05-29 6:18 ` Sachin P. Sant 2007-05-29 10:14 ` Michael Ellerman 1 sibling, 1 reply; 18+ messages in thread From: Benjamin Herrenschmidt @ 2007-05-28 21:31 UTC (permalink / raw) To: sachinp; +Cc: linuxppc-dev, Paul Mackerras, kexec, Milton Miller II On Mon, 2007-05-28 at 17:10 +0530, Sachin P. Sant wrote: > > +#define HPTE_V_1TB_SEG ASM_CONST(0x4000000000000000) > +#define HPTE_V_VRMA_MASK ASM_CONST(0x4001ffffff) Move those to mmu-hash64.h along with the other ones. Also, keep the mask aligned to the top bits > static void pSeries_lpar_hptab_clear(void) > { > unsigned long size_bytes = 1UL << ppc64_pft_size; > unsigned long hpte_count = size_bytes >> 4; > - unsigned long dummy1, dummy2; > + unsigned long dummy1, dummy2, dword0; > + long lpar_rc; > int i; > > /* TODO: Use bulk call */ > - for (i = 0; i < hpte_count; i++) > - plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); > + for (i = 0; i < hpte_count; i++) { > + /* dont remove HPTEs with VRMA mappings */ > + lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, HPTE_V_1TB_SEG, > + &dummy1, &dummy2); > + if (lpar_rc == H_NOT_FOUND) { > + lpar_rc = plpar_pte_read_raw(0, i, &dword0, &dummy1); > + if (!lpar_rc && (((dword0 >> 24) & HPTE_V_VRMA_MASK) > + != HPTE_V_VRMA_MASK)) No need to shift >> 24, just have the mask left justified in the first place. No need to have a "magic" shift value in there. > + /* Can be hpte for 1TB Seg. So remove it */ > + plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); > + } > + } > } Appart from that, looks good. Does it actually work ? :-) Cheers, Ben. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch ] Kexec/Kdump support - POWER6 2007-05-28 21:31 ` Benjamin Herrenschmidt @ 2007-05-29 6:18 ` Sachin P. Sant 2007-05-29 6:58 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 18+ messages in thread From: Sachin P. Sant @ 2007-05-29 6:18 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, kexec [-- Attachment #1: Type: text/plain, Size: 779 bytes --] Benjamin Herrenschmidt wrote: > Move those to mmu-hash64.h along with the other ones. Also, keep the > mask aligned to the top bits > In previous patches i had these #defines in mmu-hash64.h. But got review comments to move them to lpar.c :-) Oh well i will move them back to mmu-hash64.h. >> + if (!lpar_rc && (((dword0 >> 24) & HPTE_V_VRMA_MASK) >> > No need to shift >> 24, just have the mask left justified in the first > place. No need to have a "magic" shift value in there. > Ok. > Appart from that, looks good. Does it actually work ? :-) > Yes it does work. It must be my lucky day when i coded the patch :-) Thanks -Sachin Signed-off-by : Sachin Sant <sachinp@in.ibm.com> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com> --- [-- Attachment #2: kexec-kdump-support-on-POWER6 --] [-- Type: text/plain, Size: 3012 bytes --] * On Power machines supporting VRMA, Kexec/Kdump does not work. * Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables. * Make sure these hpte entries are left untouched. * * This patch also adds plpar_pte_read_raw() on the lines of * plpar_pte_remove_raw(). Signed-off-by : Sachin Sant <sachinp@in.ibm.com> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com> --- diff -Naurp a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c --- a/arch/powerpc/platforms/pseries/lpar.c 2007-05-19 09:36:17.000000000 +0530 +++ b/arch/powerpc/platforms/pseries/lpar.c 2007-05-29 10:45:34.000000000 +0530 @@ -373,12 +373,23 @@ static void pSeries_lpar_hptab_clear(voi { unsigned long size_bytes = 1UL << ppc64_pft_size; unsigned long hpte_count = size_bytes >> 4; - unsigned long dummy1, dummy2; + unsigned long dummy1, dummy2, dword0; + long lpar_rc; int i; /* TODO: Use bulk call */ - for (i = 0; i < hpte_count; i++) - plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); + for (i = 0; i < hpte_count; i++) { + /* dont remove HPTEs with VRMA mappings */ + lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, HPTE_V_1TB_SEG, + &dummy1, &dummy2); + if (lpar_rc == H_NOT_FOUND) { + lpar_rc = plpar_pte_read_raw(0, i, &dword0, &dummy1); + if (!lpar_rc && ((dword0 & HPTE_V_VRMA_MASK) + != HPTE_V_VRMA_MASK)) + /* Can be hpte for 1TB Seg. So remove it */ + plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); + } + } } /* diff -Naurp a/arch/powerpc/platforms/pseries/plpar_wrappers.h b/arch/powerpc/platforms/pseries/plpar_wrappers.h --- a/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-19 09:36:17.000000000 +0530 +++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-25 12:20:38.000000000 +0530 @@ -108,6 +108,21 @@ static inline long plpar_pte_read(unsign return rc; } +/* plpar_pte_read_raw can be called in real mode. It calls plpar_hcall_raw */ +static inline long plpar_pte_read_raw(unsigned long flags, unsigned long ptex, + unsigned long *old_pteh_ret, unsigned long *old_ptel_ret) +{ + long rc; + unsigned long retbuf[PLPAR_HCALL_BUFSIZE]; + + rc = plpar_hcall_raw(H_READ, retbuf, flags, ptex); + + *old_pteh_ret = retbuf[0]; + *old_ptel_ret = retbuf[1]; + + return rc; +} + static inline long plpar_pte_protect(unsigned long flags, unsigned long ptex, unsigned long avpn) { diff -Naurp a/include/asm-powerpc/mmu-hash64.h b/include/asm-powerpc/mmu-hash64.h --- a/include/asm-powerpc/mmu-hash64.h 2007-05-19 09:36:17.000000000 +0530 +++ b/include/asm-powerpc/mmu-hash64.h 2007-05-29 10:46:22.000000000 +0530 @@ -94,6 +94,9 @@ extern char initial_stab[]; #define HPTE_R_C ASM_CONST(0x0000000000000080) #define HPTE_R_R ASM_CONST(0x0000000000000100) +#define HPTE_V_1TB_SEG ASM_CONST(0x4000000000000000) +#define HPTE_V_VRMA_MASK ASM_CONST(0x4001ffffff000000) + /* Values for PP (assumes Ks=0, Kp=1) */ /* pp0 will always be 0 for linux */ #define PP_RWXX 0 /* Supervisor read/write, User none */ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch ] Kexec/Kdump support - POWER6 2007-05-29 6:18 ` Sachin P. Sant @ 2007-05-29 6:58 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 18+ messages in thread From: Benjamin Herrenschmidt @ 2007-05-29 6:58 UTC (permalink / raw) To: sachinp; +Cc: linuxppc-dev, Paul Mackerras, kexec On Tue, 2007-05-29 at 11:48 +0530, Sachin P. Sant wrote: > > In previous patches i had these #defines in mmu-hash64.h. But got > review comments to move them to lpar.c :-) Hrm... weird. Oh well, _I_ personally prefer them in mmu-hash64.h and since I'm writing most of the MMU code lately I'd say my opinion makes rule :-) > Oh well i will move them back to mmu-hash64.h. Thanks. Cheers, Ben. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch ] Kexec/Kdump support - POWER6 2007-05-28 11:40 ` Sachin P. Sant 2007-05-28 21:31 ` Benjamin Herrenschmidt @ 2007-05-29 10:14 ` Michael Ellerman 2007-05-29 11:06 ` Stephen Rothwell 1 sibling, 1 reply; 18+ messages in thread From: Michael Ellerman @ 2007-05-29 10:14 UTC (permalink / raw) To: sachinp; +Cc: Milton Miller II, Paul Mackerras, kexec, linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 3070 bytes --] On Mon, 2007-05-28 at 17:10 +0530, Sachin P. Sant wrote: > Benjamin Herrenschmidt wrote: > > If you're going to use the B (1T segment) bit instead of the bolted bit, > > at least define a proper constant in line with the existing naming of > > the hash table constants in mmu-hash64.h. I would suggest doing the same > > with the VRMA_MASK/VALUE thing and calling it HPTE_V_VRMA_MASK or > > something similar. > > > Well i had used them properly in my previous patches. Don't know why > i changed it in this patch :-( > > Here is the updated patch. > > >> + } > >> } > >> > > In addition, I would recommend following Michael's advice and using > > using the bulk remove Hcall whenever possible. > > > Yes will send out a separate patch to use bulk remove Hcall. > > Thanks > -Sachin > > > Signed-off-by : Sachin Sant <sachinp@in.ibm.com> > Signed-off-by : Mohan Kumar M <mohan@in.ibm.com> > --- > > > > > plain text document attachment (kexec-kdump-support-on-POWER6) > * On Power machines supporting VRMA, Kexec/Kdump does not work. > * Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables. > * Make sure these hpte entries are left untouched. > * > * This patch also adds plpar_pte_read_raw() on the lines of > * plpar_pte_remove_raw(). > > Signed-off-by : Sachin Sant <sachinp@in.ibm.com> > Signed-off-by : Mohan Kumar M <mohan@in.ibm.com> > --- > > diff -Naurp a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c > --- a/arch/powerpc/platforms/pseries/lpar.c 2007-05-19 09:36:17.000000000 +0530 > +++ b/arch/powerpc/platforms/pseries/lpar.c 2007-05-28 16:49:46.000000000 +0530 > @@ -369,16 +369,30 @@ static long pSeries_lpar_hpte_remove(uns > return -1; > } > > +#define HPTE_V_1TB_SEG ASM_CONST(0x4000000000000000) > +#define HPTE_V_VRMA_MASK ASM_CONST(0x4001ffffff) > + > static void pSeries_lpar_hptab_clear(void) > { > unsigned long size_bytes = 1UL << ppc64_pft_size; > unsigned long hpte_count = size_bytes >> 4; > - unsigned long dummy1, dummy2; > + unsigned long dummy1, dummy2, dword0; > + long lpar_rc; > int i; > > /* TODO: Use bulk call */ > - for (i = 0; i < hpte_count; i++) > - plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2); > + for (i = 0; i < hpte_count; i++) { > + /* dont remove HPTEs with VRMA mappings */ > + lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, HPTE_V_1TB_SEG, > + &dummy1, &dummy2); > + if (lpar_rc == H_NOT_FOUND) { > + lpar_rc = plpar_pte_read_raw(0, i, &dword0, &dummy1); > + if (!lpar_rc && (((dword0 >> 24) & HPTE_V_VRMA_MASK) <xxxxxxx You have trailing whitespace on that line. Add this to your ~/.vimrc, you do use vim right :) highlight RedundantWhitespace ctermbg=red guibg=red cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Patch ] Kexec/Kdump support - POWER6 2007-05-29 10:14 ` Michael Ellerman @ 2007-05-29 11:06 ` Stephen Rothwell 0 siblings, 0 replies; 18+ messages in thread From: Stephen Rothwell @ 2007-05-29 11:06 UTC (permalink / raw) To: michael; +Cc: Milton Miller II, kexec, linuxppc-dev, Mackerras, Paul [-- Attachment #1: Type: text/plain, Size: 367 bytes --] On Tue, 29 May 2007 20:14:44 +1000 Michael Ellerman <michael@ellerman.id.au> wrote: > > Add this to your ~/.vimrc, you do use vim right :) > > highlight RedundantWhitespace ctermbg=red guibg=red You need this as well: match RedundantWhitespace /\s\+$\| \+\ze\t/ -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2007-05-29 11:06 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-05-22 12:22 [Patch 0/2] Kexec/Kdump support POWER6 Sachin P. Sant 2007-05-22 12:24 ` [Patch 1/2] " Sachin P. Sant 2007-05-22 12:26 ` [Patch 2/2] " Sachin P. Sant 2007-05-22 15:34 ` Olof Johansson 2007-05-23 5:13 ` Sachin P. Sant 2007-05-23 5:14 ` Sachin P. Sant 2007-05-23 9:37 ` [Patch 2/2] Kexec/Kdump support - POWER6 Sachin P. Sant 2007-05-23 10:55 ` Paul Mackerras 2007-05-24 12:17 ` Mohan Kumar M 2007-05-24 14:21 ` Olof Johansson 2007-05-25 8:55 ` [Patch ] " Sachin P. Sant 2007-05-25 22:43 ` Benjamin Herrenschmidt 2007-05-28 11:40 ` Sachin P. Sant 2007-05-28 21:31 ` Benjamin Herrenschmidt 2007-05-29 6:18 ` Sachin P. Sant 2007-05-29 6:58 ` Benjamin Herrenschmidt 2007-05-29 10:14 ` Michael Ellerman 2007-05-29 11:06 ` Stephen Rothwell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).