Re: Jailhouse: enter_hypervisor returns -ENOMEM
Am Sun, 13 Nov 2022 22:24:45 + schrieb Karim Manaouil : > Hi Ralf, > > Thanks for the reply! > > >Did you use jailhouse-config-create? > > I am using `jailhouse config create` to generate the sysconfig.c file. > > >You can use the --mem-hv option to > increate the memory. Try, for example, 32MiB and see if it works. > > I tried with 32MiB. It worked. I am not getting -ENOMEM anymore. > The driver prints "The Jailhouse is opening" on dmesg. However, right > after that the CPUs get stuck, and I get rcu_sched detected stalls. > The system is completely irresponsive. > > I attached a text file containing the full output from dmesg. Here is > the initial part: I guess the output of the hypervisor might also be valuable here. According to its spec that machine should have a serial port, and with that default config from the generate script you should see logs coming out of there. With the usual 115200 8n1 Henning > [ 434.792008] The Jailhouse is opening. > [ 455.787315] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: > [ 455.793303] rcu: 1-...0: (839 GPs behind) > idle=c2a/1/0x4000 softirq=681/681 fqs=1827 [ 455.802292] > rcu: 2-...0: (144 GPs behind) idle=812/1/0x4000 > softirq=905/905 fqs=1827 [ 455.811276] rcu: 3-...0: (144 GPs > behind) idle=eaa/1/0x4000 softirq=719/719 fqs=1827 [ > 455.820266] rcu: 4-...0: (1 GPs behind) > idle=c2e/1/0x4000 softirq=1324/1324 fqs=1827 [ > 455.829252] rcu: 5-...0: (144 GPs behind) > idle=41a/1/0x4000 softirq=556/556 fqs=1827 [ 455.838238] > rcu: 6-...0: (144 GPs behind) idle=912/1/0x4000 > softirq=777/777 fqs=1827 [ 455.847218] rcu: 7-...0: (144 GPs > behind) idle=5e6/1/0x4000 softirq=2409/2410 fqs=1827 [ > 455.856404] (detected by 87, t=5253 jiffies, g=48537, q=364) [ > 455.862170] Sending NMI from CPU 87 to CPUs 1: [ 465.776884] Sending > NMI from CPU 87 to CPUs 2: [ 467.182686] watchdog: BUG: soft lockup > - CPU#0 stuck for 23s! [kworker/0:1:7] [ 467.189857] Modules linked > in: jailhouse(O) nf_conntrack_netlink xfrm_user xt_addrtype > br_netfilter xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT > nf_reject_ipv4 xt_tcpudp nft_compat nft_chain_nat nf_natp [ > 467.189928] binfmt_misc configfs efivarfs ip_tables x_tables autofs4 > ext4 crc16 mbcache jbd2 raid10 raid456 libcrc32c crc32c_generic > async_raid6_recov async_memcpy async_pq async_xor xor async_tx > raid6_pq ] [ 467.320567] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G > O 5.10.0 #3 [ 467.328767] Hardware name: Dell Inc. > PowerEdge R7425/08V001, BIOS 1.15.0 09/11/2020 [ 467.337154] > Workqueue: events drm_fb_helper_dirty_work [drm_kms_helper] [ > 467.344501] RIP: 0010:smp_call_function_many_cond+0x289/0x2d0 [ > 467.350979] Code: e8 1c 8a 39 00 3b 05 0a c1 74 01 89 c7 0f 83 0b fe > ff ff 48 63 c7 49 8b 16 48 03 14 c5 00 d9 99 9c 8b 42 08 a8 01 74 09 > f3 90 <8b> 42 08 a8 01 75 f7 eb c9 48 c7 c2 20 cf 07 9d 4c 89 fe 44 7 > [ 467.371232] RSP: 0018:a7d78015fcd8 EFLAGS: 0202 [ > 467.377220] RAX: 0011 RBX: 00031280 RCX: > 0001 [ 467.385123] RDX: 964f1fa31280 RSI: > RDI: 0001 [ 467.393024] RBP: > R08: R09: 0001 [ > 467.400928] R10: 0002 R11: 0002 R12: > [ 467.408836] R13: 007f R14: > 962f1f42c9c0 R15: 0080 [ 467.416737] FS: > () GS:962f1f40() > knlGS: [ 467.425604] CS: 0010 DS: ES: > CR0: 80050033 [ 467.432127] CR2: CR3: > 0010987ea000 CR4: 003506f0 [ 467.440045] Call Trace: [ > 467.443289] ? tlbflush_read_file+0x70/0x70 [ 467.448266] ? > tlbflush_read_file+0x70/0x70 [ 467.453242] on_each_cpu+0x2b/0x60 [ > 467.457437] __purge_vmap_area_lazy+0x5d/0x680 [ 467.462679] ? > _cond_resched+0x16/0x40 [ 467.467224] ? > unmap_kernel_range_noflush+0x2fa/0x380 [ 467.473072] > free_vmap_area_noflush+0xe7/0x100 [ 467.478315] > remove_vm_area+0x96/0xa0 [ 467.482770] __vunmap+0x8d/0x290 [ > 467.486792] drm_gem_shmem_vunmap+0x8b/0xa0 [drm] [ 467.492299] > drm_client_buffer_vunmap+0x16/0x20 [drm] [ 467.498144] > drm_fb_helper_dirty_work+0x187/0x1b0 [drm_kms_helper] [ 467.505118] > process_one_work+0x1b6/0x350 [ 467.509912] worker_thread+0x53/0x3e0 > [ 467.514361] ? process_one_work+0x350/0x350 [ 467.519338] > kthread+0x11b/0x140 [ 467.523342] ? __kthread_bind_mask+0x60/0x60 [ > 467.528389] ret_from_fork+0x22/0x30 > > Cheers > Karim > > From: Ralf Ramsauer > Sent: 12 November 2022 17:47 > To: Karim Manaouil ; jan.kis...@siemens.com > Cc: jailhouse-dev@googlegroups.com > Subject: Re: Jailhouse: > enter_hypervisor returns -ENOMEM > > This email was sent to you by someone outside the University. > You should only click on links or att
Re: NXP LS1043
I ran it successfully on that board years ago. There was some collaboration with NXP at the time and the files you seen in the tree have been contributed by NXP. So support is present and good. However DPAA can not be partitioned so you get say ... 4 totally independent NICs with cells that do not need to trust each other. But a cooperative sharing is possible. Like a root cell gets DPAA and a non-root gets a vNIC that is bridged to a DPAA port in the root cell. So both have network. But root-cell can see traffic of non-root and has to be running to forward it. Henning Am Wed, 26 Oct 2022 09:13:40 -0700 (PDT) schrieb Tim Biernat : > Can someone speak to (or point me in the right direction) to the > state of current support for this board? I see some config support > under arm64. > > Thanks in advance, > Tim B > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20221027172715.1bbfaeaf%40md1za8fc.ad001.siemens.net.
Re: Ask for help，about cpu down after jailhouse enable。。
Am Wed, 10 Aug 2022 23:29:16 -0700 (PDT) schrieb star sun : > i want make jailhouse working in one phone with 4 cortex-a53 cpu. > > I feel like I've successfully executed jailhouse enbale. > unfortunately, there is a kernel panicwhen i down one cpu for a > non-root-cell during jialhouse cell create . > > This question has puzzled me for a long timeDo you have any good > methods? thank you You could try offlining one or more CPUs with your stock kernel and not even the jailhouse module loaded. If that also causes problems you are likely dealing with a vendor kernel that has been patched to become sort of broken. echo 0 > /sys/devices/system/cpu/cpu3/online writing a 1 will bring it back. This should work before you even start with jailhouse. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20220811133427.336a5da7%40md1za8fc.ad001.siemens.net.
Re: Troubles running jailhouse
Am Fri, 29 Jul 2022 13:02:55 +0200 schrieb Sara Alonso : > Dear Henning, > > Thanks a lot for your help. It worked with insmod. Now I can do > *modprobe jailhouse*, but then, when I do* jailhouse enable > /boot/zynqmp-zcu102.cell* I get this message:* -sh: jailhouse: > command not found*. Is there another step I have to do before, or do > you know how I could fix this? I bet you made some mistake in actually installing all jailhouse components into that rootfs. So that module was somehow missing, now you are missing the jailhouse binary ... next will be the hypervisor binary and so on. Please double check that "make install" maybe with a V=1 to see what gets installed where. You should be able to specify any temporary dir as DESTDIR and all you find there should exist in that rootfs at the same location. Maybe the jailhouse binary was installed just fine but in a directory not in your PATH, something like "/usr/local/bin". In that case maybe add that to your PATH or try calling it absolute. But i guess for the later runs where you might want to have a linux non-root it would be good if all things are installed and binaries all found via PATH. Henning > Thank you very much, > Sara > > El vie, 29 jul 2022 a las 12:44, Henning Schild > () escribió: > > > Am Fri, 29 Jul 2022 11:33:32 +0200 > > schrieb Sara Alonso : > > > > > Hi! > > > > > > I am trying to run jailhouse in a zcu102 board following this > > > tutorial: > > > > > https://github.com/siemens/jailhouse/blob/master/Documentation/setup-on-zynqmp-zcu102.md > > > > > But I am new at this and I have some troubles. > > > > > > I have built the petalinux-project and also jailhouse. I have > > > copied into the SD: the image.ub, BOOT.BIN, system.dtb, > > > inmate-zynqmp.dtb, zynqmp-zcu102.cell and > > > zynqmp-zcu102-inmate-demo.cell in the BOOT partition and the > > > rootfs.cpio + the lib and usr files installed when jailhouse is > > > compiled in the ROOT partition. I don't know if something else is > > > required or if something is not needed. > > > > > > The project is running, but if I do "modprobe jailhouse" it says: > > > modprobe: module jailhouse not found in modules.dep > > > I think I have followed all the steps of the tutorial. What could > > > be happening? > > > > Jailhouse uses a kernel module which you have to copy as well. > > Double check that you did. It should be called jailhouse.ko and end > > up somewhere in /lib/modules//extra or something. For > > "modprobe" to work you might have to run "depmod -a" first, > > otherwise you can also "insmod /lib/.../jailhouse.ko" and load it > > by file instead of by name. > > > > regards, > > Henning > > > > > Thank you very much, > > > Sara > > > > > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20220729143439.11e5a2d8%40md1za8fc.ad001.siemens.net.
Re: Troubles running jailhouse
Am Fri, 29 Jul 2022 11:33:32 +0200 schrieb Sara Alonso : > Hi! > > I am trying to run jailhouse in a zcu102 board following this > tutorial: > https://github.com/siemens/jailhouse/blob/master/Documentation/setup-on-zynqmp-zcu102.md > But I am new at this and I have some troubles. > > I have built the petalinux-project and also jailhouse. I have copied > into the SD: the image.ub, BOOT.BIN, system.dtb, inmate-zynqmp.dtb, > zynqmp-zcu102.cell and zynqmp-zcu102-inmate-demo.cell in the BOOT > partition and the rootfs.cpio + the lib and usr files installed when > jailhouse is compiled in the ROOT partition. I don't know if > something else is required or if something is not needed. > > The project is running, but if I do "modprobe jailhouse" it says: > modprobe: module jailhouse not found in modules.dep > I think I have followed all the steps of the tutorial. What could be > happening? Jailhouse uses a kernel module which you have to copy as well. Double check that you did. It should be called jailhouse.ko and end up somewhere in /lib/modules//extra or something. For "modprobe" to work you might have to run "depmod -a" first, otherwise you can also "insmod /lib/.../jailhouse.ko" and load it by file instead of by name. regards, Henning > Thank you very much, > Sara > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20220729124412.4f8aecc6%40md1za8fc.ad001.siemens.net.
Re: Adding another vpci
Am Mon, 10 Jan 2022 13:31:16 -0800 (PST) schrieb Moustafa Nofal : > Hi, > I intend to add another Linux on Raspberry Pi4. So, I added also a > memory region on rpi4.c and extended the size of mem_regions by, and > managed to get working. I added a pci device, and extended the array > by one, and the pci device is added, but without kernel driver in > use? So, how to add the driver to it? What kind of device is it? The kernel should simply find it and bind any driver that fits, in case it has one that does. If it is a virtual network device based on ivshmem2 you need to add the pci device, and multiple memory regions for it JAILHOUSE_SHMEM_NET_REGIONS for the driver to pick it up correctly you need to set the shmem_protocol of the pci device to JAILHOUSE_SHMEM_PROTO_VETH and set the index shmem_regions_start to your newly added memory regions. regards, 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/2022003848.5abbc20e%40md1za8fc.ad001.siemens.net.
Re: HELP
Am Mon, 13 Dec 2021 01:31:01 -0800 (PST) schrieb Moustafa Nofal : > Hello Mr Henning > >If that PCI device is of type JAILHOUSE_SHMEM_PROTO_VETH > >and the cell has a driver ... you will see a new ethernet interface > >becoming available. > What do you mean by "and the cell has a driver" I ported jailhouse on > both 5.4 and 5.10 kernel using jailhouse patches. And added ivshmem > interface but it was not working. Cell has a driver means that you took one of the "jailhouse-enabling" branches from https://github.com/siemens/linux/ You did set CONFIG_IVSHMEM_NET for that kernel. You did configure your cells with the respective virtual PCI devices and memory regions. Best check out https://github.com/siemens/jailhouse-images to see how to plug things together. regards, Henning > Best regards, > Moustafa Noufale > On Monday, 29 March 2021 at 11:02:57 UTC+2 Henning Schild wrote: > > > Am Sun, 28 Mar 2021 22:16:14 +0800 (GMT+08:00) > > schrieb 曹宏鹏 : > > > > > Dear sir: > > > > > > As we all know, the cell could communicate with root cell by > > > ivshmem in Jailhouse. And there is a virtual Network Interface > > > Card(NIC) on non-root cell. When I run Jailhouse on my raspberry > > > Pi 4 model b, I was successful to create a cell and assigned a > > > address to it. The root cell can communicate with non-root cell , > > > I know this is based on ivshmem. But I want to know > > > > > > 1. Whether the virtual NIC support other protocols. > > > > It is a virtual ethernet connection, on top you can use anything > > that can be done on top of "network". It is probably best to build > > whatever you need on top of Ethernet, maybe nfs, remote desktop ... > > but if you really need a custom protocol at the base you can write > > your own driver and choose another ".shmem_protocol" > > There is ivshmem-demo giving a simple raw usage example of > > JAILHOUSE_SHMEM_PROTO_UNDEFINED. > > > > > 2. What is difference between virtual NIC in non-root cell and > > > NIC in root cell. > > > > There is none. Once running under jailhouse a cell might see the PCI > > device for shared memory communication on the bus (depending on the > > cell config). If that PCI device is of type > > JAILHOUSE_SHMEM_PROTO_VETH and the cell has a driver ... you will > > see a new ethernet interface becoming available. > > > > > 3. Why the virtual NIC cannot ping baidu.com(in China ) or > > > google.com. > > > > You essentially have an isolated network between the two cells. To > > connect the inmate to the internet, the root cell will have to > > become a network router. So you would set up i.e. NAT to connect on > > layer3 > > > > The most simple solution could be to create a network bridge where > > you attach the real physical network interface and later the > > virtual one. (in the root cell) > > After doing that the non-root should be in the same Layer2 network > > and can use DHCP to get a network configuration that will allow > > internet access just like the root-cell has. > > > > All that is basic networking and has nothing to do with jailhouse. > > > > regards, > > Henning > > > > > If I get your help, I will appreciate ！ > > > > > > > > > Yours sincerely, > > > HOngpeng Cao. > > > > > > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20220105204517.06c9af0a%40md1za8fc.ad001.siemens.net.
Re: Problem: system hangs
Am Thu, 4 Nov 2021 11:47:00 +
schrieb Raimundo Sagarzazu :
> Hello all,
>
> I'm experiencing a "system hanging" problem when jalhouse is enabled.
> It happens with just rootcell enabled, no need to start inmate cells.
> I've been working on it for several weeks trying to have at least an
> error log or report but I didn't success. System just freezes.
You should see what happens without jailhouse. If the hypervisor was
blocking any access to anything, it would tell you. So it might be that
it in fact has nothing to do with jailhouse.
> I'm able to reproduce it by launching and killing an application
> repeatedly. It hangs when launching, not when killing, so I'm
> thinking it could happen when trying to access an invalid memory
> region. Could be?
Unlikely because applications can not directly use physical memory.
Unless you have an application using "/dev/mem". In fact you can try a
dd of /dev/mem and break out ... i bet you would see a hypervisor
violation and not just a hang.
"dd if=/dev/mem of=/dev/null bs=1 count=1 seek="
> Sometimes it arrives quit easily, just after some launches but
> sometimes it can take several hours, more than 7000 launches ...
Sounds more like a memory leak or something, a memory leak would also
show quicker when running under jailhouse (with reduces memory).
I suggest to valgrind that application, or just keep an eye on "free"
as you re-launch. Regular applications should not be a problem, but say
that application re-loads a leaky kernel module ...
regards,
Henning
> I'm working with x86 Intl Atom E3950 hardware platforms. I'm
> attaching "/proc/iomem" and "memregions" from the config file, in
> case anyone can see something is wrong.
>
> Any hint on how to debug it or where should I focus on will be very
> welcome.
>
>
> /proc/Iomem:
>
> -0fff : Reserved
> 1000-0003efff : System RAM
> 0003f000-0003 : Reserved
> 0004-0009efff : System RAM
> 0009f000-000f : Reserved
> 000a-000b : PCI Bus :00
> 000c-000d : PCI Bus :00
> 000e-000f : PCI Bus :00
> 000f-000f : System ROM
> 0010-0fff : System RAM
> 1000-12150fff : Reserved
> 12151000-77874fff : System RAM
> 77875000-79994fff : Reserved
> 79995000-79a69fff : System RAM
> 79a6a000-79d8efff : ACPI Non-volatile Storage
> 79d8f000-7a1a9fff : Reserved
> 7a1aa000-7a1fbfff : Unknown E820 type
> 7a1fc000-7a569fff : System RAM
> 7a56a000-7a56afff : ACPI Non-volatile Storage
> 7a56b000-7a594fff : Reserved
> 7a595000-7aae5fff : System RAM
> 7aae6000-7aae7fff : Reserved
> 7aae8000-7aff : System RAM
> 7b00-7fff : Reserved
> 7b81-7bff : PCI Bus :00
> 7c01-7fff : PCI Bus :00
> 7c01-7ffe : Graphics Stolen Memory
> 8000-cfff : PCI Bus :00
> 8000-8fff : :00:02.0
> 9000-90ff : :00:02.0
> 9100-910f : :00:0e.0
> 9110-912f : PCI Bus :05
> 9110-911f : :05:00.0
> 9120-91203fff : :05:00.0
> 9130-914f : PCI Bus :03
> 9130-913f : :03:00.0
> 9140-91403fff : :03:00.0
> 9150-916f : PCI Bus :01
> 9150-915f : :01:00.0
> 9160-9160 : :01:00.0
> 9170-9170 : :00:15.0
> 9170-9170 : xhci-hcd
> 91708070-9170846f : intel_xhci_usb_sw
> 9171-91713fff : :00:0e.0
> 9171-91713fff : ICH HD audio
> 91714000-91715fff : :00:12.0
> 91714000-91715fff : ahci
> 91716000-917160ff : :00:1f.1
> 91717000-91717fff : :00:16.0
> 91718000-91718fff : :00:16.0
> 91719000-917197ff : :00:12.0
> 91719000-917197ff : ahci
> 9171a000-9171a0ff : :00:12.0
> 9171a000-9171a0ff : ahci
> 9171d000-9171dfff : :00:0f.0
> d000-d0ff : Reserved
> d0c0-d0c00653 : INT3452:03
> d0c4-d0c40763 : INT3452:01
> d0c5-d0c5076b : INT3452:00
> d0c7-d0c70673 : INT3452:02
> e000-efff : PCI MMCONFIG [bus 00-ff]
> e000-efff : Reserved
> e000-efff : PCI Bus :00
> e000-efff : pnp 00:05
> fe042000-fe044fff : Reserved
> fe90-fe902fff : Reserved
> fea0-feaf : pnp 00:05
> fec0-fec00fff : Reserved
> fec0-fec003ff : IOAPIC 0
> fed0-fed003ff : PNP0103:00
> fed01000-fed01fff : Reserved
> fed01000-fed01fff : pnp 00:05
> fed03000-fed03fff : pnp 00:05
> fed06000-fed06fff : pnp 00:05
> fed08000-fed09fff : pnp 00:05
> fed1c000-fed1cfff : pnp 00:05
> fed64000-fed64fff : dmar0
> fed65000-fed65fff : dmar1
> fed8-fedb : pnp 00:05
> fee0-fee00fff : Local APIC
> fee0-fee00fff : Reserved
> ff00- : Reserved
> 1-17fff : System RAM
> 17560-176603b86 : Kernel code
> 17680-176bacfff : Kernel rodata
> 176c0-176e919ff : Kernel data
> 17754e000-1775f : Kernel bss
>
>
> Config:
>
>.mem_regions = {
>
Re: Jailhouse cell linux
Am Mon, 1 Nov 2021 00:55:07 -0700 (PDT) schrieb Moustafa Nofal : > > > > >Might well be very little documentation on that. The code would be > > >under tools/jailhouse-cell-linux which might give a little more > > >insight on what it does and how. > > > > >And "./jailhouse-cell-linux --help" might help > > > Yes, it was necessary and very helpful. > > >Maybe start with the virtual qemu target, in which things should > >work. > >Not sure if that second linux will have its own uart there, but it > >should come up and be reachable via network a few secs after start. > I used vmlinux and rootfs.cpio from jailhouse-image to run a non-root > linux cell on RPi4(5.3 with compiled Jailhouse). Good to hear you made progress. > So the current > situation is: 1 CPU @ RootCell, 2 CPUs @non-root LinuxCell, and 1 CPU > @BareMetalCell. I have another problem regarding the network. the IP > was assigned, but the cell is accessible only with UART1, the cell > has an IP, but it cannot be reached.( Destination unreachable) when > pinged or ssh'ed. I attached 2 screenshots, just for the information. Not sure how you ended up assigning that IP (i do not look at screenshots). But i guess your network setup is that you have one physical NIC which still belongs to the root cell. And you have a virtual network with two jailhouse shmem network adapters going between your non-root and root-cell. An i further guess that the non-root cell got its IP via its kernel cmdline. To hook that up to the root-cell, the root-cell will need an IP from the same subnet. And that additional subnet should not overlap with the subnet your root-cell is already using on the physical NIC. That way you should eventually be able to "ping" and "ssh" between root and non-root. What you might want to do later would be to create a bridge on the root-cell, where you would attach the physical NIC and the jailhouse-NIC ... that would connect you non-root cell to your LAN and allow for DHCP and external communication. Nothing jailhouse specific really, simple Linux networking stuff. The only thing really needed is the jailhouse NIC driver on the root cell, i assume a new NIC appeared after your "jailhouse enable" ... Henning > Thanks for your support. > Regards, > Moustafa Noufale > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20211102095459.3a17440d%40md1za8fc.ad001.siemens.net.
Re: Jailhouse cell linux
Am Sun, 24 Oct 2021 23:26:06 -0700 (PDT) schrieb Moustafa Nofal : > I was not able to find a documentation about this jailhouse command > "Jailhouse cell linux" , what I understand it takes the following > arguments: > - linux configuration file .cell > - kernel image .img > - device tree file .dtb Might well be very little documentation on that. The code would be under tools/jailhouse-cell-linux which might give a little more insight on what it does and how. And "./jailhouse-cell-linux --help" might help. > -rootfs.cpio, It might be not clear to me, is it necessary to load > this file, how can it be built? As seen in --help that is an optional argument. That would be your root filesystem as cpio archive. But unless you have nfs or assign a mass storage device you will very likely want that. But rootfs could be embedded in the kernel as well. Easiest way to get one for your architecture is to take one generated by jailhouse-images. (where internally buildroot is used to generate a minimal demo-rootfs) > - console , baud rate and IP. things that would go on the kernel cmdline. Imagine the tool like a bootloader, it will need kernel, cmdline, possibly initrd (that cpio) and possible device tree. > Another question: I used Jailhouse-images and started a > linux-non-root-cell, but the UART terminal hangs at this point, is > there any solution for this. So, I tried to ping/SSH IP from another > terminal over LAN but it is unreachable. Maybe start with the virtual qemu target, in which things should work. Not sure if that second linux will have its own uart there, but it should come up and be reachable via network a few secs after start. regards, Henning > Thanks in advance > Moustafa Noufale > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20211025161715.61aa35fe%40md1za8fc.ad001.siemens.net.
Re: Building Jailhouse on STM32MP157A
Am Fri, 22 Oct 2021 02:45:44 -0700 (PDT) schrieb Andrea Marchetta : > Hi, i'm currently trying to use jailhouse on my stm32mp157a-dk1 kit > for a research project. My main concerns are the followings: > - first off, i've found the device tree for my board, but i'm > struggling to convert it to a suitable jailhouse config file. My > device tree is enormous, and thus i don't know which peripherals are > mandatory and which one could be skipped altogether Writing that initial config is cumbersome, unfortunately. You can check out existing examples and see how their device trees have been translated. It is an iterative process where you need to solve several issues until you have something working. Later could be hardening to remove bits that the root cell maybe should not be allowed to do anymore, once running under jailhouse. But the hypervisor will tell you about problems with reporting access violations, so the process could be called "guided". Maybe your research can be done on a board that is already supported. > - secondly, i'm not sure the linux distro i'll be using, which is the > openstlinux one, can work seamlessly with jailhouse > has anybody tried something similar? As far as i know Emtrion used > some STM chips with their boards jailhouse-compatible, but the > address mapping is completely different Jailhouse consists of a bunch of tools and a driver, plus the need to apply a bunch of kernel patches - or use the jailhouse kernel tree if your board is supported by mainline. That should not pose a problem for any distro. But again ... taking a problematic distro on a problematic board is not research, it is "BSP doing". For your research just take another board and i.e. jailhouse-images which will give you debian as distro. Or if your sponsor insists, you have to do the "BSP doing", which is not too bad but will cost. regards, 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20211022120341.5b77c9db%40md1za8fc.ad001.siemens.net.
Re: [PATCH] customizations: include wildcard into SRC_URI
Am Tue, 8 Jun 2021 07:28:19 +0200
schrieb Jan Kiszka :
> On 07.06.21 20:07, Henning Schild wrote:
> > That kind of tells bitbake that the file is "optional" and it will
> > not warn about it missing when parsing the recipes. It would find
> > it missing in the install task.
> >
> > That allows re-using jailhouse-images in projects that do not even
> > install the customizations package and would receive warnings when
> > not having a config for the package and their machine.
> >
> > Signed-off-by: Henning Schild
> > ---
> > recipes-core/customizations/customizations.bb | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/recipes-core/customizations/customizations.bb
> > b/recipes-core/customizations/customizations.bb index
> > f71a07887bed..c3a1fde01822 100644 ---
> > a/recipes-core/customizations/customizations.bb +++
> > b/recipes-core/customizations/customizations.bb @@ -20,7 +20,7 @@
> > DESCRIPTION = "demo image customizations"
> > SRC_URI = " \
> > file://postinst \
> > -file://.bash_history-${MACHINE} \
> > +file://.bash_history* \
> > file://e1000e-intx.conf \
> > file://ethernet \
> > file://ivshmem-net \
> >
>
> Taking this, just making it ".bash_history-*".
That sound like you do not want to be add that hypen and turn a second
round, Thanks.
Henning
>
> Thanks,
> 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/20210610164553.4755e741%40md1za8fc.ad001.siemens.net.
Re: [PATCH] customizations: include wildcard into SRC_URI
[jh-images]
passed a test where i did build qemu-amd64.
and another one where i integrated into a project as a layer, where
that warning disappeared
"WARNING:
/work/jailhouse-images/recipes-core/customizations/customizations.bb:
Unable to get checksum for customizations-siemens-ipc427e SRC_URI entry
.bash_history-siemens-ipc427e: file could not be found"
Henning
Am Mon, 7 Jun 2021 20:07:41 +0200
schrieb Henning Schild :
> That kind of tells bitbake that the file is "optional" and it will not
> warn about it missing when parsing the recipes. It would find it
> missing in the install task.
>
> That allows re-using jailhouse-images in projects that do not even
> install the customizations package and would receive warnings when not
> having a config for the package and their machine.
>
> Signed-off-by: Henning Schild
> ---
> recipes-core/customizations/customizations.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-core/customizations/customizations.bb
> b/recipes-core/customizations/customizations.bb index
> f71a07887bed..c3a1fde01822 100644 ---
> a/recipes-core/customizations/customizations.bb +++
> b/recipes-core/customizations/customizations.bb @@ -20,7 +20,7 @@
> DESCRIPTION = "demo image customizations"
> SRC_URI = " \
> file://postinst \
> -file://.bash_history-${MACHINE} \
> +file://.bash_history* \
> file://e1000e-intx.conf \
> file://ethernet \
> file://ivshmem-net \
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/20210607211303.708ad0c3%40md1za8fc.ad001.siemens.net.
[PATCH] customizations: include wildcard into SRC_URI
That kind of tells bitbake that the file is "optional" and it will not
warn about it missing when parsing the recipes. It would find it missing
in the install task.
That allows re-using jailhouse-images in projects that do not even
install the customizations package and would receive warnings when not
having a config for the package and their machine.
Signed-off-by: Henning Schild
---
recipes-core/customizations/customizations.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-core/customizations/customizations.bb
b/recipes-core/customizations/customizations.bb
index f71a07887bed..c3a1fde01822 100644
--- a/recipes-core/customizations/customizations.bb
+++ b/recipes-core/customizations/customizations.bb
@@ -20,7 +20,7 @@ DESCRIPTION = "demo image customizations"
SRC_URI = " \
file://postinst \
-file://.bash_history-${MACHINE} \
+file://.bash_history* \
file://e1000e-intx.conf \
file://ethernet \
file://ivshmem-net \
--
2.31.1
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/20210607180741.12416-1-henning.schild%40siemens.com.
Re: Installation error in Fedora
Am Tue, 18 May 2021 13:32:00 +0530 schrieb Prashant Kalikotay : > Hello All, > I am trying to install Jailhouse in Fedora, X86 system. > While running make I run into these errors: > [prashant@fedora jailhouse]$ make > CC [M] /home/prashant/jailhouse/driver/cell.o > CC [M] /home/prashant/jailhouse/driver/main.o > CC [M] /home/prashant/jailhouse/driver/sysfs.o > CC [M] /home/prashant/jailhouse/driver/pci.o > LD [M] /home/prashant/jailhouse/driver/jailhouse.o > CC /home/prashant/jailhouse/configs/x86/apic-demo.o > OBJCOPY /home/prashant/jailhouse/configs/x86/apic-demo.cell > CC /home/prashant/jailhouse/configs/x86/e1000-demo.o > OBJCOPY /home/prashant/jailhouse/configs/x86/e1000-demo.cell > CC /home/prashant/jailhouse/configs/x86/f2a88xm-hd3.o > OBJCOPY /home/prashant/jailhouse/configs/x86/f2a88xm-hd3.cell > CC /home/prashant/jailhouse/configs/x86/imb-a180.o > OBJCOPY /home/prashant/jailhouse/configs/x86/imb-a180.cell > CC /home/prashant/jailhouse/configs/x86/ioapic-demo.o > OBJCOPY /home/prashant/jailhouse/configs/x86/ioapic-demo.cell > CC /home/prashant/jailhouse/configs/x86/ivshmem-demo.o > OBJCOPY /home/prashant/jailhouse/configs/x86/ivshmem-demo.cell > CC /home/prashant/jailhouse/configs/x86/linux-x86-demo.o > OBJCOPY /home/prashant/jailhouse/configs/x86/linux-x86-demo.cell > CC /home/prashant/jailhouse/configs/x86/pci-demo.o > OBJCOPY /home/prashant/jailhouse/configs/x86/pci-demo.cell > CC /home/prashant/jailhouse/configs/x86/qemu-x86.o > OBJCOPY /home/prashant/jailhouse/configs/x86/qemu-x86.cell > CC /home/prashant/jailhouse/configs/x86/smp-demo.o > OBJCOPY /home/prashant/jailhouse/configs/x86/smp-demo.cell > CC /home/prashant/jailhouse/configs/x86/tiny-demo.o > OBJCOPY /home/prashant/jailhouse/configs/x86/tiny-demo.cell > CC /home/prashant/jailhouse/hypervisor/arch/x86/asm-defines.s > GEN > /home/prashant/jailhouse/hypervisor/arch/x86/include/generated/asm/asm-defines.h > CC /home/prashant/jailhouse/hypervisor/arch/x86/svm.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/amd_iommu.o > AS /home/prashant/jailhouse/hypervisor/arch/x86/svm-vmexit.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/apic.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/dbg-write.o > AS /home/prashant/jailhouse/hypervisor/arch/x86/entry.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/setup.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/control.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/mmio.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/iommu.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/paging.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/pci.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/i8042.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/vcpu.o > /home/prashant/jailhouse/hypervisor/arch/x86/vcpu.c: In function > ‘vcpu_reset’: > /home/prashant/jailhouse/hypervisor/arch/x86/vcpu.c:429:9: warning: > ‘memset’ offset [0, 127] is out of the bounds [0, 0] [-Warray-bounds] > 429 | memset(&cpu_data->guest_regs, 0, > sizeof(cpu_data->guest_regs)); > | > ^~ > CC /home/prashant/jailhouse/hypervisor/arch/x86/efifb.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/ivshmem.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/ioapic.o > AR /home/prashant/jailhouse/hypervisor/arch/x86/lib-amd.a > CC /home/prashant/jailhouse/hypervisor/arch/x86/vmx.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/vtd.o > AS /home/prashant/jailhouse/hypervisor/arch/x86/vmx-vmexit.o > CC /home/prashant/jailhouse/hypervisor/arch/x86/cat.o > AR /home/prashant/jailhouse/hypervisor/arch/x86/lib-intel.a > LDS /home/prashant/jailhouse/hypervisor/hypervisor.lds > CC /home/prashant/jailhouse/hypervisor/setup.o > CC /home/prashant/jailhouse/hypervisor/printk.o > CC /home/prashant/jailhouse/hypervisor/paging.o > CC /home/prashant/jailhouse/hypervisor/control.o > CC /home/prashant/jailhouse/hypervisor/lib.o > CC /home/prashant/jailhouse/hypervisor/mmio.o > CC /home/prashant/jailhouse/hypervisor/pci.o > CC /home/prashant/jailhouse/hypervisor/ivshmem.o > CC /home/prashant/jailhouse/hypervisor/uart.o > CC /home/prashant/jailhouse/hypervisor/uart-8250.o > LD /home/prashant/jailhouse/hypervisor/hypervisor-amd.o > OBJCOPY /home/prashant/jailhouse/hypervisor/jailhouse-amd.bin > LD /home/prashant/jailhouse/hypervisor/hypervisor-intel.o > OBJCOPY /home/prashant/jailhouse/hypervisor/jailhouse-intel.bin > CC /home/prashant/jailhouse/inmates/lib/x86/../alloc.o > CC /home/prashant/jailhouse/inmates/lib/x86/../cmdline.o > CC /home/prashant/jailho
Re: Windows on Jailhouse
Am Mon, 10 May 2021 17:24:25 +0200 schrieb Ralf Ramsauer : > Hi Bram, > > On 10/05/2021 16:19, Bram Hooimeijer wrote: > > Dear Jailhouse community, > > > > Is there anyone who has tried to get Windows running in a Jailhouse > > cell? > > > > Given that Windows is often used as HMI, it would be interesting to > > see whether it would be possible to use it alongside Jailhouse. > > > > What are the fundamental limitations one would run into? > > You MUST emulate every trap that Windows would cause, as you have no > chance to adjust Windows, as we can do it with Linux. And Windows > 'expects' a certain defined environment to be present at boot, such as > ACPI / Bios / EFI. But we arrive in Jailhouse with in a void > environment. E.g., there's no regular hardware discovery available for > platform devices. The most realistic way would be to bring nested virtualization to jailhouse, which would enable kvm on the root-cell. I think Jan has once started that but it never reached a merge-point into jailhouse. Not too many people seem to care, and it would probably increase the complexity of jailhouse significantly ... maybe to a point where a working implementation would still not get merged. You can most likely run Windows in qemu, performance might be "not acceptable". There is "llvm-qemu" to maybe mitigate that to some degree, but i am not sure that is still in the research state or "ready for a product". And then there is wine, or choosing QT/GTK for your HMI ... if you can. I guess QT for HMI is the best way, but you might already have an HMI which might not be QT ... regards, Henning > I could rather imagine to run Windows in the root-cell rather than in > a non-root cell. But that would require to port the driver to Windows > and is probably combined with a huge amount of pain. And who knows > what Windows is doing with your platform while it is running… > > Maybe there's a better chance with Windows for ARM, but I never looked > into that. > > Ralf > > > > > Thanks, > > > > Best regards, Bram Hooimeijer > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20210510194902.40fc1ff9%40md1za8fc.ad001.siemens.net.
Re: Can Jailhouse work with CentOS
There is no reason for "sudo" for a simple "make". It is likely you are missing kernel sources, or tools that the build process needs. Or - given that distro - things are outdated. Jailhouse does not need much, but also centos does not offer much ;) try a fresh clone, no "sudo", "make V=1 -j1" Henning Am Sat, 8 May 2021 11:19:01 +0530 schrieb Prashant Kalikotay : > Thank you so much for your reply. While my installation I run sudo > make and that fails with the error : /path/to/build no such file or > directory is present. I checked the path/to/build and it exists and i > have also given superuser privileges to the user. > Could anyone get me anything on this. I am using CentOS 8. > > Regards, > Prashant K > > On Fri, 7 May 2021, 14:37 Bram Hooimeijer, < > bram.hooimei...@prodrive-technologies.com> wrote: > > > > > > Dear Sir/Madam, > > > > > > I am trying to install jailhouse in > > > CentOS > > but the installation did > > > not work or it did not get installed. Whereas when I tried to > > > install in > > Ubuntu > > > it readily installed. My query is does Jailhouse install in > > > CentOS or is > > there any > > > additional things to be done to install it?. > > > > What errors do you get? Maybe there's someone on the list who > > encountered those before. > > > > As far as I know, Jailhouse should run given that the kernel is > > properly configured. > > For newer Linux kernels, you might need some patches: > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.kiszka.org%2F%3Fp%3Dlinux.git%3Ba%3Dsummary&data=04%7C01%7Cde173c00-e982-4fda-8644-47edf4671d63%40ad011.siemens.com%7C0e6b87ebf9ab493372b708d911e504e8%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637560497853991126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ppGRrGseipDA4Jlu%2BQkvXdFOCw5RKP8P6Y2LD6Nh4iY%3D&reserved=0 > > I have it running with minimal modifications on Linux 5.4 > > > > Best, Bram Hooimeijer > > > > > > > > > > Thanking you in advance. > > > > > > > > > Regards, > > > > > > Prashant K > > > > > > -- > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20210510123616.15344255%40md1za8fc.ad001.siemens.net.
Re: HELP
Am Sun, 28 Mar 2021 22:16:14 +0800 (GMT+08:00) schrieb 曹宏鹏 : > Dear sir: > > As we all know, the cell could communicate with root cell by ivshmem > in Jailhouse. And there is a virtual Network Interface Card(NIC) on > non-root cell. When I run Jailhouse on my raspberry Pi 4 model b, I > was successful to create a cell and assigned a address to it. The > root cell can communicate with non-root cell , I know this is based > on ivshmem. But I want to know > > 1. Whether the virtual NIC support other protocols. It is a virtual ethernet connection, on top you can use anything that can be done on top of "network". It is probably best to build whatever you need on top of Ethernet, maybe nfs, remote desktop ... but if you really need a custom protocol at the base you can write your own driver and choose another ".shmem_protocol" There is ivshmem-demo giving a simple raw usage example of JAILHOUSE_SHMEM_PROTO_UNDEFINED. > 2. What is difference between virtual NIC in non-root cell and NIC in > root cell. There is none. Once running under jailhouse a cell might see the PCI device for shared memory communication on the bus (depending on the cell config). If that PCI device is of type JAILHOUSE_SHMEM_PROTO_VETH and the cell has a driver ... you will see a new ethernet interface becoming available. > 3. Why the virtual NIC cannot ping baidu.com(in China ) or > google.com. You essentially have an isolated network between the two cells. To connect the inmate to the internet, the root cell will have to become a network router. So you would set up i.e. NAT to connect on layer3 The most simple solution could be to create a network bridge where you attach the real physical network interface and later the virtual one. (in the root cell) After doing that the non-root should be in the same Layer2 network and can use DHCP to get a network configuration that will allow internet access just like the root-cell has. All that is basic networking and has nothing to do with jailhouse. regards, Henning > If I get your help, I will appreciate ！ > > > Yours sincerely, > HOngpeng Cao. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20210329104747.2f396831%40md1za8fc.ad001.siemens.net.
Re: Invalid PCI config write, port cfc, size 1, address port: 8000f940
Am Tue, 23 Feb 2021 14:26:32 +
schrieb Raimundo Sagarzazu :
> Yes, I was trying it and it seems that it works.
Tight ... chicken ;)
Henning
> Thankyou,
>
> Rai.
>
> De: jailhouse-dev@googlegroups.com
> En nombre de Jan Kiszka Enviado el: martes, 23 de febrero de 2021
> 14:21 Para: Raimundo Sagarzazu ;
> jailhouse-dev@googlegroups.com Asunto: Re: Invalid PCI config write,
> port cfc, size 1, address port: 8000f940
>
> On 22.02.21 09:27, Raimundo Sagarzazu wrote:
> Hi all,
>
> I'm trying to give SMbus access to an inmate cell but the system
> hangs on this error: “Invalid PCI config write, port cfc, size 1,
> address port: 8000f940” when I try to load the cell.
>
> It’s a x86 host and we already have jailhouse running with two inmate
> cells giving access to net devices, sharing memory, etc.
>
> From "lspci", I have:
>
> 00:1f.1 SMBus: Intel Corporation Celeron N3350/Pentium
> N4200/Atom E3900 Series SMBus Controller (rev 0b) DeviceName: Onboard
> - Other Subsystem: Intel Corporation Device 7270
> Flags: medium devsel, IRQ 20
> Memory at 91616000 (64-bit,
> non-prefetchable) [size=256] I/O ports at f040 [size=32]
> Kernel driver in use: i801_smbus
>
> From "jailhouse config create ...":
>
> /* MemRegion: 91516000-915160ff : :00:1f.1 */
> {
> .phys_start = 0x91516000,
> .virt_start = 0x91516000,
> .size = 0x1000,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE, },
> ...
> /* Port I/O: f040-f05f : :00:1f.1 */
> PIO_RANGE(0xf040, 0x20),
> ...
> /* PCIDevice: 00:1f.1 */
> {
> .type = JAILHOUSE_PCI_TYPE_DEVICE,
> .iommu = 1,
> .domain = 0x0,
> .bdf = 0xf9,
> .bar_mask = {
> 0xff00, 0x,
> 0x, 0x, 0xffe0, 0x,
> },
> .caps_start = 0,
> .num_caps = 0,
> .num_msi_vectors = 0,
> .msi_64bits = 0,
> .msi_maskable = 0,
> .num_msix_vectors = 0,
> .msix_region_size = 0x0,
> .msix_address = 0x0,
> },
>
> First thing I can see is that lspci shows that device's memory region
> is: Memory at 91616000 (64-bit, non-prefetchable) [size=256]
>
> While "jailhouse config create ..." shows:
> MemRegion: 91516000-915160ff : :00:1f.1
>
> Is that correct?
>
> Anyway, digging in the code I can see that the error comes on
> "hypervisor/pci.c, pci_cfg_write_moderate() ...", when trying to
> access address 0x40 but device has no capabilities.
>
> Giving access to this device is not a big issue for us because we can
> share "/dev/i2c-0" status over IVshmem but I'd like to known if
> there's something else I can do or it just can't be done.
>
>
> This config space register might be a side-band register. You could
> permit access by modelling it like a capability, ie. create one at
> 0x04 of the needed size (at least 1 byte) and with write permissions.
> Cap ID can be 0 or anything else invalid.
>
> Jan
>
>
> --
>
> Siemens AG, T RDA IOT
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jailhouse-dev/0d6ec3fd-adf2-d54e-57c9-99244f280538%40siemens.com.
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/20210312212232.19511dbd%40md1za8fc.ad001.siemens.net.
Re: [EXT] Re: [PATCH v1 0/3] Jailhouse: Add DPAA support for NXP ls1043ardb platform
Am Thu, 4 Feb 2021 02:33:20 + schrieb Hongbo Wang : > > > .../dts/inmate-ls1043a-rdb-fman-ucode.dtsi| 1030 > > + > > > configs/arm64/dts/inmate-ls1043a-rdb.dts | 767 +++- > > > configs/arm64/ls1043a-rdb-linux-demo.c| 57 +- > > > 3 files changed, 1843 insertions(+), 11 deletions(-) create mode > > > 100644 configs/arm64/dts/inmate-ls1043a-rdb-fman-ucode.dtsi > > > > > > > What exactly will that allow the non-root cell to do? Own the DPAA > > completely (taking it from the root cell)? Or does this enable > > sharing (and then only in a cooperative way, due to architectural > > limitations of the DPAAv1)? > > there are some case that user want to non-root cell can connect > ethernet and cloud via DPAA1 port, and test their performance, so we > plan to add DPAAv1 support in jailhouse. > > in this patch set, all DPAA ports are owned by non-root cell, root > cell don't connect ethernet directly via DPAA. Radu-andrei Bulie already has a setup where root and non-root can share DPAA1 in a cooperative way. That depends on driver changes in Linux but in the end is much more powerful than what is proposed here. But it also has nasty implications on isolation between the cells. Handing all of DPAA1 to non-root is an extreme case, next to leaving all in root. While "something in the middle" seems way more useful/flexible and it would be a shame to just go for the extremes. I assume that people will want that sharing eventually, so it should be considered already to see how it fits on the second "extreme" that is proposed here. Henning > > thanks, > hongbo > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20210206122300.09b3711c%40md1za8fc.ad001.siemens.net.
Re: ivshmem-net issue
On Thu, 28 Jan 2021 07:03:51 +
Peng Fan wrote:
> > Subject: Re: ivshmem-net issue
> >
> > On Thu, 28 Jan 2021 01:28:32 +
> > Peng Fan wrote:
> >
> > > > Subject: Re: ivshmem-net issue
> > > >
> > > > On Wed, 27 Jan 2021 09:08:28 +
> > > > Peng Fan wrote:
> > > >
> > > > > Hi Jan,
> > > > >
> > > > > When booting inmate Linux, I have ivshmem-net configured. In
> > > > > root cell it shows as eth2.
> > > > >
> > > > > I monitor system network, and see eth2 is assigned a random
> > > > > address.
> > > >
> > > > This is not "random", this is where some dhcp-clients end up
> > > > when they do not receive an answer to their requests. It is a
> > > > fallback when there is no proper DHCP server and machines still
> > > > want to gain an address to potentially communicate. (zeroconf
> > > > APIPA)
> > > >
> > > > So it is worth checking the DHCP server to see why it did not
> > > > hand out an IP. Maybe because of the random MAC that Jan talked
> > > > about.
> > >
> > > What do you mean DHCP server here? The eth2 is created by
> > > ivshmem-net, it has no physical connection.
> >
> > Well if you do not have a DHCP server in the other cell, you
> > probably should not be running a DHCP client. And looking at the
> > address you are running one. You probably do the whole setup on the
> > kernel cmdline and that works until userspace goes and configures
> > that interface as well ... again. You have to tell userspace that
> > this one interface is off limits and already configured. How to do
> > that depends an what is doing that, probably nm or systemd.
>
> But seems we are not able to differentiate the ivshmem-net created
> eth2 and the physical interface eth1?
You can do that by name. And if that is not stable enough you can do it
i.e. by driver or vendor. Maybe with an udev rule. For starters just
disable nm or systemd-networkd entirely and bring up that physical
interface manually.
On the kernel cmdline you can specify an interface name for your nfs
ip, in case the kernel picks the wrong device.
Taken from an NXP ls1043 lab setup of mine
root=/dev/nfs ip=${ipaddr}:::${netmask}:${hostname}:eth0
nfsroot=${serverip}:/srv/nfs/boards/${hostname}yocto,v3,tcp
Notice the ":eth0" at the end of "ip=".
https://elixir.bootlin.com/linux/latest/source/Documentation/admin-guide/nfs/nfsroot.rst#L88
regards,
Henning
> Thanks,
> Peng.
>
> >
> > Henning
> >
> > > Thanks,
> > > Peng.
> > >
> > > Or maybe that
> > > > MAC was taken and the client did not have a valid lease for it.
> > > >
> > > > Henning
> > > >
> > > > > [ADDR]4: eth2inet 169.254.232.89/16 brd 169.254.255.255
> > > > > scope global eth2 valid_lft forever preferred_lft forever
> > > > > [ROUTE]local 169.254.232.89 dev eth2 table local proto kernel
> > > > > scope host src 169.254.232.89 [ROUTE]broadcast
> > > > > 169.254.255.255 dev eth2 table local proto kernel scope link
> > > > > src 169.254.232.89 [ROUTE]169.254.0.0/16 dev eth2 proto
> > > > > kernel scope link src 169.254.232.89 [ROUTE]broadcast
> > > > > 169.254.0.0 dev eth2 table local proto kernel scope link src
> > > > > 169.254.232.89 [ROUTE]default dev eth2 scope link
> > > > >
> > > > >
> > > > > And also in route table, it added two entries going through
> > > > > eth2, I not understand why it will add one entry that default
> > > > > use eth2 with gateway 0.0.0.0 #route Kernel IP routing table
> > > > > Destination Gateway Genmask Flags Metric
> > Ref
> > > > > Use Iface default 0.0.0.0 0.0.0.0 U
> > 0
> > > > > 00 eth2 default _gateway0.0.0.0
> > > > UG
> > > > > 0 00 eth1 10.193.102.00.0.0.0
> > > > 255.255.255.0
> > > > > U 0 00 eth1 169.254.0.0 0.0.0.0
> > > > > 255.255.0.0 U 0 00 eth2
> > > > >
> > > > > It added the eth2 route table and will break nfsroot if we
> > > > > using 10.193.108.x for nfsroot server, because it will match
> > > > > the 1st entry.
> > > > >
> > > > > This is not jailhouse hypervisor issue, I just not sure the
> > > > > eth2 behavior, it is systemd does that route change or we
> > > > > need look into ivshmem-net to avoid update route table when
> > > > > creating eth2?
> > > > >
> > > > > Thanks,
> > > > > Peng.
> > > > >
> > > > >
> > >
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/20210128120507.7d719105%40md1za8fc.ad001.siemens.net.
Re: ivshmem-net issue
On Thu, 28 Jan 2021 01:28:32 + Peng Fan wrote: > > Subject: Re: ivshmem-net issue > > > > On Wed, 27 Jan 2021 09:08:28 + > > Peng Fan wrote: > > > > > Hi Jan, > > > > > > When booting inmate Linux, I have ivshmem-net configured. In root > > > cell it shows as eth2. > > > > > > I monitor system network, and see eth2 is assigned a random > > > address. > > > > This is not "random", this is where some dhcp-clients end up when > > they do not receive an answer to their requests. It is a fallback > > when there is no proper DHCP server and machines still want to gain > > an address to potentially communicate. (zeroconf APIPA) > > > > So it is worth checking the DHCP server to see why it did not hand > > out an IP. Maybe because of the random MAC that Jan talked about. > > What do you mean DHCP server here? The eth2 is created by ivshmem-net, > it has no physical connection. Well if you do not have a DHCP server in the other cell, you probably should not be running a DHCP client. And looking at the address you are running one. You probably do the whole setup on the kernel cmdline and that works until userspace goes and configures that interface as well ... again. You have to tell userspace that this one interface is off limits and already configured. How to do that depends an what is doing that, probably nm or systemd. Henning > Thanks, > Peng. > > Or maybe that > > MAC was taken and the client did not have a valid lease for it. > > > > Henning > > > > > [ADDR]4: eth2inet 169.254.232.89/16 brd 169.254.255.255 scope > > > global eth2 valid_lft forever preferred_lft forever [ROUTE]local > > > 169.254.232.89 dev eth2 table local proto kernel scope host src > > > 169.254.232.89 [ROUTE]broadcast 169.254.255.255 dev eth2 table > > > local proto kernel scope link src 169.254.232.89 > > > [ROUTE]169.254.0.0/16 dev eth2 proto kernel scope link src > > > 169.254.232.89 [ROUTE]broadcast 169.254.0.0 dev eth2 table local > > > proto kernel scope link src 169.254.232.89 [ROUTE]default dev > > > eth2 scope link > > > > > > > > > And also in route table, it added two entries going through eth2, > > > I not understand why it will add one entry that default use eth2 > > > with gateway 0.0.0.0 #route Kernel IP routing table > > > Destination Gateway Genmask Flags Metric Ref > > > Use Iface default 0.0.0.0 0.0.0.0 U 0 > > > 00 eth2 default _gateway0.0.0.0 > > UG > > > 0 00 eth1 10.193.102.00.0.0.0 > > 255.255.255.0 > > > U 0 00 eth1 169.254.0.0 0.0.0.0 > > > 255.255.0.0 U 0 00 eth2 > > > > > > It added the eth2 route table and will break nfsroot if we using > > > 10.193.108.x for nfsroot server, because it will match the 1st > > > entry. > > > > > > This is not jailhouse hypervisor issue, I just not sure the eth2 > > > behavior, it is systemd does that route change or we need look > > > into ivshmem-net to avoid update route table when creating eth2? > > > > > > Thanks, > > > Peng. > > > > > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20210128075935.648f6522%40md1za8fc.ad001.siemens.net.
Re: ivshmem-net issue
On Wed, 27 Jan 2021 09:08:28 + Peng Fan wrote: > Hi Jan, > > When booting inmate Linux, I have ivshmem-net configured. In root > cell it shows as eth2. > > I monitor system network, and see eth2 is assigned a random address. This is not "random", this is where some dhcp-clients end up when they do not receive an answer to their requests. It is a fallback when there is no proper DHCP server and machines still want to gain an address to potentially communicate. (zeroconf APIPA) So it is worth checking the DHCP server to see why it did not hand out an IP. Maybe because of the random MAC that Jan talked about. Or maybe that MAC was taken and the client did not have a valid lease for it. Henning > [ADDR]4: eth2inet 169.254.232.89/16 brd 169.254.255.255 scope > global eth2 valid_lft forever preferred_lft forever > [ROUTE]local 169.254.232.89 dev eth2 table local proto kernel scope > host src 169.254.232.89 [ROUTE]broadcast 169.254.255.255 dev eth2 > table local proto kernel scope link src 169.254.232.89 > [ROUTE]169.254.0.0/16 dev eth2 proto kernel scope link src > 169.254.232.89 [ROUTE]broadcast 169.254.0.0 dev eth2 table local > proto kernel scope link src 169.254.232.89 [ROUTE]default dev eth2 > scope link > > > And also in route table, it added two entries going through eth2, I > not understand why it will add one entry that default use eth2 with > gateway 0.0.0.0 #route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref > Use Iface default 0.0.0.0 0.0.0.0 U 0 > 00 eth2 default _gateway0.0.0.0 UG > 0 00 eth1 10.193.102.00.0.0.0 255.255.255.0 > U 0 00 eth1 169.254.0.0 0.0.0.0 > 255.255.0.0 U 0 00 eth2 > > It added the eth2 route table and will break nfsroot if we using > 10.193.108.x for nfsroot server, because it will match the 1st entry. > > This is not jailhouse hypervisor issue, I just not sure the eth2 > behavior, it is systemd does that route change or we need look into > ivshmem-net to avoid update route table when creating eth2? > > Thanks, > Peng. > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20210127195845.348673a3%40md1za8fc.ad001.siemens.net.
Re: License of custom cell configs
On Wed, 8 Jul 2020 22:35:58 +0900 Yang Chung Fan wrote: > Hi, > > Thank you for your quick response. > > I think BSD is good for our situation. > I will stick to that. > > A follow up question, > I am porting the linux ivshmem_net driver to an RTOS and want to > distribute it with the RTOS source. > At the end of the day, I want to have it PRed and included in > upstream. However as the ivshmem_net linux driver is licensed as GPL > v2 and the RTOS is Apache v2. They don't get along too well. I am not sure a re-licensing is possible or feasible here. The driver is a Linux driver and therefore needs to be GPL. Adding a second license would probably require a sort of split, separating a dual-license core from an OS-glue. Making that split generic and maintaining the driver for multiple OSs would be hard. In fact i wrote several such drivers for our products, turns our that the re-usable "core" is not that big. And different coding style, device driver frameworks, or network-stacks reduce the reuse potential further. While reuse sounds good, the pragmatic answer seems to be to fully rewrite the driver for every new OS. You should get in touch with that project early, maybe they already have something ... regards, Henning > I would kindly ask that is there any possibility to have a more > permissive license on that driver, just like those in the inmate > library? > > BR, > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20200708162421.56e41496%40md1za8fc.ad001.siemens.net.
Re: License of custom cell configs
Hi, On Wed, 8 Jul 2020 04:49:38 -0700 (PDT) Chung-Fan Yang wrote: > Hi, > > I want to ask a silly question. Not silly, valid! > Is there any restrictions on the cell configs source files, including > those hand crafted and these generated by jailhouse command line tool > ? Kind of, you basically can choose between GPLv2 and BSD. > For a hand crafted configs, may I distributed them with the licenses > as I wish? You will very likely have to include a header that imposes one of the two mentioned above. > On the other hand for generated configs, I noticed that they have BSD > headers, so I must comply and following that, right? I guess you could write the header yourself if you really did want to choose your own license. And even then ... the format is well defined so it is pretty clear what the config source says from just looking at the binary. So if you plan to protect something ... say IP. You might be able to do that with the syntax but not the semantics. Henning > BR, > > Yang. > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20200708152531.25e804b0%40md1za8fc.ad001.siemens.net.
Re: jailhouse-config-create: creates many overlapping memory regions
Am Fri, 19 Jun 2020 13:22:12 +0200 schrieb "[ext] Jan Kiszka" : > On 19.06.20 13:08, contact@gmail.com wrote: > > This issue may be in the works / known -- just to add another > > example. > > > > On the this x86 box (Edge Up-Squared, similar device class like the > > existing nuc6cay), jailhouse-config-create finds ~100 memory > > regions, of which many overlap and most probably are irrelevant to > > actual use. jailhouse-config-check coughs them up again. > > Yes, the sysconfig parser has a problem with sub-page memory regions. > Unfortunately, this usually requires manual cleanup (generally a > consolidation of most sub-page resources). Is there anything that can be done about this or does the source of the information simply not contain enough detail to fix this? /proc/iomem ? Maybe in its different versions with different kernels? Henning > > > > Apart from this uncomfort, just for understanding: > > > > What happens to resources *not* mentioned in the system-config? Do > > they stay with the root-cell or become completely unavailable? > > The latter. Jailhouse denies access to everything not explicitly > permitted. > > > > > In theory, how would I make a resource inaccessible to the root-cell > > (but available to non-root)? > > By listing it in the non-root cell. If it was listed in root as well, > cell creation will take it away from there. If it wasn't listed, the > root cell will not have access at all (as long as Jailhouse is up). > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20200625215735.12848c5d%40md1za8fc.ad001.siemens.net.
Re: [PATCH V2 1/2] Cell configs for imx8mq EVK board.
On Thu, 26 Mar 2020 21:20:24 +0800
Alice Guo wrote:
> Signed-off-by: Alice Guo
> ---
> configs/arm64/imx8mq-inmate-demo.c | 70 +++--
> configs/arm64/imx8mq-linux-demo.c | 158
> + configs/arm64/imx8mq.c |
> 93 +++-- 3 files changed, 307 insertions(+), 14
> deletions(-) create mode 100644 configs/arm64/imx8mq-linux-demo.c
>
> diff --git a/configs/arm64/imx8mq-inmate-demo.c
> b/configs/arm64/imx8mq-inmate-demo.c index 8c1ad624..d3c89aec 100644
> --- a/configs/arm64/imx8mq-inmate-demo.c
> +++ b/configs/arm64/imx8mq-inmate-demo.c
> @@ -1,7 +1,7 @@
> /*
> * iMX8MQ target - inmate demo
> *
> - * Copyright NXP 2018
> + * Copyright 2018-2019 NXP
Maybe even 2020? And that is the only update to the several files you
touch, maybe do them all.
Henning
> *
> * Authors:
> * Peng Fan
> @@ -16,7 +16,9 @@
> struct {
> struct jailhouse_cell_desc cell;
> __u64 cpus[1];
> - struct jailhouse_memory mem_regions[3];
> + struct jailhouse_memory mem_regions[8];
> + struct jailhouse_irqchip irqchips[1];
> + struct jailhouse_pci_device pci_devices[1];
> } __attribute__((packed)) config = {
> .cell = {
> .signature = JAILHOUSE_CELL_DESC_SIGNATURE,
> @@ -26,8 +28,9 @@ struct {
>
> .cpu_set_size = sizeof(config.cpus),
> .num_memory_regions = ARRAY_SIZE(config.mem_regions),
> - .num_irqchips = 0,
> - .num_pci_devices = 0,
> + .num_irqchips = ARRAY_SIZE(config.irqchips),
> + .num_pci_devices = ARRAY_SIZE(config.pci_devices),
> + .vpci_irq_base = 108,
>
> .console = {
> .address = 0x3086,
> @@ -42,6 +45,38 @@ struct {
> },
>
> .mem_regions = {
> + /* IVHSMEM shared memory region for 00:00.0 */ {
> + .phys_start = 0xbfd0,
> + .virt_start = 0xbfd0,
> + .size = 0x1000,
> + .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_ROOTSHARED,
> + },
> + {
> + .phys_start = 0xbfd01000,
> + .virt_start = 0xbfd01000,
> + .size = 0x9000,
> + .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE |
> + JAILHOUSE_MEM_ROOTSHARED,
> + },
> + {
> + .phys_start = 0xbfd0a000,
> + .virt_start = 0xbfd0a000,
> + .size = 0x2000,
> + .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_ROOTSHARED,
> + },
> + {
> + .phys_start = 0xbfd0c000,
> + .virt_start = 0xbfd0c000,
> + .size = 0x2000,
> + .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE |
> + JAILHOUSE_MEM_ROOTSHARED,
> + },
> + {
> + .phys_start = 0xbfd0e000,
> + .virt_start = 0xbfd0e000,
> + .size = 0x2000,
> + .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_ROOTSHARED,
> + },
> /* UART1 */ {
> .phys_start = 0x3086,
> .virt_start = 0x3086,
> @@ -50,7 +85,7 @@ struct {
> JAILHOUSE_MEM_IO |
> JAILHOUSE_MEM_ROOTSHARED, },
> /* RAM: Top at 4GB Space */ {
> - .phys_start = 0xffaf,
> + .phys_start = 0xc000,
> .virt_start = 0,
> .size = 0x0001,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | @@ -62,5 +97,28 @@ struct {
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_COMM_REGION,
> },
> - }
> + },
> +
> + .irqchips = {
> + /* GIC */ {
> + .address = 0x3880,
> + .pin_base = 128,
> + .pin_bitmap = {
> + 0x1 << (108 + 32 - 128) /* SPI 109 */
> + },
> + },
> + },
> +
> + .pci_devices = {
> + { /* IVSHMEM 00:00.0 (demo) */
> + .type = JAILHOUSE_PCI_TYPE_IVSHMEM,
> + .domain = 1,
> + .bdf = 0 << 3,
> + .bar_mask = JAILHOUSE_IVSHMEM_BAR_MASK_INTX,
> + .shmem_regions_start = 0,
> + .shmem_dev_id = 1,
> + .shmem_peers = 1,
> + .shmem_protocol =
> JAILHOUSE_SHMEM_PROTO_UNDEFINED,
> + },
> + },
> };
> diff --git a/configs/arm64/imx8mq-linux-demo.c
> b/configs/arm64/imx8mq-linux-demo.c new file mode 100644
> index ..a59dd934
> --- /dev/null
> +++ b/configs/arm64
Re: Difference in execution duration between root cell and inmate for same code
Hi Michael, thanks for sharing that with us. Maybe the whole story points to a gap in the docs? In that case please let us know how to improve them, otherwise happy hacking! Henning On Fri, 14 Feb 2020 13:12:51 -0800 Michael Hinton wrote: > Thanks for all the help. I just want to give an update and mention > that I also changed the (old) IVSHMEM code to do MAP_CACHED. It's now > just as fast as my other MAP_CACHED memory region and is working > great! -Michael > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/2020021424.7b141d64%40md1za8fc.ad001.siemens.net.
Re: Difference in execution duration between root cell and inmate for same code
Am Thu, 6 Feb 2020 11:00:29 -0800
schrieb Michael Hinton :
> Hi Henning,
>
> On Monday, January 27, 2020 at 12:16:08 AM UTC-7, Henning Schild
> wrote:
> >
> > Ok, so we are just looking for differences between the inmate and
> > the linux as non-root cell, because the jailhouse/virtualization
> > overhead is acceptable or known.
> >
> I'm sorry, I was confused. That is actually not correct. I am looking
> for the difference between the inmate running my simple workload vs.
> running that same workload in the *root cell* rather than in a
> non-root Linux cell. What I am doing is activating the root cell,
In that case the baseline would really have been try a non-root Linux
first and forget all the pagetable/huge-page etc. micro-optimizations ;)
But from what i read, you have your solution and going shmem with it
should work as well. Let us see ;)
Henning
> then simply running the workload in Linux with a wrapper program
> (sha3-512.c
> <https://github.com/hintron/jailhouse/blob/05824b901ce714c7a61770774b862ef24caf641e/mgh/workloads/src/sha3-512.c>).
> Then, I activate my inmate and run the same workload, but this time
> within the inmate in a real-time wrapper application (mgh-demo.c
> <https://github.com/hintron/jailhouse/blob/05824b901ce714c7a61770774b862ef24caf641e/inmates/demos/x86/mgh-demo.c>).
> Both wrapper applications now use the exact same object file,
> compiled once under the Jailhouse build system. But the results are
> still the same.
>
> However, the input used by the program in the inmate is in a special
> 'add-on' memory region I had to create and map manually with
> map_range().
>
> Here is the additional memory region in my config that I named the
> 'heap' (I need it big enough to hold a 20 MiB+ data input):
>
> /* MGH: RAM - Heap */
> {
> /* MGH: We have 36 MB of memory allocated to the inmate
> * in the root config, but are only using 1 MB for the
> * inmate's stack and program. So create an additional
> * "heap" area with the other 35 MB to allow the program
> * more memory to work with. */
> .phys_start = 0x3a70,
> .virt_start = 0x0020,
> // 35 MB (3a7 + 23 = 3ca)
> .size = 0x0230,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_LOADABLE,
> },
>
> https://github.com/hintron/jailhouse/blob/05824b901ce714c7a61770774b862ef24caf641e/configs/x86/bazooka-inmate.c#L90-L103
>
> I am able to map that large 35 MiB memory region into my inmate, and
> it works ok:
>
> #define MGH_HEAP_BASE 0x0020
> #define MGH_HEAP_SIZE (35 * MB)
> ...
> /*
> * MGH: By default, x86 inmates only map the first 2 MB of virtual
> memory, even
> * when more memory is configured. So map configured memory pages
> behind the
> * virtual memory address MGH_HEAP_BASE. Without this, there is
> nothing behind
> * the virtual memory address and you'll get a page fault.
> */
> static void expand_memory(void)
> {
> map_range((char *)MGH_HEAP_BASE, MGH_HEAP_SIZE, MAP_UNCACHED);
>
> /* Set heap_pos to point to MGH_HEAP_BASE, instead of right after the
> * inmate's stack, so alloc() can allocate more than 1 MB. */
> heap_pos = MGH_HEAP_BASE;
> }
>
> https://github.com/hintron/jailhouse/blob/05824b901ce714c7a61770774b862ef24caf641e/inmates/demos/x86/mgh-demo.c#L113-L114
> https://github.com/hintron/jailhouse/blob/05824b901ce714c7a61770774b862ef24caf641e/inmates/demos/x86/mgh-demo.c#L930-L943
> .
>
> I have tried using both my 'heap' memory region (with
> programmatically-generated input) as well as using input passed into
> the IVSHMEM shared memory region
> <https://github.com/hintron/jailhouse/blob/05824b901ce714c7a61770774b862ef24caf641e/configs/x86/bazooka-inmate.c#L79-L89>,
>
> with the same results.
>
> Maybe there is something wrong with the memory paging that is making
> things a lot slower than expected, like you implied. Maybe regular
> Linux has a faster way of setting up paging/memory.
>
> In your last response, you said this:
>
> "For the inmate itself the pagetable is constructed by the mapping
> library. The code looks like it tries to do huge pages, make sure the
> call map_range just once with your full memory range. Aligned and
> maybe more than you actually need. Consider putting a few printfs
> into the mapping code to see which path (page-size) it goes."
>
> Could you explain the following suggestion a bit more?: "make sure
> the call map_range just once with your full memory range." It looks
> like mgh-demo.c calls map_range twice: once in map_shmem_and_bars()
> (from your original IVSHMEM demo code, which I based t
Re: Difference in execution duration between root cell and inmate for same code
On Thu, 30 Jan 2020 09:41:08 -0800 Michael Hinton wrote: > On Monday, January 27, 2020 at 12:16:08 AM UTC-7, Henning Schild > wrote: > > > > Ok, so we are just looking for differences between the inmate and > > the linux as non-root cell, because the jailhouse/virtualization > > overhead is acceptable or known. > > > I think so, yeah. > > > > In that case a memory bound workload boils down to the mapping and > > the tlb misses or CAT. And cpu bound could be an issue with the > > FPU. If your binary uses FPU instructions but is able to fall back > > to soft-fpu, you should check which path it takes in the inmate. > > > Let's see: CAT isn't supported by my chip, so that won't help, > unfortunately. But the Linux workload is mostly idle, so I'm not sure > how much that would have helped anyways. > > My inmates don't use FPU instructions, and it's not even set up, so I > don't think that will cause a problem. > > I will investigate TLB misses and page mappings and see what I can > find. To align the mapping on the hypervisor side, you could just run that inmate in the same cell configuration you are running that guest-linux in. For the inmate itself the pagetable is constructed by the mapping library. The code looks like it tries to do huge pages, make sure the call map_range just once with your full memory range. Aligned and maybe more than you actually need. Consider putting a few printfs into the mapping code to see which path (page-size) it goes. That way you might get lucky without having to find how to read tlb-miss counters from the inmate. Henning > Thanks, > Michael > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20200131100917.3ad1b337%40md1za8fc.ad001.siemens.net.
Re: mem_region_request failed for hypervisor memory in jetson-tx2 kit
Sending code around as html does not really help, especially since i
guess that you have a formatting problem with your bootloader
configuration.
My guess is that you want to "append" to the APPEND line and not create
a new line behind it. You might want to add a completely new entry for
that.
LABEL jailhouse
MENU LABEL jailhouse kernel
LINUX /boot/Image-jailhouse
INITRD /boot/initrd-jailhouse
APPEND ${cbootargs} quiet mem=7808M vmalloc=512M
This would be an example entry expecting two new files
"Image-jailhouse" and "initrd-jailhouse", making sure you do not have
to overwrite the previously working kernel.
But as long as you do not see the change in /proc/cmdline you have a
boot configuration issue not related to jailhouse at all. Consult the
documentation of your distro or the booloader used by it.
Henning
On Tue, 28 Jan 2020 13:50:09 -0800
Saroj Sapkota wrote:
> I'm trying to run jailhouse on Jetson tx2 kit. I downloaded the
> jailhouse and compiled it and run the command
>
> =>sudo insmod Downloads/linux-jailhouse-jetson/driver/jailhouse.ko
>
> // there is no error message in terminal console
>
> but it gives following output on the serial console:
>
> tx2@tx2-desktop:~$ [ 129.954491] jailhouse: loading out-of-tree
> module taints kernel.
>
> After this I tried to enable jailhouse through this command
>
> =>sudo jailhouse enable
> Downloads/linux-jetson/configs/arm64/jetson-tx2.cell // terminal
> displays: JAILHOUSE_ENABLE: Invalid argument
>
> //and on the terminal console it displays:
>
> [ 333.421533] jailhouse: mem_region_request failed for hypervisor
> memory mem_region_request failed for hypervisor memory
> mem_region_request failed for hypervisor memory mem_region_request
> failed for hypervisor memory. [ 333.428303] jailhouse: Did you
> reserve the memory with "memmap=" or "mem="?
>
> I have changed /boot/extlinux/extlinux.conf file as follows:
> TIMEOUT 30
> DEFAULT primary
>
> MENU TITLE L4T boot options
>
> LABEL primary
> MENU LABEL primary kernel
> LINUX /boot/Image
> INITRD /boot/initrd
> APPEND ${cbootargs} quiet
> *mem=7808M vmalloc=512M*
> # When testing a custom kernel, it is recommended that you create a
> backup of
> # the original kernel and add a new entry to this file so that the
> device can
> # fallback to the original kernel. To do this:
> #
> # 1, Make a backup of the original kernel
> # sudo cp /boot/Image /boot/Image.backup
> #
> # 2, Copy your custom kernel into /boot/Image
> #
> # 3, Uncomment below menu setting lines for the original kernel
> #
> # 4, Reboot
>
> # LABEL backup
> #MENU LABEL backup kernel
> #LINUX /boot/Image.backup
> #INITRD /boot/initrd
> #APPEND ${cbootargs}
>
> but this change is not working. So what's the wrong in this
> extlinux.conf file as boot up is ignoring *mem=7808M vmalloc=512M
> *this statement. Please help me through this error.
> Thank you
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/20200129123244.22fa5113%40md1za8fc.ad001.siemens.net.
Re: Difference in execution duration between root cell and inmate for same code
On Sat, 25 Jan 2020 23:07:53 -0800 Michael Hinton wrote: > Hi Henning, > > On Thursday, January 23, 2020 at 5:15:08 AM UTC-7, Henning Schild > wrote: > > > > Thanks, > > > > that is a lot of information. I would say that is CPU and memory > > bound work. It should not cause exits at all, maybe a few for > > getting the input in and the output out. reading ivshmem should not > > trap, > > So IVSHMEM won't trap/cause a vmexit? What are the other potential > causes for traps, then? My inmate doesn't access any other resources. > > > > writing > > output to a console should be avoided within the measured time. > > > Before starting this thread, I found that I accidentally did do this, > and after removing the console print, I shaved 300 ms off the inmate > time. But I don't see any more prints that could happen. > > This is how I measure the workload in the inmate: > https://github.com/hintron/jailhouse/blob/ba0c5f9cc28edf43ab6970cdaddafea77dd07b4c/inmates/demos/x86/mgh-demo.c#L1117-L1121 > I then print the cycle count and divide it by 3,700,000 manually to > get the total duration to avoid overflows and truncations. > > > > If you need to use something that traps, see if you can "batch" > > things. I.e. do not read/write in byte-chunks. > > For truly memory bound applications the mapping of the memory > matters. > > The bigger the pages in the pagetable (and the nested pagetable) > > the better. You might be able to read performance counters and look > > at TLB misses. > > > I'll need to look into that. > > > > Not sure what Jailhouse exactly does to mitigate Spectre etc. but > > these mitigations often have a severe effect on "memory > > performance". > > > > I would for sure have a look at aligning the CFLAGS used for the > > Linux application and the inmate. > > > Ok, I'll double check CFLAGS as well. I'm now using the exact same > object files for the workload functions, but the discrepancy got > worse :D > > > The first things to compare is "native Linux", "root cell Linux > > under jailhouse" and "non-root cell Linux under jailhouse". If the > > third is better than your inmate, your inmates environment is > > likely the cause. > Yes, I've been looking at those three cases, and Linux under > Jailhouse is only 30 ms slower than Linux not under Jailhouse, while > both of those are way faster than the inmate. So that tells me that > there is something going wrong with the inmate. Ok, so we are just looking for differences between the inmate and the linux as non-root cell, because the jailhouse/virtualization overhead is acceptable or known. In that case a memory bound workload boils down to the mapping and the tlb misses or CAT. And cpu bound could be an issue with the FPU. If your binary uses FPU instructions but is able to fall back to soft-fpu, you should check which path it takes in the inmate. Henning > Thanks for the help, > -Michael > > Henning > > > > On Wed, 22 Jan 2020 23:57:29 -0800 > > Michael Hinton > wrote: > > > > > Ralf, Henning, > > > > > > > > > Thanks for the quick response, and sorry for the delay. > > > > > > Here’s my setup: I’ve got a 6-core Intel x86-64 CPU running > > > Kubuntu 19.10. I have an inmate that is given a single core and > > > runs a single-threaded workload. For comparison, I also run the > > > same workload in Linux under Jailhouse. > > > > > > For a SHA3 workload with the same 20 MiB input, the root Linux > > > cell (and no inmate running) takes about 2 seconds, while the > > > inmate (and an idle root cell) takes about 2.8 seconds. That is a > > > worrisome discrepancy, and I need to understand why it’s 0.8 s > > > slower. > > > > > > This is the SHA3 workload: > > > > > https://github.com/hintron/jailhouse/blob/76e6d446ca682f73679616a0f3df8ac79f4a1cde/inmates/lib/mgh-sha3.c#L185-L208 > > > > > > > > This is the Linux wrapper for the SHA3 workload: > > > > > https://github.com/hintron/jailhouse/blob/76e6d446ca682f73679616a0f3df8ac79f4a1cde/mgh/workloads/src/sha3-512.c#L166-L168 > > > > > > > > This is the inmate program calling the SHA3 workload: > > > > > https://github.com/hintron/jailhouse/blob/76e6d446ca682f73679616a0f3df8ac79f4a1cde/inmates/demos/x86/mgh-demo.c#L370-L379 > > > > > > > > You can see that the inmate and the Linux wrap
Re: Difference in execution duration between root cell and inmate for same code
Thanks, that is a lot of information. I would say that is CPU and memory bound work. It should not cause exits at all, maybe a few for getting the input in and the output out. reading ivshmem should not trap, writing output to a console should be avoided within the measured time. If you need to use something that traps, see if you can "batch" things. I.e. do not read/write in byte-chunks. For truly memory bound applications the mapping of the memory matters. The bigger the pages in the pagetable (and the nested pagetable) the better. You might be able to read performance counters and look at TLB misses. Not sure what Jailhouse exactly does to mitigate Spectre etc. but these mitigations often have a severe effect on "memory performance". I would for sure have a look at aligning the CFLAGS used for the Linux application and the inmate. The first things to compare is "native Linux", "root cell Linux under jailhouse" and "non-root cell Linux under jailhouse". If the third is better than your inmate, your inmates environment is likely the cause. Henning On Wed, 22 Jan 2020 23:57:29 -0800 Michael Hinton wrote: > Ralf, Henning, > > > Thanks for the quick response, and sorry for the delay. > > Here’s my setup: I’ve got a 6-core Intel x86-64 CPU running Kubuntu > 19.10. I have an inmate that is given a single core and runs a > single-threaded workload. For comparison, I also run the same > workload in Linux under Jailhouse. > > For a SHA3 workload with the same 20 MiB input, the root Linux cell > (and no inmate running) takes about 2 seconds, while the inmate (and > an idle root cell) takes about 2.8 seconds. That is a worrisome > discrepancy, and I need to understand why it’s 0.8 s slower. > > This is the SHA3 workload: > https://github.com/hintron/jailhouse/blob/76e6d446ca682f73679616a0f3df8ac79f4a1cde/inmates/lib/mgh-sha3.c#L185-L208 > > This is the Linux wrapper for the SHA3 workload: > https://github.com/hintron/jailhouse/blob/76e6d446ca682f73679616a0f3df8ac79f4a1cde/mgh/workloads/src/sha3-512.c#L166-L168 > > This is the inmate program calling the SHA3 workload: > https://github.com/hintron/jailhouse/blob/76e6d446ca682f73679616a0f3df8ac79f4a1cde/inmates/demos/x86/mgh-demo.c#L370-L379 > > You can see that the inmate and the Linux wrapper both execute the > same function, sha3_mgh(). It's the same C code. > > The other workloads I run are intentionally more memory intensive. > They see a much worse slowdown. For my CSB workload, the root cell > takes only 0.05 s for a 20 MiB input, while the inmate takes 1.48 s > (30x difference). And for my Random Access workload, the root cell > takes 0.08 s while the inmate takes 3.29 s for a 20 MiB input (40x > difference). > > Here are the root and inmate cell configs, respectively: > > https://github.com/hintron/jailhouse/blob/76e6d446ca682f73679616a0f3df8ac79f4a1cde/configs/x86/bazooka-root.c > > https://github.com/hintron/jailhouse/blob/76e6d446ca682f73679616a0f3df8ac79f4a1cde/configs/x86/bazooka-inmate.c > > I did do some modifications to Jailhouse with VMX and the preemption > timer, but any slowdown that I may have inadvertently introduced > should apply equally to the inmate and root cell. > > It’s possible that I am measuring the duration of the inmate > incorrectly. But the number of vmexits I measure for the inmate and > root seem to roughly correspond with the duration. I also made sure > to avoid tsc_read_ns() by instead recording the TSC cycles and > deriving the duration by dividing by 3,700,000,000 (the unchanging > TSC frequency of my processor). Without this, the time recorded would > overflow after something like 1.2 seconds. > > > I'm wondering if something else is causing unexpected delays: using > IVSHMEM, memory mapping extra memory pages and using it to hold my > input, printing to a virtual console in addition to a serial console, > disabling hardware p-states, turbo boost in the root cell, maybe the > workload code is being compiled to different instructions for the > inmate vs. Linux, etc. > > Sorry for all the detail, but I am grasping at straws at this point. > Any ideas at what I could look into are appreciated. > > Thanks, > Michael > > On Monday, January 20, 2020 at 6:46:32 AM UTC-7, Henning Schild wrote: > > > > On Sun, 19 Jan 2020 23:45:46 -0800 > > Michael Hinton > wrote: > > > > > Hello, > > > > > > I have found that running code in an inmate is a lot slower than > > > running that same code in the root cell on my x86 machine. I am > > > not sure why. > > > > Can you elaborate on "code" and "a lot"? Maybe roughly tell us what > > y
Re: Difference in execution duration between root cell and inmate for same code
On Sun, 19 Jan 2020 23:45:46 -0800 Michael Hinton wrote: > Hello, > > I have found that running code in an inmate is a lot slower than > running that same code in the root cell on my x86 machine. I am not > sure why. Can you elaborate on "code" and "a lot"? Maybe roughly tell us what your testcase does and how severe your slowdown is. Synthetic microbenchmark to measure context switching ? As Ralf already said, anything causing "exits" can be subject to slowdown. But that should be roughly the same for the root cell or any non-root cell, is it truly the "same" code? And of cause anything accessing shared resources can be slowed down by the sharing. Caches/buses ... but i would not expect "a lot". regards, Henning > Am I correct in assuming that when `jailhouse enable ` is > called, everything that runs after that in the Linux root cell is > running under the hypervisor, even when the inmate hasn’t started > yet? Both the inmate and the Linux root cell should both be equally > subjected to the same hypervisor performance penalty, right? > > Are there any high-level differences between the root and the inmate > that could account for this large discrepancy? I know that Turbo > Boost is likely not happening in my inmate while it is happening in > the root cell, but I don’t believe that can account for the huge gap > in execution duration that I see. > > > I'm not expecting anyone to debug this in depth for me, but I would > appreciate any ideas I could look into. > > Thanks, > > Michael > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20200120144629.201f3081%40md1za8fc.ad001.siemens.net.
Re: [PATCH 2/2] tools: gcov: Adjust Gcov counter count for GCC versions >= 7.0
Hi Andrej, nice to see that you exercise that feature of jailhouse! The two commits LGTM. You modify a section that is enclosed with a "heavily inspired by linux/kernel/gcov/gcc_4.7.c"-comment so i would suggest to maybe include a reference to the kernel commits that you are pulling in here. I think we can not avoid a "copy" in jailhouse, but the pointers in the commit messages might help some day. I remember that a couple of files are excluded from gcov entirely, because old compilers could not exclude on function-level. That was relevant for address-space switching code on arm. I believe that more recent compilers can exclude more fine-grained (on function-level instead of file). But that would be more patches on top of what you sent ... another future patch. regards, Henning Am Fri, 20 Dec 2019 16:41:26 +0100 schrieb Andrej Utz : > As in linux/kernel/gcov/gcov.h. > > Otherwise the extract tool will access Gcov data using garbage as an > index and segfault. > > Signed-off-by: Andrej Utz > --- > tools/jailhouse-gcov-extract.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/tools/jailhouse-gcov-extract.c > b/tools/jailhouse-gcov-extract.c index c126f976..5bb337a5 100644 > --- a/tools/jailhouse-gcov-extract.c > +++ b/tools/jailhouse-gcov-extract.c > @@ -43,7 +43,9 @@ typedef long gcov_type; > typedef long long gcov_type; > #endif > > -#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1) > +#if (__GNUC__ >= 7) > +#define GCOV_COUNTERS9 > +#elif (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1) > #define GCOV_COUNTERS10 > #elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9 > #define GCOV_COUNTERS9 -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20191220224016.41134d5d%40md1za8fc.ad001.siemens.net.
Re: Adding a shared tracing mechanism
Hi, i think (hope) that ftrace of the Linux kernel has some sort of networking support. A mechanism to send the trace data to a remote host over TCP or UDP and read the trace on the remote machine. If you really just want to trace the RTOS i would look into such network tracing, where Linux would be the consumer of the trace. You would just have to establish a network link (ivshmem or device assignment) and write the trace in a format that Linux will understand, given you have drivers and an IP stack in your RTOS. The benefit for you would be to not having to deal with jailhouse shared memory. And you would have an abstraction that should work on any hypervisor and even bare-metal. So it would be more sustainable for your RTOS and would allow for comparisons, i.e. jailhouse vs. bare-metal. regards, Henning Am Fri, 13 Dec 2019 08:58:25 +0100 schrieb "[ext] Henning Schild" : > Am Fri, 13 Dec 2019 08:08:32 +0100 > schrieb Jan Kiszka : > > > On 12.12.19 16:43, Guido Roncarolo wrote: > > > Hello All, > > > > > > I am trying to add a small tracing mechanism developed for a RTOS > > > inside jailhouse. > > > > Henning started to look into such a feature as well, but those were > > only early stages. The idea is similar: export a memory region to a > > cell for trace pickup. Events could come from function tracing (gcc > > -pg). > > Well i never actually wrote any code. The idea was similar but the > goal was a different one. We wanted to trace the hypervisor and > process the traces in the root-cell. As far as i understand Guido > might want to trace the RTOS. > > > > It is a simple circular buffer where in constant time access you > > > can insert events, then from Linux > > > you can dump the shared memory and translate the circular buffer > > > content into babletrace format > > Time was not too much in the focus of the idea, rather control-flow. > The reason to not think about time in the first place is the lack of a > clock in the hypervisor and the wish to keep the mechanism > light-weight. > > On x86 TSC could be used and core correlation of possibly out of sync > TSCs could have been done on Linux later. Note that recent kernels > (afaik 4.10+) and modern x86 cores (X86_FEATURE_TSC_ADJUST) support > TSC synchronization at boot-time. Not sure what to do on arm and > aarch64. > > And the "constant time" suggests you want to do sampling with i.e. > performance counters. We though about instrumentation (gcc -gc). > > But the underlying memory channel and maybe trace format could > probably used for both "hypervisor instrumentation" tracing and "cell > sampling". > > Sorry there nothing more than the prosa description. Happy hacking and > looking forward to contributions ;). > > Henning > > > > To achieve this I > > > 1) added a memory region inside the cell config > > > 2) initialize the tracer struct in init_early() hypervisor/setup.c > > > 3) try to insert a test event -> OK > > > 3.1) dump mem from linux -> OK record is there > > > 4) try to insert an event inside entry() or after -> NOT good > > > > > > > > > FATAL: Unhandled HYP exception: synchronous abort from EL2 > > > pc: c020bf68 lr: c02024d4 spsr: 83c9 > > > EL2 sp: ff010e90 esr: 25 1 006 > > > x0: 002b x1: 001e x2: > > > c021d000 x3: b7e0 x4: c021d030 > > > x5: x6: x7: > > > x8: x9: x10: > > > x11: x12: x13: > > > x14: x15: > > > x16: x17: x18: > > > x19: 001e x20: c0219038 > > > x21: 0001 x22: 0001 x23: > > > 0002 x24: 0969c000 x25: 0801 > > > x26: 08014000 x27: x28: > > > 8000283ea880 x29: ff010e90 > > > > > > > > > I tried to to understand from memory-layout.txt if sharing memory > > > like this is legal:what I would need a "Common memory region" > > > that stays visible to all contexts but I'm unsure if this is > > > feasible or allowed > > > > Well, for filling the region, the step that fails after early_init, > > you need a valid mapping inside the hypervisor at any point. Study > > what happens to make the console page work. That is just the same > > use case as tracing. > > > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20191213092118.11df7309%40md1za8fc.ad001.siemens.net.
Re: Adding a shared tracing mechanism
Am Fri, 13 Dec 2019 08:08:32 +0100 schrieb Jan Kiszka : > On 12.12.19 16:43, Guido Roncarolo wrote: > > Hello All, > > > > I am trying to add a small tracing mechanism developed for a RTOS > > inside jailhouse. > > Henning started to look into such a feature as well, but those were > only early stages. The idea is similar: export a memory region to a > cell for trace pickup. Events could come from function tracing (gcc > -pg). Well i never actually wrote any code. The idea was similar but the goal was a different one. We wanted to trace the hypervisor and process the traces in the root-cell. As far as i understand Guido might want to trace the RTOS. > > It is a simple circular buffer where in constant time access you can > > insert events, then from Linux > > you can dump the shared memory and translate the circular buffer > > content into babletrace format Time was not too much in the focus of the idea, rather control-flow. The reason to not think about time in the first place is the lack of a clock in the hypervisor and the wish to keep the mechanism light-weight. On x86 TSC could be used and core correlation of possibly out of sync TSCs could have been done on Linux later. Note that recent kernels (afaik 4.10+) and modern x86 cores (X86_FEATURE_TSC_ADJUST) support TSC synchronization at boot-time. Not sure what to do on arm and aarch64. And the "constant time" suggests you want to do sampling with i.e. performance counters. We though about instrumentation (gcc -gc). But the underlying memory channel and maybe trace format could probably used for both "hypervisor instrumentation" tracing and "cell sampling". Sorry there nothing more than the prosa description. Happy hacking and looking forward to contributions ;). Henning > > To achieve this I > > 1) added a memory region inside the cell config > > 2) initialize the tracer struct in init_early() hypervisor/setup.c > > 3) try to insert a test event -> OK > > 3.1) dump mem from linux -> OK record is there > > 4) try to insert an event inside entry() or after -> NOT good > > > > > > FATAL: Unhandled HYP exception: synchronous abort from EL2 > > pc: c020bf68 lr: c02024d4 spsr: 83c9 EL2 > > sp: ff010e90 esr: 25 1 006 > > x0: 002b x1: 001e x2: c021d000 > > x3: b7e0 x4: c021d030 x5: > > x6: x7: x8: > > x9: x10: x11: > > x12: x13: x14: > > x15: x16: x17: > > x18: x19: 001e x20: c0219038 > > x21: 0001 x22: 0001 x23: 0002 > > x24: 0969c000 x25: 0801 x26: 08014000 > > x27: x28: 8000283ea880 x29: ff010e90 > > > > > > I tried to to understand from memory-layout.txt if sharing memory > > like this is legal:what I would need a "Common memory region" > > that stays visible to all contexts but I'm unsure if this is > > feasible or allowed > > Well, for filling the region, the step that fails after early_init, > you need a valid mapping inside the hypervisor at any point. Study > what happens to make the console page work. That is just the same use > case as tracing. > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20191213085825.1d37128d%40md1za8fc.ad001.siemens.net.
Re: v0.9 vs v1.1 interrupt latency raise
Well you only have soo many shared ressources and if it is not additional exits/interrupts then it is contention on shared ressources. We are probably talking about caches, TLBs and buses. You should be able to use i.e. "perf" on Linux to read out hardware performance counters. And there you might want to look for TLB and cache misses. But the bisecting might be the better idea. Jan already mentioned the "features" that could be responsible. With a bit of educated guessing you will get away with just a few tries. Henning Am Fri, 25 Oct 2019 00:04:36 -0700 schrieb Chung-Fan Yang : > Alright, I have test the latency from HW IRQ to application response. > > I found out that there aren't any additional VM-Exit or IRQ, nor RTOS > scheduling and house-keeping. > > It feels like the processor is generally slower as everything takes > longer to run. > > The IRQ epilogue takes ~7.8us and iretq ~2.x us. In addition, the > libc and syscall interface also have slow downed a bit. > > I do notice after upgrading, even with CAT, my RTOS latency are prone > to be influenced by the Linux side applications. > This was not observed during v0.9.1. > > It's strange. > > > Yang. > -- Siemens AG Corporate Technology CT RDA IOT SES-DE Otto-Hahn-Ring 6 81739 Muenchen, Germany Mobile: +49 172 8378927 mailto: henning.sch...@siemens.com -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20191025155257.6af12e29%40md1za8fc.ad001.siemens.net.
Re: [PATCH v4 00/13] pyjailhouse: x86: Implement config generator for port I/O
Hi, that is a long standing "issue" and we once had a chinese student working on that as well. He never finished though ... I did not look into all details but the insight that the existing code for memory can be reused for ports was in there ... inside the kernel it is also "the same". I only wonder whether IORegionTree.parse_io_file can get away with just one argument, which file to take can be derived from the target class. Or the other way around. Henning Am Tue, 15 Oct 2019 18:22:29 +0200 schrieb Ralf Ramsauer : > (reusing Andrej's cover-letter) > > This patch series eases configuration of port I/O devices for x86 > plattforms by generating an initial PIO region list. To sustain > previous behavior, most entries are disabled (commented out). Only > whitelisted device ports are allowed. This includes the peripheral > PCI port space. > > Additionally the code paths for memory region generation are cleaned > up and streamlined. > > since v3: > - Address Jan's comments > - Dynamically whitelist some platform devices + PCI ports > - I (Ralf) resend the series as Andrej runs into nasty email > throttling issues with his account > > since v2: > - Use new PIO whitelist structures > > Andrej Utz (4): > tools: jailhouse-config-create: Rename regions to mem_regions in > preparation for port_regions > pyjailhouse: abstract parts of MemRegion into IORegion > pyjailhouse: simplify integer formatting for regions in config > template > pyjailhouse: x86: implement pio_regions generator > > Ralf Ramsauer (9): > pyjailhouse: sysfs_parser: remove dead code > pyjailhouse: sysfs_parser: minor stylistic fixups > pyjailhouse: sysfs_parser: introduce new class IORegionTree > pyjailhouse: sysfs_parser: move parse_iomem_file to the new parser > pyjailhouse: sysfs_parser: make regions_split_by_kernel static > pyjailhouse: sysfs_parser: entirely separate IO parsers > pyjailhouse: sysfs_parser: remove parse_iomem_file > pyjailhouse: sysfs_parser: move find_regions_by_name to IORegionTree > pyjailhouse: sysfs_parser: Remove IOMemRegionTree class > > pyjailhouse/sysfs_parser.py | 340 > +- tools/jailhouse-config-create | > 25 +-- tools/root-cell-config.c.tmpl | 22 +-- > 3 files changed, 233 insertions(+), 154 deletions(-) > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20191017145100.0e923e14%40md1za8fc.ad001.siemens.net.
Re: Compilation error (jailhouse.c) in Yocto build
Nice to hear that works for you. If you find any issues with that go
ahead and take me in CC to questions here in the list. And check out
the other "forks".
There is also
https://github.com/cevatbostancioglu/meta-orangepi/tree/master/yocto/meta-orangepi/recipes-jailhouse/jailhouse
and
https://bitbucket.org/retotech/meta-jailhouse/commits/branch/imx8-dev
These two somehow contain my fixes +X, have not looked into the
details. The former one is the most recent, but lacks git-history.
Maybe we get lucky and see a new "master" with 0.11 support on
bitbucket.
If your build system does not have to be yocto, check out
jailhouse-images ... using isar as build system.
Henning
Am Wed, 11 Sep 2019 14:35:22 +0100
schrieb Peter Smith :
> Thanks, I found some other layers to work from (
> https://github.com/henning-schild-work/meta-jailhouse) also. I
> understand why I was getting the error now, working through it all.
> New to Jailhouse.
>
> Best Regards
> Peter
>
>
> On Wed, 11 Sep 2019 at 13:42, Jan Kiszka
> wrote:
>
> > On 11.09.19 13:23, Peter Smith wrote:
> > > Apologize if this is a stupid question.
> > >
> > > I am trying to build jailhouse as part of a Yocto (thud) build
> > > for the
> > US+
> > > MPSoC. I have based my recipe on one found in
> > > meta-ti/kernel/jailhouse
> > as it
> > > seemed to be the most up to date recipe I could find.
> > >
> > > The recipe builds using the following:
> > >
> > > EXTRA_OEMAKE = "ARCH=${JH_ARCH} CROSS_COMPILE=${TARGET_PREFIX}
> > > KDIR=${STAGING_KERNEL_BUILDDIR}"
> > >
> > > do_compile() {
> > > oe_runmake V=1
> > > }
> > >
> > >
> > > Everything proceeds well until the make process reaches the
> > > tools
> > directory
> > > where I get a compilation errors complaining about a missing
> > >
> > which Is
> > > rather odd I thought.
> > >
> > >
> > > |
> > >
> > /build1/peter/PE2/ZCU/build/tmp/work/zcu102_zynqmp-poky-linux/jailhouse/0.11+gitAUTOINC+955a9418df-r0/git/tools/jailhouse-gcov-extract.c:13:10:
> >
> > > fatal error: stdio.h: No such file or directory
> > > | #include
> > > | ^
> > > | compilation terminated.
> > > |
> > >
> > /build1/peter/PE2/ZCU/build/tmp/work/zcu102_zynqmp-poky-linux/jailhouse/0.11+gitAUTOINC+955a9418df-r0/git/tools/jailhouse.c:14:10:
> >
> > > fatal error: stdio.h: No such file or directory
> > > | #include
> > > | ^
> > > | compilation terminated.
> > >
> > > So my question is, is this expected behavior?
> > >
> > > Can the tools be built via Yocto?
> > >
> >
> > Sure, you can. There have been various layers shared in the list
> > before, check
> > e.g. this thread:
> >
> >
> > https://groups.google.com/d/msgid/jailhouse-dev/CABPcKDPEVAW0Y1x8ndpc6LQutq8cCsEKu20inFyFhrMRwa%2B--w%40mail.gmail.com?utm_medium=email&utm_source=footer
> >
> > 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/20190920183156.124c073b%40md1za8fc.ad001.siemens.net.
Re: [PATCH] driver: sysfs: fix parameter usage
Am Fri, 20 Sep 2019 16:59:14 +0200
schrieb Ralf Ramsauer :
> On 9/20/19 4:56 PM, Ralf Ramsauer wrote:
> > find_cell_cpu gets a cell as parameter, but ignores it. It only uses
> > root_cell.
> >
> > This bug never had any consequences, as this routine is only one
> > single caller, and always gets root_cell as parameter.
> > Nevertheless, fix this by using the correct parameter.
> >
> > Signed-off-by: Ralf Ramsauer
> > ---
> > driver/sysfs.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/driver/sysfs.c b/driver/sysfs.c
> > index a272ef4c..a15a2787 100644
> > --- a/driver/sysfs.c
> > +++ b/driver/sysfs.c
> > @@ -353,7 +353,7 @@ static struct cell_cpu *find_cell_cpu(struct
> > cell *cell, unsigned int cpu) {
> > struct cell_cpu *cell_cpu;
> >
> > - list_for_each_entry(cell_cpu, &root_cell->cell_cpus, entry)
> > + list_for_each_entry(cell_cpu, &cell->cell_cpus, entry)
>
> Found this by accident.
>
> Now the question is, should we fix it in this way, or should we
> entirely remove the cell parameter, as this routine gets always
> called with root_cell.
Without having looked at the details, just one caller with one arg
sounds like over-abtracted. If it was not factored out to make the code
more readable and less indented ... i guess it should just move where
it is needed.
Henning
> I'm wondering why the compiler never complained about the unused
> variable.
>
> Ralf
>
> > if (cell_cpu->cpu == cpu)
> > return cell_cpu;
> >
> >
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/20190920181658.64f710cf%40md1za8fc.ad001.siemens.net.
Re: Orange Pi Zero Jailhouse Yocto Integration
Am Sat, 17 Aug 2019 16:46:37 +0300 schrieb Cevat Bostancıoğlu : > Hello, it's been a 3 days and i am still trying to compile, i changed > yocto versions, gcc compiler versions, external toolchain, checked > against debian build etc. but nothing worked. > > i cant understand why this is compiled in jailhouse-images setup and > not compiling under this setup ? > > my setup is: > https://github.com/cevatbostancioglu/meta-orangepi/blob/dev/yocto/meta-orangepi/conf/machine/orange-pi-zero.conf > > my latest error is: > Short log: > > > *arm-oe-linux-gnueabi-gcc: error: -mfloat-abi=soft and > -mfloat-abi=hard may not be used together* That is the compiler complaining about getting instructions that make no nense. You tell it to use soft and hard floating point at the same time. Well you probably do not ... but something does. "make V=1" to get the full command line A first grep does not suggest that the CFLAGS come from jailhouse, they come from the kernel and your toolchain. The context from V=1 could also lead you to which code-path added the FLAGS, because they often come in groups. Wild guess is that your toolchain/compiler might be missing a configure switch. Henning > Long Log: > DEBUG: Executing shell function do_compile > NOTE: make -j 8 > KERNEL_SRC=/home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work-shared/orange-pi-zero/kernel-source > V=0 CC=arm-oe-linux-gnueabi-gcc -mfpu=neon-vfpv4 -mfloat-abi=hard > -mcpu=cortex-a7 > --sysroot=/home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/recipe-sysroot > CROSS_COMPILE=arm-oe-linux-gnueabi- > KDIR=/home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work-shared/orange-pi-zero/kernel-build-artifacts > CHK > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/hypervisor/include/generated/ > config.mk > CHK > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/hypervisor/include/generated/version.h > UPD > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/hypervisor/include/generated/ > config.mk > UPD > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/hypervisor/include/generated/version.h > CC > > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/inmates/lib/arm/../arm-common/../alloc.o > CC > > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/inmates/lib/arm/../arm-common/../cmdline.o > CC > > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/inmates/lib/arm/../arm-common/../printk.o > CC > > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/inmates/lib/arm/../arm-common/../setup.o > CC > > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/inmates/lib/arm/../arm-common/../string.o > CC > > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/hypervisor/arch/arm/asm-defines.s > CC > > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/configs/arm/bananapi-gic-demo.o > CC > > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/inmates/lib/arm/../arm-common/../uart-8250.o > CC [M] > > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/driver/cell.o > CC > > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/inmates/lib/arm/../arm-common/gic-v2.o > > *arm-oe-linux-gnueabi-gcc: error: -mfloat-abi=soft and > -mfloat-abi=hard may not be used together*make[5]: *** > [/home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work-shared/orange-pi-zero/kernel-source/scripts/Makefile.build:314: > /home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work/orange_pi_zero-oe-linux-gnueabi/jailhouse/0.10-gitAUTOINC+55de0454d8-r0/git/driver/cell.o] > Error 1 > make[4]: *** > [/home/cevat/Desktop/meta-orangepi/yocto/build_arm/tmp-glibc/work-shared/orange-pi-zero/ke
Re: [jh-images][PATCH 05/13] Add recipe for building ZynqMP PMU firmware
Am Wed, 4 Sep 2019 17:52:59 +0200
schrieb Jan Kiszka :
> On 04.09.19 15:22, Henning Schild wrote:
> > Am Wed, 4 Sep 2019 13:40:34 +0200
> > schrieb Jan Kiszka :
> >
> >> On 04.09.19 11:17, Henning Schild wrote:
> >>> Am Tue, 3 Sep 2019 07:59:17 +0200
> >>> schrieb "[ext] Jan Kiszka" :
> >>>
> >>>> From: Jan Kiszka
> >>>>
> >>>> Will replace the old binary package so far used for the Ultra96.
> >>>>
> >>>> Signed-off-by: Jan Kiszka
> >>>> ---
> >>>>recipes-bsp/zynqmp-pmufw/files/debian/compat | 1 +
> >>>>recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl | 10
> >>>> recipes-bsp/zynqmp-pmufw/files/debian/rules| 24
> >>>> + recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb
> >>>> | 30 ++ 4 files changed, 65 insertions(+)
> >>>>create mode 100644
> >>>> recipes-bsp/zynqmp-pmufw/files/debian/compat create mode 100644
> >>>> recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl create mode
> >>>> 100755 recipes-bsp/zynqmp-pmufw/files/debian/rules create mode
> >>>> 100644 recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb
> >>>>
> >>>> diff --git a/recipes-bsp/zynqmp-pmufw/files/debian/compat
> >>>> b/recipes-bsp/zynqmp-pmufw/files/debian/compat new file mode
> >>>> 100644 index 000..ec63514
> >>>> --- /dev/null
> >>>> +++ b/recipes-bsp/zynqmp-pmufw/files/debian/compat
> >>>> @@ -0,0 +1 @@
> >>>> +9
> >>>> diff --git a/recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl
> >>>> b/recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl new file
> >>>> mode 100644 index 000..4d14702
> >>>> --- /dev/null
> >>>> +++ b/recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl
> >>>> @@ -0,0 +1,10 @@
> >>>> +Source: ${PN}
> >>>> +Section: misc
> >>>> +Priority: optional
> >>>> +Standards-Version: 3.9.6
> >>>> +Build-Depends: crosstool-ng-microblaze:native
> >>>> +Maintainer: Jan Kiszka
> >>>> +
> >>>> +Package: ${PN}
> >>>> +Architecture: all
> >>>> +Description: ${DESCRIPTION}
> >>>> diff --git a/recipes-bsp/zynqmp-pmufw/files/debian/rules
> >>>> b/recipes-bsp/zynqmp-pmufw/files/debian/rules new file mode
> >>>> 100755 index 000..e86f7a3
> >>>> --- /dev/null
> >>>> +++ b/recipes-bsp/zynqmp-pmufw/files/debian/rules
> >>>> @@ -0,0 +1,24 @@
> >>>> +#!/usr/bin/make -f
> >>>> +#
> >>>> +# Jailhouse, a Linux-based partitioning hypervisor
> >>>> +#
> >>>> +# Copyright (c) Siemens AG, 2019
> >>>> +#
> >>>> +# Authors:
> >>>> +# Jan Kiszka
> >>>> +#
> >>>> +# SPDX-License-Identifier: MIT
> >>>> +#
> >>>> +
> >>>> +DPKG_EXPORT_BUILDFLAGS = 1
> >>>> +include /usr/share/dpkg/default.mk
> >>>> +
> >>>> +override_dh_auto_build:
> >>>> +$(MAKE) -C lib/sw_apps/zynqmp_pmufw/src
> >>>> +
> >>>> +override_dh_auto_install:
> >>>> +dh_install lib/sw_apps/zynqmp_pmufw/src/executable.elf \
> >>>> +usr/share/zynqmp-pmufw/
> >>>> +
> >>>> +%:
> >>>> +dh $@ --parallel
> >>>> diff --git a/recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb
> >>>> b/recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb new file mode
> >>>> 100644 index 000..ff9f05e
> >>>> --- /dev/null
> >>>> +++ b/recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb
> >>>> @@ -0,0 +1,30 @@
> >>>> +#
> >>>> +# Jailhouse, a Linux-based partitioning hypervisor
> >>>> +#
> >>>> +# Copyright (c) Siemens AG, 2019
> >>>> +#
> >>>> +# Authors:
> >>>> +# Jan Kiszka
> >>>> +#
> >>>> +# SPDX-License-Identifier: MIT
> >>>> +#
> >>>> +
> >>>> +inherit dpkg
> >>>> +
> >>>> +DESCRIPTION = "ZynqMP PMU Firmware"
> >>>> +
> >>>> +SRC_URI = &q
Re: [jh-images][PATCH 02/13] build-images: Use latest kas-docker internally
Am Wed, 4 Sep 2019 13:38:18 +0200
schrieb Jan Kiszka :
> On 04.09.19 11:15, Henning Schild wrote:
> > Am Tue, 3 Sep 2019 07:59:14 +0200
> > schrieb "[ext] Jan Kiszka" :
> >
> >> From: Jan Kiszka
> >>
> >> By now, more mature starting of the kas-isar container is achieved
> >> by using upstream kas-docker. E.g., build-images.sh still forwards
> >> SHELL unconditionally, breaking on hosts with shells the container
> >> does not support.
> >>
> >> Therefore, pull kas-docker on demand and use it. Expert users can
> >> define an own source by setting KAS_DOCKER.
> >>
> >> Signed-off-by: Jan Kiszka
> >> ---
> >> .gitignore | 1 +
> >> build-images.sh | 33 -
> >> 2 files changed, 17 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/.gitignore b/.gitignore
> >> index fe0ae1a..43892c0 100644
> >> --- a/.gitignore
> >> +++ b/.gitignore
> >> @@ -1,3 +1,4 @@
> >> build/
> >> isar/
> >> recipes-core/customizations/local.inc
> >> +kas-docker
> >> diff --git a/build-images.sh b/build-images.sh
> >> index 50ed677..28c3a50 100755
> >> --- a/build-images.sh
> >> +++ b/build-images.sh
> >> @@ -2,7 +2,7 @@
> >> #
> >> # Jailhouse, a Linux-based partitioning hypervisor
> >> #
> >> -# Copyright (c) Siemens AG, 2018
> >> +# Copyright (c) Siemens AG, 2018-2019
> >> #
> >> # Authors:
> >> # Jan Kiszka
> >> @@ -21,24 +21,25 @@ usage()
> >>exit 1
> >> }
> >>
> >> -KAS_FILES="/jailhouse-images/kas.yml"
> >> +JAILHOUSE_IMAGES=$(dirname $0)
> >> +KAS_FILES="${JAILHOUSE_IMAGES}/kas.yml"
> >> CMD="build"
> >>
> >> while [ $# -gt 0 ]; do
> >>case "$1" in
> >>--latest)
> >> -
> >> KAS_FILES="${KAS_FILES}:/jailhouse-images/opt-latest.yml"
> >> +
> >> KAS_FILES="${KAS_FILES}:${JAILHOUSE_IMAGES}/opt-latest.yml" shift 1
> >>;;
> >>--rt)
> >> -
> >> KAS_FILES="${KAS_FILES}:/jailhouse-images/opt-rt.yml" +
> >> KAS_FILES="${KAS_FILES}:${JAILHOUSE_IMAGES}/opt-rt.yml" shift 1
> >>;;
> >>--all)
> >>KAS_TARGET=
> >>while read MACHINE DESCRIPTION; do
> >>KAS_TARGET="${KAS_TARGET}
> >> multiconfig:${MACHINE}-jailhouse-demo:demo-image"
> >> - done < images.list
> >> + done < ${JAILHOUSE_IMAGES}/images.list
> >>shift 1
> >>;;
> >>--shell)
> >> @@ -60,7 +61,7 @@ if [ -z "${KAS_TARGET}" ]; then
> >>MACHINES="${MACHINES} ${MACHINE}"
> >>NUM_MACHINES=$((NUM_MACHINES + 1))
> >>echo " ${NUM_MACHINES}: ${DESCRIPTION}"
> >> - done < images.list
> >> + done < ${JAILHOUSE_IMAGES}/images.list
> >>echo " 0: all (may take hours...)"
> >>echo ""
> >>
> >> @@ -93,17 +94,15 @@ if [ -z "${KAS_TARGET}" ]; then
> >>fi
> >>done
> >> fi
> >> +export KAS_TARGET
> >>
> >> -if [ -t 1 ]; then
> >> - INTERACTIVE="-t -i"
> >> +if [ -z ${KAS_DOCKER} ]; then
> >
> > In addition a "command -v" or "which" to see if it is installed
> > globally would be useful.
>
> I thought about using an installed version where available but
> dropped the idea as "too special for this interface". The point is
> that, as an expert, you can now call kas-docker on jailhouse-images
> directly while build-images.sh is the simple interface for people not
> familiar with the internals.
It is not too special because even experts in kas and isar are not
experts on how to compose the several yml files for a chosen build,
they want that "menu". But fetching this one script is not going to
hurt runtime or bandwith usage ;).
Henning
> 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/20190904152815.79ccde31%40md1za8fc.ad001.siemens.net.
Re: [jh-images][PATCH 05/13] Add recipe for building ZynqMP PMU firmware
Am Wed, 4 Sep 2019 13:40:34 +0200
schrieb Jan Kiszka :
> On 04.09.19 11:17, Henning Schild wrote:
> > Am Tue, 3 Sep 2019 07:59:17 +0200
> > schrieb "[ext] Jan Kiszka" :
> >
> >> From: Jan Kiszka
> >>
> >> Will replace the old binary package so far used for the Ultra96.
> >>
> >> Signed-off-by: Jan Kiszka
> >> ---
> >> recipes-bsp/zynqmp-pmufw/files/debian/compat | 1 +
> >> recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl | 10
> >> recipes-bsp/zynqmp-pmufw/files/debian/rules| 24
> >> + recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb
> >> | 30 ++ 4 files changed, 65 insertions(+)
> >> create mode 100644 recipes-bsp/zynqmp-pmufw/files/debian/compat
> >> create mode 100644
> >> recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl create mode
> >> 100755 recipes-bsp/zynqmp-pmufw/files/debian/rules create mode
> >> 100644 recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb
> >>
> >> diff --git a/recipes-bsp/zynqmp-pmufw/files/debian/compat
> >> b/recipes-bsp/zynqmp-pmufw/files/debian/compat new file mode 100644
> >> index 000..ec63514
> >> --- /dev/null
> >> +++ b/recipes-bsp/zynqmp-pmufw/files/debian/compat
> >> @@ -0,0 +1 @@
> >> +9
> >> diff --git a/recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl
> >> b/recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl new file mode
> >> 100644 index 000..4d14702
> >> --- /dev/null
> >> +++ b/recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl
> >> @@ -0,0 +1,10 @@
> >> +Source: ${PN}
> >> +Section: misc
> >> +Priority: optional
> >> +Standards-Version: 3.9.6
> >> +Build-Depends: crosstool-ng-microblaze:native
> >> +Maintainer: Jan Kiszka
> >> +
> >> +Package: ${PN}
> >> +Architecture: all
> >> +Description: ${DESCRIPTION}
> >> diff --git a/recipes-bsp/zynqmp-pmufw/files/debian/rules
> >> b/recipes-bsp/zynqmp-pmufw/files/debian/rules new file mode 100755
> >> index 000..e86f7a3
> >> --- /dev/null
> >> +++ b/recipes-bsp/zynqmp-pmufw/files/debian/rules
> >> @@ -0,0 +1,24 @@
> >> +#!/usr/bin/make -f
> >> +#
> >> +# Jailhouse, a Linux-based partitioning hypervisor
> >> +#
> >> +# Copyright (c) Siemens AG, 2019
> >> +#
> >> +# Authors:
> >> +# Jan Kiszka
> >> +#
> >> +# SPDX-License-Identifier: MIT
> >> +#
> >> +
> >> +DPKG_EXPORT_BUILDFLAGS = 1
> >> +include /usr/share/dpkg/default.mk
> >> +
> >> +override_dh_auto_build:
> >> + $(MAKE) -C lib/sw_apps/zynqmp_pmufw/src
> >> +
> >> +override_dh_auto_install:
> >> + dh_install lib/sw_apps/zynqmp_pmufw/src/executable.elf \
> >> + usr/share/zynqmp-pmufw/
> >> +
> >> +%:
> >> + dh $@ --parallel
> >> diff --git a/recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb
> >> b/recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb new file mode
> >> 100644 index 000..ff9f05e
> >> --- /dev/null
> >> +++ b/recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb
> >> @@ -0,0 +1,30 @@
> >> +#
> >> +# Jailhouse, a Linux-based partitioning hypervisor
> >> +#
> >> +# Copyright (c) Siemens AG, 2019
> >> +#
> >> +# Authors:
> >> +# Jan Kiszka
> >> +#
> >> +# SPDX-License-Identifier: MIT
> >> +#
> >> +
> >> +inherit dpkg
> >> +
> >> +DESCRIPTION = "ZynqMP PMU Firmware"
> >> +
> >> +SRC_URI = " \
> >> +
> >> https://github.com/Xilinx/embeddedsw/archive/xilinx-v${PV}.tar.gz \
> >> +file://debian/"
> >> +SRC_URI[sha256sum] =
> >> "0b36721d62f970b1873fd337e94ee13304500ecec1dd5dbfc4f0ed952e55cf5f"
> >> + +DEPENDS = "crosstool-ng-microblaze"
> >> +
> >> +TEMPLATE_FILES = "debian/control.tmpl"
> >> +
> >> +S = "${WORKDIR}/embeddedsw-xilinx-v${PV}"
> >> +
> >> +do_prepare_build() {
> >> +cp -r ${WORKDIR}/debian ${S}
> >> +deb_add_changelog
> >
> > Why not use the whole debianization? It supports custom pre-existing
> > files, and if there are gaps we could improve it in isar.
>
> deb_debianize is still somehow in the stage of "for insiders only".
> Add a proper upstream test case, document the API, and we can move
> forward with it.
I know that, but you are using deb_add_changelog which is a subset of
it. So no reason, except for you did not yet look into it?
Henning
> 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/20190904152249.14086fef%40md1za8fc.ad001.siemens.net.
Re: [jh-images][PATCH 05/13] Add recipe for building ZynqMP PMU firmware
Am Tue, 3 Sep 2019 07:59:17 +0200
schrieb "[ext] Jan Kiszka" :
> From: Jan Kiszka
>
> Will replace the old binary package so far used for the Ultra96.
>
> Signed-off-by: Jan Kiszka
> ---
> recipes-bsp/zynqmp-pmufw/files/debian/compat | 1 +
> recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl | 10
> recipes-bsp/zynqmp-pmufw/files/debian/rules| 24
> + recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb
> | 30 ++ 4 files changed, 65 insertions(+)
> create mode 100644 recipes-bsp/zynqmp-pmufw/files/debian/compat
> create mode 100644 recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl
> create mode 100755 recipes-bsp/zynqmp-pmufw/files/debian/rules
> create mode 100644 recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb
>
> diff --git a/recipes-bsp/zynqmp-pmufw/files/debian/compat
> b/recipes-bsp/zynqmp-pmufw/files/debian/compat new file mode 100644
> index 000..ec63514
> --- /dev/null
> +++ b/recipes-bsp/zynqmp-pmufw/files/debian/compat
> @@ -0,0 +1 @@
> +9
> diff --git a/recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl
> b/recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl new file mode
> 100644 index 000..4d14702
> --- /dev/null
> +++ b/recipes-bsp/zynqmp-pmufw/files/debian/control.tmpl
> @@ -0,0 +1,10 @@
> +Source: ${PN}
> +Section: misc
> +Priority: optional
> +Standards-Version: 3.9.6
> +Build-Depends: crosstool-ng-microblaze:native
> +Maintainer: Jan Kiszka
> +
> +Package: ${PN}
> +Architecture: all
> +Description: ${DESCRIPTION}
> diff --git a/recipes-bsp/zynqmp-pmufw/files/debian/rules
> b/recipes-bsp/zynqmp-pmufw/files/debian/rules new file mode 100755
> index 000..e86f7a3
> --- /dev/null
> +++ b/recipes-bsp/zynqmp-pmufw/files/debian/rules
> @@ -0,0 +1,24 @@
> +#!/usr/bin/make -f
> +#
> +# Jailhouse, a Linux-based partitioning hypervisor
> +#
> +# Copyright (c) Siemens AG, 2019
> +#
> +# Authors:
> +# Jan Kiszka
> +#
> +# SPDX-License-Identifier: MIT
> +#
> +
> +DPKG_EXPORT_BUILDFLAGS = 1
> +include /usr/share/dpkg/default.mk
> +
> +override_dh_auto_build:
> + $(MAKE) -C lib/sw_apps/zynqmp_pmufw/src
> +
> +override_dh_auto_install:
> + dh_install lib/sw_apps/zynqmp_pmufw/src/executable.elf \
> + usr/share/zynqmp-pmufw/
> +
> +%:
> + dh $@ --parallel
> diff --git a/recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb
> b/recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb new file mode 100644
> index 000..ff9f05e
> --- /dev/null
> +++ b/recipes-bsp/zynqmp-pmufw/zynqmp-pmufw_2019.1.bb
> @@ -0,0 +1,30 @@
> +#
> +# Jailhouse, a Linux-based partitioning hypervisor
> +#
> +# Copyright (c) Siemens AG, 2019
> +#
> +# Authors:
> +# Jan Kiszka
> +#
> +# SPDX-License-Identifier: MIT
> +#
> +
> +inherit dpkg
> +
> +DESCRIPTION = "ZynqMP PMU Firmware"
> +
> +SRC_URI = " \
> +
> https://github.com/Xilinx/embeddedsw/archive/xilinx-v${PV}.tar.gz \
> +file://debian/"
> +SRC_URI[sha256sum] =
> "0b36721d62f970b1873fd337e94ee13304500ecec1dd5dbfc4f0ed952e55cf5f" +
> +DEPENDS = "crosstool-ng-microblaze"
> +
> +TEMPLATE_FILES = "debian/control.tmpl"
> +
> +S = "${WORKDIR}/embeddedsw-xilinx-v${PV}"
> +
> +do_prepare_build() {
> +cp -r ${WORKDIR}/debian ${S}
> +deb_add_changelog
Why not use the whole debianization? It supports custom pre-existing
files, and if there are gaps we could improve it in isar.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/20190904111724.1f8e2b9d%40md1za8fc.ad001.siemens.net.
Re: [jh-images][PATCH 02/13] build-images: Use latest kas-docker internally
Am Tue, 3 Sep 2019 07:59:14 +0200
schrieb "[ext] Jan Kiszka" :
> From: Jan Kiszka
>
> By now, more mature starting of the kas-isar container is achieved by
> using upstream kas-docker. E.g., build-images.sh still forwards SHELL
> unconditionally, breaking on hosts with shells the container does not
> support.
>
> Therefore, pull kas-docker on demand and use it. Expert users can
> define an own source by setting KAS_DOCKER.
>
> Signed-off-by: Jan Kiszka
> ---
> .gitignore | 1 +
> build-images.sh | 33 -
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index fe0ae1a..43892c0 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,3 +1,4 @@
> build/
> isar/
> recipes-core/customizations/local.inc
> +kas-docker
> diff --git a/build-images.sh b/build-images.sh
> index 50ed677..28c3a50 100755
> --- a/build-images.sh
> +++ b/build-images.sh
> @@ -2,7 +2,7 @@
> #
> # Jailhouse, a Linux-based partitioning hypervisor
> #
> -# Copyright (c) Siemens AG, 2018
> +# Copyright (c) Siemens AG, 2018-2019
> #
> # Authors:
> # Jan Kiszka
> @@ -21,24 +21,25 @@ usage()
> exit 1
> }
>
> -KAS_FILES="/jailhouse-images/kas.yml"
> +JAILHOUSE_IMAGES=$(dirname $0)
> +KAS_FILES="${JAILHOUSE_IMAGES}/kas.yml"
> CMD="build"
>
> while [ $# -gt 0 ]; do
> case "$1" in
> --latest)
> -
> KAS_FILES="${KAS_FILES}:/jailhouse-images/opt-latest.yml"
> +
> KAS_FILES="${KAS_FILES}:${JAILHOUSE_IMAGES}/opt-latest.yml" shift 1
> ;;
> --rt)
> - KAS_FILES="${KAS_FILES}:/jailhouse-images/opt-rt.yml"
> +
> KAS_FILES="${KAS_FILES}:${JAILHOUSE_IMAGES}/opt-rt.yml" shift 1
> ;;
> --all)
> KAS_TARGET=
> while read MACHINE DESCRIPTION; do
> KAS_TARGET="${KAS_TARGET}
> multiconfig:${MACHINE}-jailhouse-demo:demo-image"
> - done < images.list
> + done < ${JAILHOUSE_IMAGES}/images.list
> shift 1
> ;;
> --shell)
> @@ -60,7 +61,7 @@ if [ -z "${KAS_TARGET}" ]; then
> MACHINES="${MACHINES} ${MACHINE}"
> NUM_MACHINES=$((NUM_MACHINES + 1))
> echo " ${NUM_MACHINES}: ${DESCRIPTION}"
> - done < images.list
> + done < ${JAILHOUSE_IMAGES}/images.list
> echo " 0: all (may take hours...)"
> echo ""
>
> @@ -93,17 +94,15 @@ if [ -z "${KAS_TARGET}" ]; then
> fi
> done
> fi
> +export KAS_TARGET
>
> -if [ -t 1 ]; then
> - INTERACTIVE="-t -i"
> +if [ -z ${KAS_DOCKER} ]; then
In addition a "command -v" or "which" to see if it is installed
globally would be useful.
Henning
> + KAS_DOCKER=./kas-docker
> + if [ ! -e ${KAS_DOCKER} ]; then
> + wget -q --show-progress -O ${KAS_DOCKER} \
> +
> https://raw.githubusercontent.com/siemens/kas/master/kas-docker
> + chmod a+x ${KAS_DOCKER}
> + fi
> fi
>
> -docker run -v $(pwd):/jailhouse-images:ro -v $(pwd):/work:rw
> --workdir=/work \
> --e USER_ID=$(id -u) -e SHELL=${SHELL} \
> --e KAS_TARGET="${KAS_TARGET}" -e KAS_TASK="${KAS_TASK}" \
> ---rm ${INTERACTIVE} \
> ---cap-add=SYS_ADMIN --cap-add=MKNOD --privileged \
> --e http_proxy=$http_proxy -e https_proxy=$https_proxy \
> --e ftp_proxy=$ftp_proxy -e no_proxy=$no_proxy \
> --e NO_PROXY=$NO_PROXY \
> -kasproject/kas-isar ${CMD} ${KAS_FILES}
> +${KAS_DOCKER} --isar ${CMD} ${KAS_FILES}
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/20190904111502.2fcbe1c3%40md1za8fc.ad001.siemens.net.
Re: Interrupt Latency in RTOS inmate cell
Am Tue, 3 Sep 2019 02:28:13 -0700 schrieb Nir Geller : > Hi Henning > > When I execute "sync" I get a spike on jitter. > When executing > echo 1 > /proc/sys/vm/drop_caches > or > echo 2 > /proc/sys/vm/drop_caches > or > echo 3 > /proc/sys/vm/drop_caches > No spike occurs. Not those caches. The CPUs caches. If your two cores share i.e. a layer3 cache one core can evict all warm entries from the other. Forcing that other to go back to slow RAM and get it again. In the worst case you share and NUMA kicks in, which gets you twice the slowness of RAM. Do you share any memory i.e. a ivshmem region? > I'm not familiar with AMBA, so I'm trying to learn the subject now. I > guess you mean giving higher priority to core1 > in attempt to narrow DMA latency? Yes i thought about DMA latency. But if that also happens for sysfs or proc, there is no IO and no DMA. What is your storage backing anyways? NFS, some filesystem on some mass storage ? Maybe your Linux UART has some shared resources with with the GPIO? Can you silence the UART and operate that Linux with i.e. ssh? Henning > Thanks, > > Nir. > > On Monday, September 2, 2019 at 7:57:16 PM UTC+3, Henning Schild > wrote: > > > > A good way of estimating the cost of someone messing with ones > > caches is to flush them yourself in your test and see how much that > > costs you. > > > > I am not sure how complicated it is to read performance counters on > > ARM, but those might give a clue. > > > > AMBA QoS can maybe help raise the IO prio of your RT-cell. If a DMA > > request is what is slowing down your GPIO. > > I have never used that but maybe you can configure it from Linux > > before you enable Jailhouse, and make sure that your root cell > > config blocks future access to the configuration mechanism. > > > > Henning > > > > > > > > Am Mon, 2 Sep 2019 17:27:47 +0200 > > schrieb Ralf Ramsauer >: > > > > > Hi, > > > > > > On 9/2/19 5:11 PM, Nir Geller wrote: > > > > CPUFREQ is set to performance, and I'm setting scaling_min_freq > > > > to the highest available frequency (150) > > > > CPU idling is disabled > > > > > > > > Now I see that executing a simple "cat somefile" on the command > > > > line causes a spike in jitter > > > > > > only for the first time or also for consecutive calls on the same > > > file? IOW, can you observe/trigger the spike when somefile is in > > > your page cache? > > > > > > Does the non-root cell share any devices with the root cell? > > > (e.g. debug UART) > > > > > > Ralf > > > > > > > > > > > On Monday, September 2, 2019 at 5:51:24 PM UTC+3, Henning > > > > Schild wrote: > > > > > > > > Am Mon, 2 Sep 2019 06:12:00 -0700 > > > > schrieb Nir Geller >: > > > > > > > > > I created a kernel module that catches/releases a > > > > > spinlock and disables/enables preemption, and it had no > > > > > observable effect on the jitter, however, > > > > > the operations insmod and rmmod definitely cause spikes > > > > > in jitter. > > > > > > > > > > Any pointers? > > > > > > > > Do you have any power management features enabled in that > > > > Linux? > > > > > > > > Henning > > > > > > > > > Thanks. > > > > > > > > > > > > > -- > > > > 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 jailho...@googlegroups.com > > > > <mailto:jailhouse-dev+unsubscr...@googlegroups.com > > > > >. To view this discussion on the web visit > > > > > > https://groups.google.com/d/msgid/jailhouse-dev/a3c23a6a-95ee-4baa-9714-229c84d9d5b7%40googlegroups.com > > > > > > < > > https://groups.google.com/d/msgid/jailhouse-dev/a3c23a6a-95ee-4baa-9714-229c84d9d5b7%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > > > > > > > > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20190903141907.65025fe4%40md1za8fc.ad001.siemens.net.
Re: Interrupt Latency in RTOS inmate cell
A good way of estimating the cost of someone messing with ones caches is to flush them yourself in your test and see how much that costs you. I am not sure how complicated it is to read performance counters on ARM, but those might give a clue. AMBA QoS can maybe help raise the IO prio of your RT-cell. If a DMA request is what is slowing down your GPIO. I have never used that but maybe you can configure it from Linux before you enable Jailhouse, and make sure that your root cell config blocks future access to the configuration mechanism. Henning Am Mon, 2 Sep 2019 17:27:47 +0200 schrieb Ralf Ramsauer : > Hi, > > On 9/2/19 5:11 PM, Nir Geller wrote: > > CPUFREQ is set to performance, and I'm setting scaling_min_freq to > > the highest available frequency (150) > > CPU idling is disabled > > > > Now I see that executing a simple "cat somefile" on the command line > > causes a spike in jitter > > only for the first time or also for consecutive calls on the same > file? IOW, can you observe/trigger the spike when somefile is in your > page cache? > > Does the non-root cell share any devices with the root cell? (e.g. > debug UART) > > Ralf > > > > > On Monday, September 2, 2019 at 5:51:24 PM UTC+3, Henning Schild > > wrote: > > > > Am Mon, 2 Sep 2019 06:12:00 -0700 > > schrieb Nir Geller >: > > > > > I created a kernel module that catches/releases a spinlock and > > > disables/enables preemption, and it had no observable effect > > > on the jitter, however, > > > the operations insmod and rmmod definitely cause spikes in > > > jitter. > > > > > > Any pointers? > > > > Do you have any power management features enabled in that Linux? > > > > Henning > > > > > Thanks. > > > > > > > -- > > 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 > > <mailto:jailhouse-dev+unsubscr...@googlegroups.com>. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/jailhouse-dev/a3c23a6a-95ee-4baa-9714-229c84d9d5b7%40googlegroups.com > > <https://groups.google.com/d/msgid/jailhouse-dev/a3c23a6a-95ee-4baa-9714-229c84d9d5b7%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20190902185713.0c54ed6b%40md1za8fc.ad001.siemens.net.
Re: Interrupt Latency in RTOS inmate cell
Am Mon, 2 Sep 2019 06:12:00 -0700 schrieb Nir Geller : > I created a kernel module that catches/releases a spinlock and > disables/enables preemption, and it had no observable effect on the > jitter, however, > the operations insmod and rmmod definitely cause spikes in jitter. > > Any pointers? Do you have any power management features enabled in that Linux? Henning > Thanks. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20190902165120.7cc1048b%40md1za8fc.ad001.siemens.net.
Re: Orange Pi Zero Jailhouse Yocto Integration
Hi, i did not look into the problem yet. But my jailhouse layer for yocto is on github. https://github.com/henning-schild-work/meta-jailhouse Have a look at the branch henning/staging for patches to get a more recent jailhouse to work. Henning Am Tue, 13 Aug 2019 14:31:36 +0300 schrieb Cevat Bostancıoğlu : > Hello, > Thanks for the fast reply, > > I tried with 9f233898917f8c1141132606f2f2c624405d8c81 commit and also > latest commit, still have same problem. > > I will be appreciated if you guys can provide/help with examples. > > Thanks, > Cevat > > Jan Kiszka , 13 Ağu 2019 Sal, 14:09 tarihinde > şunu yazdı: > > > On 13.08.19 12:39, Cevat Bostancıoğlu wrote: > > > Hello, > > > I am trying to learn/play embedded virtualization tools and i saw > > > Isar Integrated jailhouse-image repo, tested orange pi > > > zero(256mb) image and everything is fine. > > > I am trying to integrate latest jailhouse(0.11) into yocto > > > project and i > > saw > > > https://bitbucket.org/retotech/meta-jailhouse/src/master/ , which > > > is > > for banana > > > pi with jailhouse_0.8. > > > > > > Anyway, I ported jailhouse-images and meta-jailhouse > > together(meta-orangepi, > > > https://github.com/cevatbostancioglu/meta-orangepi/tree/dev) and > > > trying > > to > > > compile for orange pi zero(256mb) but I saw many errors while > > > building. > > can you > > > guys can guess what is the problem? > > > > > > my status: > > > i am trying to build exact image with jailhouse-images so i > > > patched > > u-boot & > > > kernel, now i am trying to compile/install jailhouse. > > > > > > You can see build error as follows, > > > also attached log outputs too. > > > > > > > The errors look like they could get better with > > > > https://github.com/siemens/jailhouse/commit/9f233898917f8c1141132606f2f2c624405d8c81 > > > > > My repo: > > > https://github.com/cevatbostancioglu/meta-orangepi/tree/dev > > > > > > > Thanks for sharing. Henning did some yocto'ization for an internal > > Jailhouse > > project recently (though that was for legacy vendor BSP) - maybe he > > can share > > some thoughts on your direction. > > > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20190814085057.43ce8c63%40md1za8fc.ad001.siemens.net.
Re: [PATCH v2 2/2] pyjailhouse: x86: implement pio_bitmap generator
Hey Andrej,
this feature was already proposed and discussed before, but never
resulted in patches getting merged.
https://groups.google.com/d/topic/jailhouse-dev/BSfMKio91BQ/discussion
I did not look into it yet. But you might want to reread that thread,
making sure your proposal covers what was discussed back than.
The main issue really is that a lot of device drivers do not register
themselfs as port-users, so we can not detect them.
But those exotic ports are probably blocked in the default config so
there is no new problem. A new problem would be if the generated configs
shrink the default set, revoking access that was granted before.
But i agree that it is a good idea to improve the generated config to
reach a working out-of-the-box state.
Henning
Am Fri, 21 Jun 2019 00:06:14 +0200
schrieb Andrej Utz :
> This replaces the old static port list with actual port regions from
> '/proc/ioports'. The static regions from said list are kept and
> override the data in case of region overlap to retain compability.
> The generated port list is virtually identicall to the old one but
> eases manual configuration.
>
> Signed-off-by: Andrej Utz
> ---
> pyjailhouse/sysfs_parser.py | 150
> ++ tools/jailhouse-config-create |
> 26 ++ tools/root-cell-config.c.tmpl | 31 ---
> 3 files changed, 176 insertions(+), 31 deletions(-)
>
> diff --git a/pyjailhouse/sysfs_parser.py b/pyjailhouse/sysfs_parser.py
> index d612c6d3..ce490236 100644
> --- a/pyjailhouse/sysfs_parser.py
> +++ b/pyjailhouse/sysfs_parser.py
> @@ -141,6 +141,52 @@ def parse_iomem(pcidevices):
>
> return ret, dmar_regions
>
> +def parse_ioports():
> +regions = IOMapTree.parse_ioports_tree(
> +IOMapTree.parse_iomap_file('/proc/ioports', PortRegion))
> +
> +tmp = [
> +# static regions
> +PortRegion(0x0, 0x3f, ''),
> +PortRegion(0x40, 0x43, 'PIT', allowed=True),
> +PortRegion(0x60, 0x61, 'NMI', allowed=True,
> comments=["HACK!"]), # NMI status/control
> +PortRegion(0x64, 0x64, 'NMI', allowed=True,
> comments=["HACK!"]), # ditto
> +PortRegion(0x70, 0x71, 'RTC', allowed=True),
> +PortRegion(0x3b0, 0x3df, 'VGA', allowed=True),
> +PortRegion(0xd00, 0x, 'PCI bus', allowed=True),
> +]
> +
> +pm_timer_base = None
> +for r in regions:
> +if r.typestr == 'ACPI PM_TMR':
> +pm_timer_base = r.start
> +
> +tmp.append(r)
> +
> +tmp.sort(key=lambda r: r.start)
> +ret = [ tmp[0] ]
> +
> +# adjust overlapping regions
> +for r in tmp[1:]:
> +prev = ret[-1]
> +
> +# combine multiple regions under the same bit mask
> +if prev.aligned_stop() >= r.aligned_start():
> +if r.stop > prev.stop:
> +n = prev
> +while n.neighbor != None:
> +n = n.neighbor
> +n.neighbor = r
> +continue
> +
> +# forbid access to unrecognized regions
> +if prev.aligned_stop() - r.aligned_start() > 0:
> +ret.append(
> +PortRegion(prev.aligned_stop() + 1,
> r.aligned_start() - 1, '')) +
> +ret.append(r)
> +
> +return (ret, pm_timer_base)
>
> def parse_pcidevices():
> int_src_cnt = 0
> @@ -772,6 +818,85 @@ class MemRegion:
> return 'JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE'
>
>
> +class PortRegion:
> +def __init__(self, start, stop, typestr, comments=None,
> allowed=False):
> +self.start = start
> +self.stop = stop
> +self.typestr = typestr or ''
> +self.comments = comments or []
> +self.allowed = allowed
> +self.neighbor = None
> +
> +def __str__(self):
> +# as in MemRegion this method is purely for C comment
> generation +
> +# remove consecutive duplicates
> +neighbor = self.neighbor
> +stop = self.stop
> +ns = ''
> +while neighbor:
> +if self.typestr != neighbor.typestr \
> +or self.comments != neighbor.comments:
> +ns += ', ' + str(neighbor)
> +break
> +
> +stop = neighbor.stop
> +neighbor = neighbor.neighbor
> +
> +s = ''
> +# pretty print single ports
> +if self.start == stop:
> +s += '%5s' % ''
> +else:
> +s += '%04x-' % self.start
> +
> +s += '%04x' % stop
> +
> +
> +if self.typestr:
> +s += ' : ' + self.typestr
> +
> +if self.comments:
> +s += ' (' + ', '.join(c for c in self.comments) + ')'
> +
> +s += ns
> +return s
> +
> +# used in root-cell-config.c.tmpl
> +def is_combined(self):
> +neighbor = self.neighbor
> +while neighbor:
> +if self.typestr != neighbor.typestr:
> +return True
> +
> +neighbor = neighbor.neighbor
> +
> +return False
> +
>
Re: Jailhouse enable hangs on AMD EPYC 7351P
Am Fri, 21 Jun 2019 07:18:14 -0700 schrieb Adam Przybylski : > Am Freitag, 21. Juni 2019 15:54:15 UTC+2 schrieb Henning Schild: > > Am Fri, 21 Jun 2019 14:51:30 +0200 > > schrieb Ralf Ramsauer: > > > > > Hi, > > > > > > On 6/21/19 2:22 PM, Valentine Sinitsyn wrote: > > > > Hi Adam, > > > > > > > > On 21.06.2019 17:16, Adam Przybylski wrote: > > > >> Dear Jailhouse Community, > > > >> > > > >> I am trying to enabled Jailhouse on the AMD EPYC 7351P 16-Core > > > >> Processor. Unfortunately the system hangs after I execute > > > >> "jailhouse enable sysconfig.cell". > > > >> > > > >> Do you have any hint how to debug and instrument this issue? > > > >> > > > >> Any kind of help is appreciated. > > > >> > > > >> Attached you can find the jailhouse logs, processor info, and > > > >> sysconfig.c. > > > >> > > > >> Looking forward to hear from you. > > > > I'd say the following line is the culprit: > > > > > > > >> FATAL: Invalid PIO read, port: 814 size: 1 > > > > > > Could you please attach /proc/ioports? This will tell us the > > > secret behind Port 814. > > > > Not always, the driver doing that has to be so friendly to register > > the region. > > > > > > > > > > As a quick fix, you may grant your root cell access to all I/O > > > > ports and see if it helps. > > > > > > Allowing access will suppress the symptoms, yet we should > > > investigate its cause. Depending on the semantics of Port 819, to > > > allow access might have unintended side effects. > > > > > > You could also try to disassemble your kernel (objdump -d > > > vmlinux) and check what function hides behind the instruction > > > pointer at the moment of the crash 0xa4ac3114. > > > > A look in the System.map can also answer that question. On a distro > > that will be ready to read somewhere in /boot/. > > > > Henning > > > > > Ralf > > > > > > > > > > > Best, > > > > Valentine > > > > > > > >> > > > >> Kind regards, > > > >> Adam Przybylski > > > >> > > > > > > > > > Hi, > > I looked up the function which gets executed in the Kernel. It's > "acpi_idle_do_entry". Well now you are back to what Valentine said. Open up those ports one by one, until the problem goes away. The alternative is to disable the drivers in the root-linux. In the case of ACPI i.e. acpi=off as kernel parameter, but you probably do not want that. Note that whatever you allow might cause weaker isolation, in this case maybe real-time related. Henning > Adam > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20190623183232.084b6744%40md1za8fc.ad001.siemens.net. For more options, visit https://groups.google.com/d/optout.
Re: Jailhouse enable hangs on AMD EPYC 7351P
Am Fri, 21 Jun 2019 14:51:30 +0200 schrieb Ralf Ramsauer : > Hi, > > On 6/21/19 2:22 PM, Valentine Sinitsyn wrote: > > Hi Adam, > > > > On 21.06.2019 17:16, Adam Przybylski wrote: > >> Dear Jailhouse Community, > >> > >> I am trying to enabled Jailhouse on the AMD EPYC 7351P 16-Core > >> Processor. Unfortunately the system hangs after I execute > >> "jailhouse enable sysconfig.cell". > >> > >> Do you have any hint how to debug and instrument this issue? > >> > >> Any kind of help is appreciated. > >> > >> Attached you can find the jailhouse logs, processor info, and > >> sysconfig.c. > >> > >> Looking forward to hear from you. > > I'd say the following line is the culprit: > > > >> FATAL: Invalid PIO read, port: 814 size: 1 > > Could you please attach /proc/ioports? This will tell us the secret > behind Port 814. Not always, the driver doing that has to be so friendly to register the region. > > > > As a quick fix, you may grant your root cell access to all I/O > > ports and see if it helps. > > Allowing access will suppress the symptoms, yet we should investigate > its cause. Depending on the semantics of Port 819, to allow access > might have unintended side effects. > > You could also try to disassemble your kernel (objdump -d vmlinux) and > check what function hides behind the instruction pointer at the moment > of the crash 0xa4ac3114. A look in the System.map can also answer that question. On a distro that will be ready to read somewhere in /boot/. Henning > Ralf > > > > > Best, > > Valentine > > > >> > >> Kind regards, > >> Adam Przybylski > >> > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20190621155406.18df2751%40md1za8fc.ad001.siemens.net. For more options, visit https://groups.google.com/d/optout.
Re: Ivshmem-demo interrupt
Am Tue, 28 May 2019 06:22:05 -0700 schrieb : > Hello everyone, > > I'm trying to run the ivshmem-demo on a lanner NCA-510A. The inmate > cell seems to be working well. However, I can't get the interruptions > between the cells to work. Is this due to a configuration problem? > (You will find attached my configuration files) I explain : when I > launch the inmate the shared memory is written but the inmate doesn't > react to the uio_send and there is nothing to read in the uio_read... The ivshmem guestcode repo is not tested as well as jailhouse. And together with kernels there are now 3 components to combine. So i would not be surprised if your problem has to do with that uio linux example. But it is not horribly broken and should work! The main issue with it is that people do not read the docs and check out the wrong branch, later use the python code ... which is not tested on jailhouse ... I would suggest two ivshmem-demo cells before you even look at linux+uio. That way you get isvhmem-guestcode out of the picture and will start with just jailhouse. Especially since you later want to run linux in another cell anyways. > here is my : > grep ivshmem /proc/interrupts > 202: 0 0 0 0 0 > 0 0 0 0 0 0 > 0 0 0 0 0 0 > 0 0 0 0 0 0 IR-PCI-MSI > 229376-edge uio_ivshmem > > Second question: the next step of my project will be to run the > uio_ivshmem driver between two linux cells. Is it possible or is the > driver only for the rootCell? The uio stuff will work in either root or non-root, no problem. That is, if it works. Henning > best regards, > > Jeanne > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20190528210147.6dd80c1d%40md1za8fc.ad001.siemens.net. For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] Scripts: Fix for Parsing DMAR Region under Reserved Section
Am Mon, 6 May 2019 12:26:42 -0700
schrieb Hakkı Kurumahmut :
> Hi Henning,
>
> I have write new patch but I have not test it more. But it is more
> suitable for your advices.
>
That one looks very good and you can propose it with "git format-patch
--subject prefix PATCHv2" after a few more things. Again comments inline
> diff --git a/pyjailhouse/sysfs_parser.py b/pyjailhouse/sysfs_parser.py
> index 46c95fc2..985c1129 100644
> --- a/pyjailhouse/sysfs_parser.py
> +++ b/pyjailhouse/sysfs_parser.py
> @@ -22,6 +22,7 @@ import struct
> import os
> import fnmatch
>
> +# root_dir = "/home/ubuntu/repos/siemens/jailhouse/data/"
> root_dir = "/"
Do you already know about "jailhouse-config-collect" and the "-r"
switch for the config creator?
Needless to say that this should not become part of the patch. The same
applies to some whitespace diff and the debug prints.
> def set_root_dir(dir):
> @@ -58,6 +59,7 @@
> inputs['files_intel'].add('/sys/firmware/acpi/tables/DMAR')
> inputs['files_amd'].add('/sys/firmware/acpi/tables/IVRS')
>
> +
> def check_input_listed(name, optional=False):
> set = inputs['files_opt']
> if optional is False:
> @@ -94,14 +96,15 @@ def input_listdir(dir, wildcards):
>
>
> def parse_iomem(pcidevices):
> -regions = IOMemRegionTree.parse_iomem_tree(
> +dmar_regions = []
this is already done inside the function and can be skipped
> +(regions, dmar_regions) = IOMemRegionTree.parse_iomem_tree(
> IOMemRegionTree.parse_iomem_file())
>
> rom_region = MemRegion(0xc, 0xd, 'ROMs')
> add_rom_region = False
>
> ret = []
> -dmar_regions = []
> +
> for r in regions:
> append_r = True
> # filter the list for MSI-X pages
> @@ -249,9 +252,14 @@ def parse_dmar(pcidevices, ioapics,
> dmar_regions): if d.iommu is None:
> d.iommu = len(units) - 1
> offset += 16 - offset
> +print('DRHD: struct_len: %d offset: %2d -> flags: %d
> segment: %d base: 0x%x ' % (struct_len, offset, flags, segment,
> base)) + while offset < struct_len:
> (scope_type, scope_len, id, bus, dev, fn) =\
> parse_dmar_devscope(f)
> +
> +print('DevScope: offset: %2d -> scope_type: %d
> scope_len: %d id: %d bus: %d dev: %d fn: %d' % (offset, scope_type,
> scope_len, id, bus, dev, fn)) + # PCI Endpoint Device
> if scope_type == 1:
> assert not (flags & 1)
> @@ -290,11 +298,15 @@ def parse_dmar(pcidevices, ioapics,
> dmar_regions): offset += 8 - offset
> (base, limit) = struct.unpack(' offset += 16
> +print('RMRR: struct_len: %d offset: %2d -> base: 0x%x
> limit: %d ' % (struct_len, offset, base, limit))
> comments = []
> while offset < struct_len:
> (scope_type, scope_len, id, bus, dev, fn) =\
> parse_dmar_devscope(f)
> +
> +print('DevScope: offset: %2d -> scope_type: %d
> scope_len: %d id: %d bus: %d dev: %d fn: %d' % (offset, scope_type,
> scope_len, id, bus, dev, fn)) + if scope_type == 1:
> comments.append('PCI device: %02x:%02x.%x' %
> (bus, dev, fn))
> @@ -860,21 +872,21 @@ class IOMemRegionTree:
>
> return root
>
> -# find HPET regions in tree
> +# find specific regions in tree
> @staticmethod
> -def find_hpet_regions(tree):
> +def find_regions_by_name(tree, string):
> regions = []
>
> for tree in tree.children:
> r = tree.region
> s = r.typestr
>
> -if (s.find('HPET') >= 0):
> +if (s.find(string) >= 0):
> regions.append(r)
>
> # if the tree continues recurse further down ...
> if (len(tree.children) > 0):
> -
> regions.extend(IOMemRegionTree.find_hpet_regions(tree))
> +
> regions.extend(IOMemRegionTree.find_regions_by_name(tree, string))
> return regions
>
> @@ -882,6 +894,7 @@ class IOMemRegionTree:
> @staticmethod
> def parse_iomem_tree(tree):
> regions = []
> +dmar_regions = []
>
> for tree in tree.children:
> r = tree.region
> @@ -901,20 +914,23 @@ class IOMemRegionTree:
> ):
> continue
>
> -# generally blacklisted, unless we find an HPET behind it
> +# generally blacklisted, with a few exceptions
> if (s.lower() == 'reserved'):
> -
> regions.extend(IOMemRegionTree.find_hpet_regions(tree))
> +
> regions.extend(IOMemRegionTree.find_regions_by_name(tree, 'HPET'))
> +
> dmar_regions.extend(IOMemRegionTree.find_regions_by_name(tree,
> 'dmar')) continue
> # if the tree continues recurse further down ...
> if (len(tree.children) > 0):
> -
> regions.extend(IOMemRegionTree.parse_iomem_tree(tree))
> +
Re: [PATCH] Scripts: Fix for Parsing DMAR Region under Reserved Section
Hi Hakki,
maybe you can comment inline as well. So everybody can see what part of
the mail you refer to.
Now as far as i can tell you are explaining the difference of call by
value and by ref and how that affects return values. I think i already
know the basics of that.
My comment just was that
value = function(ref0)
is not a good pattern when the existing code is using
value, value0 = function()
Say we did not already have the above pattern, the following would be
possible and not mixing up both
function(ref, ref0)
Now i think there were more comments, so let us take this back inline.
Henning
Am Mon, 6 May 2019 07:45:46 -0700
schrieb Hakkı Kurumahmut :
> Hi Henning,
>
> I am not a python expert. But it works because list is a mutable type.
>
> https://stackoverflow.com/questions/986006/how-do-i-pass-a-variable-by-reference/986145#986145
>
> Some Link content:
>
> Arguments are passed by assignment. The rationale behind this is two
> fold:
>
> the parameter passed in is actually a reference to an object (but the
> reference is passed by value) some data types are mutable, but others
> aren't So:
>
> If you pass a mutable object into a method, the method gets a
> reference to that same object and you can mutate it to your heart's
> delight, but if you rebind the reference in the method, the outer
> scope will know nothing about it, and after you're done, the outer
> reference will still point at the original object.
>
> If you pass an immutable object to a method, you still can't rebind
> the outer reference, and you can't even mutate the object.
>
> To make it even more clear, let's have some examples.
>
> List - a mutable type
> Let's try to modify the list that was passed to a method:
>
> def try_to_change_list_contents(the_list):
> print('got', the_list)
> the_list.append('four')
> print('changed to', the_list)
>
> outer_list = ['one', 'two', 'three']
>
> print('before, outer_list =', outer_list)
> try_to_change_list_contents(outer_list)
> print('after, outer_list =', outer_list)
> Output:
>
> before, outer_list = ['one', 'two', 'three']
> got ['one', 'two', 'three']
> changed to ['one', 'two', 'three', 'four']
> after, outer_list = ['one', 'two', 'three', 'four']
> Since the parameter passed in is a reference to outer_list, not a
> copy of it, we can use the mutating list methods to change it and
> have the changes reflected in the outer scope.
>
>
> HAKKI
>
--
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: [PATCH] Scripts: Fix for Parsing DMAR Region under Reserved Section
Hi Hakki,
you found the right spot to exclude something from the generally
blacklisted "reserved" but i still have a few comments, find them
inline.
Am Sun, 5 May 2019 12:35:49 -0700
schrieb Hakkı Kurumahmut :
> While kernel command parameters are intel_iommu=on intremap=on at
> some machines, cat /proc/iomem shows DMAR region under reserved
> section. This patch must be done for config creation to complete
> because of generating DMAR region not found error although it exist.
> If this patch is not apply, below error is throw by "cell create"
> command whether intel_iommu On or Off because "reserved" regions are
> currently excluded from the generated config although DMAR region
> exists. Thus, DMAR under reserved section must be parsed by parser.
>
>
> if size == 0:
> raise RuntimeError('DMAR region size cannot be
> identified.\n' 'Target Linux must run with Intel IOMMU '
>'enabled.')
>
>
> git diff
> diff --git a/pyjailhouse/sysfs_parser.py
> b/pyjailhouse/sysfs_parser.py index 46c95fc2..70fe8869 100644
> --- a/pyjailhouse/sysfs_parser.py
> +++ b/pyjailhouse/sysfs_parser.py
> @@ -94,14 +94,13 @@ def input_listdir(dir, wildcards):
>
>
> def parse_iomem(pcidevices):
> -regions = IOMemRegionTree.parse_iomem_tree(
> -IOMemRegionTree.parse_iomem_file())
> +dmar_regions = []
> +regions =
> IOMemRegionTree.parse_iomem_tree(IOMemRegionTree.parse_iomem_file(),
> dmar_regions) rom_region = MemRegion(0xc, 0xd, 'ROMs')
> add_rom_region = False
This is confusing. I guess parse_iomem_tree should return (regions,
dmar_regions). Here you mix returning by value and by ref.
> ret = []
> -dmar_regions = []
> for r in regions:
> append_r = True
> # filter the list for MSI-X pages
> @@ -878,9 +877,27 @@ class IOMemRegionTree:
>
> return regions
>
> +# find DMAR regions in tree
> +@staticmethod
> +def find_dmar_regions(tree):
> +regions = []
> +
> +for tree in tree.children:
> +r = tree.region
> +s = r.typestr
> +
> +if (s.find('dmar') >= 0):
> +regions.append(r)
> +
> +# if the tree continues recurse further down ...
> +if (len(tree.children) > 0):
> +
> regions.extend(IOMemRegionTree.find_dmar_regions(tree))
> +
> +return regions
This is just a copy of find_hpet_regions. I would suggest to change the
original to i.e. "find_regions_by_name(tree, name)"
And now call that once with name="HPET" and once with name="dmar".
> # recurse down the tree
> @staticmethod
> -def parse_iomem_tree(tree):
> +def parse_iomem_tree(tree, dmar_regions):
>
> regions = []
>
> for tree in tree.children:
> @@ -904,11 +921,12 @@ class IOMemRegionTree:
>
> # generally blacklisted, unless we find an HPET behind
This is now incorrect. Change to i.e. "# generally blacklisted, with a
few exceptions"
Henning
> it if (s.lower() == 'reserved'):
> regions.extend(IOMemRegionTree.find_hpet_regions(tree))
> +
> dmar_regions.extend(IOMemRegionTree.find_dmar_regions(tree)) continue
>
>
> # if the tree continues recurse further down ...
> if (len(tree.children) > 0):
> -
> regions.extend(IOMemRegionTree.parse_iomem_tree(tree))
> +
> regions.extend(IOMemRegionTree.parse_iomem_tree(tree, dmar_regions))
> continue
> # add all remaining leaves
>
>
> Example /proc/iomem
>
> "intel_iommu=on intremap=on"
>
> You can see that dmar0 under Reserved region.
>
> ubuntu@ubuntu-HP8300:~$ sudo cat /proc/iomem
> -0fff : Reserved
> 1000-0009 : System RAM
> 000a-000b : PCI Bus :00
> 000c-000ce9ff : Video ROM
> 000cf000-000c : Adapter ROM
> 000d-000d3fff : PCI Bus :00
> 000d4000-000d7fff : PCI Bus :00
> 000d8000-000dbfff : PCI Bus :00
> 000dc000-000d : PCI Bus :00
> 000f-000f : System ROM
> 0010-38ff : System RAM
> 3900-78ff : Reserved
> 7900-de35bfff : System RAM
> de35c000-de365fff : Unknown E820 type
> de366000-de3e6fff : Reserved
> de3e7000-de414fff : Unknown E820 type
> de415000-de93efff : Reserved
> de93f000-deba4fff : ACPI Non-volatile Storage
> deba5000-debb5fff : ACPI Tables
> debb6000-debbefff : ACPI Non-volatile Storage
> debbf000-debc3fff : ACPI Tables
> debc4000-dec06fff : ACPI Non-volatile Storage
> dec07000-deff : System RAM
> df00-dfff : RAM buffer
> e000-feaf : PCI Bus :00
> e000-efff : PCI Bus :01
> e000-efff : :01:00.0
> f000-ffff : pnp 00:0a
> f7e0-f7ef : PCI Bus :01
> f7e2-f7e3 : :01:00.0
> f7f0-f7f1 : :00:19.0
> f7f0-f7f1 : e1000e
> f7f2-f7f2 : :00:14.0
> f7f2-
Re: [PATCH 5/5] pyjailhouse: let the generator produce speaking names for PCI caps
Am Thu, 2 May 2019 16:34:35 +0200 schrieb Ralf Ramsauer : > On 5/2/19 4:14 PM, Henning Schild wrote: > > Am Thu, 2 May 2019 12:19:10 +0200 > > schrieb Ralf Ramsauer : > > > >> Hi, > >> > >> On 5/2/19 10:31 AM, Henning Schild wrote: > >>> Hi Ralf, > >>> > >>> redefining the "Enum" seems not too elegant. Did you look into > >>> ways to use the header from python? > >> > >> Duplicating things is in deed not the most elegant way, but it's > >> the way how we handle other magic constants as well. > >> > >> Didn't yet look at any alternatives. > >> > >>> > >>> The "defines" should be really easy to parse without even using a > >>> special python library. The only real problem might be locating > >>> the header, it would need to be installed when running > >>> "installed" or relative when running "local". > >> > >> We could create a pyjailhouse/pcicaps.py during compilation phase. > >> Make/sed magic could create the python file from a stub. This is > >> basically the same how we create generated C headers. > >> > >> This would a) autocreate the "Enum" and make it easy to maintain > >> and b) solve the problem when being installed. > >> > >> What do you think about this? > > > > Not sure the extra make before the first use would be nice or > > acceptable. The python code could be generated inside pip, in which > > case you want to have a solution for non-pip users. > > Maybe we're not talking about the same thing. > > I'd simply use a small template for the skeleton of the python file, > use sed and friends to fill its content based on C headers and copy > it over to its final destination (e.g., pyjailhouse/pci_caps.py). I see, have a generated copy in the tree instead of just shipping the generator. Reminds me of autotools and make ;). Henning > There's no overlap with Pip. Pip won't care how this file was > generated. > > > Maybe generate the python code from the header with pip, if the > > python code is not there fall back to using magic numbers. > > > > Or we stick with the copy and wait for the first inconsistency to > > make us follow up ;). > > Yeah, that's the easiest way. But maybe it's worth sourcing out those > classes to a separate python file in any case. > > BTW, there's one nice thing about those python Enums: > > They will raise an expection if we get an unknown PCI cap id (which > should never happen, though). If it happens, this gives a hint that we > either lack a definition, or something really odd is going on. > > Ralf > > > > > Henning > > > >> Ralf > >> > >>> > >>> Henning > >>> > >>> Am Tue, 30 Apr 2019 23:45:04 +0200 > >>> schrieb Ralf Ramsauer : > >>> > >>>> Definitions on C-side are in place, so let the generator produce > >>>> those definitions. > >>>> > >>>> Signed-off-by: Ralf Ramsauer > >>>> --- > >>>> pyjailhouse/sysfs_parser.py | 79 > >>>> +++ > >>>> tools/root-cell-config.c.tmpl | 6 +-- 2 files changed, 72 > >>>> insertions(+), 13 deletions(-) > >>>> > >>>> diff --git a/pyjailhouse/sysfs_parser.py > >>>> b/pyjailhouse/sysfs_parser.py index 4bb50605..368714b0 100644 > >>>> --- a/pyjailhouse/sysfs_parser.py > >>>> +++ b/pyjailhouse/sysfs_parser.py > >>>> @@ -22,6 +22,8 @@ import struct > >>>> import os > >>>> import fnmatch > >>>> > >>>> +from enum import Enum > >>>> + > >>>> root_dir = "/" > >>>> > >>>> def set_root_dir(dir): > >>>> @@ -542,6 +544,65 @@ class PCIBARs: > >>>> f.close() > >>>> > >>>> > >>>> +class PCI_CAP_ID(Enum): > >>>> +PM = 0x01 # Power Management > >>>> +VPD= 0x03 # Vital Product Data > >>>> +MSI= 0x05 # Message Signalled Interrupts > >>>> +HT = 0x08 # HyperTransport > >>>> +VNDR = 0x09 # Vendor-Specific > >>>> +DBG= 0x0A # Debug port > >>>> +SSVID = 0x0D # Bridge subsystem vend
Re: [PATCH 1/5] configs: define ARRAY_SIZE in cell-config.h
Am Thu, 2 May 2019 12:10:34 +0200 schrieb Ralf Ramsauer : > Hi, > > On 5/2/19 10:23 AM, Henning Schild wrote: > > Hi Ralf, > > > > good idea! What happens if i through my "legacy" config on that? In > > that case i would expect one define inside + one in the header. The > > header will win, will the config-one cause an issue. I would expect > > at least a warning, which is probably fine. > > Easy to find out: Simply re-introduce the definition of ARRAY_SIZE in > a configuration again. > > My compiler (gcc 8.3.0) doesn't even warn. I assume this is because > definition and redefinition are textually equivalent. Right. Even an old debian9 gcc 6.3.0 will not complain, just if the two definitions differ, there will be a warning. Henning > Ralf > > > > > Henning > > > > Am Tue, 30 Apr 2019 23:45:00 +0200 > > schrieb Ralf Ramsauer : > > > >> instead of defining this useful macro in every single config file. > >> > >> There's only one quirk: ARRAY_SIZE is defined for hypervisor code > >> in util.h, which we can't include in cell-config.h, as it's > >> GPL-only. So we have to duplicate the definitions, which might > >> lead to redefinitions of the macro. Hence, surround the macro by > >> guards. > >> > >> Also remove the macro from the root cell template. > >> > >> Signed-off-by: Ralf Ramsauer > >> --- > >> configs/arm/bananapi-gic-demo.c | 2 -- > >> configs/arm/bananapi-linux-demo.c | 2 -- > >> configs/arm/bananapi-uart-demo.c | 2 -- > >> configs/arm/bananapi.c| 2 -- > >> configs/arm/emtrion-rzg1e-linux-demo.c| 2 -- > >> configs/arm/emtrion-rzg1e-uart-demo.c | 2 -- > >> configs/arm/emtrion-rzg1e.c | 2 -- > >> configs/arm/emtrion-rzg1h-linux-demo.c| 2 -- > >> configs/arm/emtrion-rzg1h-uart-demo.c | 2 -- > >> configs/arm/emtrion-rzg1h.c | 2 -- > >> configs/arm/emtrion-rzg1m-linux-demo.c| 2 -- > >> configs/arm/emtrion-rzg1m-uart-demo.c | 2 -- > >> configs/arm/emtrion-rzg1m.c | 2 -- > >> configs/arm/jetson-tk1-demo.c | 2 -- > >> configs/arm/jetson-tk1-linux-demo.c | 2 -- > >> configs/arm/jetson-tk1.c | 2 -- > >> configs/arm/orangepi0-gic-demo.c | 2 -- > >> configs/arm/orangepi0-linux-demo.c| 2 -- > >> configs/arm/orangepi0.c | 2 -- > >> configs/arm64/amd-seattle-gic-demo.c | 2 -- > >> configs/arm64/amd-seattle-linux-demo.c| 2 -- > >> configs/arm64/amd-seattle-uart-demo.c | 2 -- > >> configs/arm64/amd-seattle.c | 2 -- > >> configs/arm64/espressobin-gic-demo.c | 2 -- > >> configs/arm64/espressobin-linux-demo.c| 2 -- > >> configs/arm64/espressobin.c | 2 -- > >> configs/arm64/foundation-v8-gic-demo.c| 2 -- > >> configs/arm64/foundation-v8-linux-demo.c | 2 -- > >> configs/arm64/foundation-v8-uart-demo.c | 2 -- > >> configs/arm64/foundation-v8.c | 2 -- > >> configs/arm64/hikey-gic-demo.c| 2 -- > >> configs/arm64/hikey-linux-demo.c | 2 -- > >> configs/arm64/hikey.c | 2 -- > >> configs/arm64/imx8mq-gic-demo.c | 2 -- > >> configs/arm64/imx8mq.c| 2 -- > >> configs/arm64/jetson-tx1-demo.c | 2 -- > >> configs/arm64/jetson-tx1-linux-demo.c | 2 -- > >> configs/arm64/jetson-tx1.c| 2 -- > >> configs/arm64/jetson-tx2-demo.c | 2 -- > >> configs/arm64/jetson-tx2.c| 2 -- > >> configs/arm64/k3-am654-gic-demo.c | 2 -- > >> configs/arm64/k3-am654-idk-linux-demo.c | 2 -- > >> configs/arm64/k3-am654-idk.c | 2 -- > >> configs/arm64/k3-am654-uart-demo.c| 2 -- > >> configs/arm64/macchiatobin-gic-demo.c | 2 -- > >> configs/arm64/macchiatobin-linux-demo.c | 2 -- > >> configs/arm64/macchiatobin.c | 2 -- > >> configs/arm64/miriac-sbc-ls1046a-gic-demo.c | 2 -- > >> configs/arm64/miriac-sbc-ls1046a-linux-demo.c | 2 -- > >> configs/arm64/miriac-sbc-ls1046a.c| 2 -- > >&g
Re: [PATCH 5/5] pyjailhouse: let the generator produce speaking names for PCI caps
Am Thu, 2 May 2019 12:19:10 +0200 schrieb Ralf Ramsauer : > Hi, > > On 5/2/19 10:31 AM, Henning Schild wrote: > > Hi Ralf, > > > > redefining the "Enum" seems not too elegant. Did you look into ways > > to use the header from python? > > Duplicating things is in deed not the most elegant way, but it's the > way how we handle other magic constants as well. > > Didn't yet look at any alternatives. > > > > > The "defines" should be really easy to parse without even using a > > special python library. The only real problem might be locating the > > header, it would need to be installed when running "installed" or > > relative when running "local". > > We could create a pyjailhouse/pcicaps.py during compilation phase. > Make/sed magic could create the python file from a stub. This is > basically the same how we create generated C headers. > > This would a) autocreate the "Enum" and make it easy to maintain and > b) solve the problem when being installed. > > What do you think about this? Not sure the extra make before the first use would be nice or acceptable. The python code could be generated inside pip, in which case you want to have a solution for non-pip users. Maybe generate the python code from the header with pip, if the python code is not there fall back to using magic numbers. Or we stick with the copy and wait for the first inconsistency to make us follow up ;). Henning > Ralf > > > > > Henning > > > > Am Tue, 30 Apr 2019 23:45:04 +0200 > > schrieb Ralf Ramsauer : > > > >> Definitions on C-side are in place, so let the generator produce > >> those definitions. > >> > >> Signed-off-by: Ralf Ramsauer > >> --- > >> pyjailhouse/sysfs_parser.py | 79 > >> +++ tools/root-cell-config.c.tmpl | > >> 6 +-- 2 files changed, 72 insertions(+), 13 deletions(-) > >> > >> diff --git a/pyjailhouse/sysfs_parser.py > >> b/pyjailhouse/sysfs_parser.py index 4bb50605..368714b0 100644 > >> --- a/pyjailhouse/sysfs_parser.py > >> +++ b/pyjailhouse/sysfs_parser.py > >> @@ -22,6 +22,8 @@ import struct > >> import os > >> import fnmatch > >> > >> +from enum import Enum > >> + > >> root_dir = "/" > >> > >> def set_root_dir(dir): > >> @@ -542,6 +544,65 @@ class PCIBARs: > >> f.close() > >> > >> > >> +class PCI_CAP_ID(Enum): > >> +PM = 0x01 # Power Management > >> +VPD= 0x03 # Vital Product Data > >> +MSI= 0x05 # Message Signalled Interrupts > >> +HT = 0x08 # HyperTransport > >> +VNDR = 0x09 # Vendor-Specific > >> +DBG= 0x0A # Debug port > >> +SSVID = 0x0D # Bridge subsystem vendor/device ID > >> +SECDEV = 0x0F # Secure Device > >> +EXP= 0x10 # PCI Express > >> +MSIX = 0x11 # MSI-X > >> +SATA = 0x12 # SATA Data/Index Conf. > >> +AF = 0x13 # PCI Advanced Features > >> + > >> +def __str__(self): > >> +return "PCI_CAP_ID_" + self.name > >> + > >> + > >> +class PCI_EXT_CAP_ID(Enum): > >> +ZERO= 0x00 # ??? > >> + > >> +ERR = 0x01 # Advanced Error Reporting > >> +VC = 0x02 # Virtual Channel Capability > >> +DSN = 0x03 # Device Serial Number > >> +PWR = 0x04 # Power Budgeting > >> +RCLD= 0x05 # Root Complex Link Declaration > >> +RCILC = 0x06 # Root Complex Internal Link Control > >> +RCEC= 0x07 # Root Complex Event Collector > >> +MFVC= 0x08 # Multi-Function VC Capability > >> +VC9 = 0x09 # same as _VC > >> +RCRB= 0x0A # Root Complex RB? > >> +VNDR= 0x0B # Vendor-Specific > >> +CAC = 0x0C # Config Access - obsolete > >> +ACS = 0x0D # Access Control Services > >> +ARI = 0x0E # Alternate Routing ID > >> +ATS = 0x0F # Address Translation Services > >> +SRIOV = 0x10 # Single Root I/O Virtualization > >> +MRIOV = 0x11 # Multi Root I/O Virtualization > >> +MCAST = 0x12 # Multicast > >> +PRI = 0x13 # Page Request Interface > >> +AMD_XXX = 0x14 # Reserved for AMD > >> +REBAR = 0x15 # Resizable BAR > >> +DPA = 0x16 # Dynamic Power Allocation > >> +TPH
Re: [PATCH 5/5] pyjailhouse: let the generator produce speaking names for PCI caps
Hi Ralf,
redefining the "Enum" seems not too elegant. Did you look into ways to
use the header from python?
The "defines" should be really easy to parse without even using a
special python library. The only real problem might be locating the
header, it would need to be installed when running "installed" or
relative when running "local".
Henning
Am Tue, 30 Apr 2019 23:45:04 +0200
schrieb Ralf Ramsauer :
> Definitions on C-side are in place, so let the generator produce those
> definitions.
>
> Signed-off-by: Ralf Ramsauer
> ---
> pyjailhouse/sysfs_parser.py | 79
> +++ tools/root-cell-config.c.tmpl |
> 6 +-- 2 files changed, 72 insertions(+), 13 deletions(-)
>
> diff --git a/pyjailhouse/sysfs_parser.py b/pyjailhouse/sysfs_parser.py
> index 4bb50605..368714b0 100644
> --- a/pyjailhouse/sysfs_parser.py
> +++ b/pyjailhouse/sysfs_parser.py
> @@ -22,6 +22,8 @@ import struct
> import os
> import fnmatch
>
> +from enum import Enum
> +
> root_dir = "/"
>
> def set_root_dir(dir):
> @@ -542,6 +544,65 @@ class PCIBARs:
> f.close()
>
>
> +class PCI_CAP_ID(Enum):
> +PM = 0x01 # Power Management
> +VPD= 0x03 # Vital Product Data
> +MSI= 0x05 # Message Signalled Interrupts
> +HT = 0x08 # HyperTransport
> +VNDR = 0x09 # Vendor-Specific
> +DBG= 0x0A # Debug port
> +SSVID = 0x0D # Bridge subsystem vendor/device ID
> +SECDEV = 0x0F # Secure Device
> +EXP= 0x10 # PCI Express
> +MSIX = 0x11 # MSI-X
> +SATA = 0x12 # SATA Data/Index Conf.
> +AF = 0x13 # PCI Advanced Features
> +
> +def __str__(self):
> +return "PCI_CAP_ID_" + self.name
> +
> +
> +class PCI_EXT_CAP_ID(Enum):
> +ZERO= 0x00 # ???
> +
> +ERR = 0x01 # Advanced Error Reporting
> +VC = 0x02 # Virtual Channel Capability
> +DSN = 0x03 # Device Serial Number
> +PWR = 0x04 # Power Budgeting
> +RCLD= 0x05 # Root Complex Link Declaration
> +RCILC = 0x06 # Root Complex Internal Link Control
> +RCEC= 0x07 # Root Complex Event Collector
> +MFVC= 0x08 # Multi-Function VC Capability
> +VC9 = 0x09 # same as _VC
> +RCRB= 0x0A # Root Complex RB?
> +VNDR= 0x0B # Vendor-Specific
> +CAC = 0x0C # Config Access - obsolete
> +ACS = 0x0D # Access Control Services
> +ARI = 0x0E # Alternate Routing ID
> +ATS = 0x0F # Address Translation Services
> +SRIOV = 0x10 # Single Root I/O Virtualization
> +MRIOV = 0x11 # Multi Root I/O Virtualization
> +MCAST = 0x12 # Multicast
> +PRI = 0x13 # Page Request Interface
> +AMD_XXX = 0x14 # Reserved for AMD
> +REBAR = 0x15 # Resizable BAR
> +DPA = 0x16 # Dynamic Power Allocation
> +TPH = 0x17 # TPH Requester
> +LTR = 0x18 # Latency Tolerance Reporting
> +SECPCI = 0x19 # Secondary PCIe Capability
> +PMUX= 0x1A # Protocol Multiplexing
> +PASID = 0x1B # Process Address Space ID
> +DPC = 0x1D # Downstream Port Containment
> +L1SS= 0x1E # L1 PM Substates
> +PTM = 0x1F # Precision Time Measurement
> +
> +def __str__(self):
> +id = "0x00"
> +if self.value != 0:
> +id = "PCI_EXT_CAP_ID_" + self.name
> +return id + " | JAILHOUSE_PCI_EXT_CAP"
> +
> +
> class PCICapability:
> def __init__(self, id, start, len, flags, content, msix_address):
> self.id = id
> @@ -580,11 +641,12 @@ class PCICapability:
> msix_address = 0
> f.seek(cap)
> (id, next) = struct.unpack(' -if id == 0x01: # Power Management
> +id = PCI_CAP_ID(id)
> +if id == PCI_CAP_ID.PM:
> # this cap can be handed out completely
> len = 8
> flags = PCICapability.RW
> -elif id == 0x05: # MSI
> +elif id == PCI_CAP_ID.MSI:
> # access will be moderated by hypervisor
> len = 10
> (msgctl,) = struct.unpack(' @@ -593,7 +655,7 @@ class PCICapability:
> if (msgctl & (1 << 8)) != 0: # per-vector masking
> support len += 10
> flags = PCICapability.RW
> -elif id == 0x10: # Express
> +elif id == PCI_CAP_ID.EXP:
> len = 20
> (cap_reg,) = struct.unpack(' if (cap_reg & 0xf) >= 2: # v2 capability
> @@ -601,7 +663,7 @@ class PCICapability:
> # access side effects still need to be analyzed
> flags = PCICapability.RD
> has_extended_caps = True
> -elif id == 0x11: # MSI-X
> +elif id == PCI_CAP_ID.MSIX:
> # access will be moderated by hypervisor
> len = 12
> (table,) = struct.unpack(' @@ -637,8 +699,9 @@ class PCICapability:
>'Extended
Re: [PATCH 1/5] configs: define ARRAY_SIZE in cell-config.h
Hi Ralf, good idea! What happens if i through my "legacy" config on that? In that case i would expect one define inside + one in the header. The header will win, will the config-one cause an issue. I would expect at least a warning, which is probably fine. Henning Am Tue, 30 Apr 2019 23:45:00 +0200 schrieb Ralf Ramsauer : > instead of defining this useful macro in every single config file. > > There's only one quirk: ARRAY_SIZE is defined for hypervisor code in > util.h, which we can't include in cell-config.h, as it's GPL-only. So > we have to duplicate the definitions, which might lead to > redefinitions of the macro. Hence, surround the macro by guards. > > Also remove the macro from the root cell template. > > Signed-off-by: Ralf Ramsauer > --- > configs/arm/bananapi-gic-demo.c | 2 -- > configs/arm/bananapi-linux-demo.c | 2 -- > configs/arm/bananapi-uart-demo.c | 2 -- > configs/arm/bananapi.c| 2 -- > configs/arm/emtrion-rzg1e-linux-demo.c| 2 -- > configs/arm/emtrion-rzg1e-uart-demo.c | 2 -- > configs/arm/emtrion-rzg1e.c | 2 -- > configs/arm/emtrion-rzg1h-linux-demo.c| 2 -- > configs/arm/emtrion-rzg1h-uart-demo.c | 2 -- > configs/arm/emtrion-rzg1h.c | 2 -- > configs/arm/emtrion-rzg1m-linux-demo.c| 2 -- > configs/arm/emtrion-rzg1m-uart-demo.c | 2 -- > configs/arm/emtrion-rzg1m.c | 2 -- > configs/arm/jetson-tk1-demo.c | 2 -- > configs/arm/jetson-tk1-linux-demo.c | 2 -- > configs/arm/jetson-tk1.c | 2 -- > configs/arm/orangepi0-gic-demo.c | 2 -- > configs/arm/orangepi0-linux-demo.c| 2 -- > configs/arm/orangepi0.c | 2 -- > configs/arm64/amd-seattle-gic-demo.c | 2 -- > configs/arm64/amd-seattle-linux-demo.c| 2 -- > configs/arm64/amd-seattle-uart-demo.c | 2 -- > configs/arm64/amd-seattle.c | 2 -- > configs/arm64/espressobin-gic-demo.c | 2 -- > configs/arm64/espressobin-linux-demo.c| 2 -- > configs/arm64/espressobin.c | 2 -- > configs/arm64/foundation-v8-gic-demo.c| 2 -- > configs/arm64/foundation-v8-linux-demo.c | 2 -- > configs/arm64/foundation-v8-uart-demo.c | 2 -- > configs/arm64/foundation-v8.c | 2 -- > configs/arm64/hikey-gic-demo.c| 2 -- > configs/arm64/hikey-linux-demo.c | 2 -- > configs/arm64/hikey.c | 2 -- > configs/arm64/imx8mq-gic-demo.c | 2 -- > configs/arm64/imx8mq.c| 2 -- > configs/arm64/jetson-tx1-demo.c | 2 -- > configs/arm64/jetson-tx1-linux-demo.c | 2 -- > configs/arm64/jetson-tx1.c| 2 -- > configs/arm64/jetson-tx2-demo.c | 2 -- > configs/arm64/jetson-tx2.c| 2 -- > configs/arm64/k3-am654-gic-demo.c | 2 -- > configs/arm64/k3-am654-idk-linux-demo.c | 2 -- > configs/arm64/k3-am654-idk.c | 2 -- > configs/arm64/k3-am654-uart-demo.c| 2 -- > configs/arm64/macchiatobin-gic-demo.c | 2 -- > configs/arm64/macchiatobin-linux-demo.c | 2 -- > configs/arm64/macchiatobin.c | 2 -- > configs/arm64/miriac-sbc-ls1046a-gic-demo.c | 2 -- > configs/arm64/miriac-sbc-ls1046a-linux-demo.c | 2 -- > configs/arm64/miriac-sbc-ls1046a.c| 2 -- > configs/arm64/qemu-arm64-gic-demo.c | 2 -- > configs/arm64/qemu-arm64-linux-demo.c | 2 -- > configs/arm64/qemu-arm64.c| 2 -- > configs/arm64/ultra96-gic-demo.c | 2 -- > configs/arm64/ultra96-linux-demo.c| 2 -- > configs/arm64/ultra96.c | 2 -- > configs/arm64/zynqmp-zcu102-gic-demo.c| 2 -- > configs/arm64/zynqmp-zcu102-linux-demo-2.c| 2 -- > configs/arm64/zynqmp-zcu102-linux-demo.c | 2 -- > configs/arm64/zynqmp-zcu102.c | 2 -- > configs/x86/apic-demo.c | 2 -- > configs/x86/e1000-demo.c | 2 -- > configs/x86/f2a88xm-hd3.c | 2 -- > configs/x86/imb-a180.c| 2 -- > configs/x86/ioapic-demo.c | 2 -- > configs/x86/ivshmem-demo.c| 2 -- > configs/x86/linux-x86-demo.c | 2 -- > configs/x86/pci-demo.c| 2 -- > configs/x86/qemu-x86.c| 2 -- > configs/x86/smp-demo.c| 2 -- > configs/x86/tiny-demo.c | 2 -- > hypervisor/include/jailhouse/utils.h | 2 ++ > include/jailhouse/cell-config.h | 4 > tools/root-cell-config.c.tmpl | 2 -- > 74 files changed, 6 insertions(+), 144 deletions(-) > > diff --git a/configs/arm/b
Re: jailhouse config create sysconfig.c mem_region doesn't match /proc/iomem
Am Thu, 18 Apr 2019 04:32:19 -0700
schrieb :
> Hello,
>
>
> I just start to try to install jailhouse on my card with ubuntu
> 16.04.3.
I actually still found such an old thing in our lab. Kernel 3.13 ... is
the default on that Distribution. Which kernel version are you using?
I do not know the jailhouse requirements by heart, but going below 4.9
is probably not the best idea.
regards,
Henning
> I can generate my "jailhouse config create my_sysconfig.c" but when I
> try to enable the cell, I get an error:
>
> jailhouse: request_mem_region failed for hypervisor memory.
>
>
>
> Looking at my file my_sysconfig.c I realize that the .mem_regions do
> not match the ones I find in /proc/iomem (as well as the number of
> cpus).
>
> here is an extract of my_sysconfig.c :
>
> ---
>
> .cpus = {
> 0x,
> },
>
> .mem_regions = {
> /* MemRegion: -0009 : System RAM */
> {
> .phys_start = 0x0,
> .virt_start = 0x0,
> .size = 0xa,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_DMA,
> },
> /* MemRegion: 0010-01ff : System RAM */
> {
> .phys_start = 0x10,
> .virt_start = 0x10,
> .size = 0x1f0,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_DMA,
> },
> /* MemRegion: 0200-03ff : Kernel */
> {
> .phys_start = 0x200,
> .virt_start = 0x200,
> .size = 0x200,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_DMA,
> },
> /* MemRegion: 0400-39ff : System RAM */
> {
> .phys_start = 0x400,
> .virt_start = 0x400,
> .size = 0x3600,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_DMA,
> },
> /* MemRegion: 3f20-6a720fff : System RAM */
> {
> .phys_start = 0x3f20,
> .virt_start = 0x3f20,
> .size = 0x2b521000,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_DMA,
> },
> /* MemRegion: 6c821000-6c942fff : System RAM */
> {
> .phys_start = 0x6c821000,
> .virt_start = 0x6c821000,
> .size = 0x122000,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_DMA,
> },
> /* MemRegion: 6c943000-6d496fff : ACPI Non-volatile
> Storage */ {
> .phys_start = 0x6c943000,
> .virt_start = 0x6c943000,
> .size = 0xb54000,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE, },
> /* MemRegion: 6f2e6000-6f7f : System RAM */
> {
> .phys_start = 0x6f2e6000,
> .virt_start = 0x6f2e6000,
> .size = 0x51a000,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_DMA,
> },
> /* MemRegion: a900-a9ff : :02:00.0 */
> {
> .phys_start = 0xa900,
> .virt_start = 0xa900,
> .size = 0x100,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE, },
> /* MemRegion: aa00-aa01 : :02:00.0 */
> {
> .phys_start = 0xaa00,
> .virt_start = 0xaa00,
> .size = 0x2,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE, },
> /* MemRegion: aa10-aa17 : igb */
> {
> .phys_start = 0xaa10,
> .virt_start = 0xaa10,
> .size = 0x8,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE, },
> /* MemRegion: aa181000-aa183fff : igb */
> {
> .phys_start = 0xaa181000,
> .virt_start = 0xaa181000,
> .size = 0x3000,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE, },
> /* MemRegion: aa20-aa27
Re: Non-root linux with storage devices?
Hi, i have done that before but can not point you to the code. You have two options: 1. assign a complete storage device - you will need multiple truly seperate devices/conrtrollers 2. use a network filesystem (i.e. nfs) over a virtual network - your non-root will depend on root to be available regards, Henning Am Thu, 18 Apr 2019 05:08:37 -0700 schrieb yshala : > Is there any example which can guide the creation of non-root guest > with persistent state? > -- 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: How are we supposed to setup sysconfig?
Am Sun, 7 Apr 2019 21:25:52 -0700
schrieb yshala :
> FATAL: Invalid PIO write, port: 0 size: 2
> RIP: 0x RSP: 0xfffa FLAGS: 93
> RAX: 0xc9cd RBX: 0x RCX:
> 0x RDX: 0x RSI: 0x
> RDI: 0x CS: 0 BASE: 0x AR-BYTES: 9b
> EFER.LMA 0 CR0: 0x0030 CR3: 0x CR4:
> 0x2000 EFER: 0x
> Parking CPU 3 (Cell: "apic-demo")
>
> FATAL: Invalid PIO read, port: cac size: 1
> RIP: 0xc038db02 RSP: 0xc900203e7b78 FLAGS: 6
> RAX: 0xc038daf0 RBX: 0x880c19171000 RCX:
> 0x RDX: 0x0cac RSI: 0x0004
> RDI: 0x880c18471c40 CS: 10 BASE: 0x AR-BYTES:
> a09b EFER.LMA 1 CR0: 0x80050033 CR3: 0x002408f4a006 CR4:
> 0x007626e0 EFER: 0x0d01
> Parking CPU 11 (Cell: "RootCell")
>
>
> Confused about how to setup these port-based io. The first PIO
> failure occurs in vcpu.c when the PIO emulation discovers an access
> via instruction with rep/str prefix/type.
>
> The second one seems to be because of ipmi pio.
Note that you always have two options, either allow PIO or disable the
driver. IPMI can potentially be used for power cycling and similar
things.
Henning
> Okay, so what does this mean? In the first case, I have no clue.
>
> In the second case, is it just a case of an access in the IPMI
> handler being trapped by the root-cell and not having the proper PIO
> bitmap?? But I changed it to 0 in the sysconfig.c. Here is my
> piobitmap:
>
> """
> .pio_bitmap = {
> [ 0/8 ... 0x3f/8] = -1,
> [ 0x40/8 ... 0x47/8] = 0xf0, /* PIT */
> [ 0x48/8 ... 0x5f/8] = -1,
> [ 0x60/8 ... 0x67/8] = 0xec, /* HACK: NMI status/control
> */ [ 0x68/8 ... 0x6f/8] = -1,
> [ 0x70/8 ... 0x77/8] = 0xfc, /* RTC */
> [ 0x78/8 ... 0x3af/8] = -1,
> [ 0x3b0/8 ... 0x3df/8] = 0x00, /* VGA */
> [ 0x3e0/8 ... 0xc9f/8] = -1,
> [ 0x3e0/8 ... 0xc9f/8] = -1,
> [ 0xca0/8 ... 0xcaf/8] = 0, //Need to allow CAC and CA8...
> [ 0xcb0/8 ... 0xcff/8] = -1,
> [ 0xd00/8 ... 0x/8] = 0, /* HACK: PCI bus */
> },
>
> """
>
> Overall, I am pretty confused about what state I need to get
> sysconfig to.
>
--
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.
[siemens/jailhouse] c4963c: tools: hardware-check: Fix duplicate variable name...
Branch: refs/heads/next
Home: https://github.com/siemens/jailhouse
Commit: c4963cc113063ef3222a07ac64520767a54f05ab
https://github.com/siemens/jailhouse/commit/c4963cc113063ef3222a07ac64520767a54f05ab
Author: Jan Kiszka
Date: 2019-04-01 (Mon, 01 Apr 2019)
Changed paths:
M tools/jailhouse-hardware-check
Log Message:
---
tools: hardware-check: Fix duplicate variable name usage
We already use "n" for the outer loop that iterate over all IOMMUs. Make
the register offset calculation more readable at this chance.
Reported-by: Burak Atalay
Signed-off-by: Jan Kiszka
Commit: e989624e2ab70db6c399f66c316aa7ef63aa970c
https://github.com/siemens/jailhouse/commit/e989624e2ab70db6c399f66c316aa7ef63aa970c
Author: Andrej Utz
Date: 2019-04-01 (Mon, 01 Apr 2019)
Changed paths:
M pyjailhouse/sysfs_parser.py
Log Message:
---
pyjailhouse: sysfs_parser: Fix wrong IVRS device ID for IOAPIC
If the type of an IVHD device entry is a Special Device (0x48),
then device ID is stored at a different location. The code already
parsed the value to device_id_b, but it was never used.
This set the ID of all IOAPICs to 0x0 in the system configuration.
Fixes: 5fe206927c05 ("tools: Implement ACPI IVRS table parses")
Signed-off-by: Andrej Utz
Signed-off-by: Ralf Ramsauer
Signed-off-by: Jan Kiszka
Commit: eeed9ece00596cbaa332feaffe6166d6a694100e
https://github.com/siemens/jailhouse/commit/eeed9ece00596cbaa332feaffe6166d6a694100e
Author: Henning Schild
Date: 2019-04-01 (Mon, 01 Apr 2019)
Changed paths:
M configs/arm64/miriac-sbc-ls1046a.c
Log Message:
---
configs: miriac-sbc-ls1046a: remove mem region numbering
This commit just changes the comments and removes the indices from the
the region comments. These numbers make it hard to add or remove regions
without touching most of the file.
Signed-off-by: Henning Schild
Signed-off-by: Jan Kiszka
Commit: 03dc807daeb133fcd678ef87749033419b535cac
https://github.com/siemens/jailhouse/commit/03dc807daeb133fcd678ef87749033419b535cac
Author: Henning Schild
Date: 2019-04-01 (Mon, 01 Apr 2019)
Changed paths:
M configs/arm64/miriac-sbc-ls1046a.c
Log Message:
---
configs: miriac-sbc-ls1046a: move IVSHMEM region to end of array
Now that we are not counting anymore, find the one we need to index from
the ARRAY_SIZE.
Signed-off-by: Henning Schild
Signed-off-by: Jan Kiszka
Commit: 87437c42bf52c95407fb8a53202c7f2e715319a7
https://github.com/siemens/jailhouse/commit/87437c42bf52c95407fb8a53202c7f2e715319a7
Author: Henning Schild
Date: 2019-04-01 (Mon, 01 Apr 2019)
Changed paths:
M configs/arm64/miriac-sbc-ls1046a.c
Log Message:
---
configs: miriac-sbc-ls1046a: adjust memory flags for qbman portals
The qbman portal regions are split into two, cache-inhibited and
cache-enabled. (see DPAA_PORTAL_C[IE] in drivers/soc/fsl/qbman/)
When the underlying memory is not mapped correctly, like it was before
this commit, you will see TX errors and loose a significant amount of
packets on the DPAA NICs after jailhouse is enabled.
Signed-off-by: Henning Schild
Signed-off-by: Jan Kiszka
Compare:
https://github.com/siemens/jailhouse/compare/2b039faf401c...87437c42bf52
--
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: [PATCH 1/3] configs: miriac-sbc-ls1046a: remove mem region numbering
Am Tue, 26 Mar 2019 15:25:33 +0100
schrieb "[ext] Henning Schild" :
> Hey,
>
> the first two commits are purely cosmetic, and p3 fixes an issue i saw
> on a ls1043a-rdb. The whole series is not tested since i do not have
> the hardware to do so.
I could also prepare a commit with the ls1043a configs. But right now i
have the feeling they might not belong into jailhouse since we do have
a pretty similar example in there right now.
Let me know if they are still relevant and should be made
upstream-ready.
Henning
> Andreas could you please test this. Before the patch you should see a
> significant amount of packet loss after "jailhouse enable". Test
> command from a remote machine could be
>
> "fping -l ls1043 -b 1200 -p 10"
>
> After the patch the packet loss should get back down to 0% even when
> jailhouse is enabled.
>
> Henning
>
> Am Tue, 26 Mar 2019 15:19:57 +0100
> schrieb Henning Schild :
>
> > From: Henning Schild
> >
> > This commit just changes the comments and removes the indices from
> > the the region comments. These numbers make it hard to add or remove
> > regions without touching most of the file.
> >
> > Signed-off-by: Henning Schild
> > ---
> > configs/arm64/miriac-sbc-ls1046a.c | 100
> > ++--- 1 file changed, 50 insertions(+), 50
> > deletions(-)
> >
> > diff --git a/configs/arm64/miriac-sbc-ls1046a.c
> > b/configs/arm64/miriac-sbc-ls1046a.c index a8fb5b4c..98275d48 100644
> > --- a/configs/arm64/miriac-sbc-ls1046a.c
> > +++ b/configs/arm64/miriac-sbc-ls1046a.c
> > @@ -74,349 +74,349 @@ struct {
> > },
> >
> > .mem_regions = {
> > - /* 0 - DDR memory controller */ {
> > + /* DDR memory controller */ {
> > .phys_start = 0x0108,
> > .virt_start = 0x0108,
> > .size = 0x1000,
> > .flags = JAILHOUSE_MEM_READ |
> > JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> > },
> > - /* 1 - IFC */ {
> > + /* IFC */ {
> > .phys_start = 0x0153,
> > .virt_start = 0x0153,
> > .size = 0x1,
> > .flags = JAILHOUSE_MEM_READ |
> > JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> > },
> > - /* 2 - QSPI */ {
> > + /* QSPI */ {
> > .phys_start = 0x0155,
> > .virt_start = 0x0155,
> > .size = 0x1,
> > .flags = JAILHOUSE_MEM_READ |
> > JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> > },
> > - /* 3 - esdhc */ {
> > + /* esdhc */ {
> > .phys_start = 0x0156,
> > .virt_start = 0x0156,
> > .size = 0x1,
> > .flags = JAILHOUSE_MEM_READ |
> > JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> > },
> > - /* 4 - scfg */ {
> > + /* scfg */ {
> > .phys_start = 0x0157,
> > .virt_start = 0x0157,
> > .size = 0x1,
> > .flags = JAILHOUSE_MEM_READ |
> > JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> > },
> > - /* 5 - crypto */ {
> > + /* crypto */ {
> > .phys_start = 0x0170,
> > .virt_start = 0x0170,
> > .size = 0x10,
> > .flags = JAILHOUSE_MEM_READ |
> > JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> > },
> > - /* 6 - qman */ {
> > + /* qman */ {
> > .phys_start = 0x0188,
> > .virt_start = 0x0188,
> > .size = 0x1,
> > .flags = JAILHOUSE_MEM_READ |
> > JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> > },
> > -/* 7 - bman */ {
> > +/* bman */ {
> > .phys_start = 0x0189,
> > .virt_start = 0x0189,
> > .size = 0x1,
> > .flags = JAILHOUSE_MEM_READ |
> > JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> > },
> > - /* 8 - fman */ {
> > + /* fman */ {
> > .phys_start = 0x01a
Re: Running on AMD Ryzen
Am Wed, 27 Mar 2019 17:15:37 +0100 schrieb Ralf Ramsauer : > On 3/26/19 6:03 PM, Jan Kiszka wrote: > > On 26.03.19 17:41, Ralf Ramsauer wrote: > >> Hi Jan, > >> > >> On 3/25/19 4:03 PM, Jan Kiszka wrote: > >>> On 25.03.19 14:18, Andrej Utz wrote: > Greetings Jailhouse developers, > > I am trying to run Jailhouse on AMD Ryzen 2700X (x86_64) with > B450 chipset and > got into some problems. > > After whitelisting some I/O ports and putting "amd_iommu=off > mce=off" I managed > to enable Jailhouse, but instantly lost some USB ports (keyboard > being one of > them). After some retries I noticed this happens only 80 % of > the time and it > seems that some interrupts are never acknowledged and keep > blocking the USB hub. > > >>> > >>> A typical pattern if the interrupt controller (IOAPIC or even > >>> APIC) is directly > >>> accesses by the guest. Or of the MSI-X page of a PCI device is > >>> passed through. > >>> Double-check if none of the resources is guest-assigned. Jailhouse > >>> needs to > >>> intercept them. > >> > >> Looks like jailhouse-config-create might have issues with parsing > >> IVRS tables on AMD. This is why both irq chips had the same ID in > >> our config (cf. Andrej's attachment). > > > > Hmm, another variable shadowing like we have in > > jailhouse-hardware-check? > >> > >> Parsing the table with hexdump, AMD's manual and five fingers on > >> two hands gave us the correct ID. Andrej will provide a patch soon. > >> (BTW, the python-parsers are really hard to read) > > > > Improvement ideas welcome. > > > >> > >> So our APIC IDs were wrong in the system configuration, but still, > >> this doesn't solve the issue. > >> > >> I double checked that the APIC region is not directly assigned to > >> the guest. > >> > >> So in sum, we currently face two issues on AMD: > >> - Loose USB interrupts on enabling with high probability. > >> Disabling jailhouse works, but won't revive it. > >> - Loose our network device on cell create > >> > >> Somehow, those two problems smell related, and maybe the second > >> one is indirectly solved after solving the first one. Let's see. > > > > Do both interrupts have something in common? Maybe something other > > devices that > > still have working interrupts do not? Are they INTx, MSI, MSI-X? > > We had a Vodoo-Debugging session today. All interrupts that seem to > disappear are edge-triggered MSI-X interrupts. The first thing we > tried was pci=nomsi. This turns them to legacy IOAPIC interrupts, but > the problem pattern still remains the same. > > When using legacy interrupts, interrupts looked like this: > - IRQ 25: xhci (some USB 3.1 ports), enp3s0 > - IRQ 29: xhci (some other USB 3.0) > > So IRQ 25 seems to be shared. The funny thing is that while USB 3.0 > (IRQ 29) and enp3s0 (IRQ 25) died, USB 3.1 (also IRQ 25) still worked… > > After a while, we found that if there is no ethernet link (cable > disconnected) and no USB devices connected (we use a PS/2 keyboard for > enabling jh), everything seems to be stable after enabling jh. USB + > Ethernet works fine if we bring up devices after enabling. > > Yes, we tried turning it off and on again :-) Subsequent jailhouse > disable/enable sequences then seem to remain stable, it's look like > that it's 'important' that those devices are disconnected before > enabling jailhouse for the first time. > > So at least we found some pattern so far. Not sure if AMD has an SMI counter, but i wonder whether the BIOS is messing with you. BIOSs oftern emulate "good old" input devs until the OS initializes USB, for keyboard usage in the bootloader and so on. The NIC could have such a thing going on for PXE. Henning > Ralf > > > > > 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: FATAL: Invalid PIO read, port: 934 size: 1
Am Tue, 26 Mar 2019 21:17:45 -0700
schrieb :
> Hello,
>
> I used the root config generator to create a root config for my
> x86-64 Dell Inspiron running Kubuntu 18.04 (kernel 4.14). However,
> starting up the root cell usually causes the entire laptop to freeze
> soon after.
>
> I don’t have access to a serial console, but I am briefly able to see
> the jailhouse console output before the system freezes, with an error
> that reads:
>
> [Initializing processors, Initializing VT-d, IOAPIC, Cache Allocation
> Technology, PCI, PCI devices, etc.]
>
> Page pool usage after late setup: mem 355/975, remap 65545/131072
> Activating hypervisor
> FATAL: Invalid PIO read, port: 934 size: 1
> RIP: 0xa3f49be6 RSP: 0xb05b427c7718 FLAGS: 46
Find the RIP in the System.map of the kernel you are running. That will
tell you which function and which driver. Instead of just allowing the
access, as Jan suggested, you can also choose to not include that
driver into your kernel.
I am not sure if that will also work for drivers loaded as modules.
Henning
> RAX: 0x RBX: 0xa0057d734900 RCX:
> 0x0004 RDX: 0x0934 RSI: 0xa4896780
> RDI: 0x028a CS: 10 BASE: 0x AR-BYTES:
> a09b EFER.LMA 1 CR0: 0x80050033 CR3: 0x000336d74001 CR4:
> 0x003626f0 EFER: 0x0d01
> Parking CPU 0 (Cell: "RootCell")
>
> Note: 934 is hex, not decimal (the error is originating from
> hypervisor/arch/x86/vcpu.c -> vcpu_handle_io_access()).
>
> PIO doesn't seem to be configured properly, but I’m not sure what to
> change. Here is the pio_bitmap in my root config:
>
> .pio_bitmap = {
> [ 0/8 ... 0x3f/8] = -1,
> [ 0x40/8 ... 0x47/8] = 0xf0, /* PIT */
> [ 0x48/8 ... 0x5f/8] = -1,
> [ 0x60/8 ... 0x67/8] = 0xec, /* HACK: NMI
> status/control */ [ 0x68/8 ... 0x6f/8] = -1,
> [ 0x70/8 ... 0x77/8] = 0xfc, /* RTC */
> [ 0x78/8 ... 0x3af/8] = -1,
> [ 0x3b0/8 ... 0x3df/8] = 0x00, /* VGA */
> [ 0x3e0/8 ... 0xcff/8] = -1,
> [ 0xd00/8 ... 0x/8] = 0, /* HACK: PCI bus */
> },
>
> As you can see, 0x934 (it's between 0x3e0 and 0xcff) is set to all
> 1’s (-1). I’m assuming that 0’s are needed to enable access to
> whatever is at 0x934, but I’m not sure which bits to set to 0 and for
> which bytes.
>
> Here is what /proc/ioports shows:
>
> -0cf7 : PCI Bus :00
> -001f : dma1
> 0020-0021 : pic1
> 0040-0043 : timer0
> 0050-0053 : timer1
> 0060-0060 : keyboard
> 0064-0064 : keyboard
> 0070-0077 : rtc0
> 0080-008f : dma page reg
> 00a0-00a1 : pic2
> 00c0-00df : dma2
> 00f0-00ff : fpu
> 0680-069f : pnp 00:00
> 0930-0930 : PNP0C09:00
> 0930-0930 : EC data
> 0934-0934 : PNP0C09:00
> 0934-0934 : EC cmd
> 0cf8-0cff : PCI conf1
> 0d00- : PCI Bus :00
> 164e-164f : pnp 00:00
> 1800-18fe : pnp 00:00
> 1800-1803 : ACPI PM1a_EVT_BLK
> 1804-1805 : ACPI PM1a_CNT_BLK
> 1808-180b : ACPI PM_TMR
> 1850-1850 : ACPI PM2_CNT_BLK
> 1854-1857 : pnp 00:02
> 1880-189f : ACPI GPE0_BLK
> f000-f03f : :00:02.0
> f040-f05f : :00:1f.4
> f060-f07f : :00:17.0
> f060-f07f : ahci
> f080-f083 : :00:17.0
> f080-f083 : ahci
> f090-f097 : :00:17.0
> f090-f097 : ahci
> ff00-fffe : pnp 00:07
> - : pnp 00:00
> - : pnp 00:00
> - : pnp 00:00
>
> Any ideas on what I need to do, or how to debug this?
>
> Thanks,
> -Michael
>
--
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: [PATCH 1/3] configs: miriac-sbc-ls1046a: remove mem region numbering
Hey,
the first two commits are purely cosmetic, and p3 fixes an issue i saw
on a ls1043a-rdb. The whole series is not tested since i do not have
the hardware to do so.
Andreas could you please test this. Before the patch you should see a
significant amount of packet loss after "jailhouse enable". Test
command from a remote machine could be
"fping -l ls1043 -b 1200 -p 10"
After the patch the packet loss should get back down to 0% even when
jailhouse is enabled.
Henning
Am Tue, 26 Mar 2019 15:19:57 +0100
schrieb Henning Schild :
> From: Henning Schild
>
> This commit just changes the comments and removes the indices from the
> the region comments. These numbers make it hard to add or remove
> regions without touching most of the file.
>
> Signed-off-by: Henning Schild
> ---
> configs/arm64/miriac-sbc-ls1046a.c | 100
> ++--- 1 file changed, 50 insertions(+), 50
> deletions(-)
>
> diff --git a/configs/arm64/miriac-sbc-ls1046a.c
> b/configs/arm64/miriac-sbc-ls1046a.c index a8fb5b4c..98275d48 100644
> --- a/configs/arm64/miriac-sbc-ls1046a.c
> +++ b/configs/arm64/miriac-sbc-ls1046a.c
> @@ -74,349 +74,349 @@ struct {
> },
>
> .mem_regions = {
> - /* 0 - DDR memory controller */ {
> + /* DDR memory controller */ {
> .phys_start = 0x0108,
> .virt_start = 0x0108,
> .size = 0x1000,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> },
> - /* 1 - IFC */ {
> + /* IFC */ {
> .phys_start = 0x0153,
> .virt_start = 0x0153,
> .size = 0x1,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> },
> - /* 2 - QSPI */ {
> + /* QSPI */ {
> .phys_start = 0x0155,
> .virt_start = 0x0155,
> .size = 0x1,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> },
> - /* 3 - esdhc */ {
> + /* esdhc */ {
> .phys_start = 0x0156,
> .virt_start = 0x0156,
> .size = 0x1,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> },
> - /* 4 - scfg */ {
> + /* scfg */ {
> .phys_start = 0x0157,
> .virt_start = 0x0157,
> .size = 0x1,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> },
> - /* 5 - crypto */ {
> + /* crypto */ {
> .phys_start = 0x0170,
> .virt_start = 0x0170,
> .size = 0x10,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> },
> - /* 6 - qman */ {
> + /* qman */ {
> .phys_start = 0x0188,
> .virt_start = 0x0188,
> .size = 0x1,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> },
> -/* 7 - bman */ {
> +/* bman */ {
> .phys_start = 0x0189,
> .virt_start = 0x0189,
> .size = 0x1,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> },
> - /* 8 - fman */ {
> + /* fman */ {
> .phys_start = 0x01a0,
> .virt_start = 0x01a0,
> .size = 0x10,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> },
> - /* 9 - qportals */ {
> + /* qportals */ {
> .phys_start = 0x5,
> .virt_start = 0x5,
> .size = 0x800,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_IO,
> },
> - /* 10 - bportals */ {
> + /* bportals */ {
> .phys_start = 0x50800,
> .virt_start =
[PATCH 1/3] configs: miriac-sbc-ls1046a: remove mem region numbering
From: Henning Schild
This commit just changes the comments and removes the indices from the
the region comments. These numbers make it hard to add or remove regions
without touching most of the file.
Signed-off-by: Henning Schild
---
configs/arm64/miriac-sbc-ls1046a.c | 100 ++---
1 file changed, 50 insertions(+), 50 deletions(-)
diff --git a/configs/arm64/miriac-sbc-ls1046a.c
b/configs/arm64/miriac-sbc-ls1046a.c
index a8fb5b4c..98275d48 100644
--- a/configs/arm64/miriac-sbc-ls1046a.c
+++ b/configs/arm64/miriac-sbc-ls1046a.c
@@ -74,349 +74,349 @@ struct {
},
.mem_regions = {
- /* 0 - DDR memory controller */ {
+ /* DDR memory controller */ {
.phys_start = 0x0108,
.virt_start = 0x0108,
.size = 0x1000,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
- /* 1 - IFC */ {
+ /* IFC */ {
.phys_start = 0x0153,
.virt_start = 0x0153,
.size = 0x1,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
- /* 2 - QSPI */ {
+ /* QSPI */ {
.phys_start = 0x0155,
.virt_start = 0x0155,
.size = 0x1,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
- /* 3 - esdhc */ {
+ /* esdhc */ {
.phys_start = 0x0156,
.virt_start = 0x0156,
.size = 0x1,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
- /* 4 - scfg */ {
+ /* scfg */ {
.phys_start = 0x0157,
.virt_start = 0x0157,
.size = 0x1,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
- /* 5 - crypto */ {
+ /* crypto */ {
.phys_start = 0x0170,
.virt_start = 0x0170,
.size = 0x10,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
- /* 6 - qman */ {
+ /* qman */ {
.phys_start = 0x0188,
.virt_start = 0x0188,
.size = 0x1,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
-/* 7 - bman */ {
+/* bman */ {
.phys_start = 0x0189,
.virt_start = 0x0189,
.size = 0x1,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
- /* 8 - fman */ {
+ /* fman */ {
.phys_start = 0x01a0,
.virt_start = 0x01a0,
.size = 0x10,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
- /* 9 - qportals */ {
+ /* qportals */ {
.phys_start = 0x5,
.virt_start = 0x5,
.size = 0x800,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
- /* 10 - bportals */ {
+ /* bportals */ {
.phys_start = 0x50800,
.virt_start = 0x50800,
.size = 0x800,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
- /* 11 - dcfg */ {
+ /* dcfg */ {
.phys_start = 0x01ee,
.virt_start = 0x01ee,
.size = 0x1000,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
-/* 12 - clockgen */ {
+/* clockgen
[PATCH 2/3] configs: miriac-sbc-ls1046a: move IVSHMEM region to end of array
From: Henning Schild
Now that we are not counting anymore, find the one we need to index from
the ARRAY_SIZE.
Signed-off-by: Henning Schild
---
configs/arm64/miriac-sbc-ls1046a.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/configs/arm64/miriac-sbc-ls1046a.c
b/configs/arm64/miriac-sbc-ls1046a.c
index 98275d48..a98f9c24 100644
--- a/configs/arm64/miriac-sbc-ls1046a.c
+++ b/configs/arm64/miriac-sbc-ls1046a.c
@@ -396,12 +396,6 @@ struct {
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE,
},
- /* IVSHMEM shared memory region for 00:00.0 */ {
- .phys_start = 0xc040,
- .virt_start = 0xc040,
- .size = 0x10,
- .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
- },
/* PCI host bridge 0 */ {
.phys_start = 0x40,
.virt_start = 0x40,
@@ -423,6 +417,12 @@ struct {
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
+ /* IVSHMEM shared memory region for 00:00.0 */ {
+ .phys_start = 0xc040,
+ .virt_start = 0xc040,
+ .size = 0x10,
+ .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
+ },
},
.irqchips = {
@@ -451,7 +451,7 @@ struct {
0xff00, 0x, 0x,
0x, 0x, 0x,
},
- .shmem_region = 46,
+ .shmem_region = ARRAY_SIZE(config.mem_regions) - 1,
.shmem_protocol = JAILHOUSE_SHMEM_PROTO_VETH,
},
},
--
2.19.2
--
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.
[PATCH 3/3] configs: miriac-sbc-ls1046a: adjust memory flags for qbman portals
From: Henning Schild
The qbman portal regions are split into two, cache-inhibited and
cache-enabled. (see DPAA_PORTAL_C[IE] in drivers/soc/fsl/qbman/)
When the underlying memory is not mapped correctly, like it was before
this commit, you will see TX errors and loose a significant amount of
packets on the DPAA NICs after jailhouse is enabled.
Signed-off-by: Henning Schild
---
configs/arm64/miriac-sbc-ls1046a.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/configs/arm64/miriac-sbc-ls1046a.c
b/configs/arm64/miriac-sbc-ls1046a.c
index a98f9c24..9597500d 100644
--- a/configs/arm64/miriac-sbc-ls1046a.c
+++ b/configs/arm64/miriac-sbc-ls1046a.c
@@ -22,7 +22,7 @@
struct {
struct jailhouse_system header;
__u64 cpus[1];
- struct jailhouse_memory mem_regions[50];
+ struct jailhouse_memory mem_regions[52];
struct jailhouse_irqchip irqchips[2];
struct jailhouse_pci_device pci_devices[1];
} __attribute__((packed)) config = {
@@ -137,17 +137,29 @@ struct {
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
- /* qportals */ {
+ /* qportals CE */ {
.phys_start = 0x5,
.virt_start = 0x5,
- .size = 0x800,
+ .size = 0x400,
+ .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
+ },
+ /* qportals CI */ {
+ .phys_start = 0x50400,
+ .virt_start = 0x50400,
+ .size = 0x400,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
- /* bportals */ {
+ /* bportals CE */ {
.phys_start = 0x50800,
.virt_start = 0x50800,
- .size = 0x800,
+ .size = 0x400,
+ .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
+ },
+ /* bportals CI */ {
+ .phys_start = 0x50c00,
+ .virt_start = 0x50c00,
+ .size = 0x400,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
--
2.19.2
--
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: [PATCH 0/4] Add Microsys miriac SBC-LS1046A board support
Am Thu, 7 Mar 2019 16:40:44 +0100 schrieb Andreas Messerschmid : > Hi Henning, > > On 3/7/19 2:32 PM, Henning Schild wrote: > > Hi Andreas, > > > > for how long did you test running jailhouse on the device? And did > > you operate it via serial or network? > I did not have 'ultra long' test periods but the device was running > overnight without any problems. I was using the serial port and the > network interfaces too. Even migration of the network interfaces to a > Linux guest worked without any problems. What do you mean with migration? Device assignment to a non-root cell? Because that will be next on my plate. If you managed to assign one of the 8 PHYs to another cell and network still working on both sides, i would appreciate an off-list follow up. > > I am currently enabling an ls1043 and network breaks after just > > creating a second cell, not even loading or starting it. I guess in > > that line i would also like to know which kernel you used and which > > device tree, to understand whether you used DPAA from mainline or > > the SDK-Version from NXP. > I was using mainline Linux 4.19.5-rt4 (Jailhouse patches from > git://git.kiszka.org/linux.git -> queues/jailhouse on top) with the > DPAA driver from there. Devicetree from this series > https://lkml.org/lkml/2018/9/3/482. I am now building a 4.19 mainline as well. Henning > Andreas > > > > > In fact a simple offlining of a CPU breaks networking, no jailhouse > > no funny stuff: > > echo 0 > /sys/devices/system/cpu/cpu3/online > > > > And that would be for LSDK-18.09-V4.14 from > > https://source.codeaurora.org/external/qoriq/qoriq-components/linux > > Using the mainline driver stack. > > > > regards, > > Henning > > > > Am Tue, 29 Jan 2019 10:00:24 +0100 > > schrieb : > > > >> From: Andreas Messerschmid > >> > >> This series adds support for the miriac SBC-LS1046A to Jailhouse. > >> > >> Andreas Messerschmid (4): > >> configs: miriac-sbc-ls1046a: Add root cell configuration > >> configs: miriac-sbc-ls1046a: Add GIC demo inmate configuration > >> configs: miriac-sbc-ls1046a: Add linux inmate demo configuration > >> configs: miriac-sbc-ls1046a: Add linux inmate demo dts > >> > >> configs/arm64/dts/inmate-miriac-sbc-ls1046a.dts | 106 ++ > >> configs/arm64/miriac-sbc-ls1046a-gic-demo.c | 74 > >> configs/arm64/miriac-sbc-ls1046a-linux-demo.c | 137 +++ > >> configs/arm64/miriac-sbc-ls1046a.c | 458 > >> 4 files changed, 775 insertions(+) > >> create mode 100644 configs/arm64/dts/inmate-miriac-sbc-ls1046a.dts > >> create mode 100644 configs/arm64/miriac-sbc-ls1046a-gic-demo.c > >> create mode 100644 configs/arm64/miriac-sbc-ls1046a-linux-demo.c > >> create mode 100644 configs/arm64/miriac-sbc-ls1046a.c > >> > > > -- 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: [PATCH 0/4] Add Microsys miriac SBC-LS1046A board support
Hi Andreas, for how long did you test running jailhouse on the device? And did you operate it via serial or network? I am currently enabling an ls1043 and network breaks after just creating a second cell, not even loading or starting it. I guess in that line i would also like to know which kernel you used and which device tree, to understand whether you used DPAA from mainline or the SDK-Version from NXP. In fact a simple offlining of a CPU breaks networking, no jailhouse no funny stuff: echo 0 > /sys/devices/system/cpu/cpu3/online And that would be for LSDK-18.09-V4.14 from https://source.codeaurora.org/external/qoriq/qoriq-components/linux Using the mainline driver stack. regards, Henning Am Tue, 29 Jan 2019 10:00:24 +0100 schrieb : > From: Andreas Messerschmid > > This series adds support for the miriac SBC-LS1046A to Jailhouse. > > Andreas Messerschmid (4): > configs: miriac-sbc-ls1046a: Add root cell configuration > configs: miriac-sbc-ls1046a: Add GIC demo inmate configuration > configs: miriac-sbc-ls1046a: Add linux inmate demo configuration > configs: miriac-sbc-ls1046a: Add linux inmate demo dts > > configs/arm64/dts/inmate-miriac-sbc-ls1046a.dts | 106 ++ > configs/arm64/miriac-sbc-ls1046a-gic-demo.c | 74 > configs/arm64/miriac-sbc-ls1046a-linux-demo.c | 137 +++ > configs/arm64/miriac-sbc-ls1046a.c | 458 > 4 files changed, 775 insertions(+) > create mode 100644 configs/arm64/dts/inmate-miriac-sbc-ls1046a.dts > create mode 100644 configs/arm64/miriac-sbc-ls1046a-gic-demo.c > create mode 100644 configs/arm64/miriac-sbc-ls1046a-linux-demo.c > create mode 100644 configs/arm64/miriac-sbc-ls1046a.c > -- 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: gdb inmate
Am Tue, 5 Mar 2019 19:28:25 +0100 schrieb "[ext] Jan Kiszka" : > On 05.03.19 18:45, Tim Michals wrote: > > Is it possible to use gdb from one inmate to debug another inmate? > > For example, using Linux to debug FreeRTOS Application? > > There is no Jailhouse support for that. If the inmate has a built-in > gdbserver that can be directed to UART or some other physical > channel, you can loop that back. I once played a bit with emulating > the Jailhouse cell environment in QEMU (which has a nice built-in > gdbserver). But that was x86 only and never went far. I did use that over a UART, both for arm and x86. Everything was hooked up to an Eclipse running on Windows and i could use all those colorful buttons to single-step/breakpoint etc. The "application" was an OS with a gdb-stub. Henning > Hardware debugging is another option, see > https://groups.google.com/forum/#!topic/jailhouse-dev/UGYwpahEkqI > > 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: Inmate not receiving interrupt from root cell
Am Fri, 1 Mar 2019 11:27:35 +0100 schrieb "[ext] Jan Kiszka" : > On 01.03.19 09:56, michael.g.hin...@gmail.com wrote: > > Hello, > > > > I've got most everything working with ivshmem: the inmate is > > modifying shared memory and sending interrupts to the root cell, > > the root cell is receiving the interrupts and seeing the shared > > memory and PCI config space, and the root is writing to shared > > memory, which the inmate sees. > > > > However, I'm having a hard time getting the root cell to send > > interrupts back to the inmate via the ivshmem PCI device. I've > > tried writing to both the doorbell and lstate registers, with no > > success. > > > > Do you have any general tips on what I can do to debug the > > interrupt path from root cell to inmate? What configs do I need to > > match up? (IRQ vectors?) How do I know what values to write to the > > doorbell or lstate registers? > > You are on x86? Try using a different .iommu ID (typically 1, check > what others exit) in the jailhouse_pci_device for ivshmem. And make sure your inmate device driver did enable PCI bus master. Henning > 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: [PATCH] driver: invoke jailhouse_firmware_free when disabling jailhouse
That is on me! Good catch but it is intentional.
Henning
On Tue, 19 Feb 2019 02:30:52 +
Peng Fan wrote:
> After `jailhouse disable`, there is still an IO entry from /proc/iomem
> for jailhouse, so call jailhouse_firmware_free when disabling
> jailhouse for fix this. Also drop the call to jailhouse_firmware_free
> when enabling jailhouse.
>
> Signed-off-by: Peng Fan
> ---
> driver/main.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/driver/main.c b/driver/main.c
> index fe752753..5cdb5892 100644
> --- a/driver/main.c
> +++ b/driver/main.c
> @@ -306,8 +306,11 @@ static void jailhouse_firmware_free(void)
> resource_size(hypervisor_mem_res));
> hypervisor_mem_res = NULL;
> }
> - vunmap(hypervisor_mem);
> - hypervisor_mem = NULL;
> +
> + if (hypervisor_mem) {
> + vunmap(hypervisor_mem);
> + hypervisor_mem = NULL;
> + }
> }
>
> int jailhouse_console_dump_delta(char *dst, unsigned int head,
> @@ -437,10 +440,6 @@ static int jailhouse_cmd_enable(struct
> jailhouse_system __user *arg) #ifdef JAILHOUSE_BORROW_ROOT_PT
> remap_addr = JAILHOUSE_BASE;
> #endif
> - /* Unmap hypervisor_mem from a previous "enable". The
> mapping has to be
> - * redone since the root-cell config might have changed. */
> - jailhouse_firmware_free();
> -
> hypervisor_mem_res = request_mem_region(hv_mem->phys_start,
> hv_mem->size,
> "Jailhouse
> hypervisor"); @@ -701,6 +700,7 @@ static int
> jailhouse_cmd_disable(void) update_last_console();
>
> jailhouse_cell_delete_root();
> + jailhouse_firmware_free();
> jailhouse_enabled = false;
> module_put(THIS_MODULE);
>
--
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 Cell Creation Error // Unhandled MSR write: c8f
Am Wed, 13 Feb 2019 07:54:54 + schrieb Burak Atalay : > Hello everyone, > > I am trying to run a non-root Linux cell, however I am encountering > an error. I followed the documentation and I am using your modified > Linux kernel from queues/jailhouse. When I issue the command > "jailhouse cell linux > configs/x86/linux-x86-demo.cell /path/to/bzImage" I get the following > error: > > FATAL: Unhandled MSR write: c8f > RIP: 0x9646c084 RSP: 0xa9ea41a2be08 FLAGS: 246 > RAX: 0x RBX: 0x9b46e06fe000 RCX: > 0x0c8f RDX: 0x RSI: 0x > RDI: 0x0c8f CS: 10 BASE: 0x AR-BYTES: > a09b EFER.LMA 1 CR0: 0x80050033 CR3: 0x0001c920a001 > CR4: 0x003626e0 EFER: 0x0d01 > Parking CPU 1 (Cell: "RootCell") > Ignoring NMI IPI to CPU1 > > At this point the machine is still functional, when I issue a > "jailhouse cell list" command I see the following: > > ID NameState Assigned CPUs Failed > CPUs 0 RootCellRunning > 0-31 1 1 linux-x86-demo > invalid 1-3 1 > > However I am unable to shutdown or destroy the linux cell with > respective shutdown and destroy commands. Since I failed to run a > non-root Linux cell, I tried to run the other demo cells, like > tiny-demo and apic. When I issue the command "jailhouse cell create > configs/x86/tiny-demo.cell" I get the following error: > > FATAL: Unhandled MSR write: c8f > RIP: 0xafe6c084 RSP: 0xb302c1a5be08 FLAGS: 246 > RAX: 0x RBX: 0x89b4e069f000 RCX: > 0x0c8f RDX: 0x RSI: 0x > RDI: 0x0c8f CS: 10 BASE: 0x AR-BYTES: > a09b EFER.LMA 1 CR0: 0x80050033 CR3: 0x0001a1c0a001 > CR4: 0x003626e0 EFER: 0x0d01 > Parking CPU 2 (Cell: "RootCell") > Ignoring NMI IPI to CPU2 > > Since the errors for both non-root cells are similar, my assumption > is that the problem is not related to my config file for the Linux > cell or the kernel. In any case, I am attaching my sysconfig for the > root cell, the data collected by "jailhouse config collect", and my > config file for the Linux kernel. > > Could you help me with this issue? >From the MSR i would guess CONFIG_INTEL_RDT in both your kernels. If you look up the RIP in the System.map of your kernel, you be able to find out which code caused the access. The MSR is IA32_PQR_ASSOC I did not look into the details of the feature. Your options are: - Allow access to the MSR, after an assessment whether that is a good idea - disable the feature in the kernels regards, Henning > Thanks and best regards, > Burak Atalay > > > -- 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: How do I get ivshmem-demo working with Jailhouse Images?
Am Fri, 8 Feb 2019 21:26:29 -0800 schrieb : > On Friday, February 8, 2019 at 8:40:18 AM UTC-7, Henning Schild wrote: > > Am Thu, 7 Feb 2019 16:53:41 -0800 > > schrieb : > > > > > On Wednesday, February 6, 2019 at 5:59:09 AM UTC-7, Henning Schild > > > wrote: > > > > Am Tue, 5 Feb 2019 19:25:28 -0800 > > > > schrieb : > > > > > > > > > On Friday, February 1, 2019 at 12:32:40 AM UTC-7, J. Kiszka > > > > > wrote: > > > > > > You likely want > > > > > > https://github.com/siemens/linux/commits/jailhouse-enabling/4.14 > > > > > > or the 4.19-variant that is jailhouse-prepared. That's what > > > > > > jailhouse-images is building for you. If you just rebuild > > > > > > the kernel that the original image was using, only adding > > > > > > UIO, you should be fine with keeping the jailhouse kernel > > > > > > package untouched. But the cleanest way is reproducing the > > > > > > image via jailhouse-images after adjusting the parameter > > > > > > you want to change (CONFIG_UIO, ROOTFS_EXTRA etc.). > > > > > > > > > > > > Jan > > > > > > > > > > > > -- > > > > > > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > > > > > > Corporate Competence Center Embedded Linux > > > > > > > > > > That worked! I was able to figure out the correct kernel to > > > > > build by looking at > > > > > jailhouse-images/recipes-kernel/linux/linux-jailhouse.bb from > > > > > when I last generated my image at 4.14.73 > > > > > (https://github.com/siemens/linux/archive/1dd68658b3a8308a160b0786fc4e1e04d8ff5216.tar.gz). > > > > > With that, I supplied QEMU with the new UIO-enabled kernel > > > > > image and built jailhouse and uio_ivshmem.ko and ran the > > > > > ivshmem jailhouse demo. > > > > > > > > > > However, I'm still not sure how to read in the data from the > > > > > ivshmem-demo. Once I insmod uio_ivshmem.ko, shouldn't there > > > > > be a device called /dev/uio0 that I can read "Hello From > > > > > IVSHMEM" from and write back to? And shouldn't there be an > > > > > entry in /sys/class/uio/? I don't see either of these, and > > > > > I'm not quite sure how to debug this yet. > > > > > > > > Yes you should get that. If you do not, my first guess would be > > > > that you are not building the jailhouse branch of the > > > > guest-code repo. The jailhouse version of the PCI interface is > > > > slightly different, so the probing between the two is not > > > > compatible. > > > Shouldn't I see /dev/uio0 and /sys/class/uio/ once I `insmod` it, > > > regardless if it's built against a non-jailhouse-enabled kernel? > > > Or will it show up once jailhouse is running? > > > > I am not actually sure what will happen, so if a /dev/uio0 will pop > > up even if probing failed. > > Just to clarify, i did not talk about a jailhouse enabled kernel, i > > talked about checking out the jailhouse branch of the repo you got > > the uio driver from. The one from branch "master" will not work! > > Thanks! That's just what I needed. I didn't realize that there was a > jailhouse branch. I rebuilt it, /dev/uio0 shows up, and the > ivshmem-demo is working! uio_read and shmem_test.py > (README.jailhouse) both work great. > > But unfortunately uio_send doesn't. When I run `uio_send /dev/uio0 1 > 0 0`, it fails to mmap() with an ENODEV/"No such device" error. The > mmap man page says "the underlying filesystem of the specified file > does not support memory mapping." > > Do you know why this is? Isn't uio_send just trying to mmap() the PCI > config space (the first 256 bytes)? Sorry no clue. I guess you should follow that error to the condition triggering it. A first guess would be that you need to mmap the full page ... change the value to 4096. Only the first 256 bytes are of interest but 4k is the lowest mapping granularity. And check whether your user has write permissions to the file, maybe try as root first. Henning > Thanks, > -Michael > > > > > Henning > > > > > When I `make` uio_ivshmem, it shows that it's entering the correct > > > kernel source. Is > > > https:
Re: How do I get ivshmem-demo working with Jailhouse Images?
Am Thu, 7 Feb 2019 22:11:45 -0800 schrieb : > Hello, > > So I've been debugging uio_ivshmem.c with print statements, and I > think have a theory for what's going wrong: > > I believe the ivshem-net driver is being attached to the root cell's > ivshmem PCI device before the uio_ivshmem driver can, since I > compiled the kernel with CONFIG_IVSHMEM_NET=Y. > > It appears that uio_ivshmem is not successfully completing the UIO > probe stage, because it's probing PCI device `f` (ivshmem-demo's > ivshmem device) instead of PCI device `e` (the root cell's ivshmem > device). uio_ivshmem never probes device `e` because it's already > taken by ivshmem-net. So uio_ivshmem appears to find the next > available ivshmem device, which is `f`. But since it's not allowed > access (maybe?), the driver fails and doesn't set up properly. In addition to the vendor and device id we have a protocol defined. ivshmem-net will only bind to JAILHOUSE_SHMEM_PROTO_VETH while the ivshmem-demo will only bind to JAILHOUSE_SHMEM_PROTO_UNDEFINED. The uio driver does not check that, but obviously should not be used on PROTO_VETH devices. That means all the ones that are claimed by ivshmem-net would not work anyways, so there is no conflict and no unbinding needed. Even if you bound the uio driver on one device, the other side "ivshmem-demo" would refuse to do the same. My theory is still that you are on the wrong branch for the uio driver. Henning > Even when I manually unbind ivshmem-net from device `e`, whenever I > start jailhouse, it seems to automatically rebind. So I guess that > means that I'll need to rebuild the kernel with CONFIG_IVSHMEM_NET=N > to allow uio_ivshmem a chance to bind to `e`. > > I'm still investigating, but wanted to see if I'm on the right track > here. > > Thanks, > Michael > -- 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: How do I get ivshmem-demo working with Jailhouse Images?
Am Thu, 7 Feb 2019 16:53:41 -0800 schrieb : > On Wednesday, February 6, 2019 at 5:59:09 AM UTC-7, Henning Schild > wrote: > > Am Tue, 5 Feb 2019 19:25:28 -0800 > > schrieb : > > > > > On Friday, February 1, 2019 at 12:32:40 AM UTC-7, J. Kiszka > > > wrote: > > > > You likely want > > > > https://github.com/siemens/linux/commits/jailhouse-enabling/4.14 > > > > or the 4.19-variant that is jailhouse-prepared. That's what > > > > jailhouse-images is building for you. If you just rebuild the > > > > kernel that the original image was using, only adding UIO, you > > > > should be fine with keeping the jailhouse kernel package > > > > untouched. But the cleanest way is reproducing the image via > > > > jailhouse-images after adjusting the parameter you want to > > > > change (CONFIG_UIO, ROOTFS_EXTRA etc.). > > > > > > > > Jan > > > > > > > > -- > > > > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > > > > Corporate Competence Center Embedded Linux > > > > > > That worked! I was able to figure out the correct kernel to build > > > by looking at > > > jailhouse-images/recipes-kernel/linux/linux-jailhouse.bb from > > > when I last generated my image at 4.14.73 > > > (https://github.com/siemens/linux/archive/1dd68658b3a8308a160b0786fc4e1e04d8ff5216.tar.gz). > > > With that, I supplied QEMU with the new UIO-enabled kernel image > > > and built jailhouse and uio_ivshmem.ko and ran the ivshmem > > > jailhouse demo. > > > > > > However, I'm still not sure how to read in the data from the > > > ivshmem-demo. Once I insmod uio_ivshmem.ko, shouldn't there be a > > > device called /dev/uio0 that I can read "Hello From IVSHMEM" from > > > and write back to? And shouldn't there be an entry > > > in /sys/class/uio/? I don't see either of these, and I'm not > > > quite sure how to debug this yet. > > > > Yes you should get that. If you do not, my first guess would be that > > you are not building the jailhouse branch of the guest-code repo. > > The jailhouse version of the PCI interface is slightly different, > > so the probing between the two is not compatible. > Shouldn't I see /dev/uio0 and /sys/class/uio/ once I `insmod` it, > regardless if it's built against a non-jailhouse-enabled kernel? Or > will it show up once jailhouse is running? I am not actually sure what will happen, so if a /dev/uio0 will pop up even if probing failed. Just to clarify, i did not talk about a jailhouse enabled kernel, i talked about checking out the jailhouse branch of the repo you got the uio driver from. The one from branch "master" will not work! Henning > When I `make` uio_ivshmem, it shows that it's entering the correct > kernel source. Is https://github.com/siemens/linux/commit/1dd68658b > not the correct jailhouse-enabled source to build for 4.14.73? > > Does making all the UIO modules be built-in (Y) instead of (M) make > any difference? I set them to Y because I thought it would make > things easier. > > I may consider upgrading jailhouse images to the latest if I can't > get things working. > > Thanks, > Michael > > > > Henning > > > > > The only documentation I can find on this is > > > https://www.kernel.org/doc/html/v4.18/driver-api/uio-howto.html. > > > > > > Any help is appreciated. Sorry to be a bother. Thanks! > > > -Michael > > > > -- 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: How do I get ivshmem-demo working with Jailhouse Images?
Am Tue, 5 Feb 2019 19:25:28 -0800 schrieb : > On Friday, February 1, 2019 at 12:32:40 AM UTC-7, J. Kiszka wrote: > > You likely want > > https://github.com/siemens/linux/commits/jailhouse-enabling/4.14 or > > the 4.19-variant that is jailhouse-prepared. That's what > > jailhouse-images is building for you. If you just rebuild the > > kernel that the original image was using, only adding UIO, you > > should be fine with keeping the jailhouse kernel package untouched. > > But the cleanest way is reproducing the image via jailhouse-images > > after adjusting the parameter you want to change (CONFIG_UIO, > > ROOTFS_EXTRA etc.). > > > > Jan > > > > -- > > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > > Corporate Competence Center Embedded Linux > > That worked! I was able to figure out the correct kernel to build by > looking at jailhouse-images/recipes-kernel/linux/linux-jailhouse.bb > from when I last generated my image at 4.14.73 > (https://github.com/siemens/linux/archive/1dd68658b3a8308a160b0786fc4e1e04d8ff5216.tar.gz). > With that, I supplied QEMU with the new UIO-enabled kernel image and > built jailhouse and uio_ivshmem.ko and ran the ivshmem jailhouse demo. > > However, I'm still not sure how to read in the data from the > ivshmem-demo. Once I insmod uio_ivshmem.ko, shouldn't there be a > device called /dev/uio0 that I can read "Hello From IVSHMEM" from and > write back to? And shouldn't there be an entry in /sys/class/uio/? I > don't see either of these, and I'm not quite sure how to debug this > yet. Yes you should get that. If you do not, my first guess would be that you are not building the jailhouse branch of the guest-code repo. The jailhouse version of the PCI interface is slightly different, so the probing between the two is not compatible. Henning > The only documentation I can find on this is > https://www.kernel.org/doc/html/v4.18/driver-api/uio-howto.html. > > Any help is appreciated. Sorry to be a bother. Thanks! > -Michael > -- 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: [PATCH 0/4] Add Microsys miriac SBC-LS1046A board support
Hi Andreas, thanks for sharing that! Do you happen to know if that will work for an fsl-ls1046a as well? I guess a dts diff should give a clue. If it does the target should probably be called fsl-ls1046a. We talked off list and i have those configs for an fsl-ls1043a. There is good config sharing potential between the two. Let us see if that gets merged, and thanks for starting the discussion! Henning On Tue, 29 Jan 2019 10:00:24 +0100 wrote: > From: Andreas Messerschmid > > This series adds support for the miriac SBC-LS1046A to Jailhouse. > > Andreas Messerschmid (4): > configs: miriac-sbc-ls1046a: Add root cell configuration > configs: miriac-sbc-ls1046a: Add GIC demo inmate configuration > configs: miriac-sbc-ls1046a: Add linux inmate demo configuration > configs: miriac-sbc-ls1046a: Add linux inmate demo dts > > configs/arm64/dts/inmate-miriac-sbc-ls1046a.dts | 106 ++ > configs/arm64/miriac-sbc-ls1046a-gic-demo.c | 74 > configs/arm64/miriac-sbc-ls1046a-linux-demo.c | 137 +++ > configs/arm64/miriac-sbc-ls1046a.c | 458 > 4 files changed, 775 insertions(+) > create mode 100644 configs/arm64/dts/inmate-miriac-sbc-ls1046a.dts > create mode 100644 configs/arm64/miriac-sbc-ls1046a-gic-demo.c > create mode 100644 configs/arm64/miriac-sbc-ls1046a-linux-demo.c > create mode 100644 configs/arm64/miriac-sbc-ls1046a.c > -- 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: (&p->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.
Re: Jailhouse Images Demo No Longer Works After Image Resize
Am Mon, 21 Jan 2019 15:46:25 -0800 schrieb : > So here's what happened: I increased the memory from 1 GB to 4 GB in > the QEMU command (from `-m 1G` to `-m 4G`). The Jailhouse-images's > qemu-x86.cell root cell didn't like that. > > So I guess if I want to increase the memory to 4 GB, I'll need to > update configs/x86/qemu-x86.c accordingly. Yes, and maybe all you other cells configs as well as the kernel command line. > How can I do this? Do I just need to change the RAM mem regions? I'm > not sure how to determine how big each mem region should be. Are > there resources that explain how to create a valid cell configuration > (for x86, at least)? The config is derived from /proc/iomem. Just look how this file changes when you assign more RAM, and apply a similar change to the root cells config. The memory available to all other cells and the hypervisor is mentioned on the kernel command line. If you want to assign more memory to those cells or the hypervisor you will need to change the configs and the command line reservation. There is "jailhouse config create" (tools/jailhouse-config-create), i think it does not work on qemu but should give you an idea on how to create a config for an x86. Henning > Any help is appreciated. > > Thanks, > Michael > -- 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 console setup
Hi Stefan, i am not going to parse your screenshot. In fact i am not even sure if i am allowed to read that mail or if i need to send a fax ;). There is a project to assist people in building ready-to-use images, and a NUC is in there. While you might not be able to use the image on your NUC, you can look at the configs which probably solve the problem you are facing. https://github.com/siemens/jailhouse-images Specifically recipes-jailhouse/jailhouse/files/*nuc6cay*.c Henning Am Fri, 18 Jan 2019 07:40:58 + schrieb Stefan KLEMKE : > Hello Folks, > > I am trying to run Jailhouse on a NUC7i5DNK2E and managed to get a > root cell and the tiny-demo inmate "running". Since I dont have > serial output ports, I want to use the virtual jailhouse console to > capture debugging informations from the non-root cell. My > understanding is, that my configs need the following flags set: > RootCell: .flag = JAILHOUSE_SYS_VIRTUAL_DEBUG_CONSOLE Non-root > cells: .flag JAILHOUSE_CELL_VIRTUAL_CONSOLE_ACTIVE (Docu says, it > implies JAILHOUSE_CELL_VIRTUAL_CONSOLE_PERMITTED) .. but I cannot see > the printk string from the tiny demo on my cat /dev/jailhouse console > output. I tried the PERMITTED flag for the non-root cell as well, > since it is the default in the example files, but still no output to > be seen. > > I have screenshotted everything I used, maybe you guys have an idea, > what I am doing wrong. > > thx for helping me out > Stefan > > Der Inhalt dieser E-Mail ist für den Absender rechtlich nicht > verbindlich. Informieren Sie uns bitte, wenn Sie diese E-Mail > fälschlicherweise erhalten haben (Fax: +49-7551-891-4001). Bitte > löschen Sie in diesem Fall die Nachricht. Jede Form der weiteren > Benutzung ist untersagt. > > > The content of this e-mail is not legally binding upon the sender. > If this e-mail was transmitted to you by error, then please inform us > accordingly (Fax: +49-7551-891-4001). In such case you are requested > to erase the message. Any use of such e-mail message is strictly > prohibited. > -- 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
Am Tue, 15 Jan 2019 04:09:03 -0800 schrieb Chung-Fan Yang : > > Did you regenerate the root cell config after adding the card? Or > > manually added the additional entries needed for it? Something went > > wrong in that area. > > I regenerated the config and cross checked with the working one. > Nothing vicious was found. > > I did notice that the IRQ was an IO-APIC IRQ in the /proc/interrupts. > I think this is the problem. I am working on a MSI version of the > driver. A jailhouse assignment resets devices and removes the pci bus master config flag from them. I am not sure about the "jailhouse enable" case, but assigning the card to another cell can clear the bus master flag, which is a common case for MSI not working. A proper linux pci driver will take care of that once msi is used, but if i understand you correctly you are extending an existing driver and maybe the bus master init was overlooked. Henning > - > Yang > -- 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.
[PATCH] core: Update comment according to recent change
From: Henning Schild 37c7b05b21 renamed the flag JAILHOUSE_CON2_TYPE_ROOTPAGE, update that last remaining comment as well Signed-off-by: Henning Schild --- hypervisor/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hypervisor/setup.c b/hypervisor/setup.c index 786b54c9..99a2b0c3 100644 --- a/hypervisor/setup.c +++ b/hypervisor/setup.c @@ -73,7 +73,7 @@ static void init_early(unsigned int cpu_id) * Linux' page table before shutdown without triggering violations. * * Allow read access to the console page, if the hypervisor has the -* debug console flag JAILHOUSE_CON2_TYPE_ROOTPAGE set. +* debug console flag JAILHOUSE_SYS_VIRTUAL_DEBUG_CONSOLE set. */ hyp_phys_start = system_config->hypervisor_memory.phys_start; hyp_phys_end = hyp_phys_start + system_config->hypervisor_memory.size; -- 2.19.2 -- 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: ivshmem pci issue
Am Fri, 11 Jan 2019 01:40:42 + schrieb Peng Fan : > Hi Jan, Henning > > We are trying to enable jailhouse with 4.1 ARM Linux Kernel with > ivshmem, however the uio_ivshmem driver uses some new APIs not > existed in 4.1 kernel. > > There two options to me, > 1. backport Linux pci code from community to 4.1 > 2. rework uio_ivshmem driver to use 4.1 kernel API, according to the > git history of uio_ivshmem > > Do you have any suggestions? I know about that issue, it appeared when i reworked the driver quite some time ago. At the time i did not test such old kernels. You should be able to find a working version in the history. If you come up with a patch guarded by some ifdefs i would merge it to enable 4.1 again. So option 2 for sure. Henning > Thanks, > Peng. > -- 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 gets stuck on LS1046a
Hi, i have a ls1043 config that works on current master and a ls1046 config that worked on some older version. Will send it to you off list. Henning Am Wed, 12 Dec 2018 17:28:43 +0100 schrieb Andreas Messerschmid : > Hi all, > > I'm trying to bring up Jailhouse on a NXP Layerscape LS1046a based > board with four Cortex-A72 cores. The system gets stuck after issuing > the 'jailhouse enable .cell' command. > > After debugging through the jailhouse loading process everything seems > to settle correctly. The system gets stuck in enter_hypervisor() when > calling 'arch_entry' via 'err = entry(cpu);'. > > arch_entry is called for each of the four cpus, but none of these > function calls returns and the system is stuck afterwards. > > I'm using the current Jailhouse master branch and a 4.19 rootcell > Linux kernel. > > Anybody seen this before? > > > Best regards > Andreas > > > -- 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: Linux inmate serial console issues
Hi, that is the fault of systemd. Unlike the kernel it does not support multiple "console=" correctly. It just takes the first ... i think. And if you do not have your serial as that console, you will also not get a getty. Because those are magic services that systemd spawns looking the the kernel command line. Use another init and /etc/inittab if you can ;). Henning Am Fri, 7 Dec 2018 02:36:00 -0800 schrieb : > Did anyone of you ever experienced a strange behaviour of a Linux > inmate with a systemd root filesystem, where the userspace does not > have access to the UART, but systemd and kernel do? I only see the > kernel log and the systemd output which is oddly enough printed in a > 30 seconds interval to the serial console, but then systemd stops > after a while and apparently fails to start further services. > > Now if I replace /sbin/init with my own source code and open the > serial console /dev/ttySC5 I get a valid fd, in my case 3. But when I > write in that file I never see anything on the other side. However > writing to /dev/kmsg works just fine within my /sbin/init. Is this > some sort of CPU permission level issue in the inmate? > > BR, > 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: [PATCH 0/4] ivshmem-demo inmate for BananaPi-M1
Am Thu, 29 Nov 2018 02:53:24 -0800 schrieb : > On Monday, January 15, 2018 at 9:04:57 AM UTC+1, jonas wrote: > > > > - it also seems you have added tools to the guest-code-repo but > > > they do not seem essential, but are mentioned in your docs > > > (shmem-pump) > > Yes, some very simple tools for modifying/displaying the contents > > of the shmem-area from the root-cell using the uio-ivshmem.ko > > module. > > Hi Jonas and Henning, > > I managed to get the demo running on the emtrion RZ/G1E, but I'm not > sure what shmem_pump and shmem_dump are doing. These tools are not > available in the ivshmem-guest-code repo. Can you please elaborate, > what they're doing or even share the code? That'd be great. Hi, i do not actually remember the details. Most of the stuff in the repo is not jailhouse specific but rather qemu specific. The scope of the jailhouse support does not go beyond what you will find in README.jailhouse. And it is really just a demo to understand the basics of setting up the shmem, sending/receiving data and interrupts. For anything beyond that i suggest to check out the ivshmem network device driver. This driver is an example working on all arches since a long time, just harder to understand what is going on. The tools you are looking for might be in qemu and might just not work with the jailhouse implementation of ivshmem. There was a follow up series of patches from me, which also did not get merged, but might be a better start if you are just looking at the demo. https://groups.google.com/forum/#!topic/jailhouse-dev/TeGZNtfOV1Y 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: x86_64 Power management
Am Wed, 7 Nov 2018 17:17:32 +0100 schrieb Jan Kiszka : > On 07.11.18 16:13, Henning Schild wrote: > > Am Tue, 6 Nov 2018 17:02:34 -0800 > > schrieb Chung-Fan Yang : > > > >> Hi, > >> > >> I am having some quextions about power management(PM) on x86. > >> As afr as I understand, there are C-states and P-states, > >> controlling the sleeping depth and frequency scale accrodingly, on > >> an x86 processor. > >> > >> My question is that when I use jailhouse house to create a non-root > >> cell, which state it will fall into? > > > > You will get the CPU in its full power mode, if you want any of the > > other states your inmate needs to support that (PM code). > > > >> Will it be reset to C0 and full frequency? or inherit the root > >> state when cell is created? > >> > >> Is it necessary to write some PM code in the inmates? > > > > Only if you want to safe power, or if you need to throttle so your > > BIOS does not hit you with an SMI. > > Power management - better: power management moderation - is not > provided by Jailhouse so far. That means, as Henning described, > inmates are responsible to do "the right thing". That's surely not > optimal, can lead to mistakes and has to be improved (see TODO). E.g, > we just learned that calling "hlt" in the apic-demo is likely a > source of undesired latency, we should do polling or mwait with the > right level (there will be patches soonish). Interesting. Will you switch the test to mwait or will you trap hlt and emulate it with mwait? Henning > 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: x86_64 Power management
Am Tue, 6 Nov 2018 17:02:34 -0800 schrieb Chung-Fan Yang : > Hi, > > I am having some quextions about power management(PM) on x86. > As afr as I understand, there are C-states and P-states, controlling > the sleeping depth and frequency scale accrodingly, on an x86 > processor. > > My question is that when I use jailhouse house to create a non-root > cell, which state it will fall into? You will get the CPU in its full power mode, if you want any of the other states your inmate needs to support that (PM code). > Will it be reset to C0 and full frequency? or inherit the root state > when cell is created? > > Is it necessary to write some PM code in the inmates? Only if you want to safe power, or if you need to throttle so your BIOS does not hit you with an SMI. Henning > > Yang > -- 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: ivshmem-net PCI devices not available in RootCell
Am Tue, 6 Nov 2018 10:52:58 +0100
schrieb Andreas Messerschmid :
> On 11/06/2018 10:48 AM, Henning Schild wrote:
> > Am Tue, 6 Nov 2018 10:29:08 +0100
> > schrieb Andreas Messerschmid :
> >
> >> Hi Henning,
> >>
> >> On 11/06/2018 10:14 AM, Henning Schild wrote:
> >>> Am Mon, 5 Nov 2018 17:32:40 +0100
> >>> schrieb Andreas Messerschmid :
> >>>
> >>>> Hi,
> >>>>
> >>>> I'm trying to bring úp an ivshmem-net based
> >>>> inter-cell-communication on an Intel-Atom E3950 hardware running
> >>>> Jailhouse but I can't discover any ivshmem-net virtual PCI
> >>>> devices in the RootCell. The Hypervisor and Linux inmate are up
> >>>> and running fine and I can see the ivshmem-net virtual PCI
> >>>> device in the inmate including the appropriate network interface.
> >>>>
> >>>> The hypervisor console states the following:
> >>>> Reserving 5 interrupt(s) for device 0100 at index 136
> >>>> Adding PCI device 02:00.0 to cell "RootCell"
> >>>> Reserving 5 interrupt(s) for device 0200 at index 141
> >>>> Adding virtual PCI device 00:0a.0 to cell "RootCell"
> >>>> Page pool usage after late setup: mem 393/15822, remap
> >>>> 65547/131072 Activating hypervisor
> >>>> Removing PCI device 01:00.0 from cell "RootCell"
> >>>> Freeing 5 interrupt(s) for device 0100 at index 136
> >>>> Adding PCI device 01:00.0 to cell "inmate1"
> >>>> Reserving 5 interrupt(s) for device 0100 at index 136
> >>>> Adding virtual PCI device 00:0a.0 to cell "inmate1"
> >>>> Shared memory connection established: "inmate1" <--> "RootCell"
> >>>> Created cell "inmate1"
> >>>
> >>> All this looks fine to me, the two devices get added and the link
> >>> gets established.
> >>>
> >>>> But the virtual PCI device 00:0a.0 is not discoverable in the
> >>>> RootCell.
> >>>
> >>> I guess the interface does not appear, which could also be the
> >>> driver not liking the device. What do lspci or browsing
> >>> in /sys/bus/pci say?
> >>
> >> neither lspci nor /sys/bus/pci/devices in the RootCell show the
> >> '00:0a.0' device.
> >
> > I guess your 4.19 is from here?
> > http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/jailhouse
> >
>
> Yes, that's the kernel in use.
>
> >
> > You could try rescanning the PCI bus, but i think the jailhouse
> > driver should do that when adding a device.
> >
> > might cause a trap ... "sync" before
> > # echo 1 > /sys/bus/pci/rescan
>
> Same result, even after rescanning the device does not show up.
In this case i would instrument the hypervisor to check that
pci_read_config and arch_pci_read_config intercept the accesses. (put a
few printks in there)
You could also try and change the pci cfg space access method, things
like "pci=conf1" or "pci=nommconf" and friends. Maybe posting your root
cell config would be a good idea as well.
I assume you are using a recent jailhouse and your config is derived
from something generated with the corresponding config creator.
Henning
> Andreas
>
>
> >>>> My RootCell ivshmem config looks like this:
> >>>> { /* IVSHMEM (networking rootcell <-> inmate1) */
> >>>> .type = JAILHOUSE_PCI_TYPE_IVSHMEM,
> >>>> .iommu = 1,
> >>>> .domain = 0x,
> >>>> .bdf = 0x0a << 3,
> >>>> .bar_mask = {
> >>>> 0xff00, 0x, 0x,
> >>>> 0x, 0xffe0, 0x,
> >>>>},
> >>>>.num_msix_vectors = 1,
> >>>>.shmem_region = 40,
> >>>>.shmem_protocol = JAILHOUSE_SHMEM_PROTO_VETH,
> >>>> },
> >>>>
> >>>> RootCell kernel config ist attached.
> >>>>
> >>>> Did anybody face such an issue before? Any hints?
> >>>>
> >>>> Best regards
> >>>> Andreas
> >>>>
> >>>
> >>
> >
>
--
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: ivshmem-net PCI devices not available in RootCell
Am Tue, 6 Nov 2018 10:29:08 +0100
schrieb Andreas Messerschmid :
> Hi Henning,
>
> On 11/06/2018 10:14 AM, Henning Schild wrote:
> > Am Mon, 5 Nov 2018 17:32:40 +0100
> > schrieb Andreas Messerschmid :
> >
> >> Hi,
> >>
> >> I'm trying to bring úp an ivshmem-net based
> >> inter-cell-communication on an Intel-Atom E3950 hardware running
> >> Jailhouse but I can't discover any ivshmem-net virtual PCI devices
> >> in the RootCell. The Hypervisor and Linux inmate are up and
> >> running fine and I can see the ivshmem-net virtual PCI device in
> >> the inmate including the appropriate network interface.
> >>
> >> The hypervisor console states the following:
> >> Reserving 5 interrupt(s) for device 0100 at index 136
> >> Adding PCI device 02:00.0 to cell "RootCell"
> >> Reserving 5 interrupt(s) for device 0200 at index 141
> >> Adding virtual PCI device 00:0a.0 to cell "RootCell"
> >> Page pool usage after late setup: mem 393/15822, remap 65547/131072
> >> Activating hypervisor
> >> Removing PCI device 01:00.0 from cell "RootCell"
> >> Freeing 5 interrupt(s) for device 0100 at index 136
> >> Adding PCI device 01:00.0 to cell "inmate1"
> >> Reserving 5 interrupt(s) for device 0100 at index 136
> >> Adding virtual PCI device 00:0a.0 to cell "inmate1"
> >> Shared memory connection established: "inmate1" <--> "RootCell"
> >> Created cell "inmate1"
> >
> > All this looks fine to me, the two devices get added and the link
> > gets established.
> >
> >> But the virtual PCI device 00:0a.0 is not discoverable in the
> >> RootCell.
> >
> > I guess the interface does not appear, which could also be the
> > driver not liking the device. What do lspci or browsing
> > in /sys/bus/pci say?
>
> neither lspci nor /sys/bus/pci/devices in the RootCell show the
> '00:0a.0' device.
I guess your 4.19 is from here?
http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/jailhouse
You could try rescanning the PCI bus, but i think the jailhouse driver
should do that when adding a device.
might cause a trap ... "sync" before
# echo 1 > /sys/bus/pci/rescan
Henning
> Andreas
>
> >> My RootCell ivshmem config looks like this:
> >> { /* IVSHMEM (networking rootcell <-> inmate1) */
> >> .type = JAILHOUSE_PCI_TYPE_IVSHMEM,
> >> .iommu = 1,
> >> .domain = 0x,
> >> .bdf = 0x0a << 3,
> >> .bar_mask = {
> >> 0xff00, 0x, 0x,
> >> 0x, 0xffe0, 0x,
> >>},
> >>.num_msix_vectors = 1,
> >>.shmem_region = 40,
> >>.shmem_protocol = JAILHOUSE_SHMEM_PROTO_VETH,
> >> },
> >>
> >> RootCell kernel config ist attached.
> >>
> >> Did anybody face such an issue before? Any hints?
> >>
> >> Best regards
> >> Andreas
> >>
> >
>
--
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: ivshmem-net PCI devices not available in RootCell
Am Mon, 5 Nov 2018 17:32:40 +0100
schrieb Andreas Messerschmid :
> Hi,
>
> I'm trying to bring úp an ivshmem-net based inter-cell-communication
> on an Intel-Atom E3950 hardware running Jailhouse but I can't
> discover any ivshmem-net virtual PCI devices in the RootCell. The
> Hypervisor and Linux inmate are up and running fine and I can see the
> ivshmem-net virtual PCI device in the inmate including the
> appropriate network interface.
>
> The hypervisor console states the following:
> Reserving 5 interrupt(s) for device 0100 at index 136
> Adding PCI device 02:00.0 to cell "RootCell"
> Reserving 5 interrupt(s) for device 0200 at index 141
> Adding virtual PCI device 00:0a.0 to cell "RootCell"
> Page pool usage after late setup: mem 393/15822, remap 65547/131072
> Activating hypervisor
> Removing PCI device 01:00.0 from cell "RootCell"
> Freeing 5 interrupt(s) for device 0100 at index 136
> Adding PCI device 01:00.0 to cell "inmate1"
> Reserving 5 interrupt(s) for device 0100 at index 136
> Adding virtual PCI device 00:0a.0 to cell "inmate1"
> Shared memory connection established: "inmate1" <--> "RootCell"
> Created cell "inmate1"
All this looks fine to me, the two devices get added and the link gets
established.
> But the virtual PCI device 00:0a.0 is not discoverable in the
> RootCell.
I guess the interface does not appear, which could also be the driver
not liking the device. What do lspci or browsing in /sys/bus/pci say?
Henning
> My RootCell ivshmem config looks like this:
> { /* IVSHMEM (networking rootcell <-> inmate1) */
> .type = JAILHOUSE_PCI_TYPE_IVSHMEM,
> .iommu = 1,
> .domain = 0x,
> .bdf = 0x0a << 3,
> .bar_mask = {
> 0xff00, 0x, 0x,
> 0x, 0xffe0, 0x,
>},
>.num_msix_vectors = 1,
>.shmem_region = 40,
>.shmem_protocol = JAILHOUSE_SHMEM_PROTO_VETH,
> },
>
> RootCell kernel config ist attached.
>
> Did anybody face such an issue before? Any hints?
>
> Best regards
> Andreas
>
--
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.
