Re: Testing xen-arm on Arndale

Re: Testing xen-arm on Arndale

[Anthony PERARD]

CC'ing xen-devel, where the ARMv7+ port of Xen is happening.

On 25/03/13 09:46, Sengul Thomas wrote:
> Hello Anthony,
> I'm hoping your are the right person to ask about xen-arm on Arndale.
> 
> I've tried the following wiki to run xen-arm on Arndale and it crashes while booting dom0.
> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Arndale
> 
> Here goes some part of log (attached the full log):
> 
> (XEN) Guest data abort: Translation fault at level 2
> (XEN)     gva=23c1901c
> (XEN)     gpa=0000000023c1901c
> (XEN)     size=2 sign=0 write=1 reg=0
> (XEN)     eat=0 cm=0 s1ptw=0 dfsc=6
> (XEN) dom0 IPA 0x0000000023c1901c
> (XEN) P2M @ 02ffbfc0 mfn:0xbfdfe
> (XEN) 1ST[0x0] = 0x00000000bfdfd6ff
> (XEN) 2ND[0x11e] = 0x0000000000000000
> (XEN) ----[ Xen-4.3-unstable  arm32  debug=y  Tainted:    C ]----
> (XEN) CPU:    0
> (XEN) PC:     4000893c
> 
> Looks like dom0 tried to access at 23c1901c and page fault happens.
> I've got no idea how to figure out what is going on.
> Could you tell me any helpful tips to move on further?

Sorry, I don't know where this address come from. So, let's look at what
Linux is doing.

> One more question:
> How can I look up the function that PC is pointing (4000893c)?

There is a programme called `addr2line` and you can use it like that:
$ addr2line -e vmlinux 4000893c
and it will give a source file and hopefully a line.

Then, if this does not help, there is always objdump to disassemble and
get addresses associated with instructions and function names.
So I do `arm-unknown-linux-gnueabi-objdump -d vmlinux | less`  and
search for the PC.

There is 2 vmlinux, one (linux.git/arch/arm/boot/compressed/vmlinux)
that decompress the second one (linux.git/vmlinux).

Regards,

-- 
Anthony PERARD

Re: Testing xen-arm on Arndale

[Julien Grall]

On 03/26/2013 04:04 PM, Anthony PERARD wrote:

> CC'ing xen-devel, where the ARMv7+ port of Xen is happening.
> 
> On 25/03/13 09:46, Sengul Thomas wrote:
>> Hello Anthony,
>> I'm hoping your are the right person to ask about xen-arm on Arndale.
>>
>> I've tried the following wiki to run xen-arm on Arndale and it crashes while booting dom0.
>> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Arndale
>>
>> Here goes some part of log (attached the full log):
>>
>> (XEN) Guest data abort: Translation fault at level 2
>> (XEN)     gva=23c1901c
>> (XEN)     gpa=0000000023c1901c
>> (XEN)     size=2 sign=0 write=1 reg=0
>> (XEN)     eat=0 cm=0 s1ptw=0 dfsc=6
>> (XEN) dom0 IPA 0x0000000023c1901c
>> (XEN) P2M @ 02ffbfc0 mfn:0xbfdfe
>> (XEN) 1ST[0x0] = 0x00000000bfdfd6ff
>> (XEN) 2ND[0x11e] = 0x0000000000000000
>> (XEN) ----[ Xen-4.3-unstable  arm32  debug=y  Tainted:    C ]----
>> (XEN) CPU:    0
>> (XEN) PC:     4000893c
>>
>> Looks like dom0 tried to access at 23c1901c and page fault happens.
>> I've got no idea how to figure out what is going on.
>> Could you tell me any helpful tips to move on further?

It's seems the kernel is unable to start when the zImage is loaded at
0x40007000. If you change this address, both in U-Boot and the DTS, by
0x60000000 the kernel is able to start.

I updated wiki page with the new instructions and the new device tree.

Cheers,

Julien

Re: Testing xen-arm on Arndale

[Sengul Thomas]

[-- Attachment #1.1: Type: text/plain, Size: 1661 bytes --]

Thanks Julien, it works now!
Now, I can start /bin/bash as Linux init process :)


Sincerely,
Thomas


On Wed, Mar 27, 2013 at 4:29 AM, Julien Grall <julien.grall@citrix.com>wrote:

> On 03/26/2013 04:04 PM, Anthony PERARD wrote:
>
> > CC'ing xen-devel, where the ARMv7+ port of Xen is happening.
> >
> > On 25/03/13 09:46, Sengul Thomas wrote:
> >> Hello Anthony,
> >> I'm hoping your are the right person to ask about xen-arm on Arndale.
> >>
> >> I've tried the following wiki to run xen-arm on Arndale and it crashes
> while booting dom0.
> >> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Arndale
> >>
> >> Here goes some part of log (attached the full log):
> >>
> >> (XEN) Guest data abort: Translation fault at level 2
> >> (XEN)     gva=23c1901c
> >> (XEN)     gpa=0000000023c1901c
> >> (XEN)     size=2 sign=0 write=1 reg=0
> >> (XEN)     eat=0 cm=0 s1ptw=0 dfsc=6
> >> (XEN) dom0 IPA 0x0000000023c1901c
> >> (XEN) P2M @ 02ffbfc0 mfn:0xbfdfe
> >> (XEN) 1ST[0x0] = 0x00000000bfdfd6ff
> >> (XEN) 2ND[0x11e] = 0x0000000000000000
> >> (XEN) ----[ Xen-4.3-unstable  arm32  debug=y  Tainted:    C ]----
> >> (XEN) CPU:    0
> >> (XEN) PC:     4000893c
> >>
> >> Looks like dom0 tried to access at 23c1901c and page fault happens.
> >> I've got no idea how to figure out what is going on.
> >> Could you tell me any helpful tips to move on further?
>
> It's seems the kernel is unable to start when the zImage is loaded at
> 0x40007000. If you change this address, both in U-Boot and the DTS, by
> 0x60000000 the kernel is able to start.
>
> I updated wiki page with the new instructions and the new device tree.
>
> Cheers,
>
> Julien
>
>

[-- Attachment #1.2: Type: text/html, Size: 2438 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [XenARM] Testing xen-arm on Arndale

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

Great! Thanks Julien for updating the wiki.

On Wed, 27 Mar 2013, Sengul Thomas wrote:
> Thanks Julien, it works now!
> Now, I can start /bin/bash as Linux init process :)
> 
> 
> Sincerely,
> Thomas
> 
> 
> On Wed, Mar 27, 2013 at 4:29 AM, Julien Grall <julien.grall@citrix.com> wrote:
>       On 03/26/2013 04:04 PM, Anthony PERARD wrote:
> 
>       > CC'ing xen-devel, where the ARMv7+ port of Xen is happening.
>       >
>       > On 25/03/13 09:46, Sengul Thomas wrote:
>       >> Hello Anthony,
>       >> I'm hoping your are the right person to ask about xen-arm on Arndale.
>       >>
>       >> I've tried the following wiki to run xen-arm on Arndale and it crashes while booting dom0.
>       >> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Arndale
>       >>
>       >> Here goes some part of log (attached the full log):
>       >>
>       >> (XEN) Guest data abort: Translation fault at level 2
>       >> (XEN)     gva=23c1901c
>       >> (XEN)     gpa=0000000023c1901c
>       >> (XEN)     size=2 sign=0 write=1 reg=0
>       >> (XEN)     eat=0 cm=0 s1ptw=0 dfsc=6
>       >> (XEN) dom0 IPA 0x0000000023c1901c
>       >> (XEN) P2M @ 02ffbfc0 mfn:0xbfdfe
>       >> (XEN) 1ST[0x0] = 0x00000000bfdfd6ff
>       >> (XEN) 2ND[0x11e] = 0x0000000000000000
>       >> (XEN) ----[ Xen-4.3-unstable  arm32  debug=y  Tainted:    C ]----
>       >> (XEN) CPU:    0
>       >> (XEN) PC:     4000893c
>       >>
>       >> Looks like dom0 tried to access at 23c1901c and page fault happens.
>       >> I've got no idea how to figure out what is going on.
>       >> Could you tell me any helpful tips to move on further?
> 
> It's seems the kernel is unable to start when the zImage is loaded at
> 0x40007000. If you change this address, both in U-Boot and the DTS, by
> 0x60000000 the kernel is able to start.
> 
> I updated wiki page with the new instructions and the new device tree.
> 
> Cheers,
> 
> Julien
> 
> 
> 
> 

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Testing xen-arm on Arndale

[Sengul Thomas]

[-- Attachment #1.1: Type: text/plain, Size: 1851 bytes --]

I'm using the root file system from "
http://snapshots.linaro.org/quantal/images/server/" and it lacks a lot of
stuffs for running domU.

Are you also using RFS above or another one?

Also, if you have a working RFS that can launch domU, could you post it on
wiki?

Thanks always,
Thomas





On Wed, Mar 27, 2013 at 4:29 AM, Julien Grall <julien.grall@citrix.com>wrote:

> On 03/26/2013 04:04 PM, Anthony PERARD wrote:
>
> > CC'ing xen-devel, where the ARMv7+ port of Xen is happening.
> >
> > On 25/03/13 09:46, Sengul Thomas wrote:
> >> Hello Anthony,
> >> I'm hoping your are the right person to ask about xen-arm on Arndale.
> >>
> >> I've tried the following wiki to run xen-arm on Arndale and it crashes
> while booting dom0.
> >> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Arndale
> >>
> >> Here goes some part of log (attached the full log):
> >>
> >> (XEN) Guest data abort: Translation fault at level 2
> >> (XEN)     gva=23c1901c
> >> (XEN)     gpa=0000000023c1901c
> >> (XEN)     size=2 sign=0 write=1 reg=0
> >> (XEN)     eat=0 cm=0 s1ptw=0 dfsc=6
> >> (XEN) dom0 IPA 0x0000000023c1901c
> >> (XEN) P2M @ 02ffbfc0 mfn:0xbfdfe
> >> (XEN) 1ST[0x0] = 0x00000000bfdfd6ff
> >> (XEN) 2ND[0x11e] = 0x0000000000000000
> >> (XEN) ----[ Xen-4.3-unstable  arm32  debug=y  Tainted:    C ]----
> >> (XEN) CPU:    0
> >> (XEN) PC:     4000893c
> >>
> >> Looks like dom0 tried to access at 23c1901c and page fault happens.
> >> I've got no idea how to figure out what is going on.
> >> Could you tell me any helpful tips to move on further?
>
> It's seems the kernel is unable to start when the zImage is loaded at
> 0x40007000. If you change this address, both in U-Boot and the DTS, by
> 0x60000000 the kernel is able to start.
>
> I updated wiki page with the new instructions and the new device tree.
>
> Cheers,
>
> Julien
>
>

[-- Attachment #1.2: Type: text/html, Size: 2745 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Testing xen-arm on Arndale

[Sengul Thomas]

[-- Attachment #1.1: Type: text/plain, Size: 3012 bytes --]

I somehow end-up running "xl list" in dom0 and it gives the following
results:

    root@localhost:/root/make_test# xl list
    Name                                        ID   Mem VCPUs    State
Time(s)
    (null)                                       0   256     1
r-----    8071.1

Looks like the root file system in the above link is just fine :-)
Just have to enable all xen-related features while building linux (e.g.,
xen-driver-support and xen-network-device-frontend-driver).


Now I am going to run DomU and have a question regarding the following wiki
(DomU kernel and DTS section):
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions

(Question) In the configuration file, there is a line:
        kernel = "/root/kernel"
I think this one is pointing to some kernel image used for booting and how
can I build this image? (for instance, can I use the same kernel source for
dom0?)

Also, is there a helpful wiki link that describes manually building domU
image?

Sincerely,
Thomas



On Wed, Mar 27, 2013 at 5:23 PM, Sengul Thomas <thomas.sengul@gmail.com>wrote:

> I'm using the root file system from "
> http://snapshots.linaro.org/quantal/images/server/" and it lacks a lot of
> stuffs for running domU.
>
> Are you also using RFS above or another one?
>
> Also, if you have a working RFS that can launch domU, could you post it on
> wiki?
>
> Thanks always,
> Thomas
>
>
>
>
>
> On Wed, Mar 27, 2013 at 4:29 AM, Julien Grall <julien.grall@citrix.com>wrote:
>
>> On 03/26/2013 04:04 PM, Anthony PERARD wrote:
>>
>> > CC'ing xen-devel, where the ARMv7+ port of Xen is happening.
>> >
>> > On 25/03/13 09:46, Sengul Thomas wrote:
>> >> Hello Anthony,
>> >> I'm hoping your are the right person to ask about xen-arm on Arndale.
>> >>
>> >> I've tried the following wiki to run xen-arm on Arndale and it crashes
>> while booting dom0.
>> >>
>> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Arndale
>> >>
>> >> Here goes some part of log (attached the full log):
>> >>
>> >> (XEN) Guest data abort: Translation fault at level 2
>> >> (XEN)     gva=23c1901c
>> >> (XEN)     gpa=0000000023c1901c
>> >> (XEN)     size=2 sign=0 write=1 reg=0
>> >> (XEN)     eat=0 cm=0 s1ptw=0 dfsc=6
>> >> (XEN) dom0 IPA 0x0000000023c1901c
>> >> (XEN) P2M @ 02ffbfc0 mfn:0xbfdfe
>> >> (XEN) 1ST[0x0] = 0x00000000bfdfd6ff
>> >> (XEN) 2ND[0x11e] = 0x0000000000000000
>> >> (XEN) ----[ Xen-4.3-unstable  arm32  debug=y  Tainted:    C ]----
>> >> (XEN) CPU:    0
>> >> (XEN) PC:     4000893c
>> >>
>> >> Looks like dom0 tried to access at 23c1901c and page fault happens.
>> >> I've got no idea how to figure out what is going on.
>> >> Could you tell me any helpful tips to move on further?
>>
>> It's seems the kernel is unable to start when the zImage is loaded at
>> 0x40007000. If you change this address, both in U-Boot and the DTS, by
>> 0x60000000 the kernel is able to start.
>>
>> I updated wiki page with the new instructions and the new device tree.
>>
>> Cheers,
>>
>> Julien
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 4571 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Testing xen-arm on Arndale

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 2431 bytes --]

On Wed, 27 Mar 2013, Sengul Thomas wrote:
> I somehow end-up running "xl list" in dom0 and it gives the following results:
> 
>     root@localhost:/root/make_test# xl list
>     Name                                        ID   Mem VCPUs    State    Time(s)
>     (null)                                       0   256     1     r-----    8071.1
> 
> Looks like the root file system in the above link is just fine :-)
> Just have to enable all xen-related features while building linux (e.g., xen-driver-support and
> xen-network-device-frontend-driver).
> 
> 
> Now I am going to run DomU and have a question regarding the following wiki (DomU kernel and DTS section):
> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions
> 
> (Question) In the configuration file, there is a line:
>         kernel = "/root/kernel"
> I think this one is pointing to some kernel image used for booting and how can I build this image? (for instance, can I use the
> same kernel source for dom0?)

Right, in fact that section of the wiki says:

"where the kernel is actually a Linux zImage with an appended
xenvm-4.2.dtb."

In order to build /root/kernel, you just need to build a Linux tree v3.7
or greater, build the dtbs, then:

cat arch/arm/boot/zImage arch/arm/boot/dts/xenvm-4.2.dtb > kernel


> Also, is there a helpful wiki link that describes manually building domU image?

Not really, I could create one I guess.
Right now I am using a simple script to create a domU filesystem from
busybox and other libraries in dom0 on the fly:

#!/bin/bash

mount -t tmpfs tmpfs /mnt
dd if=/dev/zero of=/mnt/file bs=4096 count=2048
losetup /dev/loop0 /mnt/file
mkfs.ext2 /dev/loop0
mount /dev/loop0 /mnt2
mkdir -p /mnt2/proc
mkdir -p /mnt2/sys
mkdir -p /mnt2/bin
mkdir -p /mnt2/sbin
mkdir -p /mnt2/lib
mkdir -p /mnt2/lib/arm-linux-gnueabihf
cp -r /bin/busybox /mnt2/bin
cp -r /lib/ld-linux-armhf.so.3 /mnt2/lib
cp -r /lib/arm-linux-gnueabihf/libc* /mnt2/lib/arm-linux-gnueabihf
cp -r /lib/arm-linux-gnueabihf/ld-* /mnt2/lib/arm-linux-gnueabihf
#cp /root/network-script /mnt2
#cp -r /sbin/dhcpcd3 /mnt2/sbin/dhcpcd
cd /mnt2/bin
ln -s busybox sh
ln -s busybox ash
ln -s busybox bash
ln -s busybox udhcpc
ln -s busybox httpd
ln -s busybox wget
cd /
umount /mnt2
sync

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Testing xen-arm on Arndale

[Sengul Thomas]

On Wed, Mar 27, 2013 at 8:57 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 27 Mar 2013, Sengul Thomas wrote:

>
> In order to build /root/kernel, you just need to build a Linux tree v3.7
> or greater, build the dtbs, then:
>
> cat arch/arm/boot/zImage arch/arm/boot/dts/xenvm-4.2.dtb > kernel
>

Oh! It literally is appending :-)


>
>> Also, is there a helpful wiki link that describes manually building domU image?
>
> Not really, I could create one I guess.
> Right now I am using a simple script to create a domU filesystem from
> busybox and other libraries in dom0 on the fly:
>

Thanks for the script. But, at the moment, I'm just hoping to see some
booting messages poping out from console.
When I try 'xl create <some conf> -c', rather than booting messages,
following messages (attached the full log) pop out and domU dies.

(XEN) Guest data abort: Translation fault at level 1
(XEN)     gva=40004000
(XEN)     gpa=0000000040004000
(XEN)     instruction syndrome invalid
(XEN)     eat=0 cm=0 s1ptw=0 dfsc=5
(XEN) dom14 IPA 0x0000000040004000
(XEN) P2M @ 02ff9d40 mfn:0xbfcea
(XEN) 1ST[0x1] = 0x0000000000000000
(XEN) ----[ Xen-4.3-unstable  arm32  debug=y  Tainted:    C ]----
(XEN) CPU:    0
(XEN) PC:     80008338
(XEN) CPSR:   800001d3 MODE:SVC
(XEN)      R0: 40004000 R1: 00000c12 R2: 40008000 R3: 40004000
(XEN)      R4: 40008000 R5: 00000000 R6: 0000000e R7: ffffffff
(XEN)      R8: ffffffff R9: 40000000 R10:50000000 R11:10201105 R12:800080a8

After digging into domU Linux kernel, it turns out that someone tries
to access 0x40004000 while uncompressing zImage.
This is quite weird because, when I checked the page table setup for
domU, it starts mapping from 0x80000000 and 0x40004000 address is not
supposed to be accessed.
Do you guys have any hint about this?

Additionally, it turns out that if we try to use Linux kernel 3.8.4
(from https://www.kernel.org/), we do not see the above page-fault
messages and we can see domU is running using xl as follows:

    root@localhost:~# xl list
    Name                                        ID   Mem VCPUs
State    Time(s)
    Domain-0                                     0   256     1
r-----    2009.2
    win                                          1   128     1
------    1898.6

Unfortunately, I'm not still seeing any booting messages:

    root@localhost:~# xl create xl.conf -c
    Parsing config from xl.conf
    Daemon running with PID 1802
    <hangs here>

I'm running xenconsoled with the following command:

    root@localhost:~# xenconsoled --log=all

Then, I can see xenconsoled running in ps:

    root@localhost:~# ps ax | grep xenconsoled
     1767 ?        SLl    0:00 xenconsoled --log=all
     1839 pts/0    S+     0:00 grep --color=auto xenconsoled

I can see pid file is properly generated:

    root@localhost:~# cat /var/run/xenconsoled.pid
    1767

Log file is created (but sadly, no log messages):

   root@localhost:~# ls /var/log/xen/console/* -l
   -rw-r--r-- 1 root root 0 Mar 28 09:00 /var/log/xen/console/guest-win.log
   -rw-r--r-- 1 root root 0 Mar 28 09:00 /var/log/xen/console/hypervisor.log

I guess we are almost right there launching domU, only a little bit
more puzzle (I'm hoping) should be solved.
Do you guys have any hints or tips for solving this puzzle?


Fun hacking xen arm arndale,
Thomas

Re: Testing xen-arm on Arndale

[Stefano Stabellini]

On Thu, 28 Mar 2013, Sengul Thomas wrote:
> Thanks for the script. But, at the moment, I'm just hoping to see some
> booting messages poping out from console.
> When I try 'xl create <some conf> -c', rather than booting messages,
> following messages (attached the full log) pop out and domU dies.
> 
> (XEN) Guest data abort: Translation fault at level 1
> (XEN)     gva=40004000
> (XEN)     gpa=0000000040004000
> (XEN)     instruction syndrome invalid
> (XEN)     eat=0 cm=0 s1ptw=0 dfsc=5
> (XEN) dom14 IPA 0x0000000040004000
> (XEN) P2M @ 02ff9d40 mfn:0xbfcea
> (XEN) 1ST[0x1] = 0x0000000000000000
> (XEN) ----[ Xen-4.3-unstable  arm32  debug=y  Tainted:    C ]----
> (XEN) CPU:    0
> (XEN) PC:     80008338
> (XEN) CPSR:   800001d3 MODE:SVC
> (XEN)      R0: 40004000 R1: 00000c12 R2: 40008000 R3: 40004000
> (XEN)      R4: 40008000 R5: 00000000 R6: 0000000e R7: ffffffff
> (XEN)      R8: ffffffff R9: 40000000 R10:50000000 R11:10201105 R12:800080a8
> 
> After digging into domU Linux kernel, it turns out that someone tries
> to access 0x40004000 while uncompressing zImage.
> This is quite weird because, when I checked the page table setup for
> domU, it starts mapping from 0x80000000 and 0x40004000 address is not
> supposed to be accessed.
> Do you guys have any hint about this?
> 
> Additionally, it turns out that if we try to use Linux kernel 3.8.4
> (from https://www.kernel.org/), we do not see the above page-fault
> messages and we can see domU is running using xl as follows:

Julien,
do you know whether they need to use the Arndale Linux tree you posted
on the wiki or if a vanilla Linux kernel should be used as DomU kernel?
That's something worth writing down in the wiki page to avoid
confusion.


>     root@localhost:~# xl list
>     Name                                        ID   Mem VCPUs
> State    Time(s)
>     Domain-0                                     0   256     1
> r-----    2009.2
>     win                                          1   128     1
> ------    1898.6
> 
> Unfortunately, I'm not still seeing any booting messages:
> 
>     root@localhost:~# xl create xl.conf -c
>     Parsing config from xl.conf
>     Daemon running with PID 1802
>     <hangs here>
> 
> I'm running xenconsoled with the following command:
> 
>     root@localhost:~# xenconsoled --log=all
> 
> Then, I can see xenconsoled running in ps:
> 
>     root@localhost:~# ps ax | grep xenconsoled
>      1767 ?        SLl    0:00 xenconsoled --log=all
>      1839 pts/0    S+     0:00 grep --color=auto xenconsoled
> 
> I can see pid file is properly generated:
> 
>     root@localhost:~# cat /var/run/xenconsoled.pid
>     1767
> 
> Log file is created (but sadly, no log messages):
> 
>    root@localhost:~# ls /var/log/xen/console/* -l
>    -rw-r--r-- 1 root root 0 Mar 28 09:00 /var/log/xen/console/guest-win.log
>    -rw-r--r-- 1 root root 0 Mar 28 09:00 /var/log/xen/console/hypervisor.log
> 
> I guess we are almost right there launching domU, only a little bit
> more puzzle (I'm hoping) should be solved.
> Do you guys have any hints or tips for solving this puzzle?

You need to get more debug output to figure out where the guest is
stuck.
I suggest enabling:

CONFIG_DEBUG_LL
CONFIG_DEBUG_VEXPRESS_UART0_RS1
CONFIG_EARLY_PRINTK

in your kernel config, they should allow your guest to print some early
messages via Xen.
However these are vexpress specific debug tools, if they don't work
correctly on Arndale, you can try this hacky patch:

diff --git a/kernel/printk.c b/kernel/printk.c
index 0b31715..23ceeba 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1674,10 +1674,12 @@ EXPORT_SYMBOL(printk_emit);
  *
  * See the vsnprintf() documentation for format string extensions over C99.
  */
+void xen_raw_console_write(const char *str);
 asmlinkage int printk(const char *fmt, ...)
 {
 	va_list args;
 	int r;
+	static char buf[512];
 
 #ifdef CONFIG_KGDB_KDB
 	if (unlikely(kdb_trap_printk)) {
@@ -1688,8 +1690,9 @@ asmlinkage int printk(const char *fmt, ...)
 	}
 #endif
 	va_start(args, fmt);
-	r = vprintk_emit(0, -1, NULL, 0, fmt, args);
+	r = vsnprintf(buf, sizeof(buf), fmt, args);
 	va_end(args);
+	xen_raw_console_write(buf);
 
 	return r;
 }

Re: Testing xen-arm on Arndale

[Sengul Thomas]

> Julien,
> do you know whether they need to use the Arndale Linux tree you posted
> on the wiki or if a vanilla Linux kernel should be used as DomU kernel?
> That's something worth writing down in the wiki page to avoid
> confusion.
>

Oops, my bad. vanilla Linux kernel 3.8.4 still has the same problem.
I did not configure the processor type to Exynos (it was VE) when
compiling the kernel.
Linux kernel 3.8.4 still has the same problem and I'm digging into it.

If we see the log below, in this time, translation fault happen at level 2.
I'm just guessing that page table at hypervisor is not properly set.

(XEN) Guest data abort: Translation fault at level 2
(XEN)     gva=10000000
(XEN)     gpa=0000000010000000
(XEN)     size=2 sign=0 write=0 reg=6
(XEN)     eat=0 cm=0 s1ptw=0 dfsc=6
(XEN) dom3 IPA 0x0000000010000000
(XEN) P2M @ 02ff6400 mfn:0xbfb20
(XEN) 1ST[0x0] = 0x00000000bfb236ff
(XEN) 2ND[0x80] = 0x0000000000000000
(XEN) ----[ Xen-4.3-unstable  arm32  debug=y  Tainted:    C ]----
(XEN) CPU:    0
(XEN) PC:     803c2f6c

Re: Testing xen-arm on Arndale

[Julien Grall]

On 03/29/2013 06:57 AM, Sengul Thomas wrote:

>> Julien,
>> do you know whether they need to use the Arndale Linux tree you posted
>> on the wiki or if a vanilla Linux kernel should be used as DomU kernel?
>> That's something worth writing down in the wiki page to avoid
>> confusion.
>>
> 
> Oops, my bad. vanilla Linux kernel 3.8.4 still has the same problem.
> I did not configure the processor type to Exynos (it was VE) when
> compiling the kernel.
> Linux kernel 3.8.4 still has the same problem and I'm digging into it.
> 
> If we see the log below, in this time, translation fault happen at level 2.
> I'm just guessing that page table at hypervisor is not properly set.
> 
> (XEN) Guest data abort: Translation fault at level 2
> (XEN)     gva=10000000
> (XEN)     gpa=0000000010000000
> (XEN)     size=2 sign=0 write=0 reg=6
> (XEN)     eat=0 cm=0 s1ptw=0 dfsc=6
> (XEN) dom3 IPA 0x0000000010000000
> (XEN) P2M @ 02ff6400 mfn:0xbfb20
> (XEN) 1ST[0x0] = 0x00000000bfb236ff
> (XEN) 2ND[0x80] = 0x0000000000000000
> (XEN) ----[ Xen-4.3-unstable  arm32  debug=y  Tainted:    C ]----
> (XEN) CPU:    0
> (XEN) PC:     803c2f6c


The xenvm-4.2.dts only works with Versatile Expresss, because the gic is not
mapped to the right address.

I have pushed a working tree for domU based on linux 3.9-rc3:
http://xenbits.xen.org/gitweb/?p=people/julieng/linux-arm.git;a=shortlog;h=refs/heads/arndale-domU-3.9

You can compile with:
make ARCH=arm xen_domU_arndale_defconfig
make ARCH=arm zImage

And the you just need to append the dts.

Cheers,

Julien

Re: Testing xen-arm on Arndale

[Stefano Stabellini]

On Fri, 29 Mar 2013, Julien Grall wrote:
> On 03/29/2013 06:57 AM, Sengul Thomas wrote:
> 
> >> Julien,
> >> do you know whether they need to use the Arndale Linux tree you posted
> >> on the wiki or if a vanilla Linux kernel should be used as DomU kernel?
> >> That's something worth writing down in the wiki page to avoid
> >> confusion.
> >>
> > 
> > Oops, my bad. vanilla Linux kernel 3.8.4 still has the same problem.
> > I did not configure the processor type to Exynos (it was VE) when
> > compiling the kernel.
> > Linux kernel 3.8.4 still has the same problem and I'm digging into it.
> > 
> > If we see the log below, in this time, translation fault happen at level 2.
> > I'm just guessing that page table at hypervisor is not properly set.
> > 
> > (XEN) Guest data abort: Translation fault at level 2
> > (XEN)     gva=10000000
> > (XEN)     gpa=0000000010000000
> > (XEN)     size=2 sign=0 write=0 reg=6
> > (XEN)     eat=0 cm=0 s1ptw=0 dfsc=6
> > (XEN) dom3 IPA 0x0000000010000000
> > (XEN) P2M @ 02ff6400 mfn:0xbfb20
> > (XEN) 1ST[0x0] = 0x00000000bfb236ff
> > (XEN) 2ND[0x80] = 0x0000000000000000
> > (XEN) ----[ Xen-4.3-unstable  arm32  debug=y  Tainted:    C ]----
> > (XEN) CPU:    0
> > (XEN) PC:     803c2f6c
> 
> 
> The xenvm-4.2.dts only works with Versatile Expresss, because the gic is not
> mapped to the right address.

Of course we'll have to fix this at some point, because xenvm is
supposed to be a generic VM device tree interface. One day it will
probably be generated automatically by the Xen tools.

Re: Testing xen-arm on Arndale

[Sengul Thomas]

>
> I have pushed a working tree for domU based on linux 3.9-rc3:
> http://xenbits.xen.org/gitweb/?p=people/julieng/linux-arm.git;a=shortlog;h=refs/heads/arndale-domU-3.9
>
> You can compile with:
> make ARCH=arm xen_domU_arndale_defconfig
> make ARCH=arm zImage

Thanks a lot! Julien,  now I can see console messages when booting domU.

>
> The xenvm-4.2.dts only works with Versatile Expresss, because the gic is not
> mapped to the right address.

I noticed that you have changed the gic mmio address to 0x10481000.
I figured that this gic (actually vgic) is emulated by
"xen/arch/arm/vgic.c" and according to the source code,
the virtual mmio address is defined as following:

    #define VGIC_DISTR_BASE_ADDRESS (GIC_BASE_ADDRESS+GIC_DR_OFFSET)

which is the same physical gic mmio address (plus GIC_DR_OFFSET).
So we have to use this (0x10481000) value, right?


Sincerely,
Thomas

Re: Testing xen-arm on Arndale

[Julien Grall]

On 03/30/2013 03:40 AM, Sengul Thomas wrote:

>>
>> I have pushed a working tree for domU based on linux 3.9-rc3:
>> http://xenbits.xen.org/gitweb/?p=people/julieng/linux-arm.git;a=shortlog;h=refs/heads/arndale-domU-3.9
>>
>> You can compile with:
>> make ARCH=arm xen_domU_arndale_defconfig
>> make ARCH=arm zImage
> 
> Thanks a lot! Julien,  now I can see console messages when booting domU.
> 
>>
>> The xenvm-4.2.dts only works with Versatile Expresss, because the gic is not
>> mapped to the right address.
> 
> I noticed that you have changed the gic mmio address to 0x10481000.
> I figured that this gic (actually vgic) is emulated by
> "xen/arch/arm/vgic.c" and according to the source code,
> the virtual mmio address is defined as following:
> 
>     #define VGIC_DISTR_BASE_ADDRESS (GIC_BASE_ADDRESS+GIC_DR_OFFSET)
> 
> which is the same physical gic mmio address (plus GIC_DR_OFFSET).
> So we have to use this (0x10481000) value, right?


Yes. This value is hard-coded for the moment. In the future, we will try
to retrieve the base address from the DTS.

Cheers,

Julien

Re: Testing xen-arm on Arndale

[See-Hwan Yoo]

[-- Attachment #1.1: Type: text/plain, Size: 2194 bytes --]

Hello,
I am trying to run with xen-arm.
Following through the Wiki's instruction, I've launched dom0, and trying to
run domU.
xl create dom1 generates the following message.
Can somebody tell me what is going on?
* dom1 configuration is as follows:

kernel = "/root/zImage.domU"
memory = 64
name = "uBuntU"
vcpus = 1
disk = [ 'phy:/dev/loop0,xvda,w' ]

----
libxl: error: libxl_create.c:423:libxl__domain_make: domain creation fail
libxl: error: libxl_create.c:651:initiate_domain_create: cannot make
domain: -3
libxl: error: libxl.c:1377:libxl__destroy_domid: non-existant domain -1
libxl: error: libxl.c:1341:domain_destroy_callback: unable to destroy guest
with domid 4294967295
libxl: error: libxl_create.c:1215:domcreate_destruction_cb: unable to
destroy domain 4294967295 following failed creation

One additional question) How do you debug with ARM-ve?



2013/4/1 Julien Grall <julien.grall@citrix.com>

> On 03/30/2013 03:40 AM, Sengul Thomas wrote:
>
> >>
> >> I have pushed a working tree for domU based on linux 3.9-rc3:
> >>
> http://xenbits.xen.org/gitweb/?p=people/julieng/linux-arm.git;a=shortlog;h=refs/heads/arndale-domU-3.9
> >>
> >> You can compile with:
> >> make ARCH=arm xen_domU_arndale_defconfig
> >> make ARCH=arm zImage
> >
> > Thanks a lot! Julien,  now I can see console messages when booting domU.
> >
> >>
> >> The xenvm-4.2.dts only works with Versatile Expresss, because the gic
> is not
> >> mapped to the right address.
> >
> > I noticed that you have changed the gic mmio address to 0x10481000.
> > I figured that this gic (actually vgic) is emulated by
> > "xen/arch/arm/vgic.c" and according to the source code,
> > the virtual mmio address is defined as following:
> >
> >     #define VGIC_DISTR_BASE_ADDRESS (GIC_BASE_ADDRESS+GIC_DR_OFFSET)
> >
> > which is the same physical gic mmio address (plus GIC_DR_OFFSET).
> > So we have to use this (0x10481000) value, right?
>
>
> Yes. This value is hard-coded for the moment. In the future, we will try
> to retrieve the base address from the DTS.
>
> Cheers,
>
> Julien
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 3348 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Testing xen-arm on Arndale

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

I would appreciate if you could send emails in plain text, rather than
html.


On Wed, 3 Apr 2013, See-Hwan Yoo wrote:
> Hello, I am trying to run with xen-arm. 
> Following through the Wiki's instruction, I've launched dom0, and trying to run domU.
> xl create dom1 generates the following message. 
> Can somebody tell me what is going on?
> * dom1 configuration is as follows:
> 
> kernel = "/root/zImage.domU"
> memory = 64
> name = "uBuntU"
> vcpus = 1
> disk = [ 'phy:/dev/loop0,xvda,w' ]
> 
> ----
> libxl: error: libxl_create.c:423:libxl__domain_make: domain creation fail
> libxl: error: libxl_create.c:651:initiate_domain_create: cannot make domain: -3
> libxl: error: libxl.c:1377:libxl__destroy_domid: non-existant domain -1
> libxl: error: libxl.c:1341:domain_destroy_callback: unable to destroy guest with domid 4294967295
> libxl: error: libxl_create.c:1215:domcreate_destruction_cb: unable to destroy domain 4294967295 following failed creation

Please post the output of

xl -vvv create /path/to/vm_file

the -vvv enables all the debugging output in libxl and should give us a
pretty good idea of why it failed.

 
> One additional question) How do you debug with ARM-ve?

If you are using the emulator, they have a version of it that includes a
debugger. If you are using the real hardware, you can use the jtag port
to connect an hardware debugger.
In both cases you can type ctrl-a three times on the serial to get the
menu of debugging commands from Xen.
Of course you can also add more printk's to figure out what's happening.

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Testing xen-arm on Arndale

[See-Hwan Yoo]

[-- Attachment #1.1: Type: text/plain, Size: 4483 bytes --]

Thank you, Stefano:
I have checked -vvv and it seems that xl is looking for a file that is
missing. I've included the printed message at the tail of the mail.
I've farmed xl tools through Ian campbell's cross toolchain wiki.

Making cross toolchain using schroot is a good way around building the xen
tools, but documentation could be improved if it includes the following
facts.
Because the current arndale board's rootfs snapshot does not include the
proper python library tools, it firstly complains about some missing python
modules such as 'commands'.
In addition, libyajl library files are also missing. In the cross-compiling
phase, I've installed those library's dev port to schroot build directory;
however, it has to be explicitly copied to the rootfs so that
libxenguest/libxenlight can refer those libraries.
Namely, the dependent libraries have to be included in the root file
system; I hope the document includes specifically which libraries have
run-time dependency, and which modules are required to run.

Finally, I am curious about the mismatch in the two debug console options:
in the bootargs options console=dbgp (given in dts), and codes in
start_xen() shows
exynos5_uart_init(2, FIXMAP_ADDR, ...);
It seems like uart2 is fixed to use as console; but the code seems work
only when console=dbgp.
How about using console=com1/2 instead of dbgp? (it seems more intuitive.)

The log from xl create with -vvv option is as follows:
xl -vvv create dom1
Parsing config from dom1
libxl: verbose: libxl_create.c:130:libxl__domain_build_info_setdefault:
qemu-xen is unavailable, use qemu-xen-traditional instead: No such file or
directory
libxl: debug: libxl_create.c:1236:do_domain_create: ao 0x2ea28: create:
how=(nil) callback=(nil) poller=0x2e6a8
xc: detail: domctl operation failed -- need to rebuild the user-space tool
set?
libxl: error: libxl_create.c:423:libxl__domain_make: domain creation fail
libxl: error: libxl_create.c:651:initiate_domain_create: cannot make
domain: -3
libxl: error: libxl.c:1377:libxl__destroy_domid: non-existant domain -1
libxl: error: libxl.c:1341:domain_destroy_callback: unable to destroy guest
with domid 4294967295
libxl: error: libxl_create.c:1215:domcreate_destruction_cb: unable to
destroy domain 4294967295 following failed creation
libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x2ea28: complete,
rc=-3
libxl: debug: libxl_create.c:1249:do_domain_create: ao 0x2ea28: inprogress:
poller=0x2e6a8, flags=ic
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x2ea28: destroy
xc: debug: hypercall buffer: total allocations:5 total releases:5
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:3 misses:2 toobig:0



2013/4/3 Stefano Stabellini <stefano.stabellini@eu.citrix.com>

> I would appreciate if you could send emails in plain text, rather than
> html.
>
>
> On Wed, 3 Apr 2013, See-Hwan Yoo wrote:
> > Hello, I am trying to run with xen-arm.
> > Following through the Wiki's instruction, I've launched dom0, and trying
> to run domU.
> > xl create dom1 generates the following message.
> > Can somebody tell me what is going on?
> > * dom1 configuration is as follows:
> >
> > kernel = "/root/zImage.domU"
> > memory = 64
> > name = "uBuntU"
> > vcpus = 1
> > disk = [ 'phy:/dev/loop0,xvda,w' ]
> >
> > ----
> > libxl: error: libxl_create.c:423:libxl__domain_make: domain creation fail
> > libxl: error: libxl_create.c:651:initiate_domain_create: cannot make
> domain: -3
> > libxl: error: libxl.c:1377:libxl__destroy_domid: non-existant domain -1
> > libxl: error: libxl.c:1341:domain_destroy_callback: unable to destroy
> guest with domid 4294967295
> > libxl: error: libxl_create.c:1215:domcreate_destruction_cb: unable to
> destroy domain 4294967295 following failed creation
>
> Please post the output of
>
> xl -vvv create /path/to/vm_file
>
> the -vvv enables all the debugging output in libxl and should give us a
> pretty good idea of why it failed.
>
>
> > One additional question) How do you debug with ARM-ve?
>
> If you are using the emulator, they have a version of it that includes a
> debugger. If you are using the real hardware, you can use the jtag port
> to connect an hardware debugger.
> In both cases you can type ctrl-a three times on the serial to get the
> menu of debugging commands from Xen.
> Of course you can also add more printk's to figure out what's happening.

[-- Attachment #1.2: Type: text/html, Size: 5381 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Testing xen-arm on Arndale

[Julien Grall]

On 04/03/2013 12:57 PM, See-Hwan Yoo wrote:

> Thank you, Stefano:
> I have checked -vvv and it seems that xl is looking for a file that is
> missing. I've included the printed message at the tail of the mail.
> I've farmed xl tools through Ian campbell's cross toolchain wiki.
> 
> Making cross toolchain using schroot is a good way around building the
> xen tools, but documentation could be improved if it includes the
> following facts.
> Because the current arndale board's rootfs snapshot does not include the
> proper python library tools, it firstly complains about some missing
> python modules such as 'commands'.
> In addition, libyajl library files are also missing. In the
> cross-compiling phase, I've installed those library's dev port to
> schroot build directory; however, it has to be explicitly copied to the
> rootfs so that libxenguest/libxenlight can refer those libraries.
> Namely, the dependent libraries have to be included in the root file
> system; I hope the document includes specifically which libraries have
> run-time dependency, and which modules are required to run.
> 
> Finally, I am curious about the mismatch in the two debug console
> options: in the bootargs options console=dbgp (given in dts), and codes
> in start_xen() shows
> exynos5_uart_init(2, FIXMAP_ADDR, ...);
> It seems like uart2 is fixed to use as console; but the code seems work
> only when console=dbgp.
> How about using console=com1/2 instead of dbgp? (it seems more intuitive.)

Xen can use up to 3 serials port with the following name: com1, com2, dbgp.
The first is assigned to value 0 and the last 2.
Here, index 2 (ie dbgp) is used because log will output to the second UART.
But it's completely unrelated, and it was for a first draft.

I'm currently trying to clean up the code for the exynos5 in order to have
a single code base for all ARM platforms. I'll plan to modify serial
handling for ARM at that time.

> The log from xl create with -vvv option is as follows:
> xl -vvv create dom1
> Parsing config from dom1
> libxl: verbose: libxl_create.c:130:libxl__domain_build_info_setdefault:
> qemu-xen is unavailable, use qemu-xen-traditional instead: No such file
> or directory
> libxl: debug: libxl_create.c:1236:do_domain_create: ao 0x2ea28: create:
> how=(nil) callback=(nil) poller=0x2e6a8
> xc: detail: domctl operation failed -- need to rebuild the user-space
> tool set?


Which tree do you use to build the tools? You need to use
git clone --branch exynos5250-2013-03-22 git://xenbits.xen.org/people/aperard/xen-arm.git
Exynos5 port uses an old tree and it's not compatible with recent xen
due to ABI breakage. It should allow you to cross compile tools.

> libxl: error: libxl_create.c:423:libxl__domain_make: domain creation fail
> libxl: error: libxl_create.c:651:initiate_domain_create: cannot make
> domain: -3
> libxl: error: libxl.c:1377:libxl__destroy_domid: non-existant domain -1
> libxl: error: libxl.c:1341:domain_destroy_callback: unable to destroy
> guest with domid 4294967295
> libxl: error: libxl_create.c:1215:domcreate_destruction_cb: unable to
> destroy domain 4294967295 following failed creation
> libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x2ea28:
> complete, rc=-3
> libxl: debug: libxl_create.c:1249:do_domain_create: ao 0x2ea28:
> inprogress: poller=0x2e6a8, flags=ic
> libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x2ea28: destroy
> xc: debug: hypercall buffer: total allocations:5 total releases:5
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:3 misses:2 toobig:0
> 


Sincerely yours,

Julien

Re: Testing xen-arm on Arndale

[See-Hwan Yoo]

[-- Attachment #1.1: Type: text/plain, Size: 4651 bytes --]

Hello Julien,
Thank you for informative way.

However, the git tree also seems broken.
I have faced several problems, and some of them are as follows.

1. libxc compilation error.
In xc_dom.h, declares the following function.
int xc_dom_feature_translated(struct xc_dom_image *dom);

However, the function is differently defined at the following locations,
differently.
xc_core_arm.h has macro that has the same name; and
xc_dom_arm.c has static function.
Fortunately, they seem to function in the same way.
Thus, one of them can be eliminated.

2. several files under blktap/blktap2
have type mismatch conflicts. (mostly off_t and uint64_t)
They have to be re-touched so that the compiler would not complains about
it.




On Wed, Apr 3, 2013 at 10:22 PM, Julien Grall <julien.grall@citrix.com>wrote:

> On 04/03/2013 12:57 PM, See-Hwan Yoo wrote:
>
> > Thank you, Stefano:
> > I have checked -vvv and it seems that xl is looking for a file that is
> > missing. I've included the printed message at the tail of the mail.
> > I've farmed xl tools through Ian campbell's cross toolchain wiki.
> >
> > Making cross toolchain using schroot is a good way around building the
> > xen tools, but documentation could be improved if it includes the
> > following facts.
> > Because the current arndale board's rootfs snapshot does not include the
> > proper python library tools, it firstly complains about some missing
> > python modules such as 'commands'.
> > In addition, libyajl library files are also missing. In the
> > cross-compiling phase, I've installed those library's dev port to
> > schroot build directory; however, it has to be explicitly copied to the
> > rootfs so that libxenguest/libxenlight can refer those libraries.
> > Namely, the dependent libraries have to be included in the root file
> > system; I hope the document includes specifically which libraries have
> > run-time dependency, and which modules are required to run.
> >
> > Finally, I am curious about the mismatch in the two debug console
> > options: in the bootargs options console=dbgp (given in dts), and codes
> > in start_xen() shows
> > exynos5_uart_init(2, FIXMAP_ADDR, ...);
> > It seems like uart2 is fixed to use as console; but the code seems work
> > only when console=dbgp.
> > How about using console=com1/2 instead of dbgp? (it seems more
> intuitive.)
>
> Xen can use up to 3 serials port with the following name: com1, com2, dbgp.
> The first is assigned to value 0 and the last 2.
> Here, index 2 (ie dbgp) is used because log will output to the second UART.
> But it's completely unrelated, and it was for a first draft.
>
> I'm currently trying to clean up the code for the exynos5 in order to have
> a single code base for all ARM platforms. I'll plan to modify serial
> handling for ARM at that time.
>
> > The log from xl create with -vvv option is as follows:
> > xl -vvv create dom1
> > Parsing config from dom1
> > libxl: verbose: libxl_create.c:130:libxl__domain_build_info_setdefault:
> > qemu-xen is unavailable, use qemu-xen-traditional instead: No such file
> > or directory
> > libxl: debug: libxl_create.c:1236:do_domain_create: ao 0x2ea28: create:
> > how=(nil) callback=(nil) poller=0x2e6a8
> > xc: detail: domctl operation failed -- need to rebuild the user-space
> > tool set?
>
>
> Which tree do you use to build the tools? You need to use
> git clone --branch exynos5250-2013-03-22 git://
> xenbits.xen.org/people/aperard/xen-arm.git
> Exynos5 port uses an old tree and it's not compatible with recent xen
> due to ABI breakage. It should allow you to cross compile tools.
>
> > libxl: error: libxl_create.c:423:libxl__domain_make: domain creation fail
> > libxl: error: libxl_create.c:651:initiate_domain_create: cannot make
> > domain: -3
> > libxl: error: libxl.c:1377:libxl__destroy_domid: non-existant domain -1
> > libxl: error: libxl.c:1341:domain_destroy_callback: unable to destroy
> > guest with domid 4294967295
> > libxl: error: libxl_create.c:1215:domcreate_destruction_cb: unable to
> > destroy domain 4294967295 following failed creation
> > libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x2ea28:
> > complete, rc=-3
> > libxl: debug: libxl_create.c:1249:do_domain_create: ao 0x2ea28:
> > inprogress: poller=0x2e6a8, flags=ic
> > libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x2ea28: destroy
> > xc: debug: hypercall buffer: total allocations:5 total releases:5
> > xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> > xc: debug: hypercall buffer: cache current size:2
> > xc: debug: hypercall buffer: cache hits:3 misses:2 toobig:0
> >
>
>
> Sincerely yours,
>
> Julien
>

[-- Attachment #1.2: Type: text/html, Size: 5805 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Testing xen-arm on Arndale

[Julien Grall]

On 04/04/2013 03:06 AM, See-Hwan Yoo wrote:

> Hello Julien,


Hello,

> Thank you for informative way.
> 
> However, the git tree also seems broken.
> I have faced several problems, and some of them are as follows.
> 
> 1. libxc compilation error.
> In xc_dom.h, declares the following function.
> int xc_dom_feature_translated(struct xc_dom_image *dom);
> 
> However, the function is differently defined at the following locations,
> differently.
> xc_core_arm.h has macro that has the same name; and
> xc_dom_arm.c has static function.
> Fortunately, they seem to function in the same way.
> Thus, one of them can be eliminated.


Thanks, I have pushed a fix in my branch.

 
> 2. several files under blktap/blktap2
> have type mismatch conflicts. (mostly off_t and uint64_t)
> They have to be re-touched so that the compiler would not complains
> about it.


blktap and blktap2 are not usefull for a basic installation.
By the way, I think Ian has fixed the compilation issue in it's
cross-compil branch, but I didn't add this patch for the arndale.

> On Wed, Apr 3, 2013 at 10:22 PM, Julien Grall <julien.grall@citrix.com
> <mailto:julien.grall@citrix.com>> wrote:
> 
>     On 04/03/2013 12:57 PM, See-Hwan Yoo wrote:
> 
>     > Thank you, Stefano:
>     > I have checked -vvv and it seems that xl is looking for a file that is
>     > missing. I've included the printed message at the tail of the mail.
>     > I've farmed xl tools through Ian campbell's cross toolchain wiki.
>     >
>     > Making cross toolchain using schroot is a good way around building the
>     > xen tools, but documentation could be improved if it includes the
>     > following facts.
>     > Because the current arndale board's rootfs snapshot does not
>     include the
>     > proper python library tools, it firstly complains about some missing
>     > python modules such as 'commands'.
>     > In addition, libyajl library files are also missing. In the
>     > cross-compiling phase, I've installed those library's dev port to
>     > schroot build directory; however, it has to be explicitly copied
>     to the
>     > rootfs so that libxenguest/libxenlight can refer those libraries.
>     > Namely, the dependent libraries have to be included in the root file
>     > system; I hope the document includes specifically which libraries have
>     > run-time dependency, and which modules are required to run.
>     >
>     > Finally, I am curious about the mismatch in the two debug console
>     > options: in the bootargs options console=dbgp (given in dts), and
>     codes
>     > in start_xen() shows
>     > exynos5_uart_init(2, FIXMAP_ADDR, ...);
>     > It seems like uart2 is fixed to use as console; but the code seems
>     work
>     > only when console=dbgp.
>     > How about using console=com1/2 instead of dbgp? (it seems more
>     intuitive.)
> 
>     Xen can use up to 3 serials port with the following name: com1,
>     com2, dbgp.
>     The first is assigned to value 0 and the last 2.
>     Here, index 2 (ie dbgp) is used because log will output to the
>     second UART.
>     But it's completely unrelated, and it was for a first draft.
> 
>     I'm currently trying to clean up the code for the exynos5 in order
>     to have
>     a single code base for all ARM platforms. I'll plan to modify serial
>     handling for ARM at that time.
> 
>     > The log from xl create with -vvv option is as follows:
>     > xl -vvv create dom1
>     > Parsing config from dom1
>     > libxl: verbose:
>     libxl_create.c:130:libxl__domain_build_info_setdefault:
>     > qemu-xen is unavailable, use qemu-xen-traditional instead: No such
>     file
>     > or directory
>     > libxl: debug: libxl_create.c:1236:do_domain_create: ao 0x2ea28:
>     create:
>     > how=(nil) callback=(nil) poller=0x2e6a8
>     > xc: detail: domctl operation failed -- need to rebuild the user-space
>     > tool set?
> 
> 
>     Which tree do you use to build the tools? You need to use
>     git clone --branch exynos5250-2013-03-22
>     git://xenbits.xen.org/people/aperard/xen-arm.git
>     Exynos5 <http://xenbits.xen.org/people/aperard/xen-arm.git Exynos5>
>     port uses an old tree and it's not compatible with recent xen
>     due to ABI breakage. It should allow you to cross compile tools.
> 
>     > libxl: error: libxl_create.c:423:libxl__domain_make: domain
>     creation fail
>     > libxl: error: libxl_create.c:651:initiate_domain_create: cannot make
>     > domain: -3
>     > libxl: error: libxl.c:1377:libxl__destroy_domid: non-existant
>     domain -1
>     > libxl: error: libxl.c:1341:domain_destroy_callback: unable to destroy
>     > guest with domid 4294967295
>     > libxl: error: libxl_create.c:1215:domcreate_destruction_cb: unable to
>     > destroy domain 4294967295 following failed creation
>     > libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x2ea28:
>     > complete, rc=-3
>     > libxl: debug: libxl_create.c:1249:do_domain_create: ao 0x2ea28:
>     > inprogress: poller=0x2e6a8, flags=ic
>     > libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x2ea28:
>     destroy
>     > xc: debug: hypercall buffer: total allocations:5 total releases:5
>     > xc: debug: hypercall buffer: current allocations:0 maximum
>     allocations:2
>     > xc: debug: hypercall buffer: cache current size:2
>     > xc: debug: hypercall buffer: cache hits:3 misses:2 toobig:0
>     >
> 
> 
>     Sincerely yours,
> 
>     Julien
> 
> 

Re: Testing xen-arm on Arndale

[See-Hwan Yoo]

[-- Attachment #1.1: Type: text/plain, Size: 6273 bytes --]

Thanks Julien,

Though this is a minor thing, I want you to update the Minimal-init - Xen
wiki.

The script assumes that there exists /dev/pts directory; but, in fact, it
is not in all cases.
Thus, I needed to create /dev/pts directory before running the script,
using the following command.
mkdir -p /dev/pts

Now I can see the console of domU.

Is there some material about the future direction of Xen-arm? (or
Arndale-specific issues?)

Regards,
Seehwan


On Thu, Apr 4, 2013 at 10:38 PM, Julien Grall <julien.grall@citrix.com>wrote:

> On 04/04/2013 03:06 AM, See-Hwan Yoo wrote:
>
> > Hello Julien,
>
>
> Hello,
>
> > Thank you for informative way.
> >
> > However, the git tree also seems broken.
> > I have faced several problems, and some of them are as follows.
> >
> > 1. libxc compilation error.
> > In xc_dom.h, declares the following function.
> > int xc_dom_feature_translated(struct xc_dom_image *dom);
> >
> > However, the function is differently defined at the following locations,
> > differently.
> > xc_core_arm.h has macro that has the same name; and
> > xc_dom_arm.c has static function.
> > Fortunately, they seem to function in the same way.
> > Thus, one of them can be eliminated.
>
>
> Thanks, I have pushed a fix in my branch.
>
>
> > 2. several files under blktap/blktap2
> > have type mismatch conflicts. (mostly off_t and uint64_t)
> > They have to be re-touched so that the compiler would not complains
> > about it.
>
>
> blktap and blktap2 are not usefull for a basic installation.
> By the way, I think Ian has fixed the compilation issue in it's
> cross-compil branch, but I didn't add this patch for the arndale.
>
> > On Wed, Apr 3, 2013 at 10:22 PM, Julien Grall <julien.grall@citrix.com
> > <mailto:julien.grall@citrix.com>> wrote:
> >
> >     On 04/03/2013 12:57 PM, See-Hwan Yoo wrote:
> >
> >     > Thank you, Stefano:
> >     > I have checked -vvv and it seems that xl is looking for a file
> that is
> >     > missing. I've included the printed message at the tail of the mail.
> >     > I've farmed xl tools through Ian campbell's cross toolchain wiki.
> >     >
> >     > Making cross toolchain using schroot is a good way around building
> the
> >     > xen tools, but documentation could be improved if it includes the
> >     > following facts.
> >     > Because the current arndale board's rootfs snapshot does not
> >     include the
> >     > proper python library tools, it firstly complains about some
> missing
> >     > python modules such as 'commands'.
> >     > In addition, libyajl library files are also missing. In the
> >     > cross-compiling phase, I've installed those library's dev port to
> >     > schroot build directory; however, it has to be explicitly copied
> >     to the
> >     > rootfs so that libxenguest/libxenlight can refer those libraries.
> >     > Namely, the dependent libraries have to be included in the root
> file
> >     > system; I hope the document includes specifically which libraries
> have
> >     > run-time dependency, and which modules are required to run.
> >     >
> >     > Finally, I am curious about the mismatch in the two debug console
> >     > options: in the bootargs options console=dbgp (given in dts), and
> >     codes
> >     > in start_xen() shows
> >     > exynos5_uart_init(2, FIXMAP_ADDR, ...);
> >     > It seems like uart2 is fixed to use as console; but the code seems
> >     work
> >     > only when console=dbgp.
> >     > How about using console=com1/2 instead of dbgp? (it seems more
> >     intuitive.)
> >
> >     Xen can use up to 3 serials port with the following name: com1,
> >     com2, dbgp.
> >     The first is assigned to value 0 and the last 2.
> >     Here, index 2 (ie dbgp) is used because log will output to the
> >     second UART.
> >     But it's completely unrelated, and it was for a first draft.
> >
> >     I'm currently trying to clean up the code for the exynos5 in order
> >     to have
> >     a single code base for all ARM platforms. I'll plan to modify serial
> >     handling for ARM at that time.
> >
> >     > The log from xl create with -vvv option is as follows:
> >     > xl -vvv create dom1
> >     > Parsing config from dom1
> >     > libxl: verbose:
> >     libxl_create.c:130:libxl__domain_build_info_setdefault:
> >     > qemu-xen is unavailable, use qemu-xen-traditional instead: No such
> >     file
> >     > or directory
> >     > libxl: debug: libxl_create.c:1236:do_domain_create: ao 0x2ea28:
> >     create:
> >     > how=(nil) callback=(nil) poller=0x2e6a8
> >     > xc: detail: domctl operation failed -- need to rebuild the
> user-space
> >     > tool set?
> >
> >
> >     Which tree do you use to build the tools? You need to use
> >     git clone --branch exynos5250-2013-03-22
> >     git://xenbits.xen.org/people/aperard/xen-arm.git
> >     Exynos5 <http://xenbits.xen.org/people/aperard/xen-arm.git Exynos5>
> >     port uses an old tree and it's not compatible with recent xen
> >     due to ABI breakage. It should allow you to cross compile tools.
> >
> >     > libxl: error: libxl_create.c:423:libxl__domain_make: domain
> >     creation fail
> >     > libxl: error: libxl_create.c:651:initiate_domain_create: cannot
> make
> >     > domain: -3
> >     > libxl: error: libxl.c:1377:libxl__destroy_domid: non-existant
> >     domain -1
> >     > libxl: error: libxl.c:1341:domain_destroy_callback: unable to
> destroy
> >     > guest with domid 4294967295
> >     > libxl: error: libxl_create.c:1215:domcreate_destruction_cb: unable
> to
> >     > destroy domain 4294967295 following failed creation
> >     > libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x2ea28:
> >     > complete, rc=-3
> >     > libxl: debug: libxl_create.c:1249:do_domain_create: ao 0x2ea28:
> >     > inprogress: poller=0x2e6a8, flags=ic
> >     > libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x2ea28:
> >     destroy
> >     > xc: debug: hypercall buffer: total allocations:5 total releases:5
> >     > xc: debug: hypercall buffer: current allocations:0 maximum
> >     allocations:2
> >     > xc: debug: hypercall buffer: cache current size:2
> >     > xc: debug: hypercall buffer: cache hits:3 misses:2 toobig:0
> >     >
> >
> >
> >     Sincerely yours,
> >
> >     Julien
> >
> >
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 8125 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Testing xen-arm on Arndale

[Stefano Stabellini]

On Fri, 5 Apr 2013, See-Hwan Yoo wrote:
> Thanks Julien,
> 
> Though this is a minor thing, I want you to update the Minimal-init - Xen wiki.
> 
> The script assumes that there exists /dev/pts directory; but, in fact, it is not in all cases.
> Thus, I needed to create /dev/pts directory before running the script, using the following command.
> mkdir -p /dev/pts
> 
> Now I can see the console of domU.
> 
> Is there some material about the future direction of Xen-arm? (or Arndale-specific issues?)

I wrote an high level list of open projects:

http://wiki.xen.org/wiki/Xen_ARM_TODO

Julien, could you please fill in more details on Arndale-specific bugs
or work items?

Thanks,

Stefano

Re: Testing xen-arm on Arndale

[Julien Grall]

On 04/05/2013 12:34 PM, Stefano Stabellini wrote:

> On Fri, 5 Apr 2013, See-Hwan Yoo wrote:
>> Thanks Julien,
>>
>> Though this is a minor thing, I want you to update the Minimal-init - Xen wiki.
>>
>> The script assumes that there exists /dev/pts directory; but, in fact, it is not in all cases.
>> Thus, I needed to create /dev/pts directory before running the script, using the following command.
>> mkdir -p /dev/pts
>>
>> Now I can see the console of domU.
>>
>> Is there some material about the future direction of Xen-arm? (or Arndale-specific issues?)
> 
> I wrote an high level list of open projects:
> 
> http://wiki.xen.org/wiki/Xen_ARM_TODO
> 
> Julien, could you please fill in more details on Arndale-specific bugs
> or work items?

I have added 2 other known bugs for the Arndale board.

Sincerely yours,

Julien

Re: Testing xen-arm on Arndale

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 5402 bytes --]

On Wed, 3 Apr 2013, See-Hwan Yoo wrote:
> Thank you, Stefano:
> I have checked -vvv and it seems that xl is looking for a file that is missing. I've included the printed message at the tail of
> the mail.
> I've farmed xl tools through Ian campbell's cross toolchain wiki.
> 
> Making cross toolchain using schroot is a good way around building the xen tools, but documentation could be improved if it
> includes the following facts.
> Because the current arndale board's rootfs snapshot does not include the proper python library tools, it firstly complains about
> some missing python modules such as 'commands'.
> In addition, libyajl library files are also missing. In the cross-compiling phase, I've installed those library's dev port to
> schroot build directory; however, it has to be explicitly copied to the rootfs so that libxenguest/libxenlight can refer those
> libraries.
> Namely, the dependent libraries have to be included in the root file system; I hope the document includes specifically which
> libraries have run-time dependency, and which modules are required to run.

You are right, we should improve the documentation for cross-compiling
tools. I have CC'ed Ian that wrote the page.


> Finally, I am curious about the mismatch in the two debug console options: in the bootargs options console=dbgp (given in dts),
> and codes in start_xen() shows
> exynos5_uart_init(2, FIXMAP_ADDR, ...);
> It seems like uart2 is fixed to use as console; but the code seems work only when console=dbgp.
> How about using console=com1/2 instead of dbgp? (it seems more intuitive.)

Good point, in fact I think that Julien had something similar in mind.


> The log from xl create with -vvv option is as follows:
> xl -vvv create dom1
> Parsing config from dom1
> libxl: verbose: libxl_create.c:130:libxl__domain_build_info_setdefault: qemu-xen is unavailable, use qemu-xen-traditional instead:
> No such file or directory

Ah, yes, we should fix this bug, but it's not a critical failure.


> libxl: debug: libxl_create.c:1236:do_domain_create: ao 0x2ea28: create: how=(nil) callback=(nil) poller=0x2e6a8
> xc: detail: domctl operation failed -- need to rebuild the user-space tool set?

This is the critical failure that you are experiencing.
Usually it happens because of a mismatch between Xen, Linux and the Xen
tools.
In particular make sure that you have "xen: event channel arrays are
xen_ulong_t and not unsigned long" in both Xen and Linux (or neither).


> libxl: error: libxl_create.c:423:libxl__domain_make: domain creation fail
> libxl: error: libxl_create.c:651:initiate_domain_create: cannot make domain: -3
> libxl: error: libxl.c:1377:libxl__destroy_domid: non-existant domain -1
> libxl: error: libxl.c:1341:domain_destroy_callback: unable to destroy guest with domid 4294967295
> libxl: error: libxl_create.c:1215:domcreate_destruction_cb: unable to destroy domain 4294967295 following failed creation
> libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x2ea28: complete, rc=-3
> libxl: debug: libxl_create.c:1249:do_domain_create: ao 0x2ea28: inprogress: poller=0x2e6a8, flags=ic
> libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x2ea28: destroy
> xc: debug: hypercall buffer: total allocations:5 total releases:5
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:3 misses:2 toobig:0
> 
> 
> 
> 2013/4/3 Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>       I would appreciate if you could send emails in plain text, rather than
>       html.
> 
> 
>       On Wed, 3 Apr 2013, See-Hwan Yoo wrote:
>       > Hello, I am trying to run with xen-arm. 
>       > Following through the Wiki's instruction, I've launched dom0, and trying to run domU.
>       > xl create dom1 generates the following message. 
>       > Can somebody tell me what is going on?
>       > * dom1 configuration is as follows:
>       >
>       > kernel = "/root/zImage.domU"
>       > memory = 64
>       > name = "uBuntU"
>       > vcpus = 1
>       > disk = [ 'phy:/dev/loop0,xvda,w' ]
>       >
>       > ----
>       > libxl: error: libxl_create.c:423:libxl__domain_make: domain creation fail
>       > libxl: error: libxl_create.c:651:initiate_domain_create: cannot make domain: -3
>       > libxl: error: libxl.c:1377:libxl__destroy_domid: non-existant domain -1
>       > libxl: error: libxl.c:1341:domain_destroy_callback: unable to destroy guest with domid 4294967295
>       > libxl: error: libxl_create.c:1215:domcreate_destruction_cb: unable to destroy domain 4294967295 following failed
>       creation
> 
> Please post the output of
> 
> xl -vvv create /path/to/vm_file
> 
> the -vvv enables all the debugging output in libxl and should give us a
> pretty good idea of why it failed.
> 
> 
> > One additional question) How do you debug with ARM-ve?
> 
> If you are using the emulator, they have a version of it that includes a
> debugger. If you are using the real hardware, you can use the jtag port
> to connect an hardware debugger.
> In both cases you can type ctrl-a three times on the serial to get the
> menu of debugging commands from Xen.
> Of course you can also add more printk's to figure out what's happening.
> 
> 
> 
> 

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Testing xen-arm on Arndale

[Ian Campbell]

On Wed, 2013-04-03 at 14:37 +0100, Stefano Stabellini wrote:
> On Wed, 3 Apr 2013, See-Hwan Yoo wrote:
> > Thank you, Stefano:
> > I have checked -vvv and it seems that xl is looking for a file that is missing. I've included the printed message at the tail of
> > the mail.
> > I've farmed xl tools through Ian campbell's cross toolchain wiki.
> > 
> > Making cross toolchain using schroot is a good way around building the xen tools, but documentation could be improved if it
> > includes the following facts.
> > Because the current arndale board's rootfs snapshot does not include the proper python library tools, it firstly complains about
> > some missing python modules such as 'commands'.
> > In addition, libyajl library files are also missing. In the cross-compiling phase, I've installed those library's dev port to
> > schroot build directory; however, it has to be explicitly copied to the rootfs so that libxenguest/libxenlight can refer those
> > libraries.
> > Namely, the dependent libraries have to be included in the root file system; I hope the document includes specifically which
> > libraries have run-time dependency, and which modules are required to run.
> 
> You are right, we should improve the documentation for cross-compiling
> tools. I have CC'ed Ian that wrote the page.

I don't think the requirement to have the runtime part of the libraries
in your rootfs is particular to cross-compiling, it's just as true if
you do a native compile on some other system.

> > libxl: debug: libxl_create.c:1236:do_domain_create: ao 0x2ea28: create: how=(nil) callback=(nil) poller=0x2e6a8
> > xc: detail: domctl operation failed -- need to rebuild the user-space tool set?
> 
> This is the critical failure that you are experiencing.
> Usually it happens because of a mismatch between Xen, Linux and the Xen
> tools.
> In particular make sure that you have "xen: event channel arrays are
> xen_ulong_t and not unsigned long" in both Xen and Linux (or neither).

FWIW although this patch is an ABI break it doesn't (AFAIK) affect the
domctl interface, which is versioned independently. Not to say that
mismatch isn't still a problem (I typically see it as a failure to
connect the PV devices)

Ian.

Re: [XenARM] Testing xen-arm on Arndale

[Giridhar Maruthy]

Hi Julien,

I am trying to use Xen on Arndale board with instrunction on page
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Arndale

I am also facing a problem similar to the one that you debugged
before. Translation fault is happening at level3. The fault happens
when 0x12c20008 is accessed. This location happens to be a register of
UART2 port on Arndale. A part of the log is below. Any idea what
caused access to UART to fail?

(XEN) Device-tree contains "xen,xen" node. Ignoring.
(XEN) Populate P2M 0x50000000->0x60000000 (1:1 mapping for dom0)
(XEN) Loading kernel from boot module 1
(XEN) Loading zImage from 0000000060000000 to 0000000050008000-00000000503b6858
(XEN) Loading dom0 DTB to 0x000000005fe00000-0x000000005fe04442
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 220kB init memory.
(XEN) Guest data abort: Translation fault at level 3
(XEN)     gva=f7020008
(XEN)     gpa=0000000012c20008
(XEN)     size=2 sign=0 write=0 reg=2
(XEN)     eat=0 cm=0 s1ptw=0 dfsc=7
(XEN) dom0 IPA 0x0000000012c20008
(XEN) P2M @ 02ffbf80 mfn:0xbfdfc
(XEN) 1ST[0x0] = 0x00000000bfdfe6ff
(XEN) 2ND[0x96] = 0x00000000bfd776ff
(XEN) 3RD[0x20] = 0x0000000000000000

Thanks,
Giridhar

On 27 March 2013 00:59, Julien Grall <julien.grall@citrix.com> wrote:
> On 03/26/2013 04:04 PM, Anthony PERARD wrote:
>
>> CC'ing xen-devel, where the ARMv7+ port of Xen is happening.
>>
>> On 25/03/13 09:46, Sengul Thomas wrote:
>>> Hello Anthony,
>>> I'm hoping your are the right person to ask about xen-arm on Arndale.
>>>
>>> I've tried the following wiki to run xen-arm on Arndale and it crashes while booting dom0.
>>> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Arndale
>>>
>>> Here goes some part of log (attached the full log):
>>>
>>> (XEN) Guest data abort: Translation fault at level 2
>>> (XEN)     gva=23c1901c
>>> (XEN)     gpa=0000000023c1901c
>>> (XEN)     size=2 sign=0 write=1 reg=0
>>> (XEN)     eat=0 cm=0 s1ptw=0 dfsc=6
>>> (XEN) dom0 IPA 0x0000000023c1901c
>>> (XEN) P2M @ 02ffbfc0 mfn:0xbfdfe
>>> (XEN) 1ST[0x0] = 0x00000000bfdfd6ff
>>> (XEN) 2ND[0x11e] = 0x0000000000000000
>>> (XEN) ----[ Xen-4.3-unstable  arm32  debug=y  Tainted:    C ]----
>>> (XEN) CPU:    0
>>> (XEN) PC:     4000893c
>>>
>>> Looks like dom0 tried to access at 23c1901c and page fault happens.
>>> I've got no idea how to figure out what is going on.
>>> Could you tell me any helpful tips to move on further?
>
> It's seems the kernel is unable to start when the zImage is loaded at
> 0x40007000. If you change this address, both in U-Boot and the DTS, by
> 0x60000000 the kernel is able to start.
>
> I updated wiki page with the new instructions and the new device tree.
>
> Cheers,
>
> Julien
>
>
> _______________________________________________
> Xen-arm mailing list
> Xen-arm@lists.xen.org
> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm

Re: [XenARM] Testing xen-arm on Arndale

[Julien Grall]

Add back xen-devel

On 07/16/2013 02:37 PM, Giridhar Maruthy wrote:
> Hi Julien,

Hello,

> My mistake.
> I went through the code and found that handle_mmio() for UART2 of
> exynos was failing. I had used a generic xen tree (4.4 unstable).
If you use my linux tree (xenbits.xen.org/people/julieng/linux-arm.git
branch arndale), the UART 2 is used by Xen and not map in dom0. So it
can't access to this UART.


> I now started using
> git://xenbits.xen.org/people/julieng/xen-unstable.git (arndale
> branch).

This branch is old, the last commit was at the end of april. I advice
you to move to 4.4 unstable. If you follow the wiki page:
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale
you should be able to boot Xen on the Arndale board.

> I still dont get a prompt. The last 3 lines on the console is as
> follows. Should I be using some other tree/branch
> 
> Machine: SAMSUNG EXYNOS5 (Flattened Device Tree), model: Insignal
> Arndale evaluation board based on EXYNOS5250
> debug: ignoring loglevel setting.
> bootconsole [xenboot0] enabled

Which version of Linux are you using?

Cheers,

-- 
Julien

Re: [XenARM] Testing xen-arm on Arndale

[Giridhar Maruthy]

Thanks Julien for the response.

Following is my environment:
Dom0 kernel: git://xenbits.xen.org/people/julieng/linux-arm.git
(arndale branch) version 3.9-rc4
Xen : git://xenbits.xen.org/people/julieng/xen-unstable.git (branch
dev-arm) version 4.4 unstable

Following are the steps followed as directed by wiki:
On linux tree,
    make xen_dom0_arndale_defconfig
    make zImage
    make exynos5250-arndale.dtb

On Xen tree,
    CONFIG_DTB_FILE=exynos5250-arndale.dtb make dist-xen
XEN_TARGET_ARCH=arm32 CROSS_COMPILE=arm-linux-gnueabihf-
    mkimage -A arm -T kernel -a 0x80200000 -e 0x80200000 -C none -d
xen/xen.bin xen-uImage


Then I loaded zImage from linux kernel to 0x60000000 and xen-uImage to
0x50000000.
I ended up getting the following error when dom0 tried to start. Are
any steps wrong or missing?



(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 220kB init memory.
(XEN) Guest data abort: Translation fault at level 3
(XEN)     gva=f8000000
(XEN)     gpa=0000000010000000
(XEN)     size=2 sign=0 write=0 reg=3
(XEN)     eat=0 cm=0 s1ptw=0 dfsc=7
(XEN) dom0 IPA 0x0000000010000000
(XEN) P2M @ 02ffbf80 mfn:0xbfdfc
(XEN) 1ST[0x0] = 0x00000000bfdfe6ff
(XEN) 2ND[0x80] = 0x00000000bfdfa6ff
(XEN) 3RD[0x0] = 0x0000000000000000

Thanks,
Giridhar


On 17 July 2013 15:09, Julien Grall <julien.grall@linaro.org> wrote:
> Add back xen-devel
>
> On 07/16/2013 02:37 PM, Giridhar Maruthy wrote:
>> Hi Julien,
>
> Hello,
>
>> My mistake.
>> I went through the code and found that handle_mmio() for UART2 of
>> exynos was failing. I had used a generic xen tree (4.4 unstable).
> If you use my linux tree (xenbits.xen.org/people/julieng/linux-arm.git
> branch arndale), the UART 2 is used by Xen and not map in dom0. So it
> can't access to this UART.
>
>
>> I now started using
>> git://xenbits.xen.org/people/julieng/xen-unstable.git (arndale
>> branch).
>
> This branch is old, the last commit was at the end of april. I advice
> you to move to 4.4 unstable. If you follow the wiki page:
> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale
> you should be able to boot Xen on the Arndale board.
>
>> I still dont get a prompt. The last 3 lines on the console is as
>> follows. Should I be using some other tree/branch
>>
>> Machine: SAMSUNG EXYNOS5 (Flattened Device Tree), model: Insignal
>> Arndale evaluation board based on EXYNOS5250
>> debug: ignoring loglevel setting.
>> bootconsole [xenboot0] enabled
>
> Which version of Linux are you using?
>
> Cheers,
>
> --
> Julien
>

Re: [XenARM] Testing xen-arm on Arndale

[Julien Grall]

On 07/17/2013 01:53 PM, Giridhar Maruthy wrote:
> Thanks Julien for the response.
> 
> Following is my environment:
> Dom0 kernel: git://xenbits.xen.org/people/julieng/linux-arm.git
> (arndale branch) version 3.9-rc4
> Xen : git://xenbits.xen.org/people/julieng/xen-unstable.git (branch
> dev-arm) version 4.4 unstable

As specified on the wiki page, you should use:
git://xenbits.xen.org/xen.git

The branch dev-arm, in my git tree, is not intended to be use by
user/developper. It mostly contains debugging patch and my on-going work
on Xen. I will rename this branch dev-arm to avoid confusion.

Currently, this branch doesn't work with linux 3.9 because the DTS is
incomplete.

-- 
Julien

Re: [XenARM] Testing xen-arm on Arndale

[Giridhar Maruthy]

Thanks a lot Julien, got the dom0 to boot.

On 17 July 2013 22:08, Julien Grall <julien.grall@linaro.org> wrote:
> On 07/17/2013 01:53 PM, Giridhar Maruthy wrote:
>> Thanks Julien for the response.
>>
>> Following is my environment:
>> Dom0 kernel: git://xenbits.xen.org/people/julieng/linux-arm.git
>> (arndale branch) version 3.9-rc4
>> Xen : git://xenbits.xen.org/people/julieng/xen-unstable.git (branch
>> dev-arm) version 4.4 unstable
>
> As specified on the wiki page, you should use:
> git://xenbits.xen.org/xen.git
>
> The branch dev-arm, in my git tree, is not intended to be use by
> user/developper. It mostly contains debugging patch and my on-going work
> on Xen. I will rename this branch dev-arm to avoid confusion.
>
> Currently, this branch doesn't work with linux 3.9 because the DTS is
> incomplete.
>
> --
> Julien
>

Re: [XenARM] Testing xen-arm on Arndale

[Giridhar Maruthy]

I am trying to use linaro quantal file system for dom0, but facing a
problem with serial console.

I see the following lines getting repeated

"init: auto-serial-console main process ended, respawning"

When I modify dom0 kernel bootargs to include init=/bin/sh, I get the prompt.

The script /bin/auto-serial-console has cases to handle only tty* as
the console. Do we have to modify it to handle hvc as serial console?

Thanks,
Giridhar



On 18 July 2013 15:28, Giridhar Maruthy <giridhar.maruthy@linaro.org> wrote:
> Thanks a lot Julien, got the dom0 to boot.
>
> On 17 July 2013 22:08, Julien Grall <julien.grall@linaro.org> wrote:
>> On 07/17/2013 01:53 PM, Giridhar Maruthy wrote:
>>> Thanks Julien for the response.
>>>
>>> Following is my environment:
>>> Dom0 kernel: git://xenbits.xen.org/people/julieng/linux-arm.git
>>> (arndale branch) version 3.9-rc4
>>> Xen : git://xenbits.xen.org/people/julieng/xen-unstable.git (branch
>>> dev-arm) version 4.4 unstable
>>
>> As specified on the wiki page, you should use:
>> git://xenbits.xen.org/xen.git
>>
>> The branch dev-arm, in my git tree, is not intended to be use by
>> user/developper. It mostly contains debugging patch and my on-going work
>> on Xen. I will rename this branch dev-arm to avoid confusion.
>>
>> Currently, this branch doesn't work with linux 3.9 because the DTS is
>> incomplete.
>>
>> --
>> Julien
>>

Re: [XenARM] Testing xen-arm on Arndale

[Julien Grall]

On 07/18/2013 02:43 PM, Giridhar Maruthy wrote:
> I am trying to use linaro quantal file system for dom0, but facing a
> problem with serial console.
> 
> I see the following lines getting repeated
> 
> "init: auto-serial-console main process ended, respawning"
> 
> When I modify dom0 kernel bootargs to include init=/bin/sh, I get the prompt.
> 
> The script /bin/auto-serial-console has cases to handle only tty* as
> the console. Do we have to modify it to handle hvc as serial console?

I have created a file /etc/init/hvc0.conf with the following data:
==================================================================
# hvc0 - getty
#
# This service maintains a getty on tty1 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345] and (
            not-container or
            container CONTAINER=lxc or
            container CONTAINER=lxc-libvirt)

stop on runlevel [!2345]

respawn
exec /sbin/getty -8 38400 hvc0
==================================================================

This file will start a service and allow you to access to the console.

In future, I think Linaro quantal must be able to handle hvc0 without
any modifications.

Cheers,

-- 
Julien

Re: [XenARM] Testing xen-arm on Arndale

[Giridhar Maruthy]

Great! Thanks.

On 18 July 2013 19:24, Julien Grall <julien.grall@citrix.com> wrote:
> On 07/18/2013 02:43 PM, Giridhar Maruthy wrote:
>> I am trying to use linaro quantal file system for dom0, but facing a
>> problem with serial console.
>>
>> I see the following lines getting repeated
>>
>> "init: auto-serial-console main process ended, respawning"
>>
>> When I modify dom0 kernel bootargs to include init=/bin/sh, I get the prompt.
>>
>> The script /bin/auto-serial-console has cases to handle only tty* as
>> the console. Do we have to modify it to handle hvc as serial console?
>
> I have created a file /etc/init/hvc0.conf with the following data:
> ==================================================================
> # hvc0 - getty
> #
> # This service maintains a getty on tty1 from the point the system is
> # started until it is shut down again.
>
> start on stopped rc RUNLEVEL=[2345] and (
>             not-container or
>             container CONTAINER=lxc or
>             container CONTAINER=lxc-libvirt)
>
> stop on runlevel [!2345]
>
> respawn
> exec /sbin/getty -8 38400 hvc0
> ==================================================================
>
> This file will start a service and allow you to access to the console.
>
> In future, I think Linaro quantal must be able to handle hvc0 without
> any modifications.
>
> Cheers,
>
> --
> Julien