Hi, I recently subscribed to xen-users asking about a powernow-k8 problem, but in the meantime I am not sure if the users-list was the right place for it. So I decided to repeat my question here ;-) My current config is attached. --- snip --- Hi, I recently installed Xen on my AMD64 for my first time and so far, everything seems to work pretty fine. :-) I tried to enable cpu frequency support. After booting, I get the following message in Dom0-dmesg: powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.60.0) powernow-k8: BIOS error - no PSB or ACPI _PSS objects I tried to find answers in the mailing-list archive and with Google, but could not find answers. Is there support in Xen? Are there any patches, I can download anywhere? Would be really nice to get an answer Thanks in advance --- snap --- Kind regards Christian -- Tel.: 0641-2097252, Mobil: 0171-3611230 PGP: http://www.roessner-net.com/0x6B929997.asc _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11 Jun 2006, at 16:49, Christian Roessner wrote:> After booting, I get the following message in Dom0-dmesg: > > powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version > 1.60.0) > powernow-k8: BIOS error - no PSB or ACPI _PSS objects > > I tried to find answers in the mailing-list archive and with Google, > but > could not find answers. > > Is there support in Xen? Are there any patches, I can download > anywhere?Try adding cpufreq.debug=11 to your domain0 Linux kernel command line. That should get more debugging about what''s going wrong. Also, what does boot output look like for native Linux? Perhaps it''s possible to see where the cpufreq paths diverge for native versus running on Xen. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, I have activated debugging. The output is attached. dmesg.gz is the native kernel with debug enabled both others are self explaining ;-) ; also debug enabled Thanks in advance Keir Fraser schrieb:> > On 11 Jun 2006, at 16:49, Christian Roessner wrote: > >> After booting, I get the following message in Dom0-dmesg: >> >> powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.60.0) >> powernow-k8: BIOS error - no PSB or ACPI _PSS objects >> >> I tried to find answers in the mailing-list archive and with Google, but >> could not find answers. >> >> Is there support in Xen? Are there any patches, I can download anywhere? > > Try adding cpufreq.debug=11 to your domain0 Linux kernel command line. > That should get more debugging about what''s going wrong. Also, what does > boot output look like for native Linux? Perhaps it''s possible to see > where the cpufreq paths diverge for native versus running on Xen. > > -- Keir > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Tel.: 0641-2097252, Mobil: 0171-3611230 PGP: http://www.roessner-net.com/0x6B929997.asc _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11 Jun 2006, at 20:48, Christian Roessner wrote:> I have activated debugging. The output is attached. > > dmesg.gz is the native kernel with debug enabled > both others are self explaining ;-) ; also debug enabledEdit source file arch/i386/kernel/cpu/cpufreq/powernow-k8.c and change use of phys_to_virt() to isa_bus_to_virt(). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi,
it seems that the change did work partially. But the frequency can not
be changed.
The kernel freezes when udev is loading the alsa modules and/or the
nvidia module. After that the machine may reboot automatically.
Here some infos I found in my /var/log/messages file:
==== Example 1 ===Jun 12 01:54:02 desktop kernel: NVRM: Trying to sleep during
raised irql!!
Jun 12 01:54:02 desktop kernel: NVRM: are we holding a lock?
Jun 12 01:54:02 desktop kernel: NVRM: skipping os_delay
Jun 12 01:54:02 desktop kernel: NVRM: Trying to sleep during raised irql!!
Jun 12 01:54:02 desktop kernel: NVRM: are we holding a lock?
Jun 12 01:54:02 desktop kernel: NVRM: skipping os_delay
Jun 12 01:54:02 desktop kernel: NVRM: Trying to sleep during raised irql!!
Jun 12 01:54:02 desktop kernel: NVRM: are we holding a lock?
Jun 12 01:54:02 desktop kernel: NVRM: skipping os_delay
==== Example 2 ===Jun 12 01:57:48 desktop kernel: NVRM: loading NVIDIA Linux x86
Kernel
Module 1.0-8762 Mon May 15 13:06:38 PDT 2006
Jun 12 01:57:48 desktop kernel: Modules linked in: snd_emu10k1
snd_rawmidi snd_ac97_codec snd_ac97_bus nvidia snd_pcm_oss snd_mixer_oss
ohci1394 snd_pcm snd_seq_device ieee1394 snd_timer snd_page_alloc
snd_util_mem b1pci b1 snd_hwdep kernelcapi snd i2c_nforce2 ehci_hcd
ohci_hcd soundcore usbcore i2c_core forcedeth evdev
Jun 12 01:57:48 desktop kernel: EIP: 0061:[<ec84fa5a>] Tainted: P
VLI
Jun 12 01:57:48 desktop kernel: EFLAGS: 00010082 (2.6.16.20-4 #1)
==== Example 3 ===Jun 12 02:11:21 desktop kernel: NVRM: loading NVIDIA Linux x86
Kernel
Module 1.0-8762 Mon May 15 13:06:38 PDT 2006
Jun 12 02:11:21 desktop kernel: Modules linked in: nvidia parport_pc lp
parport capi capifs xt_tcpudp ip6table_filter ip6_tables xt_state
xt_pkttype iptable_raw xt_CLASSIFY xt_connmark xt_physdev xt_conntrack
iptable_mangle ipt_ULOG ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_TCPMSS
ipt_SAME ipt_REJECT ipt_REDIRECT ipt_recent ipt_policy ipt_owner
ipt_NETMAP ipt_multiport ipt_MASQUERADE ipt_LOG ipt_iprange
ipt_hashlimit ipt_esp ipt_ECN ipt_ecn ipt_DSCP ipt_dscp ipt_CLUSTERIP
ipt_ah ipt_addrtype ip_nat_irc ip_nat_tftp ip_nat_ftp ip_conntrack_irc
ip_conntrack_tftp ip_conntrack_ftp iptable_nat ip_nat ip_conntrack
nfnetlink iptable_filter ip_tables x_tables zaurus usbhid md5 ipv6
cdc_ether usbnet it87 hwmon_vid lm90 hwmon eeprom i2c_isa saa7134
video_buf compat_ioctl32 v4l1_compat ir_kbd_i2c ir_common videodev tuner
v4l2_common tda9887 b1pci b1 kernelcapi ohci1394 ieee1394 ehci_hcd
ohci_hcd usbcore forcedeth i2c_nforce2 i2c_core evdev
Jun 12 02:11:21 desktop kernel: EIP: 0061:[<ecab9a5a>] Tainted: P
VLI
Jun 12 02:11:21 desktop kernel: EFLAGS: 00010082 (2.6.16.20-4 #1)
Jun 12 02:11:55 desktop exiting on signal 15
So it seems that the nvidia driver has some problems with this code
modification??
Attached the last dmesg output. You my look at the end of this file
Thanks in advance
Christian
Keir Fraser schrieb:>
> On 11 Jun 2006, at 20:48, Christian Roessner wrote:
>
>> I have activated debugging. The output is attached.
>>
>> dmesg.gz is the native kernel with debug enabled
>> both others are self explaining ;-) ; also debug enabled
>
> Edit source file arch/i386/kernel/cpu/cpufreq/powernow-k8.c and change
> use of phys_to_virt() to isa_bus_to_virt().
>
> -- Keir
>
--
Tel.: 0641-2097252, Mobil: 0171-3611230
PGP: http://www.roessner-net.com/0x6B929997.asc
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 12 Jun 2006, at 01:26, Christian Roessner wrote:> it seems that the change did work partially. But the frequency can not > be changed.Ah yes, I have some patches for this that are waiting to get merged into the tree.> The kernel freezes when udev is loading the alsa modules and/or the > nvidia module. After that the machine may reboot automatically.Has this started since you made my suggested patch? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> On 11 Jun 2006, at 20:48, Christian Roessner wrote: > > > I have activated debugging. The output is attached. > > > > dmesg.gz is the native kernel with debug enabled both > others are self > > explaining ;-) ; also debug enabled > > Edit source file arch/i386/kernel/cpu/cpufreq/powernow-k8.c > and change use of phys_to_virt() to isa_bus_to_virt().Is this a change that needs to made in the mainstream driver? It''s only called in the legacy PSB code, and AMD is deprecating support for PSB on newer processors. -Mark Langsdorf AMD, Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12 Jun 2006, at 17:00, Langsdorf, Mark wrote:>> Edit source file arch/i386/kernel/cpu/cpufreq/powernow-k8.c >> and change use of phys_to_virt() to isa_bus_to_virt(). > > Is this a change that needs to made in the mainstream > driver? It''s only called in the legacy PSB code, and > AMD is deprecating support for PSB on newer processors.It can be assessed when we actually support Powernow in Xen. As you say this is legacy code anyway, so we may not care so much (depends when it became legacy?). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> On 12 Jun 2006, at 17:00, Langsdorf, Mark wrote: > > >> Edit source file arch/i386/kernel/cpu/cpufreq/powernow-k8.c > >> and change use of phys_to_virt() to isa_bus_to_virt(). > > > > Is this a change that needs to made in the mainstream driver? It''s > > only called in the legacy PSB code, and AMD is deprecating > support for > > PSB on newer processors. > > It can be assessed when we actually support Powernow in Xen. > As you say this is legacy code anyway, so we may not care so > much (depends when it became legacy?).Older laptops support it. New laptops, sometimes but not often. It will not be part of the BIOS/UEFI for processors by 2008. No multiprocessor system has it. So it''s support for some amount of the installed base, but I don''t know how much. -Mark Langsdorf AMD, Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Keir Fraser schrieb:> > On 12 Jun 2006, at 17:00, Langsdorf, Mark wrote: > >>> Edit source file arch/i386/kernel/cpu/cpufreq/powernow-k8.c >>> and change use of phys_to_virt() to isa_bus_to_virt(). >> >> Is this a change that needs to made in the mainstream >> driver? It''s only called in the legacy PSB code, and >> AMD is deprecating support for PSB on newer processors. > > It can be assessed when we actually support Powernow in Xen. As you say > this is legacy code anyway, so we may not care so much (depends when it > became legacy?).Well, I thought there would be outstanding patches which actually fix the problems. Did I missunderstand this? (I am from Germany. Maybe some problems in understanding). If I did -not- missunderstand, can you send me this code, so I may test this here? Thanks Christian> -- Keir > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Tel.: 0641-2097252, Mobil: 0171-3611230 PGP: http://www.roessner-net.com/0x6B929997.asc _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12 Jun 2006, at 17:58, Christian Roessner wrote:> Well, I thought there would be outstanding patches which actually fix > the problems. Did I missunderstand this? (I am from Germany. Maybe some > problems in understanding). > > If I did -not- missunderstand, can you send me this code, so I may test > this here?It''s back in the xen-devel archives: http://lists.xensource.com/archives/html/xen-devel/2006-04/msg00484.html -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> It''s back in the xen-devel archives: > > http://lists.xensource.com/archives/html/xen-devel/2006-04/msg00484.html >One question for patch xen-cpufreq-amd-powernow-k8.diff What about line number 140 + __update_vcpu_system_time(current); This makes trouble while trying to compile (implicit decalaration of function...). As I could read in the Changelog, this was removed sometime ago. changeset: 9644:8821da562fe0 user: kaf24@firebug.cl.cam.ac.uk date: Sat Apr 22 10:29:27 2006 +0100 summary: Remove update_vcpu_system_time() call from the per-VCPU timer Do I also need one of these patches: cpufreq-xen-dom0-func.diff cpufreq-xen-linux-2.6.16.diff I tested only the first patch. To get the xen-3.0-3.0.2+hg9681 compiled, I commented out the line shown above. The system seems to start and powernow-k8 seems to work. But something still seems to be wrong, because the nvidia driver crashes and it does not crash with the same kernel in native linux mode (Not booted in xen). I attached the nvidia dump. Maybe you could have a look at this :-) At the moment of this writing, I only can use the nv driver and this one only supports 1024x768, so this is not really funny on an 19" LCD ;-) But so far, thanks very much. I hope you still may/want to help me with this issue. Christian -- Tel.: 0641-2097252, Mobil: 0171-3611230 PGP: http://www.roessner-net.com/0x6B929997.asc _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13 Jun 2006, at 09:49, Christian Roessner wrote:> One question for patch > > xen-cpufreq-amd-powernow-k8.diff > > What about line number > > 140 + __update_vcpu_system_time(current); > > This makes trouble while trying to compile (implicit decalaration of > function...). As I could read in the Changelog, this was removed > sometime ago.You do want that line. Remove ''static inline'' modifiers from the function definition in arch/x86/time.c. As for your nvidia driver crashes: where do you get that driver from? Is it binary-only? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> 140 + __update_vcpu_system_time(current); >> >> This makes trouble while trying to compile (implicit decalaration of >> function...). As I could read in the Changelog, this was removed >> sometime ago. > > You do want that line. Remove ''static inline'' modifiers from the > function definition in arch/x86/time.c.The problem is that the line containing __update_vcpu_system_time(current); is the only one inside the whole source directory. desktop xen-3.0-3.0.2+hg9681 # grep -R __update_vcpu_system_time * xen/arch/x86/time.c: __update_vcpu_system_time(current); xen-cpufreq-amd-powernow-k8.diff:+ __update_vcpu_system_time(current); The function itself does not have modifieres static inline: 999 int handle_k8_fidvid_ctl_msr_write(u32 lo, u32 hi) {> As for your nvidia driver crashes: where do you get that driver from? Is > it binary-only?Some parts of the driver are binary only, some not. Unfortunatley the source part is licenced under NVIDIA stuff. If this is _REALLY_ a nvidia problem, I could paste the dump to NView forum and ask the nvidia developers for help with the nvidia driver (But I guess, I will not get help there).> -- Keir >-- Tel.: 0641-2097252, Mobil: 0171-3611230 PGP: http://www.roessner-net.com/0x6B929997.asc _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13 Jun 2006, at 10:24, Christian Roessner wrote:> Some parts of the driver are binary only, some not. Unfortunatley the > source part is licenced under NVIDIA stuff. > > If this is _REALLY_ a nvidia problem, I could paste the dump to NView > forum and ask the nvidia developers for help with the nvidia driver > (But > I guess, I will not get help there).It really depends what is hidden inside the binary-only portion. If they try to enable/disable interrupts in there, for example, then the driver is going to be unreliable. If they provide accessors for that kind of operation in their ''open source'' wrapper, then that shouldn''t be a problem as they will link against the versions modified for Xen. Looking at the functions exported by the source wrapper might give you a clue, or try ''objdump -d'' on the binary-only portion and grep for things like cli, sti and popf. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi,> It really depends what is hidden inside the binary-only portion. If they > try to enable/disable interrupts in there, for example, then the driver > is going to be unreliable. If they provide accessors for that kind of > operation in their ''open source'' wrapper, then that shouldn''t be a > problem as they will link against the versions modified for Xen. Looking > at the functions exported by the source wrapper might give you a clue, > or try ''objdump -d'' on the binary-only portion and grep for things like > cli, sti and popf.I searched around inside the NVidia forum and I found 2 patches, which I applied to the hypervisor and to nv.c. Now, CPUfreq is working fine here and I successfully use the nvidia driver. I have attached both patches. Maybe someone else may have the same problem, so in this thread he/she may find all neccessary info, whatever. Only one thing left ist the problem with the line line 1058 /* __update_vcpu_system_time(current); */ But everything is working with this solution. What should this be for? I have noticed one other interesting thing with Xen: openVPN is nomore able to initialize any tunnels. Does this have something to do with the __update_vcpu_system_time function? Kind regards Christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13 Jun 2006, at 13:20, Christian Roessner wrote:> I searched around inside the NVidia forum and I found 2 patches, which > I > applied to the hypervisor and to nv.c. Now, CPUfreq is working fine > here > and I successfully use the nvidia driver. I have attached both patches. > Maybe someone else may have the same problem, so in this thread he/she > may find all neccessary info, whatever.I''m surprised the nvidia driver works at all without this patch.> Only one thing left ist the problem with the line > > line 1058 /* __update_vcpu_system_time(current); */ > > But everything is working with this solution. What should this be for?Time may temporarily run at the incorrect rate for a short while (less than a second). It''s not that critical.> I have noticed one other interesting thing with Xen: openVPN is nomore > able to initialize any tunnels. Does this have something to do with the > __update_vcpu_system_time function?No. That''s just weird. I wouldn''t expect this to have any effect on openVPN. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser schrieb:> > On 13 Jun 2006, at 13:20, Christian Roessner wrote: > >> I searched around inside the NVidia forum and I found 2 patches, which I >> applied to the hypervisor and to nv.c. Now, CPUfreq is working fine here >> and I successfully use the nvidia driver. I have attached both patches. >> Maybe someone else may have the same problem, so in this thread he/she >> may find all neccessary info, whatever. > > I''m surprised the nvidia driver works at all without this patch.Without which patch?? The nvidia driver is patched.>> I have noticed one other interesting thing with Xen: openVPN is nomore >> able to initialize any tunnels. Does this have something to do with the >> __update_vcpu_system_time function? > > No. That''s just weird. I wouldn''t expect this to have any effect on > openVPN.Well, the tunnel(s) hangs with problems in TLS negotiation. I do absolutley not know, if this is timeing critical stuff. I attahced my time.c. Could you have a look at line 1058 and give me a hint what to change to get this fixed? Would be really nice. Thanks Christian -- Tel.: 0641-2097252, Mobil: 0171-3611230 PGP: http://www.roessner-net.com/0x6B929997.asc _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, The problem with OpenVPN is fixed. It was not a problem with Xen. The router did not forward a Port. Sorry with this issue. Thanks Christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13 Jun 2006, at 15:12, Christian Roessner wrote:>>> I searched around inside the NVidia forum and I found 2 patches, >>> which I >>> applied to the hypervisor and to nv.c. Now, CPUfreq is working fine >>> here >>> and I successfully use the nvidia driver. I have attached both >>> patches. >>> Maybe someone else may have the same problem, so in this thread >>> he/she >>> may find all neccessary info, whatever. >> >> I''m surprised the nvidia driver works at all without this patch. > > Without which patch?? The nvidia driver is patched.I mean, before you fiddled with powernow at all, you claim that the nvidia driver worked just fine for you. And presumably you were running at that time without the patch. I''m surprised it worked for you at that point. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I mean, before you fiddled with powernow at all, you claim that the > nvidia driver worked just fine for you. And presumably you were running > at that time without the patch. I''m surprised it worked for you at that > point.One big problem I had was that a friend of mine configured my system for the first use with xen. He is able to hack thousands commands and you can not follow all of them :-) Maybe he had patched the nvidia driver once before, but I could not find any saved patches. Only those for the hypervisor. I had much work to clean up the machine in /usr/src and /usr/local/src. Okay, at the end, I needed some patches from you and the CPUfreq stuff now is working. I thank you very much for your help and your hints. If you find some time to look for the time.c file, I also would be happy. Will all these patches (concerning powernow-k8) merge into stable Xen-source? Regards Christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13 Jun 2006, at 15:57, Christian Roessner wrote:> Will all these patches (concerning powernow-k8) merge into stable > Xen-source?It''s in my todo list. There''s actually not much to be done I think. I was happy to take the patch mostly as-is and clean it up later. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13 Jun 2006, at 15:12, Christian Roessner wrote:> I attahced my time.c. Could you have a look at line 1058 and give me a > hint what to change to get this fixed? Would be really nice.The function''s called __update_dom_time() in that version of the file, not __update_vcpu_time(). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > Well, I thought there would be outstanding patches which > actually fix > > the problems. Did I missunderstand this? (I am from Germany. Maybe > > some problems in understanding). > > > > If I did -not- missunderstand, can you send me this code, so I may > > test this here? > > It''s back in the xen-devel archives: > > http://lists.xensource.com/archives/html/xen-devel/2006-04/msg00484.html Should I (as the powernow-k8 maintainer) be modifying this code as we add new features? Most of it looks pretty safe, but the new 2.00.00 driver uses different MSRs, and there are other things coming up that will confuse things. -Mark Langsdorf AMD, Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 14 Jun 2006, at 22:43, Langsdorf, Mark wrote:> Should I (as the powernow-k8 maintainer) be modifying this > code as we add new features? Most of it looks pretty safe, > but the new 2.00.00 driver uses different MSRs, and there > are other things coming up that will confuse things.One thing I''m a bit undecided on is whether MSR emulation is the right way to go, or whether we should just pull the low-level cpufreq drivers verbatim into Xen and then provide access to them via hypercalls. We could then have a paravirtual cpufreq driver added to Linux. This has the advantage that we have less new per-cpu-type code to maintain in Xen (we can more easily sync with cpufreq changes in Linux) but it does mean we change more Linux code and we''d want to be a bit careful not to make the hypercall interface too Linux specific (or too x86 specific). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser schrieb:> > On 14 Jun 2006, at 22:43, Langsdorf, Mark wrote: > >> Should I (as the powernow-k8 maintainer) be modifying this >> code as we add new features? Most of it looks pretty safe, >> but the new 2.00.00 driver uses different MSRs, and there >> are other things coming up that will confuse things. > > One thing I''m a bit undecided on is whether MSR emulation is the right > way to go, or whether we should just pull the low-level cpufreq drivers > verbatim into Xen and then provide access to them via hypercalls. We > could then have a paravirtual cpufreq driver added to Linux. This has > the advantage that we have less new per-cpu-type code to maintain in Xen > (we can more easily sync with cpufreq changes in Linux) but it does mean > we change more Linux code and we''d want to be a bit careful not to make > the hypercall interface too Linux specific (or too x86 specific).Has this something to do with the private mail I sent to Keir Fraser? I told him that the powernow-k8 support in dom0 seems to work, while in domUs not. Second was that the shown Bogomips under /proc/cpuinfo never changes from ~4000, even when the CPU was @ 800. Regards Christian -- Tel.: 0641-2097252, Mobil: 0171-3611230 PGP: http://www.roessner-net.com/0x6B929997.asc _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15 Jun 2006, at 10:58, Christian Roessner wrote:>> One thing I''m a bit undecided on is whether MSR emulation is the right >> way to go, or whether we should just pull the low-level cpufreq >> drivers >> verbatim into Xen and then provide access to them via hypercalls. We >> could then have a paravirtual cpufreq driver added to Linux. This has >> the advantage that we have less new per-cpu-type code to maintain in >> Xen >> (we can more easily sync with cpufreq changes in Linux) but it does >> mean >> we change more Linux code and we''d want to be a bit careful not to >> make >> the hypercall interface too Linux specific (or too x86 specific). > > Has this something to do with the private mail I sent to Keir Fraser? > > I told him that the powernow-k8 support in dom0 seems to work, while in > domUs not. Second was that the shown Bogomips under /proc/cpuinfo never > changes from ~4000, even when the CPU was @ 800.That''s a quite separate issue. The ''stale'' frequency info in domU is harmless. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel