[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW feature in guests
On 02/02/12 08:22, Jan Beulich wrote: On 01.02.12 at 17:30, Boris Ostrovsky<boris.ostrovsky@xxxxxxx> wrote:# HG changeset patch # User Boris Ostrovsky<boris.ostrovsky@xxxxxxx> # 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |