| Message ID | 8yapqn7fyab.fsf@huya.qualcomm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, 24 May 2011, David Brown wrote: > On Tue, May 24 2011, Catalin Marinas wrote: > > > This set of patches adds support for the Large Physical Extensions on > > the ARM architecture (available with the Cortex-A15 processor). LPAE > > comes with a 3-level page table format (compared to 2-level for the > > classic one), allowing up to 40-bit physical address space. > > Do you expect non LPAE targets to be able to boot with these changes > applied (and LPAE enabled)? I am able to build this tree for the > MSM8660 (with a minor patch below), but it fails to boot with LPAE > enabled. It seems to work fine with LPAE not enabled. I wouldn't expect a LPAE kernel to boot on non LPAE capable hardware. And I don't think we'll ever try to support both LPAE and non-LPAE modes in the same kernel binary either since this has implications all over the place in core kernel mm code. Nicolas
On Wed, 2011-05-25 at 00:56 +0100, David Brown wrote: > On Tue, May 24 2011, Catalin Marinas wrote: > > > This set of patches adds support for the Large Physical Extensions on > > the ARM architecture (available with the Cortex-A15 processor). LPAE > > comes with a 3-level page table format (compared to 2-level for the > > classic one), allowing up to 40-bit physical address space. > > Do you expect non LPAE targets to be able to boot with these changes > applied (and LPAE enabled)? I am able to build this tree for the > MSM8660 (with a minor patch below), but it fails to boot with LPAE > enabled. It seems to work fine with LPAE not enabled. As Nicolas replied already, we can't run an LPAE kernel on non-LPAE hardware. We could add some checks in head.S and branch to __error_p but it only works if you have CONFIG_DEBUG_LL enabled. > I did have to fix the msm timer code to get the branch you mentioned to > compile. The return type of the function changed back to 'void' without > changing the returns: I cc'ed Marc since he's maintaining the timer patches. > --- > arch/arm/mach-msm/timer.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c > index 50cc0bc..6e659e4 100644 > --- a/arch/arm/mach-msm/timer.c > +++ b/arch/arm/mach-msm/timer.c > @@ -268,7 +268,7 @@ static void __cpuinit msm_local_timer_setup(struct clock_event_device *evt) > > /* Use existing clock_event for cpu 0 */ > if (!smp_processor_id()) > - return 0; > + return; > > writel(DGT_CLK_CTL_DIV_4, MSM_TMR_BASE + DGT_CLK_CTL); > > @@ -296,7 +296,8 @@ static void __cpuinit msm_local_timer_setup(struct clock_event_device *evt) > if (res) { > pr_err("local_timer_setup: request_irq failed for %s\n", > clock->clockevent.name); > - return res; > + /* TODO: How to handle this error. */ > + return; > } > > clockevents_register_device(evt); Thanks.
On Wednesday 25 May 2011, Nicolas Pitre wrote: > > Do you expect non LPAE targets to be able to boot with these changes > > applied (and LPAE enabled)? I am able to build this tree for the > > MSM8660 (with a minor patch below), but it fails to boot with LPAE > > enabled. It seems to work fine with LPAE not enabled. > > I wouldn't expect a LPAE kernel to boot on non LPAE capable hardware. > > And I don't think we'll ever try to support both LPAE and non-LPAE modes > in the same kernel binary either since this has implications all over > the place in core kernel mm code. Just for information and to complete the picture, what other of these combinations are possible? * Non-LPAE kernel on LPAE-capable hardware * LPAE kernel as KVM guest of LPAE kernel * non-LPAE kernel as KVM guest of LPAE kernel * LPAE kernel as KVM guest of non-LPAE kernel * non-LPAE kernel as KVM guest of non-LPAE kernel on LPAE-enabled hardware Arnd
On Wed, 2011-05-25 at 12:10 +0100, Arnd Bergmann wrote: > On Wednesday 25 May 2011, Nicolas Pitre wrote: > > > Do you expect non LPAE targets to be able to boot with these changes > > > applied (and LPAE enabled)? I am able to build this tree for the > > > MSM8660 (with a minor patch below), but it fails to boot with LPAE > > > enabled. It seems to work fine with LPAE not enabled. > > > > I wouldn't expect a LPAE kernel to boot on non LPAE capable hardware. > > > > And I don't think we'll ever try to support both LPAE and non-LPAE modes > > in the same kernel binary either since this has implications all over > > the place in core kernel mm code. > > Just for information and to complete the picture, what other of these > combinations are possible? > > * Non-LPAE kernel on LPAE-capable hardware Works fine. The LPAE-capable processors like A15 support the classic page table format as well, it's only a configuration bit to switch to LPAE. > * LPAE kernel as KVM guest of LPAE kernel Should work when KVM for A15 becomes available > * non-LPAE kernel as KVM guest of LPAE kernel Same as above. KVM shouldn't care much about the underlying OS, it just sets up the IPA (Intermediate Physical Address) translations and you can have classic page tables on top. > * LPAE kernel as KVM guest of non-LPAE kernel No. KMV without LPAE uses a shadow page tables mechanism and I'm not aware of any plans to make it (guest) LPAE-aware. > * non-LPAE kernel as KVM guest of non-LPAE kernel on LPAE-enabled > hardware Would work as the current KVM implementation for ARMv7 with classic page tables (but I don't know what the status it).
On 25 May 2011 12:22, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Wed, 2011-05-25 at 12:10 +0100, Arnd Bergmann wrote: >> On Wednesday 25 May 2011, Nicolas Pitre wrote: >> > > Do you expect non LPAE targets to be able to boot with these changes >> > > applied (and LPAE enabled)? I am able to build this tree for the >> > > MSM8660 (with a minor patch below), but it fails to boot with LPAE >> > > enabled. It seems to work fine with LPAE not enabled. >> > >> > I wouldn't expect a LPAE kernel to boot on non LPAE capable hardware. >> > >> > And I don't think we'll ever try to support both LPAE and non-LPAE modes >> > in the same kernel binary either since this has implications all over >> > the place in core kernel mm code. >> >> Just for information and to complete the picture, what other of these >> combinations are possible? >> >> * Non-LPAE kernel on LPAE-capable hardware > > Works fine. The LPAE-capable processors like A15 support the classic > page table format as well, it's only a configuration bit to switch to > LPAE. > >> * LPAE kernel as KVM guest of LPAE kernel > > Should work when KVM for A15 becomes available > >> * non-LPAE kernel as KVM guest of LPAE kernel > > Same as above. KVM shouldn't care much about the underlying OS, it just > sets up the IPA (Intermediate Physical Address) translations and you can > have classic page tables on top. Just a clarification here - KVM with support for LPAE also requires the virtualisation extensions (which are present in Cortex-A15). The virtualisation extensions require LPAE in hardware but I'm not sure the opposite is true.
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c index 50cc0bc..6e659e4 100644 --- a/arch/arm/mach-msm/timer.c +++ b/arch/arm/mach-msm/timer.c @@ -268,7 +268,7 @@ static void __cpuinit msm_local_timer_setup(struct clock_event_device *evt) /* Use existing clock_event for cpu 0 */ if (!smp_processor_id()) - return 0; + return; writel(DGT_CLK_CTL_DIV_4, MSM_TMR_BASE + DGT_CLK_CTL); @@ -296,7 +296,8 @@ static void __cpuinit msm_local_timer_setup(struct clock_event_device *evt) if (res) { pr_err("local_timer_setup: request_irq failed for %s\n", clock->clockevent.name); - return res; + /* TODO: How to handle this error. */ + return; } clockevents_register_device(evt);