Re: [Xen-devel] [arm64] How to compile libc-for-xen on arm64?

[Ajay Garg]

Ideas please.

Perhaps some way to pick up (arm64) xen-stuff from
https://github.com/zyzii/mini-os/tree/arm64-v3, and (arm64) libc stuff
from http://xenbits.xen.org/xen.git (provided libc for arm32 and arm64
is same)?

On Sat, Jun 9, 2018 at 11:31 AM, Ajay Garg  wrote:
> += xen-devel
>
> On Sat, Jun 9, 2018 at 10:55 AM, Ajay Garg  wrote:
>> Hi All.
>>
>> a)
>> git://xenbits.xen.org/xen.git does not have a arm64 listing in the
>> stubdom directory.
>> Upon running "make c", following is seen :
>>
>> \u@\h:\w$ make c
>> /xen/stubdom/../extras/mini-os/Config.mk:86:
>> /xen/stubdom/../extras/mini-os/arch/arm64/arch.mk: No such file or
>> directory
>> make: *** No rule to make target
>> `/xen/stubdom/../extras/mini-os/arch/arm64/arch.mk'.  Stop.
>>
>>
>> b)
>> Any chance libc could be built from
>> https://github.com/zyzii/mini-os/tree/arm64-v3 ?
>>
>>
>> Thanks and Regards,
>> Ajay

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [arm64] How to compile libc-for-xen on arm64?

[Ajay Garg]

+= xen-devel

On Sat, Jun 9, 2018 at 10:55 AM, Ajay Garg  wrote:
> Hi All.
>
> a)
> git://xenbits.xen.org/xen.git does not have a arm64 listing in the
> stubdom directory.
> Upon running "make c", following is seen :
>
> \u@\h:\w$ make c
> /xen/stubdom/../extras/mini-os/Config.mk:86:
> /xen/stubdom/../extras/mini-os/arch/arm64/arch.mk: No such file or
> directory
> make: *** No rule to make target
> `/xen/stubdom/../extras/mini-os/arch/arm64/arch.mk'.  Stop.
>
>
> b)
> Any chance libc could be built from
> https://github.com/zyzii/mini-os/tree/arm64-v3 ?
>
>
> Thanks and Regards,
> Ajay

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [For knowledge-sake] Understanding of couple of things under the hood

[Ajay Garg]

Thanks a ton Julien, that was mighty useful !!

On Tue, May 1, 2018 at 4:44 PM, Julien Grall <julien.gr...@arm.com> wrote:
>
>
> On 01/05/18 11:27, Ajay Garg wrote:
>>
>> Hi All.
>
>
> Hello,
>
>
>> I have been able to bring up xen on cubieboard2, using the following
>> script gathered from google :
>>
>> ###
>> # SUNXI Xen Boot Script
>> # Arch Linux ARM adaption of the cmd file which can be found at
>> http://openmirage.org/wiki/xen-on-cubieboard2
>>
>> # Addresses suitable for 1GB system, adjust as appropriate for a 2GB
>> system.
>> # Top of RAM: 0x8000
>> # Xen relocate addr   0x7fe0
>> setenv kernel_addr_r  0x7f60 # 10 MB
>> setenv fdt_addr   0x7ec0 #  2 MB
>> setenv xen_addr_r 0x7ea0 #  2 MB
>>
>> setenv fdt_high  0x # Load fdt in place instead of relocating
>>
>> # Load xen/xen to ${xen_addr_r}.
>> fatload mmc 0 ${xen_addr_r} /xen
>> setenv bootargs "dom0_mem=256M"
>>
>> # Load appropriate .dtb file to ${fdt_addr}
>> fatload mmc 0 ${fdt_addr} /sun7i-a20-cubieboard2.dtb
>> fdt addr ${fdt_addr} 0x4
>> fdt resize
>> fdt chosen
>> fdt set /chosen \#address-cells <1>
>> fdt set /chosen \#size-cells <1>
>>
>> # Load Linux arch/arm/boot/zImage to ${kernel_addr_r}
>> fatload mmc 0 ${kernel_addr_r} /zImage
>>
>> 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 rw root=/dev/mmcblk0p2
>> rootwait  clk_ignore_unused"
>>
>> bootz ${xen_addr_r} - ${fdt_addr}
>> ###
>>
>>
>> I have been able to understand most of the workflow, except three things :
>>
>> a)
>> Is the relocation-address of xen, given by
>> # Xen relocate addr   0x7fe0
>> hardcoded? Or it is computed someway from ${kernel_addr_r},
>> {fdt_addr}, {xen_addr_r}?
>>
>> In the bootup logs, xen does relocate to 0x7fe0, so surely there
>> is some magic going ..
>
>
> Xen will always relocate towards the end of the memory. See get_xen_paddr()
> in xen/arch/arm/setup.c. As the placement of the binaries by U-boot will
> have an impact to the relocation address, you need to cleverly choose the
> different addresses.
>
>>
>>
>> b)
>> What does the argument 0x4 signify in the following :
>> fdt addr ${fdt_addr} 0x4
>>
>> I consulted https://www.denx.de/wiki/DULG/UBootCmdFDT, but did not
>> find anything about this third argument.
>
>
> It is explained in section 5.9.7.7. The length is optional and used to tell
> the size of the FDT. This is useful in case the original FDT is not big
> enough to create more properties/nodes.
>
>>
>>
>> c)
>> I assume filesize is the size of the kernel-binary, but how is it
>> determined in the following :
>> fdt set /chosen/module@0 reg <${kernel_addr_r}
>> 0x${filesize} >
>
>
> filesize will contain the size of the latest binary load in memory. The
> udpate will be done by fatload command.
>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,
Ajay

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [For knowledge-sake] Understanding of couple of things under the hood

[Ajay Garg]

Hi All.

I have been able to bring up xen on cubieboard2, using the following
script gathered from google :

###
# SUNXI Xen Boot Script
# Arch Linux ARM adaption of the cmd file which can be found at
http://openmirage.org/wiki/xen-on-cubieboard2

# Addresses suitable for 1GB system, adjust as appropriate for a 2GB system.
# Top of RAM: 0x8000
# Xen relocate addr   0x7fe0
setenv kernel_addr_r  0x7f60 # 10 MB
setenv fdt_addr   0x7ec0 #  2 MB
setenv xen_addr_r 0x7ea0 #  2 MB

setenv fdt_high  0x # Load fdt in place instead of relocating

# Load xen/xen to ${xen_addr_r}.
fatload mmc 0 ${xen_addr_r} /xen
setenv bootargs "dom0_mem=256M"

# Load appropriate .dtb file to ${fdt_addr}
fatload mmc 0 ${fdt_addr} /sun7i-a20-cubieboard2.dtb
fdt addr ${fdt_addr} 0x4
fdt resize
fdt chosen
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>

# Load Linux arch/arm/boot/zImage to ${kernel_addr_r}
fatload mmc 0 ${kernel_addr_r} /zImage

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 rw root=/dev/mmcblk0p2
rootwait  clk_ignore_unused"

bootz ${xen_addr_r} - ${fdt_addr}
###


I have been able to understand most of the workflow, except three things :

a)
Is the relocation-address of xen, given by
   # Xen relocate addr   0x7fe0
hardcoded? Or it is computed someway from ${kernel_addr_r},
{fdt_addr}, {xen_addr_r}?

In the bootup logs, xen does relocate to 0x7fe0, so surely there
is some magic going ..


b)
What does the argument 0x4 signify in the following :
   fdt addr ${fdt_addr} 0x4

I consulted https://www.denx.de/wiki/DULG/UBootCmdFDT, but did not
find anything about this third argument.


c)
I assume filesize is the size of the kernel-binary, but how is it
determined in the following :
   fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize} >


Will be grateful for some help, as it will gain deeper understanding
of the ecosystem.


Thanks and Regards,
Ajay

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [cubieboard2] Bringing up dom0

[Ajay Garg]

Thanks a ton Amit .. that worked !!
"sudo xl list" now shows Domain-0 :)

On Mon, Apr 30, 2018 at 12:10 PM, Amit Tomer  wrote:

> Hello
> >
> > debian@debian-armhf:~$ sudo xl list
> > NameID   Mem VCPUsState
> > Time(s)
> >
> >
> > Now what am I missing?
>
> You may need to run following
>
> # /etc/init.d/xencommons start
>
> Thanks
> -Amit
>



Thanks and Regards,
Ajay
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [cubieboard2] Bringing up dom0

[Ajay Garg]

d. ok
[   21.960384] random: dbus-daemon: uninitialized urandom read (12 bytes
read)
[   21.996335] random: dbus-daemon: uninitialized urandom read (12 bytes
read)
[   22.038283] random: sshd: uninitialized urandom read (32 bytes read)
[] Starting periodic command scheduler: cron. ok
[] Starting system message bus: dbus. ok
[] Starting OpenBSD Secure Shell server: sshd. ok
#


c)
After I ssh into the machine, following just hangs (without returning to
prompt) :

debian@debian-armhf:~$ sudo xl list
Name    ID   Mem VCPUsState
Time(s)


Now what am I missing?

On Sun, Apr 29, 2018 at 11:30 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:

> I changed the /chosen node in the dts file to
>
> ###
> chosen {
> stdout-path = "serial0:115200n8";
> xen,xen-bootargs = "dom0_mem=752M console=dtuart dtuart=serial0
> dom0_max_vcpus=4";
> xen,dom0-bootargs = "console=ttyS0,115200 rw root=/dev/mmcblk0p2
> ignore_loglevel cma=128M";
> modules {
> #address-cells = <2>;
> #size-cells = <2>;
> module@1 {
> compatible = "xen,linux-zimage", "xen,multiboot-module";
> reg = <0x0 0x7a00 0x0 0x0200>;
> };
> };
> };
> ###
>
>
>
> Also, the xen-related features in the kernel are as follows (created by
> default after selecting "Kernel features => Xen guest support on ARM" in
> menuconfig) :
>
> ###
>   CONFIG_XEN_DOM0=y
>   CONFIG_XEN=y
>   CONFIG_XEN_BLKDEV_FRONTEND=y
>   CONFIG_XEN_NETDEV_FRONTEND=y
>   CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
>   CONFIG_HVC_XEN=y
>   CONFIG_HVC_XEN_FRONTEND=y
>   CONFIG_XEN_FBDEV_FRONTEND=y
>   CONFIG_XEN_BALLOON=y
>   CONFIG_XEN_SCRUB_PAGES=y
>   CONFIG_XEN_DEV_EVTCHN=y
>   CONFIG_XEN_BACKEND=y
>   CONFIG_XENFS=y
>   CONFIG_XEN_COMPAT_XENFS=y
>   CONFIG_XEN_SYS_HYPERVISOR=y
>   CONFIG_XEN_XENBUS_FRONTEND=y
>   CONFIG_XEN_GNTDEV=m
>   CONFIG_XEN_GRANT_DEV_ALLOC=m
>   CONFIG_SWIOTLB_XEN=y
>   CONFIG_XEN_PRIVCMD=y
>   CONFIG_XEN_AUTO_XLATE=y
>
>
>   # CONFIG_XEN_BLKDEV_BACKEND is not set
>   # CONFIG_XEN_SCSI_FRONTEND is not set
>   # CONFIG_XEN_NETDEV_BACKEND is not set
>   # CONFIG_XEN_WDT is not set
>   # CONFIG_XEN_PVCALLS_FRONTEND is not set
>   # CONFIG_XEN_PVCALLS_BACKEND is not set
> ###
>
> However, I see absolutely no change in the observations; no xen-related
> log on the serial-console, and "sudo xl list" gives the same error messages.
>
> What am I lacking?
>
>
> On Sat, Apr 28, 2018 at 11:06 PM, Andrew Cooper <andrew.coop...@citrix.com
> > wrote:
>
>> On 28/04/18 18:34, Ajay Garg wrote:
>>
>> Hi Andrew.
>>
>> Thanks for the reply.
>>
>> On Sat, Apr 28, 2018 at 10:57 PM, Andrew Cooper <
>> andrew.coop...@citrix.com> wrote:
>>
>>> On 28/04/18 18:12, Ajay Garg wrote:
>>>
>>> Hi All.
>>>
>>> We have brought up the cubieboard2 from almost scratch, following are
>>> the steps done :
>>>
>>> 
>>>
>>> == getting xen ready ==
>>>
>>> i)
>>> Compiled xen on cubieboard itself, via :
>>>
>>>* git clone git://xenbits.xen.org/xen.git
>>>* cd xen
>>> .  * ./configure --libdir=/usr/lib
>>>* make debball CONFIG_EARLY_PRINTK=sun7i -j4
>>>* sudo dpkg -i dist/xen-upstream-4.11-unstable.deb
>>>* sudo reboot
>>>
>>> ii)
>>> Upon reboot, "sudo xl list" gives following :
>>>
>>> ##
>>> debian@debian-armhf:~$ sudo  xl list
>>> [sudo] password for debian:
>>> xencall: error: Could not obtain handle on privileged command interface:
>>> No such file or directory
>>> libxl: error: libxl.c:102:libxl_ctx_alloc: cannot open libxc handle: No
>>> such file or directory
>>> cannot init xl context
>>> ##
>>>
>>>
>>> This means that /dev/xen/privcmd (or the legacy /proc/xen/privcmd)
>>> device isn't available.
>>>
>>> First check that you have actually booted Xen with Linux as dom0.  You
>>> don't show any logs in this final section, and simply installing the
>>> debball and rebooting won't typically cause Xen to be the head of the boot
>>> list.
>>>
>>
>> Yes, I haven't been able to setup xen bootup.
>>
>> That's why, requested help regarding the changes that are required in
>> https://github.com/torvalds/linux/blob/master/arch/arm/boot/
>> dts/sun7i-a20-cubieboard2.dts, that would cause dom0 to boot up.
>>
>>
>> Sorry for the confusion.
>>
>>
>> Ah - sorry.  I misunderstood.  I'm afraid you're going to have to wait
>> for some people more knowledge about ARM to answer.
>>
>> ~Andrew
>>
>
>
>
> --
> Regards,
> Ajay
>



-- 
Regards,
Ajay
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [cubieboard2] Bringing up dom0

[Ajay Garg]

Hi Andrew.

Thanks for the reply.

On Sat, Apr 28, 2018 at 10:57 PM, Andrew Cooper <andrew.coop...@citrix.com>
wrote:

> On 28/04/18 18:12, Ajay Garg wrote:
>
> Hi All.
>
> We have brought up the cubieboard2 from almost scratch, following are the
> steps done :
>
> 
>
> == getting xen ready ==
>
> i)
> Compiled xen on cubieboard itself, via :
>
>* git clone git://xenbits.xen.org/xen.git
>* cd xen
> .  * ./configure --libdir=/usr/lib
>* make debball CONFIG_EARLY_PRINTK=sun7i -j4
>* sudo dpkg -i dist/xen-upstream-4.11-unstable.deb
>* sudo reboot
>
> ii)
> Upon reboot, "sudo xl list" gives following :
>
> ##
> debian@debian-armhf:~$ sudo  xl list
> [sudo] password for debian:
> xencall: error: Could not obtain handle on privileged command interface:
> No such file or directory
> libxl: error: libxl.c:102:libxl_ctx_alloc: cannot open libxc handle: No
> such file or directory
> cannot init xl context
> ##
>
>
> This means that /dev/xen/privcmd (or the legacy /proc/xen/privcmd) device
> isn't available.
>
> First check that you have actually booted Xen with Linux as dom0.  You
> don't show any logs in this final section, and simply installing the
> debball and rebooting won't typically cause Xen to be the head of the boot
> list.
>

Yes, I haven't been able to setup xen bootup.

That's why, requested help regarding the changes that are required in
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts,
that would cause dom0 to boot up.


Sorry for the confusion.


Thanks and Regards,
Ajay
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [cubieboard2] Bringing up dom0

[Ajay Garg]

Hi All.

We have brought up the cubieboard2 from almost scratch, following are the
steps done :


== u-boot ==

u-boot has been compiled using bleeding-edge mainline
(ec5c4a8fd64a178a4d159917cda0aa176e5a9be5), via :

* make Cubieboard2_defconfig
* make ARCH=arm
CROSS_COMPILE=/home/ajay/arm-toolchain-6.2/arm-linux-gnueabihf-

This gives us u-boot-sunxi-with-spl.bin



== kernel ==

kernel also has been compiled using bleeding-edge mainline
(6d08b06e67cd117f6992c46611dfb4ce267cd71e) via :

* make clean
* make ARCH=arm sunxi_defconfig menuconfig

  In the menu, enabled following additional features :

  * General setup => System V IPC
  * General setup => POSIX Message Queues
  * Kernel features => Xen guest support on ARM


* make -j$(nproc) ARCH=arm
CROSS_COMPILE=/home/ajay/arm-toolchain-6.2/arm-linux-gnueabihf- zImage
* make -j$(nproc) ARCH=arm
CROSS_COMPILE=/home/ajay/arm-toolchain-6.2/arm-linux-gnueabihf-
sun7i-a20-cubieboard2.dtb

This gives us zImage and sun7i-a20-cubieboard2.dtb.



== integration, and starting up ==

Followed the steps as per
https://github.com/maronai/cubieboard/wiki/3.1.-Compiling-mainline-kernel-for-CubieBoard2-and-CubieTruck,
but with following differences :

a)
Used u-boot-sunxi-with-spl.bin, zImage, sun7i-a20-cubieboard2.dtb from
above steps.

b)
Used (and compiled to boot.scr) the following boot.cmd :

fatload mmc 0 0x4600 zImage
fatload mmc 0 0x4900 sun7i-a20-cubieboard2.dtb
setenv bootargs console=ttyS0,115200 rw root=/dev/mmcblk0p2
bootz 0x4600 - 0x4900

c)
Extracted debian-wheezy-7.5-armhf.com-20140603.tar to the rootfs partition
on the sd-card.

d)
Finally, inserted the sdcard in cubieboard2, following are the brief bootup
logs :

##
U-Boot SPL 2018.05-rc2-00118-gec5c4a8 (Apr 28 2018 - 08:40:48
+0530)
DRAM: 1024
MiB
CPU: 91200Hz, AXI/AHB/APB:
3/2/2
Trying to boot from
MMC1




U-Boot 2018.05-rc2-00118-gec5c4a8 (Apr 28 2018 - 08:40:48 +0530) Allwinner
Techy


CPU:   Allwinner A20
(SUN7I)
Model: Cubietech
Cubieboard2
I2C:
ready
DRAM:  1
GiB
MMC:   SUNXI SD/MMC:
0
Loading Environment from FAT... *** Warning - bad CRC, using default
environment


Failed
(-5)
In:
serial
Out:
serial
Err:
serial
SCSI:  SATA link 0
timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA
mode
flags: ncq stag pm led clo only pmp pio slum part ccc
apst
Net:   eth0: ethernet@01c5

starting
USB...
USB0:   USB EHCI
1.00
USB1:   USB OHCI
1.0
USB2:   USB EHCI
1.00
USB3:   USB OHCI
1.0
scanning bus 0 for devices... 1 USB Device(s)
found
scanning bus 2 for devices... 1 USB Device(s)
found
   scanning usb for storage devices... 0 Storage Device(s)
found
Hit any key to stop autoboot:
0
switch to partitions #0,
OK
mmc0 is current
device
Scanning mmc
0:1...
Found U-Boot script
/boot.scr
245 bytes read in 12 ms (19.5
KiB/s)
## Executing script at
4310
4076736 bytes read in 247 ms (15.7
MiB/s)
26147 bytes read in 24 ms (1
MiB/s)
## Flattened Device Tree blob at
4900
   Booting using the fdt blob at
0x4900
   Loading Device Tree to 49ff6000, end 49fff622 ...
OK


Starting kernel
...


[0.00] Booting Linux on physical CPU
0x0
[0.00] Linux version 4.17.0-rc2 (ajay@latitude-3480) (gcc version
6.2.18
[0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7),
cr=10c5387d
[0.00] CPU: div instructions available: patching division
code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instructie
[0.00] OF: fdt: Machine model: Cubietech
Cubieboard2
[0.00] Memory policy: Data cache
writealloc
[0.00] cma: Reserved 16 MiB at
0x7f00
[0.00] psci: probing for conduit method from
DT.
[0.00] psci: Using PSCI v0.1 Function IDs from
DT
[0.00] random: get_random_bytes called from start_kernel+0xa0/0x3fc
wit0
[0.00] percpu: Embedded 16 pages/cpu @(ptrval) s34764 r8192 d22580
u6556
[0.00] Built 1 zonelists, mobility grouping on.  Total pages:
260608
[0.00] Kernel command line: console=ttyS0,115200 rw
root=/dev/mmcblk0p2
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes)
[0.00] Memory: 1013064K/1048576K available (6144K kernel code, 427K
rwd)
[0.00] Virtual kernel memory
layout:
[0.00] vector  : 0x - 0x1000   (   4
kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072
kB)
[0.00] vmalloc : 0xf080 - 0xff80   ( 240
MB)
[0.00] lowmem  : 0xc000 - 0xf000   ( 768
MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2
MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14
MB)
[0.00]   .text : 0x(ptrval) - 0x(ptrval)   (7136
kB)
[0.00]   .init : 0x(ptrval) - 0x(ptrval)   (1024
kB)
[0.00]   .data : 0x(ptrval) - 0x(ptrval)   ( 428
kB)
[0.00].bss : 

[Xen-devel] Unikernels for xen ?

[Ajay Garg]

Hi All.

Just a quick question ...

We know that rumprun and unikraft are the two major unikernels with xen
support.

https://wiki.xenproject.org/wiki/Unikernels mention a lot of unikernels.
Also, we intend to have python-applications running over xen. So, I guess
Ocaml/Go/Erlang/JS based unikernels are out of the picture.

In summary, any unikernels other than rumprun/unikraft that may facilitate
running python-applications in xen-context (a C/C++ unikernel is fine, as
porting  python to such c/c++ based unikernel ought to be feasible).


Thanks and Regards,
Ajay
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen-4.10 Domain-0 crashes at bootup

[Ajay Garg]

Hi All.

As suggested by Michael. I compiled the kernel as per
https://lkml.org/lkml/2018/2/23/59, containing the patch
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00045.html.

Upon installing this fresh kernel, the machine booted fine with Xen
enabled (just needed an additional "sudo apt-get install libyajl-dev"
and another reboot to get the proper listing of "Domain-0".

So, at least from my side, this thread can be marked solved/closed.


Thanks and Regards,
Ajay

On Wed, Apr 4, 2018 at 8:45 PM, Juergen Gross <jgr...@suse.com> wrote:
> On 04/04/18 17:00, M A Young wrote:
>> On Wed, 4 Apr 2018, Ajay Garg wrote:
>>
>>> Thanks Michael for the reply.
>>>
>>> I want to give this patch a try, as the symptoms look identical.
>>> However, I see no xen-head.S when I clone the repo from
>>> git://xenbits.xen.org/xen.git
>>>
>>> What am I missing?
>>
>> The patch is for the xen code in the kernel. It was accepted in the kernel
>> upstream (in 4.15.5 and probably backported to other maintained kernels)
>> so you probably just need a kernel less than a month old, but as has
>> already been said, the kernel may not be the problem.
>
> And the symptoms are completely different (well, at least for me).
>
> Ajay's crash is due to an illegal instruction, so probably a BUG().
>
> The patch above fixes an early page fault in the kernel.
>
>
> Juergen



-- 
Regards,
Ajay

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen-4.10 Domain-0 crashes at bootup

[Ajay Garg]

Thanks Michael for the reply.

I want to give this patch a try, as the symptoms look identical.
However, I see no xen-head.S when I clone the repo from
git://xenbits.xen.org/xen.git

What am I missing?


Thanks and Regards,
Ajay

>
> It is a kernel problem under some compile conditions. See for example
> https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00010.html
> and the patch at
> https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00045.html
>
> Michael Young

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen-4.10 Domain-0 crashes at bootup

[Ajay Garg]

Since I failed to get a single reply on my original issue as per
https://lists.xenproject.org/archives/html/minios-devel/2018-04/msg4.html,
so I had no option but to try on a newer xen version.

So, I created  a  new virtualbox-guest, and followed the steps as per
https://blog.werk21.de/en/2018/02/08/build-xen-hypervisor-410-and-xen-tools-ubuntu-1604-pvh

Now, when start the guest with Xen-hypervisor enabled, it does not come up.
I took serial-logs at bootup time, they are as follows :

#
 Xen 4.10.1-pre
(XEN) Xen version 4.10.1-pre (ajay@) (gcc (Ubuntu
5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609) debug=n  Wed Apr  4 12:54:58
IST 2018
(XEN) Latest ChangeSet: Tue Mar 20 14:23:14 2018 +0100 git:0f92968
(XEN) Bootloader: GRUB 2.02~beta2-36ubuntu3.17
(XEN) Command line: placeholder console=com1 com1=115200,8n1
loglvl=all guest_loglvl=all
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 0009fc00 (usable)
(XEN)  0009fc00 - 000a (reserved)
(XEN)  000f - 0010 (reserved)
(XEN)  0010 - bfff (usable)
(XEN)  bfff - c000 (ACPI data)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  fffc - 0001 (reserved)
(XEN) New Xen image base address: 0xbf80
(XEN) System RAM: 3071MB (3145276kB)
(XEN) ACPI: RSDP 000E, 0024 (r2 VBOX  )
(XEN) ACPI: XSDT BFFF0030, 003C (r1 VBOX   VBOXXSDT1 ASL61)
(XEN) ACPI: FACP BFFF00F0, 00F4 (r4 VBOX   VBOXFACP1 ASL61)
(XEN) ACPI: DSDT BFFF0470, 21FF (r2 VBOX   VBOXBIOS2 INTL 20160108)
(XEN) ACPI: FACS BFFF0200, 0040
(XEN) ACPI: APIC BFFF0240, 0054 (r2 VBOX   VBOXAPIC1 ASL61)
(XEN) ACPI: SSDT BFFF02A0, 01CC (r1 VBOX   VBOXCPUT2 INTL 20160108)
(XEN) No NUMA configuration found
(XEN) Faking a node at -bfff
(XEN) Domain heap initialised
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 142 (0x8e), Stepping 9
(raw 000806e9)
(XEN) found SMP MP-table at 0009fff0
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x4008 (32 bits)
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:4004,1:0], pm1x_evt[1:4000,1:0]
(XEN) ACPI: wakeup_vec[bfff020c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ERST table was not found
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 1 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 184 MSI/MSI-X
(XEN) Not enabling x2APIC: depends on iommu_supports_eim.
(XEN) xstate: size: 0x440 and states: 0x7
(XEN) CPU0: No MCE banks present. Machine check support disabled
(XEN) Speculative mitigation facilities:
(XEN)   Compiled-in support: INDIRECT_THUNK
(XEN) BTI mitigations: Thunk RETPOLINE, Others: RSB_NATIVE RSB_VMEXIT
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Detected 2712.035 MHz processor.
(XEN) Initing memory sharing.
(XEN) alt table 82d080421798 -> 82d080423244
(XEN) I/O virtualisation disabled
(XEN) nr_sockets: 1
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Allocated console ring of 16 KiB.
(XEN) Brought up 1 CPUs
(XEN) build-id: 0734050809e0cb9f52e65322a0d3911d082e348b
(XEN) CPUIDLE: disabled due to no HPET. Force enable with 'cpuidle'.
(XEN) ACPI sleep modes: S3
(XEN) VPMU: disabled
(XEN) xenoprof: Initialization failed. Intel processor family 6 model
142 is not supported
(XEN) Dom0 has maximum 208 PIRQs
(XEN) NX (Execute Disable) protection active
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x2957000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   b400->b800 (715309 pages
to be allocated)
(XEN)  Init. ramdisk: bc915000->bf7ffed9
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 8100->82957000
(XEN)  Init. ramdisk: ->
(XEN)  Phys-Mach map: 0080->0080005ac8c0
(XEN)  Start info:82957000->829574b4
(XEN)  Xenstore ring: