Memory Allocation Question on Arm64 (ZYNQ Ultrascale+)
Hi all, I am using ARM64 Ultrazed board (ZYNQ Ultrascale+ serials). I want to allocate memeory in the initialization functions. I use a simplified malloc and free function from other project.I modified it a little on the start address. I use the stack_top as the beginning of first available memory address. Then I tested the malloc functions, it can return correct value according to the size we need. I can allocate memory from 0x1c000(stack_top) to 0x20. But when it reach 0x20, The system crashed without any print information. Is there any limitation about stack size? 0x20? Another question is that if I start another bare-metal inmate, does it share the same stack as the first inmate or it has its own stack also available from 0x1c000 on it own memory? Thank you in advance! -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Remapping MSI interrupts of pci-e serial card
On 23.01.19 10:31, Jan Kiszka wrote: On 23.01.19 09:12, Chung-Fan Yang wrote: Hmm, this fails when passing it to jailhouse config create. Could it be that you ran the collect job as normal user, not as root? Seems like I failed to copy it from the remote host via scp. I have attached a new version. It has been run with current working condition. I noticed that the file "might" be identical. I am already running as root, so any ideas? No idea yet. I thought your PCI config regions would have been truncated, which is a typical pattern when running as normal user, but that is not the case. I will have to debug this. Are you able to run "jailhouse config create -r config.c"? Or at least "jailhouse config create config.c" on the target machine? OK, we have a regression in the config generator, more precisely with commit 20a83313 between 0.9.1 and 0.10. That regression break config generation completely. But when using the generator of 0.9.1, I'm getting ERROR: Jailhouse was enabled when collecting input files! Disable jailhouse and try again. So there is also something not correct on your side. Jan -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Jailhouse Enable Error // VT-d fault event reported by IOMMU 0
On 23.01.19 13:02, Burak Atalay wrote:
Hello Mr. Kiszka,
Thanks for the reply. Removing that memory region from the sysconfig did not solve the
problem, however could you please elaborate on what you mean by "update indexes that
refer to entries after that one"? It is probably something obvious that I am
missing, but I did not understand where the indexes that I am supposed to update are in
the config file. I also tried removing the mem regions for the device 03:00.0 completely,
and I also removed the entries for 03:00.0 from pci_devices and pci_caps, but then I got
an error for the device 03:00.1:
Activating Hypervisor
VT-d fault event reported by IOMMU 0:
Source Identifier (bus:dev.func): 03:00.1
Fault Reason 0x22 Fault Info: 6b0 Type 0
Could you please point me towards how the mapping for mem regions is defined in
the config file?
Ok, the error moved on to the next device/function (3:00.1). And the reason
seems to be some bug in the config generator that stumbles for MSI-X regions at
locations > 4G. This causes wrong values here:
/* PCIDevice: 03:00.0 */
{
...
.msix_address = 0xffe04000,
},
/* PCIDevice: 03:00.1 */
{
...
.msix_address = 0xffe0,
},
The higher bits are missing, and the related regions are incorrectly mapped into
the guest. Let me debug that...
Which Jailhouse version are you using?
Jan
-Original Message-
From: Jan Kiszka
Sent: Sunday, January 13, 2019 3:39 AM
To: Atalay Burak 1CS2 ;
jailhouse-dev@googlegroups.com
Cc: Haase Heiko 1CS2
Subject: *EXT* Re: Jailhouse Enable Error // VT-d fault event reported by IOMMU 0
On 11.01.19 22:05, Burak Atalay wrote:
Hello everyone,
I am encountering some problems while trying to run Jailhouse.
Attached you can find the sysconfig file that was generated by “jailhouse
config create” command.
While I was cross-checking the memory regions in the sysconfig file
with the output from “cat /proc/iomem” I realized that there was a
missing memory region, so I had to manually enter the following to the
sysconfig file:
/* MemRegion: 796b9000-79887fff : Reserved APEI ERST
{
.phys_start = 0x796b9000,
.virt_start = 0x796b9000,
.size = 0x1cf000,
.flags = JAILHOUSE_MEM_READ |
JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE
| JAILHOUSE_MEM_DMA,
},
Yes, the config generator does not always catch all required regions. We could
possibly improve on that by digging deeper into what Linux reports as I/O
resources. Specifically, we would have to tell generally reserved and therefore
unused regions apart from these here which are still used.
Before this configuration, “jailhouse enable” command would crash the
machine, after this modification when I run Jailhouse I get the following error:
Activating Hypervisor
VT-d fault event reported by IOMMU 0:
Source Identifier (bus:dev.func): 03:00.0
Fault Reason 0x26 Fault Info: 490 Type 0
I studied the source code for Jailhouse, and also tried to find a
solution in the mailing list, but I was unable to do so. I am
attaching the output of the command “lspci –vvv –s 03:00.0”,
“jailhouse hardware check”, “cat /proc/iomem”, and the system
information that is collected by “tools/jailhouse config collect data.tar”.
Any suggestions are welcome.
On first glance I suspect that - for whatever reason - your system
configuration got an entry to map the I/O region of 03:00.0 in BAR 4 (at
0x383fffe04000) directly into the guest. That prevents the required
virtualization of MSI-X interrupts by Jailhouse so that the hardware correctly
detect an invalid MSI-X request and rejects it.
Try to remove that mapping from the mem_regions (but make sure to update
indexes that refer to entries after that one).
Jan
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Jailhouse demo not working on BananaPi BPI-M1
Am Wed, 23 Jan 2019 04:12:39 -0800 schrieb Dan Avram : > miercuri, 23 ianuarie 2019, 12:30:41 UTC+2, Henning Schild a scris: > > Hi Henning, > > Thank you for the quick answer. > > > you could try an image created with > > https://github.com/siemens/jailhouse-images > > There isn't provided an image for BananaPi. I will try with a qemu > image to see at least how it should behave. Indeed, i was tricked by a grep finding. > > Does the problem appear every time or just sometimes? Might be a > > race in the cpu offlining. > > The problem appears every time. I restarted the board several times > and when I run: $ jailhouse cell create > ~/jailhouse/configs/arm/bannapi-freertos-demo.cell the board freezes. In that case i would suggest trying a more recent kernel. Something in the 4.14 or 4.19 range, if available for that board. Henning -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Jailhouse demo not working on BananaPi BPI-M1
Hi Dan,
you could try an image created with
https://github.com/siemens/jailhouse-images
That will give you a reference image that is well tested and might not
have the issue you ran into.
Does the problem appear every time or just sometimes? Might be a race
in the cpu offlining.
Henning
Am Wed, 23 Jan 2019 02:10:57 -0800
schrieb Dan Avram :
> Hello,
>
> I tried to run jailhouse on a BananaPi BPI-M1 as described on the
> Jailhouse Documentation [1]. I configured the u-boot parameters as
> described(with mem=932M vmalloc=512M), and did all the steps
> described in [1] and all is fine until I run the command
>
> $ jailhouse cell create
> ~/jailhouse/configs/arm/bannapi-freertos-demo.cell
>
> After running the command there is some logging on the screen [2] and
> the console freezes. I tried to do it all over again, but same thing
> happens.
>
>
>
> [1]
> https://github.com/siemens/jailhouse/blob/master/Documentation/setup-on-banana-pi-arm-board.md
>
> [2]
> [ 231.636652]
> [ 231.638175] ===
> [ 231.642357] [ INFO: suspicious RCU usage. ]
> [ 231.646544] 4.3.3-dirty #1 Tainted: G O
> [ 231.651503] ---
> [ 231.655685] include/trace/events/sched.h:89 suspicious
> rcu_dereference_check() usage! [ 231.663505]
> [ 231.663505] other info that might help us debug this:
> [ 231.663505]
> [ 231.671506]
> [ 231.671506] RCU used illegally from offline CPU!
> [ 231.671506] rcu_scheduler_active = 1, debug_locks = 0
> [ 231.682627] 2 locks held by swapper/1/0:
> [ 231.686547] #0: ((cpu_died).wait.lock){..}, at: []
> complete+0x24/0x54 [ 231.694462] #1: (>pi_lock){-.-.-.}, at:
> [] try_to_wake_up+0x34/0x4a0 [ 231.702193]
> [ 231.702193] stack backtrace:
> [ 231.706556] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G
> O4.3.3-dirty #1 [ 231.714116] Hardware name: Allwinner sun7i
> (A20) Family [ 231.719357] [] (unwind_backtrace) from
> [] (show_stack+0x20/0x24) [ 231.727104] []
> (show_stack) from [] (dump_stack+0x84/0xb4) [ 231.734332]
> [] (dump_stack) from []
> (lockdep_rcu_suspicious+0xd8/0x114) [ 231.742685] []
> (lockdep_rcu_suspicious) from []
> (try_to_wake_up+0x110/0x4a0) [ 231.751472] []
> (try_to_wake_up) from [] (default_wake_function+0x1c/0x20)
> [ 231.759996] [] (default_wake_function) from []
> (__wake_up_common+0x58/0x84) [ 231.768691] []
> (__wake_up_common) from [] (__wake_up_locked+0x24/0x2c)
> [ 231.776953] [] (__wake_up_locked) from []
> (complete+0x44/0x54) [ 231.784522] [] (complete) from
> [] (arch_cpu_idle_dead+0x3c/0x9c) [ 231.792265]
> [] (arch_cpu_idle_dead) from []
> (cpu_startup_entry+0x9c/0x358) [ 231.800875] []
> (cpu_startup_entry) from []
> (secondary_start_kernel+0x12c/0x14c) [ 231.809918] []
> (secondary_start_kernel) from [<4000966c>] (0x4000966c)
> [ 231.817387] CPU1: shutdown Adding virtual PCI device 00:00.0 to
> cell "FreeRTOS" Shared memory connection established: "FreeRTOS" <-->
> "Banana-Pi" Created cell "FreeRTOS" Page pool usage after cell
> creation: mem 77/16360, remap 5/131072 [ 231.839804] Created
> Jailhouse cell "FreeRTOS" root@bananapi ~ # Unhandled data read at
> 0x1c2090c(4) FATAL: unhandled trap (exception class 0x24)
> pc=0xc030c584 cpsr=0x6193 hsr=0x93840007 r0=0x4113
> r1=0x03940393 r2=0x r3=0xdf89a90c r4=0x0001 r5=0x0018
> r6=0x010c r7=0xde3a9fbc r8=0xde3a9f90 r9=0x4113
> r10=0x0001 r11=0xc087fd24 r12=0xc087fcc8 r13=0xc087fcf8
> r14=0xc05c9640 Parking CPU 0 (Cell: "Banana-Pi")
>
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jailhouse demo not working on BananaPi BPI-M1
Hello,
I tried to run jailhouse on a BananaPi BPI-M1 as described on the Jailhouse
Documentation [1].
I configured the u-boot parameters as described(with mem=932M vmalloc=512M),
and did all the steps described in [1] and all is fine until I run the command
$ jailhouse cell create ~/jailhouse/configs/arm/bannapi-freertos-demo.cell
After running the command there is some logging on the screen [2] and the
console freezes.
I tried to do it all over again, but same thing happens.
[1]
https://github.com/siemens/jailhouse/blob/master/Documentation/setup-on-banana-pi-arm-board.md
[2]
[ 231.636652]
[ 231.638175] ===
[ 231.642357] [ INFO: suspicious RCU usage. ]
[ 231.646544] 4.3.3-dirty #1 Tainted: G O
[ 231.651503] ---
[ 231.655685] include/trace/events/sched.h:89 suspicious
rcu_dereference_check() usage!
[ 231.663505]
[ 231.663505] other info that might help us debug this:
[ 231.663505]
[ 231.671506]
[ 231.671506] RCU used illegally from offline CPU!
[ 231.671506] rcu_scheduler_active = 1, debug_locks = 0
[ 231.682627] 2 locks held by swapper/1/0:
[ 231.686547] #0: ((cpu_died).wait.lock){..}, at: []
complete+0x24/0x54
[ 231.694462] #1: (>pi_lock){-.-.-.}, at: []
try_to_wake_up+0x34/0x4a0
[ 231.702193]
[ 231.702193] stack backtrace:
[ 231.706556] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G O
4.3.3-dirty #1
[ 231.714116] Hardware name: Allwinner sun7i (A20) Family
[ 231.719357] [] (unwind_backtrace) from []
(show_stack+0x20/0x24)
[ 231.727104] [] (show_stack) from []
(dump_stack+0x84/0xb4)
[ 231.734332] [] (dump_stack) from []
(lockdep_rcu_suspicious+0xd8/0x114)
[ 231.742685] [] (lockdep_rcu_suspicious) from []
(try_to_wake_up+0x110/0x4a0)
[ 231.751472] [] (try_to_wake_up) from []
(default_wake_function+0x1c/0x20)
[ 231.759996] [] (default_wake_function) from []
(__wake_up_common+0x58/0x84)
[ 231.768691] [] (__wake_up_common) from []
(__wake_up_locked+0x24/0x2c)
[ 231.776953] [] (__wake_up_locked) from []
(complete+0x44/0x54)
[ 231.784522] [] (complete) from []
(arch_cpu_idle_dead+0x3c/0x9c)
[ 231.792265] [] (arch_cpu_idle_dead) from []
(cpu_startup_entry+0x9c/0x358)
[ 231.800875] [] (cpu_startup_entry) from []
(secondary_start_kernel+0x12c/0x14c)
[ 231.809918] [] (secondary_start_kernel) from [<4000966c>]
(0x4000966c)
[ 231.817387] CPU1: shutdown
Adding virtual PCI device 00:00.0 to cell "FreeRTOS"
Shared memory connection established: "FreeRTOS" <--> "Banana-Pi"
Created cell "FreeRTOS"
Page pool usage after cell creation: mem 77/16360, remap 5/131072
[ 231.839804] Created Jailhouse cell "FreeRTOS"
root@bananapi ~ # Unhandled data read at 0x1c2090c(4)
FATAL: unhandled trap (exception class 0x24)
pc=0xc030c584 cpsr=0x6193 hsr=0x93840007
r0=0x4113 r1=0x03940393 r2=0x r3=0xdf89a90c
r4=0x0001 r5=0x0018 r6=0x010c r7=0xde3a9fbc
r8=0xde3a9f90 r9=0x4113 r10=0x0001 r11=0xc087fd24
r12=0xc087fcc8 r13=0xc087fcf8 r14=0xc05c9640
Parking CPU 0 (Cell: "Banana-Pi")
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Remapping MSI interrupts of pci-e serial card
On 23.01.19 09:12, Chung-Fan Yang wrote: Hmm, this fails when passing it to jailhouse config create. Could it be that you ran the collect job as normal user, not as root? Seems like I failed to copy it from the remote host via scp. I have attached a new version. It has been run with current working condition. I noticed that the file "might" be identical. I am already running as root, so any ideas? No idea yet. I thought your PCI config regions would have been truncated, which is a typical pattern when running as normal user, but that is not the case. I will have to debug this. Are you able to run "jailhouse config create -r config.c"? Or at least "jailhouse config create config.c" on the target machine? Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Remapping MSI interrupts of pci-e serial card
On 23.01.19 09:10, Chung-Fan Yang wrote: Hmm, this fails when passing it to jailhouse config create. Could it be that you ran the collect job as normal user, not as root? Seems like I failed to copy it from the remote host via scp. I have attached a new version. It has been run with current working condition. I ran into more problem. This card have BAR1 32bit presenting a MMIO address for its 16550 registers. Mapping and accessing it in the Linux driver is OK. However, the whole page is presented as 0xff and writing has no effect in a custom RTOS cell. I passed this device into a custom RTOS cell by adding PCI device, PCI caps, and memory regions in the config file. My code had mapped the BAR1 physical address 1:1 to virtual space. Have I done anything wrong? You possibly lack some logic in your RTOS code to properly enable the PCI device, like Henning mentioned. You can always validate that by booting a Linux in the non-root cell - it comes with all the needed logic. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Remapping MSI interrupts of pci-e serial card
> > Hmm, this fails when passing it to jailhouse config create. Could it be > > that you > > ran the collect job as normal user, not as root? > > Seems like I failed to copy it from the remote host via scp. > I have attached a new version. > It has been run with current working condition. I noticed that the file "might" be identical. I am already running as root, so any ideas? -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
