[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
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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.