From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 29 Feb 2012 19:06:05 +0000 Subject: Re: [PATCH] KVM: PPC: Don't sync timebase when inside KVM Message-Id: <4F4E771D.1040403@freescale.com> List-Id: References: <1330481769-24390-1-git-send-email-agraf@suse.de> <4F4E6574.5050604@freescale.com> <39AA9511-4D56-4087-BC98-4BB32EF048AA@suse.de> In-Reply-To: <39AA9511-4D56-4087-BC98-4BB32EF048AA@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: "" , "" , "" , Stuart Yoder On 02/29/2012 12:28 PM, Alexander Graf wrote: > > > On 29.02.2012, at 18:50, Scott Wood wrote: > >> On 02/28/2012 08:16 PM, Alexander Graf wrote: >>> When we know that we're running inside of a KVM guest, we don't have to >>> worry about synchronizing timebases between different CPUs, since the >>> host already took care of that. >>> >>> This fixes CPU overcommit scenarios where vCPUs could hang forever trying >>> to sync each other while not being scheduled. >>> >>> Reported-by: Stuart Yoder >>> Signed-off-by: Alexander Graf >> >> This should apply to any hypervisor, not just KVM. > > Sure, but do you have a generic function to evaluate that? :) The presence of a hypervisor node without testing compatible. Might not get them all, but at least it will cover more than just KVM. >> Which platforms are you seeing this on? If it's on Freescale chips, >> U-Boot should be doing the sync and Linux should never do it, even in >> the absence of a hypervisor. > > This is on e500mc. On e500mc Linux should never by trying to sync the timebase. If it is, let's fix that. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from AM1EHSOBE005.bigfish.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "Microsoft Secure Server Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id B18AAB6F9D for ; Thu, 1 Mar 2012 06:06:18 +1100 (EST) Message-ID: <4F4E771D.1040403@freescale.com> Date: Wed, 29 Feb 2012 13:06:05 -0600 From: Scott Wood MIME-Version: 1.0 To: Alexander Graf Subject: Re: [PATCH] KVM: PPC: Don't sync timebase when inside KVM References: <1330481769-24390-1-git-send-email-agraf@suse.de> <4F4E6574.5050604@freescale.com> <39AA9511-4D56-4087-BC98-4BB32EF048AA@suse.de> In-Reply-To: <39AA9511-4D56-4087-BC98-4BB32EF048AA@suse.de> Content-Type: text/plain; charset="ISO-8859-1" Cc: "" , "" , "" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 02/29/2012 12:28 PM, Alexander Graf wrote: > > > On 29.02.2012, at 18:50, Scott Wood wrote: > >> On 02/28/2012 08:16 PM, Alexander Graf wrote: >>> When we know that we're running inside of a KVM guest, we don't have to >>> worry about synchronizing timebases between different CPUs, since the >>> host already took care of that. >>> >>> This fixes CPU overcommit scenarios where vCPUs could hang forever trying >>> to sync each other while not being scheduled. >>> >>> Reported-by: Stuart Yoder >>> Signed-off-by: Alexander Graf >> >> This should apply to any hypervisor, not just KVM. > > Sure, but do you have a generic function to evaluate that? :) The presence of a hypervisor node without testing compatible. Might not get them all, but at least it will cover more than just KVM. >> Which platforms are you seeing this on? If it's on Freescale chips, >> U-Boot should be doing the sync and Linux should never do it, even in >> the absence of a hypervisor. > > This is on e500mc. On e500mc Linux should never by trying to sync the timebase. If it is, let's fix that. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH] KVM: PPC: Don't sync timebase when inside KVM Date: Wed, 29 Feb 2012 13:06:05 -0600 Message-ID: <4F4E771D.1040403@freescale.com> References: <1330481769-24390-1-git-send-email-agraf@suse.de> <4F4E6574.5050604@freescale.com> <39AA9511-4D56-4087-BC98-4BB32EF048AA@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "" , "" , "" , Stuart Yoder To: Alexander Graf Return-path: Received: from am1ehsobe005.messaging.microsoft.com ([213.199.154.208]:38143 "EHLO AM1EHSOBE005.bigfish.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030667Ab2B2TGO (ORCPT ); Wed, 29 Feb 2012 14:06:14 -0500 In-Reply-To: <39AA9511-4D56-4087-BC98-4BB32EF048AA@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 02/29/2012 12:28 PM, Alexander Graf wrote: > > > On 29.02.2012, at 18:50, Scott Wood wrote: > >> On 02/28/2012 08:16 PM, Alexander Graf wrote: >>> When we know that we're running inside of a KVM guest, we don't have to >>> worry about synchronizing timebases between different CPUs, since the >>> host already took care of that. >>> >>> This fixes CPU overcommit scenarios where vCPUs could hang forever trying >>> to sync each other while not being scheduled. >>> >>> Reported-by: Stuart Yoder >>> Signed-off-by: Alexander Graf >> >> This should apply to any hypervisor, not just KVM. > > Sure, but do you have a generic function to evaluate that? :) The presence of a hypervisor node without testing compatible. Might not get them all, but at least it will cover more than just KVM. >> Which platforms are you seeing this on? If it's on Freescale chips, >> U-Boot should be doing the sync and Linux should never do it, even in >> the absence of a hypervisor. > > This is on e500mc. On e500mc Linux should never by trying to sync the timebase. If it is, let's fix that. -Scott