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.
-Scott
--
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
