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

[Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx>]

On Mon, Oct 13, 2014 at 5:11 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 13.10.14 at 15:38, <andrii.tseglytskyi@xxxxxxxxxxxxxxx> wrote:
>> On Mon, Oct 13, 2014 at 3:28 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 13.10.14 at 13:59, <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx> wrote:
>>>> There are few reasons to not implement PV I2C in Xen:
>>>> 1. It is difficult to implement concurrent access to I2C controller
>>>
>>> I already outlined how I think this could be made work.
>>>
>>
>> It should be noticed that sometimes I2C transactions require platform
>> specific IPs.
>> For example OMAP3+ platforms contain HW spinlock IP (which is a real
>> HW module with its own clocks).
>> Each i2c_send call must acquire this HW spinlock. And this is
>> something we can't implement in Xen hypervisor.
>
> Do you really mean "can't", or rather "don't want to"? It's very
> hard for me to imagine something that absolutely can't be done
> in the hypervisor.
>

I mean that we must deal with platform specific IP in this case. This
is dependency from specific HW, and driver will not be simple and
generic.
Also I think such interactions are out of scope for hypervisor.
What do you think?

>>>> 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.
>>>
>>> Others seem to be of different opinion.
>>>
>>>> 4. There will be overhead to do all steps above.
>>>
>>> Not sure what you mean here.
>>>
>>
>> I see the following concern here:
>>
>> It should be noticed that almost all peripheral uses I2C bus.
>> For example on our platform touchscreen uses I2C (jacinto6 evm board).
>> Each scroll produces about 50 I2C commands.
>> It means 50 hypercalls in the line to hypervisor, and 100 context
>> switches between hypervisor and dom0.
>>
>> Taking in account all the above - we should think twice about even
>> simple I2C driver which may control voltage regulator.
>
> Leaving aside that there are no real context switches between a
> domain and the hypervisor (only domains, or more precisely vCPU-s,
> get context switched), I'm not sure we need to be worried by these
> numbers. Whether they're problematic depends significantly on the
> time a full I2C command takes to issue (and perhaps complete). And
> then I'm sure you're aware that hypercalls can be batched, so as
> long as not every of these 50 commands depends on results from
> the immediately preceding one, the hypercall cost can certainly be
> amortized to a certain degree.

But in case if each I2C command depends on results of previous one -
we can't use such calls, right? Can we really rely on this?
Some time ago I had a model (for testing which is not related to this
thread) where I sent about 20 hypercalls each second.
I observed lugs in such use cases as Video playback in domU (Android
Jelly Bean as domU). Maybe if we have only Xen and dom0 - everything
will be fine and we can send as many hypercalls as we want. But I'm
worrying in our case this will not work.

Regards,
Andrii

>
> Jan
>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

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