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

[Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>]

On Mon, Oct 13, 2014 at 12:39 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>
> >>> 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
>

There are few reasons to not implement PV I2C in Xen:
1. It is difficult to implement concurrent access to I2C controller
2. I2C code is closely integrated to the Linux kernel code and
I2C driver has lots of levels of abstraction. It is very difficult to cut
I2C code from kernel and make kernel working without it. Kernel folks
will not take this solution to the mainline.
3. Implementation of the  I2C driver in Xen will rather be more complex
than simple.
4. There will be overhead to do all steps above.

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