Re: [RFC V2] xen: interface: introduce pvclk interface

[Peng Fan <van.freenix@gmail.com>]

Hi Jan,

On Thu, Jan 21, 2016 at 03:21:38AM -0700, Jan Beulich wrote:
>>>> On 21.01.16 at 09:59, <van.freenix@gmail.com> wrote:
>> uart2 needs clock IMX7D_UART2_ROOT_CLK from the ccm.
>> passthrough uart2, hypervisor handles the reg and interrupts, that is 
>> because
>> hypervisor handles the memory map and the interrupt controller(GIC). But 
>> here
>> CCM is not handled by hypervisor, it is handled by Dom0.
>
>This, I take it, describes the current state, which doesn't make clear
>whether this is intentionally that way (and can't be changed), or
>just happens to be that way because so far it didn't matter.
>
>> For ARMV8 server products, I am not sure whether hypercall is better; but to 
>> my case, it's not feasible to use hypercall.
>
>Because of ...?

I guess you mean DomU issues hypercall and Xen forwards the request to Dom0,
then Dom0 reply the response?

If you experts think pvclk is not a good way to handle the clock for passed through
device, I can try hypercall way.

>
>> Dom0 handles all the clocks, DomU just send request to Dom0 and ask Dom0 to
>> enable/disable/set rate for a clock for the device. So I think it's okay
>> for multipile parties, the clk subsystem in Dom0 can handle mutiple requests 
>> even if the clock is shared.
>
>I.e. if one party sets one rate, and later another party sets
>a different rate, things are going to work fine? If so, why would
>the different parties need control over the rate in the first place?

oh. thanks for teaching me. If two IPs share one clock, and IP1 for Dom0, IP2 for DomU,
Dom0 needs clock work at 20Hz, but DomU want clock work at 40Hz. pvclk can not avoid this.

If not using pvclk, we develop a new method to handle clock. I guest we can also not avoid this?

Thanks,
Peng.

>
>Jan
>