From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH] PPC: Don't sync timebase when inside VM Date: Fri, 2 Mar 2012 11:17:20 -0600 Message-ID: <4F5100A0.8040802@freescale.com> References: <1330697553-27156-1-git-send-email-agraf@suse.de> <20120302162058.GA24552@schlenkerla.am.freescale.net> <9A229F04-DFC9-485D-AB06-B1A4F0AEB348@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "" , kvm list , linuxppc-dev , Stuart Yoder , To: Alexander Graf Return-path: In-Reply-To: <9A229F04-DFC9-485D-AB06-B1A4F0AEB348@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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 >>> Signed-off-by: Alexander Graf >>> --- >>> 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