[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |