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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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