From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v4] x86/AMD: Add support for AMD's OSVW feature in guests Date: Thu, 2 Feb 2012 15:29:16 -0500 Message-ID: <4F2AF21C.3090305@amd.com> References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com> <4F2A9C1C0200007800070823@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F2A9C1C0200007800070823@nat28.tlf.novell.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: Jan Beulich Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org List-Id: xen-devel@lists.xenproject.org On 02/02/12 08:22, Jan Beulich wrote: >>>> On 01.02.12 at 17:30, Boris Ostrovsky wrote: >> # HG changeset patch >> # User Boris Ostrovsky >> # Date 1328108207 -3600 >> # Node ID 789bbf4f478b0e81d71240a1f1147ef66a7c8848 >> # 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 >> 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. > > As I was about to apply this to my local tree to give it a try, I had > to realize that the microcode integration is still not correct: There > is (at least from an abstract perspective) no guarantee for > cpu_request_microcode() to be called on all CPUs, yet you want > svm_host_osvw_init() to be re-run on all of them. If you choose > to not deal with this in a formally correct way, it should be stated > so in a code comment (to lower the risk of surprises when someone > touches that code) that this is not possible in practice because > collect_cpu_info() won't currently fail for CPUs of interest. What if svm_host_osvw_init() is called from collect_cpu_info()? There may be cases when svm_host_osvw_init() is called multiple times for the same cpu but that should be harmless (and the routine will be renamed to svm_host_osvw_update()). This would change a bit the scope of things that collect_cpu_info() is expected to do though. But then one could argue that stashing OSVW bits is to some extent also collecting CPU info, albeit for a different purpose. -boris