From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v5] x86/AMD: Add support for AMD's OSVW feature in guests Date: Mon, 6 Feb 2012 18:08:20 -0500 Message-ID: <20120206230820.GA8636@phenom.dumpdata.com> References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com> <20120206174745.GA14324@phenom.dumpdata.com> <4F301F8B.5010306@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <4F301F8B.5010306@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Boris Ostrovsky Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com List-Id: xen-devel@lists.xenproject.org On Mon, Feb 06, 2012 at 01:44:27PM -0500, Boris Ostrovsky wrote: > On 02/06/12 12:47, Konrad Rzeszutek Wilk wrote: > >On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote: > >># HG changeset patch > >># User Boris Ostrovsky > >># Date 1328549858 -3600 > >># Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5 > >># Parent e2722b24dc0962de37215320b05d1bb7c4c42864 > >>x86/AMD: Add support for AMD's OSVW feature in guests. > >> > >>In some cases guests should not provide workarounds for errata even when the > >>physical processor is affected. For example, because of erratum 400 on family > >>10h processors a Linux guest will read an MSR (resulting in VMEXIT) before > >>going to idle in order to avoid getting stuck in a non-C0 state. This is not > > > >What about fixing the Linux guest to actually not do this? I presume you > >have encountered this with HVM guests - would it be possible to use > > > >set_pm_idle_to_default(default_idle) in the HVM bootup path, say in 'xen_hvm_guest_init' ?? > > > Changing Linux won't help guests running Linux prior to the change > so we still need this patch. And with the patch guest's pm_idle will Well, it can go on the stable tree. > be set to default_idle anyway (because > cpu_has_amd_erratum(amd_erratum_400) will return 0). Right, but that won't be called anymore to set the pm_idle b/c pm_idle is set to default_idle. > > > -boris > > > > > > >>necessary: HLT and IO instructions are intercepted and therefore there is no > >>reason for erratum 400 workaround in the guest. > >> > >>This patch allows us to present a guest with certain errata as fixed, > >>regardless of the state of actual hardware. >