Re: Share memory among cells on arm64

[Giovani Gracioli]

Hello,

Thank you for the answers.

My comments are below.

1) The root config is defined as follows (copied only the relevant parts):

.platform_info = {
.pci_mmconfig_base = 0xfc00,
.pci_mmconfig_end_bus = 0,
.pci_is_virtual = 1,
.arm = {
.gic_version = 2,
.gicd_base = 0xf901,
.gicc_base = 0xf902f000,
.gich_base = 0xf904,
.gicv_base = 0xf906f000,
.maintenance_irq = 25,
},
},

.mem_regions = {
/* MMIO (permissive) */ {
.phys_start = 0xfd00,
.virt_start = 0xfd00,
.size =   0x0300,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
/* RAM */ {
.phys_start = 0x0,
.virt_start = 0x0,
.size = 0x8000,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE,
},
/* RAM */ {
.phys_start = 0x80060,
.virt_start = 0x80060,
.size = 0x7fa0,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE,
},
/* IVSHMEM shared memory region for 00:00.0 */ {
.phys_start = 0x80040,
.virt_start = 0x80040,
.size = 0x10,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | 
JAILHOUSE_MEM_ROOTSHARED,
},
/* IVSHMEM shared memory region for 00:01.0 */ {
.phys_start = 0x80050,
.virt_start = 0x80050,
.size = 0x10,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | 
JAILHOUSE_MEM_ROOTSHARED,
},
},


.pci_devices = {
/* 00:00.0 */ {
.type = JAILHOUSE_PCI_TYPE_IVSHMEM,
.bdf = 0 << 3,
.bar_mask = {
0xff00, 0x, 0x,
0x, 0x, 0x,
},
.shmem_region = 3,
.shmem_protocol = JAILHOUSE_SHMEM_PROTO_UNDEFINED, 
.num_msix_vectors = 0, 
.domain = 0x,
},
/* 00:01.0 */ {
.type = JAILHOUSE_PCI_TYPE_IVSHMEM,
.bdf = 1 << 3,
.bar_mask = {
0xff00, 0x, 0x,
0x, 0x, 0x,
},
.shmem_region = 4,
.shmem_protocol = JAILHOUSE_SHMEM_PROTO_UNDEFINED,
.num_msix_vectors = 0,
.domain = 0x,
},
},

For the other inmate cell, the config is defined as follows:

.mem_regions = {
/* UART */ {
.phys_start = 0xff01,
.virt_start = 0xff01,
.size = 0x1000,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO | JAILHOUSE_MEM_ROOTSHARED,
},
/* RAM */ {
.phys_start = 0x80060,
.virt_start = 0,
.size = 0x0001,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_LOADABLE,
},
/* IVSHMEM shared memory region for 00:00.0 */ {
.phys_start = 0x80040,
.virt_start = 0x80040,
.size = 0x10,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | 
JAILHOUSE_MEM_ROOTSHARED,
},
},

.pci_devices = {
/* 00:00.0 */ {
.type = JAILHOUSE_PCI_TYPE_IVSHMEM,
.bdf = 0 << 3,
.bar_mask = {
0xff00, 0x, 0x,
0x, 0x, 0x,
},
   

Re: Jailhouse zynqMP

[iallende]

El jueves, 12 de abril de 2018, 9:20:03 (UTC+2), J. Kiszka  escribió:
> On 2018-04-11 14:32, iallende wrote:
> > El martes, 10 de abril de 2018, 16:44:45 (UTC+2), J. Kiszka  escribió:
> >> On 2018-04-10 15:12, Ralf Ramsauer wrote:
> >>> Hi,
> >>>
> >>> On 04/10/2018 02:10 PM, iallende wrote:
>  El martes, 10 de abril de 2018, 10:47:57 (UTC+2), Ralf Ramsauer  
>  escribió:
> > Hi,
> >
> > On 04/10/2018 10:26 AM, iallende wrote:
> >> El jueves, 22 de marzo de 2018, 16:33:02 (UTC+1), Ralf Ramsauer  
> >> escribió:
> >>> On 03/22/2018 04:23 PM, iallende wrote:
>  El miércoles, 21 de marzo de 2018, 15:25:02 (UTC+1), Ralf Ramsauer  
>  escribió:
> > Hi,
> >
> > On 03/21/2018 02:54 PM, iallende wrote:
> >> Hi everyone,
> >>
> >> I am trying to run Jailhouse in the ZynqMP, with Linux PREEMPT RT 
> >> in another cell. However, I have some problems when I add the 
> >> second Linux.
> >>
> >> root@xilinx-zcu102-2017_4:/# modprobe jailhouse
> >> [   52.445169] jailhouse: loading out-of-tree module taints kernel.
> >> root@xilinx-zcu102-2017_4:/# ls /dev/jailhouse ^C
> >> root@xilinx-zcu102-2017_4:/# jailhouse enable zynqmp-zcu102.cell 
> >>
> >> Initializing Jailhouse hypervisor v0.7 (0-g5c13b64) on CPU 2
> > Please checkout next and try again. This might already fix your 
> > issue.
>  With v0.8 i get this WARNING and I can load the module:
>  WARNING: "__hyp_stub_vectors" [/jailhouse/driver/jailhouse.ko] 
>  undefined!
> >>> Please switch to next, and not to v0.8. Compile your kernel with
> >>> CONFIG_KALLSYMS_ALL=y, or use this [1] patch.
> >>>
> >>>   Ralf
> >>>
> >>> [1]
> >>> http://git.kiszka.org/?p=linux.git;a=commit;h=2a681cb2213e3ea0f142fae7345fb80208a88a53
> >> Code location: 0xc0200050
> >> Page pool usage after early setup: mem 33/996, remap 64/131072
> >> Initializing processors:
> >>  CPU 2... OK
> >>  CPU 0... OK
> >>  CPU 3... OK
> >>  CPU 1... OK
> >> Adding virtual PCI device 00:00.0 to cell "ZynqMP-ZCU102"
> >> Adding virtual PCI device 00:01.0 to cell "ZynqMP-ZCU102"
> >> Page pool usage after late setup: mem 42/996, remap 69/131072
> >> Activating hypervisor
> >> [   63.697232] jailhouse: CONFIG_OF_OVERLAY disabled
> >> [   63.704029] jailhouse: failed to add virtual host controller
> >> [   63.711610] The Jailhouse is opening.
> >>
> >> root@xilinx-zcu102-2017_4:/# jailhouse cell linux 
> >> zynqmp-zcu102-linux-demo.cell Image -d system.dtb -i rootfs.cpio 
> >>
> >> FATAL: unhandled trap (exception class 0x17)
> > Exception class 0x17 is a SMC64 call.
> >
> >> Cell state before exception:
> >>  pc: ff800808e390   lr: ff8008467504 spsr: 2145 EL1
> >>  sp: ffc87b927ab0  esr: 17 1 000
> >>  x0: c214   x1: fd1a0060   x2: 
> > Furthermore, it's a SIP_64.
> >
> > Commit 2482c47bc2d05f ("arm64: ignore SIPs used for low-power 
> > modes") on
> > next will probably fix your issue.
> >
> >   Ralf
> >>  x3:    x4:    x5: 
> >>  x6:    x7:    x8: ff8008d27ee0
> >>  x9: ffc87aaa4b5c  x10: ffc87b927b4c  x11: ff8008c8ccb2
> >> x12:   x13: 0f93  x14: 0001
> >> x15:   x16: ff8008193240  x17: 004128f0
> >> x18: 00040900  x19: ffc87b927b28  x20: 0001
> >> x21: 4784b740  x22: 4784b740  x23: fffa
> >> x24: 000f4240  x25: 000f4240  x26: 000f4240
> >> x27:   x28:   x29: ffc87b927ac0
> >>
> >> Parking CPU 2 (Cell: "ZynqMP-ZCU102")
> >>
> >>
> >> Does anyone know why I have this problem? Am I missing any step?
> >>
> 
> >>
> >> Sorry Ralf, I did an error with the dtb. It works with the 
> >> inmate-zynqmp-zcu102.dtb. However, I do not achieve to see the 
> >> non-root linux console. I have tried with ttyS0 and ttyS1, but nothing 
> >> appears. How can I access to the second cell?
> >
> > Sorry for the late response! Ok -- so the other issues are solved and
> > the rest works now?
> >
> > Try to enable the JAILHOUSE_DBCON [1] in your kernel config and allow
> > your cell to use it by adding the .flag JAILHOUSE_CELL_DEBUG_CONSOLE to
> > your inmate's cell config (see Documentation/debug-output.md), and use
> > jailhouse0 as 

Re: [EXTERNAL] Re: Try jailhouse on Orange Pi Zero

[Qiu Shui]

On Monday, April 9, 2018 at 8:26:56 PM UTC+8, Qiu Shui wrote:
> On Monday, April 9, 2018 at 5:40:48 PM UTC+8, Qiu Shui wrote:
> > On Monday, April 9, 2018 at 2:19:13 PM UTC+8, J. Kiszka wrote:
> > > On 2018-04-09 02:42, Qiu Shui wrote:
> > > > On Sunday, April 8, 2018 at 2:18:28 PM UTC+8, Qiu Shui wrote:
> > > >> On Sunday, April 8, 2018 at 11:29:01 AM UTC+8, Qiu Shui wrote:
> > > >>> On Monday, April 2, 2018 at 4:33:40 PM UTC+8, Qiu Shui wrote:
> > >  On Monday, April 2, 2018 at 3:05:08 PM UTC+8, Nikhil Devshatwar 
> > >  wrote:
> > > > On Monday 02 April 2018 11:16 AM, Qiu Shui wrote:
> > > >> On Monday, April 2, 2018 at 11:12:12 AM UTC+8, Qiu Shui wrote:
> > > >>> On Thursday, March 29, 2018 at 1:09:46 PM UTC+8, Jan Kiszka wrote:
> > >  On 2018-03-29 06:36, Qiu Shui wrote:
> > > > I build the armbian with these two patches to the kernel:
> > > > [1]
> > > > http://git.kiszka.org/?p=linux.git;a=commit;h=f057e9bb4ba2fca0b435d36893eb41ddd57b4208
> > > > [2]
> > > > http://git.kiszka.org/?p=linux.git;a=commit;h=1c926e27072d4cca76a756058554485067ce472b
> > > >
> > > > But when I build jailhouse with the armbian kernel source 
> > > > files(version: Linux orangepizero 4.16.0-rc6-sunxi #2 SMP Wed 
> > > > Mar 28 15:33:44 CST 2018 armv7l GNU/Linux), I got these 
> > > > warnings:
> > > > WARNING: "__stack_chk_fail" 
> > > > [/home/liu/project/kiszka/jailhouse-0.8/driver/jailhouse.ko] 
> > > > undefined!
> > > > WARNING: "__hyp_stub_vectors" 
> > > > [/home/liu/project/kiszka/jailhouse-0.8/driver/jailhouse.ko] 
> > > > undefined!
> > > > WARNING: "__stack_chk_guard" 
> > > > [/home/liu/project/kiszka/jailhouse-0.8/driver/jailhouse.ko] 
> > > > undefined!
> > > >
> > > > I have tried some google solutions but still not solved.
> > > >
> > > > Are there any suggestions?
> > > 
> > >  Regarding __hyp_stub_vectors: you also need
> > >  http://git.kiszka.org/?p=linux.git;a=commitdiff;h=2a681cb2213e3ea0f142fae7345fb80208a88a53
> > > 
> > >  The other two issue seem to be related to some build 
> > >  inconsistency: Your
> > >  kernel was built without CONFIG_CC_STACKPROTECTOR, but when you 
> > >  build
> > >  the Jailhouse module, this feature is considered to be enabled.
> > > 
> > >  Jan
> > > >>>
> > > >>> Thank you very much!
> > > >>> After two days trying, I've finally built the kernel and 
> > > >>> jailhouse module successfully.
> > > >>> (I am using armbian building scripts and modified the 
> > > >>> linux-sunxi-dev.config with "# CONFIG_THUMB2_KERNEL is not set")
> > > >>>
> > > >>> Now I can enable jailhouse and create cell:
> > > >>> # jailhouse enable configs/orangepi0.cell
> > > >>> # jailhouse cell create configs/orangepi0-gic-demo.cell
> > > >>> # jailhouse cell list
> > > >>> ID  NameState   Assigned CPUs 
> > > >>>   Failed CPUs
> > > >>> 0   Orange-Pi0  running 0,2-3
> > > >>> 1   orangepi0-gic-demo  shut down   1
> > > >>>
> > > >>> But when I load the gic-demo.bin, it failed:
> > > >>> # jailhouse cell load orangepi0-gic-demo 
> > > >>> inmates/demos/arm/gic-demo.bin
> > > >>> Unhandled data read at 0x1f0(4)
> > > >>> FATAL: unhandled trap (exception class 0x24)
> > > >>> pc=0xc08cc6c0 cpsr=0x2013 hsr=0x93830007
> > > >>> r0=0x0190 r1=0x0002 r2=0xa035 r3=0xcf807000
> > > >>> r4=0xcda54e10 r5=0xc1103d00 r6=0x00300402 r7=0xcd8d7480
> > > >>> r8=0x0002300c r9=0x0285 r10=0x r11=0xcda47df4
> > > >>> r12=0x0030 r13=0xcda47dd0 r14=0xc08c9ab8
> > > >>> Parking CPU 3 (Cell: "Orange-Pi0")
> > > >>> Cell "orangepi0-gic-demo" can be loaded
> > > >>>
> > > >>> Any suggestions would be greatly appreciated :)
> > > >>>
> > > >>> Is there any demo can be used to make sure my jailhouse 
> > > >>> environments are ready?
> > > >>>
> > > >>> Thanks!
> > > >>
> > > >> I solved this problem by trying some different memory 
> > > >> configurations.
> > > >> The following does work:
> > > >> mem=448M vmalloc=256M
> > > >> /* Orangepi0.c */
> > > >>.hypervisor_memory = {
> > > >>.phys_start = 0x5f80,
> > > >>.size = 0x80,
> > > >>},
> > > >> ...
> > > >>/* RAM */ {
> > > >>.phys_start = 0x4000,
> > > >>.virt_start = 0x4000,
> > > >>.size =0x1f70,
> > > >>.flags = JAILHOUSE_MEM_READ | 
> > > >> JAILHOUSE_MEM_WRITE |
> > > >>   

Re: virtual network interface on x86

[anilappana]

On Monday, April 9, 2018 at 4:37:28 PM UTC+5:30, J. Kiszka wrote:
> On 2018-04-09 13:04, anilapp...@gmail.com wrote:
> > On Monday, April 9, 2018 at 11:55:26 AM UTC+5:30, J. Kiszka wrote:
> >> On 2018-04-08 11:59, anilapp...@gmail.com wrote:
> >>> On Saturday, April 7, 2018 at 3:24:13 PM UTC+5:30, Jan Kiszka wrote:
>  On 2018-04-07 06:01, anilapp...@gmail.com wrote:
> > Hi Henning,
> > Thanks for understanding our issue for ready to help us. I want to 
> > inform one more failure which we observed we after non rootcell bootup( 
> > it shows io remap failed).
> >
> >
> >
> > 0.403714] cpuidle: using governor ladder
> > [0.412705] cpuidle: using governor menu
> > [0.416813] PCI: Using configuration type 1 for base access
> > [0.422401] PCI: ashok JH PCI MMCONFIG
> > [0.426159] PCI: MMCONFIG for domain  [bus 00-ff] at [mem 
> > 0x8000-0x8fff] (base 0x8000)
> > [0.435469] [ cut here ]
> > [0.440098] WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:121 
> > __ioremap_caller+0x286/0x360
> > [0.448536] ioremap on RAM at 0x8000 - 0x8fff
> > [0.454974] Modules linked in:
> > [0.458050] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> > 4.9.47-rt37+-RedHawk-7.4-custom #27
> > [0.466216]  c962bd10 8155da23 c962bd60 
> > 
> > [0.473666]  c962bd50 81077d1b 0079 
> > 1000
> > [0.481119]  0002 81d95e3f 8000 
> > 
> > [0.488573] Call Trace:
> > [0.491021]  [] dump_stack+0x85/0xc2
> > [0.496159]  [] __warn+0xcb/0xf0
> > [0.500945]  [] ? pci_mmcfg_arch_map+0x2f/0x70
> > [0.506947]  [] warn_slowpath_fmt+0x4f/0x60
> > [0.512685]  [] __ioremap_caller+0x286/0x360
> > [0.518510]  [] ? vprintk_default+0x29/0x40
> > [0.524249]  [] ? printk+0x48/0x50
> > [0.529213]  [] ? pcibios_resource_survey+0x70/0x70
> > [0.535641]  [] ioremap_nocache+0x17/0x20
> > [0.541205]  [] pci_mmcfg_arch_map+0x2f/0x70
> > [0.547029]  [] pci_mmcfg_arch_init+0x1d/0x42
> > [0.552941]  [] jailhouse_pci_arch_init+0x40/0x44
> > [0.559197]  [] pci_arch_init+0x3b/0x66
> > [0.564588]  [] do_one_initcall+0x50/0x190
> > [0.570238]  [] ? parse_args+0x26a/0x3f0
> > [0.575717]  [] kernel_init_freeable+0x1cf/0x257
> > [0.581887]  [] ? rest_init+0x90/0x90
> > [0.587102]  [] kernel_init+0xe/0x120
> > [0.592321]  [] ret_from_fork+0x2a/0x40
> > [0.597728] ---[ end trace 38a36dc7a73d77e3 ]---
> > [0.602349] PCI: can't map MMCONFIG at [mem 0x8000-0x8fff]
> > [0.609402] kworker/u4:4 (63) used greatest stack depth: 13512 bytes 
> > left
> >
> >
> > I attached complete logs for your reference. we will try with what ever 
> > the inputs you gave to us and will let you know. I am also sharing 
> > rootcell and non root cell configs which we are using.
> 
>  You configured a conflict here: The shared memory region is also a RAM
>  region for the cell.
> 
>  Jan
> >>>
> >>> Jan,
> >>> we added below region for shared memory
> >>>
> >>>.phys_start = 0x40410, 
> >>>   
> >>>  .virt_start = 0x40410, 
> >>>.size = 0x10, 
> >>> This is not RAM region. I attached iomem file for by Machine. Can you 
> >>> please check.
> >>>
> >>
> >> Ah, sorry, it's not the shared memory, it's the MMCONFIG region:
> >>
> >> [0.440098] WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:121 
> >> __ioremap_caller+0x286/0x360
> >> [0.448536] ioremap on RAM at 0x8000 - 0x8fff
> >>
> >> because of (fixed)
> >>
> >>.platform_info = {
> >>.pci_mmconfig_base = 0x8000,
> >>.pci_mmconfig_end_bus = 0xff,
> >>
> >>
> >> vs. 
> >>
> >>/* high RAM */ 
> >>{
> >> .phys_start = 0x40430/*0x40110*/,
> >> .virt_start = 0x0020,
> >> .size = 0xC000, /*1GB*/
> >> /*.size = 0x3200, */   /*800MB try*/   
> >> /*0x1BF0, 400MB rajmohan*/ /*0xC80*/
> >> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> >>JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_DMA |
> >>JAILHOUSE_MEM_LOADABLE,
> >>},
> >>
> >> BTW, I would recommend to cleanup your configs. They are... hard to read
> >> now.
> >>
> >> Jan
> >> -- 
> >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >> Corporate Competence Center Embedded Linux
> > 
> > Hi 

Re: Share memory among cells on arm64

[Jan Kiszka]

On 2018-04-12 08:51, Claudio Scordino wrote:
> BTW, we plan to have a version of the PCI stuff rebased upstream in a
> couple of weeks.
> We'll post it on the ML once ready.

Great!

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: Jailhouse zynqMP

[Jan Kiszka]

On 2018-04-11 14:32, iallende wrote:
> El martes, 10 de abril de 2018, 16:44:45 (UTC+2), J. Kiszka  escribió:
>> On 2018-04-10 15:12, Ralf Ramsauer wrote:
>>> Hi,
>>>
>>> On 04/10/2018 02:10 PM, iallende wrote:
 El martes, 10 de abril de 2018, 10:47:57 (UTC+2), Ralf Ramsauer  escribió:
> Hi,
>
> On 04/10/2018 10:26 AM, iallende wrote:
>> El jueves, 22 de marzo de 2018, 16:33:02 (UTC+1), Ralf Ramsauer  
>> escribió:
>>> On 03/22/2018 04:23 PM, iallende wrote:
 El miércoles, 21 de marzo de 2018, 15:25:02 (UTC+1), Ralf Ramsauer  
 escribió:
> Hi,
>
> On 03/21/2018 02:54 PM, iallende wrote:
>> Hi everyone,
>>
>> I am trying to run Jailhouse in the ZynqMP, with Linux PREEMPT RT in 
>> another cell. However, I have some problems when I add the second 
>> Linux.
>>
>> root@xilinx-zcu102-2017_4:/# modprobe jailhouse
>> [   52.445169] jailhouse: loading out-of-tree module taints kernel.
>> root@xilinx-zcu102-2017_4:/# ls /dev/jailhouse ^C
>> root@xilinx-zcu102-2017_4:/# jailhouse enable zynqmp-zcu102.cell 
>>
>> Initializing Jailhouse hypervisor v0.7 (0-g5c13b64) on CPU 2
> Please checkout next and try again. This might already fix your issue.
 With v0.8 i get this WARNING and I can load the module:
 WARNING: "__hyp_stub_vectors" [/jailhouse/driver/jailhouse.ko] 
 undefined!
>>> Please switch to next, and not to v0.8. Compile your kernel with
>>> CONFIG_KALLSYMS_ALL=y, or use this [1] patch.
>>>
>>>   Ralf
>>>
>>> [1]
>>> http://git.kiszka.org/?p=linux.git;a=commit;h=2a681cb2213e3ea0f142fae7345fb80208a88a53
>> Code location: 0xc0200050
>> Page pool usage after early setup: mem 33/996, remap 64/131072
>> Initializing processors:
>>  CPU 2... OK
>>  CPU 0... OK
>>  CPU 3... OK
>>  CPU 1... OK
>> Adding virtual PCI device 00:00.0 to cell "ZynqMP-ZCU102"
>> Adding virtual PCI device 00:01.0 to cell "ZynqMP-ZCU102"
>> Page pool usage after late setup: mem 42/996, remap 69/131072
>> Activating hypervisor
>> [   63.697232] jailhouse: CONFIG_OF_OVERLAY disabled
>> [   63.704029] jailhouse: failed to add virtual host controller
>> [   63.711610] The Jailhouse is opening.
>>
>> root@xilinx-zcu102-2017_4:/# jailhouse cell linux 
>> zynqmp-zcu102-linux-demo.cell Image -d system.dtb -i rootfs.cpio 
>>
>> FATAL: unhandled trap (exception class 0x17)
> Exception class 0x17 is a SMC64 call.
>
>> Cell state before exception:
>>  pc: ff800808e390   lr: ff8008467504 spsr: 2145 EL1
>>  sp: ffc87b927ab0  esr: 17 1 000
>>  x0: c214   x1: fd1a0060   x2: 
> Furthermore, it's a SIP_64.
>
> Commit 2482c47bc2d05f ("arm64: ignore SIPs used for low-power modes") 
> on
> next will probably fix your issue.
>
>   Ralf
>>  x3:    x4:    x5: 
>>  x6:    x7:    x8: ff8008d27ee0
>>  x9: ffc87aaa4b5c  x10: ffc87b927b4c  x11: ff8008c8ccb2
>> x12:   x13: 0f93  x14: 0001
>> x15:   x16: ff8008193240  x17: 004128f0
>> x18: 00040900  x19: ffc87b927b28  x20: 0001
>> x21: 4784b740  x22: 4784b740  x23: fffa
>> x24: 000f4240  x25: 000f4240  x26: 000f4240
>> x27:   x28:   x29: ffc87b927ac0
>>
>> Parking CPU 2 (Cell: "ZynqMP-ZCU102")
>>
>>
>> Does anyone know why I have this problem? Am I missing any step?
>>

>>
>> Sorry Ralf, I did an error with the dtb. It works with the 
>> inmate-zynqmp-zcu102.dtb. However, I do not achieve to see the non-root 
>> linux console. I have tried with ttyS0 and ttyS1, but nothing appears. 
>> How can I access to the second cell?
>
> Sorry for the late response! Ok -- so the other issues are solved and
> the rest works now?
>
> Try to enable the JAILHOUSE_DBCON [1] in your kernel config and allow
> your cell to use it by adding the .flag JAILHOUSE_CELL_DEBUG_CONSOLE to
> your inmate's cell config (see Documentation/debug-output.md), and use
> jailhouse0 as output path. Then you should at least see the kernel 
> booting.
>
> Maybe this already gives you a clue what's going on. As far as I can
> see, the upstream inmate configs look fine.
>
> Are other inmates that use the same inmate config able to use the UART?
>

Re: Share memory among cells on arm64

[Luca Cuomo]

Il giorno giovedì 12 aprile 2018 08:51:39 UTC+2, Claudio Scordino ha scritto:
> Hi Giovani,
> 
> 
> 
> 
> 2018-04-12 8:01 GMT+02:00 Jan Kiszka :
> On 2018-04-11 19:40, Giovani Gracioli wrote:
> 
> > Here is the output of the unhandled data read:
> 
> >
> 
> > Unhandled data read at 0xfc10(2)
> 
> >
> 
> > FATAL: unhandled trap (exception class 0x24)
> 
> > Cell state before exception:
> 
> >  pc: 1828   lr: 15f0 spsr: 6005     EL1
> 
> >  sp: 3f30  esr: 24 1 146
> 
> >  x0: fc10   x1:    x2: 0002
> 
> >  x3: fc00   x4:    x5: 
> 
> >  x6: 1000   x7:    x8: 
> 
> >  x9:   x10:   x11: 
> 
> > x12:   x13:   x14: 
> 
> > x15:   x16:   x17: 
> 
> > x18:   x19: 1000  x20: 
> 
> > x21: 1af4  x22: 1110  x23: 1000
> 
> > x24: 2660  x25:   x26: 
> 
> > x27:   x28:   x29: 
> 
> >
> 
> > Parking CPU 3 (Cell: "gic-demo-ivshmem")
> 
> >
> 
> > Am I missing something in the configuration?
> 
> 
> 
> Possibly. As this is code of Claudio and his colleagues, he may answer
> 
> this better.
> 
> 
> 
> A collegue of mine is looking at your issue.
> 
> 
> BTW, we plan to have a version of the PCI stuff rebased upstream in a couple 
> of weeks.
> 
> We'll post it on the ML once ready.
> 
> 
> Regards,
> 
> 
>    Claudio

Hi all,

i'm trying to understand what's wrong in the configuration.
1. The PCI configuration of the root cell (and its relative shared memory 
region ) needs a counterpart in the inmate configuration. The two PCI must have 
the same bdf. In fact when the configuration is ok, jailhouse prints on the 
screen che binding between the PCI devices.

2. The starting search address of the inmate library (#define PCI_CFG_BASE in 
inmates/lib/arm-common/pci.c) must be the same of the platform_info section in 
the root cell configuration (  
.platform_info = {
.pci_mmconfig_base = 0x4800,
.pci_mmconfig_end_bus = 0x0,
.pci_is_virtual = 1,
.
)

3. The best way to access the shared memory region from linux is using the 
uio_ivshmem driver. It works correctly on ARM64. It just needs the UIO kernel 
module as dependency. Once loaded, you can see memory infos in 
/sys/class/uio/uio0/maps[0,1] which are shmem informations and bar information. 

Regards,

--Luca

-- 
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: Share memory among cells on arm64

[Claudio Scordino]

Hi Giovani,

2018-04-12 8:01 GMT+02:00 Jan Kiszka :

> On 2018-04-11 19:40, Giovani Gracioli wrote:
> > Here is the output of the unhandled data read:
> >
> > Unhandled data read at 0xfc10(2)
> >
> > FATAL: unhandled trap (exception class 0x24)
> > Cell state before exception:
> >  pc: 1828   lr: 15f0 spsr: 6005 EL1
> >  sp: 3f30  esr: 24 1 146
> >  x0: fc10   x1:    x2: 0002
> >  x3: fc00   x4:    x5: 
> >  x6: 1000   x7:    x8: 
> >  x9:   x10:   x11: 
> > x12:   x13:   x14: 
> > x15:   x16:   x17: 
> > x18:   x19: 1000  x20: 
> > x21: 1af4  x22: 1110  x23: 1000
> > x24: 2660  x25:   x26: 
> > x27:   x28:   x29: 
> >
> > Parking CPU 3 (Cell: "gic-demo-ivshmem")
> >
> > Am I missing something in the configuration?
>
> Possibly. As this is code of Claudio and his colleagues, he may answer
> this better.
>

A collegue of mine is looking at your issue.

BTW, we plan to have a version of the PCI stuff rebased upstream in a
couple of weeks.
We'll post it on the ML once ready.

Regards,

   Claudio

-- 
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: RFC: text for cell loading documentation

[Jan Kiszka]

On Wednesday, April 11, 2018 at 12:23:21 PM UTC+2, f1f0 wrote:
>
> I am proposing to add a Documentation/cell-loading.md file. 
> Rather than proposing the .md directly, I prefer to propose raw text 
> discussion, 
> then work on the cosmetics and links from other parts of the 
> Documentation. 
>
> -FF 
>
> Jailhouse loading of images is pretty flexible but can be disconcerting. 
>
> The syntax is: 
>
> jailhouse cell load \ 
> { ID | [--name] NAME } \ 
> { { IMAGE | { -s | --string } "STRING" } [-a | --address ADDRESS] } ... 
>
> Valid forms are: 
>
> # loads inamte.bin (offset 0 assumed) 

inmate.bin

>  jailhouse cell load foocell inmate.bin 
>
> # same as above with explicit location 
> jailhouse cell load foocell inmate.bin -a 0 
>
> # load three binary objects (in order) 
> jailhouse cell load foocell \ 
> inmate.bin \ 
> sharedobject.so -a 0x100 \ 
> ramfs.bin -a 0x200 
>
> The first example assumes "-a 0". 
>
> The last example, loads in the order specified, three binary objects, 
> the first one at offset 0, the second one at 0x100. 
> Should inmate.bin be larger than 0x100, the upper part will be 
> overridden 
> by sharedobject.so. 
>
> Whatever load order, execution starts in the cell at offset 0. 
>
>
> This multi-image loading capability can be used to patch images and 
> pass parameters to the image. The following explains how parameters are 
> passed 
> with the inmate library. 
>
> The inmate library assumes a command line string to be located at a 
> fixed 
> location that is processor specific: 
> - On x86 this is offset 0x100 (see inmates/lib/x86/inmate.lds) 
> - On arm64, this is offset 0x1000 (see inmates/lib/arm64/inmate.lds.S) 
>
> The command line string capacity is fixed (256 bytes by defaylt) by 

default

But it is not fixed, inmates may expand it. None of the demo inmates
does, though.

> CMDLINE_BUFFER_SIZE 
> in inmates/lib/cmdline.c. 
>
> Here is an example to pass  parameters stored in the file 
> commandline.txt to the last example on an x86 system: 
>
> OFFSET=0x100 
> jailhouse cell load foocell \ 
> inmate.bin \ 
> commanline.txt -a $OFFSET \ 
> sharedobject.so -a 0x100 \ 
> ramfs.bin -a 0x200 
>
> This command patches inmate.bin at offset 0x100 that happens to be char* 
> cmdline for 
> inmates that uses Jailhouse inmates library. 
>
> Note: on an arm64 we would set OFFSET=0x1000 
>
> To be more practical and avoid using a text file, there is an 
> image-as-string 
> option: 
>
> OFFSET=0x100 
> jailhouse cell load foocell \ 
> inmate.bin \ 
> -s "" -a $OFFSET \ 
> sharedobject.so -a 0x100 \ 
> ramfs.bin -a 0x200 
>
> The string in the -s need to be less than 255 characters long 
> (CMDLINE_BUFFER_SIZE - terminatind \0) 
> otherwise it will silently overwrite existing code. 

You pointed out this limit above already.

Thanks for kicking this off. As I wrote in the other thread, I think
this information is best located in a man page for the jailhouse tool.
Of course, that would imply writing more than "just" about jailhouse
cell load... :D But maybe we can start the man page with "to-be-written"
stubs.

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: Share memory among cells on arm64

[Jan Kiszka]

On 2018-04-11 19:40, Giovani Gracioli wrote:
> Here is the output of the unhandled data read:
> 
> Unhandled data read at 0xfc10(2)
> 
> FATAL: unhandled trap (exception class 0x24)
> Cell state before exception:
>  pc: 1828   lr: 15f0 spsr: 6005 EL1
>  sp: 3f30  esr: 24 1 146
>  x0: fc10   x1:    x2: 0002
>  x3: fc00   x4:    x5: 
>  x6: 1000   x7:    x8: 
>  x9:   x10:   x11: 
> x12:   x13:   x14: 
> x15:   x16:   x17: 
> x18:   x19: 1000  x20: 
> x21: 1af4  x22: 1110  x23: 1000
> x24: 2660  x25:   x26: 
> x27:   x28:   x29: 
> 
> Parking CPU 3 (Cell: "gic-demo-ivshmem")
> 
> Am I missing something in the configuration?

Possibly. As this is code of Claudio and his colleagues, he may answer
this better.

Jan

> 
>> Hi Jan,
>>
>> Thanks for the reply. I am using the uio driver and when I load it, the pci 
>> devices become enabled. I suppose this part is ok:
>>
>> lspci -v after the driver is loaded:
>>
>> 00:00.0 Unassigned class [ff00]: Red Hat, Inc Inter-VM shared memory
>> Subsystem: Red Hat, Inc Inter-VM shared memory
>> Flags: bus master, fast devsel, latency 0, IRQ 38
>> Memory at fc10 (64-bit, non-prefetchable) [size=256]
>> Kernel driver in use: uio_ivshmem
>>
>> 00:01.0 Unassigned class [ff01]: Red Hat, Inc Inter-VM shared memory
>> Subsystem: Red Hat, Inc Inter-VM shared memory
>> Flags: bus master, fast devsel, latency 0, IRQ 39
>> Memory at fc100100 (64-bit, non-prefetchable) [size=256]
>> Kernel driver in use: uio_ivshmem
>>
>> I got the code available here 
>> (https://github.com/evidence/linux-jailhouse-tx1) that has an ivshmem demo 
>> on arm. I basically copied and pasted the pci_read_config and 
>> pci_write_config functions in the inmates/lib/arm-common/pci.c (had to 
>> change some makefiles to compile the code because of the pci.c file).
>>
>> However, I am getting an Unhandled data read at 0xfc10, which is the 
>> address of the 00:00.0 device, during the execution of the function 
>> pci_find_device().
>>
>> If a decrease the while value test in the pci_find_device() function (bdf < 
>> 0x1), it does not find any PCI device (obviously) and there is no error.
>>
>> start_bdf is initially defined as 0xfc00, as configured in the root cell 
>> (.pci_mmconfig_base = 0xfc00).
>>
>> Any suggestion?
>>
>> Giovani
>>
>>> On 2018-04-10 16:39, Giovani Gracioli wrote:
 Updating:

 I added 

 .num_msix_vectors = 1,
 .iommu = 1, 

 to the root cell .pci_devices config, wrote a simple linux program to 
 write to the shared memory (0x80050) and a simple inmate cell code to 
 read from the shared memory. It was able to read the values that were 
 written.

 The next step is how to generate interrupts among the cells. I tried to 
 use the pci functions (the same used in the ivshmem-demo) on the arm64 but 
 got an error. The lib/pci.c is not compiled by arm64.

 How should I discover the pci device and send/receive interrupts on arm64?

>>>
>>> ivshmem demo inmate for ARM/ARM64 is still work in progress. Henning, is
>>> there any intermediate step we can point to?
>>>
>>> You could start your tests between two Linux cells, meanwhile, using the
>>> uio driver.
>>>
>>> Jan
>>>
>>> -- 
>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>>> Corporate Competence Center Embedded Linux
> 

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