Re: [Xen-devel] [RFC PATCH 11/13] cpufreq: add xen-cpufreq driver

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.10.14 at 10:56, <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx> wrote:
> On Fri, Oct 10, 2014 at 5:42 PM, Stefano Stabellini
>> Oleksandr, how would you feel about this change of direction?
> I see that XENPF_resource_op is used to safely read/write MSR.
> In my case the cpufreq governor driver is inside XEN and the rest of the 
> cpufreq
> driver is inside Dom0. Dom0 directly changes CPUs frequency. I don't know 
> how
> to use XENPF_resource_op for ARM. If we want to change CPUs frequency that 
> we
> should change the voltage and write something to the clock control registers 
> in
> ARM.

You didn't understand then: Use of XENPF_resource_op was only
suggested to help with handling both Dom0-based and Xen-initiated
accesses to the same I2C bus, which would be necessary as a result
of keeping control over CPU frequency in the hypervisor.

> If the I2C driver will be virtualized then Regulator framework
> can be inside
> Dom0. But every ARM processor has own clock control registers with different
> addresses. How in this case I should handle this situation? May be
> Clock framework
> should be virtualized too? But this is huge framework. Could 
> XENPF_resource_op
> be used to read/write given value at given address (not predefined addresses
> such as MSR for X86)? If yes that this is possible to not access the 
> hardware
> directly from dom0. But Clock framework in Dom0 can read/write a lot of
> registers and there will be too much hypercalls.

I think the question is mostly moot with the above, but just in case
there's still some use case: Any resource could theoretically be
accessed this way. The only requirement for each individual
resource kind is that it be enumerable. And I'm sure these special
registers can be enumerated (e.g. using the system register
numbering, if it's that how they get represented).

Jan


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