public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Len Brown <lenb@kernel.org>, pradeepv@amazon.com
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>
Subject: Re: [Xen-devel] Re: Regression in 3.1 causes Xen to use wrong idle routine
Date: Mon, 14 Nov 2011 13:26:56 -0500	[thread overview]
Message-ID: <20111114182656.GB14966@phenom.dumpdata.com> (raw)
In-Reply-To: <20111114143123.GA8317@phenom.dumpdata.com>

On Mon, Nov 14, 2011 at 09:31:24AM -0500, Konrad Rzeszutek Wilk wrote:
> Hey Len,
> 
> > > The problem I see is that select_idle_routine() is called from
> > > arch/x86/kernel/cpu/common.c and since Xen setup does not set pm_idle
> > > anymore, it can cause mwait_idle or amd_e400_idle functions to be selected.
> > > In testing it seem amd_e400_idle in PVM domU at least does not immediately cause
> > > problems, but mwait_idle just causes crashes. From the reports I have
> > > this may be related to older hypervisors (3.1 and older) not clearing the mwait
> > > capability. But overall there seems something wrong in the interaction.
> > 
> > Why is Xen advertising X86_FEATURE_MWAIT and then crashing
> > when the dom0 (or other guests) use what it advertises?
> 
> The only case where I've seen this is with Amazon EC2. The other
> newer hypervisors (4.1.1 and such) do not trigger this.
> 
> > 
> > What versions of Xen have this bug?
> 
> Whatever Amazon is using. I think they are RHEL5 based hypervisor.

Vincent,

Would you have ideas of what might be happening? It looks as if some Amazon
instances are advertisting the MWAIT flag but not really supporting it. Any ideas
of what might be going on?

> 
> > 
> > > I am not really sure whether the logic of calling pm_idle() on all errors from
> > > cpuidle_call_idle() is already flawed or the assumption in the Xen patch about
> > > being able to prevent the wrong idle function by turning cpuidle off is incorrect.
> > 
> > The patches above appear to be operating as intended.
> > What wasn't expected, was that some version of Xen is deployed that
> > advertises the MWAIT feature, but crashes when it is used.
> 
> How does that work with AMD? On those machines it ends up calling
> amd_e400_idle instead of the default_idle. Granted it does not "BUG" out
> but it does lead to extra trap-n-emulate (the MSR operation) in to the hypervisor
> which is not good.

.. snip..
> > Working around this Xen bug for a newly compiled Dom0 is insufficient.

It looks to affect PV guests as well.

> > 
> > All guests that also look for MWAIT support w/o asking ACPI
> > (ie. all versions of Linux that use intel_idle, such as the last few
> > Fedora's, RHEL, SLES etc.)
> > will trip over the same Xen bug, even if Dom0 doesn't.

Don't think I answered this one: 

The intel_idle has not been used in those cases b/c the default_idle
had been used instead.

> > 
> > Xen must not advertises MWAIT support if it doesn't have MWAIT support.
> 
> How does work out when we figure MWAIT support from the CPUID?
> Or are you saying that it is correct - if the CPU advertises it, then yes
> advertise it to the Linux kernel?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

      reply	other threads:[~2011-11-14 18:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-26 10:24 Regression in 3.1 causes Xen to use wrong idle routine Stefan Bader
2011-10-26 13:30 ` Konrad Rzeszutek Wilk
2011-10-26 13:36   ` Stefan Bader
2011-10-26 13:48     ` Konrad Rzeszutek Wilk
2011-10-26 13:57       ` Stefan Bader
2011-11-09 17:58         ` [Xen-devel] " Konrad Rzeszutek Wilk
2011-11-10  8:33           ` Stefan Bader
2011-11-10 14:55             ` Konrad Rzeszutek Wilk
2011-11-10 15:35               ` Stefan Bader
2011-11-13  3:46 ` Len Brown
2011-11-13 16:59   ` [Xen-devel] " Keir Fraser
2011-11-14 18:19     ` Konrad Rzeszutek Wilk
2011-11-14 20:11       ` Konrad Rzeszutek Wilk
2011-11-14 14:31   ` Konrad Rzeszutek Wilk
2011-11-14 18:26     ` Konrad Rzeszutek Wilk [this message]

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=20111114182656.GB14966@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=pradeepv@amazon.com \
    --cc=stefan.bader@canonical.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox