Re: [Xen-devel] FAILED/MISSING cstate/cpufreq/cpupower support with Xen 4.13 + kernel 5.4.14; withOUT xen/hypervisor, WORKS. bug or config?

[Jürgen Groß <jgross@xxxxxxxx>]

On 30.01.20 09:18, Jan Beulich wrote:
> On 29.01.2020 20:29, PGNet Dev wrote:
> > with xen cmd line opts reduced to
> >
> >         options=dom0_max_vcpus=4 dom0_mem=4016M,max:4096M loglvl=all 
> > guest_loglvl=all noreboot=false sync_console=true sched_debug iommu=verbose 
> > apic_verbosity=verbose
> >
> > still no freq data/control
> Sure, there was no suggestion that the command line options would
> affect this. It was just that there were so many options that it
> was hard to see what you actually want to achieve. There are still
> pointless options above: noreboot=false is the default anyway. The
> last three options also shouldn't be strictly needed. Then again
> it is unclear (because of ...
>
> > and,
> >
> > xl dmesg
> >         (XEN)  0000000092118000 - 000000009213c000 (usable)
> ... the log being cur off at the beginning, whether you use a
> debug or release hypervisor. For figuring out issues, it is
> generally helpful (advisable) to use the debug variant. If you're
> using openSUSE and xen.efi, this may mean you need to build you
> own, though.
>
> In any event - does this log cover the (failed) attempt to
> load the xen-acpi-processor driver? If not, please provide one
> which does. It is the loading of that driver which is crucial
> for P-state control to start working in Xen, as - other than
> for C-states on halfway modern CPUs - Xen depends on Dom0 to
> upload relevant data obtained from ACPI tables.
I'd like to request you adding the dom0 kernel boot parameters, too:

debug initcall_debug

This should give us a clue whether there was a try to call the driver
at all and when this did happen and with what result.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel