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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.01.16 at 02:29, <van.freenix@xxxxxxxxx> wrote:
> The platform device passthrough part for arm is to mapping the machine io 
> address
> to the guest physical io address. Then guest can map the phsical io address 
> to its
> own virtual address, then by accessing virtual address, guest can access 
> machine io address space.
> So the platform device passthrough does not needs frontend/backend driver to 
> support, except smmu is handled by xen.
> 
> But the platform device needs clk to drive the hardware IP, also may needs 
> pinmux settings.
> the driver in guest needs to drive the hardware IP passed through to the 
> guest, so it needs to operate on the clk.
> 
> Just pasted comments from George for V1:
> 
> "
> Just speaking from the perspective of a Xen dev who's not an ARM dev:
> a few more words on the relationship between pvclk and
> device-passthrough would be helpful to set the context.  It sounds
> like:
> 
> * On ARM, passing through a device requires a clocksource (at least
> for many devices)
> 
> * dom0 has the hardware clocksource, but at the moment domUs don't
> have a suitable clocksource
> 
> * This patch implements pvclk front/backend suitable for such devices
> 
> Is that right?  In which case something like the following would be helpful:
> 
> "This patch introduces pvclk, a paravirtualized clock source suitable
> for devices to use when passing through to domUs on ARM systems."
> "

That's a possible perspective to take, but not the only one. In
fact, coming to what I said previously, I wonder whether placing
the "backend" in Dom0 is the right thing in the first place -
fundamentally arbitration of hardware use should be done
(or at least checked/enforced) by the hypervisor. I.e. just like
while Dom0 may assign a PCI device to a guest, the hypervisor
is in charge of actually making all the resources needed for this
to work accessible to the guest, and/or verifying that permissions
are in place (like e.g. when setting up interrupts). Yet the model
proposed here completely bypasses the hypervisor afaict.

Are there connections between a platform device and its clock(s),
e.g. in DT? If so, wouldn't it be possible for granting access to a
platform device to imply granting control of the respective clock?
In which case clock control might perhaps better become a
hypercall based mechanism? And further - are all clocks in use for
at most one platform device (i.e. is there no sharing possible)? If
not, how do you envision to make multiple parties agree on the
clock settings and state?

> Since my use case is for ARM embedded products, X86 may not need this.

Which already points at one of the issues in your Linux patches:
The drivers did get enabled unconditionally iirc, which would
need changing especially when they're likely useless on x86.

> I try to make this interface common,
> but not sure.

I'm not sure either.

Jan


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