All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [PATCH v4] x86/AMD: Add support for AMD's OSVW feature in guests
Date: Thu, 2 Feb 2012 15:29:16 -0500	[thread overview]
Message-ID: <4F2AF21C.3090305@amd.com> (raw)
In-Reply-To: <4F2A9C1C0200007800070823@nat28.tlf.novell.com>

On 02/02/12 08:22, Jan Beulich wrote:
>>>> On 01.02.12 at 17:30, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>> # HG changeset patch
>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>> # 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

  reply	other threads:[~2012-02-02 20:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-01 16:30 [PATCH v4] x86/AMD: Add support for AMD's OSVW feature in guests Boris Ostrovsky
2012-02-02 13:22 ` Jan Beulich
2012-02-02 20:29   ` Boris Ostrovsky [this message]
2012-02-03  7:53     ` Jan Beulich
2012-02-03 16:13       ` Boris Ostrovsky
2012-02-03 16:25         ` Jan Beulich
2012-02-03 16:48           ` Boris Ostrovsky
2012-02-03 16:59             ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F2AF21C.3090305@amd.com \
    --to=boris.ostrovsky@amd.com \
    --cc=Christoph.Egger@amd.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.