Sriram,
Sorry for not replying before. The response is fairly lengthy and may be
more generally useful so I've cc'ed it to the xen-devel list.
Yes, you have a number of issues to tackle to get this to work reliably.
Your approach will depend on what exactly it is you hope to achieve: for
example, a reliable general solution for cpufreq on Xen which may be
considered for inclusion in the tree, or perhaps as part of a larger
research project in which shortcuts are reasonable as a means to a greater
end?
The problems you are seeing are due to a number of reasons:
1. DOM0_MSR is no longer supported -- we now emulate MSR reads and writes.
BUT:
2. We whitelist writable MSRs in emulate_privileged_op() in
xen/arch/x86/traps.c. You will need to add your MSR(s) to the switch
statement. ALSO:
3. The emulation happens on the very physical CPU you happen to be running
on. This may not be the CPU you want it to happen on! This can be solved by
using the dom0_vcpus_pin argument to Xen, which will pin VCPUs 1:1 onto
PCPUs. This is desirable anyway as it will mean that per-cpu sysfs
interfaces will be present for every PCPU (which they obviously wouldn't if,
for example, dom0 were uniprocessor).
4. No topology information is exported to any guest. There is a more
general demand for this from vendors of NUMA systems. You could statically
hack round this depending on your needs, but it's obviously not a real
solution.
5. Even if you do change the frequency on the right CPU, Xen needs to be
told that this has happened immediately as the TSC will change rate and we
rely on that heavily for timekeeping. Xen will get back on track within a
few seconds but things may go a bit haywire in the meantime!
My current preferred strategy for power management is to implement a daemon
in dom0. This will make use of Intel's acpica package, or wholesale steal
drivers/acpi from Linux, and use this code to parse the ACPI processor
objects to find out dependencies among processors and to find out which
IO-port or MSR must be poked to change frequency. An interface will need to
be added to Xen to allow notifications of time changes. A further interface
will be needed to specify that a particular piece of code is executed on a
particular set of CPUs (needed to execute the MSR or IO-port access in ring0
on the right CPUs). This latter interface can also be used to execute CPUID
on every CPU in turn and find out the correspondence between ACPI processors
and Xen cpu ids.
This userspace implementation requires a bit of heavy lifting but sounds
like a fun project for a hacker with some previous experience. To my mind it
is also a more viable long-term strategy than relying on dom0 kernel to do
the right thing (requiring dom0_vcpus_pin in all environments being somewhat
undesirable).
If you dig into this then do keep me (and the list) in the loop.
Good Luck!
Keir
On 22/4/07 14:52, "Sriram Govindan" <sgovinda@xxxxxxxxxxx> wrote:
> Hi,
>
> I am working on Xen as part of my research project. I had already posted
> this in the Xen devel group 2 days back, didn't get any response. My
> advisor suggested mailing you in person.
>
> My story goes as follows,
>
> I installed the latest version of xen (3.0.4_1). I used userspace governor
> to change frequency of my xeon dual processor SMT. The driver used is
> p4-clockmod.
>
> Changes to the frequency (through the /sys interface) is not getting
> reflected to the hardware, even though the /sys interface reports the
> change. From previous posts, i understand that rdmsr
> and wrmsr (since being silently ignored) has to be replaced with dom0_msr
> operations. Even after this modification (patch), still the frequency is not
> getting changed and the
> domain0 hypercall is returning a negative value when reads and writes are
> made to the dom0_msr.
>
> Also, In xen, SMT seems to have some problems. cpumask (affected cpus)
> does not seem to include the hyperthread (atleast as seen by the CPU
> frequency drivers).
>
> Sorry for emailing you in person, i really didn't have an option.
>
> Thank you,
>
> Regards,
> Sriram.G,
> www.cse.psu.edu/~sgovinda
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home