Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

[Peng Fan <van.freenix@xxxxxxxxx>]

Hi Jan,

On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
>>>> On 21.01.16 at 13:06, <van.freenix@xxxxxxxxx> wrote:
>> On Thu, Jan 21, 2016 at 03:21:38AM -0700, Jan Beulich wrote:
>>>>>> On 21.01.16 at 09:59, <van.freenix@xxxxxxxxx> 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?
>
>Well, no, that wouldn't be a desirable (or even sane) model.
>
>>>> 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.
>
>But you mustn't allow a DomU to affect Dom0, nor may two DomU-s
>interact in such a way with one another.
>
>> If not using pvclk, we develop a new method to handle clock. I guest we can 
>> also not avoid this?
>
>At the very least it would need to be avoided by denying the request.
>Upon shared use, either all parties agree, or only one may use the
>clock. And passing through a (platform) device would therefore imply
>validating that the needed clock(s) are available to the target domain.
>Doing this in a consistent way with all control in one component's
>hands seems doable only if hypervisor and/or tool stack are the
>controlling (and arbitrating) entity. In the end this is one of the
>reasons why to me a simple PV I/O interface doesn't seem suitable
>here.

How about let userspace libxl pvclk code to denying the request?

If the pvclk interface is not desirable, I have no more idea on this for now(:

Thanks,
Peng.
>
>Jan
>

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