From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v5] x86/AMD: Add support for AMD's OSVW feature in guests Date: Mon, 6 Feb 2012 13:44:27 -0500 Message-ID: <4F301F8B.5010306@amd.com> References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com> <20120206174745.GA14324@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120206174745.GA14324@phenom.dumpdata.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: Konrad Rzeszutek Wilk Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com List-Id: xen-devel@lists.xenproject.org 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 be set to default_idle anyway (because cpu_has_amd_erratum(amd_erratum_400) will return 0). -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.