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

[Peng Fan <van.freenix@xxxxxxxxx>]

Hi Jan,

On Wed, Jan 20, 2016 at 07:52:58AM -0700, Jan Beulich wrote:
>>>> On 20.01.16 at 15:37, <van.freenix@xxxxxxxxx> wrote:
>> On Wed, Jan 20, 2016 at 07:16:36AM -0700, Jan Beulich wrote:
>>>>>> On 20.01.16 at 15:05, <van.freenix@xxxxxxxxx> wrote:
>>>> On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote:
>>>>>>>> On 20.01.16 at 12:40, <van.freenix@xxxxxxxxx> wrote:
>>>>>> On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote:
>>>>>>>>>> On 20.01.16 at 09:31, <van.freenix@xxxxxxxxx> wrote:
>>>>>>>And what I'm missing throughout the file is some description of how
>>>>>>>clock events (interrupts?) are actually meant to make it into the
>>>>>>>guest.
>>>>>> 
>>>>>> I have a simple implementation v1 patch for linux, 
>>>>>> http://lists.xen.org/archives/html/xen-devel/2016-01/msg01860.html.
>>>>>> You can see how it works.
>>>>>
>>>>>No, sorry, that's not the point of the inquiry. It seems to me that
>>>>>there are more aspects to this interface, not directly related to
>>>>>the request/reply protocol written down here, which need to be
>>>>>spelled out event if they don't require any particular definitions
>>>>>or type declarations.
>>>> 
>>>> I try to follow you about clock events(interrupts?), not sure whether I 
>>>> understand correct or not.
>>>> clock in this file is the clk for a device. In linux side, it managed by 
>>>> clk 
>>>> subsystem, drivers/clk/xx.
>>>> This is not the clock events or clock source in drivers/clocksource/xx.
>>>> For the pvclk interface, there will be no interrupt for the guest.
>>>
>>>Then (also considering the set of commands you propose) what
>>>use is the clock to the guest? It can't get events from it, it can't
>>>read its current value, all it can is get/set its rate, enable/disable,
>>>and prepare/unprepare it. I may be lacking some ARM knowledge
>>>here, but all of this looks pretty odd to me.
>> 
>> I follow this 
>> https://events.linuxfoundation.org/sites/events/files/slides/talk_5.pdf to 
>> do 
>> platform device
>> passthrough on ARM platform. I met the same issue as note in the ppt, at 
>> page 24.
>> 
>> In my test case, the uart driver works well without xen. There is serveral 
>> function calls in the driver, such as
>> clk = clk_get("uart2_root"),rate = clk_get_rate(clk), use rate to set 
>> baudrate for uart.
>> 
>> 
>> There is a clk tree in kernel without XEN or dom0 kernel like the following 
>> (only an example):
>> osc -
>>     |-->pll1
>>     |-->pll2
>>          |-->pll2_div
>>               |-->uart2_gate
>>                       |-->uart2_root  --> clk for uart2
>> 
>> uart2_root is directly handled by Dom0.If I assign uart2 to DomU, DomU does
>> not have the clk tree as above, so DomU can not handle directly handle 
>> uart2_root and the uart2 driver in
>> DomU will run into failure to intialize the uart2 hardware IP.
>> 
>> So I introudce pvclk. Pass the operation for uart2_root in DomU to Dom0 and 
>> Dom0 directly handle the clock management hardware IP.
>> 
>> Hope this is clear.
>
>I'm afraid it's not, but it now looks even more like this is too ARM
>specific for me to comment. I wonder whether a generic (not
>ARM specific) PV I/O protocol is actually warranted here. In my
>(presumably too simplistic) view controlling the clock of a passed
>through platform device should be part of that pass-through,
>not the subject of a PV side band protocol.From an abstract
>pov the passed through device should work without any PV I/O
>protocol; such protocols are generally only to accelerate I/O,
>not to make things work in the first place.

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

Since my use case is for ARM embedded products, X86 may not need this. I try to 
make this interface common,
but not sure.. If you have better ideas, please advise me.

Thanks,
Peng.

>
>Jan
>

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