Re: [Xen-devel] Xen support on ARM64
Hi Julien, Awesome, after applying those patches in latest xen, hikey960 able to enable 4 CPUs and other four CPUs are giving error -5. And after using "hmp-unsafe" in xen command line, all CPUs got enabled successfully. Thank you, Omkar B On Mon, Dec 3, 2018 at 7:27 PM Julien Grall wrote: > > > On 29/11/2018 07:39, Omkar Bolla wrote: > > Hi, > > Hello, > > > I just wanted to run xen hypervisor on ARMv8 architecture, I tried on > Hikey960 > > platform which has armv8, but latest xen giving cpu errors. > > > > Could you please tell me, on which platforms latest xen is working? > > If your platform supports virtualization. Then there are a good chance for > Xen > to boot on it out-of-box. So what platform are you looking at? > > Regarding the hikey960, there are patches on the ML to fix boot. See [1]. > > Cheers, > > [1] > https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03360.html > > -- > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen support on ARM64
Hi, I just wanted to run xen hypervisor on ARMv8 architecture, I tried on Hikey960 platform which has armv8, but latest xen giving cpu errors. Could you please tell me, on which platforms latest xen is working? Thanks, Omkar B ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Problems building and running Xen on Hikey960
HI Mathues, I checked your log and crashes in xen and linux. Do following things to fix or move further. On Fri, Nov 9, 2018 at 4:52 PM Julien Grall wrote: > > > On 08/11/2018 07:07, Matthew Daley wrote: > > Hi all, > > Hi Matthew, > > > > > I'm trying to build and run Linux (Debian) on top of Xen on a Hikey960 > > ARM board but am having trouble. > > > > I've been following Konrad's guide on the Wiki (at > > https://wiki.xenproject.org/wiki/HiKey960), namely: > > * I have upgraded the board's base firmware to support UEFI > > * I am building the hikey960-upstream-rebase branch of > > https://github.com/96boards-hikey/linux.git (with a patch from Linus's > > tree to fix a Hynix UFS bug) > > * I am building the master branch of Xen unstable > > * I am building the master branch of GRUB (with a patch to fix a DTB > > padding bug) > > > > However, I see two problems when booting. > > > > Firstly, Xen fails to bring up any other CPUs but the one it is booting > on: > > > > (XEN) Bringing up CPU1 > > (XEN) Failed to bring up CPU1 > > (XEN) Failed to bring up CPU 1 (error -9) > > (XEN) Bringing up CPU2 > > (XEN) Failed to bring up CPU2 > > (XEN) Failed to bring up CPU 2 (error -9) > > (XEN) Bringing up CPU3 > > (XEN) Failed to bring up CPU3 > > (XEN) Failed to bring up CPU 3 (error -9) > > (XEN) Bringing up CPU4 > > (XEN) Failed to bring up CPU4 > > (XEN) Failed to bring up CPU 4 (error -9) > > (XEN) Bringing up CPU5 > > (XEN) Failed to bring up CPU5 > > (XEN) Failed to bring up CPU 5 (error -9) > > (XEN) Bringing up CPU6 > > (XEN) Failed to bring up CPU6 > > (XEN) Failed to bring up CPU 6 (error -9) > > (XEN) Bringing up CPU7 > > (XEN) Failed to bring up CPU7 > > (XEN) Failed to bring up CPU 7 (error -9) > > (XEN) Brought up 1 CPUs > > > > I have traced this error code -9 being returned by call_psci_cpu_on. > > A similar error was reported a couple of months on the mailing list. From > the > report, a regression was introduced between Xen 4.8 and unstable. > > Unfortunately, I don't have an hikey board to bisect it. May I ask if you > can > bisect it? If you can point the offending commit, I should be able to > provide > ideas why it breaks. > > As Julien said, For your CPUs problem in Hikey960, use 4.8 of xen source, Then all CPUs will be enabled and worked properly. > > > > Secondly, Linux fails when it tries to initialise AMBA devices: > > > > [0.941352] Synchronous External Abort: synchronous external abort > > (0x96000210) at 0x093fdfe > > 0 > > [0.950601] Internal error: : 96000210 [#1] PREEMPT SMP > > [0.955866] Modules linked in: > > [0.958990] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > 4.14.0-rc7-linaro-hikey960+ #8 > > [0.966791] Hardware name: HiKey960 (DT) > > [0.970777] task: 80001d90 task.stack: 08058000 > > [0.976778] PC is at amba_device_try_add+0x108/0x260 > > [0.981791] LR is at amba_device_try_add+0xf0/0x260 > > [0.986735] pc : [] lr : [] > > pstate: 6045 > > [0.994192] sp : 0805bbf0 > > [0.997572] x29: 0805bbf0 x28: > > [1.002953] x27: 090203a8 x26: > > [1.008326] x25: 80001dbf9810 x24: > > [1.013702] x23: 093fd000 x22: 1000 > > [1.019079] x21: 80001cc1b6f8 x20: > > [1.024455] x19: 80001cc1b400 x18: 0010 > > [1.029832] x17: 0001 x16: deadbeef > > [1.035209] x15: 0006 x14: > > [1.040585] x13: 0020 x12: 0101010101010101 > > [1.045962] x11: 0020 x10: 0101010101010101 > > [1.051338] x9 : x8 : 80001cc0cf00 > > [1.056717] x7 : x6 : 003f > > [1.062092] x5 : x4 : > > [1.067468] x3 : x2 : > > [1.072845] x1 : 80001d90 x0 : 093fdfe0 > > [1.078223] Process swapper/0 (pid: 1, stack limit = > 0x08058000) > > [1.084989] Call trace: > > [1.087504] Exception stack(0x0805bab0 to 0x0805bbf0) > > [1.094008] baa0: > > 093fdfe0 80001d90 > > [1.101902] bac0: > > > > [1.109790] bae0: 003f > > 80001cc0cf00 > > [1.117684] bb00: 0101010101010101 0020 > > 0101010101010101 0020 > > [1.125576] bb20: 0006 > > deadbeef 0001 > > [1.133468] bb40: 0010 80001cc1b400 > > 80001cc1b6f8 > > [1.141356] bb60: 1000 093fd000 > > 80001dbf9810 > > [1.149248] bb80: 090203a8 > > 0805bbf0 > > [1.157139] bba0: 084ead90 0805bbf0 > > 084eada8
Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains
Hi,
>
> > I am trying to pass-through the display to guest domain. to do through
> > driver needs clocks. I have written simple basic clock pv frontend and
> > backend.
> > So I thought these clocks must be initialised before display driver
> > initialisation.
>
> The graphic driver should request the clock, right? So Linux will make
> sure to have the clock before initializing the display.
>
We are not using graphics(GPU), I think drm takes care of graphics. And all
clocks needed for display I enabled using clocks PV. Clocks i have checked
in host domain all got enabled properly.
> >
> > But if I start both domain and clocks script one after another, clock
> > got initialised properly. Problem solved.
> > But still i have some doubt, is it possible to do some thing in xenbits
> > src to start automatically when we start underprivileged domain?
>
> I am not entirely sure if we have a way to run a script during domain
> creation. Wei, do you know if that's possible?
>
> A workaround would be to create the domain paused, call the script and
> then unpause it.
>
> 42sh> xl create -p ...
> 42sh> ./myscript.sh
> 42sh> xl unpause
>
Now, I am doing same way pause and unpauase domain to start PV and it is
working.
>
> >
> > I have one more question about pass-through
> > To implement pass through I took reference from below link
> > https://wiki.xen.org/images/1/17/Device_passthrough_xen.pdf
> >
> > I added 'xen-passthrough' to actual dom0 dtb and created new dtb with
> > below nodes in passthrough node
> >
>
> > dpe: dpe@10004000 {
> > compatible = "hisilicon,hi3660-dpe";
> > status = "ok";
> > #if 0
> > //ACTUAL REG PROPERTY of DISPLAY
> > reg = <0x0 0xE860 0x0 0x8>,
> > <0x0 0xFFF35000 0 0x1000>,
> > <0x0 0xFFF0A000 0 0x1000>,
> > <0x0 0xFFF31000 0 0x1000>,
> > <0x0 0xE86C 0 0x1>;
> > #endif
> > //reg = <0x0 0x10004000 0x0 0x8>,
> > reg = <0x0 0x10004000 0x0 0x8>,
> ><0x0 0x10084000 0 0x1000>,
> ><0x0 0x10085000 0 0x1000>,
> ><0x0 0x10086000 0 0x1000>,
> ><0x0 0x100C4000 0 0x1>;
> > // <0x0 0x10087000 0 0x1>;
> >
> > interrupts = <0 245 4>;
> >
> > clocks = <_xen HI3660_ACLK_GATE_DSS>,
> > <_xen HI3660_PCLK_GATE_DSS>,
> > <_xen HI3660_CLK_GATE_EDC0>,
> > <_xen HI3660_CLK_GATE_LDI0>,
> > <_xen HI3660_CLK_GATE_LDI1>,
> > <_xen HI3660_CLK_GATE_DSS_AXI_MM>,
> > <_xen HI3660_PCLK_GATE_MMBUF>;
> > clock-names = "aclk_dss",
> > "pclk_dss",
> > "clk_edc0",
> > "clk_ldi0",
> > "clk_ldi1",
> > "clk_dss_axi_mm",
> > "pclk_mmbuf";
> >
> > dma-coherent;
> >
> > port {
> > dpe_out: endpoint {
> > remote-endpoint = <_in>;
> > };
> > };
> > };
> >
> > dsi: dsi@10097000 {
> > compatible = "hisilicon,hi3660-dsi";
> > status = "ok";
> > #if 0
> > //ACTUAL REG PROPERTY of DISPLAY
> > reg = <0 0xE8601000 0 0x7F000>,
> > <0 0xFFF35000 0 0x1000>;
> > #endif
> > //reg = <0 0x10097000 0 0x7F000>,
> > //<0 0x10116000 0 0x1000>;
> > reg = <0 0x10004000 0 0x8>,
> > <0 0x10084000 0 0x1000>;
> >
> > clocks = <_xen HI3660_CLK_GATE_TXDPHY0_REF>,
> > <_xen HI3660_CLK_GATE_TXDPHY1_REF>,
> > <_xen HI3660_CLK_GATE_TXDPHY0_CFG>,
> > <_xen HI3660_CLK_GATE_TXDPHY1_CFG>,
> > <_xen HI3660_PCLK_GATE_DSI0>,
> > <_xen HI3660_PCLK_GATE_DSI1>;
> > clock-names = "clk_txdphy0_ref",
> > "clk_txdphy1_ref",
> > "clk_txdphy0_cfg",
> > "clk_txdphy1_cfg",
> > "pclk_dsi0",
> > "pclk_dsi1";
> >
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > };
> > #endif
> > clocks {
> > compatible = "simple-bus";
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> > clk_xen: xen_clk@0 {
> > compatible = "xen,xen-vclk";
> > #clock-cells = <1>;
> > };
> > };
> >
>
> > Below is my 'debian.cfg' file:
> >
>
> > kernel = "/debian/Image"
> > device_tree="/debian/domu.dtb"
> > memory = 512
> > vcpus = 8
> > cpus = "all"
> > name="debian"
> >
> > # DPE
> > #iomem = [ "0xE8600,0x80@0x10004", "0xFFF35,1@0x10084",
> > "0xFFF0A,1@0x10085", "0xFFF31,1@0x10086", "0xE86C0,10@0x10087"]
> > #iomem = [ "0xE8600,0x80", "0xFFF35,1", "0xFFF0A,1", "0xFFF31,1",
> > "0xE86C0,10"]
> > irqs = [ 277 ]
> >
> > iomem = [ "0xE8600,80@0x10004" ]
> >
> > iomem = [ "0xFFF35,1@0x10084" ]
> > iomem = [ "0xFFF0A,1@0x10085" ]
> > iomem = [ "0xFFF31,1@0x10086" ]
> > iomem = [ "0xE86C0,10@0x100C4"]
> > #iomem = [ "0xE86C0,10@0x10087"]
> > #iomem = [ "0xE8600,80@0x0" ]
> >
> > # DPE
> > # DSI
> > #iomem = [ "0xE8601,0x7F", "0xFFF35,1"]
> > #iomem = [
Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains
in_drm_mode_config_init(): 91: [4.212547] [DISPLAY] dss_drm_init(): 638: [4.212563] [drm] +. [4.212585] [DISPLAY] dss_dts_parse(): 513: [4.212603] [DISPLAY] dss_dts_parse(): 530: of device: /passthrough/dpe@10004000 [4.212635] [DISPLAY] dss_dts_parse(): 531: [4.212661] [DISPLAY] dss_dts_parse(): 532: ctx->base: ff800bd0 [4.212688] Unhandled fault: ttbr address size fault (0x9600) at 0xff800bd01000 [4.212708] Mem abort info: [4.212720] Exception class = DABT (current EL), IL = 32 bits [4.212738] SET = 0, FnV = 0 [4.212751] EA = 0, S1PTW = 0 [4.212763] Data abort info: [4.212776] ISV = 0, ISS = 0x [4.212789] CM = 0, WnR = 0 [4.212806] Internal error: : 9600 [#1] PREEMPT SMP [4.212821] Modules linked in: [4.212839] CPU: 7 PID: 99 Comm: kworker/7:1 Tainted: G S 4.14.0-rc7 #456 [4.212857] Hardware name: XENVM-4.8 (DT) [4.212878] Workqueue: events deferred_probe_work_func [4.212893] task: ffc01abe6000 task.stack: ff8009878000 [4.212916] PC is at dss_drm_init+0x1a8/0x680 [4.212931] LR is at dss_drm_init+0x1a0/0x680 [4.212945] pc : [] lr : [] pstate: 4045 [4.212963] sp : ff800987ba20 [4.212973] x29: ff800987ba30 x28: ffc01bff42e8 [4.212990] x27: ff800bd01000 x26: ffc018d25760 [4.213006] x25: ff80090f8c70 x24: ffc017212800 [4.213023] x23: ff8008e32000 x22: ff80090f8000 [4.213039] x21: ff8008e32748 x20: ffc018d25018 [4.213055] x19: ffc01abdf810 x18: 0010 [4.213071] x17: 000e x16: 0020 [4.213087] x15: x14: ff80894c6157 [4.213104] x13: ff80094c6165 x12: ff8009379000 [4.213120] x11: 05f5e0ff x10: ff800987b6f0 [4.257555] x9 : ffd0 x8 : 004b [4.257573] x7 : 000c x6 : 01ee [4.257591] x5 : 7ceb x4 : [4.257608] x3 : ff800934a000 x2 : [4.257625] x1 : x0 : 003b [4.257644] Process kworker/7:1 (pid: 99, stack limit = 0xff8009878000) [4.257661] Call trace: [4.257672] Exception stack(0xff800987b8e0 to 0xff800987ba20) [4.257691] b8e0: 003b ff800934a000 [4.257713] b900: 7ceb 01ee 000c [4.257734] b920: 004b ffd0 ff800987b6f0 05f5e0ff [4.257756] b940: ff8009379000 ff80094c6165 ff80894c6157 [4.25] b960: 0020 000e 0010 ffc01abdf810 [4.257799] b980: ffc018d25018 ff8008e32748 ff80090f8000 ff8008e32000 [4.257821] b9a0: ffc017212800 ff80090f8c70 ffc018d25760 ff800bd01000 [4.257842] b9c0: ffc01bff42e8 ff800987ba30 ff80087061c8 ff800987ba20 [4.257864] b9e0: ff80087061d0 4045 0214 ff800bd0 [4.257885] ba00: 7c9f ff800987ba30 ff80087061d0 [4.257908] [] dss_drm_init+0x1a8/0x680 [4.257926] [] kirin_drm_bind+0x128/0x310 [4.257945] [] try_to_bring_up_master+0x180/0x1e0 [4.257965] [] component_add+0xa4/0x170 [4.257981] [] dsi_probe+0x52c/0x5a0 [4.258000] [] platform_drv_probe+0x60/0xc0 [4.258018] [] driver_probe_device+0x234/0x2e0 [4.258037] [] __device_attach_driver+0xa0/0xe8 [4.258056] [] bus_for_each_drv+0x58/0xa8 [4.258072] [] __device_attach+0xc8/0x138 [4.302470] [] device_initial_probe+0x24/0x30 [4.302490] [] bus_probe_device+0x9c/0xa8 [4.302506] [] deferred_probe_work_func+0xac/0x150 [4.302528] [] process_one_work+0x1d8/0x490 [4.302547] [] worker_thread+0x248/0x478 [4.302565] [] kthread+0x138/0x140 [4.302584] [] ret_from_fork+0x10/0x1c [4.302601] Code: f90037a4 97e8a1ea f943a69b 9140077b (b940037b) [4.302621] ---[ end trace d64c23a811313502 ]--- [4.302638] Kernel panic - not syncing: Fatal exception [4.302656] SMP: stopping secondary CPUs [4.332694] Kernel Offset: disabled [4.332708] CPU features: 0x002004 [4.332720] Memory Limit: none [4.332736] Rebooting in 5 seconds.. How to fix this IO addr size fault, I think some problem in dts or debian.cfg to map Physical addresses to GFNs Please help me to come out of this problem. Thanks Omkar B On Thu, Nov 1, 2018 at 1:11 AM Julien Grall wrote: > > > On 10/17/18 1:24 PM, Omkar Bolla wrote: > > Hi, > > Hi Omkar, > > > I have started finding which patch introduced Armv8 Secondary CPUs issue. > > > > I just want to start PV vdevb before domainU debian rootfs mount.
Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains
Hi, I have started finding which patch introduced Armv8 Secondary CPUs issue. I just want to start PV vdevb before domainU debian rootfs mount. Is it possible? Thanks, Omkar B On Mon, Oct 8, 2018 at 4:00 PM Julien Grall wrote: > > > On 08/10/2018 10:12, Omkar Bolla wrote: > > Hi, > > Hi, > > > This is also okay, but problem here is I am using 4.8 stable xen > > because it is working on Hkey960(ArmV8) > > This is because you can't bring up secondary CPUs on the Hikey with Xen > 4.11 [1], right? It would be nice to find where the bug was introduced > because Xen 4.8 is out of support and does not contain the latest fixes > (such as Meltdown/Spectre). > > > Is there any other way to share buffer dynamically? > You would have to write your own PV drivers or port the series to Xen 4.8. > > Cheers, > > [1] > https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg21576.html > > -- > Julien Grall > -- This message contains confidential information and is intended only for the individual(s) named. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this mail and attached file/s is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains
Hi, Sorry for late response, On Wed, Oct 3, 2018 at 3:23 PM Julien Grall wrote: > > > On 10/02/2018 11:03 AM, Omkar Bolla wrote: > > Hi, > > > > Thanks, > > Basic state change is working now, after using above script. > > > > As I said, I want to share buffer between two domains. > > Could you please suggest outlines, how can I share buffer between 2 > > domains(Guest and Host)? > > My question on a previous e-mail was left unanswered. Do you have > requirements to share the buffer dynamically? > > Yes, I want to share buffer dynamically but not more than 1024 bytes. > If not, you may want to have a look at "Allow setting up shared memory > areas between VMs from xl config files" [2]. We aim to merge it in the > next Xen release. > > Cheers, > > [2] https://lists.xen.org/archives/html/xen-devel/2018-08/msg00883.html > > This is also okay, but problem here is I am using 4.8 stable xen because it is working on Hkey960(ArmV8) Is there any other way to share buffer dynamically? > This message contains confidential information and is intended only for > > the individual(s) named.If you are not the intended recipient, you are > > notified that disclosing, copying, distributing or taking any action in > > reliance on the contents of this mail and attached file/s is strictly > > prohibited. Please notify the sender immediately and delete this e-mail > > from your system. E-mail transmission cannot be guaranteed to be secured > > or error-free as information could be intercepted, corrupted, lost, > > destroyed, arrive late or incomplete, or contain viruses. The sender > > therefore does not accept liability for any errors or omissions in the > > contents of this message, which arise as a result of e-mail transmission. > > > > Please configure your client to remove your disclaimer company. > I am looking into settings, to remove disclaimer. > > Cheers, > > -- > Julien Grall > Thanks, Omkar B -- This message contains confidential information and is intended only for the individual(s) named. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this mail and attached file/s is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains
Hi, Thanks, Basic state change is working now, after using above script. As I said, I want to share buffer between two domains. Could you please suggest outlines, how can I share buffer between 2 domains(Guest and Host)? Thanks, Omkar B On Fri, Sep 28, 2018 at 7:12 PM Juergen Gross wrote: > On 28/09/2018 14:55, Omkar Bolla wrote: > > Hi, > > I tried to run script after pause the domain and unpause domain after > > run script. But I ended up with same error > > I looked at the script again, it is wrong. The permissions should > be set for each node under the root path of the respective domains, > the first permission should be "n$domid" ($domid is the owner who > can always read/write, the n is "no access" for all domains not > explicitly listed), the second permission should be "r$domid" as > the other side should be able to read only. > > In order to do it correctly the script should be: > > #!/bin/bash > > DOMU_ID=$1 > > if [ -z "$DOMU_ID" ]; then > echo "Usage: $0 [domU ID]]" > echo > echo "Connects the new device, with dom0 as backend, domU as frontend" > exit 1 > fi > > # Pause domU as a script can't write an entry and set permission > # in a single operation. > xl pause $DOMU_ID > > DEVICE=mydevice > DOMU_KEY=/local/domain/$DOMU_ID/device/$DEVICE/0 > DOM0_KEY=/local/domain/0/backend/$DEVICE/$DOMU_ID/0 > > # Tell the domU about the new device and its backend > xenstore-write $DOMU_KEY/backend-id 0 > xenstore-write $DOMU_KEY/backend > "/local/domain/0/backend/$DEVICE/$DOMU_ID/0" > > # Tell the dom0 about the new device and its frontend > xenstore-write $DOM0_KEY/frontend-id $DOMU_ID > xenstore-write $DOM0_KEY/frontend "/local/domain/$DOMU_ID/device/$DEVICE/0" > > # Activate the device, dom0 needs to be activated last > xenstore-write $DOMU_KEY/state 1 > xenstore-write $DOM0_KEY/state 1 > > # Make sure the domU can read the dom0 data > xenstore-chmod -r $DOM0_KEY n0 r$DOMU_ID > xenstore-chmod -r $DOMU_KEY n$DOMU_ID r0 > > xl unpause $DOMU_ID > > > Juergen > -- This message contains confidential information and is intended only for the individual(s) named. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this mail and attached file/s is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains
Hi,
I tried to run script after pause the domain and unpause domain after run
script. But I ended up with same error
Below I shared PV device log, and attached my FE and BE driver and script
that i used,
root@hikey960:/debian#
[XEN_BUF]xen_vdevb_be_probe(): 124: Probe called. We are good to go.
[ 165.087419] [XEN_BUF]xen_vdevb_be_probe(): 125: ffc017fb7000 1
[ 165.093759] [XEN_BUF]xen_vdevb_be_probe(): 137: info->domid: 1
[ 165.099641] [XEN_BUF]xen_vdevb_be_probe(): 138: devicetype: vdevb,
nodename: backend/vdevb/1/0, otherend: /local/domain/1/device/vdevb/0
[ 165.112939] [XEN_BUF]xen_vdevb_be_frontend_changed(): 177: dev->state:
XenbusStateInitialising-1, frontend_state: XenbusStateInitialising-1
root@hikey960:/debian#
root@hikey960:/debian#
root@hikey960:/debian#
root@hikey960:/debian#
root@hikey960:/debian# xl console debian
[ 22.243570] [XEN_BUF]xen_vdevb_fe_probe(): 24: Probe called. We are good
to go.
[ 22.243606] [XEN_BUF]xen_vdevb_fe_probe(): 25: ffc0160b4000 0
[ 22.243620] [XEN_BUF]xen_vdevb_fe_probe(): 38: info->domid: 0
[ 22.243633] [XEN_BUF]xen_vdevb_fe_probe(): 39: devicetype: vdevb,
nodename: device/vdevb/0, otherend: /local/domain/0/backend/vdevb/1/0
[ 22.244669] [XEN_BUF]xen_vdevb_fe_backend_changed(): 64: dev->state:
XenbusStateInitialising-1, backend_state: XenbusStateInitWait-2
[ 22.244701] [XEN_BUF]frontend_connect(): 53: Connecting the frontend now
[ 22.245866] vdevb vdevb-0: 13 writing new state
[ 22.246085] vdevb vdevb-0: failed to write error node for device/vdevb/0
(13 writing new state)
[ 22.250005] vdevb vdevb-0: 13 writing new state
[ 22.250220] vdevb vdevb-0: failed to write error node for device/vdevb/0
(13 writing new state)
root@hikey960:~#
Thanks,
Omkar B
On Thu, Sep 27, 2018 at 4:33 PM Juergen Gross wrote:
> On 27/09/2018 12:35, Omkar Bolla wrote:
> > Hi,
> >
> > Sorry, I forgot, I used code from github chapter [2] from that link, and
> > I just changed name "mydevice" to "vdevb"
>
> Okay.
>
> >
> >> Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
> >> are not sufficient to write the needed entries.
> > Where I have to provide access rights, i.e from Kernel code or from from
> > command line in domain-0 or modify in xen source?
>
> I guess you have your frontend already loaded when running the
> script creating the Xenstore entries?
>
> This would explain the problem: as soon as the entries are written
> the frontend will react. At this point the access rights are not setup
> properly, this is done a little bit later in the script.
>
> Possible solutions are to either load the frontend driver only after
> setting up the Xenstore entries, or to pause the domain while doing
> so and unpause it afterwards (or start the domain paused, create the
> Xenstore entries, and unpause the domain).
>
> The really correct way to do it would be to setup Xenstore in a single
> transaction (write all the entries and set access rights).
>
> > Any thing that I have to do/change in xenbits xen-4.8 sources code, to
> > add new PV device?
>
> Only if you want to include domain config file entries for your device.
>
> >
> >> Did you modify Xen tools (xl/libxl) for adding the new device type?
> > No, is it needed to modify some thing in xl/libxl for adding new device
> > type?
>
> This was just a question to learn how Xenstore is being initialized
> in your scenario.
>
> >
> >> If not you need to setup the Xenstore nodes manually.
> > Setup manually Xenstore means, using commands?
>
> Yes, like your script does.
>
>
> Juergen
>
--
This
message contains confidential information and is intended only
for the
individual(s) named. If you are not the intended
recipient, you are
notified that disclosing, copying, distributing or taking any
action in
reliance on the contents of this mail and attached file/s is strictly
prohibited. Please notify the
sender immediately and delete this e-mail
from your system. E-mail transmission
cannot be guaranteed to be secured or
error-free as information could be
intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain
viruses. The sender therefore does
not accept liability for any errors or
omissions in the contents of this
message, which arise as a result of e-mail
transmission.
#include /* Needed by all modules */
#include /* Needed for KERN_ALERT */
#include/* We are doing something with Xen */
#include
#include "xen_buf.h"
struct vdevbfrnt_info {
struct xenbus_device *dev;
unsigned int evtchn;
unsigned int irq;
grant_ref_t ring_ref;
};
// The function is called on activation of the device
static int xen_vdevb_fe_probe(struct xenbus_device *dev,
const struct
Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains
Hi,
Sorry, I forgot, I used code from github chapter [2] from that link, and
I just changed name "mydevice" to "vdevb"
> Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
> are not sufficient to write the needed entries.
Where I have to provide access rights, i.e from Kernel code or from from
command line in domain-0 or modify in xen source?
Any thing that I have to do/change in xenbits xen-4.8 sources code, to add
new PV device?
> Did you modify Xen tools (xl/libxl) for adding the new device type?
No, is it needed to modify some thing in xl/libxl for adding new device
type?
> If not you need to setup the Xenstore nodes manually.
Setup manually Xenstore means, using commands?
Thanks,
Omkar B
On Thu, Sep 27, 2018 at 3:50 PM Oleksandr Andrushchenko <
oleksandr_andrushche...@epam.com> wrote:
> On 09/27/2018 01:16 PM, Juergen Gross wrote:
> > On 27/09/2018 12:07, Oleksandr Andrushchenko wrote:
> >> Hi,
> >> On 09/27/2018 12:39 PM, Lars Kurth wrote:
> >>> Adding a few people who have recently been working on PV drivers, as
> >>> well as Julien
> >>> Lars
> >>>
> >>>> On 27 Sep 2018, at 06:44, Omkar Bolla
> >>>> >>>> <mailto:omkar.bo...@pathpartnertech.com>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I am using Debian as Domain-0 and Debian as Domain-U on Hikey960
> >>>> platform(ARMv8) and using Xen-4.8 stable release. Here I want to
> >>>> create a PV frontend and backend to share memory between Domain-0 and
> >>>> Domain-U.
> >>>>
> >>>>
> >>>>
> >>>> I used below link to create frontend and backend,
> >>>> https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/
> >> The link above has another link to github [1] with 2 chapters. And it
> >> looks like you have
> >> already modified the sources ("mydevice" -> "vdevb" at least).
> >> So, what are the sources you are using?
> >>
> >> You could probably take a look at the relatively small vkbd frontend
> >> driver [2]
> >> to get some hints.
> >>>> But I am facing below errors while adding device vdevb to xenstore.
> >>>> Below errors I am getting from xenbus_switch_state().
> >>>> vdevb vdevb-0: failed to write error node for device/vdevb/0 (13
> >>>> writing new state)
> > Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
> > are not sufficient to write the needed entries.
> >
> > Did you modify Xen tools (xl/libxl) for adding the new device type?
> > If not you need to setup the Xenstore nodes manually.
> There is a script [1] which comes with the example implementation,
> so I believe Omkar uses it with "mydevice" -> "vdevb" change
> >
> >
> > Juergen
> [1]
>
> https://github.com/badboy/xen-split-driver-example/blob/master/chapter02/activate.sh
>
--
This
message contains confidential information and is intended only
for the
individual(s) named. If you are not the intended
recipient, you are
notified that disclosing, copying, distributing or taking any
action in
reliance on the contents of this mail and attached file/s is strictly
prohibited. Please notify the
sender immediately and delete this e-mail
from your system. E-mail transmission
cannot be guaranteed to be secured or
error-free as information could be
intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain
viruses. The sender therefore does
not accept liability for any errors or
omissions in the contents of this
message, which arise as a result of e-mail
transmission.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains
Hi, I am using Debian as Domain-0 and Debian as Domain-U on Hikey960 platform(ARMv8) and using Xen-4.8 stable release. Here I want to create a PV frontend and backend to share memory between Domain-0 and Domain-U. I used below link to create frontend and backend, https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/ But I am facing below errors while adding device vdevb to xenstore. Below errors I am getting from xenbus_switch_state(). vdevb vdevb-0: failed to write error node for device/vdevb/0 (13 writing new state) Please suggest me, How to create PV drivers. Thanks, Omkar B -- This message contains confidential information and is intended only for the individual(s) named. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this mail and attached file/s is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Armv8-A: Not able to enable secondary CPUs in Hikey960 board
] Build-time adjustment of leaf fanout to 64. [0.00] RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=1. [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=1 [0.00] NR_IRQS:64 nr_irqs:64 0 [0.00] arm_arch_timer: Architected cp15 timer(s) running at 1.92MHz (virt). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x1c570327e, max_idle_ns: 1763180809505 ns [0.05] sched_clock: 56 bits at 1920kHz, resolution 520ns, wraps every 4398046510977ns [0.000105] clocksource: arm,sp804: mask: 0x max_cycles: 0x, max_idle_ns: 58334160866034 ns [0.000699] Console: colour dummy device 80x25 [0.001190] console [tty0] enabled [0.341427] console [hvc0] enabled [0.344935] Calibrating delay loop (skipped), value calculated using timer frequency.. 3.84 BogoMIPS (lpj=7680) [0.355049] pid_max: default: 32768 minimum: 301 [0.359845] Security Framework initialized [0.363910] SELinux: Initializing. [0.367538] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes) [0.374225] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes) [0.382219] ftrace: allocating 44464 entries in 174 pages [0.479344] sched-energy: CPU device node has no sched-energy-costs [0.485645] Invalid sched_group_energy for CPU0 [0.490181] CPU0: update cpu_capacity 1024 [0.494355] ASID allocator initialised with 32768 entries [0.500803] xen:grant_table: Grant tables using version 1 layout [0.506746] Grant table initialized [0.510310] xen:events: Using FIFO-based ABI [0.514720] Xen: initializing cpu0 [0.547593] EFI services will not be available. [0.560149] Brought up 1 CPUs [0.563030] SMP: Total of 1 processors activated. [0.567826] CPU features: detected feature: 32-bit EL0 Support [0.573708] CPU features: detected feature: Kernel page table isolation (KPTI) [0.586209] CPU: All CPU(s) started at EL1 [0.590234] alternatives: patching kernel code [0.594924] Invalid sched_group_energy for CPU0 [0.599376] CPU0: update max cpu_capacity 1024 [0.603878] Invalid sched_group_energy for Cluster0 [0.610428] devtmpfs: initialized Thanks, Omkar B On Wed, Aug 15, 2018 at 11:52 PM, Julien Grall wrote: > On 08/15/2018 10:15 AM, Omkar Bolla wrote: > >> HI Julien, >> > > Hello, > > As you suggested, I enabled early printk for hikey960 in xen-4.8 stable >> branch and xen-4.11 stable branch. >> > > Looking at the logs, Xen is placed differently in the memory: > - Xen 4.8: 0x1aa0 > - Xen 4.11: 0x00021fe0 > > With Xen 4.11, the binary will be placed above 4GB. There was some change > in the way to place Xen in the memory in 2016 allowing to place Xen at the > end of the usable RAM. > > I suspect the firmware does not support 64-bit address entry point for > secondary CPU. This would explain the ADDRESS_INVALID from PSCI CPU UP > call. Can you give a try to this patch: > > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 7d40a8466b..13318da6b1 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -408,13 +408,11 @@ static paddr_t __init get_xen_paddr(void) > if ( !e ) > continue; > > -#ifdef CONFIG_ARM_32 > /* Xen must be under 4GB */ > if ( e > 0x1ULL ) > e = 0x1ULL; > if ( e < bank->start ) > continue; > -#endif > > s = e - min_size; > > > Cheers, > > -- > Julien Grall > -- This message contains confidential information and is intended only for the individual(s) named. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this mail and attached file/s is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Armv8-A: Not able to enable secondary CPUs in Hikey960 board
#6 SMP PREEMPT Wed A ug 15 11:55:00 IST 2018 [0.00] Boot CPU: AArch64 Processor [410fd034] [0.00] Xen 4.11 support found [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: UEFI not found. [0.00] Ion: base 0xde20, size is 0x1e0, node name graphic, heap-name carveout_gralloc namesize 17,[99][97][114][118] [0.00] Ion: insert heap-name carveout_gralloc [0.00] OF: reserved mem: initialized node graphic, compatible id hisi_ion [0.00] Reserved memory: created CMA memory pool at 0x16c0, size 64 MiB [0.00] OF: reserved mem: initialized node fastboot-cma-mem, compatible id shared-dma-pool [0.00] cma: Reserved 64 MiB at 0xda00 [0.00] psci: probing for conduit method from DT. [0.00] psci: PSCIv1.1 detected in firmware. [0.00] psci: Using standard PSCI v0.2 function IDs [0.00] psci: Trusted OS migration not required [0.00] psci: SMC Calling Convention v1.1 [0.00] percpu: Embedded 23 pages/cpu @ffc01e18b000 s54936 r8192 d31080 u94208 [0.00] Detected VIPT I-cache on CPU0 [0.00] CPU features: enabling workaround for ARM erratum 845719 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129024 [0.00] Kernel command line: console=tty0 console=hvc0 root=/dev/sdd10 rw efi=noruntime [0.00] PID hash table entries: 2048 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) -- In above logs, I marked CMA memory area reserving, which is giving errors while initialising cma pools in linux when i am using xen-4.8 Could you please tell me, what could be the problem? I hope it belongs to CMA memory address part in DTS, please correct me if i were wrong. Thank you, Omkar B On Mon, Aug 13, 2018 at 8:40 PM, Julien Grall wrote: > Hello, > > On 13/08/18 14:01, Konrad Rzeszutek Wilk wrote: > >> On Mon, Aug 13, 2018 at 11:16:14AM +0530, Omkar Bolla wrote: >> >>> Please check below log: >>>>> >>>>> Using modules provided by bootloader in FDT >>>>> Xen 4.11.1-pre (c/s Mon Jul 30 11:30:09 2018 +0200 git:33ced72) EFI >>>>> >>>> loader >>>> >>>>> Xen 4.11.1-pre >>>>> (XEN) Xen version 4.11.1-pre (omkar.bolla@) (aarch64-linux-gnu-gcc >>>>> >>>> (Linaro >>>> >>>>> GCC 7.1-2017.05) 7.1.1 20170510) debug=n Sat Aug 11 20:35:10 IST 201 >>>>> 8 >>>>> (XEN) Latest ChangeSet: Mon Jul 30 11:30:09 2018 +0200 git:33ced72 >>>>> (XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev >>>>> >>>> 0x4 >>>> >>>>> (XEN) 64-bit Execution: >>>>> (XEN) Processor Features: >>>>> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 >>>>> (XEN) Extensions: FloatingPoint AdvancedSIMD >>>>> (XEN) Debug Features: 10305106 >>>>> (XEN) Auxiliary Features: >>>>> (XEN) Memory Model Features: 1122 >>>>> (XEN) ISA Features: 00011120 >>>>> (XEN) 32-bit Execution: >>>>> (XEN) Processor Features: 0131:00011011 >>>>> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle >>>>> (XEN) Extensions: GenericTimer Security >>>>> (XEN) Debug Features: 03010066 >>>>> (XEN) Auxiliary Features: >>>>> (XEN) Memory Model Features: 10201105 4000 0126 02102211 >>>>> (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 >>>>> >>>> 00011121 >>>> >>>>> (XEN) Using SMC Calling Convention v1.1 >>>>> (XEN) Using PSCI v1.1 >>>>> (XEN) SMP: Allowing 8 CPUs >>>>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 1920 KHz >>>>> (XEN) GICv2 initialization: >>>>> (XEN) gic_dist_addr=e82b1000 >>>>> (XEN) gic_cpu_addr=e82b2000 >>>>> (XEN) gic_hyp_addr=e82b4000 >>>>> (XEN) gic_vcpu_addr=e82b6000 >>>>> (XEN) gic_maintenance_irq=25 >>>>> (XEN) GICv2: 384 lines, 8 cpus, secure (IID 0200143b). >>>>> (XEN) Using s
Re: [Xen-devel] Armv8-A: Not able to enable secondary CPUs in Hikey960 board
Hi Konrad, Thank you Konrad. I tried other versions also, and Xen 4.8.5 stable branch is working properly. And i will investigate which patch causing this issue between xen-4.8 and xen-4.9 branch. Thank you, Omkar B -- This message contains confidential information and is intended only for the individual(s) named. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this mail and attached file/s is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Armv8-A: Not able to enable secondary CPUs in Hikey960 board
Hi, I am using Hikey960 board and i started trying to port xen on hykey960. I followed all procedure has given in https://wiki.xenproject.org/wiki/HiKey960 link. And using *Xen version 4.11.1-pre *and linux as mentioned in above link. But, After flashing, I ended up with secondary CPUs errors and linux Dom0 errors. Please give some suggestions to start xen with all CPUs. Please check below log: Using modules provided by bootloader in FDT Xen 4.11.1-pre (c/s Mon Jul 30 11:30:09 2018 +0200 git:33ced72) EFI loader Xen 4.11.1-pre (XEN) Xen version 4.11.1-pre (omkar.bolla@) (aarch64-linux-gnu-gcc (Linaro GCC 7.1-2017.05) 7.1.1 20170510) debug=n Sat Aug 11 20:35:10 IST 201 8 (XEN) Latest ChangeSet: Mon Jul 30 11:30:09 2018 +0200 git:33ced72 (XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4 (XEN) 64-bit Execution: (XEN) Processor Features: (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 10305106 (XEN) Auxiliary Features: (XEN) Memory Model Features: 1122 (XEN) ISA Features: 00011120 (XEN) 32-bit Execution: (XEN) Processor Features: 0131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: (XEN) Memory Model Features: 10201105 4000 0126 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Using SMC Calling Convention v1.1 (XEN) Using PSCI v1.1 (XEN) SMP: Allowing 8 CPUs (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 1920 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=e82b1000 (XEN) gic_cpu_addr=e82b2000 (XEN) gic_hyp_addr=e82b4000 (XEN) gic_vcpu_addr=e82b6000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 384 lines, 8 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 64 KiB. (XEN) Bringing up CPU1 (XEN) Failed to bring up CPU1 (XEN) Failed to bring up CPU 1 (error -9) (XEN) Bringing up CPU2 (XEN) Failed to bring up CPU2 (XEN) Failed to bring up CPU 2 (error -9) (XEN) Bringing up CPU3 (XEN) Failed to bring up CPU3 (XEN) Failed to bring up CPU 3 (error -9) (XEN) Bringing up CPU4 (XEN) Failed to bring up CPU4 (XEN) Failed to bring up CPU 4 (error -9) (XEN) Bringing up CPU5 (XEN) Failed to bring up CPU5 (XEN) Failed to bring up CPU 5 (error -9) (XEN) Bringing up CPU6 (XEN) Failed to bring up CPU6 (XEN) Failed to bring up CPU 6 (error -9) (XEN) Bringing up CPU7 (XEN) Failed to bring up CPU7 (XEN) Failed to bring up CPU 7 (error -9) (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 (XEN) I/O virtualisation disabled (XEN) build-id: fa5f17a58e5d75750920185c7944c71cbea9de1d (XEN) alternatives: Patching with alt table 400acfc8 -> 400ad544 (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ b8887000 (XEN) Allocating 1:1 mappings totalling 512MB for dom0: (XEN) BANK[0] 0x00c000-0x00e000 (512MB) (XEN) Grant table range: 0x021fe0-0x021fe4 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading zImage from b8887000 to c008-c1187200 (XEN) Loading dom0 DTB to 0xc800-0xc800a4db (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) done. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) *** (XEN) PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR NOW (XEN) *** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 292kB init memory. (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER20 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER24 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER28 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER32 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER36 (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER40 [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version
