[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120314001833.GB20363@phenom.dumpdata.com>
Date: Tue, 13 Mar 2012 20:18:33 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: "Liu, Jinsong" <jinsong.liu@...el.com>
Cc: "lenb@...nel.org" <lenb@...nel.org>,
"Brown, Len" <len.brown@...el.com>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
Kernel development list <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"keir.xen@...il.com" <keir.xen@...il.com>,
Jan Beulich <JBeulich@...e.com>,
"Li, Shaohua" <shaohua.li@...el.com>
Subject: Re: [PATCH 2/2] RFC: Xen pad logic
On Thu, Feb 23, 2012 at 01:31:25PM +0000, Liu, Jinsong wrote:
> >From ba9abf6ee7e5fe0515e2d51b14743c8d5416285c Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@...el.com>
> Date: Fri, 24 Feb 2012 02:18:02 +0800
> Subject: [PATCH 2/2] Xen pad logic
>
> This patch implement Xen pad logic, and when getting pad device
> notification, it hypercalls to Xen hypervisor for core parking.
Can you explain to me how and what pad device is? And how it functions
right now in baremetal? And what kind of hardware do you need to use this?
And what happens if you do not use it? Can one ignore the "pad" support?
Please assume that I've a basic understanding of ACPI.
Also, what happens now, if the this patch is not implemented? What
will/is dom0 doing without these patches (so 3.2 for example on this machine)?
Is it just idling using mwait on idle CPUs and ending up trapping in the hypervisor?
Or is not mwaiting since the cstate.c doesn't get executed since we have:
boot_option_idle_override = IDLE_HALT;
in arch/x86/xen/setup.c ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists