Xen devel - Feb 2012 - [PATCH 0 of 2] [RFC] Patches to work with processor-passthru driver (v1).

These two patches provide the neccessary infrastructure changes
for the processor-passthru driver
[www.spinics.net/lists/linux-acpi/msg34655.html]
to properly function.

The first one is quite easy - we just modprobe the processor-passthru driver.

The second allows it to work under AMD machines by exposing the PM RDMSR
to dom0. It has been tested with 2.6.32 kernel as well to make sure it does
not negativly impact them and it does not.

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1330065828 18000
# Node ID a34b652afb0ca484b7416008c95fd36ffbbea334
# Parent  a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)

The restriction to read and write the AMD power management MSRs is gated if the
domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
relax this restriction and allow the privileged domain to read the MSRs
(but not write). This allows the priviliged domain to harvest the power
management information (ACPI _PSS states) and send it to the hypervisor.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r a4d93d0e0df2 -r a34b652afb0c xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Wed Feb 22 14:33:24 2012 +0000
+++ b/xen/arch/x86/traps.c	Fri Feb 24 01:43:48 2012 -0500
@@ -2610,7 +2610,7 @@ static int emulate_privileged_op(struct 
         case MSR_K8_PSTATE7:
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
                 goto fail;
-            if ( !is_cpufreq_controller(v->domain) )
+            if ( !is_cpufreq_controller(v->domain) &&
!IS_PRIV(v->domain) )
             {
                 regs->eax = regs->edx = 0;
                 break;

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1330065828 18000
# Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
# Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
linux-xencommons: Load processor-passthru

The processor-passthru module is used in the upstream kernels
to upload power management information to the hypervisor. We
need to load it to work first.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r a34b652afb0c -r aa3a294327ed tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 01:43:48 2012 -0500
+++ b/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 01:43:48 2012 -0500
@@ -58,6 +58,7 @@ do_start () {
 	modprobe xen-gntdev 2>/dev/null
 	modprobe evtchn 2>/dev/null
 	modprobe gntdev 2>/dev/null
+	modprobe processor-passthru 2>/dev/null
 
 	if ! `xenstore-read -s / >/dev/null 2>&1`
 	then

>>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> # HG changeset patch
> # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> # Date 1330065828 18000
> # Node ID a34b652afb0ca484b7416008c95fd36ffbbea334
> # Parent  a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
> traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)
> 
> The restriction to read and write the AMD power management MSRs is gated if
> the
> domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
> relax this restriction and allow the privileged domain to read the MSRs
> (but not write). This allows the priviliged domain to harvest the power
> management information (ACPI _PSS states) and send it to the hypervisor.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff -r a4d93d0e0df2 -r a34b652afb0c xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c	Wed Feb 22 14:33:24 2012 +0000
> +++ b/xen/arch/x86/traps.c	Fri Feb 24 01:43:48 2012 -0500
> @@ -2610,7 +2610,7 @@ static int emulate_privileged_op(struct 
>          case MSR_K8_PSTATE7:
>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
>                  goto fail;
> -            if ( !is_cpufreq_controller(v->domain) )
> +            if ( !is_cpufreq_controller(v->domain) &&
!IS_PRIV(v->domain) )
As said already in response to your Linux side overview mail, while
I don''t view this as having potential to cause any problems, I also
don''t see the need.

And then if this indeed is wanted, replacing is_cpufreq_controller()
by IS_PRIV() rather than adding the latter would seem preferable
(because of being more strait forward).

Jan
>              {
>                  regs->eax = regs->edx = 0;
>                  break;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel

>>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> # HG changeset patch
> # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> # Date 1330065828 18000
> # Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
> # Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
> linux-xencommons: Load processor-passthru
> 
> The processor-passthru module is used in the upstream kernels
> to upload power management information to the hypervisor. We
> need to load it to work first.
Hmm, I don''t really like this (and prior) pvops-specific additions
here,
even if stderr gets directed into nowhere. I don''t think this (and any
other) script intended to target Linux in general should target just
a specific implementation.

Furthermore, given the purpose of the driver, I''m thinking that this
is too late in the boot process anyway, and the driver should rather
be loaded at the point where other CPUFreq drivers would normally
be by a particular distro (which would still be later than when the
respective code gets run on traditional Xenified Linux).

Jan
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff -r a34b652afb0c -r aa3a294327ed tools/hotplug/Linux/init.d/xencommons
> --- a/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 01:43:48 2012 -0500
> +++ b/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 01:43:48 2012 -0500
> @@ -58,6 +58,7 @@ do_start () {
>  	modprobe xen-gntdev 2>/dev/null
>  	modprobe evtchn 2>/dev/null
>  	modprobe gntdev 2>/dev/null
> +	modprobe processor-passthru 2>/dev/null
>  
>  	if ! `xenstore-read -s / >/dev/null 2>&1`
>  	then
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel

On Fri, Feb 24, 2012 at 10:44:54AM +0000, Jan Beulich
wrote:
> >>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> > # HG changeset patch
> > # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > # Date 1330065828 18000
> > # Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
> > # Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
> > linux-xencommons: Load processor-passthru
> > 
> > The processor-passthru module is used in the upstream kernels
> > to upload power management information to the hypervisor. We
> > need to load it to work first.
> 
> Hmm, I don''t really like this (and prior) pvops-specific additions
here,
> even if stderr gets directed into nowhere. I don''t think this (and
any
> other) script intended to target Linux in general should target just
> a specific implementation.
> 
> Furthermore, given the purpose of the driver, I''m thinking that
this
> is too late in the boot process anyway, and the driver should rather
> be loaded at the point where other CPUFreq drivers would normally
> be by a particular distro (which would still be later than when the
> respective code gets run on traditional Xenified Linux).
My thinking is to keep the amount of changes to be within the Xen-ecosystem.

Doing the changes in the old-fashioned way in drivers/acpi has not been
very productive - so I''ve been looking at just some form of uploading
the PM information to the hypervisor. And I''ve been piggybacking on
top of the cpufreq scaling drivers collecting the information. So with that 
in mind, the next idea I had was to provide a cpufreq governor, called
''xen''
which would inhibit the cpufreq scaling drivers from changing anything in dom0
(so that the hypervisor can do it instead). Also it would be responsible
for uploading the PM information to the hypervisor. See attached.

The fix to the tool-stack would be something along:
# HG changeset patch
# Parent 917f845f3e838dcc1efccb132abe2d1f254cb7b8

diff -r 917f845f3e83 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Thu Feb 23 13:29:00 2012 -0500
+++ b/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 21:42:20 2012 -0500
@@ -58,7 +58,7 @@ do_start () {
 	modprobe xen-gntdev 2>/dev/null
 	modprobe evtchn 2>/dev/null
 	modprobe gntdev 2>/dev/null
-
+	for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo xen
> $file; done 2>/dev/null
 	if ! `xenstore-read -s / >/dev/null 2>&1`
 	then
 		test -z "$XENSTORED_ROOTDIR" ||
XENSTORED_ROOTDIR="/var/lib/xenstored"


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

>>> On 27.02.12 at 02:46, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Feb 24, 2012 at 10:44:54AM +0000, Jan Beulich wrote:
>> >>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> > # HG changeset patch
>> > # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> > # Date 1330065828 18000
>> > # Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
>> > # Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
>> > linux-xencommons: Load processor-passthru
>> > 
>> > The processor-passthru module is used in the upstream kernels
>> > to upload power management information to the hypervisor. We
>> > need to load it to work first.
>> 
>> Hmm, I don''t really like this (and prior) pvops-specific
additions here,
>> even if stderr gets directed into nowhere. I don''t think this
(and any
>> other) script intended to target Linux in general should target just
>> a specific implementation.
>> 
>> Furthermore, given the purpose of the driver, I''m thinking
that this
>> is too late in the boot process anyway, and the driver should rather
>> be loaded at the point where other CPUFreq drivers would normally
>> be by a particular distro (which would still be later than when the
>> respective code gets run on traditional Xenified Linux).
> 
> My thinking is to keep the amount of changes to be within the
Xen-ecosystem.
> 
> Doing the changes in the old-fashioned way in drivers/acpi has not been
> very productive - so I''ve been looking at just some form of
uploading
> the PM information to the hypervisor. And I''ve been piggybacking
on
> top of the cpufreq scaling drivers collecting the information. So with that
> in mind, the next idea I had was to provide a cpufreq governor, called
''xen''
> which would inhibit the cpufreq scaling drivers from changing anything in 
> dom0
> (so that the hypervisor can do it instead). Also it would be responsible
> for uploading the PM information to the hypervisor. See attached.
> 
> The fix to the tool-stack would be something along:
> # HG changeset patch
> # Parent 917f845f3e838dcc1efccb132abe2d1f254cb7b8
> 
> diff -r 917f845f3e83 tools/hotplug/Linux/init.d/xencommons
> --- a/tools/hotplug/Linux/init.d/xencommons	Thu Feb 23 13:29:00 2012 -0500
> +++ b/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 21:42:20 2012 -0500
> @@ -58,7 +58,7 @@ do_start () {
>  	modprobe xen-gntdev 2>/dev/null
>  	modprobe evtchn 2>/dev/null
>  	modprobe gntdev 2>/dev/null
> -
> +	for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
echo xen > $file; done 2>/dev/null
While not an unreasonable idea (yes, I sort of contradict my other mail
from a few minutes ago, given your explanation above), this won''t work
with subsequently onlined vCPU-s (and hence, consistent with my other
mail, having the thing be a governor is likely the wrong choice - it ought
to be a driver).

Jan
>  	if ! `xenstore-read -s / >/dev/null 2>&1`
>  	then
>  		test -z "$XENSTORED_ROOTDIR" ||
XENSTORED_ROOTDIR="/var/lib/xenstored"

On 24/02/2012 10:38, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> # HG changeset patch
>> # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> # Date 1330065828 18000
>> # Node ID a34b652afb0ca484b7416008c95fd36ffbbea334
>> # Parent  a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
>> traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)
>> 
>> The restriction to read and write the AMD power management MSRs is
gated if
>> the
>> domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
>> relax this restriction and allow the privileged domain to read the MSRs
>> (but not write). This allows the priviliged domain to harvest the power
>> management information (ACPI _PSS states) and send it to the
hypervisor.
>> 
>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> 
>> diff -r a4d93d0e0df2 -r a34b652afb0c xen/arch/x86/traps.c
>> --- a/xen/arch/x86/traps.c Wed Feb 22 14:33:24 2012 +0000
>> +++ b/xen/arch/x86/traps.c Fri Feb 24 01:43:48 2012 -0500
>> @@ -2610,7 +2610,7 @@ static int emulate_privileged_op(struct
>>          case MSR_K8_PSTATE7:
>>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
>>                  goto fail;
>> -            if ( !is_cpufreq_controller(v->domain) )
>> +            if ( !is_cpufreq_controller(v->domain) &&
!IS_PRIV(v->domain) )
> 
> As said already in response to your Linux side overview mail, while
> I don''t view this as having potential to cause any problems, I
also
> don''t see the need.
> 
> And then if this indeed is wanted, replacing is_cpufreq_controller()
> by IS_PRIV() rather than adding the latter would seem preferable
> (because of being more strait forward).
Any response to this, Konrad?

 K.
> Jan
> 
>>              {
>>                  regs->eax = regs->edx = 0;
>>                  break;
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

>>> Furthermore, given the purpose of the driver, I''m thinking
that this
>>> is too late in the boot process anyway, and the driver should
rather
>>> be loaded at the point where other CPUFreq drivers would normally
>>> be by a particular distro (which would still be later than when the
In Ubuntu and Fedora they are set to:
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_ACPI_CPUFREQ=y

(thought previous to Fedora 16 POWERNOW_K8 was =m, per
https://bugzilla.redhat.com/show_bug.cgi?id=739159, " powernow-k8
transitions fail in xen dom0")

Looking at how the built is done with =y, the cpufreq drivers are loaded
in the late_init stage and there is a strict order (drivers/cpufreq/Makefile):
  # x86 drivers.
  # Link order matters. K8 is preferred to ACPI because of firmware
bugs in early
  # K8 systems. ACPI is preferred to all other hardware-specific drivers.
  # speedstep-* is preferred over p4-clockmod.

Both of them (acpi-cpufreq.c and powernow-k8.c) have a symbol
dependency on drivers/acpi/processor.c
>>> respective code gets run on traditional Xenified Linux).
>>
>> My thinking is to keep the amount of changes to be within the
Xen-ecosystem.
.. snip..
>> The fix to the tool-stack would be something along:
.. snip..
>> diff -r 917f845f3e83 tools/hotplug/Linux/init.d/xencommons
>> --- a/tools/hotplug/Linux/init.d/xencommons   Thu Feb 23 13:29:00 2012
-0500
>> +++ b/tools/hotplug/Linux/init.d/xencommons   Fri Feb 24 21:42:20 2012
-0500
>> @@ -58,7 +58,7 @@ do_start () {
>>       modprobe xen-gntdev 2>/dev/null
>>       modprobe evtchn 2>/dev/null
>>       modprobe gntdev 2>/dev/null
>> -
>> +     for file in
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo xen > $file;
done 2>/dev/null
>
> While not an unreasonable idea (yes, I sort of contradict my other mail
> from a few minutes ago, given your explanation above), this won''t
work
> with subsequently onlined vCPU-s (and hence, consistent with my other
This udev rule could do it? [completely untested]

ACTION=="add", SUBSYSTEM=="cpu", RUN+="/bin/sh -c
''[ ! -e
/sys$devpath/online ] || echo xen >
/sys$devpath/cpufreq/scaling_governor''"
> mail, having the thing be a governor is likely the wrong choice - it ought
> to be a driver).
>
By driver, I think you mean either a) a new cpufreq scaling driver, or
b) the processor-core driver.

The b) is what the old Xen-O-Linux tree had, and a simplified version
of this had been posted on LKML: https://lkml.org/lkml/2011/11/30/245
. There was no response from Len Brown about it and from the off-topic
email conversations I got the hint that Len wasn''t particularly
thrilled about it.

For a), this would mean some form of unregistering the existing
cpufreq scaling drivers.The reason
for that is we want to use the generic ones (acpi-cpufreq and
powernow-k8) b/c they do all the filtering and parsing of the ACPI
data instead of re-implementing it in our own cpufreq-xen-scaling.
Thought one other option is to export both powernow-k8 and
acpi-cpufreq functions that do this and use them within the
cpufreq-xen-scaling-driver but that sounds icky.

I think the "unregistering" would be akin to
"cpufreq_unregister_driver" but without any parameters.
However, we would be the only user of this mechanism and I am not sure
what Dave Jones feelings are about that (CC-ed here) Here is what I
was thinking (this is of course completely untested/uncompiled):

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 622013f..049fca9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1881,9 +1881,12 @@ int cpufreq_unregister_driver(struct
cpufreq_driver *driver)
 {
 	unsigned long flags;

-	if (!cpufreq_driver || (driver != cpufreq_driver))
+	if (!cpufreq_driver)
 		return -EINVAL;

+	if (!driver)
+		driver = cpufreq_driver;
+
 	pr_debug("unregistering driver %s\n", driver->name);

 	subsys_interface_unregister(&cpufreq_interface);

There would also be the need to do some tweaking of the order of drivers to load
(so that cpufreq-xen-scaling-driver gets loaded _after_ all of the
other ones). And I am afraid
about the scenario where a cpufreq-gov-X tries to set a specific
frequency and we yank it out
from within and might end up with a NULL pointer. But I think the
"cpufreq_driver_lock" inhibits that. The other thing that strikes me
as dangerous is that we don''t call the module_exit of the cpufreq
scaling driver.

While I was writing this up I thought about the overall picture.
Right now, the APIs work in this way:

[acpi processors] -> [cpufreq-scaling] <- [cpufreq-gov-*]

And we want to leverage them to do two things:
1). Inhibit cpufreq-gov-* telling cpufreq-scaling drivers what to do
[which is a bug
right now with Linux dom0 pvops - as the cpufreq-gov-* has no clue
about the other domains and might set the P states to something
incorrect]
2). Upload the power management information up to the hypervisor.

The 1) option can be either done by ignoring the WRMSR or outb in the hypervisor
(but for that we need 2) to know _which_ ones to inhibit). Or it can
be done by your
suggestion by introducing a cpufreq scaling driver that would nop all
calls and unregister
the other drivers. Or lastly by the cpufreq-gov-xen driver which would
leave it to the hypervisor to do it.

The 2). Can be done by either the proposed cpufreq-gov-xen, or the
earlier patch set I sent called processor-passthru
[https://lwn.net/Articles/483668/] which is a simple driver that
checks when cpufreq-scaling driver is loaded and then it upload the
power management data. It does nothing
with the cpufreq-[scaling|gov] APIs. Granted it does need a ''modprobe
processor-passthru'' in the xencommons to take advantage of the data -
and yes, it does deal with hot-cpu on lining.

Thoughts?

>>> On 05.03.12 at 03:49, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
>>>> Furthermore, given the purpose of the driver, I''m
thinking that this
>>>> is too late in the boot process anyway, and the driver should
rather
>>>> be loaded at the point where other CPUFreq drivers would
normally
>>>> be by a particular distro (which would still be later than when
the
> 
> In Ubuntu and Fedora they are set to:
> CONFIG_X86_POWERNOW_K8=y
> CONFIG_X86_ACPI_CPUFREQ=y
> 
> (thought previous to Fedora 16 POWERNOW_K8 was =m, per
> https://bugzilla.redhat.com/show_bug.cgi?id=739159, " powernow-k8
> transitions fail in xen dom0")
> 
> Looking at how the built is done with =y, the cpufreq drivers are loaded
> in the late_init stage and there is a strict order 
> (drivers/cpufreq/Makefile):
>   # x86 drivers.
>   # Link order matters. K8 is preferred to ACPI because of firmware
> bugs in early
>   # K8 systems. ACPI is preferred to all other hardware-specific drivers.
>   # speedstep-* is preferred over p4-clockmod.
> 
> Both of them (acpi-cpufreq.c and powernow-k8.c) have a symbol
> dependency on drivers/acpi/processor.c
But them being ''m'' or ''y'' shouldn''t
matter in the end.
>> mail, having the thing be a governor is likely the wrong choice - it
ought
>> to be a driver).
>>
> 
> By driver, I think you mean either a) a new cpufreq scaling driver, or
> b) the processor-core driver.
I really meant a).
> For a), this would mean some form of unregistering the existing
> cpufreq scaling drivers.The reason
Or loading before them (and not depending on them), thus
preventing them from loading successfully.
> for that is we want to use the generic ones (acpi-cpufreq and
> powernow-k8) b/c they do all the filtering and parsing of the ACPI
> data instead of re-implementing it in our own cpufreq-xen-scaling.
> Thought one other option is to export both powernow-k8 and
> acpi-cpufreq functions that do this and use them within the
> cpufreq-xen-scaling-driver but that sounds icky.
Indeed.
> 2). Upload the power management information up to the hypervisor.
Which doesn''t require cpufreq drivers at all (in non-pv-ops we simply
suppress the CPU_FREQ config option when XEN is set).

Jan

On Thu, Mar 01, 2012 at 04:33:42PM +0000, Keir Fraser
wrote:
> On 24/02/2012 10:38, "Jan Beulich" <JBeulich@suse.com>
wrote:
> 
> >>>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> >> # HG changeset patch
> >> # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >> # Date 1330065828 18000
> >> # Node ID a34b652afb0ca484b7416008c95fd36ffbbea334
> >> # Parent  a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
> >> traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)
> >> 
> >> The restriction to read and write the AMD power management MSRs is
gated if
> >> the
> >> domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we
can
> >> relax this restriction and allow the privileged domain to read the
MSRs
> >> (but not write). This allows the priviliged domain to harvest the
power
> >> management information (ACPI _PSS states) and send it to the
hypervisor.
> >> 
> >> Signed-off-by: Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>
> >> 
> >> diff -r a4d93d0e0df2 -r a34b652afb0c xen/arch/x86/traps.c
> >> --- a/xen/arch/x86/traps.c Wed Feb 22 14:33:24 2012 +0000
> >> +++ b/xen/arch/x86/traps.c Fri Feb 24 01:43:48 2012 -0500
> >> @@ -2610,7 +2610,7 @@ static int emulate_privileged_op(struct
> >>          case MSR_K8_PSTATE7:
> >>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
> >>                  goto fail;
> >> -            if ( !is_cpufreq_controller(v->domain) )
> >> +            if ( !is_cpufreq_controller(v->domain) &&
!IS_PRIV(v->domain) )
> > 
> > As said already in response to your Linux side overview mail, while
> > I don''t view this as having potential to cause any problems,
I also
> > don''t see the need.
> > 
> > And then if this indeed is wanted, replacing is_cpufreq_controller()
> > by IS_PRIV() rather than adding the latter would seem preferable
> > (because of being more strait forward).
> 
> Any response to this, Konrad?
Ah, lets drop this patch. Jan got me thinking about doing it in a much
nicer way without a need to do the MSRs.
> 
>  K.
> 
> > Jan
> > 
> >>              {
> >>                  regs->eax = regs->edx = 0;
> >>                  break;
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>