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

[Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx>]

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.

Regards,
Andrii


-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

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