Xen project Mailing List

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

On Wed, Sep 10, 2014 at 1:15 PM, Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx> wrote:

Hi,

>> In case where dom0 has more vcpus than pcpus on the
>> system, the dom0 kernel is the most bug-prone place for pcpu cpufreq governor. So I still believe that separate driver
>> domain with direct 1:1 vcpu:pcpu mapping is the best place for cpufreq governor. But it also reasonable to run cpufreq
>> governor as userspace daemon in dom0.
>>
>> Also what do you think about PM QoS support? On bare metal cpufreq is tightly integrated with PM QoS and intensively
>> cooperate in frequency scaling.
>
> Device PM needs to be done in Dom0.
> CPU an Platform level PM architecturally belongs to Xen, but I do
> understand that to do that in Xen we would need to add lots of code to
> the hypervisor. There is no silver bullet here.
>
> A driver domain with 1:1 vcpu:pcpu mapping could work, but what kernel
> are you going to use for that? Linux? Wouldn't Linux be too big for a
> cpufreq driver domain, especially in embedded deployments? I think it
> would need at least 32MB to run.
>

I would suggest not to do this. Driver domain will need to share the
same HW with dom0, which is impossible to implement. Good examples are
I2C, which is needed for Display and for Cpufreq, and it cannot be
shared between domains. (At least in current Linux kernel it won't be
easy to implement). dom0 is the best place to do cpufreq.

Also how do you feel about providing virtualized i2c from driver domain to dom0?

Regards,
Andrii

--

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

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

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