| Message ID | 1435661062-4127-1-git-send-email-grygorii.strashko@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 6/30/2015 3:44 AM, Grygorii Strashko wrote: > On some PAE systems (e.g. TI Keystone), memory is above the 32-bit > addressable limit, and the interconnect provides an aliased view of > parts of physical memory in the 32-bit addressable space. This alias > is strictly for boot time usage, and is not otherwise usable because > of coherency limitations. > > On such systems, the idmap mechanism has to be used to pass correct > boot address of secondary CPU to FW. > virt_to_idmap() will fall-back to existing virt_to_phys() macro if > such conversation is not required. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Nicolas Pitre <nico@linaro.org> > Cc: Santosh Shilimkar <ssantosh@kernel.org> > Cc: Vitaly Andrianov <vitalya@ti.com> > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > --- Acked-by: Santosh Shilimkar <ssantosh@kernel.org> > arch/arm/kernel/psci_smp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c > index 28a1db4..244aadd 100644 > --- a/arch/arm/kernel/psci_smp.c > +++ b/arch/arm/kernel/psci_smp.c > @@ -51,7 +51,7 @@ static int psci_boot_secondary(unsigned int cpu, struct task_struct *idle) > { > if (psci_ops.cpu_on) > return psci_ops.cpu_on(cpu_logical_map(cpu), > - __pa(secondary_startup)); > + virt_to_idmap(&secondary_startup)); > return -ENODEV; > } > >
On Tue, Jun 30, 2015 at 01:44:22PM +0300, Grygorii Strashko wrote: > On some PAE systems (e.g. TI Keystone), memory is above the 32-bit > addressable limit, and the interconnect provides an aliased view of > parts of physical memory in the 32-bit addressable space. This alias > is strictly for boot time usage, and is not otherwise usable because > of coherency limitations. > > On such systems, the idmap mechanism has to be used to pass correct > boot address of secondary CPU to FW. > virt_to_idmap() will fall-back to existing virt_to_phys() macro if > such conversation is not required. I think this could do with improvement so that those who aren't aware of the issue can understand better. The idmap mechanism is always used for secondary booting anyway. "In this case, virt_to_phys(secondary_startup) would return the physical address of the secondary CPU boot entry point, but on such systems, this would be above the 4GB limit. A separate function, virt_to_idmap(), has been provided to return a usable physical address for functions in the identity mapping, and this must be used in preference to virt_to_phys() or __pa() to find the physical entry point for functions in the identity mapping range. For other systems, virt_to_idmap() and virt_to_phys() return identical physical addresses." > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Nicolas Pitre <nico@linaro.org> > Cc: Santosh Shilimkar <ssantosh@kernel.org> > Cc: Vitaly Andrianov <vitalya@ti.com> > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Code-wise, this looks correct to me - but as it's PSCI stuff, I'd like to see Nico ack it. Thanks. > --- > arch/arm/kernel/psci_smp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c > index 28a1db4..244aadd 100644 > --- a/arch/arm/kernel/psci_smp.c > +++ b/arch/arm/kernel/psci_smp.c > @@ -51,7 +51,7 @@ static int psci_boot_secondary(unsigned int cpu, struct task_struct *idle) > { > if (psci_ops.cpu_on) > return psci_ops.cpu_on(cpu_logical_map(cpu), > - __pa(secondary_startup)); > + virt_to_idmap(&secondary_startup)); > return -ENODEV; > } > > -- > 2.4.5 >
On Tue, 30 Jun 2015, Russell King - ARM Linux wrote: > On Tue, Jun 30, 2015 at 01:44:22PM +0300, Grygorii Strashko wrote: > > On some PAE systems (e.g. TI Keystone), memory is above the 32-bit > > addressable limit, and the interconnect provides an aliased view of > > parts of physical memory in the 32-bit addressable space. This alias > > is strictly for boot time usage, and is not otherwise usable because > > of coherency limitations. > > > > On such systems, the idmap mechanism has to be used to pass correct > > boot address of secondary CPU to FW. > > virt_to_idmap() will fall-back to existing virt_to_phys() macro if > > such conversation is not required. > > I think this could do with improvement so that those who aren't aware of > the issue can understand better. The idmap mechanism is always used for > secondary booting anyway. > > "In this case, virt_to_phys(secondary_startup) would return the > physical address of the secondary CPU boot entry point, but on such > systems, this would be above the 4GB limit. > > A separate function, virt_to_idmap(), has been provided to return a > usable physical address for functions in the identity mapping, and > this must be used in preference to virt_to_phys() or __pa() to find > the physical entry point for functions in the identity mapping range. > > For other systems, virt_to_idmap() and virt_to_phys() return identical > physical addresses." > > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: Nicolas Pitre <nico@linaro.org> > > Cc: Santosh Shilimkar <ssantosh@kernel.org> > > Cc: Vitaly Andrianov <vitalya@ti.com> > > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > > Code-wise, this looks correct to me - but as it's PSCI stuff, I'd like > to see Nico ack it. I cannot pretend to be the authority on PSCI stuff. But this looks correct to me as well, assuming the amended commit message. Acked-by: Nicolas Pitre <nico@linaro.org> > Thanks. > > > --- > > arch/arm/kernel/psci_smp.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c > > index 28a1db4..244aadd 100644 > > --- a/arch/arm/kernel/psci_smp.c > > +++ b/arch/arm/kernel/psci_smp.c > > @@ -51,7 +51,7 @@ static int psci_boot_secondary(unsigned int cpu, struct task_struct *idle) > > { > > if (psci_ops.cpu_on) > > return psci_ops.cpu_on(cpu_logical_map(cpu), > > - __pa(secondary_startup)); > > + virt_to_idmap(&secondary_startup)); > > return -ENODEV; > > } > > > > -- > > 2.4.5 > > > > -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net. > >
Hi, On Tue, Jun 30, 2015 at 11:44:22AM +0100, Grygorii Strashko wrote: > On some PAE systems (e.g. TI Keystone), memory is above the 32-bit > addressable limit, and the interconnect provides an aliased view of > parts of physical memory in the 32-bit addressable space. This alias > is strictly for boot time usage, and is not otherwise usable because > of coherency limitations. > > On such systems, the idmap mechanism has to be used to pass correct > boot address of secondary CPU to FW. > virt_to_idmap() will fall-back to existing virt_to_phys() macro if > such conversation is not required. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Nicolas Pitre <nico@linaro.org> > Cc: Santosh Shilimkar <ssantosh@kernel.org> > Cc: Vitaly Andrianov <vitalya@ti.com> > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > --- > arch/arm/kernel/psci_smp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) The code itself looks sane to me, though the commit message would be better with Russell's suggested rewording. This will also conflict with my migration to a common PSCI client implementation [1,2] (especially given the absence of virt_to_idmap on arm64), but I'm happy to fold it in or rebase atop of it. Russell, are you able to take a look at the migration patch [2]? How would you prefer for the two patches to be taken? Thanks, Mark. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/346492.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/346503.html > > diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c > index 28a1db4..244aadd 100644 > --- a/arch/arm/kernel/psci_smp.c > +++ b/arch/arm/kernel/psci_smp.c > @@ -51,7 +51,7 @@ static int psci_boot_secondary(unsigned int cpu, struct task_struct *idle) > { > if (psci_ops.cpu_on) > return psci_ops.cpu_on(cpu_logical_map(cpu), > - __pa(secondary_startup)); > + virt_to_idmap(&secondary_startup)); > return -ENODEV; > } > > -- > 2.4.5 >
On 06/30/2015 11:59 AM, Nicolas Pitre wrote: > On Tue, 30 Jun 2015, Russell King - ARM Linux wrote: > >> On Tue, Jun 30, 2015 at 01:44:22PM +0300, Grygorii Strashko wrote: >>> On some PAE systems (e.g. TI Keystone), memory is above the 32-bit >>> addressable limit, and the interconnect provides an aliased view of >>> parts of physical memory in the 32-bit addressable space. This alias >>> is strictly for boot time usage, and is not otherwise usable because >>> of coherency limitations. >>> >>> On such systems, the idmap mechanism has to be used to pass correct >>> boot address of secondary CPU to FW. >>> virt_to_idmap() will fall-back to existing virt_to_phys() macro if >>> such conversation is not required. >> >> I think this could do with improvement so that those who aren't aware of >> the issue can understand better. The idmap mechanism is always used for >> secondary booting anyway. >> >> "In this case, virt_to_phys(secondary_startup) would return the >> physical address of the secondary CPU boot entry point, but on such >> systems, this would be above the 4GB limit. >> >> A separate function, virt_to_idmap(), has been provided to return a >> usable physical address for functions in the identity mapping, and >> this must be used in preference to virt_to_phys() or __pa() to find >> the physical entry point for functions in the identity mapping range. >> >> For other systems, virt_to_idmap() and virt_to_phys() return identical >> physical addresses." >> >>> >>> Cc: Mark Rutland <mark.rutland@arm.com> >>> Cc: Nicolas Pitre <nico@linaro.org> >>> Cc: Santosh Shilimkar <ssantosh@kernel.org> >>> Cc: Vitaly Andrianov <vitalya@ti.com> >>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> >> >> Code-wise, this looks correct to me - but as it's PSCI stuff, I'd like >> to see Nico ack it. > > I cannot pretend to be the authority on PSCI stuff. > > But this looks correct to me as well, assuming the amended commit > message. > > Acked-by: Nicolas Pitre <nico@linaro.org> > >> Thanks. >> >>> --- >>> arch/arm/kernel/psci_smp.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c >>> index 28a1db4..244aadd 100644 >>> --- a/arch/arm/kernel/psci_smp.c >>> +++ b/arch/arm/kernel/psci_smp.c >>> @@ -51,7 +51,7 @@ static int psci_boot_secondary(unsigned int cpu, struct task_struct *idle) >>> { >>> if (psci_ops.cpu_on) >>> return psci_ops.cpu_on(cpu_logical_map(cpu), >>> - __pa(secondary_startup)); >>> + virt_to_idmap(&secondary_startup)); >>> return -ENODEV; >>> } >>> >>> -- >>> 2.4.5 >>> >> >> -- >> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up >> according to speedtest.net. >> >> Tested-by Vitaly Andrianov <vitalya@ti.com>
On Tue, Jun 30, 2015 at 05:18:37PM +0100, Mark Rutland wrote: > Hi, > > On Tue, Jun 30, 2015 at 11:44:22AM +0100, Grygorii Strashko wrote: > > On some PAE systems (e.g. TI Keystone), memory is above the 32-bit > > addressable limit, and the interconnect provides an aliased view of > > parts of physical memory in the 32-bit addressable space. This alias > > is strictly for boot time usage, and is not otherwise usable because > > of coherency limitations. > > > > On such systems, the idmap mechanism has to be used to pass correct > > boot address of secondary CPU to FW. > > virt_to_idmap() will fall-back to existing virt_to_phys() macro if > > such conversation is not required. > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: Nicolas Pitre <nico@linaro.org> > > Cc: Santosh Shilimkar <ssantosh@kernel.org> > > Cc: Vitaly Andrianov <vitalya@ti.com> > > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > > --- > > arch/arm/kernel/psci_smp.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > The code itself looks sane to me, though the commit message would be > better with Russell's suggested rewording. > > This will also conflict with my migration to a common PSCI client > implementation [1,2] (especially given the absence of virt_to_idmap on > arm64), but I'm happy to fold it in or rebase atop of it. > > Russell, are you able to take a look at the migration patch [2]? How > would you prefer for the two patches to be taken? Well, the first thing that stands out about patch [2] is that it's introducing a load of magic hex numbers, where before we had a struct with nice definitions. (I'm thinking about highbank_suspend_finish() and calxeda_idle_finish().) This seems to be a backwards step. There's two options on how to handle this. Either accept the virt_to_idmap() change first, and then sort out the resulting difference, maybe by having ARM64 grow a virt_to_idmap() of its own (which is just a virt_to_phys()) or we do it the other way around. Either way, we need a new macro, and the established name for it is virt_to_idmap(). The order doesn't matter as the end result would be the same. > Thanks, > Mark. > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/346492.html > [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/346503.html
Hi, On 06/30/2015 11:25 PM, Russell King - ARM Linux wrote: > On Tue, Jun 30, 2015 at 05:18:37PM +0100, Mark Rutland wrote: >> On Tue, Jun 30, 2015 at 11:44:22AM +0100, Grygorii Strashko wrote: >>> On some PAE systems (e.g. TI Keystone), memory is above the 32-bit >>> addressable limit, and the interconnect provides an aliased view of >>> parts of physical memory in the 32-bit addressable space. This alias >>> is strictly for boot time usage, and is not otherwise usable because >>> of coherency limitations. >>> >>> On such systems, the idmap mechanism has to be used to pass correct >>> boot address of secondary CPU to FW. >>> virt_to_idmap() will fall-back to existing virt_to_phys() macro if >>> such conversation is not required. >>> >>> Cc: Mark Rutland <mark.rutland@arm.com> >>> Cc: Nicolas Pitre <nico@linaro.org> >>> Cc: Santosh Shilimkar <ssantosh@kernel.org> >>> Cc: Vitaly Andrianov <vitalya@ti.com> >>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> >>> --- >>> arch/arm/kernel/psci_smp.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> The code itself looks sane to me, though the commit message would be >> better with Russell's suggested rewording. >> >> This will also conflict with my migration to a common PSCI client >> implementation [1,2] (especially given the absence of virt_to_idmap on >> arm64), but I'm happy to fold it in or rebase atop of it. I saw your series in lists, but, seems, It is not in next (4.2). Therefor I've not tried to base this patch on top of your series, but you can reuse/squash it as you think is better. >> >> Russell, are you able to take a look at the migration patch [2]? How >> would you prefer for the two patches to be taken? > > Well, the first thing that stands out about patch [2] is that it's > introducing a load of magic hex numbers, where before we had a struct > with nice definitions. (I'm thinking about highbank_suspend_finish() > and calxeda_idle_finish().) This seems to be a backwards step. > > There's two options on how to handle this. Either accept the > virt_to_idmap() change first, and then sort out the resulting difference, > maybe by having ARM64 grow a virt_to_idmap() of its own (which is just > a virt_to_phys()) or we do it the other way around. Either way, we > need a new macro, and the established name for it is virt_to_idmap(). > The order doesn't matter as the end result would be the same. There is another advantage to keep this patch as is - as a fix it can be back-ported to stable trees (at least in 4.1, but probably even in v3.13. psci_smp.c added in v3.11 virt_to_idmap added in v3.13
On Tue, Jun 30, 2015 at 09:25:37PM +0100, Russell King - ARM Linux wrote: > On Tue, Jun 30, 2015 at 05:18:37PM +0100, Mark Rutland wrote: > > Hi, > > > > On Tue, Jun 30, 2015 at 11:44:22AM +0100, Grygorii Strashko wrote: > > > On some PAE systems (e.g. TI Keystone), memory is above the 32-bit > > > addressable limit, and the interconnect provides an aliased view of > > > parts of physical memory in the 32-bit addressable space. This alias > > > is strictly for boot time usage, and is not otherwise usable because > > > of coherency limitations. > > > > > > On such systems, the idmap mechanism has to be used to pass correct > > > boot address of secondary CPU to FW. > > > virt_to_idmap() will fall-back to existing virt_to_phys() macro if > > > such conversation is not required. > > > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > Cc: Nicolas Pitre <nico@linaro.org> > > > Cc: Santosh Shilimkar <ssantosh@kernel.org> > > > Cc: Vitaly Andrianov <vitalya@ti.com> > > > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > > > --- > > > arch/arm/kernel/psci_smp.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > The code itself looks sane to me, though the commit message would be > > better with Russell's suggested rewording. > > > > This will also conflict with my migration to a common PSCI client > > implementation [1,2] (especially given the absence of virt_to_idmap on > > arm64), but I'm happy to fold it in or rebase atop of it. > > > > Russell, are you able to take a look at the migration patch [2]? How > > would you prefer for the two patches to be taken? > > Well, the first thing that stands out about patch [2] is that it's > introducing a load of magic hex numbers, where before we had a struct > with nice definitions. (I'm thinking about highbank_suspend_finish() > and calxeda_idle_finish().) This seems to be a backwards step. The existing suspend parameter packing/unpacking didn't work now that there are multiple possible formats for the suspend parameter from PSCIv1.0 onwards, and the core PSCI code won't do any more packing/unpacking, treating the suspend parameter as a mostly opaque token. I could retain the struct and packing functions for the two cases you mention, but it seemed somewhat misleading. I'll see if I can figure out something better than a raw hex value. Other than that, were you happy with the arch/arm changes? > There's two options on how to handle this. Either accept the > virt_to_idmap() change first, and then sort out the resulting difference, > maybe by having ARM64 grow a virt_to_idmap() of its own (which is just > a virt_to_phys()) or we do it the other way around. Either way, we > need a new macro, and the established name for it is virt_to_idmap(). > The order doesn't matter as the end result would be the same. Ok. I guess it's easier to take Grygorii's patch first (with updated commit message), and I'll fix the rest of my patches to cater for that. I'll add that to the front of my series for the moment. Thanks, Mark.
On Thu, Jul 02, 2015 at 11:29:37AM +0100, Mark Rutland wrote: > On Tue, Jun 30, 2015 at 09:25:37PM +0100, Russell King - ARM Linux wrote: > > On Tue, Jun 30, 2015 at 05:18:37PM +0100, Mark Rutland wrote: > > > Hi, > > > > > > On Tue, Jun 30, 2015 at 11:44:22AM +0100, Grygorii Strashko wrote: > > > > On some PAE systems (e.g. TI Keystone), memory is above the 32-bit > > > > addressable limit, and the interconnect provides an aliased view of > > > > parts of physical memory in the 32-bit addressable space. This alias > > > > is strictly for boot time usage, and is not otherwise usable because > > > > of coherency limitations. > > > > > > > > On such systems, the idmap mechanism has to be used to pass correct > > > > boot address of secondary CPU to FW. > > > > virt_to_idmap() will fall-back to existing virt_to_phys() macro if > > > > such conversation is not required. > > > > > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > > Cc: Nicolas Pitre <nico@linaro.org> > > > > Cc: Santosh Shilimkar <ssantosh@kernel.org> > > > > Cc: Vitaly Andrianov <vitalya@ti.com> > > > > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > > > > --- > > > > arch/arm/kernel/psci_smp.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > The code itself looks sane to me, though the commit message would be > > > better with Russell's suggested rewording. > > > > > > This will also conflict with my migration to a common PSCI client > > > implementation [1,2] (especially given the absence of virt_to_idmap on > > > arm64), but I'm happy to fold it in or rebase atop of it. > > > > > > Russell, are you able to take a look at the migration patch [2]? How > > > would you prefer for the two patches to be taken? > > > > Well, the first thing that stands out about patch [2] is that it's > > introducing a load of magic hex numbers, where before we had a struct > > with nice definitions. (I'm thinking about highbank_suspend_finish() > > and calxeda_idle_finish().) This seems to be a backwards step. > > The existing suspend parameter packing/unpacking didn't work now that > there are multiple possible formats for the suspend parameter from > PSCIv1.0 onwards, and the core PSCI code won't do any more > packing/unpacking, treating the suspend parameter as a mostly opaque > token. ... which is fine. > I could retain the struct and packing functions for the two cases you > mention, but it seemed somewhat misleading. I'll see if I can figure out > something better than a raw hex value. What's wrong with a few #defines for this? It obviously is well enough defined in existing pre-v1.0 implementations as there is an existing structure to the parameter. Can we not do something like: #define PSCI_POWER_STATE_ID(x) (x) #define PSCI_POWER_STATE_TYPE_POWER_DOWN 0x000100000 #define PSCI_POWER_STATE_AFFINITY_LEVEL(x) ((x) << 24) ?
> > I could retain the struct and packing functions for the two cases you > > mention, but it seemed somewhat misleading. I'll see if I can figure out > > something better than a raw hex value. > > What's wrong with a few #defines for this? Nothing. > It obviously is well enough defined in existing pre-v1.0 > implementations as there is an existing structure to the parameter. > > Can we not do something like: > > #define PSCI_POWER_STATE_ID(x) (x) > #define PSCI_POWER_STATE_TYPE_POWER_DOWN 0x000100000 > #define PSCI_POWER_STATE_AFFINITY_LEVEL(x) ((x) << 24) Looks good. We already have some constants defined in a UAPI header, so I'll see about reusing those. Thanks, Mark.
diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c index 28a1db4..244aadd 100644 --- a/arch/arm/kernel/psci_smp.c +++ b/arch/arm/kernel/psci_smp.c @@ -51,7 +51,7 @@ static int psci_boot_secondary(unsigned int cpu, struct task_struct *idle) { if (psci_ops.cpu_on) return psci_ops.cpu_on(cpu_logical_map(cpu), - __pa(secondary_startup)); + virt_to_idmap(&secondary_startup)); return -ENODEV; }
On some PAE systems (e.g. TI Keystone), memory is above the 32-bit addressable limit, and the interconnect provides an aliased view of parts of physical memory in the 32-bit addressable space. This alias is strictly for boot time usage, and is not otherwise usable because of coherency limitations. On such systems, the idmap mechanism has to be used to pass correct boot address of secondary CPU to FW. virt_to_idmap() will fall-back to existing virt_to_phys() macro if such conversation is not required. Cc: Mark Rutland <mark.rutland@arm.com> Cc: Nicolas Pitre <nico@linaro.org> Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Vitaly Andrianov <vitalya@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> --- arch/arm/kernel/psci_smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)