Hi Ian, On Thu, Jan 21, 2016 at 12:49:24PM +0000, Ian Campbell wrote: >On Thu, 2016-01-21 at 20:35 +0800, Peng Fan wrote: >> On Thu, Jan 21, 2016 at 12:26:04PM +0000, Ian Campbell wrote: >> > Would adding a dummy fixed-clock[0] (or several of them) to the guest >> > passthrough DT satisfy the driver's requirements? They would be hardcoded >> > to whatever rate dom0 and/or the tools has decided upon (and had set in the >> > real h/w). >> >> If using this way, we have the assumption that DomU device driver would not >> change the rate of the clock driving the device. I am not sure whether this >> is >> ok for so many platform devices based ARM core. > >Don't (non-buggy) drivers already need to cope with the possibility that >the clk core may not be able to satisfy their request for a particular rate >due to constraints from other ip blocks? > >I would also expect the user to want to configure things in dom0 such that >the specific drivers used in domU are satisfied with what they get (which >is a bit fiddly perhaps, but platform device passthrough already is >somewhat that way). > >> In /sys/kernel/debug/clk/...., there are clk tree info, but >> clk api are not exposed to userspace as far as I know, so >> if using sysfs interface to set a known fixed rate or enable/disable the >> clock, >> we need to expose the clk info to userspace. > >That seems possible to arrange given a use case for it though, a SMOP (and >convincing the clk maintainer of the need).
Sorry to bother you again on this. For the fixed clock method, I add such a xl cfg entry: devclk=["uart_root_clk,24000000", "gpu_root_clk,200000000"]. After add code for writeing sysfs clk node in libxl, the clk can be set rate/prepared/enabled. But I do not know the resource release path, when need to shutdown/destroy a domain. For example: when domain creation, the clk is prepared, when domain destroied, I want the clk unprepared. But I do not find out the code path to releasing resource. Also, since need to add fixed-clock nodes in DomU dts, do you agree to let libxl or xc to create the nodes in dts, but not mannually add them in passthrough node? Thanks, Peng. > >Worst case is a xen-clkback driver or perhaps even vfio will want to do >something like this, we can't normally use vfio on Xen, but in this case >perhaps we could. > > >> Jan said using hypercall in the other mail, do you have any ideas about >> this? > >This would need a whole clock infrastructure in Xen, wouldn't it? I >described why that is not currently available in an earlier mail, and also >my opinion that doing the whole thing in Xen would involve pulling in far >too much SoC specific code for each specific platform. > >Ian. >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel