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

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

On Tue, Feb 07, 2012 at 08:26:57AM +0000, Jan Beulich wrote:
> >>> On 06.02.12 at 18:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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' ??
> 
> Are you saying this would work even with CONFIG_XEN not set
> (which I doubt, but is a valid case to consider)?

Ugh. Not in that case.

> 
> Also, this sort of adjustment is exactly what is being done better
> in the hypervisor, as it'll address the problem at hand for all guests,
> no matter what kernel (version or kind) they run.

Right. I concur that it should also be done in the hypervisor. But earlier
versions of the hypervisor are not getting this patch. So fixing it in
the kernel could cover some issues if one is using Xen 4.0 for example.

Hm, it seems that I actually neglected to say that and made it sound
like it should be either in the hypervisor or in the kernel. I meant both.

> 
> Jan