Hi Ian,
On Thu, Jan 21, 2016 at 12:49:24PM +, Ian Campbell wrote:
>On Thu, 2016-01-21 at 20:35 +0800, Peng Fan wrote:
>> On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
>> > Would adding a dummy fixed-clock[0] (or several of them) to the guest
>> > passthrough DT satisfy the driv
On Fri, 22 Jan 2016, Jan Beulich wrote:
> >>> On 22.01.16 at 13:12, wrote:
> > On Fri, Jan 22, 2016 at 03:25:40AM -0700, Jan Beulich wrote:
> >>In particular, with the user space exposure of clock control
> >>discussed in another sub-thread, the next best option would
> >>seem to be to handle this
>>> On 22.01.16 at 13:12, wrote:
> On Fri, Jan 22, 2016 at 03:25:40AM -0700, Jan Beulich wrote:
>>In particular, with the user space exposure of clock control
>>discussed in another sub-thread, the next best option would
>>seem to be to handle this via emulation in a device model. Yes,
>>ARM guest
Hi Jan,
On Fri, Jan 22, 2016 at 03:25:40AM -0700, Jan Beulich wrote:
On 22.01.16 at 10:27, wrote:
>> Hi Jan,
>>
>> On Fri, Jan 22, 2016 at 12:36:31AM -0700, Jan Beulich wrote:
>> On 22.01.16 at 02:56, wrote:
On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
>At the
>>> On 22.01.16 at 10:27, wrote:
> Hi Jan,
>
> On Fri, Jan 22, 2016 at 12:36:31AM -0700, Jan Beulich wrote:
> On 22.01.16 at 02:56, wrote:
>>> On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
At the very least it would need to be avoided by denying the request.
Upon share
Hi Jan,
On Fri, Jan 22, 2016 at 12:36:31AM -0700, Jan Beulich wrote:
On 22.01.16 at 02:56, wrote:
>> On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
>>>At the very least it would need to be avoided by denying the request.
>>>Upon shared use, either all parties agree, or only one
>>> On 22.01.16 at 02:56, wrote:
> On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
>>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 theref
Hi Ian and Stefano,
On Thu, Jan 21, 2016 at 04:11:45PM +, Stefano Stabellini wrote:
>On Thu, 21 Jan 2016, Ian Campbell wrote:
>> On Thu, 2016-01-21 at 12:55 +, Stefano Stabellini wrote:
>> > On Thu, 21 Jan 2016, Peng Fan wrote:
>> > > Hi Ian,
>> > >
>> > > On Thu, Jan 21, 2016 at 12:26:04
Hi Ian,
On Thu, Jan 21, 2016 at 12:49:24PM +, Ian Campbell wrote:
>On Thu, 2016-01-21 at 20:35 +0800, Peng Fan wrote:
>> On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
>> > Would adding a dummy fixed-clock[0] (or several of them) to the guest
>> > passthrough DT satisfy the driv
Hi Jan,
On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
On 21.01.16 at 13:06, wrote:
>> On Thu, Jan 21, 2016 at 03:21:38AM -0700, Jan Beulich wrote:
>> On 21.01.16 at 09:59, wrote:
uart2 needs clock IMX7D_UART2_ROOT_CLK from the ccm.
passthrough uart2, hypervisor
On Thu, 21 Jan 2016, Ian Campbell wrote:
> On Thu, 2016-01-21 at 12:55 +, Stefano Stabellini wrote:
> > On Thu, 21 Jan 2016, Peng Fan wrote:
> > > Hi Ian,
> > >
> > > On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
> > > > On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
> > > >
On Thu, 2016-01-21 at 12:55 +, Stefano Stabellini wrote:
> On Thu, 21 Jan 2016, Peng Fan wrote:
> > Hi Ian,
> >
> > On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
> > > On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
> > > > Hi Ian,
> > > >
> > > > On Thu, Jan 21, 2016 at 10
On Thu, 21 Jan 2016, Peng Fan wrote:
> Hi Ian,
>
> On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
> >On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
> >> Hi Ian,
> >>
> >> On Thu, Jan 21, 2016 at 10:19:32AM +, Ian Campbell wrote:
> >> > On Thu, 2016-01-21 at 16:59 +0800, Peng
>>> On 21.01.16 at 13:06, wrote:
> On Thu, Jan 21, 2016 at 03:21:38AM -0700, Jan Beulich wrote:
> On 21.01.16 at 09:59, wrote:
>>> uart2 needs clock IMX7D_UART2_ROOT_CLK from the ccm.
>>> passthrough uart2, hypervisor handles the reg and interrupts, that is
>>> because
>>> hypervisor handles
On Thu, 2016-01-21 at 20:35 +0800, Peng Fan wrote:
> On Thu, Jan 21, 2016 at 12:26:04PM +, 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
Hi Ian,
On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
>On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
>> Hi Ian,
>>
>> On Thu, Jan 21, 2016 at 10:19:32AM +, Ian Campbell wrote:
>> > On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote:
>> > >
>> > > To platform device of AR
Hi Jan,
On Thu, Jan 21, 2016 at 03:21:38AM -0700, Jan Beulich wrote:
On 21.01.16 at 09:59, 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 interrup
On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
> Hi Ian,
>
> On Thu, Jan 21, 2016 at 10:19:32AM +, Ian Campbell wrote:
> > On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote:
> > >
> > > To platform device of ARM, hypervisor is responsible for the mapping
> > > between machine address and
Hi Ian,
On Thu, Jan 21, 2016 at 10:19:32AM +, Ian Campbell wrote:
>On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote:
>>
>> To platform device of ARM, hypervisor is responsible for the mapping
>> between machine address and guest physical address, also responsible
>> for the irq mapping.
>>
>>> On 21.01.16 at 09:59, 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 ha
On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote:
>
> To platform device of ARM, hypervisor is responsible for the mapping
> between machine address and guest physical address, also responsible
> for the irq mapping.
>
> But to embedded ARM SoC, the hardware clk IP is handled in Dom0.
Arguably
Hi Jan,
On Thu, Jan 21, 2016 at 12:53:01AM -0700, Jan Beulich wrote:
On 21.01.16 at 02:29, 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
>>> On 21.01.16 at 02:29, 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 a
Hi Jan,
On Wed, Jan 20, 2016 at 07:52:58AM -0700, Jan Beulich wrote:
On 20.01.16 at 15:37, wrote:
>> On Wed, Jan 20, 2016 at 07:16:36AM -0700, Jan Beulich wrote:
>> On 20.01.16 at 15:05, wrote:
On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote:
On 20.01.16 at 12:
>>> On 20.01.16 at 15:37, wrote:
> On Wed, Jan 20, 2016 at 07:16:36AM -0700, Jan Beulich wrote:
> On 20.01.16 at 15:05, wrote:
>>> On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote:
>>> On 20.01.16 at 12:40, wrote:
> On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wro
On Wed, 2016-01-20 at 22:37 +0800, Peng Fan wrote:
>
> > 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
Hi Jan,
On Wed, Jan 20, 2016 at 07:16:36AM -0700, Jan Beulich wrote:
On 20.01.16 at 15:05, wrote:
>> Hi Jan,
>> On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote:
>> On 20.01.16 at 12:40, wrote:
Hi Jan,
On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrot
>>> On 20.01.16 at 15:05, wrote:
> Hi Jan,
> On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote:
> On 20.01.16 at 12:40, wrote:
>>> Hi Jan,
>>>
>>> On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote:
>>> On 20.01.16 at 09:31, wrote:
> +/*
> + * Backend response
Hi Juergen,
On Wed, Jan 20, 2016 at 01:11:39PM +0100, Juergen Gross wrote:
>On 20/01/16 12:48, Peng Fan wrote:
>> Hi Juergen,
>>
>> On Wed, Jan 20, 2016 at 11:40:55AM +0100, Juergen Gross wrote:
>>> On 20/01/16 10:25, Peng Fan wrote:
Hi Juergen,
On Wed, Jan 20, 2016 at 10:05:15AM +
Hi Jan,
On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote:
On 20.01.16 at 12:40, wrote:
>> Hi Jan,
>>
>> On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote:
>> On 20.01.16 at 09:31, wrote:
+/*
+ * Backend response
+ *
+ * cmd: command for operation
Hi Ian, Stefano
On Wed, Jan 20, 2016 at 12:27:07PM +, Ian Campbell wrote:
>On Wed, 2016-01-20 at 12:06 +, Stefano Stabellini wrote:
>> On Wed, 20 Jan 2016, Peng Fan wrote:
>> > To my use case, Dom0 and DomU both use device tree, I need to build
>> > the mapping table between id and name, s
>>> On 20.01.16 at 12:40, wrote:
> Hi Jan,
>
> On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote:
> On 20.01.16 at 09:31, wrote:
>>> +/*
>>> + * Backend response
>>> + *
>>> + * cmd: command for operation on clk, same with the cmd in request.
>>> + * id: clk id, same with the id in
On Wed, 2016-01-20 at 12:06 +, Stefano Stabellini wrote:
> On Wed, 20 Jan 2016, Peng Fan wrote:
> > To my use case, Dom0 and DomU both use device tree, I need to build
> > the mapping table between id and name, since I use name to lookup
> > the clk in backend, like this:
> > "clk = __clk_loopk
On 20/01/16 12:48, Peng Fan wrote:
> Hi Juergen,
>
> On Wed, Jan 20, 2016 at 11:40:55AM +0100, Juergen Gross wrote:
>> On 20/01/16 10:25, Peng Fan wrote:
>>> Hi Juergen,
>>>
>>> On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote:
On 20/01/16 09:31, Peng Fan wrote:
> Introduce p
On Wed, 20 Jan 2016, Peng Fan wrote:
> To my use case, Dom0 and DomU both use device tree, I need to build
> the mapping table between id and name, since I use name to lookup
> the clk in backend, like this:
> "clk = __clk_loopkup(clkname); clk_prepare_enable(clk)". Maybe ACPI
> is another differen
Hi Juergen,
On Wed, Jan 20, 2016 at 11:40:55AM +0100, Juergen Gross wrote:
>On 20/01/16 10:25, Peng Fan wrote:
>> Hi Juergen,
>>
>> On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote:
>>> On 20/01/16 09:31, Peng Fan wrote:
Introduce pvclk interface which is useful when doing devic
Hi Jan,
On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote:
On 20.01.16 at 09:31, wrote:
>> +/*
>> + * Backend response
>> + *
>> + * cmd: command for operation on clk, same with the cmd in request.
>> + * id: clk id, same with the id in request.
>> + * success: indicate failure or
On 20/01/16 10:25, Peng Fan wrote:
> Hi Juergen,
>
> On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote:
>> On 20/01/16 09:31, Peng Fan wrote:
>>> Introduce pvclk interface which is useful when doing device passthrough
>>> on ARM platform.
>>
>> ...
>>
>>> +/*
>>> + * Frontend request
>
>>> On 20.01.16 at 10:25, wrote:
> On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote:
>>On 20/01/16 09:31, Peng Fan wrote:
>>> + */
>>> +struct xen_clkif_request {
>>> + uint32_t cmd;
>>> + uint32_t id;
>>> + uint64_t rate;
>>> +};
>>> +typedef struct xen_clkif_request xen_clkif_
>>> On 20.01.16 at 09:31, wrote:
> +/*
> + * Backend response
> + *
> + * cmd: command for operation on clk, same with the cmd in request.
> + * id: clk id, same with the id in request.
> + * success: indicate failure or success for the cmd.
> + * rate: clock rate. Used for get rate.
> + *
> + * c
Hi Juergen,
On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote:
>On 20/01/16 09:31, Peng Fan wrote:
>> Introduce pvclk interface which is useful when doing device passthrough
>> on ARM platform.
>
>...
>
>> +/*
>> + * Frontend request
>> + *
>> + * cmd: command for operation on clk, sho
On 20/01/16 09:31, Peng Fan wrote:
> Introduce pvclk interface which is useful when doing device passthrough
> on ARM platform.
...
> +/*
> + * Frontend request
> + *
> + * cmd: command for operation on clk, should be XEN_CLK_[xx],
> + * excluding XEN_CLK_END. id is the
> + * id: clk id
> + * r
42 matches
Mail list logo
