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

[Peng Fan]

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 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 success for the cmd.
>> + * rate: clock rate. Used for get rate.
>> + *
>> + * cmd and id are filled by backend and passed to frontend to
>> + * let frontend check whether the response is for the current
>> + * request or not.
>> + */
>> +struct xen_clkif_response {
>> +uint32_t cmd;
>> +uint32_t id;
>> +uint32_t success;
>> +uint64_t rate;
>> +};
>
>This isn't 32-/64-bit clean. Question is whether echoing cmd is really
>needed.
 
 As Juergen suggested, use a request id. I'll fix this in V3.
 32-/64-bit unclean, I can not get you here (:
>>>
>>>The layout of above structure may end up different for 32- and
>>>64-bit guests, depending on the alignment of uint64_t.
>> 
>> Thanks for teaching me. In V3, the layout will be changed to like this
>> struct xen_clkif_response {
>>  uint32_t request_id;
>>  int32_t status;
>>  uint64_t rate;
>> };
>
>Okay. Just as a not - iirc other pv interfaces use 64-bit ID values,
>so not doing this here perhaps ought to be justified.

oh. I see uint64_t id in blkif.h :). Thanks.

>
>> And more macro definitions for the status entry:
>> #define XEN_CLK_OP_SUCCESS 0
>> #define XEN_CLK_ENABLE_FALIURE -1
>> #define XEN_CLK_DISABLE_FAILURE -2
>> #define XEN_CLK_PREPARE_FAILURE -3
>> #define XEN_CLK_UNPREPARE_FAILURE -4
>> #define XEN_CLK_SET_RATE_FAILURE -5
>> #define XEN_CLK_GET_RATE_FALIURE -6
>
>That's bogus - different kinds of errors would be meaningful,
>but an error per command is quite pointless imo. (Also please
>be aware of typos and parenthesization.)

Will fine tune this in V3.

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

Thanks,
Peng.

>
>Jan
>

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

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

[Peng Fan]

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, since I use name to lookup
>> > the clk in backend, like this:
>> > "clk = __clk_loopkup(clkname); clk_prepare_enable(clk)". Maybe ACPI
>> > is another different case.
>> 
>> Theoretically on systems using ACPI there is no need to fiddle with
>> clocks,
>
>I mentioned ACPI in my replies to v1 more as a placeholder for "other
>firmware descriptions than DT", in order that the pv protocol we end up
>with does not end up being DT specific, which would be a mistake
>irrespective of what may or may not be required for non-DT firmware
>descriptions.

Thanks for clarifying. Beside this, are you ok with the xenstore node 
description in this file?

Thanks,
Peng.

>
>Ian.
>
>>  see
>> 
>> Documentation/arm64/arm-acpi.txt
>> 
>> 
>> "In DT, clocks need to be specified
>> and the drivers need to take them into account.  In ACPI, the assumption
>> is that UEFI will leave the device in a reasonable default state,
>> including
>> any clock settings.  If for some reason the driver needs to change a
>> clock
>> value, this can be done in an ACPI method; all the driver needs to do is
>> invoke the method and not concern itself with what the method needs to do
>> to change the clock.  Changing the hardware can then take place over time
>> by changing what the ACPI method does, and not the driver.
>> 
>> In DT, the parameters needed by the driver to set up clocks as in the
>> example
>> above are known as "bindings"; in ACPI, these are known as "Device
>> Properties"
>> and provided to a driver via the _DSD object."
>> 
>> 
>> However currently we don't have the ability to run ACPI in DomU guests
>> on ARM. Even if we had, there is no way to call native ACPI methods from
>> any guests other than Dom0, even on x86. We just have to hope that
>> clocks don't need to be reset on ACPI systems.

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

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

[Peng Fan]

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 +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, should be XEN_CLK_[xx],
>>>>>> + *  excluding XEN_CLK_END. id is the
>>>>>> + * id: clk id
>>>>>> + * rate: clock rate. Used for set rate.
>>>>>
>>>>> Which unit? Hz?
>>>>
>>>> Yeah. Hz. I'll add comments in V3.
>>>>
>>>>>
>>>>>> + */
>>>>>> +struct xen_clkif_request {
>>>>>> +uint32_t cmd;
>>>>>> +uint32_t id;
>>>>>> +uint64_t rate;
>>>>>> +};
>>>>>> +typedef struct xen_clkif_request xen_clkif_request_t;
>>>>>> +
>>>>>> +/*
>>>>>> + * 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.
>>>>>
>>>>> Values?
>>>>
>>>> I'd like to let the frontend/backend driver to determine the value.
>>>> In my implementation for linux, if the backend API supports return value,
>>>> I'll fill the return value to success entry. If the backend API returns
>>>> void, I'll just fill 0 to success entry.
>>>
>>> So please specify "0" to mean success and add some sensible error
>>> values. There might be multiple frontend- and/or backend-variants which
>>> all must agree using the same interface.
>> 
>> Will change this to `int status`, as also observed by Jan.
>> I'll also define macros such as "#define XEN_CLK_ENABLE_OK 0", "#define 
>> XEN_CLK_ENABLE_FAILURE -1"
>> 
>>>
>>>>>> + * rate: clock rate. Used for get rate.
>>>>>> + *
>>>>>> + * cmd and id are filled by backend and passed to frontend to
>>>>>> + * let frontend check whether the response is for the current
>>>>>> + * request or not.
>>>>>
>>>>> I'd rather let the frontend add a request Id to the request which
>>>>> will be echoed here instead cmd and clock Id.
>>>>
>>>> If using request id, I think we can encode cmd and id into request id?
>>>
>>> This should just be an opaque value for the backend. The frontend is
>>> free how to create this value, it should be unique for every outstanding
>>> request of a domU, however. It could be built from cmd and id in case
>>> there can't be multiple requests with the same cmd/id combination
>>> active in a domU.
>> 
>> Thanks for teaching me on this. So the request id should be globally unique
>> for backend. So "random value(generated in frontend) + frontend domid" is ok 
>> for this?
>
>Being unique per frontend is enough, as each frontend will only ever see
>responses for it's own requests. Make it as simple as possible. I guess
>there will be a maximum of active requests possible, e.g. the number of
>request slots in the request ring. You could use the index into the ring
>as Id (pvSCSI frontend is doing it this way).

Thanks for this info.
In my case, such as let DomU handle uart2, I only need to let DomU
handle uart2-root-clk. Later I will passthrough gpu to DomU, only
gpu-root-clk needs be handled by DomU.
In linux side, clk operation is exclusive for one device(not definitely sure),
so the number of slots can be max number of devices that supported for device 
passthrough.

I'll take pvSCSI for reference.

Thanks,
Peng.

>
>Juergen

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

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

[Peng Fan]

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 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.
 + *
 + * cmd and id are filled by backend and passed to frontend to
 + * let frontend check whether the response is for the current
 + * request or not.
 + */
 +struct xen_clkif_response {
 +  uint32_t cmd;
 +  uint32_t id;
 +  uint32_t success;
 +  uint64_t rate;
 +};
>>>
>>>This isn't 32-/64-bit clean. Question is whether echoing cmd is really
>>>needed.
>> 
>> As Juergen suggested, use a request id. I'll fix this in V3.
>> 32-/64-bit unclean, I can not get you here (:
>
>The layout of above structure may end up different for 32- and
>64-bit guests, depending on the alignment of uint64_t.

Thanks for teaching me. In V3, the layout will be changed to like this
struct xen_clkif_response {
uint32_t request_id;
int32_t status;
uint64_t rate;
};

And more macro definitions for the status entry:
#define XEN_CLK_OP_SUCCESS 0
#define XEN_CLK_ENABLE_FALIURE -1
#define XEN_CLK_DISABLE_FAILURE -2
#define XEN_CLK_PREPARE_FAILURE -3
#define XEN_CLK_UNPREPARE_FAILURE -4
#define XEN_CLK_SET_RATE_FAILURE -5
#define XEN_CLK_GET_RATE_FALIURE -6

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

I'll add more texts in the file or commit log.

Thanks,
Peng.

>
>Jan
>

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

Re: [Xen-devel] [RFC/WIP] xen: clk: introudce pvclk for device passthrough

[Peng Fan]

Hello David,

On Mon, Jan 18, 2016 at 11:24:08AM +, David Vrabel wrote:
>On 16/01/16 05:22, Peng Fan wrote:
>> This patch was just a initial patch, not sure whether this way
>> is ok from you side for handlding clk when doing platform device
>> passhthrough. Any comments are appreciated, and your comments may
>> give me a better direction.
>
>There's no documentation on the interface, which makes it difficult to
>review.  At a first look it looks very specific to the particular Linux
>implementation of a clk subsystem.

My bad. I'll add more text in commit log or cover letter in V2 to describe
the interface.

>
>> --- /dev/null
>> +++ b/include/xen/interface/io/clkif.h
>> @@ -0,0 +1,41 @@
>> +/*
>> + * The code contained herein is licensed under the GNU General Public
>> + * License. You may obtain a copy of the GNU General Public License
>> + * Version 2 or later at the following locations:
>> + *
>> + * http://www.opensource.org/licenses/gpl-license.html
>> + * http://www.gnu.org/copyleft/gpl.html
>> + */
>
>ABIs should be under a more permissive license so they can be used by
>other (non-GPLv2) operating systems.

ok. I'll change this.

>
>> +
>> +#ifndef __XEN_PUBLIC_IO_CLKIF_H__
>> +#define __XEN_PUBLIC_IO_CLKIF_H__
>> +
>> +#include 
>> +#include 
>> +
>> +/**/
>> +enum {
>> +XENCLK_PREPARE, /* clk_prepare_enable */
>> +XENCLK_UNPREPARE,   /* clk_unprepare_disable */
>> +XENCLK_GET_RATE,/* clk_get_rate */
>> +XENCLK_SET_RATE,/* clk_set_rate */
>> +XENCLK_END,
>> +};
>> +
>> +struct xen_clkif_request {
>> +int id;
>
>You should use fixed width types so the ABI is the same on 32-bit and
>64-bit guests.

Will fix in V2.

>
>> +unsigned long rate;
>> +char clk_name[32];
>
>Where does the frontend get these names from?  31 character names seems
>rather limiting.

The clk_name is got from DomU device tree. In the commit log, I wrote this:
"
clks: clks {
compatible = "xen,xen-clk";
#clock-cells = <1>;
clock-output-names = "uart2_root_clk";
};
"
The clk_name is one of the entry from clock-output-names, clk_name will
be passed to Dom0, Dom0 will use the clk_name to find the clk structure using
__clk_lookup.


>
>> +};
>> +
>> +struct xen_clkif_response {
>> +int id;
>> +int success;
>> +unsigned long rate;
>> +char clk_name[32];
>> +};
>
>I don't think you need to the name in the response.  The id will tie the
>response to the request.

My original idea is to  use id and clk_name to check whether the response is 
for the requester.
You can see in the patch:
" if ((id == comp->id) && !strncmp(name, comp->clk_name, 
sizeof(comp->clk_name)))"

Maybe clk_name is redundant here. I will remove it in V2.

Thanks for your comments.

Peng.

>
>> +
>> +DEFINE_RING_TYPES(xen_clkif, struct xen_clkif_request, struct 
>> xen_clkif_response);
>> +#define XEN_CLK_RING_SIZE __CONST_RING_SIZE(xen_clkif, PAGE_SIZE)
>> +
>> +#endif
>> 
>

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

Re: [Xen-devel] [RFC/WIP] xen: clk: introudce pvclk for device passthrough

[Peng Fan]

Hello George,

On Mon, Jan 18, 2016 at 11:22:44AM +, George Dunlap wrote:
>On Sat, Jan 16, 2016 at 5:22 AM, Peng Fan <van.free...@gmail.com> wrote:
>> This patch was just a initial patch, not sure whether this way
>> is ok from you side for handlding clk when doing platform device
>> passhthrough. Any comments are appreciated, and your comments may
>> give me a better direction.
>
>Hey Peng,
>
>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:

Yeah. right. You have a better explaination than me :)

>
>"This patch introduces pvclk, a paravirtualized clock source suitable
>for devices to use when passing through to domUs on ARM systems."
>
>(Obviously change it as necessary to make it accurate.)

I'll add your words into the commit log.

Thanks,
Peng.

>
>Thanks,
> -George

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

Re: [Xen-devel] [RFC/WIP] xen: clk: introudce pvclk for device passthrough

[Peng Fan]

Hello Ian,

On Mon, Jan 18, 2016 at 12:41:59PM +, Ian Campbell wrote:
>On Mon, 2016-01-18 at 11:24 +, David Vrabel wrote:
>> On 16/01/16 05:22, Peng Fan wrote:
>> > This patch was just a initial patch, not sure whether this way
>> > is ok from you side for handlding clk when doing platform device
>> > passhthrough. Any comments are appreciated, and your comments may
>> > give me a better direction.
>> 
>> There's no documentation on the interface, which makes it difficult to
>> review.  At a first look it looks very specific to the particular Linux
>> implementation of a clk subsystem.
>> 
>> > --- /dev/null
>> > +++ b/include/xen/interface/io/clkif.h
>> > @@ -0,0 +1,41 @@
>> > +/*
>> > + * The code contained herein is licensed under the GNU General Public
>> > + * License. You may obtain a copy of the GNU General Public License
>> > + * Version 2 or later at the following locations:
>> > + *
>> > + * http://www.opensource.org/licenses/gpl-license.html
>> > + * http://www.gnu.org/copyleft/gpl.html
>> > + */
>> 
>> ABIs should be under a more permissive license so they can be used by
>> other (non-GPLv2) operating systems.
>
>... along the same lines proposals for new ABIs should be made in the form
>of patches to xen.git:xen/include/public/io/ before being submitted as an
>implementation for one particular os.

I had no idea about this before. Do you mean that before I implement
pvclk for linux, I need to first post the clkif part to xen devel?

If it is, I'll split the interface part and send this part to
xen-de...@lists.xenproject.org for review.

>
>
>> > +  unsigned long rate;
>> > +  char clk_name[32];
>> 
>> Where does the frontend get these names from?  31 character names seems
>> rather limiting.
>
>Indeed.
>
>At a guess I would assume they come from the device-tree given to the guest
>and tie into the host device tree.

Yeah. the clk_name is got from DomU dts, and in Dom0 there is also a same
name.

>
>I think a better model might be for each clk to have it's own subdirectory
>under the overall clock bus node, e.g. something like:
>
>/local/domain/<...>/clk/0/nr-clks = 4
>/local/domain/<...>/clk/0/clk-0/ ...
>/local/domain/<...>/clk/0/clk-1/ ...
>/lo
>cal/domain/<...>/clk/0/clk-2/ ...
>/local/domain/<...>/clk/0/clk-3/ ...
>
>and for each subdirectory to contain the a node containing the corresponding 
>firmware table identifier (so path in the DT case), which the toolstack knows, 
>so it can setup the f/e and b/e to correspond as necessary, and the f/e device 
>needn't necessarily use the same name as the backend/host).
>
>The request would then include the index and not the name (and as David 
>observes the response only needs the id).

For now, I have not began the userspace libxl part for pvclk, I use the libxl 
pvusb code for test (:
The id acctually means what operation is needed, such as CLK_PREPARE, 
CLK_UNPREPARE, CLK_SET_RATE, CLK_GET_RATE. I'll add more text to document this 
in V2.

>
>As well as properly documenting the meaning of the operations 
>the clkif.h should also define the xenstore nodes and contain the binary 
>layouts of the req/rsp structs (see netif.h for examples of both, blkif.h also 
>includes examples of the former).

ok. I'll take netif/blkif for reference.

>
>I'd also like to see a description of the DT bindings, which I assume must be 
>needed such that the devices clocks property has something to refer to. For 
>example maybe it doesn't make sense for xenstore to contain the path, but for 
>the pvclk node in xenstore to contain the index.

The DT bindings for xen pvclk, I use this:
"
clks: clks {
compatible = "xen,xen-clk";
#clock-cells = <1>;
clock-output-names = "uart2_root_clk";
};
"
the clock-output-names will be parsed and be registered as clk root. The device 
will use index to refer to the clk, as the following:
"
clocks = < 0>, < 0>;
clock-names = "ipg", "per";
"
0 means the first one in clock-output-names.

To the xenstore part, I am not sure whether need to expose the clock relate 
info to xenstore. I just want to store the clock names in xenstore to let
user know what clocks are now handled by DomU.

How about the following?

doamin1:
/local/domain/1/device/vclk/nr-clks
/local/domain/1/device/vclk/clk-0/name
/local/domain/1/device/vclk/clk-1/name

domain2:
/local/domain/2/device/vclk/nr-clks
/local/domain/2/device/vclk/clk-0/name
/local/domain/2/device/vclk/clk-1/na

[Xen-devel] [RFC/WIP] xen: clk: introudce pvclk for device passthrough

[Peng Fan]

This patch was just a initial patch, not sure whether this way
is ok from you side for handlding clk when doing platform device
passhthrough. Any comments are appreciated, and your comments may
give me a better direction.

Patch was basically tested with passthrough uart2 to DomU on
freescale i.MX7D(Cortex-A7 Dual) platform with two linux os
running based on xen hypervisor.

I have not written the userspace libxl pvclk code, so I use the libxl pvusb
code for test, only need to change the compatible string in this patch
from "vclk" to "vusb", and "clk-ring-ref" to "urb-ring-ref". If this patch
is a acceptable way, I'll begin coding the userspace libxl pvclk.

I follow this doc [1] to do platform device passthrough, but I also
met the issue how to handle clk in the DomU guest. I do not want
to remove the clk api such clk_prepare_enable/disable and etc in the
uart driver, since it work well without xen. But if want the uart driver
to work well in DomU, I need to take care the clk usage. Without
this patch, clk_prepare_enable/disable will fail because no clk tree
in DomU. So I wrote this patch,

Since xen pv use asynchronous notification, clk_enable/disable can not
be implemented in the map, so I use clk_prepare_enable/disable in backend
to map clk_prepare/unprepare in frontend.

Partial dts for DomU linux:
"
aliases {
serial0 = 
clk0 = 
};

passthrough {
compatible = "simple-bus";
ranges; #address-cells = <1>;
#size-cells = <1>;

clks: clks {
compatible = "xen,xen-clk";
#clock-cells = <1>;
clock-output-names = "uart2_root_clk";
};

uart2: serial@1000 {
compatible = "fsl,imx7d-uart", "fsl,imx6q-uart", 
"fsl,imx21-uart";
reg = <0x1000 0x1>;
interrupts = <0 27 4>;
interrupt-parent = <65000>;
clocks = < 0>, < 0>;
clock-names = "ipg", "per";
};
};
"

Xen front clk driver will register itself by probing "xen,xen-clk", register
clk tree by parsing "clock-output-names" and register as ROOT clk.
See the uart2 node, ipg and per clks are also registered in Dom0,
when DomU want to prepare or set rate for the ipg clk, DomU will use pvclk
interface to pass the name "ipg" and the ID(PREPARE, SET_RATE and etc)to Dom0,
Dom0 will use __clk_lookup to find out the "struct clk *" structure and
prepare_enable or set_rate according to the ID from DomU. The ID is defined
in clkif.h in this patch.

The mapping between frontend and backend is as following:

  Frontend  Backend
clk_prepare clk_prepare_enable
clk_unprepare   clk_unprepare_disable
clk_set_rateclk_set_rate
clk_get_rateclk_get_rate

Frontend work flow example:
1. clk_prepare("ipg")
|->ID: PREPARE, name: "ipg" packed into a structure
  |->notify backend
2. wait_completion
    Dom0 finished clk_prepare_enable and send event channel interrupt
to DomU, In DomU frontend interrupt handler, call complete to wakeup.

[1] https://events.linuxfoundation.org/sites/events/files/slides/talk_5.pdf

Signed-off-by: Peng Fan <van.free...@gmail.com>
Cc: xen-de...@lists.xenproject.org
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: David Vrabel <david.vra...@citrix.com>
Cc: Julien Grall <julien.gr...@citrix.com>
Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: Michael Turquette <mturque...@baylibre.com>
Cc: Stephen Boyd <sb...@codeaurora.org>

---
 drivers/clk/Makefile |   2 +
 drivers/clk/xen/Makefile |   1 +
 drivers/clk/xen/clk-xen.c| 197 ++
 drivers/clk/xen/xen-clkback.c| 357 
 drivers/clk/xen/xen-clkfront.c   | 432 +++
 include/xen/interface/io/clkif.h |  41 
 6 files changed, 1030 insertions(+)
 create mode 100644 drivers/clk/xen/Makefile
 create mode 100644 drivers/clk/xen/clk-xen.c
 create mode 100644 drivers/clk/xen/xen-clkback.c
 create mode 100644 drivers/clk/xen/xen-clkfront.c
 create mode 100644 include/xen/interface/io/clkif.h

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 820714c..7668ecc 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -15,6 +15,8 @@ ifeq ($(CONFIG_OF), y)
 obj-$(CONFIG_COMMON_CLK)   += clk-conf.o
 endif
 
+obj-$(CONFIG_

[Xen-devel] Question about arm passthrough and power related

[Peng Fan]

Hi,

I am trying to passthrough a platform device to domU, but as we know
clk dts property and related code are handled in dom0. If passthrough the
platform device to domU, then how the clock for the device.

I came across this documentation "How to passthrough your integrated device to a
VM on ARM" at  
https://events.linuxfoundation.org/sites/events/files/slides/talk_5.pdf.
And follow the steps, and I can assign machine io memory space to domU on my
platform without smmu support. But domU driver probe function will fail,
because there is no clk property in the domU partial dts.

For example, without the clocks property, domU driver probe will fail.
uart2: serial@3089 {
compatible = "fsl,imx7d-uart", "fsl,imx6q-uart", "fsl,imx21-uart";
reg = <0x3087 0x1>;
interrupts = ;
clocks = < IMX7D_UART2_ROOT_CLK>,
< IMX7D_UART2_ROOT_CLK>;
clock-names = "ipg", "per";
xx
};


I have another question which is about power related. Without xen, linux can
runs into suspend state, ddr into self-refresh state, arm core powered off, and
clocks for some devices are off and power off;
If with xen, should the power related stuff implemented in xen hypervisorr
or still in dom0 linux?

Thanks,
Peng.

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

[Xen-devel] [RFC 1/1] xen: block: correct setting for xen_blkif_max_ring_order

[Peng Fan]

According to this piece code:
"
 pr_info("Invalid max_ring_order (%d), will use default max: %d.\n",
  xen_blkif_max_ring_order, XENBUS_MAX_RING_GRANT_ORDER);
"
if xen_blkif_max_ring_order is bigger that XENBUS_MAX_RING_GRANT_ORDER,
need to set xen_blkif_max_ring_order using XENBUS_MAX_RING_GRANT_ORDER,
but not 0.

Signed-off-by: Peng Fan <van.free...@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: David Vrabel <david.vra...@citrix.com>
Cc: "Roger Pau Monné" <roger@citrix.com>
---

Hi,

I am new to xen and reading related soure code, not sure whether
this is correct. Please comments.

Thanks

 drivers/block/xen-blkfront.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 0823a96..883b9fa 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2126,7 +2126,7 @@ static int __init xlblk_init(void)
if (xen_blkif_max_ring_order > XENBUS_MAX_RING_PAGE_ORDER) {
pr_info("Invalid max_ring_order (%d), will use default max: 
%d.\n",
xen_blkif_max_ring_order, XENBUS_MAX_RING_PAGE_ORDER);
-   xen_blkif_max_ring_order = 0;
+   xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER;
}
 
if (!xen_has_pv_disk_devices())
-- 
2.6.2


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

[Xen-devel] [RFC 1/1] xen: interface: correct comments

[Peng Fan]

According to definition of structure evtchn_alloc_unbound,
there is an entry "domid_t remote_dom", no "rdom". So
using "remote_dom" in comments instead of "rdom".

Signed-off-by: Peng Fan <van.free...@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: David Vrabel <david.vra...@citrix.com>
---
 include/xen/interface/event_channel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/xen/interface/event_channel.h 
b/include/xen/interface/event_channel.h
index 7e6acef..1903a23 100644
--- a/include/xen/interface/event_channel.h
+++ b/include/xen/interface/event_channel.h
@@ -20,7 +20,7 @@ DEFINE_GUEST_HANDLE(evtchn_port_t);
  * is allocated in  and returned as .
  * NOTES:
  *  1. If the caller is unprivileged then  must be DOMID_SELF.
- *  2.  may be DOMID_SELF, allowing loopback connections.
+ *  2.  may be DOMID_SELF, allowing loopback connections.
  */
 #define EVTCHNOP_alloc_unbound   6
 struct evtchn_alloc_unbound {
-- 
2.6.2


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

[Xen-devel] [PATCH 2/2] xen: arm: traps: correct cond

[Peng Fan]

>From "G6.2.29 CPSR, Current Program Status Register" of Aarch64 ARM
and "B1.3.3 Program Status Registers (PSRs)" of ARMv7-A ARM:
"
IT[7:5] holds the base condition for the IT block. The base condition is
the top 3 bits of the condition code specified by the first
condition field of the IT instruction.
IT[4:0] encodes the size of the IT block, which is the number of
instructions that are to be conditionally executed, by the
position of the least significant 1 in this field. It also
encodes the value of the least significant bit of the condition
code for each instruction in the block.
"

So should be "cond = ( it >> 5 );" but not "cond = ( it >> 4 );"

Signed-off-by: Peng Fan <peng@freescale.com>
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: Stefano Stabellini <stefano.stabell...@citrix.com>
Cc: Julien Grall <julien.gr...@citrix.com>
---
 xen/arch/arm/traps.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 2e2b1f2..b2879b7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1561,8 +1561,8 @@ static int check_conditional_instr(struct cpu_user_regs 
*regs,
 if ( it == 0 )
 return 1;
 
-/* The cond for this instruction works out as the top 4 bits. */
-cond = ( it >> 4 );
+/* The cond for this instruction works out as the top 3 bits. */
+cond = ( it >> 5 );
 }
 
 cpsr_cond = cpsr >> 28;
-- 
1.8.4



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

[Xen-devel] [PATCH 1/2] xen: arm: traps: check hsr.ec for ARM32

[Peng Fan]

To ARM64, "if ( hsr.ec >= 0x10 ) return 1;" is ok for unconditional
check, but to ARM32, we need to use 'hsr.ec >> 30' to check.

Signed-off-by: Peng Fan <peng@freescale.com>
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: Stefano Stabellini <stefano.stabell...@citrix.com>
Cc: Julien Grall <julien.gr...@citrix.com>
---
 xen/arch/arm/traps.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9d2bd6a..2e2b1f2 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1531,8 +1531,13 @@ static int check_conditional_instr(struct cpu_user_regs 
*regs,
 int cond;
 
 /* Unconditional Exception classes */
+#ifdef CONFIG_ARM_64
 if ( hsr.ec >= 0x10 )
 return 1;
+#else
+if ( hsr.ec >> 30 )
+return 1;
+#endif
 
 /* Check for valid condition in hsr */
 cond = hsr.cond.ccvalid ? hsr.cond.cc : -1;
-- 
1.8.4



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

Re: [Xen-devel] [PATCH 2/2] xen: arm: traps: correct cond

[Peng Fan]

On Mon, Sep 21, 2015 at 11:10:11AM +0100, Julien Grall wrote:
>Hi Peng,
>
>On 21/09/15 08:07, Peng Fan wrote:
>> From "G6.2.29 CPSR, Current Program Status Register" of Aarch64 ARM
>> and "B1.3.3 Program Status Registers (PSRs)" of ARMv7-A ARM:
>> "
>
>The section number may change between the different version of the spec.
>Can you also precise the spec version?
>
>For instance on my ARM64 spec (ARM DDI 0497A.d) the section G6.2.29
>points to "CSSELR" and not "CPSR".
>
>> IT[7:5] holds the base condition for the IT block. The base condition is
>> the top 3 bits of the condition code specified by the first
>>  condition field of the IT instruction.
>> IT[4:0] encodes the size of the IT block, which is the number of
>> instructions that are to be conditionally executed, by the
>>  position of the least significant 1 in this field. It also
>>  encodes the value of the least significant bit of the condition
>>  code for each instruction in the block.
>> "
>> So should be "cond = ( it >> 5 );" but not "cond = ( it >> 4 );"
>
>IT[7:5] encodes the top 3 bits of the condition code and one bit of
>IT[4:0] will contain the least significant bit of the condition code.
>
>In order to get the full condition code you have to use IT[7:4] which
>the current code does (see A2.5.2 ARM DDI 0406C.b).
>
>So the current code looks valid to me. Did I miss something?

No, you are correct.

Thanks,
Peng.

>
>Regards,
>
>> Signed-off-by: Peng Fan <peng@freescale.com>
>> Cc: Ian Campbell <ian.campb...@citrix.com>
>> Cc: Stefano Stabellini <stefano.stabell...@citrix.com>
>> Cc: Julien Grall <julien.gr...@citrix.com>
>> ---
>>  xen/arch/arm/traps.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 2e2b1f2..b2879b7 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -1561,8 +1561,8 @@ static int check_conditional_instr(struct 
>> cpu_user_regs *regs,
>>  if ( it == 0 )
>>  return 1;
>>  
>> -/* The cond for this instruction works out as the top 4 bits. */
>> -cond = ( it >> 4 );
>> +/* The cond for this instruction works out as the top 3 bits. */
>> +cond = ( it >> 5 );
>>  }
>>  
>>  cpsr_cond = cpsr >> 28;
>> 
>
>-- 
>Julien Grall

-- 

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

Re: [Xen-devel] [PATCH 1/2] xen: arm: traps: check hsr.ec for ARM32

[Peng Fan]

Hi Julien,
On Mon, Sep 21, 2015 at 10:47:23AM +0100, Julien Grall wrote:
>Hi Peng,
>
>On 21/09/15 08:07, Peng Fan wrote:
>> To ARM64, "if ( hsr.ec >= 0x10 ) return 1;" is ok for unconditional
>> check, but to ARM32, we need to use 'hsr.ec >> 30' to check.
>
>hsr.ec is encoded on 5 bits, therefore the shift you suggest is wrong.
>Maybe you wanted to use (hsr.ec >> 4)?
Thanks for correcting me. 0x10 can handle hsr.ec >> 4.
My bad, this patch is wrong. 

Regards,
Peng.
>
>Although, can you explain why you need a different check for ARM32?
>
>Regards,
>
>> Signed-off-by: Peng Fan <peng@freescale.com>
>> Cc: Ian Campbell <ian.campb...@citrix.com>
>> Cc: Stefano Stabellini <stefano.stabell...@citrix.com>
>> Cc: Julien Grall <julien.gr...@citrix.com>
>> ---
>>  xen/arch/arm/traps.c | 5 +
>>  1 file changed, 5 insertions(+)
>> 
>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 9d2bd6a..2e2b1f2 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -1531,8 +1531,13 @@ static int check_conditional_instr(struct 
>> cpu_user_regs *regs,
>>  int cond;
>>  
>>  /* Unconditional Exception classes */
>> +#ifdef CONFIG_ARM_64
>>  if ( hsr.ec >= 0x10 )
>>  return 1;
>> +#else
>> +if ( hsr.ec >> 30 )
>> +return 1;
>> +#endif
>>  
>>  /* Check for valid condition in hsr */
>>  cond = hsr.cond.ccvalid ? hsr.cond.cc : -1;
>> 
>
>
>-- 
>Julien Grall

-- 

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

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

[Peng Fan]

Hi Julien,

On 6/23/2015 9:56 PM, Peng Fan wrote:
 Hi,
 
 On 6/23/2015 9:36 PM, Julien Grall wrote:
 Hi,

 On 23/06/15 14:03, Peng Fan wrote:
 I did not enable LPAE for DOM0 kernel, use shor page table.
 Following is the full log from uboot to kernel with DOM0 512M:

 Which CONFIG_VMSPLIT_* do you use? Can you try to use another one? I
 remembered it had some effect on the offset between physical and virtual
 address.
  CONFIG_VMSPLIT_2G=y
 
 CONFIG_PAGE_OFFSET=0x8000
 
 ok. Will try 3G:1G split.
Later I'll reply with log info about this(Do not have log at hand).
Still panic, maybe something wrong with gnutab configration in my side,
I use default gnutab address/size.

Current I met a DomU boot issue, if do not use blk backend, DomU can
boot with ramfs as rootfs. If use an image file as rootfs, DomU can not
boot.

I am not sure why this happends:
libxl: error: libxl_create.c:1195:domcreate_launch_dm: unable to add
disk devices
libxl: error: libxl_device.c:799:libxl__initiate_device_remove: unable
to get my domid

By using gdb, I found domcreate_launch_dm fails to get domid, then it
reports unable to add disk devices. I am not familiar with xenstore and
etc. Did I miss some configuation?

My cfg file:
kernel = /home/root/xen/domu.image
memory = 128
name = domU
vcpus = 1
serial=pty
disk = [ 'phy:/dev/loop0,xvda,w' ]
extra = earlyprintk=xenboot console=hvc0 root=/dev/xvda debug=/bin/sh

My init script when Dom0 boots up:

mount -t xenfs xenfs /proc/xen

export LD_LIBRARY_PATH=/usr/local/lib

echo Starting Xenstored
xenstored -T /root/xenstored.log
echo Xenstored started

echo Starting xenconsoled
xenconsoled -i 
echo Xenconsoled started

echo Setting up loop0
losetup /dev/loop0 DomU.image
losetup -a

echo Writing dom0 name to xenstore
/usr/local/bin/xenstore-write /local/domain/0/name Domain-0
echo Done

mkdir -p /var/log/xen


Detail log when creat DomU:
xen# xl -vvv create -d  DomU-test
Parsing config from DomU-test
{
domid: null,
config: {
c_info: {
type: pv,
name: domU,
uuid: 67000363-4ae4-41a5-9c1f-293c1b69aa69,
run_hotplug_scripts: True
},
b_info: {
max_vcpus: 1,
avail_vcpus: [
0
],
max_memkb: 131072,
target_memkb: 131072,
shadow_memkb: 2048,
sched_params: {

},
claim_mode: True,
kernel: /home/root/xen/domu.image,
cmdline: earlyprintk=xenboot console=hvc0 root=/dev/xvda
debug=/bin/sh,
type.pv: {

}
},
disks: [
{
pdev_path: /dev/loop0,
vdev: xvda,
format: raw,
readwrite: 1
}
],
on_reboot: restart
}
}
libxl: debug: libxl_create.c:1544:do_domain_create: ao 0x42eb80: create:
how=(nil) callback=(nil) poller=0x42eb08
libxl: debug: libxl_arm.c:58:libxl__arch_domain_prepare_config:
Configure the domain
libxl: debug: libxl_arm.c:61:libxl__arch_domain_prepare_config:  -
Allocate 0 SPIs
libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
vdev=xvda spec.backend=unknown
libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
vdev=xvda, using backend phy
libxl: debug: libxl_create.c:949:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:329:libxl__bootloader_run: no
bootloader configured, using user supplied kernel
libxl: debug: libxl_event.c:652:libxl__ev_xswatch_deregister: watch
w=0x42a7cc: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline=earlyprintk=xenboot
console=hvc0 root=/dev/xvda debug=/bin/sh, features=(null)
libxl: debug: libxl_dom.c:630:libxl__build_pv: pv kernel mapped 0 path
/home/root/xen/domu.image
domainbuilder: detail: xc_dom_kernel_file:
filename=/home/root/xen/domu.image
domainbuilder: detail: xc_dom_malloc_filemap: 6116 kB
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.6, caps xen-3.0-armv7l
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 4
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary
loader ...
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64)
loader ...
domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel is not an
arm64 Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32)
loader ...
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l:
0x40008000 - 0x406012f8
libxl: debug: libxl_arm.c:571:libxl__arch_domain_init_hw_description:
constructing DTB for Xen version 4.6 guest
libxl: debug: libxl_arm.c:572:libxl__arch_domain_init_hw_description:  -
vGIC version: V2
libxl: debug: libxl_arm.c:333

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

[Peng Fan]

On 6/22/2015 10:02 PM, Julien Grall wrote:
 On 22/06/15 12:17, Peng Fan wrote:
 I add debug log in this piece of code:
 void __init sanity_check_meminfo(void)

 {

 phys_addr_t memblock_limit = 0;
 int i, j, highmem = 0;
 phys_addr_t vmalloc_limit = __pa(vmalloc_min - 1) + 1;


 printk(vmalloc_min virt %x phys %x\n, vmalloc_min - 1,
 __pa(vmalloc_min - 1));
 printk(vmalloc_limit %x\n, vmalloc_limit);

 If use 512M for Dom0, I found vmalloc_limit is 0xf80, vmalloc_min is
 0xef80, This comes to a question, why __pa(vmalloc_min - 1) + will
 make vmalloc_limit only 0xf80 which is less than 128M. the pv stub
 does some runtime fixup for virt_to_phys here.
 Since vmalloc_limit is small, then all other memory bank in my platform
 is recoginied as highmem, then arm_lowmem_limit is 0, then kernel panic:
 
 dma_contiguous_reserve_area(size 180, base , limit )
 CMA: failed to reserve 32 MiB
 Memory policy: Data cache writealloc
 Kernel panic - not syncing: ERROR: Failed to allocate 0x2000 bytes below
 0x0.
 
 0x - 0xef800 is about 264M. So I choose 256M as the Dom0
 memory size. I do not have clear idea about this, current I am trying to
 use xl to boot DomU, so just use 256M for Dom0 here.
 
 There use to be some issue with the way how the offset between physical
 and virtual address was computed.
 
 Do you use LPAE or short page table? Can you provide the xen log when
 DOM0 is using 512MB?

I did not enable LPAE for DOM0 kernel, use shor page table.
Following is the full log from uboot to kernel with DOM0 512M:

U-Boot 2015.04-rc4-00145-gf12a16e-dirty (Jun 19 2015 - 15:26:52)

CPU:   Freescale i.MX7D rev1.0 at 792 MHz
CPU:   Thermal invalid data, fuse: 0x1b800
CPU:   Temperature: Can't find sensor device
Reset cause: POR
Board: MX7D 12x12 LPDDR3 ARM2
I2C:   ready
DRAM:  2 GiB
PMIC: PFUZE300 DEV_ID=0x30 REV_ID=0x10
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Display: MCIMX28LCD (800x480)
Video: 800x480x24
In:serial
Out:   serial
Err:   serial
switch to partitions #0, OK
mmc0 is current device
Net:   FEC0
Error: FEC0 address not set.

Normal Boot
Hit any key to stop autoboot:  0
= setenv xen_addr_r 0x8000
= setenv bootargs console=dtuart
dtuart=/soc/aips-bus@3080/serial@3086 dom0_mem=256M
= fatload mmc 0:1 0x8000 xen.image
reading xen.image
754544 bytes read in 129 ms (5.6 MiB/s)
= setenv bootargs console=dtuart
dtuart=/soc/aips-bus@3080/serial@3086 dom0_mem=512M
= run loadfdt
reading imx7d-12x12-lpddr3-arm2.dtb
40966 bytes read in 26 ms (1.5 MiB/s)
= fatload mmc 0:1 0x8400 zImage
reading zImage
6250016 bytes read in 286 ms (20.8 MiB/s)
= setenv kernel_addr_r 0x8400
= setenv fdt_high 0x
= setenv fdt_addr 0x8300
= fdt addr ${fdt_addr} 0x4
= fdt resize
= fdt chosen
= fdt set /chosen \#address-cells 1
= fdt set /chosen \#size-cells 1
= fdt set /chosen/module@0 compatible xen,linux-zimage
xen,multiboot-module
= fdt set /chosen/module@0 reg ${kernel_addr_r} 0x${filesize}
= fdt set /chosen/module@0 bootargs console=hvc0 ro
root=/dev/mmcblk0p2 clk_ignore_unused uart_from_osc loglevel=8 earlyprintk
= bootz ${xen_addr_r} - ${fdt_addr}
Kernel image @ 0x8000 [ 0x00 - 0x101700 ]
## Flattened Device Tree blob at 8300
   Booting using the fdt blob at 0x8300
   reserving fdt memory region: addr=8300 size=b000
   Using Device Tree in place at 8300, end 8300dfff

Starting kernel ...

- UART enabled -
- CPU  booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 8000 - 
(XEN)
(XEN) MODULE[0]: 8300 - 8300b000 Device Tree
(XEN) MODULE[1]: 8400 - 845f5e20 Kernel
console=hvc0 ro root=/dev/mmcblk0p2 clk_ignore_unused uart_from_osc
loglevel=8 earlyprintk
(XEN)  RESVD[0]: 8300 - 8300b000
(XEN)
(XEN) Command line: console=dtuart
dtuart=/soc/aips-bus@3080/serial@3086 dom0_mem=512M
(XEN) Placing Xen at 0xffe0-0x0001
(XEN) Update BOOTMOD_XEN from 8000-80101701 =
ffe0-fff01701
(XEN) Xen heap: fa00-fe00 (16384 pages)
(XEN) Dom heap: 507904 pages
(XEN) Domain heap initialised
(XEN) Platform: i.MX 7Dual
(XEN) Looking for dtuart at /soc/aips-bus@3080/serial@3086,
options 
(XEN) imx-uart.c:226: xx 3086
(XEN) imx-uart.c:98: ===UFCR USR1 a01 2050
Xen 4.6-unstable
(XEN) Xen version 4.6-unstable (Freenix@(none))
(arm-poky-linux-gnueabi-gcc (GCC) 4.8.2) debug=y Fri Jun 19 18:30:50 CST
2015
(XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty
(XEN) Processor: 410fc075: ARM Limited, variant: 0x0, part 0xc07, rev 0x5
(XEN) 32-bit Execution:
(XEN)   Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

[Peng Fan]

Hi,

On 6/23/2015 9:36 PM, Julien Grall wrote:
 Hi,
 
 On 23/06/15 14:03, Peng Fan wrote:
 I did not enable LPAE for DOM0 kernel, use shor page table.
 Following is the full log from uboot to kernel with DOM0 512M:
 
 Which CONFIG_VMSPLIT_* do you use? Can you try to use another one? I
 remembered it had some effect on the offset between physical and virtual
 address.
 CONFIG_VMSPLIT_2G=y

CONFIG_PAGE_OFFSET=0x8000

ok. Will try 3G:1G split.
 
 Regards,
 
Thanks,
Peng.

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

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

[Peng Fan]

On 6/22/2015 6:20 PM, Julien Grall wrote:
 On 20/06/15 15:47, Peng Fan wrote:
 On 6/20/2015 10:08 PM, Peng Fan wrote:
 Hi Julien,

 On 6/20/2015 6:19 PM, Julien Grall wrote:
 Hi,

 On 19/06/2015 14:22, Peng Fan wrote:
 diff --git a/kernel/timer.c b/kernel/timer.c
 index 38f0d40..4a025cc 100644
 --- a/kernel/timer.c
 +++ b/kernel/timer.c
 @@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base
 *base)

  base-running_timer = timer;
  detach_expired_timer(timer, base);
 +   if (!fn) {
 +   printk(fn is null why\n); 
 This log only shows once. Not sure why fn is null and only once.
 +   continue;
 +   }

  if (irqsafe) {
  spin_unlock(base-lock);

 By any chance, does your board has a another timer (i.e other than the
 generic timer)?

 Yeah. There is a another timer whose rating is lower that generic timer.

 I would also track down to see who is adding this timer.

 But after apply the above kernel patch, Dom0 Linux can handle shell
 input.
 Just have another question, How can Dom0 handle DMA for arm.

 When Xen is allocating the RAM bank for DOM0 we use a direct mapping
 (i.e the Physical Address = Intermediate Address for the RAM). So DOM0
 can perform DMA as on baremetal.
 Thanks. Current, without using rootfs in sd card, my Dom0 kernel can
 boot using ramfs. But if with sdhc which use ADMA, Dom0 kernel will
 panic. Below is the log:

 sdhci: Secure Digital Host Controller Interface driver
 sdhci: Copyright(c) Pierre Ossman
 sdhci-pltfm: SDHCI platform and OF driver helper
 Unable to handle kernel NULL pointer dereference at virtual address 
 pgd = 80004000
 [] *pgd=
 Internal error: Oops: 5 [#1] PREEMPT SMP ARM
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.38-02383-g5ccf32b-dirty #22
 task: 84074000 ti: 84078000 task.ti: 84078000
 PC is at bitmap_clear+0xc0/0xdc
 LR is at bitmap_clear+0x54/0xdc
 pc : [8029deb8]lr : [8029de4c]psr: 2193
 sp : 84079d80  ip : 0001  fp : 
 r10: 00077fff  r9 : 0404  r8 : 0001
 r7 : 0001  r6 : 0001  r5 :   r4 : 
 r3 : 0001  r2 : 0001  r1 : 2193  r0 : 0015
 Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
 Control: 10c53c7d  Table: 8800406a  DAC: 0015
 Process swapper/0 (pid: 1, stack limit = 0x84078238)
 Stack: (0x84079d80 to 0x8407a000)
 9d80: 8113  87efa000 81109918 1000 800197f8 84128558
 00080008
 9da0: 84079dec 00d0 84bfeac0 84126c10 84126c10  0404
 
 9dc0:  0402   84126c10 80310ba8 
 
 9de0:  0524 84078000    
 84bfeac0
 9e00: 84bfe800 8000b407 07eb 8116e0f8  804ee81c 
 
 9e20:  84126c10 84c92010 84bfeac0  84126c10 84126c00
 84bfeac0
 9e40: 84078030 804f08e4 804f03d8 84126c10 fdfb 8115401c 8115401c
 
 9e60: 010f 80362330 803622ec 84126c10 811c8098  8115401c
 80360b1c
 9e80: 84126c10 8115401c 84126c44  80de1888 80360d28 
 8115401c
 9ea0: 80360c9c 8035f10c 8406965c 84123634 8115401c 84c8bf80 8112f3c8
 803602bc
 9ec0: 80d08314 8115401c 0006 8115401c 0006 8116e080 8116e080
 8036130c
 9ee0:  80e00f78 0006 800088dc 8400f900 80c94fe0 840bd480
 80735184
 9f00:  8116e080 150c 8012d430  811105b0 6113
 0001
 9f20: 87ffc576 8075ca38 010f 8004b0f0 80d66884 0006 87ffc583
 0006
 9f40: 811105a0 80e00f78 0006 8116e080 8116e080 80da150c 010f
 80df4154
 9f60: 80df4148 80da1c4c 0006 0006 80da150c 933c 84079f9c
 80731338
 9f80:   80727254    
 
 9fa0:  8072725c  8000ecf8   
 
 9fc0:       
 
 9fe0:     0013  933c
 933c
 [8029deb8] (bitmap_clear) from [800197f8]
 (__arm_dma_free.isra.18+0xe4/0x228)
 [800197f8] (__arm_dma_free.isra.18) from [80310ba8]
 (xen_swiotlb_free_coherent+0xfc/0x140)
 [80310ba8] (xen_swiotlb_free_coherent) from [804ee81c]
 (sdhci_add_host+0xb34/0xe64)
 [804ee81c] (sdhci_add_host) from [804f08e4]
 (sdhci_esdhc_imx_probe+0x50c/0x808)
 [804f08e4] (sdhci_esdhc_imx_probe) from [80362330]
 (platform_drv_probe+0x44/0xa4)
 [80362330] (platform_drv_probe) from [80360b1c]
 (driver_probe_device+0x120/0x25c)
 [80360b1c] (driver_probe_device) from [80360d28]
 (__driver_attach+0x8c/0x90)
 [80360d28] (__driver_attach) from [8035f10c]
 (bus_for_each_dev+0x60/0x94)
 [8035f10c] (bus_for_each_dev) from [803602bc]
 (bus_add_driver+0x148/0x1f0)
 [803602bc] (bus_add_driver) from [8036130c] (driver_register+0x78/0xf8)
 [8036130c

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

[Peng Fan]

Hi Julien,

On 6/20/2015 6:19 PM, Julien Grall wrote:
 Hi,

 On 19/06/2015 14:22, Peng Fan wrote:
 diff --git a/kernel/timer.c b/kernel/timer.c
 index 38f0d40..4a025cc 100644
 --- a/kernel/timer.c
 +++ b/kernel/timer.c
 @@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base
 *base)

  base-running_timer = timer;
  detach_expired_timer(timer, base);
 +   if (!fn) {
 +   printk(fn is null why\n); 
 This log only shows once. Not sure why fn is null and only once.
 +   continue;
 +   }

  if (irqsafe) {
  spin_unlock(base-lock);

 By any chance, does your board has a another timer (i.e other than the
 generic timer)?

Yeah. There is a another timer whose rating is lower that generic timer.

 I would also track down to see who is adding this timer.

 But after apply the above kernel patch, Dom0 Linux can handle shell
 input.
 Just have another question, How can Dom0 handle DMA for arm.

 When Xen is allocating the RAM bank for DOM0 we use a direct mapping
 (i.e the Physical Address = Intermediate Address for the RAM). So DOM0
 can perform DMA as on baremetal.
Thanks. Current, without using rootfs in sd card, my Dom0 kernel can
boot using ramfs. But if with sdhc which use ADMA, Dom0 kernel will
panic. Below is the log:

sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
Unable to handle kernel NULL pointer dereference at virtual address 
pgd = 80004000
[] *pgd=
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.38-02383-g5ccf32b-dirty #22
task: 84074000 ti: 84078000 task.ti: 84078000
PC is at bitmap_clear+0xc0/0xdc
LR is at bitmap_clear+0x54/0xdc
pc : [8029deb8]lr : [8029de4c]psr: 2193
sp : 84079d80  ip : 0001  fp : 
r10: 00077fff  r9 : 0404  r8 : 0001
r7 : 0001  r6 : 0001  r5 :   r4 : 
r3 : 0001  r2 : 0001  r1 : 2193  r0 : 0015
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 8800406a  DAC: 0015
Process swapper/0 (pid: 1, stack limit = 0x84078238)
Stack: (0x84079d80 to 0x8407a000)
9d80: 8113  87efa000 81109918 1000 800197f8 84128558
00080008
9da0: 84079dec 00d0 84bfeac0 84126c10 84126c10  0404

9dc0:  0402   84126c10 80310ba8 

9de0:  0524 84078000    
84bfeac0
9e00: 84bfe800 8000b407 07eb 8116e0f8  804ee81c 

9e20:  84126c10 84c92010 84bfeac0  84126c10 84126c00
84bfeac0
9e40: 84078030 804f08e4 804f03d8 84126c10 fdfb 8115401c 8115401c

9e60: 010f 80362330 803622ec 84126c10 811c8098  8115401c
80360b1c
9e80: 84126c10 8115401c 84126c44  80de1888 80360d28 
8115401c
9ea0: 80360c9c 8035f10c 8406965c 84123634 8115401c 84c8bf80 8112f3c8
803602bc
9ec0: 80d08314 8115401c 0006 8115401c 0006 8116e080 8116e080
8036130c
9ee0:  80e00f78 0006 800088dc 8400f900 80c94fe0 840bd480
80735184
9f00:  8116e080 150c 8012d430  811105b0 6113
0001
9f20: 87ffc576 8075ca38 010f 8004b0f0 80d66884 0006 87ffc583
0006
9f40: 811105a0 80e00f78 0006 8116e080 8116e080 80da150c 010f
80df4154
9f60: 80df4148 80da1c4c 0006 0006 80da150c 933c 84079f9c
80731338
9f80:   80727254    

9fa0:  8072725c  8000ecf8   

9fc0:       

9fe0:     0013  933c
933c
[8029deb8] (bitmap_clear) from [800197f8]
(__arm_dma_free.isra.18+0xe4/0x228)
[800197f8] (__arm_dma_free.isra.18) from [80310ba8]
(xen_swiotlb_free_coherent+0xfc/0x140)
[80310ba8] (xen_swiotlb_free_coherent) from [804ee81c]
(sdhci_add_host+0xb34/0xe64)
[804ee81c] (sdhci_add_host) from [804f08e4]
(sdhci_esdhc_imx_probe+0x50c/0x808)
[804f08e4] (sdhci_esdhc_imx_probe) from [80362330]
(platform_drv_probe+0x44/0xa4)
[80362330] (platform_drv_probe) from [80360b1c]
(driver_probe_device+0x120/0x25c)
[80360b1c] (driver_probe_device) from [80360d28]
(__driver_attach+0x8c/0x90)
[80360d28] (__driver_attach) from [8035f10c]
(bus_for_each_dev+0x60/0x94)
[8035f10c] (bus_for_each_dev) from [803602bc]
(bus_add_driver+0x148/0x1f0)
[803602bc] (bus_add_driver) from [8036130c] (driver_register+0x78/0xf8)
[8036130c] (driver_register) from [800088dc]
(do_one_initcall+0xf8/0x144)
[800088dc] (do_one_initcall) from [80da1c4c]
(kernel_init_freeable+0x138/0x1d8)
[80da1c4c] (kernel_init_freeable) from [8072725c] (kernel_init

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

[Peng Fan]

Hi

On 6/20/2015 10:08 PM, Peng Fan wrote:
 Hi Julien,
 
 On 6/20/2015 6:19 PM, Julien Grall wrote:
 Hi,

 On 19/06/2015 14:22, Peng Fan wrote:
 diff --git a/kernel/timer.c b/kernel/timer.c
 index 38f0d40..4a025cc 100644
 --- a/kernel/timer.c
 +++ b/kernel/timer.c
 @@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base
 *base)

  base-running_timer = timer;
  detach_expired_timer(timer, base);
 +   if (!fn) {
 +   printk(fn is null why\n); 
 This log only shows once. Not sure why fn is null and only once.
 +   continue;
 +   }

  if (irqsafe) {
  spin_unlock(base-lock);

 By any chance, does your board has a another timer (i.e other than the
 generic timer)?
 
 Yeah. There is a another timer whose rating is lower that generic timer.

 I would also track down to see who is adding this timer.

 But after apply the above kernel patch, Dom0 Linux can handle shell
 input.
 Just have another question, How can Dom0 handle DMA for arm.

 When Xen is allocating the RAM bank for DOM0 we use a direct mapping
 (i.e the Physical Address = Intermediate Address for the RAM). So DOM0
 can perform DMA as on baremetal.
 Thanks. Current, without using rootfs in sd card, my Dom0 kernel can
 boot using ramfs. But if with sdhc which use ADMA, Dom0 kernel will
 panic. Below is the log:
 
 sdhci: Secure Digital Host Controller Interface driver
 sdhci: Copyright(c) Pierre Ossman
 sdhci-pltfm: SDHCI platform and OF driver helper
 Unable to handle kernel NULL pointer dereference at virtual address 
 pgd = 80004000
 [] *pgd=
 Internal error: Oops: 5 [#1] PREEMPT SMP ARM
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.38-02383-g5ccf32b-dirty #22
 task: 84074000 ti: 84078000 task.ti: 84078000
 PC is at bitmap_clear+0xc0/0xdc
 LR is at bitmap_clear+0x54/0xdc
 pc : [8029deb8]lr : [8029de4c]psr: 2193
 sp : 84079d80  ip : 0001  fp : 
 r10: 00077fff  r9 : 0404  r8 : 0001
 r7 : 0001  r6 : 0001  r5 :   r4 : 
 r3 : 0001  r2 : 0001  r1 : 2193  r0 : 0015
 Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
 Control: 10c53c7d  Table: 8800406a  DAC: 0015
 Process swapper/0 (pid: 1, stack limit = 0x84078238)
 Stack: (0x84079d80 to 0x8407a000)
 9d80: 8113  87efa000 81109918 1000 800197f8 84128558
 00080008
 9da0: 84079dec 00d0 84bfeac0 84126c10 84126c10  0404
 
 9dc0:  0402   84126c10 80310ba8 
 
 9de0:  0524 84078000    
 84bfeac0
 9e00: 84bfe800 8000b407 07eb 8116e0f8  804ee81c 
 
 9e20:  84126c10 84c92010 84bfeac0  84126c10 84126c00
 84bfeac0
 9e40: 84078030 804f08e4 804f03d8 84126c10 fdfb 8115401c 8115401c
 
 9e60: 010f 80362330 803622ec 84126c10 811c8098  8115401c
 80360b1c
 9e80: 84126c10 8115401c 84126c44  80de1888 80360d28 
 8115401c
 9ea0: 80360c9c 8035f10c 8406965c 84123634 8115401c 84c8bf80 8112f3c8
 803602bc
 9ec0: 80d08314 8115401c 0006 8115401c 0006 8116e080 8116e080
 8036130c
 9ee0:  80e00f78 0006 800088dc 8400f900 80c94fe0 840bd480
 80735184
 9f00:  8116e080 150c 8012d430  811105b0 6113
 0001
 9f20: 87ffc576 8075ca38 010f 8004b0f0 80d66884 0006 87ffc583
 0006
 9f40: 811105a0 80e00f78 0006 8116e080 8116e080 80da150c 010f
 80df4154
 9f60: 80df4148 80da1c4c 0006 0006 80da150c 933c 84079f9c
 80731338
 9f80:   80727254    
 
 9fa0:  8072725c  8000ecf8   
 
 9fc0:       
 
 9fe0:     0013  933c
 933c
 [8029deb8] (bitmap_clear) from [800197f8]
 (__arm_dma_free.isra.18+0xe4/0x228)
 [800197f8] (__arm_dma_free.isra.18) from [80310ba8]
 (xen_swiotlb_free_coherent+0xfc/0x140)
 [80310ba8] (xen_swiotlb_free_coherent) from [804ee81c]
 (sdhci_add_host+0xb34/0xe64)
 [804ee81c] (sdhci_add_host) from [804f08e4]
 (sdhci_esdhc_imx_probe+0x50c/0x808)
 [804f08e4] (sdhci_esdhc_imx_probe) from [80362330]
 (platform_drv_probe+0x44/0xa4)
 [80362330] (platform_drv_probe) from [80360b1c]
 (driver_probe_device+0x120/0x25c)
 [80360b1c] (driver_probe_device) from [80360d28]
 (__driver_attach+0x8c/0x90)
 [80360d28] (__driver_attach) from [8035f10c]
 (bus_for_each_dev+0x60/0x94)
 [8035f10c] (bus_for_each_dev) from [803602bc]
 (bus_add_driver+0x148/0x1f0)
 [803602bc] (bus_add_driver) from [8036130c] (driver_register+0x78/0xf8)
 [8036130c] (driver_register) from [800088dc]
 (do_one_initcall+0xf8/0x144

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

[Peng Fan]

Hi,

On 6/18/2015 10:54 PM, Ian Campbell wrote:

On Thu, 2015-06-18 at 22:09 +0800, Peng Fan wrote:

Hi,

I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have
no clear idea about why Dom0 kernel panic.

Have you confirmed that this same kernel runs reliably natively on this
platform?
Yeah. With XEN related configuration, the kernel can run natively on the 
platform.



[...]

/ # Unable to handle kernel NULL pointer dereference at virtual address

pgd = 84f1c000
[] *pgd=8cf15831, *pte=, *ppte=
Internal error: Oops: 8007 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 89 Comm: sh Not tainted 3.14.28-01780-g281e5c1-dirty #269
task: 84c07a80 ti: 84f02000 task.ti: 84f02000
PC is at 0x0
LR is at call_timer_fn.isra.33+0x24/0x88
pc : []lr : [80038b38]psr: 2113

Your kernel has jumped to address 0x0 for some reason. You should use
gdb or something to examine you vmlinux file and try and figure out what
LR is doing, which may give you a hint as to why it is apparently
jumping to address zero.
I add such piece of code the linux kernel version 3.14.38. The panic 
disappears.


diff --git a/kernel/timer.c b/kernel/timer.c
index 38f0d40..4a025cc 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base 
*base)


base-running_timer = timer;
detach_expired_timer(timer, base);
+   if (!fn) {
+   printk(fn is null why\n);  
This log only shows once. Not sure why fn is null and only once.

+   continue;
+   }

if (irqsafe) {
spin_unlock(base-lock);



(XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty

What changes have you made to your version of Xen? c01e139 is not an
upstream commit.
I only add an uart driver and a platform file. The platform part is very 
simple:

PLATFORM_START(imx7d, i.MX 7Dual)
.compatible = imx7d_dt_compat,
.smp_init = imx7d_smp_init,  -- Actually I disabled this, since in 
dts, only one cpu node enabled.

.cpu_up = cpu_up_send_sgi,
/* Use IRAM base, not sure */
#if 0
.dom0_gnttab_start = 0x0090,
.dom0_gnttab_size = 0x2,
#endif
PLATFORM_END

I am not sure whether this realted to timer, the timer dts:

I think it looks like a software timer thing in the kernel rather than a
h/w timer thing.


The Dom0 kernel is also configured with  CONFIG_ARM_ARCH_TIMER=y, will
this incur errors? Or should Dom0 kernel not use arm arch timer?

Guests on Xen (including dom0) _should_ be using the arch timer.

Ian.

Not sure whether it relates to the uart driver that Julien suspected. 
But after apply the above kernel patch, Dom0 Linux can handle shell input.

Just have another question, How can Dom0 handle DMA for arm.

Thanks,
Peng.

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

[Xen-devel] Dom0 kernel panic when porting xen to new arm soc

[Peng Fan]

Hi,

I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have 
no clear idea about why Dom0 kernel panic.


Detail log see below:

U-Boot 2015.04-rc4-00145-gf12a16e (Jun 18 2015 - 10:38:06)

CPU: Freescale i.MX7D rev1.0 at 792 MHz
CPU: Thermal invalid data, fuse: 0x1b800
CPU: Temperature: Can't find sensor device
Reset cause: POR
Board: MX7D 12x12 LPDDR3 ARM2
I2C: ready
DRAM: 2 GiB
PMIC: PFUZE300 DEV_ID=0x30 REV_ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Display: MCIMX28LCD (800x480)
Video: 800x480x24
In: serial
Out: serial
Err: serial
switch to partitions #0, OK
mmc0 is current device
Net: FEC0
Error: FEC0 address not set.

Normal Boot
Hit any key to stop autoboot:  0
= setenv xen_addr_r 0x8000
= setenv bootargs console=dtuart 
dtuart=/soc/aips-bus@3080/serial@3086 dom0_mem=128M

= fatload mmc 0:1 0x8000 xen.image
reading xen.image
754544 bytes read in 129 ms (5.6 MiB/s)
= fatload mmc 0:1 0x8300 imx7d-12x12-arm2.dtb
reading imx7d-12x12-arm2.dtb
37498 bytes read in 21 ms (1.7 MiB/s)
= fatload mmc 0:1 0x8400 zImage
reading zImage
9307256 bytes read in 420 ms (21.1 MiB/s)
= setenv kernel_addr_r 0x8400
= setenv fdt_high 0x
= setenv fdt_addr 0x8300
= fdt addr ${fdt_addr} 0x4
= fdt resize
= fdt chosen
= fdt set /chosen \#address-cells 1
= fdt set /chosen \#size-cells 1
= fdt mknod /chosen module@0
= fdt set /chosen/module@0 compatible xen,linux-zimage 
xen,multiboot-module

= fdt set /chosen/module@0 reg ${kernel_addr_r} 0x${filesize}
= fdt set /chosen/module@0 bootargs console=hvc0 ro 
root=/dev/mmcblk0p2 clk_ignore_unused uart_from_osc

= bootz ${xen_addr_r} - ${fdt_addr}
Kernel image @ 0x8000 [ 0x00 - 0x101700 ]
## Flattened Device Tree blob at 8300
Booting using the fdt blob at 0x8300
reserving fdt memory region: addr=8300 size=a000
Using Device Tree in place at 8300, end 8300cfff

Starting kernel ...

Xen 4.6-unstable
(XEN) Xen version 4.6-unstable (Freenix@(none)) 
(arm-poky-linux-gnueabi-gcc (GCC) 4.8.2) debug=y Thu Jun 18 12:32:18 CST 
2015

(XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty
(XEN) Processor: 410fc075: ARM Limited, variant: 0x0, part 0xc07, rev 0x5
(XEN) 32-bit Execution:
(XEN) Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 02010555
(XEN) Auxiliary Features: 
(XEN) Memory Model Features: 10101105 4000 0124 02102211
(XEN) ISA Features: 02101110 13112111 21232041 2131 10011142 
(XEN) Set Secondary entry to ffe0004c (0020004c)
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=31001000
(XEN) gic_cpu_addr=31002000
(XEN) gic_hyp_addr=31004000
(XEN) gic_vcpu_addr=31006000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 160 lines, 2 cpus, secure (IID 0100143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) imx-uart.c:117: imx_uart_init_postirq
(XEN) Allocated console ring of 16 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Brought up 1 CPUs
(XEN) P2M: 40-bit IPA
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558
(XEN) I/O virtualisation disabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) domain_build.c:1383: idle loop
(XEN) Loading kernel from boot module @ 8400
(XEN) Allocating 1:1 mappings totalling 128MB for dom0:
(XEN) BANK[0] 0x008800-0x009000 (128MB)
(XEN) Loading zImage from 8400 to 
8f60-8fee0478

(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x8f40-0x8f409239
(XEN) regs - pc = 0x8f60
(XEN) it is 32 bit machine
(XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs
(XEN) done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input - DOM0 (type 'CTRL-a' three times to switch 
input to Xen)

(XEN) Freed 284kB init memory.
Booting Linux on physical CPU 0x0
Linux version 3.14.28-01780-g281e5c1-dirty (Freenix@linux-vaa1) (gcc 
version 4.8.2 (GCC) ) #269 SMP PREEMPT Thu Jun 18 17:30:11 CST 2015

CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Freescale i.MX7 LPDDR3 12x12 ARM2 Board
cma: CMA: failed to reserve 320 MiB
Memory policy: Data cache writealloc
psci: probing function IDs from device-tree
PERCPU: Embedded 8 pages/cpu @87ee1000 s9600 r8192 d14976 u32768
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 32512
Kernel command line: console=hvc0 ro root=/dev/mmcblk0p2 
clk_ignore_unused uart_from_osc

PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768