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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Feb 06, 2012 at 01:44:27PM -0500, 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

Well, it can go on the stable tree.

> be set to default_idle anyway (because
> cpu_has_amd_erratum(amd_erratum_400) will return 0).

Right, but that won't be called anymore to set the pm_idle b/c pm_idle is set
to default_idle.


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