Xen project Mailing List

Hi All,

On Tue, Sep 2, 2014 at 4:00 AM, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote:

On Fri, 29 Aug 2014, Andrii Tseglytskyi wrote:
> Hi,
>
> Stefano, Ian,
>
> Could you please clarify the following point:
>
> I agree that decision about frequency change should be taken by Xen
> hypervisor. But what about hardware frequency changing?
> In general when frequency changed to bigger value (for example from 1
> GHz to 1.5 GHz) for ARM kernels sequence looks like the following:
>
> 1) cpufreq governor decides that frequency should be changed. This
> decision is taken after analysing of CPU performance data taking in
> account governor policy.
> 2) cpufreq governor asks cpufreq driver about new frequency.
> 3) cpufreq driver compares current and target frequencies and asks
> cpufreq regulator about voltage change.
> 4) cpufreq regulator send i2c command to standalone microchip, which
> is responsible for voltage changing.
> 5) cpufreq driver asks clock framework about new frequency for CPU clock
> 6) clock framework performs frequency sanity checks, taking in account
> clock parents and clock divider settings, and call platform specific
> "set_frequency" callback.
> 7) platform specific callback performs proper HW registers
> configuration for newly selected frequency
>
> Also there are some special cases - for example for OMAP5+ when
> frequency is changed to 1.5 GHz+, two additional HW IPs should be
> triggered (ABB and DCC, if someone is familiar with OMAP5+ )
>
> So, for generic ARM kernel we have 3 entities to change frequency:
>
> - cpufreq governor
> - cpufreq driver
> - cpufreq regulator
>
> + 2 additional IP for OMAP5+
> - ABB
> - DCC
>
> Taking in account all above, it looks like it would be better to
> implement only Xen cpufreq governor. Xen will take a decision about
> new frequency, and kernel dom0 will perform other steps. Dom0 contains
> all generic and platform specific frameworks, needed for frequency
> changing.
>
> What do you think ?

Keep in mind that the architecture must be able to handle the case where
dom0 has only 1 or 2 vcpus on a 4 or 8 cores system with multiple
physical cpus.
Could dom0 change the frequency of a physical core or a physical cpu is
not even running on? If that is not a problem, because cpus and
frequency changing are decoupled enough in Linux to allow it, then I am
OK with it. But I suspect they are not.

Andrii's idea is reasonable because dom0 kernel already has enough knowledge about physical hardware. But from opposite side frameworks mentioned by Andrii don't have knowledge about vcpu and other virtualized HW. So i'm still doubt than dom0 linux kernel is appropriate place for introducing this functionality.

With best regards,

> Regards,
> Andrii
>
>
> On Fri, Aug 29, 2014 at 4:25 PM, Oleksandr Dmytryshyn
> <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx> wrote:
> > On Fri, Aug 22, 2014 at 7:31 PM, Stefano Stabellini
> > <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> >> On Fri, 22 Aug 2014, Oleksandr Dmytryshyn wrote:
> >>> Hi, Stefano.
> >>>
> >>> On Fri, Aug 22, 2014 at 2:31 AM, Stefano Stabellini
> >>> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> >>> > CC'ing the x86 maintainers and the cpufreq original author.
> >>> >
> >>> >
> >>> > On Thu, 21 Aug 2014, Oleksandr Dmytryshyn wrote:
> >>> >> Hi to all.
> >>> >>
> >>> >> I'm planning to do next work:
> >>> >>
> >>> >> 1. Move file xen/include/acpi/cpufreq/cpufreq.h to the
> >>> >> xen/include/drivers/cpufreq/cpufreq.h
> >>> >> 2. Create a new file xen/arch/x86/acpi/cpufreq/cpufreq_common.c
> >>> >
> >>> > you can call it cpufreq.c or cpufreq_ops.c
> >>> I'll call it cpufreq_ops.c
> >>>
> >>> >> 3. Move some acpi-specific functions from
> >>> >> xen/drivers/cpufreq/cpufreq.c to the
> >>> >> xen/arch/x86/acpi/cpufreq/cpufreq_common.c:
> >>> >> cpufreq_limit_change(), print_PCT(), print_PSS(), print_PSD(),
> >>> >> print_PPC(), set_px_pminfo().
> >>> >
> >>> > Why cpufreq_limit_change?
> >>> The function cpufreq_limit_change() is called only in the set_px_pminfo()
> >>> function and will not be used for the ARM architecture.
> >>
> >> I see.
> >> One thing to keep in mind is that although P states are obviously an
> >> Intel concept, we could abstract them away and map them into
> >> arch-independent power-saving states. That way we could share functions
> >> like set_px_pminfo between ARM and x86. But I would have to see the
> >> patches to actually know how feasible that is.
> > Here is my RFC implementation:
> > http://lists.xen.org/archives/html/xen-devel/2014-08/msg02919.html
> >
> >>> >> 4. Create a new file xen/arch/arm/cpufreq/cpufreq_common.c
> >>> >> 5. Functions cpufreq_add_cpu()/cpufreq_del_cpu() should be implemented
> >>> >> separately for the x86 and ARM architecture (in the correspond file
> >>> >> cpufreq_common.c).
> >>> >
> >>> > Why? The implementation doesn't look x86 specific.
> >>> The function cpufreq_add_cpu()/cpufreq_del_cpu() uses the acpi-specific
> >>> data structures. I don't know how make them common for both architectures
> >>> but I'll try to do this.
> >>>
> >>> >> 6. Port cpufreq driver for the OMAP from the Linux kernel.
> >>> >>
> >>> >> In case ARM the cpufreq driver will read the settings for the
> >>> >> operating-points from the device tree and the
> >>> >> XENPF_set_processor_pminfo platform hypercall will not be necessary
> >>> >> for ARM.
> >>> >>
> >>> >> Is this the right way to implement the cpufreq for OMAP under xen hypervisor?
> >>> >
> >>> > Yes, it's more or less what I had in mind.
> >>>
> >>> I have a question. I see that the original file cpufreq.c contains
> >>> 'Copyright (C)' fields. Could You please tell me which copyrights I should add
> >>> to the new cpufreq_ops.c files (for x86 and ARM arhitectures).
> >>> In case if cpufreq_add_cpu()/cpufreq_del_cpu() functions will be common for both
> >>> architectures there will be only one cpufreq_ops.c file for x86 architecture.
> >>> But there is a way when we will have two files file cpufreq_ops.c (for
> >>> x86 and ARM).
> >>
> >> I would keep the current Copyright fields for the x86 implementation of
> >> cpufreq_ops.c. You can use your own Copyright line for the ARM
> >> implementation.
> >
> >
> > --
> > Oleksandr Dmytryshyn | Product Engineering and Development
> > GlobalLogic
> > M +38.067.382.2525
> > www.globallogic.com
> >
> > http://www.globallogic.com/email_disclaimer.txt
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
>
>
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
>

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

Vitaly Chernooky |ÂSenior Developer - Product Engineering and Development

GlobalLogic

P +380.44.4929695 ext.1136 M +380.98.7920568 S cvv_2k

www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

Re: [Xen-devel] cpufreq implementation for OMAP under xen hypervisor.