Re: [PATCH v5] x86/AMD: Add support for AMD's OSVW feature in guests

[Christoph Egger <Christoph.Egger@amd.com>]

On 02/06/12 19:44, Boris Ostrovsky wrote:
> 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<boris.ostrovsky@amd.com>
>>> # 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).

Right. Also fixing Linux won't help non-Linux guests, too.

Christoph


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


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632