On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood <scottwood@xxxxxxxxxxxxx> wrote:
> On 03/02/2012 10:30 AM, Alexander Graf wrote:
>>
>> On 02.03.2012, at 17:20, Scott Wood wrote:
>>
>>> On Fri, Mar 02, 2012 at 03:12:33PM +0100, Alexander Graf wrote:
>>>> When running inside a virtual machine, we can not modify timebase, so
>>>> let's just not call the functions for it then.
>>>>
>>>> This resolves hangs when booting e500 SMP guests on overcommitted hosts.
>>>>
>>>> Reported-by: Stuart Yoder <B08248@xxxxxxxxxxxxx>
>>>> Signed-off-by: Alexander Graf <agraf@xxxxxxx>
>>>> ---
>>>> arch/powerpc/platforms/85xx/smp.c | 7 +++++++
>>>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
>>>> index ff42490..d4b6c1f 100644
>>>> --- a/arch/powerpc/platforms/85xx/smp.c
>>>> +++ b/arch/powerpc/platforms/85xx/smp.c
>>>> @@ -249,6 +249,13 @@ void __init mpc85xx_smp_init(void)
>>>> smp_85xx_ops.cause_ipi = doorbell_cause_ipi;
>>>> }
>>>>
>>>> + /* When running under a hypervisor, we can not modify tb */
>>>> + np = of_find_node_by_path("/hypervisor");
>>>> + if (np) {
>>>> + smp_85xx_ops.give_timebase = NULL;
>>>> + smp_85xx_ops.take_timebase = NULL;
>>>> + }
>>>> +
>>>> smp_ops = &smp_85xx_ops;
>>>
>>> Again, for 85xx we should *never* sync the timebase in the kernel,
>>> hypervisor or no.
>>
>> The code says "if the kexec config option is enabled, do the sync". I'm fairly sure it's there for a reason.
>
> Sigh. I forgot about that. It's because instead of doing kexec the
> simple way, we actually physically reset the core. We really shouldn't
> do that. And we *really* shouldn't do it just because CONFIG_KEXEC is
> defined, regardless of whether we're actually booting from kexec.
How would one rocver a core that's off in the weeds? We need to at
least stop it somehow before we restart into the kdump kernel. kexec
seems feasible since we have all the cores in a known state...
-M
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
