Re: [PATCH] configs: x86: align with recent qemu device model
On 16.02.24 20:36, Ralf Ramsauer wrote:
> Devices slightly changed with recent Qemu versions. Adapt changes of
> device topology.
>
> Signed-off-by: Ralf Ramsauer
> ---
>
> Tested with jailhouse enable, create, disable + apic demo.
>
> README.md | 2 +-
> configs/x86/qemu-x86.c | 80 +-
> 2 files changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/README.md b/README.md
> index 2ab2a60a..f6fe011b 100644
> --- a/README.md
> +++ b/README.md
> @@ -255,7 +255,7 @@ https://github.com/siemens/jailhouse-images.
>
> The included system configuration qemu-x86.c can be used to run Jailhouse in
> QEMU/KVM virtual machine on x86 hosts (Intel and AMD are supported).
> Currently
> -it requires Linux 4.4 or newer on the host side. QEMU version 2.8 or newer is
> +it requires Linux 4.4 or newer on the host side. QEMU version 8.2 or newer is
I'm reluctant to bump the requirements that high, given how many distros
are on 7.2 or even 7.1. What about starting to use versioned machine
models instead? Say, 'qemu-system-x86_64 -machine pc-q35-7.0'? Similar
for the other archs (virt-x.y).
Jan
> required.
>
> You also need a Linux guest image with a recent kernel (tested with >= 3.9)
> and
> diff --git a/configs/x86/qemu-x86.c b/configs/x86/qemu-x86.c
> index cdd3dd6d..7a585bd7 100644
> --- a/configs/x86/qemu-x86.c
> +++ b/configs/x86/qemu-x86.c
> @@ -179,52 +179,52 @@ struct {
> .size = 0x4000,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
> },
> - /* MemRegion: fea0-fea3 : :00:02.0 */
> + /* MemRegion: feb4-feb7 : :00:02.0 */
> {
> - .phys_start = 0xfea0,
> - .virt_start = 0xfea0,
> + .phys_start = 0xfeb4,
> + .virt_start = 0xfeb4,
> .size = 0x4,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
> },
> - /* MemRegion: fea4-fea5 : e1000e */
> + /* MemRegion: feb8-feb9 : e1000e */
> {
> - .phys_start = 0xfea4,
> - .virt_start = 0xfea4,
> + .phys_start = 0xfeb8,
> + .virt_start = 0xfeb8,
> .size = 0x2,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
> },
> - /* MemRegion: fea6-fea7 : e1000e */
> + /* MemRegion: feba-febb : e1000e */
> {
> - .phys_start = 0xfea6,
> - .virt_start = 0xfea6,
> + .phys_start = 0xfeba,
> + .virt_start = 0xfeba,
> .size = 0x2,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
> },
> - /* MemRegion: fea91000-fea93fff : e1000e */
> + /* MemRegion: febd-febd3fff : e1000e */
> {
> - .phys_start = 0xfea91000,
> - .virt_start = 0xfea91000,
> + .phys_start = 0xfebd,
> + .virt_start = 0xfebd,
> .size = 0x3000,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
> },
> - /* MemRegion: fea94000-fea97fff : :00:1b.0 (ICH HD audio) */
> + /* MemRegion: febd4000-febd7fff : :00:1b.0 (ICH HD audio) */
> {
> - .phys_start = 0xfea94000,
> - .virt_start = 0xfea94000,
> + .phys_start = 0xfebd4000,
> + .virt_start = 0xfebd4000,
> .size = 0x4000,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
> },
> - /* MemRegion: fea98000-fea98fff : :00:01.0 (vesafd) */
> + /* MemRegion: febd8000-febd8fff : :00:01.0 (vesafd) */
> {
> - .phys_start = 0xfea98000,
> - .virt_start = 0xfea98000,
> + .phys_start = 0xfebd8000,
> + .virt_start = 0xfebd8000,
> .size = 0x1000,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
> },
> - /* MemRegion: fea9a000-fea9afff : :00:1f.2 (ahci) */
> + /* MemRegion: febd9000-febd9fff : :00:1f.2 (ahci) */
> {
> - .phys_start = 0xfea9a000,
> - .virt_start = 0xfea9a000,
> + .phys_start = 0xfebd9000,
> + .virt_start = 0xfebd9000,
> .size = 0x1000,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
> },
Re: Jailhouse and optee interaction
On 10.05.23 16:21, 'Vladimir Neyelov' via Jailhouse wrote: > HI all, > We use jailhouse hypervisor on our platforms. Standard configuration is > root cell - linux, secondary cell - ThreadX. But now we want to add > optee os support. How jailhouse can interact with optee os. What is the > common way to run optee os in jailhouse. OP-TEE OS runs in secure word, Jailhouse runs in non-secure EL2. All what Jailhouse has to deal with are service calls from EL1 and above to EL3 and, eventually, to the secure world. Jailhouse traps all SMC calls and only handles or forwards a view of them, see https://github.com/siemens/jailhouse/blob/e57d1eff6d55aeed5f977fe4e2acfb6ccbdd7560/hypervisor/arch/arm-common/smccc.c#L117. Now, simply allowing all calls to OP-TEE is likely no option as those may either have side effects on the platform. If they follow a standard calling convention, maybe a permission list could be created and then enforced by Jailhouse according to a cell configuration. I vaguely recall similar thoughts about other EL3-targeting calls. Key issue, also there, is that you can police access just based on service call IDs or so. But the situation may be even more complicated when a TEE service or the OS itself are not aware of partitioning and not keeping requests from different instances (which could be different cells in Jailhouse) separate. Obviously: Anything that is harmless by design and across all boards and TEE implementations could be allowed by default in Jailhouse, but I'm not expecting to find much of that. Jan -- Siemens AG, Technology 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/716a8a07-3a7f-f20f-d08a-a9cb4ee607c2%40siemens.com.
Re: ARM: ivshmem virtual PCI device doesn't show up
On 08.05.23 03:53, Kurt Zou wrote: > Hi All, > I'm trying to bring up a ivshmem net device on a cortex-A7 platform. > > After enabling jailhouse, virtual PCI devices seem to be added > successfully, but with "lspci" or "/sys/bus/pci/devices", I didn't see > anything there. Am I missing something? I assume that pci devices (even > virtual) should be able to show up in system. > > Here's the debug information: > > root@demo:~# jailhouse enable /etc/jailhouse/demo.cell > > Initializing Jailhouse hypervisor v0.12 on CPU 0 > Code location: 0xf040 > Page pool usage after early setup: mem 37/1770, remap 0/131072 > Initializing processors: > CPU 0... OK > CPU 1... OK > CPU 2... OK > CPU 3... OK > Initializing unit: irqchip > Initializing unit: PCI > Adding virtual PCI device 00:00.0 to cell "demo" > Adding virtual PCI device 00:01.0 to cell "demo" > Page pool usage after late setup: mem 57/1770, remap 5/131072 > Activating hypervisor > root@demo:~# lspci > root@demo:~# ifconfig > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > loop txqueuelen 1000 (Local Loopback) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 0 bytes 0 (0.0 B) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > Is the virtual PCI host controller visible in the root cell's device tree (/sys/firmware/devicetree/...)? Does the root Linux kernel support it (CONFIG_PCI_HOST_GENERIC=y, IIRC)? Do you have any error reporting on the kernel log of the root cell? Jan -- Siemens AG, Technology 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/09045e94-f35b-53a6-93e4-8a1edd8e099e%40siemens.com.
Re: Question: integrating Jailhouse in the Linux kernel tree
On 15.03.23 19:29, Laurentiu Mihalcea wrote: > Hi, > > I'm not sure if this topic has been discussed before but would it be > possible to integrate the Jailhouse driver in the Linux kernel tree? > This would allow other kernel modules to utilise Jailhouse and would be > useful in cases where user space is not yet available (e.g: during a > device's probe()) to do all the setup. > > > Use case: > 1) Linux boots > 2) device_x's probe() is called > 3) User space becomes available. > > I would be interested in enabling the hypervisor, creating an inmate and > loading some image during step 2) of the above flow. > But you know that Jailhouse startup and non-root cell loading currently depends on userspace? How would a built-in Jailhouse driver help there? What you can already do is pushing the setup into an initramfs. Jan -- Siemens AG, Technology 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/83472a1d-e6cf-3336-a4a8-df3c6bcc2cab%40siemens.com.
10 years - and still alive!
It's been a while and I'm also getting older, so I do not recall anymore when exactly I wrote the first line of Jailhouse code. Maybe about a week earlier. However, my non-public git records start on the 23rd of January, 2013. Therefore, let's use this date to have the party! Jailhouse was born out of an intensive discussion with colleagues whether creating the n-th closed-source hypervisor would be the best way forward. Their idea was that it should be straightforward to create mixed-critical systems once you have a simple partitioning hypervisor in place. That little piece of software would "just" be certified according to safety standards - done. I was already skeptical whether it is a good idea to create yet another hypervisor ourselves, after having worked on various corner-cases on KVM the years before. But I specifically didn't believe it was worth to write that without having the chance to talk about it and the hardware it needs openly with a broader expert community. Still, I also felt like it would be worth exploring such a safety approach (without have much clue about saftey back then). I first thought of shrinking down KVM, benefiting from its maturity and "only" reducing its size. But then I realized the limits of this and thought: Why not trying something new, activating the partitioning during runtime? This idea was spinning in my head for some months when an unfortunate change in my personal life made me look for doing something creative. So the first code was written during long evenings and weekends. I first worked against KVM as "hardware", so I once again ran into KVM corner cases, this time around nested virtualization. Let's debug the debugger, and have even more (hacker) fun! Around the 10th of February, the first vmlaunch succeeded, still in KVM. Only if you ever have tried that yourself, you know how hard it is to make vmlaunch happy and to find out why it is still not (think of "docker run" would only return -EINVAL, whatever you feed in). Even with KVM, this was not easy to understand although some consistency checks happen in software there. On the 10th of March, the first inmate launched, the famous apic-demo. Still in KVM, still as a spare-time project. Then on the 20th of March, I added support for starting KVM on my work notebook, a Fujitsu Celsius H700. What was missing for this jump from KVM to real silicon? Actually just a minor adjustment to CR0 handling where KVM was more relaxed than actual CPUs turned out to be. With this demo in hands, literally, I went to my bosses, shared my idea and vision, made the point that this would only fly if it became open source and asked for the OK to publish it. And to drive this further towards that safety idea. Long-story short(er): The informal approval came quickly, the formal process still took a bit longer. But for the presentation of Jailhouse at the KVM Forum 2013 [1] the baseline finally went public on github. My real baseline did not - so far. But this little celebration story already became so long - and I did not even talk about what we learned about safety, software and hardware in the past 10 years -, I think 1310 lines of the real Jailhouse baseline patch do not matter. See below. Now let's celebrate. Not just those few first months. We need to celebrate much more you all, dear contributors! You made out of 404 lines of code over 5, added two further architectures (part of the pitch to my bosses which I didn't fully believe to happen that quickly), with another one on the horizon, enabled Jailhouse on dozens of different targets, and kept it alive. Thank you all! Jan [1] http://www.linux-kvm.org/images/b/b1/Kvm-forum-2013-Static-Partitioning.pdf --- >From 264de60d953188695eba5d634cafcaec35b9e2e6 Mon Sep 17 00:00:00 2001 From: Jan Kiszka Date: Wed, 23 Jan 2013 21:33:10 +0100 Subject: [PATCH] Baseline Contains build system, loader module, hypervisor skeleton and user space tool to send enable/disable commands. Signed-off-by: Jan Kiszka --- .gitignore | 9 + COPYING| 339 + Makefile | 31 ++ hypervisor/Makefile| 38 +++ hypervisor/arch/x86/Makefile | 15 + hypervisor/arch/x86/apic.c | 28 ++ hypervisor/arch/x86/dbg-write.c| 33 ++ hypervisor/arch/x86/include/asm/bitops.h | 49 +++ hypervisor/arch/x86/include/asm/io.h | 25 ++ hypervisor/arch/x86/include/asm/spinlock.h | 31 ++ hypervisor/arch/x86/include/asm/types.h| 23 ++ hypervisor/hypervisor.ld | 39 +++ hypervisor/include/jailhouse/header.h | 20 ++ hypervisor/include/jailhouse/printk.h | 15 + hypervisor/include/jailhouse/processor.h | 13 + hypervisor/printk.c| 92 ++ hypervisor/setup.c | 32 ++ jailh
Re: [PATCH 07/14] configs: arm64: Consistently move inmate demo to 2 core
On 22.01.23 20:28, Jan Kiszka wrote: > From: Jan Kiszka > > Allows to run that cell aside the linux inmate. > > For the k3-am625, we also have to shrink the linux demo to core 2 and 3. > The r8a774a1 had a inmate demo cpu set that was completely off. > > Signed-off-by: Jan Kiszka Subject should read "Consistently move inmate demo to core 1" - fixed in next. Jan -- Siemens AG, Technology 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/a53ce3e7-15c2-800f-fce0-0efa73831de3%40siemens.com.
Re: [PATCH] README: Add Renesas RZ/G2M to the list of supported hardware
On 22.01.23 20:09, Lad Prabhakar wrote: > Add Renesas RZ/G2M to the list of supported hardware. > > Signed-off-by: Lad Prabhakar > --- > README.md | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/README.md b/README.md > index dc2c3afa..2ab2a60a 100644 > --- a/README.md > +++ b/README.md > @@ -134,6 +134,8 @@ Hardware requirements (preliminary) > > - NXP MCIMX8M-EVK > > +- Renesas RZ/G2M (HopeRun HiHope RZ/G2M platform) > + > > Software requirements > - Thanks, applied. Jan -- Siemens AG, Technology 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/f58cd6df-6e56-9785-89e1-118ed8846dc0%40siemens.com.
[PATCH 02/14] tools: jailhouse-config-check: Add CPU set checks
From: Jan Kiszka
When at least one non-root cell is provided, check if the root cell is
left with at least one core. If multiple non-root cells are listed, test
the those do not overlap in their CPU set. This ensures that the given
cell set can be instantiated at the same time.
Signed-off-by: Jan Kiszka
---
tools/jailhouse-config-check | 26 ++
1 file changed, 26 insertions(+)
diff --git a/tools/jailhouse-config-check b/tools/jailhouse-config-check
index 95de6fd4..ebfe97a8 100755
--- a/tools/jailhouse-config-check
+++ b/tools/jailhouse-config-check
@@ -187,4 +187,30 @@ for cell in cells:
ret=1
print("\n" if found else " None")
+if len(cells) > 1:
+print("Root cell CPU starvation:", end='')
+remaining_root_core=root_cell.cpus
+for cell in cells[1:]:
+remaining_root_core -= cell.cpus
+if len(remaining_root_core) == 0:
+print("\n\n"
+ "No root cell CPUs left when all non-root cells are started\n")
+ret=1
+else:
+print(" None")
+
+if len(cells) > 2:
+print("Overlapping cores between non-root cells:", end='')
+found=False
+for cell in cells[1:len(cells)-1]:
+for other_cell in cells[cells.index(cell)+1:]:
+overlap=cell.cpus & other_cell.cpus
+if overlap:
+print("\n\nCells '%s' and '%s' share CPUs:" %
+ (cell.name, other_cell.name))
+print(str(overlap).strip('{}'), end='')
+found=True
+ret=1
+print("\n" if found else " None")
+
exit(ret)
--
2.35.3
--
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/d77a509484ad7cea7d9b72f35086492ca7f5046b.1674415741.git.jan.kiszka%40siemens.com.
[PATCH 01/14] pyjailhouse: config_parser: Build CPU set from cell configuration
From: Jan Kiszka
Creates a simple set of CPU numbers from the cell configuration. This
will be used by the config checker for exhaustion and overlap checks.
Signed-off-by: Jan Kiszka
---
pyjailhouse/config_parser.py | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/pyjailhouse/config_parser.py b/pyjailhouse/config_parser.py
index 2a59b651..be0c749e 100644
--- a/pyjailhouse/config_parser.py
+++ b/pyjailhouse/config_parser.py
@@ -180,8 +180,16 @@ class CellConfig:
self.name = str(name.decode().strip('\0'))
self.arch = convert_arch(self.arch)
-mem_region_offs = struct.calcsize(CellConfig._HEADER_FORMAT) + \
-self.cpu_set_size
+cpu_set_offs = struct.calcsize(CellConfig._HEADER_FORMAT)
+mask_array = struct.unpack_from('%dB' % self.cpu_set_size,
+self.data[cpu_set_offs:])
+self.cpus = set()
+for n in range(self.cpu_set_size):
+for bit in range(8):
+if mask_array[n] & (1 << bit) != 0:
+self.cpus.add(n * 8 + bit)
+
+mem_region_offs = cpu_set_offs + self.cpu_set_size
self.memory_regions = []
for n in range(self.num_memory_regions):
self.memory_regions.append(
--
2.35.3
--
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/3c759dbcae3449a2f4e1df52616dda2220ac69fd.1674415741.git.jan.kiszka%40siemens.com.
[PATCH 04/14] configs: arm: dts: Silence style warnings
From: Jan Kiszka
Resolves "unit name should not have leading 0s".
Signed-off-by: Jan Kiszka
---
configs/arm/dts/inmate-bananapi.dts | 6 +++---
configs/arm/dts/inmate-orangepi0.dts | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/configs/arm/dts/inmate-bananapi.dts
b/configs/arm/dts/inmate-bananapi.dts
index 78a29301..bd222bc7 100644
--- a/configs/arm/dts/inmate-bananapi.dts
+++ b/configs/arm/dts/inmate-bananapi.dts
@@ -69,7 +69,7 @@
clock-output-names = "osc24M";
};
- apb1_gates: clk@01c2006c {
+ apb1_gates: clk@1c2006c {
#clock-cells = <1>;
compatible = "allwinner,sun7i-a20-apb1-gates-clk";
reg = <0x01c2006c 0x4>;
@@ -79,7 +79,7 @@
};
};
- gic: interrupt-controller@01c81000 {
+ gic: interrupt-controller@1c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
<0x01c82000 0x1000>;
@@ -87,7 +87,7 @@
#interrupt-cells = <3>;
};
- uart: serial@01c29c00 {
+ uart: serial@1c29c00 {
compatible = "snps,dw-apb-uart";
reg = <0x01c29c00 0x400>;
interrupts = ;
diff --git a/configs/arm/dts/inmate-orangepi0.dts
b/configs/arm/dts/inmate-orangepi0.dts
index cfdb7cda..f3a18c14 100644
--- a/configs/arm/dts/inmate-orangepi0.dts
+++ b/configs/arm/dts/inmate-orangepi0.dts
@@ -76,7 +76,7 @@
};
};
- gic: interrupt-controller@01c81000 {
+ gic: interrupt-controller@1c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
<0x01c82000 0x1000>;
@@ -84,7 +84,7 @@
#interrupt-cells = <3>;
};
- uart: serial@01c28000 {
+ uart: serial@1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
interrupts = ;
--
2.35.3
--
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/23245e32c3772efef66a7dd9716550cc25f6ae35.1674415741.git.jan.kiszka%40siemens.com.
[PATCH 07/14] configs: arm64: Consistently move inmate demo to 2 core
From: Jan Kiszka
Allows to run that cell aside the linux inmate.
For the k3-am625, we also have to shrink the linux demo to core 2 and 3.
The r8a774a1 had a inmate demo cpu set that was completely off.
Signed-off-by: Jan Kiszka
---
configs/arm64/dts/inmate-k3-am625-sk.dts | 7 ---
configs/arm64/imx8mm-inmate-demo.c | 2 +-
configs/arm64/imx8mn-inmate-demo.c | 2 +-
configs/arm64/imx8mp-inmate-demo.c | 2 +-
configs/arm64/imx8mq-inmate-demo.c | 2 +-
configs/arm64/imx8qm-inmate-demo.c | 2 +-
configs/arm64/jetson-tx1-inmate-demo.c | 2 +-
configs/arm64/k3-am625-sk-inmate-demo.c| 2 +-
configs/arm64/k3-am625-sk-linux-demo.c | 2 +-
configs/arm64/k3-am654-inmate-demo.c | 2 +-
configs/arm64/miriac-sbc-ls1046a-inmate-demo.c | 2 +-
configs/arm64/renesas-r8a774a1-inmate-demo.c | 2 +-
configs/arm64/zynqmp-zcu102-inmate-demo.c | 2 +-
13 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/configs/arm64/dts/inmate-k3-am625-sk.dts
b/configs/arm64/dts/inmate-k3-am625-sk.dts
index c1455073..160feb45 100644
--- a/configs/arm64/dts/inmate-k3-am625-sk.dts
+++ b/configs/arm64/dts/inmate-k3-am625-sk.dts
@@ -35,13 +35,6 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu1: cpu@1 {
- compatible = "arm,cortex-a53";
- reg = <0x001>;
- device_type = "cpu";
- enable-method = "psci";
- };
-
cpu2: cpu@2 {
compatible = "arm,cortex-a53";
reg = <0x002>;
diff --git a/configs/arm64/imx8mm-inmate-demo.c
b/configs/arm64/imx8mm-inmate-demo.c
index 7d2c5c18..ef4f187a 100644
--- a/configs/arm64/imx8mm-inmate-demo.c
+++ b/configs/arm64/imx8mm-inmate-demo.c
@@ -42,7 +42,7 @@ struct {
},
.cpus = {
- 0x8,
+ 0x2,
},
.mem_regions = {
diff --git a/configs/arm64/imx8mn-inmate-demo.c
b/configs/arm64/imx8mn-inmate-demo.c
index 2b77c3f5..e3f04f07 100644
--- a/configs/arm64/imx8mn-inmate-demo.c
+++ b/configs/arm64/imx8mn-inmate-demo.c
@@ -43,7 +43,7 @@ struct {
},
.cpus = {
- 0x8,
+ 0x2,
},
.mem_regions = {
diff --git a/configs/arm64/imx8mp-inmate-demo.c
b/configs/arm64/imx8mp-inmate-demo.c
index ecbd7bb6..e5355833 100644
--- a/configs/arm64/imx8mp-inmate-demo.c
+++ b/configs/arm64/imx8mp-inmate-demo.c
@@ -43,7 +43,7 @@ struct {
},
.cpus = {
- 0x8,
+ 0x2,
},
.mem_regions = {
diff --git a/configs/arm64/imx8mq-inmate-demo.c
b/configs/arm64/imx8mq-inmate-demo.c
index b28a0dac..cbb3a01e 100644
--- a/configs/arm64/imx8mq-inmate-demo.c
+++ b/configs/arm64/imx8mq-inmate-demo.c
@@ -42,7 +42,7 @@ struct {
},
.cpus = {
- 0x8,
+ 0x2,
},
.mem_regions = {
diff --git a/configs/arm64/imx8qm-inmate-demo.c
b/configs/arm64/imx8qm-inmate-demo.c
index 8ab216cd..effd7b80 100644
--- a/configs/arm64/imx8qm-inmate-demo.c
+++ b/configs/arm64/imx8qm-inmate-demo.c
@@ -42,7 +42,7 @@ struct {
},
.cpus = {
- 0x8,
+ 0x2,
},
.mem_regions = {
diff --git a/configs/arm64/jetson-tx1-inmate-demo.c
b/configs/arm64/jetson-tx1-inmate-demo.c
index 99a704ce..8b13148d 100644
--- a/configs/arm64/jetson-tx1-inmate-demo.c
+++ b/configs/arm64/jetson-tx1-inmate-demo.c
@@ -40,7 +40,7 @@ struct {
},
.cpus = {
- 0x8,
+ 0x2,
},
.mem_regions = {
diff --git a/configs/arm64/k3-am625-sk-inmate-demo.c
b/configs/arm64/k3-am625-sk-inmate-demo.c
index 053de528..38d146a9 100644
--- a/configs/arm64/k3-am625-sk-inmate-demo.c
+++ b/configs/arm64/k3-am625-sk-inmate-demo.c
@@ -45,7 +45,7 @@ struct {
},
.cpus = {
- 0x4,
+ 0x2,
},
.mem_regions = {
diff --git a/configs/arm64/k3-am625-sk-linux-demo.c
b/configs/arm64/k3-am625-sk-linux-demo.c
index 09bece78..37b42b5e 100644
--- a/configs/arm64/k3-am625-sk-linux-demo.c
+++ b/configs/arm64/k3-am625-sk-linux-demo.c
@@ -51,7 +51,7 @@ struct {
},
.cpus = {
- 0xe,
+ 0xc,
},
.mem_regions = {
diff --git a/configs/arm64/k3-am654-inmate-demo.c
b/configs/arm64/k3-am654-inmate-demo.c
index 8c60648f..73e4f051 100644
--- a/configs/arm64/k3-am654-inmate-demo.c
+++ b/configs/arm64/k3-am654-inmate-demo.c
@@ -44,7 +44,7 @@ struct {
},
.cpus = {
- 0x4,
+ 0x2,
},
.mem_regions = {
diff --git a/configs/arm64/miriac-sbc-ls1046a-inmate-demo.c
b/configs/arm64/miriac-sbc-ls1046a-inmate-demo.c
index 1e7fd2bc..630eb589 1
[PATCH 14/14] ci: Update to actions/checkout@v3 and actions/cache@v3
From: Jan Kiszka Silences some NodeJS 12 action deprecation warnings. Signed-off-by: Jan Kiszka --- .github/workflows/main.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/main.yaml b/.github/workflows/main.yaml index 1dbbc648..eea15f37 100644 --- a/.github/workflows/main.yaml +++ b/.github/workflows/main.yaml @@ -26,7 +26,7 @@ jobs: runs-on: ubuntu-20.04 steps: - name: Checkout -uses: actions/checkout@v2 +uses: actions/checkout@v3 - name: Install dependencies run: | sudo apt-get update @@ -42,7 +42,7 @@ jobs: tar -xf coverity_tool.tar.gz ln -s cov-analysis-linux64-* cov-analysis-linux64 - name: Cache kernel build environment -uses: actions/cache@v2 +uses: actions/cache@v3 id: cache-kernel with: key: kernel-build -- 2.35.3 -- 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/90300437f01918e1055cf4674b506ae0e10a80ca.1674415741.git.jan.kiszka%40siemens.com.
[PATCH 13/14] configs: arm64: k3-am654: Rename inmate demo
From: Jan Kiszka
Aligns the naming scheme to other targets and makes check-configs work.
Signed-off-by: Jan Kiszka
---
.../arm64/{k3-am654-inmate-demo.c => k3-am654-idk-inmate-demo.c} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename configs/arm64/{k3-am654-inmate-demo.c => k3-am654-idk-inmate-demo.c}
(100%)
diff --git a/configs/arm64/k3-am654-inmate-demo.c
b/configs/arm64/k3-am654-idk-inmate-demo.c
similarity index 100%
rename from configs/arm64/k3-am654-inmate-demo.c
rename to configs/arm64/k3-am654-idk-inmate-demo.c
--
2.35.3
--
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/7e740eaf303c22664a0ef6bffcd229c8d40611cb.1674415741.git.jan.kiszka%40siemens.com.
[PATCH 11/14] configs: arm64: ls1046a: Resolve overlap between two RAM regions
From: Jan Kiszka
The loader region was also part of the root cell RAM region.
Signed-off-by: Jan Kiszka
---
configs/arm64/ls1046a-rdb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/arm64/ls1046a-rdb.c b/configs/arm64/ls1046a-rdb.c
index 7291fda7..e104ee28 100644
--- a/configs/arm64/ls1046a-rdb.c
+++ b/configs/arm64/ls1046a-rdb.c
@@ -101,7 +101,7 @@ struct {
/* RAM - 1GB at DRAM1 region - root cell */ {
.phys_start = 0x8000,
.virt_start = 0x8000,
- .size = 0x4000,
+ .size = 0x3f00,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE,
},
--
2.35.3
--
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/29447eca9fe86725da3ed1bbbaa6789a13221906.1674415741.git.jan.kiszka%40siemens.com.
[PATCH 09/14] configs: arm: emtrion-rzg1{h,m}: Fix config checker findings
From: Jan Kiszka
In the emtrion-rzg1h, the APMU regions were overlapping. In the absence
if detailed information, keep the complete range mapped, analogously to
the emtrion-rzg1m.
The emtrion-rzg1h had a VSPDU region as duplicate of the VSPD2. Drop the
former.
While at it, remove JAILHOUSE_MEM_IO_32 where unneeded. This is only
relevant for sub-page regions.
Signed-off-by: Jan Kiszka
---
configs/arm/emtrion-rzg1h.c | 42 +
configs/arm/emtrion-rzg1m.c | 21 +++
2 files changed, 21 insertions(+), 42 deletions(-)
diff --git a/configs/arm/emtrion-rzg1h.c b/configs/arm/emtrion-rzg1h.c
index 9469213b..385f45b7 100644
--- a/configs/arm/emtrion-rzg1h.c
+++ b/configs/arm/emtrion-rzg1h.c
@@ -19,7 +19,7 @@
struct {
struct jailhouse_system header;
__u64 cpus[1];
- struct jailhouse_memory mem_regions[40];
+ struct jailhouse_memory mem_regions[38];
struct jailhouse_irqchip irqchips[3];
struct jailhouse_pci_device pci_devices[1];
} __attribute__((packed)) config = {
@@ -78,98 +78,84 @@ struct {
.virt_start = 0xe670,
.size = 0x1,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
- JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32,
+ JAILHOUSE_MEM_IO,
},
/* SYS-DMAC */ {
.phys_start = 0xe672,
.virt_start = 0xe672,
.size = 0x1,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
- JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32,
+ JAILHOUSE_MEM_IO,
},
/* SDHI1 */ {
.phys_start = 0xee12,
.virt_start = 0xee12,
.size = 0x2,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
- JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32,
+ JAILHOUSE_MEM_IO,
},
/* PWM */ {
.phys_start = 0xe6e3,
.virt_start = 0xe6e3,
.size = 0x1,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
- JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32,
+ JAILHOUSE_MEM_IO,
},
/* R-GP2D */ {
.phys_start = 0xe6ec,
.virt_start = 0xe6ec,
.size = 0x1,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
- JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32,
+ JAILHOUSE_MEM_IO,
},
/* Thermal Sensor */ {
.phys_start = 0xe61f,
.virt_start = 0xe61f,
.size = 0x1000,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
- JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32,
+ JAILHOUSE_MEM_IO,
},
/* CPG */ {
.phys_start = 0xe615,
.virt_start = 0xe615,
.size = 0x1000,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
- JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32,
+ JAILHOUSE_MEM_IO,
},
- /* APMU Cortex-A7 */ {
+ /* APMU */ {
.phys_start = 0xe6151000,
.virt_start = 0xe6151000,
.size = 0xf000,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
- JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32,
- },
- /* APMU Cortex-A15 */ {
- .phys_start = 0xe6152000,
- .virt_start = 0xe6152000,
- .size = 0xf000,
- .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
- JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32,
- },
- /* APMU Cortex-A7 and Cortex-A15 */ {
- .phys_start = 0xe6154000,
- .virt_start = 0xe6154000,
- .size = 0xf000,
- .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
- JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32,
+ JAILHOUSE_MEM_IO,
},
/* RES */ {
.phys_start = 0xe616,
.virt_start
[PATCH 08/14] configs: arm64: imx8dxl: Mark 32-bit demo also as 64-bit config
From: Jan Kiszka
Coupling the config arch to the target arch was counter-productive as it
prevents checking the non-root cell against its 64-bit root cell. Even
if the inmate will run in 32-bit mode, the config continue to target a
64-bit machine.
Fixes: f2320d2ee4de ("configs: enrich configs with architecture information")
Signed-off-by: Jan Kiszka
---
configs/arm64/imx8dxl-inmate-demo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/configs/arm64/imx8dxl-inmate-demo.c
b/configs/arm64/imx8dxl-inmate-demo.c
index 7da204d2..3d2296d7 100644
--- a/configs/arm64/imx8dxl-inmate-demo.c
+++ b/configs/arm64/imx8dxl-inmate-demo.c
@@ -22,11 +22,10 @@ struct {
.signature = JAILHOUSE_CELL_DESC_SIGNATURE,
.revision = JAILHOUSE_CONFIG_REVISION,
.name = "gic-demo",
+ .architecture = JAILHOUSE_ARM64,
#ifdef USE_AARCH32
- .architecture = JAILHOUSE_ARM,
.flags = JAILHOUSE_CELL_PASSIVE_COMMREG |
JAILHOUSE_CELL_AARCH32,
#else
- .architecture = JAILHOUSE_ARM64,
.flags = JAILHOUSE_CELL_PASSIVE_COMMREG,
#endif
.cpu_set_size = sizeof(config.cpus),
--
2.35.3
--
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/ea65df766392b069bf4e4a5fa1efc9f05b3504a9.1674415741.git.jan.kiszka%40siemens.com.
[PATCH 12/14] configs: arm64: ultra96/zcu102: Carve out SMMU from MMIO region
From: Jan Kiszka
The SMMU is not managed by Jailhouse. No longer expose it to the root
cell. Found by the config checker.
Signed-off-by: Jan Kiszka
---
configs/arm64/ultra96.c | 13 ++---
configs/arm64/zynqmp-zcu102.c | 13 ++---
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/configs/arm64/ultra96.c b/configs/arm64/ultra96.c
index 0387450d..b8829741 100644
--- a/configs/arm64/ultra96.c
+++ b/configs/arm64/ultra96.c
@@ -18,7 +18,7 @@
struct {
struct jailhouse_system header;
__u64 cpus[1];
- struct jailhouse_memory mem_regions[11];
+ struct jailhouse_memory mem_regions[12];
struct jailhouse_irqchip irqchips[1];
struct jailhouse_pci_device pci_devices[2];
union jailhouse_stream_id stream_ids[2];
@@ -112,10 +112,17 @@ struct {
},
/* IVSHMEM shared memory region for 00:01.0 */
JAILHOUSE_SHMEM_NET_REGIONS(0x7fb0, 0),
- /* MMIO (permissive) */ {
+ /* MMIO low (permissive) */ {
.phys_start = 0xfd00,
.virt_start = 0xfd00,
- .size = 0x0300,
+ .size = 0x0080,
+ .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
+ JAILHOUSE_MEM_IO,
+ },
+ /* MMIO high (permissive) */ {
+ .phys_start = 0xfd82,
+ .virt_start = 0xfd82,
+ .size = 0x027e,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
diff --git a/configs/arm64/zynqmp-zcu102.c b/configs/arm64/zynqmp-zcu102.c
index cd5f6089..750c9b6d 100644
--- a/configs/arm64/zynqmp-zcu102.c
+++ b/configs/arm64/zynqmp-zcu102.c
@@ -20,7 +20,7 @@
struct {
struct jailhouse_system header;
__u64 cpus[1];
- struct jailhouse_memory mem_regions[12];
+ struct jailhouse_memory mem_regions[13];
struct jailhouse_irqchip irqchips[1];
struct jailhouse_pci_device pci_devices[2];
union jailhouse_stream_id stream_ids[3];
@@ -84,10 +84,17 @@ struct {
JAILHOUSE_SHMEM_NET_REGIONS(0x80040, 0),
/* IVSHMEM shared memory region for 0001:00:01.0 */
JAILHOUSE_SHMEM_NET_REGIONS(0x80050, 0),
- /* MMIO (permissive) */ {
+ /* MMIO low (permissive) */ {
.phys_start = 0xfd00,
.virt_start = 0xfd00,
- .size = 0x0300,
+ .size = 0x0080,
+ .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
+ JAILHOUSE_MEM_IO,
+ },
+ /* MMIO high (permissive) */ {
+ .phys_start = 0xfd82,
+ .virt_start = 0xfd82,
+ .size = 0x027e,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_IO,
},
--
2.35.3
--
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/d049193ad6d7582d5f72f40da6b6fa7c1bfa2920.1674415741.git.jan.kiszka%40siemens.com.
[PATCH 10/14] configs: arm64: jetson-tx{1,2}: Fix config checker findings
From: Jan Kiszka
The TX1 had an overlap of RAM and ivshmem. TX2 had the timer and the
TOC_TKE (whatever that was) regions overlapping. According to the DT,
the TOC_TKE is actually the timer region.
Signed-off-by: Jan Kiszka
---
configs/arm64/jetson-tx1.c | 2 +-
configs/arm64/jetson-tx2.c | 11 ++-
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/configs/arm64/jetson-tx1.c b/configs/arm64/jetson-tx1.c
index 4c3320ff..8d1b9cc4 100644
--- a/configs/arm64/jetson-tx1.c
+++ b/configs/arm64/jetson-tx1.c
@@ -365,7 +365,7 @@ struct {
/* System RAM */ {
.phys_start = 0x8000,
.virt_start = 0x8000,
- .size = 0xfc00,
+ .size = 0xfbf0,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE,
},
diff --git a/configs/arm64/jetson-tx2.c b/configs/arm64/jetson-tx2.c
index 28e7578c..c4078d90 100644
--- a/configs/arm64/jetson-tx2.c
+++ b/configs/arm64/jetson-tx2.c
@@ -24,7 +24,7 @@
struct {
struct jailhouse_system header;
__u64 cpus[1];
- struct jailhouse_memory mem_regions[61];
+ struct jailhouse_memory mem_regions[60];
struct jailhouse_irqchip irqchips[3];
} __attribute__((packed)) config = {
.header = {
@@ -154,20 +154,13 @@ struct {
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE,
},
- /* TOP_TKE */ {
+ /* TIMER */ {
.phys_start = 0x0301,
.virt_start = 0x0301,
.size = 0xe,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE,
},
- /* TIMER */ {
-.phys_start = 0x0302,
-.virt_start = 0x0302,
-.size = 0xa,
-.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
-JAILHOUSE_MEM_EXECUTE,
-},
/* UARTA */ {
.phys_start = 0x0310,
.virt_start = 0x0310,
--
2.35.3
--
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/78ddad527d7d0510d6b71fdb39bfb6f04ffa8fc5.1674415741.git.jan.kiszka%40siemens.com.
[PATCH 05/14] configs: arm: jetson-tk1: Move inmate demo to core 1
From: Jan Kiszka
Avoids the overlap with its linux-demo and aligning it with other
systems with 4 or more cores.
Signed-off-by: Jan Kiszka
---
configs/arm/jetson-tk1-inmate-demo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/arm/jetson-tk1-inmate-demo.c
b/configs/arm/jetson-tk1-inmate-demo.c
index 4ab2935d..1dab7ef7 100644
--- a/configs/arm/jetson-tk1-inmate-demo.c
+++ b/configs/arm/jetson-tk1-inmate-demo.c
@@ -49,7 +49,7 @@ struct {
},
.cpus = {
- 0x8,
+ 0x2,
},
.mem_regions = {
--
2.35.3
--
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/151255c22fdb28ede62bdbb4805739aafc9a7d9b.1674415741.git.jan.kiszka%40siemens.com.
[PATCH 06/14] configs: arm: jetson-tk1: Avoid memory region overlap
From: Jan Kiszka
The permitted root cell RAM and the ivshmem regions overlapped. Found by
the config checker.
Signed-off-by: Jan Kiszka
---
configs/arm/jetson-tk1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/arm/jetson-tk1.c b/configs/arm/jetson-tk1.c
index f73fcead..6b37e04c 100644
--- a/configs/arm/jetson-tk1.c
+++ b/configs/arm/jetson-tk1.c
@@ -225,7 +225,7 @@ struct {
/* RAM */ {
.phys_start = 0x8000,
.virt_start = 0x8000,
- .size = 0x7c00,
+ .size = 0x7bf0,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE,
},
--
2.35.3
--
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/073961eaf6e22266735f697903e4e127d3d59d28.1674415741.git.jan.kiszka%40siemens.com.
[PATCH 03/14] scripts: Add config checker script
From: Jan Kiszka
Allows to check most root-cell configs along with typically loaded
non-root cells. Except for dual-core targets and x86, each
config//.cell is tested along -inmate-demo.cell and
-linux-demo.cell.
Note that the configs have to be compiled for all architectures before
calling the script.
Signed-off-by: Jan Kiszka
---
scripts/check-configs | 90 +++
1 file changed, 90 insertions(+)
create mode 100755 scripts/check-configs
diff --git a/scripts/check-configs b/scripts/check-configs
new file mode 100755
index ..7017cc74
--- /dev/null
+++ b/scripts/check-configs
@@ -0,0 +1,90 @@
+#!/bin/sh
+#
+# Jailhouse, a Linux-based partitioning hypervisor
+#
+# Copyright (c) Siemens AG, 2023
+#
+# Authors:
+# Jan Kiszka
+#
+# This work is licensed under the terms of the GNU GPL, version 2. See
+# the COPYING file in the top-level directory.
+#
+
+topdir=$(readlink -f $(dirname $0)/..)
+
+JAILHOUSE_CONFIG_CHECK=${topdir}/tools/jailhouse-config-check
+
+ONLY_TWO_CELLS=" \
+ bananapi.cell \
+ emtrion-rzg1e.cell \
+ emtrion-rzg1m.cell \
+ espressobin.cell \
+ imx8dxl.cell \
+ jetson-tx2.cell \
+ k3-j7200-evm.cell \
+ k3-j721e-evm.cell \
+ ls1028a-rdb.cell \
+ "
+
+only_two_cells()
+{
+ for match in $ONLY_TWO_CELLS; do
+ if [ "$1" == "${match}" ]; then
+ return 0
+ fi
+ done
+ return 1
+}
+
+run_check()
+{
+ [ -f ${topdir}/configs/${arch}/$2 ] || return
+ if [ -n "$3" ]; then
+ echo -n "Checking $1 $2 $3... "
+ output=$(${JAILHOUSE_CONFIG_CHECK} \
+ ${topdir}/configs/${arch}/$1 \
+ ${topdir}/configs/${arch}/$2 \
+ ${topdir}/configs/${arch}/$3)
+ else
+ echo -n "Checking $1 $2... "
+ output=$(${JAILHOUSE_CONFIG_CHECK} \
+ ${topdir}/configs/${arch}/$1 \
+ ${topdir}/configs/${arch}/$2)
+ fi
+ if [ $? -eq 0 ]; then
+ echo "ok"
+ else
+ echo "FAILED"
+ if [ -z "${quiet}" ]; then
+ echo "-->>>---"
+ echo "$output"
+ echo "--<<<---"
+ echo
+ fi
+ fi
+}
+
+[ "$1" == "-q" ] && quiet=1
+
+# x86 is special
+arch=x86
+echo "--- x86 ---"
+run_check qemu-x86.cell apic-demo.cell tiny-demo.cell
+run_check qemu-x86.cell ivshmem-demo.cell linux-x86-demo.cell
+
+for arch in arm arm64; do
+ echo "--- ${arch} ---"
+ for root_cell in $(cd ${topdir}/configs/${arch}; grep -l JHSYS *.cell);
do
+ if only_two_cells ${root_cell}; then
+ run_check ${root_cell} \
+ ${root_cell/.cell/-inmate-demo.cell}
+ run_check ${root_cell} \
+ ${root_cell/.cell/-linux-demo.cell}
+ else
+ run_check ${root_cell} \
+ ${root_cell/.cell/-inmate-demo.cell} \
+ ${root_cell/.cell/-linux-demo.cell}
+ fi
+ done
+done
--
2.35.3
--
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/051aa4a9d5e96ba29bf407e6bd43046764a7acfb.1674415741.git.jan.kiszka%40siemens.com.
[PATCH 00/14] Configs housekeeping
While preparing the CPU-config changes for upstream, I first of all
added checks regarding CPU usage to our config checker. This confirmed
what I saw in manual review before: a lack of consistency in the core
assignment to permit running linux and inmate demo in parallel (on >2
cores systems).
The more I ran the checker on older configs, the more issues I found.
Many are resolved - but not all. This adds a new script to scan all
compiled configs, at least rool cells, inmate and linux demos, and run
the checker on them. So, you can check what is still broken:
# scripts/check-configs -q
...
Checking imx8dxl.cell imx8dxl-inmate-demo.cell... FAILED
...
Checking imx8qm.cell imx8qm-inmate-demo.cell imx8qm-linux-demo.cell... FAILED
...
Checking k3-j7200-evm.cell k3-j7200-evm-inmate-demo.cell... FAILED
Checking k3-j7200-evm.cell k3-j7200-evm-linux-demo.cell... FAILED
Checking k3-j721e-evm.cell k3-j721e-evm-inmate-demo.cell... FAILED
Checking k3-j721e-evm.cell k3-j721e-evm-linux-demo.cell... FAILED
Please check, some issues look fatal (mapping GICD/R...).
Jan
CC: Alice Guo
CC: Jiafei Pan
CC: Lad Prabhakar
CC: Matt Ranostay
CC: Peng Fan
CC: Ralf Ramsauer
Jan Kiszka (14):
pyjailhouse: config_parser: Build CPU set from cell configuration
tools: jailhouse-config-check: Add CPU set checks
scripts: Add config checker script
configs: arm: dts: Silence style warnings
configs: arm: jetson-tk1: Move inmate demo to core 1
configs: arm: jetson-tk1: Avoid memory region overlap
configs: arm64: Consistently move inmate demo to 2 core
configs: arm64: imx8dxl: Mark 32-bit demo also as 64-bit config
configs: arm: emtrion-rzg1{h,m}: Fix config checker findings
configs: arm64: jetson-tx{1,2}: Fix config checker findings
configs: arm64: ls1046a: Resolve overlap between two RAM regions
configs: arm64: ultra96/zcu102: Carve out SMMU from MMIO region
configs: arm64: k3-am654: Rename inmate demo
ci: Update to actions/checkout@v3 and actions/cache@v3
.github/workflows/main.yaml | 4 +-
configs/arm/dts/inmate-bananapi.dts | 6 +-
configs/arm/dts/inmate-orangepi0.dts | 4 +-
configs/arm/emtrion-rzg1h.c | 42 +++--
configs/arm/emtrion-rzg1m.c | 21 ++---
configs/arm/jetson-tk1-inmate-demo.c | 2 +-
configs/arm/jetson-tk1.c | 2 +-
configs/arm64/dts/inmate-k3-am625-sk.dts | 7 --
configs/arm64/imx8dxl-inmate-demo.c | 3 +-
configs/arm64/imx8mm-inmate-demo.c| 2 +-
configs/arm64/imx8mn-inmate-demo.c| 2 +-
configs/arm64/imx8mp-inmate-demo.c| 2 +-
configs/arm64/imx8mq-inmate-demo.c| 2 +-
configs/arm64/imx8qm-inmate-demo.c| 2 +-
configs/arm64/jetson-tx1-inmate-demo.c| 2 +-
configs/arm64/jetson-tx1.c| 2 +-
configs/arm64/jetson-tx2.c| 11 +--
configs/arm64/k3-am625-sk-inmate-demo.c | 2 +-
configs/arm64/k3-am625-sk-linux-demo.c| 2 +-
...mate-demo.c => k3-am654-idk-inmate-demo.c} | 2 +-
configs/arm64/ls1046a-rdb.c | 2 +-
.../arm64/miriac-sbc-ls1046a-inmate-demo.c| 2 +-
configs/arm64/renesas-r8a774a1-inmate-demo.c | 2 +-
configs/arm64/ultra96.c | 13 ++-
configs/arm64/zynqmp-zcu102-inmate-demo.c | 2 +-
configs/arm64/zynqmp-zcu102.c | 13 ++-
pyjailhouse/config_parser.py | 12 ++-
scripts/check-configs | 90 +++
tools/jailhouse-config-check | 26 ++
29 files changed, 193 insertions(+), 91 deletions(-)
rename configs/arm64/{k3-am654-inmate-demo.c => k3-am654-idk-inmate-demo.c}
(99%)
create mode 100755 scripts/check-configs
--
2.35.3
--
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/cover.1674415741.git.jan.kiszka%40siemens.com.
Re: [PATCH v2 0/3] Add support for Renesas RZ/G2M
On 19.01.23 22:45, Prabhakar wrote: > From: Lad Prabhakar > > Hi All, > > This patch series adds support for Renesas RZ/G2M SoC [0] (root cell > config) and adds demo cell config for HopeRun HiHope RZ/G2M platform [1]. > > Changes apply on top of next branch [2] and the kernel used for testing is > 5.10 (-cip) based on BSP-3.0.0 [3] release from Renesas. > > [0] > https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg2m-ultra-high-performance-microprocessors-arm-cortex-a57-and-arm-cortex-a53-cpus-3d-graphics-and-4k > [1] > https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg2m-hihope-rzg2m-reference-board#overview > [2] https://github.com/siemens/jailhouse/tree/next (e57d1eff) > [3] https://github.com/renesas-rz/meta-renesas/tree/BSP-3.0.0 > > v1->v2 > * Added inmate demo > * Added support for IVSHMEM > * Rebased on current next > > Note, > * For IVSHMEM Linux demo I have tested by pinging the root and inmate cell > * For IVSHMEM bare metal demo I ran the "ivshmem-demo -t 1" and noticed the > interrupt counters on root and inmate cells > > Cheers, > Prabhakar > > Lad Prabhakar (3): > configs: arm64: Add root cell config for Renesas RZ/G2M SoC > configs: arm64: Add linux-inmate-demo cell config for Renesas RZ/G2M > configs: arm64: Add inmate-demo cell config for Renesas RZ/G2M > > configs/arm64/dts/inmate-r8a774a1-hihope.dts | 244 > configs/arm64/renesas-r8a774a1-inmate-demo.c | 140 ++ > configs/arm64/renesas-r8a774a1-linux-demo.c | 184 +++ > configs/arm64/renesas-r8a774a1.c | 1235 ++ > 4 files changed, 1803 insertions(+) > create mode 100644 configs/arm64/dts/inmate-r8a774a1-hihope.dts > create mode 100644 configs/arm64/renesas-r8a774a1-inmate-demo.c > create mode 100644 configs/arm64/renesas-r8a774a1-linux-demo.c > create mode 100644 configs/arm64/renesas-r8a774a1.c > Thanks, merged. Jan -- Siemens AG, Technology 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/0a121c6c-d705-f0d0-db4e-b036128c56f6%40siemens.com.
Re: [PATCH v2 3/3] pyjailhouse: support automatic architecture detection
On 10.01.23 22:14, Ralf Ramsauer wrote:
> Signed-off-by: Ralf Ramsauer
> ---
> pyjailhouse/config_parser.py | 23 ---
> tools/jailhouse-config-check | 30 --
> 2 files changed, 28 insertions(+), 25 deletions(-)
>
> diff --git a/pyjailhouse/config_parser.py b/pyjailhouse/config_parser.py
> index e60b2ce9..2a59b651 100644
> --- a/pyjailhouse/config_parser.py
> +++ b/pyjailhouse/config_parser.py
> @@ -20,6 +20,21 @@ from .extendedenum import ExtendedEnum
>
> # Keep the whole file in sync with include/jailhouse/cell-config.h.
> _CONFIG_REVISION = 14
> +JAILHOUSE_X86 = 0
> +JAILHOUSE_ARM = 1
> +JAILHOUSE_ARM64 = 2
> +
> +JAILHOUSE_ARCH_MAX = 2
> +
> +
> +def convert_arch(arch):
> +if arch > JAILHOUSE_ARCH_MAX:
> +raise RuntimeError('Configuration has unsupported architecture')
> +return {
> +JAILHOUSE_X86: 'x86',
> +JAILHOUSE_ARM: 'arm',
> +JAILHOUSE_ARM64: 'arm64',
> +}[arch]
>
>
> def flag_str(enum_class, value, separator=' | '):
> @@ -163,6 +178,7 @@ class CellConfig:
> if revision != _CONFIG_REVISION:
> raise RuntimeError('Configuration file revision
> mismatch')
> self.name = str(name.decode().strip('\0'))
> +self.arch = convert_arch(self.arch)
>
> mem_region_offs = struct.calcsize(CellConfig._HEADER_FORMAT) + \
> self.cpu_set_size
> @@ -242,7 +258,7 @@ class SystemConfig:
> _ARCH_ARM_FORMAT = '=BB2xQ'
> _ARCH_X86_FORMAT = '=HBxIII28x'
>
> -def __init__(self, data, arch):
> +def __init__(self, data):
> self.data = data
>
> try:
> @@ -253,6 +269,7 @@ class SystemConfig:
> raise RuntimeError('Not a root cell configuration')
> if revision != _CONFIG_REVISION:
> raise RuntimeError('Configuration file revision mismatch')
> +self.arch = convert_arch(self.arch)
>
> offs = struct.calcsize(self._HEADER_FORMAT)
> self.hypervisor_memory = MemRegion(self.data[offs:])
> @@ -273,7 +290,7 @@ class SystemConfig:
> self.iommus.append(iommu)
> offs += IOMMU.SIZE
>
> -if arch in ('arm', 'arm64'):
> +if self.arch in ('arm', 'arm64'):
> (self.arm_maintenance_irq,
> self.arm_gic_version,
> self.arm_gicd_base,
> @@ -282,7 +299,7 @@ class SystemConfig:
> self.arm_gicv_base,
> self.arm_gicr_base) = \
> struct.unpack_from(self._ARCH_ARM_FORMAT,
> self.data[offs:])
> -elif arch == 'x86':
> +elif self.arch == 'x86':
> (self.x86_pm_timer_address,
> self.x86_apic_mode,
> self.x86_vtd_interrupt_limit,
> diff --git a/tools/jailhouse-config-check b/tools/jailhouse-config-check
> index d6ea7079..95de6fd4 100755
> --- a/tools/jailhouse-config-check
> +++ b/tools/jailhouse-config-check
> @@ -37,8 +37,6 @@ class ResourceRegion(config_parser.MemRegion):
> sys.argv[0] = sys.argv[0].replace('-', ' ')
>
> parser = argparse.ArgumentParser(description='Check system and cell
> configurations.')
> -parser.add_argument('-a', '--arch', metavar='ARCH',
> -help='target architecture')
> parser.add_argument('syscfg', metavar='SYSCONFIG',
> type=argparse.FileType('rb'),
> help='system configuration file')
> @@ -52,36 +50,23 @@ except IOError as e:
> print(e.strerror, file=sys.stderr)
> exit(1)
>
> -arch = args.arch
> -if not arch:
> -arch_str = os.uname()[4]
> -if arch_str in ('i686', 'x86_64'):
> -arch = 'x86'
> -elif arch_str == 'armv7l':
> -arch = 'arm'
> -elif arch_str == 'aarch64':
> -arch = 'arm64'
> -else:
> -arch = None
> -if not arch in ('x86', 'arm', 'arm64'):
> -print('Unsupported architecture', file=sys.stderr)
> -exit(1)
> -
> print("Reading configuration set:")
> -
> try:
> -sysconfig = config_parser.SystemConfig(args.syscfg.read(), arch)
> +sysconfig = config_parser.SystemConfig(args.syscfg.read())
> root_cell = sysconfig.root_cell
> except RuntimeError as e:
> print(str(e) + ": " + args.syscfg.name, file=sys.stderr)
> exit(1)
> cells = [root_cell]
> +print(" Architecture: %s" % sysconfig.arch)
> print(" Root cell: %s (%s)" % (root_cell.name, args.syscfg.name))
>
> non_root_cells = []
> for cfg in args.cellcfgs:
> try:
> cell = config_parser.CellConfig(cfg.read())
> +if cell.arch != sysconfig.arch:
> +raise RuntimeError('Cell architecture mismatch: %s' % cell.arch)
> except RuntimeError as e:
> print(str(e) + ": " + cfg.name, file=sys.stderr)
> exit(1)
> @@ -162,9 +147,10 @@ if len(iommu_resources) > 0:
> ret=1
>
Re: [PATCH RESEND 0/3] Add support for Renesas RZ/G2M
On 15.01.23 15:01, Lad, Prabhakar wrote: > Hi Jan, > > On Wed, Jan 4, 2023 at 9:26 AM Jan Kiszka wrote: >> >> On 02.01.23 21:55, Lad, Prabhakar wrote: >>> Hi Jan, >>> >>> On Mon, Jan 2, 2023 at 6:50 AM Jan Kiszka wrote: >>>> >>>> Hi Prabhakar, >>>> >>>> On 29.11.22 15:29, Lad, Prabhakar wrote: >>>>> Hi Jan, >>>>> >>>>> On Sun, Nov 6, 2022 at 11:05 PM Lad Prabhakar >>>>> wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> This patch series adds support for Renesas RZ/G2M SoC [0] (root cell >>>>>> config) and adds demo cell config for HopeRun HiHope RZ/G2M platform [1]. >>>>>> >>>>>> Changes apply on top of next branch [2] and the kernel used for testing >>>>>> is >>>>>> 5.10 (-cip) based on BSP-3.0.0 [3] release from Renesas. >>>>>> >>>>>> No changes from previous version sent to ML, just rebased on the next >>>>>> branch. >>>>>> >>>>>> [0] >>>>>> https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg2m-ultra-high-performance-microprocessors-arm-cortex-a57-and-arm-cortex-a53-cpus-3d-graphics-and-4k >>>>>> [1] >>>>>> https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg2m-hihope-rzg2m-reference-board#overview >>>>>> [2] https://github.com/siemens/jailhouse/tree/next (9391d30a) >>>>>> [3] https://github.com/renesas-rz/meta-renesas/tree/BSP-3.0.0 >>>>>> >>>>>> Cheers, >>>>>> Prabhakar >>>>>> >>>>>> Lad Prabhakar (3): >>>>>> renesas: Add SCIF support >>>>>> configs: arm64: Add root cell config for Renesas RZ/G2M SoC >>>>>> configs: arm64: Add demo cell config for Renesas RZ/G2M >>>>>> >>>>>> Documentation/debug-output.md |1 + >>>>>> configs/arm64/dts/inmate-r8a774a1-hihope.dts | 228 >>>>>> configs/arm64/renesas-r8a774a1-linux-demo.c | 114 ++ >>>>>> configs/arm64/renesas-r8a774a1.c | 1134 + >>>>>> hypervisor/arch/arm-common/Kbuild |2 +- >>>>>> hypervisor/arch/arm-common/dbg-write.c|2 + >>>>>> hypervisor/arch/arm-common/include/asm/uart.h |2 +- >>>>>> hypervisor/arch/arm-common/uart-scif.c| 44 + >>>>>> include/jailhouse/console.h |1 + >>>>>> inmates/lib/arm-common/Makefile.lib |2 +- >>>>>> inmates/lib/arm-common/uart-scif.c| 65 + >>>>>> inmates/lib/arm-common/uart.c |2 + >>>>>> 12 files changed, 1594 insertions(+), 3 deletions(-) >>>>>> create mode 100644 configs/arm64/dts/inmate-r8a774a1-hihope.dts >>>>>> create mode 100644 configs/arm64/renesas-r8a774a1-linux-demo.c >>>>>> create mode 100644 configs/arm64/renesas-r8a774a1.c >>>>>> create mode 100644 hypervisor/arch/arm-common/uart-scif.c >>>>>> create mode 100644 inmates/lib/arm-common/uart-scif.c >>>>>> >>>>> Gentle ping. >>>>> >>>> >>>> Sorry for letting you wait /that/ long: >>>> >>>> Patches look good except that they are missing ivshmem support and an >>>> inmate-demo cell. You should have a demo and a networking ivshmem device >>>> in the root and the linux cell, the inmate demo needs just the demo >>>> device. Check out other boards for the required pattern, e.g. the rpi4. >>>> >>> OK, I will get this in. Can you please point me to any docs on testing >>> networking ivshmem device if any. >>> >> >> Once both cells are configured, you can assigned IPs to both network >> devices, ping them or do ssh from the root cell to the non-root one. See >> jailhouse-images for a pre-integration of such a setup, e.g. that of >> qemu-arm64. I've just pushed a new version that builds here into the >> 'next' branch (still needs more work). >> > I had couple of question, > 1: For the pci_mmconfig_base should this PA? (If PA what range should > be ideally selected and should this be reserved in the root cell?) If you have a emulated PCI host controller (which is the common case on non-x86), this address should be free in the physical range of the target. > 2: How do we calculate vpci_irq_base? There have to be up to 4 unused (but GIC-wise supported) interrupts at that base. > 3: When do we need to configure the stream_ids? Only if you configure an SMMU. Do you have one and plan to use is? > 4: For the IVSHMEM 00:00.0 (demo) the PA range should this be reserved > in the root cell? The PA should be physical RAM that is otherwise not used by any cell or the hypervisor itself. > 5: And similarly for IVSHMEM (networking) the PA range should this be > reserved in the root cell? Same story. Jan -- Siemens AG, Technology 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/e26f0792-ec58-9edd-1bce-dcc8a6df0382%40siemens.com.
Re: [PATCH 2/3] driver: add architecture sanity checks
On 10.01.23 17:48, Ralf Ramsauer wrote:
> Now that we have architecture information, we can check it. Just like we
> do it for the magic bytes of the configs.
>
> Signed-off-by: Ralf Ramsauer
> ---
> driver/cell.c | 4
> driver/main.c | 4
> driver/main.h | 8
> 3 files changed, 16 insertions(+)
>
> diff --git a/driver/cell.c b/driver/cell.c
> index ade61edb..f9d7982b 100644
> --- a/driver/cell.c
> +++ b/driver/cell.c
> @@ -186,6 +186,10 @@ int jailhouse_cmd_cell_create(struct
> jailhouse_cell_create __user *arg)
> err = -EINVAL;
> goto kfree_config_out;
> }
> + if (config->architecture != JAILHOUSE_ARCHITECTURE) {
> + pr_err("jailhouse: Architecture mismatch\n");
Maybe clearer: "Configuration architecture mismatch", just like for the
revision below.
> + goto kfree_config_out;
> + }
>
> config->name[JAILHOUSE_CELL_NAME_MAXLEN] = 0;
>
> diff --git a/driver/main.c b/driver/main.c
> index 64e2b9a4..fe119890 100644
> --- a/driver/main.c
> +++ b/driver/main.c
> @@ -396,6 +396,10 @@ static int jailhouse_cmd_enable(struct jailhouse_system
> __user *arg)
> pr_err("jailhouse: Configuration revision mismatch\n");
> return -EINVAL;
> }
> + if (config_header.architecture != JAILHOUSE_ARCHITECTURE) {
> + pr_err("jailhouse: Architecture mismatch\n");
> + return -EINVAL;
> + }
>
> config_header.root_cell.name[JAILHOUSE_CELL_NAME_MAXLEN] = 0;
>
> diff --git a/driver/main.h b/driver/main.h
> index 7c9f661c..9df51aa1 100644
> --- a/driver/main.h
> +++ b/driver/main.h
> @@ -17,6 +17,14 @@
>
> #include "cell.h"
>
> +#ifdef CONFIG_X86
> +#define JAILHOUSE_ARCHITECTURE JAILHOUSE_X86
> +#elif defined(CONFIG_ARM)
> +#define JAILHOUSE_ARCHITECTURE JAILHOUSE_ARM
> +#elif defined(CONFIG_ARM64)
> +#define JAILHOUSE_ARCHITECTURE JAILHOUSE_ARM64
> +#endif
> +
> extern struct mutex jailhouse_lock;
> extern bool jailhouse_enabled;
> extern void *hypervisor_mem;
All the rest looks good to me.
Jan
--
Siemens AG, Technology
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/90801fb1-225a-b828-5d94-d2c3a53c46f8%40siemens.com.
Re: [PATCH 1/3] configs: enrich configs with architecture information
On 10.01.23 17:48, Ralf Ramsauer wrote:
> This has two advantages:
> - Automatic architecture detection in python tooling
> - Sledgehammer sanity check when enabling jailhouse / creating cells
>
> This commit just adds the field in the cell/sysconfig, adds the fields
> to the configs and aligns the config checker that it will not break for
> the moment.
>
> Logic is added later, config revision got increased.
>
> Signed-off-by: Ralf Ramsauer
...
> diff --git a/include/jailhouse/cell-config.h b/include/jailhouse/cell-config.h
> index 6b54e34b..9fd03ff8 100644
> --- a/include/jailhouse/cell-config.h
> +++ b/include/jailhouse/cell-config.h
> @@ -46,11 +46,20 @@
> #define ARRAY_SIZE(a) sizeof(a) / sizeof(a[0])
> #endif
>
> +/*
> + * Supported architectures of Jailhouse. Used in the header of system and
> cell
> + * configurations, as well as in python tooling for automatic architecture
> + * detection.
> + */
> +#define JAILHOUSE_X860
> +#define JAILHOUSE_ARM1
> +#define JAILHOUSE_ARM64 2
> +
> /*
> * Incremented on any layout or semantic change of system or cell config.
> * Also update formats and HEADER_REVISION in pyjailhouse/config_parser.py.
> */
> -#define JAILHOUSE_CONFIG_REVISION13
> +#define JAILHOUSE_CONFIG_REVISION14
>
> #define JAILHOUSE_CELL_NAME_MAXLEN 31
>
> @@ -84,6 +93,8 @@
> struct jailhouse_cell_desc {
> char signature[6];
> __u16 revision;
> + __u8 architecture;
> + __u8 __res[3];
>
It's not really that we have to save space on this file, but still: Why
not reducing the signature to 5 bytes ("JHCLL", "JHSYS") and putting the
architecture byte right behind it? The architecture conceptually belongs
closer to the signature. ;)
Jan
--
Siemens AG, Technology
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/b6c9508d-a6a3-7cf5-1cc6-a194cb181451%40siemens.com.
[PATCH] ivshmem-net: Ensure that napi_schedule is always called with bh disabled
From: Jan Kiszka ivshm_net_run is executed in task context, thus also with bottom-halves enabled. Calling napi_schedule in that state can cause problems under NOHZ, see also https://patches.linaro.org/project/linux-usb/patch/877dk162mo@nanos.tec.linutronix.de/ Therefore, disable bh around this call. Other invocations of napi_schedule are not affected: ivshm_net_poll - poll routine, always called with bh disabled ivshm_net_int_tx_rx - interrupt handler, bh implicitly off ivshm_net_poll_controller - always called with IRQs off, thus also bh Reported-by: Peng Fan Signed-off-by: Jan Kiszka --- drivers/net/ivshmem-net.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ivshmem-net.c b/drivers/net/ivshmem-net.c index 9406b4dcc6c0..a80eea5aecaf 100644 --- a/drivers/net/ivshmem-net.c +++ b/drivers/net/ivshmem-net.c @@ -558,7 +558,9 @@ static void ivshm_net_run(struct net_device *ndev) netif_start_queue(ndev); napi_enable(>napi); + local_bh_disable(); napi_schedule(>napi); + local_bh_enable(); ivshm_net_set_state(in, IVSHM_NET_STATE_RUN); } -- 2.35.3 -- 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/bb0226f4-5c26-0fc5-fdfe-e6d936e34102%40web.de.
Re: STM32MP1 hangs on when entering hypervisor
On 05.01.23 18:21, Tommi Parkkila wrote: > Oh, I was missing *.cell from the point 2. Now fixed and no complaints. > > to 5. tammik. 2023 klo 12.20 Tommi Parkkila (tommi.parkk...@gmail.com > <mailto:tommi.parkk...@gmail.com>) kirjoitti: > > Jan - Just ran the config check on the host PC and on target. > > 1. On host, it identified some memregion overlappings that were due > my own copy/paste errors. It also complained a missing resource > interception for architecture x86: > */In cell 'STM32MP1-Root', region 1 > phys_start: 0xf760 > virt_start: 0xf760 > size: 0x09a0 > flags: JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | > JAILHOUSE_MEM_EXECUTE > overlaps with xAPIC Another detail when running cross: "-a arm" - you don't have to worry about x86 resources on your target. Jan > phys_start: 0xfee0 > virt_start: 0xfee0 > size: 0x1000 > flags: /* > I fixed the copy paste mem overlappings, do I need to worry about > the xAPIC overlapping? > */ > /* > 2. On target, the check complained the configuration is not root > cell configuration??? > */root@stm32mp1:~# jailhouse/tools/jailhouse-config-check > jailhouse/configs/stm32mp157.c > Reading configuration set: > Not a root cell configuration: jailhouse/configs/arm/stm32mp157.c/* > The config here is the same as ran on the host PC. What causes it to > complain the above? > > to 5. tammik. 2023 klo 11.55 Jan Kiszka (jan.kis...@siemens.com > <mailto:jan.kis...@siemens.com>) kirjoitti: > > On 05.01.23 17:53, Tommi Parkkila wrote: > > Jan - Thanks again. I have not tried the config check yet. > Actually, it > > does not work on hw currently, it does not find pyjailhouse > module. I'll > > check whats going wrong with it and let you know. > > You can also run it offline, even directly from the source folder > (tools/jailhouse-config-check ...). > > Jan > > > -tommi > > > > to 5. tammik. 2023 klo 10.21 Jan Kiszka > (jan.kis...@siemens.com <mailto:jan.kis...@siemens.com> > > <mailto:jan.kis...@siemens.com > <mailto:jan.kis...@siemens.com>>) kirjoitti: > > > > On 05.01.23 15:34, Tommi Parkkila wrote: > > > Thanks for your reply, Jan. I managed to get forward > from the 'hang' > > > condition. There were several misdefinitions on my root-cell > > > configuration. Now I get the root-cell started > sometimes, but more > > often > > > I get two types of issues after enable command. Any help > or ideas > > where > > > to continue my debugging would be greatly appreciated. > Please, see the > > > issues explained below. > > > > Already tried "jailhouse config check"? > > > > > > > > Thanks, > > > -tommi > > > > > > + > > > > > > 1. Terminal hangs > > > -- After the enable command for the root cell, jailhouse > gets started > > > but then the terminal goes unresponsive. Below, example > log, where I > > > give ls cmd, which then causes terminal to go > unresponsive...: > > > > > > > Missing interrupts could be one reason. Or something is > completely > > broken with memory mapping so that a kernel device driver > gets stuck on > > waiting for some register bit to flip, e.g. But most > frequent are > > interrupt issues, specifically around GIC resources being > improperly > > passed through. The config checker may find that. > > > > > /*root@stm32mp1:~# modprobe jailhouse > > > [ 1315.034414] jailhouse: loading out-of-tree module > taints kernel. > > > root@stm32mp1:~# jailhouse enable > > > ~/jailhouse/configs/arm/itron_stm32mp157.cell > > > > > > Initializing Jailhouse hypervisor v0.12 > (314-gc7a1b697-dirty)
Re: STM32MP1 hangs on when entering hypervisor
On 05.01.23 17:53, Tommi Parkkila wrote: > Jan - Thanks again. I have not tried the config check yet. Actually, it > does not work on hw currently, it does not find pyjailhouse module. I'll > check whats going wrong with it and let you know. You can also run it offline, even directly from the source folder (tools/jailhouse-config-check ...). Jan > -tommi > > to 5. tammik. 2023 klo 10.21 Jan Kiszka (jan.kis...@siemens.com > <mailto:jan.kis...@siemens.com>) kirjoitti: > > On 05.01.23 15:34, Tommi Parkkila wrote: > > Thanks for your reply, Jan. I managed to get forward from the 'hang' > > condition. There were several misdefinitions on my root-cell > > configuration. Now I get the root-cell started sometimes, but more > often > > I get two types of issues after enable command. Any help or ideas > where > > to continue my debugging would be greatly appreciated. Please, see the > > issues explained below. > > Already tried "jailhouse config check"? > > > > > Thanks, > > -tommi > > > > + > > > > 1. Terminal hangs > > -- After the enable command for the root cell, jailhouse gets started > > but then the terminal goes unresponsive. Below, example log, where I > > give ls cmd, which then causes terminal to go unresponsive...: > > > > Missing interrupts could be one reason. Or something is completely > broken with memory mapping so that a kernel device driver gets stuck on > waiting for some register bit to flip, e.g. But most frequent are > interrupt issues, specifically around GIC resources being improperly > passed through. The config checker may find that. > > > /*root@stm32mp1:~# modprobe jailhouse > > [ 1315.034414] jailhouse: loading out-of-tree module taints kernel. > > root@stm32mp1:~# jailhouse enable > > ~/jailhouse/configs/arm/itron_stm32mp157.cell > > > > Initializing Jailhouse hypervisor v0.12 (314-gc7a1b697-dirty) on CPU 0 > > Code location: 0xf040 > > Page pool usage after early setup: mem 28/1514, remap 0/131072 > > Initializing processors: > > CPU 0... OK > > CPU 1... OK > > Initializing unit: irqchip > > Initializing unit: PCI > > Page pool usage after late setup: mem 50/1514, remap 5/131072 > > [0] Activating hypervisor > > [ 1355.352714] The Jailhouse is opening. > > root@stm32mp1:~# ls*/ > > > > 2. Issue with setting CPU clock > > -- The second issue I see is related to i2c bus and system clock. > > Terminal starts printing error statements infinitely after Jailhouse > > opening. Below, is a snippet of an example logs. > > > > */[ 85.322027] The Jailhouse is opening. > > [ 85.322648] stm32f7-i2c 5c002000.i2c: failed to prepare_enable > clock > > root@stm32mp1:~# [ 85.339233] cpu cpu0: _set_opp_voltage: failed to > > set voltage (135 135 135 mV): -22 > > [ 85.350413] cpufreq: __target_index: Failed to change cpu > frequency: -22 > > [ 85.357706] cpu cpu0: _set_opp_voltage: failed to set voltage > > (135 135 135 mV): -22 > > [ 85.365124] cpufreq: __target_index: Failed to change cpu > frequency: -22 > > [ 85.381985] cpu cpu0: _set_opp_voltage: failed to set voltage > > (135 135 135 mV): -22 > > /*- - - > > + > > Same possible reasons as above. Or do you know how clock control happens > on that platform? Is there firmware (TF-A?) involved? > > Jan > > -- > Siemens AG, Technology > Competence Center Embedded Linux > -- Siemens AG, Technology 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/e9acd20c-b3cb-4887-788a-266534ab5a19%40siemens.com.
Re: STM32MP1 hangs on when entering hypervisor
On 05.01.23 15:34, Tommi Parkkila wrote: > Thanks for your reply, Jan. I managed to get forward from the 'hang' > condition. There were several misdefinitions on my root-cell > configuration. Now I get the root-cell started sometimes, but more often > I get two types of issues after enable command. Any help or ideas where > to continue my debugging would be greatly appreciated. Please, see the > issues explained below. Already tried "jailhouse config check"? > > Thanks, > -tommi > > + > > 1. Terminal hangs > -- After the enable command for the root cell, jailhouse gets started > but then the terminal goes unresponsive. Below, example log, where I > give ls cmd, which then causes terminal to go unresponsive...: > Missing interrupts could be one reason. Or something is completely broken with memory mapping so that a kernel device driver gets stuck on waiting for some register bit to flip, e.g. But most frequent are interrupt issues, specifically around GIC resources being improperly passed through. The config checker may find that. > /*root@stm32mp1:~# modprobe jailhouse > [ 1315.034414] jailhouse: loading out-of-tree module taints kernel. > root@stm32mp1:~# jailhouse enable > ~/jailhouse/configs/arm/itron_stm32mp157.cell > > Initializing Jailhouse hypervisor v0.12 (314-gc7a1b697-dirty) on CPU 0 > Code location: 0xf040 > Page pool usage after early setup: mem 28/1514, remap 0/131072 > Initializing processors: > CPU 0... OK > CPU 1... OK > Initializing unit: irqchip > Initializing unit: PCI > Page pool usage after late setup: mem 50/1514, remap 5/131072 > [0] Activating hypervisor > [ 1355.352714] The Jailhouse is opening. > root@stm32mp1:~# ls*/ > > 2. Issue with setting CPU clock > -- The second issue I see is related to i2c bus and system clock. > Terminal starts printing error statements infinitely after Jailhouse > opening. Below, is a snippet of an example logs. > > */[ 85.322027] The Jailhouse is opening. > [ 85.322648] stm32f7-i2c 5c002000.i2c: failed to prepare_enable clock > root@stm32mp1:~# [ 85.339233] cpu cpu0: _set_opp_voltage: failed to > set voltage (135 135 135 mV): -22 > [ 85.350413] cpufreq: __target_index: Failed to change cpu frequency: -22 > [ 85.357706] cpu cpu0: _set_opp_voltage: failed to set voltage > (135 135 135 mV): -22 > [ 85.365124] cpufreq: __target_index: Failed to change cpu frequency: -22 > [ 85.381985] cpu cpu0: _set_opp_voltage: failed to set voltage > (135 135 135 mV): -22 > /*- - - > + Same possible reasons as above. Or do you know how clock control happens on that platform? Is there firmware (TF-A?) involved? Jan -- Siemens AG, Technology 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/990aa280-3365-429b-cd73-d1b89b0b4a83%40siemens.com.
Re: Sensitivity of hypervisor configurations to HW changes (x86 target)
On 03.01.23 14:39, Jan-Marc Stranz wrote: > For the productive use of the hypervisor "Jailhouse" I am concerned > about another topic: "Sensitivity of the hypervisor configurations to HW > changes". > > I have already created the hypervisor configurations for 8 different x86 > HW targets (evaluation boards, industrial PC's, single board computers, > ...) for the root cell and for up to 2 guest cells. > > I also "cloned" some HW targets; however, I was scrupulously careful > that the HW (RAM, PCI devices, BIOS version, ...) was identical. > > To duplicate an x86 HW target, in my experience, the following > components must remain the same so that the hypervisor configurations > already created can still be used: > > 1. CPU model and architecture > 2. RAM memory size > 3. PCI devices (including M.2 NVME SSD!) > 4. BIOS version > > For mass production based on a Single Board Computer (SBC) some points > can easily be kept (e.g. CPU model and architecture, PCI devices (except > M.2 NVME SSD), BIOS version). > > On the other hand, you can't guarantee that you can always use the same > type for the M.2 NVME SSD, for example. > However, the change of the type of the M.2 NVME SSD, which is actually > imperceptible for the user, will possibly be noticeable in the > hypervisor configuration (e.g. different PCI capabilities). > > Another problem is the deviations that creep into memory and I/O layouts. > > Are there any experiences and practical solutions regarding this topic? > I would appreciate any advice on this! > As I suggested offline already: If you don't have control over checking new hardware combinations /before/ they go into production, I would consider adding a post-production check that runs 'jailhouse config create' on the device (or outside, against what 'jailhouse config collect' provided) and compares the generated reference config against an earlier version. On deviations, an engineer would have to look at the details. Jan -- Siemens AG, Technology 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/fecd57a3-ce2d-f2ff-d2a0-a1d70fdfb43c%40siemens.com.
Re: [PATCH RESEND 0/3] Add support for Renesas RZ/G2M
On 02.01.23 21:55, Lad, Prabhakar wrote: > Hi Jan, > > On Mon, Jan 2, 2023 at 6:50 AM Jan Kiszka wrote: >> >> Hi Prabhakar, >> >> On 29.11.22 15:29, Lad, Prabhakar wrote: >>> Hi Jan, >>> >>> On Sun, Nov 6, 2022 at 11:05 PM Lad Prabhakar >>> wrote: >>>> >>>> Hi All, >>>> >>>> This patch series adds support for Renesas RZ/G2M SoC [0] (root cell >>>> config) and adds demo cell config for HopeRun HiHope RZ/G2M platform [1]. >>>> >>>> Changes apply on top of next branch [2] and the kernel used for testing is >>>> 5.10 (-cip) based on BSP-3.0.0 [3] release from Renesas. >>>> >>>> No changes from previous version sent to ML, just rebased on the next >>>> branch. >>>> >>>> [0] >>>> https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg2m-ultra-high-performance-microprocessors-arm-cortex-a57-and-arm-cortex-a53-cpus-3d-graphics-and-4k >>>> [1] >>>> https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg2m-hihope-rzg2m-reference-board#overview >>>> [2] https://github.com/siemens/jailhouse/tree/next (9391d30a) >>>> [3] https://github.com/renesas-rz/meta-renesas/tree/BSP-3.0.0 >>>> >>>> Cheers, >>>> Prabhakar >>>> >>>> Lad Prabhakar (3): >>>> renesas: Add SCIF support >>>> configs: arm64: Add root cell config for Renesas RZ/G2M SoC >>>> configs: arm64: Add demo cell config for Renesas RZ/G2M >>>> >>>> Documentation/debug-output.md |1 + >>>> configs/arm64/dts/inmate-r8a774a1-hihope.dts | 228 >>>> configs/arm64/renesas-r8a774a1-linux-demo.c | 114 ++ >>>> configs/arm64/renesas-r8a774a1.c | 1134 + >>>> hypervisor/arch/arm-common/Kbuild |2 +- >>>> hypervisor/arch/arm-common/dbg-write.c|2 + >>>> hypervisor/arch/arm-common/include/asm/uart.h |2 +- >>>> hypervisor/arch/arm-common/uart-scif.c| 44 + >>>> include/jailhouse/console.h |1 + >>>> inmates/lib/arm-common/Makefile.lib |2 +- >>>> inmates/lib/arm-common/uart-scif.c| 65 + >>>> inmates/lib/arm-common/uart.c |2 + >>>> 12 files changed, 1594 insertions(+), 3 deletions(-) >>>> create mode 100644 configs/arm64/dts/inmate-r8a774a1-hihope.dts >>>> create mode 100644 configs/arm64/renesas-r8a774a1-linux-demo.c >>>> create mode 100644 configs/arm64/renesas-r8a774a1.c >>>> create mode 100644 hypervisor/arch/arm-common/uart-scif.c >>>> create mode 100644 inmates/lib/arm-common/uart-scif.c >>>> >>> Gentle ping. >>> >> >> Sorry for letting you wait /that/ long: >> >> Patches look good except that they are missing ivshmem support and an >> inmate-demo cell. You should have a demo and a networking ivshmem device >> in the root and the linux cell, the inmate demo needs just the demo >> device. Check out other boards for the required pattern, e.g. the rpi4. >> > OK, I will get this in. Can you please point me to any docs on testing > networking ivshmem device if any. > Once both cells are configured, you can assigned IPs to both network devices, ping them or do ssh from the root cell to the non-root one. See jailhouse-images for a pre-integration of such a setup, e.g. that of qemu-arm64. I've just pushed a new version that builds here into the 'next' branch (still needs more work). Jan -- Siemens AG, Technology 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/c81bdfb1-055a-071f-8838-66b35173241b%40siemens.com.
Re: Question: ivshmem-net
On 03.01.23 01:57, Peng Fan wrote: >> To: Peng Fan ; jailhouse-dev@googlegroups.com >> Subject: Re: Question: ivshmem-net >> >> On 21.11.22 07:47, Peng Fan wrote: >>> Hi, >>> >>> I have a question regarding ivshmem-net, not sure whether we need to >> use local_bh_disable/enable to guard napi_schedule. >>> >>> See below patch: >>> >> https://patc >>> hes.linaro.org%2Fproject%2Flinux- >> usb%2Fpatch%2F877dk162mo.ffs%40nanos. >>> >> tec.linutronix.de%2F=05%7C01%7Cpeng.fan%40nxp.com%7C10674af >> e061c4 >>> >> fbdd5cd08daec94e54a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0 >> %7C63808 >>> >> 2421486787248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL >> CJQIjoiV2lu >>> >> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=nxYB >> 9%2BjoTRb >>> hTF7GGaa32nmr7hU7zCk2fEOL5ZbbL34%3D=0 >>> " >>> The driver invokes napi_schedule() in several places from task >>> context. napi_schedule() raises the NET_RX softirq bit and relies on >>> the calling context to ensure that the softirq is handled. That's >>> usually on return from interrupt or on the outermost local_bh_enable(). >>> >>> But that's not the case here which causes the soft interrupt handling >>> to be delayed to the next interrupt or local_bh_enable(). If the task >>> in which context this is invoked is the last runnable task on a CPU >>> and the CPU goes idle before an interrupt arrives or a >>> local_bh_disable/enable() pair handles the pending soft interrupt then >>> the NOHZ idle code emits the following warning. >>> >>> NOHZ tick-stop error: Non-RCU local softirq work is pending, handler >> #08!!! >>> >>> Prevent this by wrapping the napi_schedule() invocation from task >>> context into a local_bh_disable/enable() pair. >>> " >>> >> https://lore >>> .kernel.org%2Fall%2F87y28b9nyn.ffs%40tglx%2Ft%2F=05%7C01%7C >> peng.f >>> >> an%40nxp.com%7C10674afe061c4fbdd5cd08daec94e54a%7C686ea1d3bc2b >> 4c6fa92c >>> >> d99c5c301635%7C0%7C0%7C638082421486787248%7CUnknown%7CTWFp >> bGZsb3d8eyJW >>> >> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 >> C3000% >>> >> 7C%7C%7C=g%2FR48KwZCOVGt6momplzAv5VwmWpykE6c0e29pCpv >> 9k%3D >>> ed=0 >>> >>> I draft one: >>> diff --git a/drivers/net/ivshmem-net.c b/drivers/net/ivshmem-net.c >>> index 3bcd39b91176e..81e19d80bd0a7 100644 >>> --- a/drivers/net/ivshmem-net.c >>> +++ b/drivers/net/ivshmem-net.c >>> @@ -558,7 +558,9 @@ static void ivshm_net_run(struct net_device *ndev) >>> >>> netif_start_queue(ndev); >>> napi_enable(>napi); >>> + local_bh_disable(); >>> napi_schedule(>napi); >>> + local_bh_enable(); >>> ivshm_net_set_state(in, IVSHM_NET_STATE_RUN); } >>> >>> There are other places calling napi_schedule, but seems no need >> local_bh_disable/enable to protect. >>> >>> Not sure the upper change is valid or not, please help check. >>> >> >> Looks suspicious, indeed. I wonder why there are not runtime checks in >> napi_schedule to detect its needs and report a wrong bh state. >> >> Does this issue only trigger with NOHZ enabled? > [Peng Fan] > > I not tested other configurations, but I think so from various > lkml thread reading. > Ok, makes sense. And Peter even wrote a detection patch as it seems. Would you write a proper patch from your change, maybe also explaining why the other spots do not need this? Then I could merge it into queues/jailhouse where we track the driver history (it's usually folded in stable jailhouse-enabling branches). Thanks, Jan -- Siemens AG, Technology 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/5786bf3d-f0f2-48d3-609e-a9fdc68de40f%40siemens.com.
[PATCH] x86: vmx: Avoid double-accounting of MSR read exits
From: Jan Kiszka
vcpu_handle_msr_read already takes care of accounting.
Fixes: 3e9c91302ee5 ("x86: Push MSR statistic down to the dispatching points")
Signed-off-by: Jan Kiszka
---
hypervisor/arch/x86/vmx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hypervisor/arch/x86/vmx.c b/hypervisor/arch/x86/vmx.c
index 5a69710d..f610e507 100644
--- a/hypervisor/arch/x86/vmx.c
+++ b/hypervisor/arch/x86/vmx.c
@@ -1173,7 +1173,6 @@ void vcpu_handle_exit(struct per_cpu *cpu_data)
return;
break;
case EXIT_REASON_MSR_READ:
- stats[JAILHOUSE_CPU_STAT_VMEXITS_MSR_OTHER]++;
if (vcpu_handle_msr_read())
return;
break;
--
2.35.3
--
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/778388b9-9ac4-e5b2-0077-78d78501d587%40siemens.com.
Re: Running IVSHMEM-DEMO on BananaPi
On 19.10.22 23:21, Lukas Saintz wrote: > Hi Jan, > I'm studying Jailhouse Hypervisor and its implementation on a BananPi > M1 Board. > Following your guide I've successfully compiled and executed both > Bananapi.cell and FreeRTOS-demo.cell. > Now I want to study IVSHEMEM and how the two cells can properly communicate. > The only think that I can find is a ivshemem-demo.c with pci device that > unfortunately when I do the commands "jailhouse cell load FreeRTOS > /jailhouse/inmates/demos/arm/ivshmem-dem.bin " and "jailhouse cell start > FreeRTOS" results in a fail of the FreeRTOS cell. > I can't find good documentations on how to use and implement a correct > communication for my configuration. > > Can you help me? The BananaPi is a very old board by now, and it is not pre-integrated by jailhouse-images. For starting off, I would recommend a board that we have in scope with https://github.com/siemens/jailhouse-images (which may still have some build issues for a few more days, stay tuned for updates). Jan -- Siemens AG, Technology 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/bfe33597-4b4d-196f-a86b-c4fe9cf0df08%40siemens.com.
Re: Question: ivshmem-net
On 21.11.22 07:47, Peng Fan wrote: > Hi, > > I have a question regarding ivshmem-net, not sure whether we need to use > local_bh_disable/enable to guard napi_schedule. > > See below patch: > https://patches.linaro.org/project/linux-usb/patch/877dk162mo@nanos.tec.linutronix.de/ > " > The driver invokes napi_schedule() in several places from task > context. napi_schedule() raises the NET_RX softirq bit and relies on the > calling context to ensure that the softirq is handled. That's usually on > return from interrupt or on the outermost local_bh_enable(). > > But that's not the case here which causes the soft interrupt handling to be > delayed to the next interrupt or local_bh_enable(). If the task in which > context this is invoked is the last runnable task on a CPU and the CPU goes > idle before an interrupt arrives or a local_bh_disable/enable() pair > handles the pending soft interrupt then the NOHZ idle code emits the > following warning. > > NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! > > Prevent this by wrapping the napi_schedule() invocation from task context > into a local_bh_disable/enable() pair. > " > https://lore.kernel.org/all/87y28b9nyn.ffs@tglx/t/ > > I draft one: > diff --git a/drivers/net/ivshmem-net.c b/drivers/net/ivshmem-net.c > index 3bcd39b91176e..81e19d80bd0a7 100644 > --- a/drivers/net/ivshmem-net.c > +++ b/drivers/net/ivshmem-net.c > @@ -558,7 +558,9 @@ static void ivshm_net_run(struct net_device *ndev) > > netif_start_queue(ndev); > napi_enable(>napi); > + local_bh_disable(); > napi_schedule(>napi); > + local_bh_enable(); > ivshm_net_set_state(in, IVSHM_NET_STATE_RUN); > } > > There are other places calling napi_schedule, but seems no need > local_bh_disable/enable to protect. > > Not sure the upper change is valid or not, please help check. > Looks suspicious, indeed. I wonder why there are not runtime checks in napi_schedule to detect its needs and report a wrong bh state. Does this issue only trigger with NOHZ enabled? Jan -- Siemens AG, Technology 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/b8ff927b-a86e-9c92-e834-a8cdd790a679%40siemens.com.
Re: Request to Fix JH images for QEMU
On 21.11.22 23:35, Marco Barletta wrote: > Dear all; > I tried to use the repo Jailhouse of demo images for building a QEMU > target (x86), as I did a few months ago. But something has broken. First > of all the SRC_URI in jailhouse.inc is a git:// URI, deprecated by > github (afaik). I replaced the URI with https and fixed it. > However the build fails with the following log erorr (with the flag last > version of jailhouse either enabled or not): > > ERROR: mc:qemu-amd64-jailhouse-demo:jailhouse-jailhouse-0.-next-r0 > do_prepare_build: Execution of > '/build/tmp/work/jailhouse-demo-amd64/jailhouse-jailhouse/0.-next-r0/temp/run.do_prepare_build.72' > failed with exit code 1: > cp: cannot create regular file > '/build/tmp/work/jailhouse-demo-amd64/jailhouse-jailhouse/0.-next-r0/git/configs/x86/': > No such file or directory > WARNING: exit code 1 from a shell command. > > ERROR: Logfile of failure stored in: > /build/tmp/work/jailhouse-demo-amd64/jailhouse-jailhouse/0.-next-r0/temp/log.do_prepare_build.72 > Log data follows: > | DEBUG: Executing shell function do_prepare_build > | cp: cannot create regular file > '/build/tmp/work/jailhouse-demo-amd64/jailhouse-jailhouse/0.-next-r0/git/configs/x86/': > No such file or directory > | WARNING: exit code 1 from a shell command. > | ERROR: Execution of > '/build/tmp/work/jailhouse-demo-amd64/jailhouse-jailhouse/0.-next-r0/temp/run.do_prepare_build.72' > failed with exit code 1: > | cp: cannot create regular file > '/build/tmp/work/jailhouse-demo-amd64/jailhouse-jailhouse/0.-next-r0/git/configs/x86/': > No such file or directory > | WARNING: exit code 1 from a shell command. > | > ERROR: Task > (mc:qemu-amd64-jailhouse-demo:/repo/recipes-jailhouse/jailhouse/jailhouse_latest.bb:do_prepare_build) > failed with exit code '1' > > I am running kas-container on a manjaro system, kernel v5.10.151, > x86-64 arch. The ARM64 image is broken as well. > > Do you have any clue on how to fix this? We have plenty of students > relying on the repo for projects at our course, it would be great having > a quickstart for JH. > I'm on it. Part of the solution (not for build errors, though) are the Jailhouse patches [1] I just sent. Jan [1] https://groups.google.com/g/jailhouse-dev/c/aKT7L2Hs6Ow/m/d8BzplwsCAAJ -- Siemens AG, Technology 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/6bd62bc6-479f-314b-9cdc-d85bfd80a2ba%40siemens.com.
Re: the use of 2nd stage MMU translation
On 24.11.22 20:19, Yelena Konyukh wrote: > Hi All, > > Answering my own question :) : > > I have run the demo from https://github.com/siemens/jailhouse-images for > Raspberry Pie and simply collected the output of "cat /proc/iomem" > before running Jailhouse, then after enabling Jailhouse in the root cell > and in a Linux non-root cell. From that output it looks like Jialhouse > does 1:1 mapping between IPAs and PAs. It does so in many cases, but the 2nd state MMU would permit a different mapping as well. However, we do not have broad SMMU (IOMMU) support on ARM SoCs so that we often have to keep a 1:1 mapping even for non-root cells to work around that. > > On a platform with Zynq UltraScale+ MPSoC, onto which Jailhouse has been > ported, I have experimented with memory accesses, trying to access from > the root cell the memory allocated to a non-root Linux cell and the > other way round - trying to access from the non-root Linux cell the > memory allocated to the root cell only. As expected, in both cases I > have got "Unhandled data write...FATAL: unhandled trap (exception class > 0x24)", while the cells can happily read from/write into physical > addresses belonging to their own memory regions specified in the > respective cells configuration. This appears to confirm the use of the > 2nd stage translations for restricting cells access to physical memory. Yes, primarily. For remapping physical addresses, see above. Jan -- Siemens AG, Technology 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/97c9d6b2-778d-5e20-fc2e-00537d9d5e07%40siemens.com.
Re: Question: IVSHMEM Inter-cell communication
On 11.12.22 17:06, 张家铭 wrote: > Hi, > > Recently, I have used inmate-demo(inmates/demos/ivshmem-demo.c) and > ivshmem-demo(tools/ivshmem-demo.c) on rpi4 to study how to communicate > between two cells. I have following problems: > > 1. I found this result, However, I'm not sure it is correct. The > inmate-demo's Privileged Control=0 and the ivshmem-demo in root-cell, > Privileged Control=1 ? > > 2. In ivshmem-demo. If I want to change the Privileged Control, What > should I do? What means, how to open/close one-shot interrupt mode? > The Privileged Control register is only used by the UIO driver under Linux. It saves one extra exit on interrupt arrival in the UIO kernel driver to mask the interrupt line until unprivileged userspace had a chance to react to the event. In the bare-metal demo, you don't need this feature because there is no privilege separation between a driver and an application. Jan -- Siemens AG, Technology 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/4d5e6745-e79a-67fe-bcc9-6e0e3a0d11ba%40siemens.com.
Re: Jailhouse on TI AM5728 and 5.10 kernel
On 13.12.22 14:40, Ralf Ramsauer wrote: > Hi Jussi, > > On 13/12/2022 14:05, Jussi Pajala wrote: >> Hi, >> >> I'm currently running old jailhouse 0.8 on 4.9 kernel - provided by >> TI's SDK. >> >> Now, I need to upgrade to 5.10 kernel but TI has removed Jailhouse >> support from the newest SDK which contains the 5.10 kernel. >> >> The old Jailhouse doesn't compile under the new kernel. Also I saw >> some posts that the kernel requires some patches for the Jailhouse to >> work. >> >> So, what is actually needed? What are the steps to configure the 0.8 >> Jailhouse to compile under 5.10 kernel? > > I recommend to take the latest git version of Jailhouse. For the kernel, > you can use the patches on top of: > > https://github.com/siemens/linux/tree/jailhouse-enabling/5.10 > Problem with the AM5xx was that it never received official Jailhouse support. By now, that platform is likely out of scope for TI, not getting feature upstreaming anymore. I vaguely recall the details of that platform from my initial enabling, and I think it was specifically its missing PSCI support for CPU bring-up. That was even more complex than vexpress, a platform we dropped 4 years ago. So, updating Jailhouse may be tricky if Jailhouse should no longer support the required abstractions for this legacy SoC. Jan -- Siemens AG, Technology 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/25321d20-a68b-89af-af05-31ef40579ebf%40siemens.com.
Re: STM32MP1 hangs on when entering hypervisor
On 13.12.22 20:33, Tommi Parkkila wrote: > Hi all - I am trying to configure and deploy Jailhouse on STM32MP1 w/ > dual Cortex-A7. I get Jailhouse built and installed on target, and > kernel module installed successfully, but when enabling Jailhouse the > whole system hangs and restarts after several seconds by WDT. I have > hunted the last executed line of code to: > > /err = entry(cpu);/ > > on /jailhouse/driver/main.c::enter_hypervisor(). The process tries the > both CPUs and both hangs. Here are some debug prints I added about the > jailhouse header data before the entry call, if they help any: (/number > inside [ ] is cpu-id/) > > /[ 280.734679] - [1] header.core_size = 0x16000 > [ 280.734687] - [1] header.percpu_size = 0x4000 > [ 280.738521] - [0] header.core_size = 0x16000 > [ 280.742961] - [1] header.entry = 0x3720 > [ 280.747400] - [0] header.percpu_size = 0x4000 > [ 280.751840] - [1] entry = 0xF0003720 > [ 280.755775] - [0] header.entry = 0x3720 > [ 280.760215] - [1] header.console_page = 0x1 > [ 280.764049] - [0] entry = 0xF0003720 > [ 280.767986] - [1] header.gcov_info_head = 0x0 > [ 280.772627] - [0] header.console_page = 0x1 > [ 280.776462] - [1] header.max_cpus = 2 > [ 280.780902] - [0] header.gcov_info_head = 0x0 > [ 280.785443] - [1] header.online_cpus = 2 > [ 280.789278] - [0] header.max_cpus = 2 > [ 280.793718] - [1] header.debug_console_base = 0xDF96D000 > [ 280.797653] - [0] header.online_cpus = 2 > [ 280.801488] - [1] header.arm_linux_hyp_vectors = 0xC0114BE0 > [ 280.806935] - [0] header.debug_console_base = 0xDF96D000 > [ 280.810871] - [1] header.arm_linux_hyp_abi = 1 > [ 280.816419] - [0] header.arm_linux_hyp_vectors = 0xC0114BE0 > [ 280.826307] - [0] header.arm_linux_hyp_abi = 1/ > > Where and how should I start looking for the issue? All and any help > will be highly appreciated. Below, a snapshot of memory region > allocation in kernel device tree and a snapshot of jailhouse root-cell > configuration that I use as an argument when enabling jailhouse. Did you enable the debug UART properly already? That will give you fairly early output from Jailhouse and possibly hints on where it fails - or at least where it still passes by. If the hang is actually much earlier, you could instrument the entry code, make entry() return early with a special error to see if this path is taken at least. Jan -- Siemens AG, Technology 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/3071214a-b5a8-4096-8ad4-3a79b6634de5%40siemens.com.
[PATCH 1/4] pyjailhouse: sysfs_parser: Fix IOMMU assignment for PCI bridges
From: Jan Kiszka Not only the subdevices need to be assigned to the given IOMMU, also the bridge itself. Otherwise, the config generator will bail out with something like RuntimeError: PCI device 00:03.0 outside the scope of an IOMMU Signed-off-by: Jan Kiszka --- pyjailhouse/sysfs_parser.py | 1 + 1 file changed, 1 insertion(+) diff --git a/pyjailhouse/sysfs_parser.py b/pyjailhouse/sysfs_parser.py index 7f19fb57..35c59744 100644 --- a/pyjailhouse/sysfs_parser.py +++ b/pyjailhouse/sysfs_parser.py @@ -395,6 +395,7 @@ def parse_dmar(pcidevices, ioapics, dmar_regions): assert not (flags & 1) for d in pcidevices: if d.bus == bus and d.dev == dev and d.fn == fn: +d.iommu = len(units) - 1 (secondbus, subordinate) = \ PCIPCIBridge.get_2nd_busses(d) for d2 in pcidevices: -- 2.35.3 -- 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/eba9280f25c370828f51764a3c06461af99410cb.1672643463.git.jan.kiszka%40siemens.com.
[PATCH 4/4] README: Add pcie-pci-bridge to qemu command line
From: Jan Kiszka Needed now as we had to move ivshmem devices behind this hotplug-capable bridge. Signed-off-by: Jan Kiszka --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index b5937300..dc2c3afa 100644 --- a/README.md +++ b/README.md @@ -269,7 +269,7 @@ enable nested VMX support. Start the virtual machine as follows: -drive file=LinuxInstallation.img,format=raw|qcow2|...,id=disk,if=none \ -device ide-hd,drive=disk -serial stdio -serial vc \ -netdev user,id=net -device e1000e,addr=2.0,netdev=net \ --device intel-hda,addr=1b.0 -device hda-duplex +-device intel-hda,addr=1b.0 -device hda-duplex -device pcie-pci-bridge For AMD CPUs: Make sure the kvm-amd module was loaded with nested=1 to enable nested SVM support. Start the virtual machine as follows: @@ -279,7 +279,7 @@ nested SVM support. Start the virtual machine as follows: -drive file=LinuxInstallation.img,format=raw|qcow2|...,id=disk,if=none \ -device ide-hd,drive=disk -serial stdio -serial vc \ -netdev user,id=net -device e1000e,addr=2.0,netdev=net \ --device intel-hda,addr=1b.0 -device hda-duplex +-device intel-hda,addr=1b.0 -device hda-duplex -device pcie-pci-bridge Inside the VM, make sure that `jailhouse-*.bin`, generated by the build process, are available for firmware loading (typically /lib/firmware), see above for -- 2.35.3 -- 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/cfdcbcd245e06cd9006e2fa676501c3838af3919.1672643463.git.jan.kiszka%40siemens.com.
[PATCH 3/4] configs: x86: qemu: Move ivshmem devices behind hotplug-capable bridge
From: Jan Kiszka
Recent QEMU disabled hotplugging support for the root bus. Linux will
still find the ivshmem devices we inject there so far, but it will fail
to allocate IRQs for it because the related irq domain was frozen in
size, given that hotplug is not possible.
Work around this issue by moving the virtual devices behind a PCIe-PCI
bridge that is hotplug-capable. Adding that bridge shuffles some memory
regions around, so adjust the configs accordingly.
Signed-off-by: Jan Kiszka
---
configs/x86/ivshmem-demo.c | 2 +-
configs/x86/linux-x86-demo.c | 34 +-
configs/x86/qemu-x86.c | 118 +--
3 files changed, 102 insertions(+), 52 deletions(-)
diff --git a/configs/x86/ivshmem-demo.c b/configs/x86/ivshmem-demo.c
index ce05b6b5..4c24193f 100644
--- a/configs/x86/ivshmem-demo.c
+++ b/configs/x86/ivshmem-demo.c
@@ -107,7 +107,7 @@ struct {
{
.type = JAILHOUSE_PCI_TYPE_IVSHMEM,
.domain = 0x,
- .bdf = 0x0e << 3,
+ .bdf = 0x100 | (0x0e << 3),
.bar_mask = JAILHOUSE_IVSHMEM_BAR_MASK_MSIX,
.num_msix_vectors = 16,
.shmem_regions_start = 0,
diff --git a/configs/x86/linux-x86-demo.c b/configs/x86/linux-x86-demo.c
index 47cb6517..0703c5b9 100644
--- a/configs/x86/linux-x86-demo.c
+++ b/configs/x86/linux-x86-demo.c
@@ -144,31 +144,31 @@ struct {
JAILHOUSE_MEM_LOADABLE,
},
#ifdef CONFIG_QEMU_E1000E_ASSIGNMENT
- /* MemRegion: feb4-feb7 : :00:02.0 */
+ /* MemRegion: fea0-fea3 : :00:02.0 */
{
- .phys_start = 0xfeb4,
- .virt_start = 0xfeb4,
+ .phys_start = 0xfea0,
+ .virt_start = 0xfea0,
.size = 0x4,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
},
- /* MemRegion: feb8-feb9 : e1000e */
+ /* MemRegion: fea4-fea5 : e1000e */
{
- .phys_start = 0xfeb8,
- .virt_start = 0xfeb8,
+ .phys_start = 0xfea4,
+ .virt_start = 0xfea4,
.size = 0x2,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
},
- /* MemRegion: feba-febb : e1000e */
+ /* MemRegion: fea6-fea7 : e1000e */
{
- .phys_start = 0xfeba,
- .virt_start = 0xfeba,
+ .phys_start = 0xfea6,
+ .virt_start = 0xfea6,
.size = 0x2,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
},
- /* MemRegion: febd1000-febd3fff : e1000e */
+ /* MemRegion: fea91000-fea93fff : e1000e */
{
- .phys_start = 0xfebd1000,
- .virt_start = 0xfebd1000,
+ .phys_start = 0xfea91000,
+ .virt_start = 0xfea91000,
.size = 0x3000,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
},
@@ -203,7 +203,7 @@ struct {
{
.type = JAILHOUSE_PCI_TYPE_IVSHMEM,
.domain = 0x0,
- .bdf = 0x0c << 3,
+ .bdf = 0x100 | (0x0c << 3),
.bar_mask = JAILHOUSE_IVSHMEM_BAR_MASK_MSIX,
.num_msix_vectors = 2,
.shmem_regions_start = 0,
@@ -215,7 +215,7 @@ struct {
{
.type = JAILHOUSE_PCI_TYPE_IVSHMEM,
.domain = 0x0,
- .bdf = 0x0d << 3,
+ .bdf = 0x100 | (0x0d << 3),
.bar_mask = JAILHOUSE_IVSHMEM_BAR_MASK_MSIX,
.num_msix_vectors = 3,
.shmem_regions_start = 4,
@@ -227,7 +227,7 @@ struct {
{
.type = JAILHOUSE_PCI_TYPE_IVSHMEM,
.domain = 0x0,
- .bdf = 0x0e << 3,
+ .bdf = 0x100 | (0x0e << 3),
.bar_mask = JAILHOUSE_IVSHMEM_BAR_MASK_MSIX,
.num_msix_vectors = 16,
.shmem_regions_start = 8,
@@ -238,7 +238,7 @@ struct {
{
.type = JAILHOUSE_PCI_TYPE_IVSHMEM,
.domain = 0x0,
- .bdf = 0x0f <<
[PATCH 2/4] x86: vtd: Drop source-id validation while parsing root cell IRTE
From: Jan Kiszka This was not complete, rather assumed SVT to be 01b and completely ignored SQ. The SID test failed when the root cell chose SVT to be 10b to describe a source behind a PCIe-PCI bridge, thus switching SID to startbus/endbus encoding (now needed for QEMU). Let's make it simple and assume that the root cell programmed a valid source. Skipping the test will have no negative impact on isolation between cells. Signed-off-by: Jan Kiszka --- hypervisor/arch/x86/vtd.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/hypervisor/arch/x86/vtd.c b/hypervisor/arch/x86/vtd.c index acc97919..ccd0bdde 100644 --- a/hypervisor/arch/x86/vtd.c +++ b/hypervisor/arch/x86/vtd.c @@ -805,8 +805,7 @@ iommu_get_remapped_root_int(unsigned int iommu, u16 device_id, root_irte = *(union vtd_irte *)(irte_page + (irte_addr & PAGE_OFFS_MASK)); - irq_msg.valid = - (root_irte.field.p && root_irte.field.sid == device_id); + irq_msg.valid = root_irte.field.p; irq_msg.vector = root_irte.field.vector; irq_msg.delivery_mode = root_irte.field.delivery_mode; irq_msg.dest_logical = root_irte.field.dest_logical; -- 2.35.3 -- 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/f70e366bb77de3ceb59464a943cc5430e69ed7f4.1672643463.git.jan.kiszka%40siemens.com.
[PATCH 0/4] Re-enable ivshmem support in latest x86 QEMU
Happy New Year, everyone! Long time no activity from my side, but now I finally found a few days to do some long overdue renovation work. One outcome is this patch series which allows to use ivshmem devices with latest QEMU again, see patch 3 for the background. Will now look into refreshing the demo images and the kernel patches over the next days. Jan Jan Kiszka (4): pyjailhouse: sysfs_parser: Fix IOMMU assignment for PCI bridges x86: vtd: Drop source-id validation while parsing root cell IRTE configs: x86: qemu: Move ivshmem devices behind hotplug-capable bridge README: Add pcie-pci-bridge to qemu command line README.md| 4 +- configs/x86/ivshmem-demo.c | 2 +- configs/x86/linux-x86-demo.c | 34 +- configs/x86/qemu-x86.c | 118 +-- hypervisor/arch/x86/vtd.c| 3 +- pyjailhouse/sysfs_parser.py | 1 + 6 files changed, 106 insertions(+), 56 deletions(-) -- 2.35.3 -- 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/cover.1672643463.git.jan.kiszka%40siemens.com.
Re: [PATCH RESEND 0/3] Add support for Renesas RZ/G2M
Hi Prabhakar, On 29.11.22 15:29, Lad, Prabhakar wrote: > Hi Jan, > > On Sun, Nov 6, 2022 at 11:05 PM Lad Prabhakar > wrote: >> >> Hi All, >> >> This patch series adds support for Renesas RZ/G2M SoC [0] (root cell >> config) and adds demo cell config for HopeRun HiHope RZ/G2M platform [1]. >> >> Changes apply on top of next branch [2] and the kernel used for testing is >> 5.10 (-cip) based on BSP-3.0.0 [3] release from Renesas. >> >> No changes from previous version sent to ML, just rebased on the next branch. >> >> [0] >> https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg2m-ultra-high-performance-microprocessors-arm-cortex-a57-and-arm-cortex-a53-cpus-3d-graphics-and-4k >> [1] >> https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg2m-hihope-rzg2m-reference-board#overview >> [2] https://github.com/siemens/jailhouse/tree/next (9391d30a) >> [3] https://github.com/renesas-rz/meta-renesas/tree/BSP-3.0.0 >> >> Cheers, >> Prabhakar >> >> Lad Prabhakar (3): >> renesas: Add SCIF support >> configs: arm64: Add root cell config for Renesas RZ/G2M SoC >> configs: arm64: Add demo cell config for Renesas RZ/G2M >> >> Documentation/debug-output.md |1 + >> configs/arm64/dts/inmate-r8a774a1-hihope.dts | 228 >> configs/arm64/renesas-r8a774a1-linux-demo.c | 114 ++ >> configs/arm64/renesas-r8a774a1.c | 1134 + >> hypervisor/arch/arm-common/Kbuild |2 +- >> hypervisor/arch/arm-common/dbg-write.c|2 + >> hypervisor/arch/arm-common/include/asm/uart.h |2 +- >> hypervisor/arch/arm-common/uart-scif.c| 44 + >> include/jailhouse/console.h |1 + >> inmates/lib/arm-common/Makefile.lib |2 +- >> inmates/lib/arm-common/uart-scif.c| 65 + >> inmates/lib/arm-common/uart.c |2 + >> 12 files changed, 1594 insertions(+), 3 deletions(-) >> create mode 100644 configs/arm64/dts/inmate-r8a774a1-hihope.dts >> create mode 100644 configs/arm64/renesas-r8a774a1-linux-demo.c >> create mode 100644 configs/arm64/renesas-r8a774a1.c >> create mode 100644 hypervisor/arch/arm-common/uart-scif.c >> create mode 100644 inmates/lib/arm-common/uart-scif.c >> > Gentle ping. > Sorry for letting you wait /that/ long: Patches look good except that they are missing ivshmem support and an inmate-demo cell. You should have a demo and a networking ivshmem device in the root and the linux cell, the inmate demo needs just the demo device. Check out other boards for the required pattern, e.g. the rpi4. I'm merging patch 1 already as this is independent. Jan -- Siemens AG, Technology 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/a9e1e756-978a-f2de-c4cd-838f1417a8fc%40siemens.com.
Re: [PATCH 1/2] x86: Check return values from early_memremap calls
On 08.10.22 17:12, Borislav Petkov wrote:
> Adding Xen and Jailhouse people and MLs to Cc.
>
> Folks, thread starts here:
>
> https://lore.kernel.org/r/1650035401-22855-1-git-send-email-ross.philip...@oracle.com
>
> On Fri, Apr 15, 2022 at 11:10:00AM -0400, Ross Philipson wrote:
>> There are a number of places where early_memremap is called
>> but the return pointer is not checked for NULL. The call
>> can result in a NULL being returned so the checks must
>> be added.
>>
>> Signed-off-by: Ross Philipson
>> ---
>> arch/x86/kernel/devicetree.c | 10 ++
>> arch/x86/kernel/e820.c | 5 +
>> arch/x86/kernel/jailhouse.c | 6 ++
>> arch/x86/kernel/mpparse.c| 23 +++
>> arch/x86/kernel/setup.c | 5 +
>> arch/x86/xen/enlighten_hvm.c | 2 ++
>> arch/x86/xen/mmu_pv.c| 8
>> arch/x86/xen/setup.c | 2 ++
>> 8 files changed, 61 insertions(+)
>
> Ok, a couple of notes:
>
> 1. the pr_*(":" ... )
>
> thing is done using pr_fmt() - grep the tree for examples.
>
> 2. I think you should not panic() the machine but issue a the
> warning/error and let the machine die a painful death anyway. But Xen
> folks will know better what would be the optimal thing to do.
>
> Thx.
>
For the Jailhouse bits:
Reviewed-by: Jan Kiszka
(IOW, panic'ing is fine for us here)
Thanks,
Jan
--
Siemens AG, Technology
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/c4c35f8a-47ba-5e24-18e7-5190330c7e2c%40siemens.com.
Re: [PATCH] hypervisor: Add -ffreestanding to CFLAGs
On 09.08.22 14:49, Ralf Ramsauer wrote: > At the moment, Jailhouse is - by default - compiled with -Os. > Nevertheless, at least we should also support other optimisation levels, > such as -O2, without breaking anything. > > Turns out, if we compile Jailhouse with -O2, GCC creates endless loops > inside memset. What it does - at least on my RISC-V port for example - > is to emit the following code for memset: > >ffdfff00a6be : >ffdfff00a6be: 1141addisp,sp,-16 >ffdfff00a6c0: e022sd s0,0(sp) >ffdfff00a6c2: e406sd ra,8(sp) >ffdfff00a6c4: 842amv s0,a0 >ffdfff00a6c6: c609beqz a2,ffdfff00a6d0 > >ffdfff00a6c8: 0ff5f593zext.b a1,a1 > -> ffdfff00a6cc: ff3ff0efjal ra,ffdfff00a6be > >ffdfff00a6d0: 60a2ld ra,8(sp) >ffdfff00a6d2: 8522mv a0,s0 >ffdfff00a6d4: 6402ld s0,0(sp) >ffdfff00a6d6: 0141addisp,sp,16 >ffdfff00a6d8: 8082ret > > In the marked line, we end up in an endless loop. The reason is that gcc > recognises that we're about to implement a memset, and tries to take the > shortcut by replacing our implementation by calling - guess what - > memset. And here we are: endless loop. > > I don't know, but this could maybe also happen with -Os if they change > optimisation strategies. > > To avoid issues like this in future, better add -ffreestanding to our > compiler options. I wonder why we were missing that option in anyway. > > Signed-off-by: Ralf Ramsauer > --- > hypervisor/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hypervisor/Makefile b/hypervisor/Makefile > index c475b8fd..b35809f5 100644 > --- a/hypervisor/Makefile > +++ b/hypervisor/Makefile > @@ -32,7 +32,7 @@ KBUILD_CFLAGS := -g -ggdb -gdwarf-3 -O0 -Wall -Wextra > -Wno-unused-parameter \ >-Wnested-externs -Wshadow -Wredundant-decls \ >-Wundef -Wdeprecated \ >-fno-strict-aliasing -fno-pic -fno-common \ > - -fno-stack-protector -fno-builtin-ffsl \ > + -fno-stack-protector -fno-builtin-ffsl -ffreestanding \ >-D__LINUX_COMPILER_TYPES_H > > include $(src)/arch/$(SRCARCH)/Makefile Thanks, applied. 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/7cd2922f-5553-4dfa-3a79-edaa6c642bdb%40web.de.
Re: [PATCH] configs: arm64: qemu: move virtual PCI controller
On 28.08.22 20:11, Jan Kiszka wrote: > On 23.06.22 23:20, Ralf Ramsauer wrote: >> With recent QEMU versions, the GICR grew: >> >> $ cat /proc/iomem >> 0800-0800 : GICD >> 080a-08ff : GICR >> [...] >> >> Hence, we can't place the virtual PCI controller at 0x08e0 any >> longer. It will collide with the GICR. Move the pci controller to an >> empty spot: 0x8100 provides enough space for the controller. >> >> 0x8000 can't be used, as it is reserved for the commregion. >> >> Note that pci_mmconfig_base must be within a 32-bit range at the >> moment and can't be placed at a higher address. >> > > This is just papering over the underlying issue: QEMU now emulates ITS, > and that resource moves more things around. But Jailhouse does not > support ITS yet, so we better disable it in QEMU (machine attribute > "its=off"). But we will also need to tell the user which minimal QEMU > version this implies. > In fact, you already contributed that. It's just missing in jailhouse-images. 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/b8f4fb91-a747-0c86-1737-75cc44059879%40web.de.
Re: [PATCH] configs: arm64: qemu: move virtual PCI controller
On 23.06.22 23:20, Ralf Ramsauer wrote: > With recent QEMU versions, the GICR grew: > > $ cat /proc/iomem > 0800-0800 : GICD > 080a-08ff : GICR > [...] > > Hence, we can't place the virtual PCI controller at 0x08e0 any > longer. It will collide with the GICR. Move the pci controller to an > empty spot: 0x8100 provides enough space for the controller. > > 0x8000 can't be used, as it is reserved for the commregion. > > Note that pci_mmconfig_base must be within a 32-bit range at the > moment and can't be placed at a higher address. > This is just papering over the underlying issue: QEMU now emulates ITS, and that resource moves more things around. But Jailhouse does not support ITS yet, so we better disable it in QEMU (machine attribute "its=off"). But we will also need to tell the user which minimal QEMU version this implies. BTW, this patch would leave the Linux inmate broken (missing dts update). 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/d6e6b2bc-706b-22d1-c36f-15caff0aff3a%40web.de.
Re: [RFC v1 03/42] core: riscv: define MMIO accessors
On 27.06.22 15:28, Ralf Ramsauer wrote: > GCC may emit 4x 1 Byte reads in case of our regular mmio_read32 > accessor, when used in combination with -Os. Yes, I've seen it. > > Define safe handlers to overcome this issue. > The kernel does something similar, right? Worth to point that out then. Jan -- Siemens AG, Technology 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/bc6248e0-accf-37e6-6318-805220a390cf%40siemens.com.
Re: [RFC v1 34/42] configs: riscv: qemu: add system configs
On 27.06.22 15:28, Ralf Ramsauer wrote: > Signed-off-by: Ralf Ramsauer > --- > configs/riscv/qemu-riscv64.c | 218 +-- > include/jailhouse/console.h | 1 + > 2 files changed, 211 insertions(+), 8 deletions(-) > ... > diff --git a/include/jailhouse/console.h b/include/jailhouse/console.h > index 34dd7209..0b6c558b 100644 > --- a/include/jailhouse/console.h > +++ b/include/jailhouse/console.h > @@ -50,6 +50,7 @@ > #define JAILHOUSE_CON_TYPE_SCIFA 0x0007 > #define JAILHOUSE_CON_TYPE_IMX 0x0008 > #define JAILHOUSE_CON_TYPE_IMX_LPUART0x0009 > +#define JAILHOUSE_CON_TYPE_RISCV_SBI 0x000a > > /* Flags: bit 0 is used to select PIO (cleared) or MMIO (set) access */ > #define JAILHOUSE_CON_ACCESS_PIO 0x This is likely needed earlier in order to allow building things. Jan -- Siemens AG, Technology 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/d85ed09a-9979-c40c-9b15-ba68187ab22f%40siemens.com.
Re: [RFC v1 40/42] core: riscv: plic: introduce vIRQ support
On 27.06.22 15:29, Ralf Ramsauer wrote:
> diff --git a/hypervisor/arch/riscv/include/asm/percpu.h
> b/hypervisor/arch/riscv/include/asm/percpu.h
> index 4eda15b6..bcafff51 100644
> --- a/hypervisor/arch/riscv/include/asm/percpu.h
> +++ b/hypervisor/arch/riscv/include/asm/percpu.h
> @@ -43,6 +43,8 @@ enum sbi_hart_state {
> } hsm; \
> bool wait_for_power_on; \
> bool reset; \
> - bool park;
> + bool park; \
> +u32 virq_enabled_bitmap[PLIC_MAX_IRQS / (sizeof(u32) * 8)]; \
> +u32 virq_pending_bitmap[PLIC_MAX_IRQS / (sizeof(u32) * 8)];
Style issue :)
Jan
--
Siemens AG, Technology
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/fd9596de-2977-1c8c-df64-90382ad10eb6%40siemens.com.
Re: Error with Jailhouse Demo Images
On 20.06.22 09:33, Marco Barletta wrote:
> Dear all;
>
> I was trying to build JH for QEMU with the kas container in jailhouse
> demo images. Suddenly the building failes due to this error:
>
> git -c core.fsyncobjectfiles=0 ls-remote
> git://github.com/siemens/jailhouse failed with exit code 128, output:
> 2022/06/20 07:26:47 socat[251] E connect(5, AF=2 140.82.121.3:9418, 16):
> Connection timed out
> fatal: Could not read from remote repository.
>
> (Yes I have internet connection, of course, and the IP correctly
> responds to ping).
>
> Any advice? Has something changed with the git protocol?
>
You need
diff --git a/recipes-jailhouse/jailhouse/jailhouse.inc
b/recipes-jailhouse/jailhouse/jailhouse.inc
index 66d7ee3..f4325ae 100644
--- a/recipes-jailhouse/jailhouse/jailhouse.inc
+++ b/recipes-jailhouse/jailhouse/jailhouse.inc
@@ -25,7 +25,7 @@ EXTRA_JAILHOUSE_CONFIGS_amd64 = " \
"
SRC_URI = " \
-git://github.com/siemens/jailhouse;branch=next \
+git://github.com/siemens/jailhouse;branch=next;protocol=https \
file://debian/ \
${@ " ".join(["file://" + cfg for cfg in
d.getVar('EXTRA_JAILHOUSE_CONFIGS').split()]) } \
"
I'll push a patch "soon".
Jan
--
Siemens AG, Technology
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/6e8fc5f5-40fa-293f-a6e8-21913b4b1ad6%40siemens.com.
Re: [PATCH v2] arm64: check whether HPFAR is valid before getting IPA
On 09.06.22 17:27, Dongjiu Geng wrote:
> ping，sorry for the noise
>
No need to be sorry, I unfortunately didn't find the time to fully
understand this.
>
> Dongjiu Geng 于2022年6月3日周五 21:11写道：
>>
>> The HPFAR can be invalid if the stage 2 fault did not happen during a
>> stage 1 page table walk (the ESR_EL2.S1PTW bit is clear) and one of the
>> two following cases are true:
>> 1). The fault was due to a permission fault
>> 2). The processor carries errata 834220
>>
>> Therefore, for all non S1PTW faults where we either have a permission
>> fault or the errata workaround is enabled, we resolve the IPA using the
>> AT instruction.
>>
>> Signed-off-by: Dongjiu Geng
>> ---
>> hypervisor/arch/arm64/include/asm/paging.h | 8 ++
>> hypervisor/arch/arm64/include/asm/sysregs.h | 8 ++
>> hypervisor/arch/arm64/include/asm/traps.h | 2 +
>> hypervisor/arch/arm64/mmio.c| 7 +-
>> hypervisor/arch/arm64/traps.c | 89 +++--
>> 5 files changed, 105 insertions(+), 9 deletions(-)
>>
>> diff --git a/hypervisor/arch/arm64/include/asm/paging.h
>> b/hypervisor/arch/arm64/include/asm/paging.h
>> index e600cf58..4f0cb81c 100644
>> --- a/hypervisor/arch/arm64/include/asm/paging.h
>> +++ b/hypervisor/arch/arm64/include/asm/paging.h
>> @@ -198,6 +198,14 @@ unsigned int get_cpu_parange(void);
>> | (cpu_parange_encoded << TCR_PS_SHIFT) \
>> | VTCR_RES1)
>>
>> +/* Flags for get fault ipa from gva */
>> +#define GV2M_READ (0u<<0)
>> +#define GV2M_WRITE (1u<<0)
>> +
>> +/* Indicates address translation aborted */
>> +#define PAR_F (1UL)
>> +#define PADDR_MASK ((1UL << 48) - 1UL)
>> +
>> int arm_paging_cell_init(struct cell *cell);
>> void arm_paging_cell_destroy(struct cell *cell);
>>
>> diff --git a/hypervisor/arch/arm64/include/asm/sysregs.h
>> b/hypervisor/arch/arm64/include/asm/sysregs.h
>> index 868ef887..2c683832 100644
>> --- a/hypervisor/arch/arm64/include/asm/sysregs.h
>> +++ b/hypervisor/arch/arm64/include/asm/sysregs.h
>> @@ -117,6 +117,14 @@
>> #define ESR_IL(esr)GET_FIELD((esr), 25, 25)
>> /* Instruction specific syndrome */
>> #define ESR_ISS(esr) GET_FIELD((esr), 24, 0)
>> +
>> +/* Fault status code of instruction specific syndrome */
>> +#define ESR_ISS_FSC(esr) GET_FIELD((esr), 5, 0)
>> +
>> +/* Shared ISS fault status code(IFSC/DFSC) for Data/Instruction aborts */
>> +#define ESR_ISS_FSC_TYPE (0x3C)
>> +#define ESR_ISS_FSC_PERM (0x0C)
>> +
>> /* Exception classes values */
>> #define ESR_EC_UNKNOWN 0x00
>> #define ESR_EC_WFx 0x01
>> diff --git a/hypervisor/arch/arm64/include/asm/traps.h
>> b/hypervisor/arch/arm64/include/asm/traps.h
>> index a7c07624..0efedef1 100644
>> --- a/hypervisor/arch/arm64/include/asm/traps.h
>> +++ b/hypervisor/arch/arm64/include/asm/traps.h
>> @@ -25,6 +25,8 @@ struct trap_context {
>>
>> void arch_handle_trap(union registers *guest_regs);
>> void arch_el2_abt(union registers *regs);
>> +bool arch_get_fault_ipa(struct trap_context *ctx, unsigned long *ipa,
>> +unsigned int flag);
>>
>> /* now include from arm-common */
>> #include_next
>> diff --git a/hypervisor/arch/arm64/mmio.c b/hypervisor/arch/arm64/mmio.c
>> index 7fbfef75..70301ab3 100644
>> --- a/hypervisor/arch/arm64/mmio.c
>> +++ b/hypervisor/arch/arm64/mmio.c
>> @@ -43,7 +43,6 @@ enum trap_return arch_handle_dabt(struct trap_context *ctx)
>> {
>> enum mmio_result mmio_result;
>> struct mmio_access mmio;
>> - unsigned long hpfar;
>> unsigned long hdfar;
>> /* Decode the syndrome fields */
>> u32 iss = ESR_ISS(ctx->esr);
>> @@ -57,10 +56,10 @@ enum trap_return arch_handle_dabt(struct trap_context
>> *ctx)
>> u32 is_write= iss >> 6 & 0x1;
>> u32 size= 1 << sas;
>>
>> - arm_read_sysreg(HPFAR_EL2, hpfar);
>> arm_read_sysreg(FAR_EL2, hdfar);
>> - mmio.address = hpfar << 8;
>> - mmio.address |= hdfar & 0xfff;
>> +
>> + if (!arch_get_fault_ipa(ctx, , GV2M_READ))
>> + return TRAP_HANDLED; /* Try again */
So, this means we need to make the guest trap again, and then HPFAR is
valid??
>>
>> this_cpu_public()->stats[JAILHOUSE_CPU_STAT_VMEXITS_MMIO]++;
>>
>> diff --git a/hypervisor/arch/arm64/traps.c b/hypervisor/arch/arm64/traps.c
>> index 488dd7f8..10441b4b 100644
>> --- a/hypervisor/arch/arm64/traps.c
>> +++ b/hypervisor/arch/arm64/traps.c
>> @@ -33,6 +33,85 @@ void arch_skip_instruction(struct trap_context *ctx)
>> arm_write_sysreg(ELR_EL2, pc);
>> }
>>
>> +static bool check_workaround_834220(void)
>> +{
>> +unsigned long midr;
>> + unsigned int variant, revision, part;
>> +
>> + arm_read_sysreg(MIDR_EL1, midr);
>> +
>> + variant = (midr >> 20) & 0xf;
>> + revision = midr & 0xf;
>>
Re: Kernel panic on enabling root cell
On 29.05.22 16:44, Lad, Prabhakar wrote:
> Thanks, after updating gicv_base to 0xf106f000 I get an "forbidden
> access" error, looking at the address it belongs to ethernet
> "e6800304" and this is configured in the memory regions
>
> /* AVB */ {
> .phys_start = 0xe680,
> .virt_start = 0xe680,
> .size = 0x800,
This turns the region into a so-called sub-page (see
JAILHOUSE_MEMORY_IS_SUBPAGE), and then...
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_IO,
...you also need to specify the permitted access width for registers in
that sub-page (JAILHOUSE_MEM_IO_{8,16,32,64}). If unaligned accesses are
ok (unlikely), also set JAILHOUSE_MEM_IO_UNALIGNED.
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/3ed840dd-2aa5-b578-617b-cad9e8fd6667%40web.de.
Re: Kernel panic on enabling root cell
On 29.05.22 12:53, Lad, Prabhakar wrote:
> Hi Jan,
>
> On Sun, May 29, 2022 at 9:35 AM Jan Kiszka wrote:
>>
>> On 28.05.22 21:13, Lad, Prabhakar wrote:
>>> Hi Jan,
>>>
>>> On Sat, May 28, 2022 at 3:41 PM Jan Kiszka wrote:
>>>>
>>>> On 28.05.22 15:22, Lad, Prabhakar wrote:
>>>>> On Fri, May 27, 2022 at 6:07 AM Jan Kiszka wrote:
>>>>>>
>>>>>> If that should be the case, you could use the JTAG to "trace" how far
>>>>>> you get: Add an infinite loop at some point the setup should get along,
>>>>>> and then check with the debugger if PC points to that address and if EL2
>>>>>> is active. With that, you could also check if the UART print-out is
>>>>>> executed.
>>>>>>
>>>>> After tracing back I see it's looping infinitely somewhere in the
>>>>> hypervisor.o file, below is the code where it repeatedly loops.
>>>>>
>>>>> c0209550:b9400680 ldrw0, [x20, #4]
>>>>> c0209554:b9403481 ldrw1, [x4, #52]
>>>>> c0209558:6b3f cmpw1, w0
>>>>> c020955c:540013a8 b.hic02097d0
>>>>> .
>>>>> c02097d0:1760 bc0209550
>>>>>
>>>>> I haven't managed to find where exactly in the C file this is
>>>>> happening yet. Any thoughts on what could be happening?
>>>>>
>>>>
>>>> That's very likely
>>>>
>>>> while (entered_cpus < hypervisor_header.online_cpus)
>>>> cpu_relax();
>>>>
>>> Thanks for the pointer really appreciated.
>>>
>>>> Did you configure more CPUs than there are in the system?
>>>>
>>> No I haven't, I've set it up as cpus = 0x3f for 6 CPUs (2xa57 +
>>> 4xa53). I don't know what was happening there when I removed the
>>> infinite loop (which I used for break point) from entry.S that went
>>> OK. There was also an issue with the debug uart driver which I've
>>> fixed and able to get the prints now.
>>>
>>> So now moving forward I am seeing "Unhandled data read"!
>>>
>>> Looking at the address for Unhandled data read one belongs to GIC
>>> (0xf102f00c) and the other one belongs to the debug uart (0xe6e88008).
>>
>> Regarding GICC access: Try setting gicc_base to 0xf102f000 in the root
>> cell config.
>>
> Setting gicc_base to 0xf102f000 has solved the issue, I no longer get
> unhandled data reads now.
>
>> Regarding the UART: Do you pass that address through to the root cell as
>> well? It's generally fine to allow both hypervisor and one cell to
>> access the UART in parallel. Otherwise, disable UART usage by the root
>> cell prior to enabling Jailhouse.
>>
> No, I don't pass the UART address to the root cell as part of
> mem_regions. I just have it as part of the header config as below:
>
> .debug_console = {
> .address = 0xe6e88000,
> .size = 0x40,
> .type = JAILHOUSE_CON_TYPE_SCIFA,
> .flags = JAILHOUSE_CON_ACCESS_MMIO |
> JAILHOUSE_CON_REGDIST_4,
> },
>
> By disabling the UART usage by the root cell did you mean to use
> JAILHOUSE_CON_TYPE_NONE? I tried adding JAILHOUSE_CON_TYPE_NONE but I
No, I meant
- stop using the UART as kernel console
- stop running a getty on the UART (the latter happens automatically
with systemd when doing the former)
> don't get anything on the console after enabling the root cell. I even
> tried removing the entire debug_console{} from the root cell config
> but still I don't see any output on console.
>
> If I update the size to 0x1000 as below and also include it as part of
> mem_regions, I get to a state where I see the message "The Jailhouse
> is opening" but the console seems to be frozen.
Sorry, I missed one bit in the gic configuration pattern on some arm64
targets (scan configs/arm64): you also need to set gicv_base to
0xf106f000, then it will work (crossing fingers...).
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/69a0ae1d-1ee9-e99b-f190-d534ce86c227%40web.de.
Re: Kernel panic on enabling root cell
On 28.05.22 21:13, Lad, Prabhakar wrote: > Hi Jan, > > On Sat, May 28, 2022 at 3:41 PM Jan Kiszka wrote: >> >> On 28.05.22 15:22, Lad, Prabhakar wrote: >>> On Fri, May 27, 2022 at 6:07 AM Jan Kiszka wrote: >>>> >>>> If that should be the case, you could use the JTAG to "trace" how far >>>> you get: Add an infinite loop at some point the setup should get along, >>>> and then check with the debugger if PC points to that address and if EL2 >>>> is active. With that, you could also check if the UART print-out is >>>> executed. >>>> >>> After tracing back I see it's looping infinitely somewhere in the >>> hypervisor.o file, below is the code where it repeatedly loops. >>> >>> c0209550:b9400680 ldrw0, [x20, #4] >>> c0209554:b9403481 ldrw1, [x4, #52] >>> c0209558:6b3f cmpw1, w0 >>> c020955c:540013a8 b.hic02097d0 >>> . >>> c02097d0:1760 bc0209550 >>> >>> I haven't managed to find where exactly in the C file this is >>> happening yet. Any thoughts on what could be happening? >>> >> >> That's very likely >> >> while (entered_cpus < hypervisor_header.online_cpus) >> cpu_relax(); >> > Thanks for the pointer really appreciated. > >> Did you configure more CPUs than there are in the system? >> > No I haven't, I've set it up as cpus = 0x3f for 6 CPUs (2xa57 + > 4xa53). I don't know what was happening there when I removed the > infinite loop (which I used for break point) from entry.S that went > OK. There was also an issue with the debug uart driver which I've > fixed and able to get the prints now. > > So now moving forward I am seeing "Unhandled data read"! > > Looking at the address for Unhandled data read one belongs to GIC > (0xf102f00c) and the other one belongs to the debug uart (0xe6e88008). Regarding GICC access: Try setting gicc_base to 0xf102f000 in the root cell config. Regarding the UART: Do you pass that address through to the root cell as well? It's generally fine to allow both hypervisor and one cell to access the UART in parallel. Otherwise, disable UART usage by the root cell prior to enabling Jailhouse. 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/1a407933-180e-48fa-760c-1c90e159eb2f%40web.de.
Re: Kernel panic on enabling root cell
On 28.05.22 15:22, Lad, Prabhakar wrote: > On Fri, May 27, 2022 at 6:07 AM Jan Kiszka wrote: >> >> On 26.05.22 17:48, Lad, Prabhakar wrote: >>> Hi Jan, >>> >>> On Tue, May 24, 2022 at 12:55 PM Lad, Prabhakar >>> wrote: >>>> >>>> On Mon, May 23, 2022 at 4:13 PM Jan Kiszka wrote: >>>>> >>>>> On 23.05.22 15:55, Lad, Prabhakar wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On Fri, May 20, 2022 at 7:08 AM Jan Kiszka >>>>>> wrote: >>>>>>> >>>>>>> On 19.05.22 15:23, Lad, Prabhakar wrote: >>>>>>>> Hi Jan, >>>>>>>> >>>>>>>> On Thu, May 19, 2022 at 12:39 PM Jan Kiszka >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 19.05.22 11:44, Lad, Prabhakar wrote: >>>>>>>>>> On Thu, May 19, 2022 at 6:30 AM Jan Kiszka >>>>>>>>>> wrote: >>>>>>>>>>> Forgot: that cannot work. The call of arm_dcaches_flush will >>>>>>>>>>> overwrite >>>>>>>>>>> lr, thus the second ret will only return to where the first ret >>>>>>>>>>> jumped >>>>>>>>>>> to - endless loop. You would have to restore lr (x30) from x17 in >>>>>>>>>>> arch_entry first: >>>>>>>>>>> >>>>>>>>>>> mov x30, x17 >>>>>>>>>>> ret >>>>>>>>>>> >>>>>>>>>> That did the trick thanks! >>>>>>>>>> >>>>>>>>>> diff --git a/hypervisor/arch/arm64/entry.S >>>>>>>>>> b/hypervisor/arch/arm64/entry.S >>>>>>>>>> index a9cabf7f..7b340bd1 100644 >>>>>>>>>> --- a/hypervisor/arch/arm64/entry.S >>>>>>>>>> +++ b/hypervisor/arch/arm64/entry.S >>>>>>>>>> @@ -109,6 +109,8 @@ arch_entry: >>>>>>>>>> mov x0, #LINUX_HVC_SET_VECTORS_LEGACY >>>>>>>>>> 1: >>>>>>>>>> hvc #0 >>>>>>>>>> + mov x30, x17 >>>>>>>>>> + ret >>>>>>>>>> >>>>>>>>>> hvc #0 /* bootstrap vectors enter EL2 at el2_entry >>>>>>>>>> */ >>>>>>>>>> b . /* we don't expect to return here */ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> With the above diff I do get the below: >>>>>>>>>> >>>>>>>>>> [ 42.980805] jailhouse: loading out-of-tree module taints kernel. >>>>>>>>>> Reading configuration set: >>>>>>>>>> Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) >>>>>>>>>> Overlapping memory regions inside cell: None >>>>>>>>>> Overlapping memory regions with hypervisor: None >>>>>>>>>> Missing resource interceptions for architecture arm64: None >>>>>>>>>> [ 46.582588] obcode @arm_dcaches_flush: d53b0024 >>>>>>>>>> [ 46.582616] obcode @arm_dcaches_flush: d53b0024 >>>>>>>>>> [ 46.611311] The Jailhouse is opening. >>>>>>>>>> >>>>>>>>>> So it looks like something to do with the debug console. This has to >>>>>>>>>> be poked in the dark or any easy way to debug? >>>>>>>>> >>>>>>>>> Well, we do not yet know what goes wrong. We do know that we can call >>>>>>>>> into the hyp take-over stub and register Jailhouse with it. We do not >>>>>>>>> know if we will then end up in Jailhouse in hyp mode and just lack >>>>>>>>> console output or if we crash on entry already. >>>>>>>>> >>>>>>>> Right agreed. >>>>>>>> >>>>>>>>> To move the uart console out of the picture: Did you already check if >>>>>>>>> the driver you
Re: Kernel panic on enabling root cell
On 26.05.22 17:48, Lad, Prabhakar wrote: > Hi Jan, > > On Tue, May 24, 2022 at 12:55 PM Lad, Prabhakar > wrote: >> >> On Mon, May 23, 2022 at 4:13 PM Jan Kiszka wrote: >>> >>> On 23.05.22 15:55, Lad, Prabhakar wrote: >>>> Hi Jan, >>>> >>>> On Fri, May 20, 2022 at 7:08 AM Jan Kiszka wrote: >>>>> >>>>> On 19.05.22 15:23, Lad, Prabhakar wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On Thu, May 19, 2022 at 12:39 PM Jan Kiszka >>>>>> wrote: >>>>>>> >>>>>>> On 19.05.22 11:44, Lad, Prabhakar wrote: >>>>>>>> On Thu, May 19, 2022 at 6:30 AM Jan Kiszka >>>>>>>> wrote: >>>>>>>>> Forgot: that cannot work. The call of arm_dcaches_flush will overwrite >>>>>>>>> lr, thus the second ret will only return to where the first ret jumped >>>>>>>>> to - endless loop. You would have to restore lr (x30) from x17 in >>>>>>>>> arch_entry first: >>>>>>>>> >>>>>>>>> mov x30, x17 >>>>>>>>> ret >>>>>>>>> >>>>>>>> That did the trick thanks! >>>>>>>> >>>>>>>> diff --git a/hypervisor/arch/arm64/entry.S >>>>>>>> b/hypervisor/arch/arm64/entry.S >>>>>>>> index a9cabf7f..7b340bd1 100644 >>>>>>>> --- a/hypervisor/arch/arm64/entry.S >>>>>>>> +++ b/hypervisor/arch/arm64/entry.S >>>>>>>> @@ -109,6 +109,8 @@ arch_entry: >>>>>>>> mov x0, #LINUX_HVC_SET_VECTORS_LEGACY >>>>>>>> 1: >>>>>>>> hvc #0 >>>>>>>> + mov x30, x17 >>>>>>>> + ret >>>>>>>> >>>>>>>> hvc #0 /* bootstrap vectors enter EL2 at el2_entry */ >>>>>>>> b . /* we don't expect to return here */ >>>>>>>> >>>>>>>> >>>>>>>> With the above diff I do get the below: >>>>>>>> >>>>>>>> [ 42.980805] jailhouse: loading out-of-tree module taints kernel. >>>>>>>> Reading configuration set: >>>>>>>> Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) >>>>>>>> Overlapping memory regions inside cell: None >>>>>>>> Overlapping memory regions with hypervisor: None >>>>>>>> Missing resource interceptions for architecture arm64: None >>>>>>>> [ 46.582588] obcode @arm_dcaches_flush: d53b0024 >>>>>>>> [ 46.582616] obcode @arm_dcaches_flush: d53b0024 >>>>>>>> [ 46.611311] The Jailhouse is opening. >>>>>>>> >>>>>>>> So it looks like something to do with the debug console. This has to >>>>>>>> be poked in the dark or any easy way to debug? >>>>>>> >>>>>>> Well, we do not yet know what goes wrong. We do know that we can call >>>>>>> into the hyp take-over stub and register Jailhouse with it. We do not >>>>>>> know if we will then end up in Jailhouse in hyp mode and just lack >>>>>>> console output or if we crash on entry already. >>>>>>> >>>>>> Right agreed. >>>>>> >>>>>>> To move the uart console out of the picture: Did you already check if >>>>>>> the driver you select in the Jailhouse config is actually one that >>>>>>> should support the UART on your board? Next is to double check if poking >>>>>> The UART on this platform is almost identical to >>>>>> JAILHOUSE_CON_TYPE_SCIFA type, but with some differences which I have >>>>>> patched to work on this platform. >>>>>> >>>>>>> registers in the way the Jailhouse driver will do at the addresses you >>>>>>> configured will work: Pull the code into the kernel module or even into >>>>>>> a userspace application with /dev/mem raw register access and try out if >>>>>>> that works in a "safe" environment (without hypervisor mode). >>>>&g
Re: [PATCH] configs: arm64: k3-am625-sk: fix UART reference comments
On 26.05.22 21:28, 'Matt Ranostay' via Jailhouse wrote:
> Fixed incorrect comments that referenced the UART as connected to MCU.
>
> Signed-off-by: Matt Ranostay
> ---
> configs/arm64/k3-am625-sk-inmate-demo.c | 4 ++--
> configs/arm64/k3-am625-sk-linux-demo.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/configs/arm64/k3-am625-sk-inmate-demo.c
> b/configs/arm64/k3-am625-sk-inmate-demo.c
> index 65cf4a7f..49edd62d 100644
> --- a/configs/arm64/k3-am625-sk-inmate-demo.c
> +++ b/configs/arm64/k3-am625-sk-inmate-demo.c
> @@ -2,7 +2,7 @@
> * Jailhouse, a Linux-based partitioning hypervisor
> *
> * Configuration for demo inmate on K3 based platforms.
> - * 1CPU, 64K RAM, 1 serial port(MCU UART 0).
> + * 1CPU, 64K RAM, 1 serial port(MAIN UART 1).
> *
> * Copyright (c) 2019, 2022 Texas Instruments Incorporated -
> http://www.ti.com/
> *
> @@ -48,7 +48,7 @@ struct {
> },
>
> .mem_regions = {
> - /* MCU UART0 */ {
> + /* MAIN UART1 */ {
> .phys_start = 0x0281,
> .virt_start = 0x0281,
> .size = 0x1,
> diff --git a/configs/arm64/k3-am625-sk-linux-demo.c
> b/configs/arm64/k3-am625-sk-linux-demo.c
> index 81f4e880..a3385efc 100644
> --- a/configs/arm64/k3-am625-sk-linux-demo.c
> +++ b/configs/arm64/k3-am625-sk-linux-demo.c
> @@ -105,7 +105,7 @@ struct {
> JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_DMA |
> JAILHOUSE_MEM_LOADABLE,
> },
> - /* MCU UART0 */ {
> + /* MAIN UART1 */ {
> .phys_start = 0x0281,
> .virt_start = 0x0281,
> .size = 0x1,
thanks, applied.
Jan
--
Siemens AG, Technology
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/9351380d-60cf-f97b-ed17-54f3bdb44d64%40siemens.com.
Re: Kernel panic on enabling root cell
On 23.05.22 15:55, Lad, Prabhakar wrote: > Hi Jan, > > On Fri, May 20, 2022 at 7:08 AM Jan Kiszka wrote: >> >> On 19.05.22 15:23, Lad, Prabhakar wrote: >>> Hi Jan, >>> >>> On Thu, May 19, 2022 at 12:39 PM Jan Kiszka wrote: >>>> >>>> On 19.05.22 11:44, Lad, Prabhakar wrote: >>>>> On Thu, May 19, 2022 at 6:30 AM Jan Kiszka wrote: >>>>>> Forgot: that cannot work. The call of arm_dcaches_flush will overwrite >>>>>> lr, thus the second ret will only return to where the first ret jumped >>>>>> to - endless loop. You would have to restore lr (x30) from x17 in >>>>>> arch_entry first: >>>>>> >>>>>> mov x30, x17 >>>>>> ret >>>>>> >>>>> That did the trick thanks! >>>>> >>>>> diff --git a/hypervisor/arch/arm64/entry.S b/hypervisor/arch/arm64/entry.S >>>>> index a9cabf7f..7b340bd1 100644 >>>>> --- a/hypervisor/arch/arm64/entry.S >>>>> +++ b/hypervisor/arch/arm64/entry.S >>>>> @@ -109,6 +109,8 @@ arch_entry: >>>>> mov x0, #LINUX_HVC_SET_VECTORS_LEGACY >>>>> 1: >>>>> hvc #0 >>>>> + mov x30, x17 >>>>> + ret >>>>> >>>>> hvc #0 /* bootstrap vectors enter EL2 at el2_entry */ >>>>> b . /* we don't expect to return here */ >>>>> >>>>> >>>>> With the above diff I do get the below: >>>>> >>>>> [ 42.980805] jailhouse: loading out-of-tree module taints kernel. >>>>> Reading configuration set: >>>>> Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) >>>>> Overlapping memory regions inside cell: None >>>>> Overlapping memory regions with hypervisor: None >>>>> Missing resource interceptions for architecture arm64: None >>>>> [ 46.582588] obcode @arm_dcaches_flush: d53b0024 >>>>> [ 46.582616] obcode @arm_dcaches_flush: d53b0024 >>>>> [ 46.611311] The Jailhouse is opening. >>>>> >>>>> So it looks like something to do with the debug console. This has to >>>>> be poked in the dark or any easy way to debug? >>>> >>>> Well, we do not yet know what goes wrong. We do know that we can call >>>> into the hyp take-over stub and register Jailhouse with it. We do not >>>> know if we will then end up in Jailhouse in hyp mode and just lack >>>> console output or if we crash on entry already. >>>> >>> Right agreed. >>> >>>> To move the uart console out of the picture: Did you already check if >>>> the driver you select in the Jailhouse config is actually one that >>>> should support the UART on your board? Next is to double check if poking >>> The UART on this platform is almost identical to >>> JAILHOUSE_CON_TYPE_SCIFA type, but with some differences which I have >>> patched to work on this platform. >>> >>>> registers in the way the Jailhouse driver will do at the addresses you >>>> configured will work: Pull the code into the kernel module or even into >>>> a userspace application with /dev/mem raw register access and try out if >>>> that works in a "safe" environment (without hypervisor mode). >>>> >>> Sure will give that a shot, any pointers on doing this from userspace? >>> >> >> Something like this may help if you do that the first time: >> https://bakhi.github.io/devmem/ >> > Thanks for the pointer. > I have tried reading/writing from the hypervisor location and that > goes all OK. Means, you were able to generate output on the UART. Hmm, would have been too easy. > To avoid any issue related to debug UART is there any way > I could test this prior to enabling? Not without extra measures: Without JAILHOUSE_BORROW_ROOT_PT, which applies to arm64, the driver will not map the physical UART page. That only happens in init_bootstrap_pt which is run after jumping to EL2. So, we the jump goes wrong, you cannot find out where you are. Do you have the chance to get hold of some jtag to find out where the CPUs are? Jan -- Siemens AG, Technology 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/385f8761-8d70-d0c4-f903-9adadb3c9a90%40siemens.com.
Re: Kernel panic on enabling root cell
On 19.05.22 15:23, Lad, Prabhakar wrote: > Hi Jan, > > On Thu, May 19, 2022 at 12:39 PM Jan Kiszka wrote: >> >> On 19.05.22 11:44, Lad, Prabhakar wrote: >>> On Thu, May 19, 2022 at 6:30 AM Jan Kiszka wrote: >>>> Forgot: that cannot work. The call of arm_dcaches_flush will overwrite >>>> lr, thus the second ret will only return to where the first ret jumped >>>> to - endless loop. You would have to restore lr (x30) from x17 in >>>> arch_entry first: >>>> >>>> mov x30, x17 >>>> ret >>>> >>> That did the trick thanks! >>> >>> diff --git a/hypervisor/arch/arm64/entry.S b/hypervisor/arch/arm64/entry.S >>> index a9cabf7f..7b340bd1 100644 >>> --- a/hypervisor/arch/arm64/entry.S >>> +++ b/hypervisor/arch/arm64/entry.S >>> @@ -109,6 +109,8 @@ arch_entry: >>> mov x0, #LINUX_HVC_SET_VECTORS_LEGACY >>> 1: >>> hvc #0 >>> + mov x30, x17 >>> + ret >>> >>> hvc #0 /* bootstrap vectors enter EL2 at el2_entry */ >>> b . /* we don't expect to return here */ >>> >>> >>> With the above diff I do get the below: >>> >>> [ 42.980805] jailhouse: loading out-of-tree module taints kernel. >>> Reading configuration set: >>> Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) >>> Overlapping memory regions inside cell: None >>> Overlapping memory regions with hypervisor: None >>> Missing resource interceptions for architecture arm64: None >>> [ 46.582588] obcode @arm_dcaches_flush: d53b0024 >>> [ 46.582616] obcode @arm_dcaches_flush: d53b0024 >>> [ 46.611311] The Jailhouse is opening. >>> >>> So it looks like something to do with the debug console. This has to >>> be poked in the dark or any easy way to debug? >> >> Well, we do not yet know what goes wrong. We do know that we can call >> into the hyp take-over stub and register Jailhouse with it. We do not >> know if we will then end up in Jailhouse in hyp mode and just lack >> console output or if we crash on entry already. >> > Right agreed. > >> To move the uart console out of the picture: Did you already check if >> the driver you select in the Jailhouse config is actually one that >> should support the UART on your board? Next is to double check if poking > The UART on this platform is almost identical to > JAILHOUSE_CON_TYPE_SCIFA type, but with some differences which I have > patched to work on this platform. > >> registers in the way the Jailhouse driver will do at the addresses you >> configured will work: Pull the code into the kernel module or even into >> a userspace application with /dev/mem raw register access and try out if >> that works in a "safe" environment (without hypervisor mode). >> > Sure will give that a shot, any pointers on doing this from userspace? > Something like this may help if you do that the first time: https://bakhi.github.io/devmem/ Jan -- Siemens AG, Technology 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/eafaaed1-604f-569b-47f5-232b01cfcee5%40siemens.com.
Re: Kernel panic on enabling root cell
On 19.05.22 11:44, Lad, Prabhakar wrote: > On Thu, May 19, 2022 at 6:30 AM Jan Kiszka wrote: >> >> On 17.05.22 18:19, Lad, Prabhakar wrote: >>> Hi Jan, >>> >>> On Tue, May 17, 2022 at 12:44 PM Jan Kiszka wrote: >>>> >>>> On 16.05.22 20:01, Lad, Prabhakar wrote: >>>>> Hi Jan, >>>>> >>>>> On Mon, May 16, 2022 at 6:57 AM Jan Kiszka wrote: >>>>>> >>>>>> On 13.05.22 18:28, Lad, Prabhakar wrote: >>>>>>> Hi Jan, >>>>>>> >>>>>>> On Fri, May 13, 2022 at 4:33 PM Jan Kiszka >>>>>>> wrote: >>>>>>>> >>>>>>>> On 13.05.22 17:20, Lad, Prabhakar wrote: >>>>>>>>> On Fri, May 13, 2022 at 1:18 PM Jan Kiszka >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 13.05.22 13:32, Lad, Prabhakar wrote: >>>>>>>>>>>> Could it be that arm_dcaches_flush was a red herring? Maybe we are >>>>>>>>>>>> actually crashing on hvc in arch_entry, and that because of Linux >>>>>>>>>>>> not >>>>>>>>>>>> starting in HVC mode, thus no hypervisor take-over stub being >>>>>>>>>>>> installed. >>>>>>>>>>>> >>>>>>>>>>>> Could you share the boot log of the kernel? >>>>>>>>>>>> >>>>>>>>>>> Attached is the complete log. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> "CPU: All CPU(s) started at EL1" >>>>>>>>>> >>>>>>>>>> As suspected. Must be EL2 or HYP. Reconfigure your firmware to >>>>>>>>>> enable that. >>>>>>>>>> >>>>>>>>> Argh my bad, I've now enabled it to start in EL2 mode (attached are >>>>>>>>> the complete logs). Now I see the below panic, >>>>>>>>> >>>>>>>>> [ 33.920507] jailhouse: loading out-of-tree module taints kernel. >>>>>>>>> Reading configuration set: >>>>>>>>> Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) >>>>>>>>> Overlapping memory regions inside cell: None >>>>>>>>> Overlapping memory regions with hypervisor: None >>>>>>>>> Missing resource interceptions for architecture arm64: None >>>>>>>>> [ 34.741847] Bad mode in Synchronous Abort handler detected on CPU0, >>>>>>>>> code 0x5a00 -- HVC (AArch64) >>>>>> >>>>>> "HVC instruction execution in AArch64 state, when HVC is not disabled", >>>>>> origin: EL2 (hypervisor mode). >>>>>> >>>>>> Is KVM off again when you start Jailhouse here? Does the CPU support VHE >>>>>> (Virtualization Host Extension)? Is CONFIG_ARM64_VHE enabled? Try to >>>>>> turn that off. >>>>>> >>>>> KVM was OFF, I have enabled both CONFIG_VIRTUALIZATION and CONFIG_KVM >>>>> (I have attached the complete kernel config). Yes the CPU does have >>>>> VHE support. I did it by disabling CONFIG_ARM64_VHE which did not make >>>>> any difference. >>>>> >>>>> With the VHE disable now I get the below output: >>>>> root@smarc-rzg2l:~# dmesg | grep -i kvm >>>>> [0.095927] kvm [1]: IPA Size Limit: 40 bits >>>>> [0.096895] kvm [1]: GICv3: no GICV resource entry >>>>> [0.096916] kvm [1]: disabling GICv2 emulation >>>>> [0.096949] kvm [1]: GIC system register CPU interface enabled >>>>> [0.097045] kvm [1]: vgic interrupt IRQ9 >>>>> [0.097156] kvm [1]: Hyp mode initialized successfully >>>>> root@smarc-rzg2l:~# >>>>> >>>>> Now with the above configs I don't get any output on the console when >>>>> the root cell is enabled: >>>>> >>>>> root@smarc-rzg2l:~# sh -x ./hyp.sh >>>>> + insmod jailhouse.ko >>>>> [ 35.379219] jailhouse: loading out-of-tree module taints kernel. >>>>> + jailhouse config check -a arm64 renesas-
Re: Kernel panic on enabling root cell
On 17.05.22 18:19, Lad, Prabhakar wrote: > Hi Jan, > > On Tue, May 17, 2022 at 12:44 PM Jan Kiszka wrote: >> >> On 16.05.22 20:01, Lad, Prabhakar wrote: >>> Hi Jan, >>> >>> On Mon, May 16, 2022 at 6:57 AM Jan Kiszka wrote: >>>> >>>> On 13.05.22 18:28, Lad, Prabhakar wrote: >>>>> Hi Jan, >>>>> >>>>> On Fri, May 13, 2022 at 4:33 PM Jan Kiszka wrote: >>>>>> >>>>>> On 13.05.22 17:20, Lad, Prabhakar wrote: >>>>>>> On Fri, May 13, 2022 at 1:18 PM Jan Kiszka >>>>>>> wrote: >>>>>>>> >>>>>>>> On 13.05.22 13:32, Lad, Prabhakar wrote: >>>>>>>>>> Could it be that arm_dcaches_flush was a red herring? Maybe we are >>>>>>>>>> actually crashing on hvc in arch_entry, and that because of Linux not >>>>>>>>>> starting in HVC mode, thus no hypervisor take-over stub being >>>>>>>>>> installed. >>>>>>>>>> >>>>>>>>>> Could you share the boot log of the kernel? >>>>>>>>>> >>>>>>>>> Attached is the complete log. >>>>>>>>> >>>>>>>> >>>>>>>> "CPU: All CPU(s) started at EL1" >>>>>>>> >>>>>>>> As suspected. Must be EL2 or HYP. Reconfigure your firmware to enable >>>>>>>> that. >>>>>>>> >>>>>>> Argh my bad, I've now enabled it to start in EL2 mode (attached are >>>>>>> the complete logs). Now I see the below panic, >>>>>>> >>>>>>> [ 33.920507] jailhouse: loading out-of-tree module taints kernel. >>>>>>> Reading configuration set: >>>>>>> Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) >>>>>>> Overlapping memory regions inside cell: None >>>>>>> Overlapping memory regions with hypervisor: None >>>>>>> Missing resource interceptions for architecture arm64: None >>>>>>> [ 34.741847] Bad mode in Synchronous Abort handler detected on CPU0, >>>>>>> code 0x5a00 -- HVC (AArch64) >>>> >>>> "HVC instruction execution in AArch64 state, when HVC is not disabled", >>>> origin: EL2 (hypervisor mode). >>>> >>>> Is KVM off again when you start Jailhouse here? Does the CPU support VHE >>>> (Virtualization Host Extension)? Is CONFIG_ARM64_VHE enabled? Try to >>>> turn that off. >>>> >>> KVM was OFF, I have enabled both CONFIG_VIRTUALIZATION and CONFIG_KVM >>> (I have attached the complete kernel config). Yes the CPU does have >>> VHE support. I did it by disabling CONFIG_ARM64_VHE which did not make >>> any difference. >>> >>> With the VHE disable now I get the below output: >>> root@smarc-rzg2l:~# dmesg | grep -i kvm >>> [0.095927] kvm [1]: IPA Size Limit: 40 bits >>> [0.096895] kvm [1]: GICv3: no GICV resource entry >>> [0.096916] kvm [1]: disabling GICv2 emulation >>> [0.096949] kvm [1]: GIC system register CPU interface enabled >>> [0.097045] kvm [1]: vgic interrupt IRQ9 >>> [0.097156] kvm [1]: Hyp mode initialized successfully >>> root@smarc-rzg2l:~# >>> >>> Now with the above configs I don't get any output on the console when >>> the root cell is enabled: >>> >>> root@smarc-rzg2l:~# sh -x ./hyp.sh >>> + insmod jailhouse.ko >>> [ 35.379219] jailhouse: loading out-of-tree module taints kernel. >>> + jailhouse config check -a arm64 renesas-r9a07g054l2.cell >>> Reading configuration set: >>> Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) >>> Overlapping memory regions inside cell: None >>> Overlapping memory regions with hypervisor: None >>> Missing resource interceptions for architecture arm64: None >>> + jailhouse enable renesas-r9a07g054l2.cell >>> [ 36.217465] obcode @arm_dcaches_flush: d53b0024 >>> [ 36.217469] obcode @arm_dcaches_flush: d53b0024 >>> >>> Any pointers on debugging this further, has anyone tried jailhouse on >>> Cortex-A55 before? >> >> Hmm, at least not I so far. Might be the point that we are missing some >> subtle difference here around the way the setup wo
Re: Kernel panic on enabling root cell
On 16.05.22 20:01, Lad, Prabhakar wrote: > Hi Jan, > > On Mon, May 16, 2022 at 6:57 AM Jan Kiszka wrote: >> >> On 13.05.22 18:28, Lad, Prabhakar wrote: >>> Hi Jan, >>> >>> On Fri, May 13, 2022 at 4:33 PM Jan Kiszka wrote: >>>> >>>> On 13.05.22 17:20, Lad, Prabhakar wrote: >>>>> On Fri, May 13, 2022 at 1:18 PM Jan Kiszka wrote: >>>>>> >>>>>> On 13.05.22 13:32, Lad, Prabhakar wrote: >>>>>>>> Could it be that arm_dcaches_flush was a red herring? Maybe we are >>>>>>>> actually crashing on hvc in arch_entry, and that because of Linux not >>>>>>>> starting in HVC mode, thus no hypervisor take-over stub being >>>>>>>> installed. >>>>>>>> >>>>>>>> Could you share the boot log of the kernel? >>>>>>>> >>>>>>> Attached is the complete log. >>>>>>> >>>>>> >>>>>> "CPU: All CPU(s) started at EL1" >>>>>> >>>>>> As suspected. Must be EL2 or HYP. Reconfigure your firmware to enable >>>>>> that. >>>>>> >>>>> Argh my bad, I've now enabled it to start in EL2 mode (attached are >>>>> the complete logs). Now I see the below panic, >>>>> >>>>> [ 33.920507] jailhouse: loading out-of-tree module taints kernel. >>>>> Reading configuration set: >>>>> Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) >>>>> Overlapping memory regions inside cell: None >>>>> Overlapping memory regions with hypervisor: None >>>>> Missing resource interceptions for architecture arm64: None >>>>> [ 34.741847] Bad mode in Synchronous Abort handler detected on CPU0, >>>>> code 0x5a00 -- HVC (AArch64) >> >> "HVC instruction execution in AArch64 state, when HVC is not disabled", >> origin: EL2 (hypervisor mode). >> >> Is KVM off again when you start Jailhouse here? Does the CPU support VHE >> (Virtualization Host Extension)? Is CONFIG_ARM64_VHE enabled? Try to >> turn that off. >> > KVM was OFF, I have enabled both CONFIG_VIRTUALIZATION and CONFIG_KVM > (I have attached the complete kernel config). Yes the CPU does have > VHE support. I did it by disabling CONFIG_ARM64_VHE which did not make > any difference. > > With the VHE disable now I get the below output: > root@smarc-rzg2l:~# dmesg | grep -i kvm > [0.095927] kvm [1]: IPA Size Limit: 40 bits > [0.096895] kvm [1]: GICv3: no GICV resource entry > [0.096916] kvm [1]: disabling GICv2 emulation > [0.096949] kvm [1]: GIC system register CPU interface enabled > [0.097045] kvm [1]: vgic interrupt IRQ9 > [0.097156] kvm [1]: Hyp mode initialized successfully > root@smarc-rzg2l:~# > > Now with the above configs I don't get any output on the console when > the root cell is enabled: > > root@smarc-rzg2l:~# sh -x ./hyp.sh > + insmod jailhouse.ko > [ 35.379219] jailhouse: loading out-of-tree module taints kernel. > + jailhouse config check -a arm64 renesas-r9a07g054l2.cell > Reading configuration set: > Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) > Overlapping memory regions inside cell: None > Overlapping memory regions with hypervisor: None > Missing resource interceptions for architecture arm64: None > + jailhouse enable renesas-r9a07g054l2.cell > [ 36.217465] obcode @arm_dcaches_flush: d53b0024 > [ 36.217469] obcode @arm_dcaches_flush: d53b0024 > > Any pointers on debugging this further, has anyone tried jailhouse on > Cortex-A55 before? Hmm, at least not I so far. Might be the point that we are missing some subtle difference here around the way the setup works then. In any case, the fact that at least the previous crash is gone indicates that something changed. You could check if you reach now the second hvc by adding a ret in front of it. If you, you may end up in hyp mode, maybe just not have a working UART yet (is the model you have on the board in principle already supported by Jailhouse?), run into a different issue, but just don't see Jailhouse report of it. Jan -- Siemens AG, Technology 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/234b1a2d-ea25-e38c-5053-eea15f57b933%40siemens.com.
Re: phys_start and virt_start relationship with IPA, PA and VA
On 13.05.22 15:42, Jean de Bonfils wrote: > Hi everyone, > I can not understand the relationship between *phys_start *and > *virt_start* defined in cells and Intermediate Physical Address, > Physical address... > > Are phys_start addresses defined in cells IPA or PA ? It's PA, the host's view of physical addresses. > Are virt_start addresses defined in cells VA or IPA ? IPA. The hypervisor does not mess with the guest's own translation tables (IPA->VA). > Why in inmate cell samples virt_start are equals to phys_start ? What if > I would set a different mapping ? There are basically two reason to ID-map resources into the cell: - for physical resources, it avoids having to invent an own guest address layout and permits to reuse device tree fragments from the host - for RAM, this works around missing IOMMUs (which has isolation implications as well, obviously) If non-of that matters, you may also relocate the resources of a non-root cell. Jan -- Siemens AG, Technology 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/364721db-8754-728e-e117-df4df2e757a1%40siemens.com.
Re: Kernel panic on enabling root cell
On 13.05.22 18:28, Lad, Prabhakar wrote: > Hi Jan, > > On Fri, May 13, 2022 at 4:33 PM Jan Kiszka wrote: >> >> On 13.05.22 17:20, Lad, Prabhakar wrote: >>> On Fri, May 13, 2022 at 1:18 PM Jan Kiszka wrote: >>>> >>>> On 13.05.22 13:32, Lad, Prabhakar wrote: >>>>>> Could it be that arm_dcaches_flush was a red herring? Maybe we are >>>>>> actually crashing on hvc in arch_entry, and that because of Linux not >>>>>> starting in HVC mode, thus no hypervisor take-over stub being installed. >>>>>> >>>>>> Could you share the boot log of the kernel? >>>>>> >>>>> Attached is the complete log. >>>>> >>>> >>>> "CPU: All CPU(s) started at EL1" >>>> >>>> As suspected. Must be EL2 or HYP. Reconfigure your firmware to enable that. >>>> >>> Argh my bad, I've now enabled it to start in EL2 mode (attached are >>> the complete logs). Now I see the below panic, >>> >>> [ 33.920507] jailhouse: loading out-of-tree module taints kernel. >>> Reading configuration set: >>> Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) >>> Overlapping memory regions inside cell: None >>> Overlapping memory regions with hypervisor: None >>> Missing resource interceptions for architecture arm64: None >>> [ 34.741847] Bad mode in Synchronous Abort handler detected on CPU0, >>> code 0x5a00 -- HVC (AArch64) "HVC instruction execution in AArch64 state, when HVC is not disabled", origin: EL2 (hypervisor mode). Is KVM off again when you start Jailhouse here? Does the CPU support VHE (Virtualization Host Extension)? Is CONFIG_ARM64_VHE enabled? Try to turn that off. If that is the reason, we need to improve documentation, also along the different kernel version because the config vanished later on - not sure if things still work then after 5.13 on such hardware. Jan -- Siemens AG, Technology 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/8e895901-cd60-9696-935a-293245586a77%40siemens.com.
Re: Kernel panic on enabling root cell
On 13.05.22 17:20, Lad, Prabhakar wrote: > On Fri, May 13, 2022 at 1:18 PM Jan Kiszka wrote: >> >> On 13.05.22 13:32, Lad, Prabhakar wrote: >>>> Could it be that arm_dcaches_flush was a red herring? Maybe we are >>>> actually crashing on hvc in arch_entry, and that because of Linux not >>>> starting in HVC mode, thus no hypervisor take-over stub being installed. >>>> >>>> Could you share the boot log of the kernel? >>>> >>> Attached is the complete log. >>> >> >> "CPU: All CPU(s) started at EL1" >> >> As suspected. Must be EL2 or HYP. Reconfigure your firmware to enable that. >> > Argh my bad, I've now enabled it to start in EL2 mode (attached are > the complete logs). Now I see the below panic, > > [ 33.920507] jailhouse: loading out-of-tree module taints kernel. > Reading configuration set: > Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) > Overlapping memory regions inside cell: None > Overlapping memory regions with hypervisor: None > Missing resource interceptions for architecture arm64: None > [ 34.741847] Bad mode in Synchronous Abort handler detected on CPU0, > code 0x5a00 -- HVC (AArch64) > [ 34.741850] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O > 5.10.112-cip6+ #13 > [ 34.741853] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT) > [ 34.741855] pstate: 20400089 (nzCv daIf +PAN -UAO -TCO BTYPE=--) > [ 34.741857] pc : 0x800013004868 > [ 34.741859] lr : 0x80001300484c > [ 34.741860] sp : 8000118cbed0 > [ 34.741862] x29: 8000118cbed0 x28: 800011632f80 > [ 34.741869] x27: 800011632f80 x26: 8000118cc000 > [ 34.741873] x25: 8000118c8000 x24: 80001162a344 > [ 34.741877] x23: x22: > [ 34.741881] x21: 80001300 x20: 800013004800 > [ 34.741885] x19: 88c17000 x18: 0001 > [ 34.741889] x17: 88c11828 x16: > [ 34.741893] x15: c004b800 x14: 1004b800 > [ 34.741897] x13: c020 x12: b6f0 > [ 34.741900] x11: f6d0 x10: 8000118cbed0 > [ 34.741904] x9 : 8000118cbed0 x8 : 3062333564203a68 > [ 34.741908] x7 : x6 : 7fc6caa0 > [ 34.741912] x5 : 7fc6caa0 x4 : 003f > [ 34.741916] x3 : 0040 x2 : 0002 > [ 34.741920] x1 : b6f05000 x0 : > [ 34.741924] Kernel panic - not syncing: bad mode > [ 34.741927] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O > 5.10.112-cip6+ #13 > [ 34.741929] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT) > [ 34.741930] Call trace: > [ 34.741932] dump_backtrace+0x0/0x1c0 > [ 34.741934] show_stack+0x18/0x68 > [ 34.741935] dump_stack+0xd8/0x134 > [ 34.741937] panic+0x180/0x398 > [ 34.741939] bad_mode+0x8c/0x90 > [ 34.741940] el1_inv+0x3c/0x60 > [ 34.741942] el1_sync_handler+0xac/0xe0 > [ 34.741943] el1_sync+0x84/0x140 > [ 34.741945] 0x800013004868 > [ 34.741947] flush_smp_call_function_queue+0xf8/0x268 > [ 34.741949] generic_smp_call_function_single_interrupt+0x14/0x20 > [ 34.741950] ipi_handler+0x8c/0x158 > [ 34.741952] handle_percpu_devid_fasteoi_ipi+0x74/0x88 > [ 34.741953] generic_handle_irq+0x30/0x48 > [ 34.741955] __handle_domain_irq+0x60/0xb8 > [ 34.741957] gic_handle_irq+0x58/0x128 > [ 34.741958] el1_irq+0xc8/0x180 > [ 34.741960] arch_cpu_idle+0x18/0x28 > [ 34.741961] default_idle_call+0x24/0x5c > [ 34.741963] do_idle+0x1ec/0x288 > [ 34.741964] cpu_startup_entry+0x24/0x68 > [ 34.741966] rest_init+0xd8/0xe8 > [ 34.741967] arch_call_rest_init+0x10/0x1c > [ 34.741969] start_kernel+0x4b0/0x4e8 > [ 34.981086] SMP: stopping secondary CPUs > [ 34.981088] Kernel Offset: disabled > [ 34.981090] CPU features: 0x0040026,2a00aa38 > [ 34.981091] Memory Limit: none > [ 34.981094] Bad mode in Synchronous Abort handler detected on CPU1, > code 0x5a00 -- HVC (AArch64) > [ 34.981097] CPU: 1 PID: 232 Comm: jailhouse Tainted: G O > 5.10.112-cip6+ #13 > [ 34.981099] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT) > [ 34.981101] pstate: 20400089 (nzCv daIf +PAN -UAO -TCO BTYPE=--) > [ 34.981103] pc : 0x800013004868 > [ 34.981104] lr : 0x80001300484c > [ 34.981106] sp : 800011f93b30 > [ 34.981107] x29: 800011f93b30 x28: > [ 34.98] x27: 80001300 x26: 88c17000 > [ 34.981115] x25: 88c17000 x24: 0002 > [ 34.981119] x23: 0870 x22:
Re: Kernel panic on enabling root cell
On 13.05.22 13:32, Lad, Prabhakar wrote: >> Could it be that arm_dcaches_flush was a red herring? Maybe we are >> actually crashing on hvc in arch_entry, and that because of Linux not >> starting in HVC mode, thus no hypervisor take-over stub being installed. >> >> Could you share the boot log of the kernel? >> > Attached is the complete log. > "CPU: All CPU(s) started at EL1" As suspected. Must be EL2 or HYP. Reconfigure your firmware to enable that. 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/c44b2378-e682-4b0b-8443-57f28aeea9ee%40siemens.com.
Re: Kernel panic on enabling root cell
On 12.05.22 13:37, Lad, Prabhakar wrote:
> Hi Jan,
>
> On Thu, May 12, 2022 at 12:16 PM Jan Kiszka wrote:
>>
>> On 12.05.22 13:06, Lad, Prabhakar wrote:
>>> Hi Jan,
>>>
>>> On Thu, May 12, 2022 at 11:24 AM Jan Kiszka wrote:
>>>>
>>>> On 12.05.22 09:01, Lad, Prabhakar wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On Thu, May 12, 2022 at 6:45 AM Jan Kiszka wrote:
>>>>>>
>>>>>> On 11.05.22 19:09, Lad, Prabhakar wrote:
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> On Wed, May 11, 2022 at 4:11 PM Jan Kiszka
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 11.05.22 13:20, Prabhakar Lad wrote:
>>>>>>>>> To add further more details:
>>>>>>>>>
>>>>>>>>> I am using jailhouse-enabling/5.10 Linux branch [0] with -next branch
>>>>>>>>> for jailhouse [1].
>>>>>>>>>
>>>>>>>>> I added some debug prints and I see the panic is caused when entry()
>>>>>>>>> function is called (in enter_hypervisor). The entry function lands
>>>>>>>>> into
>>>>>>>>> assembly code (entry.S). I dont have a JTAG to see which exact
>>>>>>>>> instruction is causing this issue.
>>>>>>>>
>>>>>>>> So, already the first instruction in the loaded hypervisor binary is
>>>>>>>> not
>>>>>>>> executable? That would explain why we see no hypervisor output at all.
>>>>>>>>
>>>>>>> To clarify when the hypervisor is loaded the output will be via
>>>>>>> debug_console specified in the root cell config?
>>>>>>>
>>>>>>
>>>>>> Correct - if you reach entry() in setup.c.
>>>>>>
>>>>>>>> Was that memory region properly reserved from Linux (via DTB carve-out
>>>>>>>> e.g.)?
>>>>>>>>
>>>>>>> Yes I have the below memory reserved in my dts:
>>>>>>>
>>>>>>> memory@4800 {
>>>>>>> device_type = "memory";
>>>>>>> /* first 128MB is reserved for secure area. */
>>>>>>> reg = <0x0 0x4800 0x0 0x7800>;
>>>>>>> };
>>>>>>>
>>>>>>> reserved-memory {
>>>>>>> #address-cells = <2>;
>>>>>>> #size-cells = <2>;
>>>>>>> ranges;
>>>>>>>
>>>>>>> jh_inmate@a7f0 {
>>>>>>> status = "okay";
>>>>>>> no-map;
>>>>>>> reg = <0x00 0xa7f0 0x00 0xf00>;
>>>>>>> };
>>>>>>>
>>>>>>> jailhouse: jailhouse@b6f0 {
>>>>>>> status = "okay";
>>>>>>> reg = <0x0 0xb6f0 0x0 0x100>;
>>>>>>> no-map;
>>>>>>> };
>>>>>>> };
>>>>>>>
>>>>>>> Linux does report the hole in RAM:
>>>>>>>
>>>>>>> root@smarc-rzg2l:~# cat /proc/iomem | grep RAM
>>>>>>> 4800-a7ef : System RAM
>>>>>>> b7f0-bfff : System RAM
>>>>>>>
>>>>>>> And below is my root cell config related to hypervisor memory:
>>>>>>>
>>>>>>> .hypervisor_memory = {
>>>>>>> .phys_start = 0xb6f0,
>>>>>>> .size = 0x100,
>>>>>>> },
>>>>>>>
>>>>>>> Is there anything obvious I have missed above?
>>>>>>>
>>>>>>
>>>>>> Nothing obvious to me so far.
>>>>>>
>>>>>> So, is this really the first instruction in
>>>>>> hypervisor/arch/arm64/entry.S, arch_entry, that triggers the undefinstr?
>>>>>> Check the reported address by Linux against the disassembly of the
>>>>>>
Re: Kernel panic on enabling root cell
On 13.05.22 09:31, Lad, Prabhakar wrote:
> Hi Jan,
>
> On Thu, May 12, 2022 at 6:05 PM Jan Kiszka wrote:
>>
>> On 12.05.22 13:37, Lad, Prabhakar wrote:
>>> Hi Jan,
>>>
>>> On Thu, May 12, 2022 at 12:16 PM Jan Kiszka wrote:
>>>>
>>>> On 12.05.22 13:06, Lad, Prabhakar wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On Thu, May 12, 2022 at 11:24 AM Jan Kiszka
>>>>> wrote:
>>>>>>
>>>>>> On 12.05.22 09:01, Lad, Prabhakar wrote:
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> On Thu, May 12, 2022 at 6:45 AM Jan Kiszka
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 11.05.22 19:09, Lad, Prabhakar wrote:
>>>>>>>>> Hi Jan,
>>>>>>>>>
>>>>>>>>> On Wed, May 11, 2022 at 4:11 PM Jan Kiszka
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 11.05.22 13:20, Prabhakar Lad wrote:
>>>>>>>>>>> To add further more details:
>>>>>>>>>>>
>>>>>>>>>>> I am using jailhouse-enabling/5.10 Linux branch [0] with -next
>>>>>>>>>>> branch
>>>>>>>>>>> for jailhouse [1].
>>>>>>>>>>>
>>>>>>>>>>> I added some debug prints and I see the panic is caused when entry()
>>>>>>>>>>> function is called (in enter_hypervisor). The entry function lands
>>>>>>>>>>> into
>>>>>>>>>>> assembly code (entry.S). I dont have a JTAG to see which exact
>>>>>>>>>>> instruction is causing this issue.
>>>>>>>>>>
>>>>>>>>>> So, already the first instruction in the loaded hypervisor binary is
>>>>>>>>>> not
>>>>>>>>>> executable? That would explain why we see no hypervisor output at
>>>>>>>>>> all.
>>>>>>>>>>
>>>>>>>>> To clarify when the hypervisor is loaded the output will be via
>>>>>>>>> debug_console specified in the root cell config?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Correct - if you reach entry() in setup.c.
>>>>>>>>
>>>>>>>>>> Was that memory region properly reserved from Linux (via DTB
>>>>>>>>>> carve-out
>>>>>>>>>> e.g.)?
>>>>>>>>>>
>>>>>>>>> Yes I have the below memory reserved in my dts:
>>>>>>>>>
>>>>>>>>> memory@4800 {
>>>>>>>>> device_type = "memory";
>>>>>>>>> /* first 128MB is reserved for secure area. */
>>>>>>>>> reg = <0x0 0x4800 0x0 0x7800>;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> reserved-memory {
>>>>>>>>> #address-cells = <2>;
>>>>>>>>> #size-cells = <2>;
>>>>>>>>> ranges;
>>>>>>>>>
>>>>>>>>> jh_inmate@a7f0 {
>>>>>>>>> status = "okay";
>>>>>>>>> no-map;
>>>>>>>>> reg = <0x00 0xa7f0 0x00 0xf00>;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> jailhouse: jailhouse@b6f0 {
>>>>>>>>> status = "okay";
>>>>>>>>> reg = <0x0 0xb6f0 0x0 0x100>;
>>>>>>>>> no-map;
>>>>>>>>> };
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> Linux does report the hole in RAM:
>>>>>>>>>
>>>>>>>>> root@smarc-rzg2l:~# cat /proc/iomem | grep RAM
>>>>>>>>> 4800-a7ef : System RAM
>>>>>>>>> b7
[PATCH] kbuild: Fix rule for building pci_defs.py
From: Jan Kiszka To avoid rebuilding things needlessly after b5a39e1746dc, targets must be maintained. At the same time, we were missing the dependency on the input file in the rule. And that dependency should then not be hard-coded into the generator macro. Signed-off-by: Jan Kiszka --- Kbuild | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Kbuild b/Kbuild index c12f1aef..2258a62c 100644 --- a/Kbuild +++ b/Kbuild @@ -46,14 +46,16 @@ $(GEN_VERSION_H): $(src)/Makefile FORCE quiet_cmd_gen_pci_defs = GEN $@ define cmd_gen_pci_defs - $< $(src)/include/jailhouse/pci_defs.h > $@ + $(filter-out FORCE,$^) > $@ endef GEN_PCI_DEFS_PY := $(obj)/pyjailhouse/pci_defs.py -$(GEN_PCI_DEFS_PY): $(src)/scripts/gen_pci_defs.sh FORCE +$(GEN_PCI_DEFS_PY): $(src)/scripts/gen_pci_defs.sh $(src)/include/jailhouse/pci_defs.h FORCE $(call if_changed,gen_pci_defs) +targets += pyjailhouse/pci_defs.py + subdir-y := hypervisor configs inmates tools obj-m := driver/ -- 2.35.3 -- 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/4372aaef-9f12-d45d-23d5-45e9f2e64fae%40siemens.com.
Re: Kernel panic on enabling root cell
On 12.05.22 13:37, Lad, Prabhakar wrote:
> Hi Jan,
>
> On Thu, May 12, 2022 at 12:16 PM Jan Kiszka wrote:
>>
>> On 12.05.22 13:06, Lad, Prabhakar wrote:
>>> Hi Jan,
>>>
>>> On Thu, May 12, 2022 at 11:24 AM Jan Kiszka wrote:
>>>>
>>>> On 12.05.22 09:01, Lad, Prabhakar wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On Thu, May 12, 2022 at 6:45 AM Jan Kiszka wrote:
>>>>>>
>>>>>> On 11.05.22 19:09, Lad, Prabhakar wrote:
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> On Wed, May 11, 2022 at 4:11 PM Jan Kiszka
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 11.05.22 13:20, Prabhakar Lad wrote:
>>>>>>>>> To add further more details:
>>>>>>>>>
>>>>>>>>> I am using jailhouse-enabling/5.10 Linux branch [0] with -next branch
>>>>>>>>> for jailhouse [1].
>>>>>>>>>
>>>>>>>>> I added some debug prints and I see the panic is caused when entry()
>>>>>>>>> function is called (in enter_hypervisor). The entry function lands
>>>>>>>>> into
>>>>>>>>> assembly code (entry.S). I dont have a JTAG to see which exact
>>>>>>>>> instruction is causing this issue.
>>>>>>>>
>>>>>>>> So, already the first instruction in the loaded hypervisor binary is
>>>>>>>> not
>>>>>>>> executable? That would explain why we see no hypervisor output at all.
>>>>>>>>
>>>>>>> To clarify when the hypervisor is loaded the output will be via
>>>>>>> debug_console specified in the root cell config?
>>>>>>>
>>>>>>
>>>>>> Correct - if you reach entry() in setup.c.
>>>>>>
>>>>>>>> Was that memory region properly reserved from Linux (via DTB carve-out
>>>>>>>> e.g.)?
>>>>>>>>
>>>>>>> Yes I have the below memory reserved in my dts:
>>>>>>>
>>>>>>> memory@4800 {
>>>>>>> device_type = "memory";
>>>>>>> /* first 128MB is reserved for secure area. */
>>>>>>> reg = <0x0 0x4800 0x0 0x7800>;
>>>>>>> };
>>>>>>>
>>>>>>> reserved-memory {
>>>>>>> #address-cells = <2>;
>>>>>>> #size-cells = <2>;
>>>>>>> ranges;
>>>>>>>
>>>>>>> jh_inmate@a7f0 {
>>>>>>> status = "okay";
>>>>>>> no-map;
>>>>>>> reg = <0x00 0xa7f0 0x00 0xf00>;
>>>>>>> };
>>>>>>>
>>>>>>> jailhouse: jailhouse@b6f0 {
>>>>>>> status = "okay";
>>>>>>> reg = <0x0 0xb6f0 0x0 0x100>;
>>>>>>> no-map;
>>>>>>> };
>>>>>>> };
>>>>>>>
>>>>>>> Linux does report the hole in RAM:
>>>>>>>
>>>>>>> root@smarc-rzg2l:~# cat /proc/iomem | grep RAM
>>>>>>> 4800-a7ef : System RAM
>>>>>>> b7f0-bfff : System RAM
>>>>>>>
>>>>>>> And below is my root cell config related to hypervisor memory:
>>>>>>>
>>>>>>> .hypervisor_memory = {
>>>>>>> .phys_start = 0xb6f0,
>>>>>>> .size = 0x100,
>>>>>>> },
>>>>>>>
>>>>>>> Is there anything obvious I have missed above?
>>>>>>>
>>>>>>
>>>>>> Nothing obvious to me so far.
>>>>>>
>>>>>> So, is this really the first instruction in
>>>>>> hypervisor/arch/arm64/entry.S, arch_entry, that triggers the undefinstr?
>>>>>> Check the reported address by Linux against the disassembly of the
>>>>>>
Re: Kernel panic on enabling root cell
On 12.05.22 13:06, Lad, Prabhakar wrote:
> Hi Jan,
>
> On Thu, May 12, 2022 at 11:24 AM Jan Kiszka wrote:
>>
>> On 12.05.22 09:01, Lad, Prabhakar wrote:
>>> Hi Jan,
>>>
>>> On Thu, May 12, 2022 at 6:45 AM Jan Kiszka wrote:
>>>>
>>>> On 11.05.22 19:09, Lad, Prabhakar wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On Wed, May 11, 2022 at 4:11 PM Jan Kiszka wrote:
>>>>>>
>>>>>> On 11.05.22 13:20, Prabhakar Lad wrote:
>>>>>>> To add further more details:
>>>>>>>
>>>>>>> I am using jailhouse-enabling/5.10 Linux branch [0] with -next branch
>>>>>>> for jailhouse [1].
>>>>>>>
>>>>>>> I added some debug prints and I see the panic is caused when entry()
>>>>>>> function is called (in enter_hypervisor). The entry function lands into
>>>>>>> assembly code (entry.S). I dont have a JTAG to see which exact
>>>>>>> instruction is causing this issue.
>>>>>>
>>>>>> So, already the first instruction in the loaded hypervisor binary is not
>>>>>> executable? That would explain why we see no hypervisor output at all.
>>>>>>
>>>>> To clarify when the hypervisor is loaded the output will be via
>>>>> debug_console specified in the root cell config?
>>>>>
>>>>
>>>> Correct - if you reach entry() in setup.c.
>>>>
>>>>>> Was that memory region properly reserved from Linux (via DTB carve-out
>>>>>> e.g.)?
>>>>>>
>>>>> Yes I have the below memory reserved in my dts:
>>>>>
>>>>> memory@4800 {
>>>>> device_type = "memory";
>>>>> /* first 128MB is reserved for secure area. */
>>>>> reg = <0x0 0x4800 0x0 0x7800>;
>>>>> };
>>>>>
>>>>> reserved-memory {
>>>>> #address-cells = <2>;
>>>>> #size-cells = <2>;
>>>>> ranges;
>>>>>
>>>>> jh_inmate@a7f0 {
>>>>> status = "okay";
>>>>> no-map;
>>>>> reg = <0x00 0xa7f0 0x00 0xf00>;
>>>>> };
>>>>>
>>>>> jailhouse: jailhouse@b6f0 {
>>>>> status = "okay";
>>>>> reg = <0x0 0xb6f0 0x0 0x100>;
>>>>> no-map;
>>>>> };
>>>>> };
>>>>>
>>>>> Linux does report the hole in RAM:
>>>>>
>>>>> root@smarc-rzg2l:~# cat /proc/iomem | grep RAM
>>>>> 4800-a7ef : System RAM
>>>>> b7f0-bfff : System RAM
>>>>>
>>>>> And below is my root cell config related to hypervisor memory:
>>>>>
>>>>> .hypervisor_memory = {
>>>>> .phys_start = 0xb6f0,
>>>>> .size = 0x100,
>>>>> },
>>>>>
>>>>> Is there anything obvious I have missed above?
>>>>>
>>>>
>>>> Nothing obvious to me so far.
>>>>
>>>> So, is this really the first instruction in
>>>> hypervisor/arch/arm64/entry.S, arch_entry, that triggers the undefinstr?
>>>> Check the reported address by Linux against the disassembly of the
>>>> hypervisor. You could also play with adding 'ret' as first instruction,
>>>> to check if that returns without a crash.
>>>>
>>> I did play around with ret, below is my observation:
>>>
>>> Up until line 98 [0] just before calling arm_dcaches_flush adding ret
>>> returned without a crash. Adding a ret at line 99 [1] ie after
>>> arm_dcaches_flush it never returned.
>>>
>>> So I continued with adding ret in arm_dcaches_flush, I added ret as a
>>> first statement in arm_dcaches_flush and was able to see the panic!
>>
>> Which Jailhouse revision are you building? Already disassembled
>> hypervisor.o around arch_entry and arm_dcaches_flush? This is what I
>> have here for next:
>>
> I'm using the next branch too.
>
>> c0203efc :
>> c0203efc: d53b0
Re: Kernel panic on enabling root cell
On 12.05.22 09:01, Lad, Prabhakar wrote:
> Hi Jan,
>
> On Thu, May 12, 2022 at 6:45 AM Jan Kiszka wrote:
>>
>> On 11.05.22 19:09, Lad, Prabhakar wrote:
>>> Hi Jan,
>>>
>>> On Wed, May 11, 2022 at 4:11 PM Jan Kiszka wrote:
>>>>
>>>> On 11.05.22 13:20, Prabhakar Lad wrote:
>>>>> To add further more details:
>>>>>
>>>>> I am using jailhouse-enabling/5.10 Linux branch [0] with -next branch
>>>>> for jailhouse [1].
>>>>>
>>>>> I added some debug prints and I see the panic is caused when entry()
>>>>> function is called (in enter_hypervisor). The entry function lands into
>>>>> assembly code (entry.S). I dont have a JTAG to see which exact
>>>>> instruction is causing this issue.
>>>>
>>>> So, already the first instruction in the loaded hypervisor binary is not
>>>> executable? That would explain why we see no hypervisor output at all.
>>>>
>>> To clarify when the hypervisor is loaded the output will be via
>>> debug_console specified in the root cell config?
>>>
>>
>> Correct - if you reach entry() in setup.c.
>>
>>>> Was that memory region properly reserved from Linux (via DTB carve-out
>>>> e.g.)?
>>>>
>>> Yes I have the below memory reserved in my dts:
>>>
>>> memory@4800 {
>>> device_type = "memory";
>>> /* first 128MB is reserved for secure area. */
>>> reg = <0x0 0x4800 0x0 0x7800>;
>>> };
>>>
>>> reserved-memory {
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>> ranges;
>>>
>>> jh_inmate@a7f0 {
>>> status = "okay";
>>> no-map;
>>> reg = <0x00 0xa7f0 0x00 0xf00>;
>>> };
>>>
>>> jailhouse: jailhouse@b6f0 {
>>> status = "okay";
>>> reg = <0x0 0xb6f0 0x0 0x100>;
>>> no-map;
>>> };
>>> };
>>>
>>> Linux does report the hole in RAM:
>>>
>>> root@smarc-rzg2l:~# cat /proc/iomem | grep RAM
>>> 4800-a7ef : System RAM
>>> b7f0-bfff : System RAM
>>>
>>> And below is my root cell config related to hypervisor memory:
>>>
>>> .hypervisor_memory = {
>>> .phys_start = 0xb6f0,
>>> .size = 0x100,
>>> },
>>>
>>> Is there anything obvious I have missed above?
>>>
>>
>> Nothing obvious to me so far.
>>
>> So, is this really the first instruction in
>> hypervisor/arch/arm64/entry.S, arch_entry, that triggers the undefinstr?
>> Check the reported address by Linux against the disassembly of the
>> hypervisor. You could also play with adding 'ret' as first instruction,
>> to check if that returns without a crash.
>>
> I did play around with ret, below is my observation:
>
> Up until line 98 [0] just before calling arm_dcaches_flush adding ret
> returned without a crash. Adding a ret at line 99 [1] ie after
> arm_dcaches_flush it never returned.
>
> So I continued with adding ret in arm_dcaches_flush, I added ret as a
> first statement in arm_dcaches_flush and was able to see the panic!
Which Jailhouse revision are you building? Already disassembled
hypervisor.o around arch_entry and arm_dcaches_flush? This is what I
have here for next:
c0203efc :
c0203efc: d53b0024mrs x4, ctr_el0
c0203f00: d3504c84ubfxx4, x4, #16, #4
...
c0204800 :
c0204800: aa0003f0mov x16, x0
c0204804: aa1e03f1mov x17, x30
...
c0204844: d2800042mov x2, #0x2
// #2
c0204848: 97fffdadbl c0203efc
You could check if there is such a relative call in your case as well.
Then you could check, before jumping into arch_entry from the
hypervisor, that the opcode at the actual arm_dcaches_flush address is
as expected. But maybe already the building injects an issue here.
Jan
--
Siemens AG, Technology
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/fe2e7e92-8530-9913-307f-85437412fd81%40siemens.com.
Re: Kernel panic on enabling root cell
On 11.05.22 19:09, Lad, Prabhakar wrote:
> Hi Jan,
>
> On Wed, May 11, 2022 at 4:11 PM Jan Kiszka wrote:
>>
>> On 11.05.22 13:20, Prabhakar Lad wrote:
>>> To add further more details:
>>>
>>> I am using jailhouse-enabling/5.10 Linux branch [0] with -next branch
>>> for jailhouse [1].
>>>
>>> I added some debug prints and I see the panic is caused when entry()
>>> function is called (in enter_hypervisor). The entry function lands into
>>> assembly code (entry.S). I dont have a JTAG to see which exact
>>> instruction is causing this issue.
>>
>> So, already the first instruction in the loaded hypervisor binary is not
>> executable? That would explain why we see no hypervisor output at all.
>>
> To clarify when the hypervisor is loaded the output will be via
> debug_console specified in the root cell config?
>
Correct - if you reach entry() in setup.c.
>> Was that memory region properly reserved from Linux (via DTB carve-out
>> e.g.)?
>>
> Yes I have the below memory reserved in my dts:
>
> memory@4800 {
> device_type = "memory";
> /* first 128MB is reserved for secure area. */
> reg = <0x0 0x4800 0x0 0x7800>;
> };
>
> reserved-memory {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> jh_inmate@a7f0 {
> status = "okay";
> no-map;
> reg = <0x00 0xa7f0 0x00 0xf00>;
> };
>
> jailhouse: jailhouse@b6f0 {
> status = "okay";
> reg = <0x0 0xb6f0 0x0 0x100>;
> no-map;
> };
> };
>
> Linux does report the hole in RAM:
>
> root@smarc-rzg2l:~# cat /proc/iomem | grep RAM
> 4800-a7ef : System RAM
> b7f0-bfff : System RAM
>
> And below is my root cell config related to hypervisor memory:
>
> .hypervisor_memory = {
> .phys_start = 0xb6f0,
> .size = 0x100,
> },
>
> Is there anything obvious I have missed above?
>
Nothing obvious to me so far.
So, is this really the first instruction in
hypervisor/arch/arm64/entry.S, arch_entry, that triggers the undefinstr?
Check the reported address by Linux against the disassambly of the
hypervisor. You could also play with adding 'ret' as first instruction,
to check if that returns without a crash.
Jan
--
Siemens AG, Technology
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/37be2e7c-c1f4-c5b6-f200-8d1cc48e0ee5%40siemens.com.
Re: Jailhouse over ZCU-104
On 11.05.22 17:02, Daniele Ottaviano wrote:
>
> Hi, thank you for your reply.
> I prefer, if possible, to use petalinux as a baseline to test also other
> mechanisms such as OpenAMP and kernel configurations such as the Linux
> Preempt-RT patch.
> Anyway, you were right, there was a problem in the petalinux build that
> luckily I managed to resolve. Now I'm able to boot the system but when I
> try to enable jailhouse I have the following error:
>
> root@xilinx-zcu104-2019_1:~# jailhouse enable /zynqmp-zcu104-root.cell
>
> Initializing Jailhouse hypervisor v0.12 on CPU 3
> Code location: 0xc0200800
> Page pool usage after early setup: mem 39/994, remap 0/131072
> Initializing processors:
> CPU 3... OK
> CPU 1... OK
> CPU 0... OK
> CPU 2... OK
> Initializing unit: irqchip
> Initializing unit: ARM SMMU v3
> Initializing unit: PVU IOMMU
> Initializing unit: PCI
> Adding virtual PCI device 00:00.0 to cell "ZCU104-root"
> /home/user/jailhouse/hypervisor/ivshmem.c:407: returning error -EINVAL
> JAILHOUSE_ENABLE: Invalid argument
>
> I used a configuration file for zcu104 that I found in a mailing list
> conversation
> https://groups.google.com/g/jailhouse-dev/c/vMTEE3pYyPg/m/UeeqcdOhBgAJ
> (It is a modified version of the Ultra96 file):
> /*
> * Configuration for the ZCU104 root cell. Copied from ultra96.c
> * and changed where necessary.
> */
>
> #include
> #include
>
> struct {
> struct jailhouse_system header;
> __u64 cpus[1];
> struct jailhouse_memory mem_regions[3];
> struct jailhouse_irqchip irqchips[1];
> struct jailhouse_pci_device pci_devices[1];
> } __attribute__((packed)) config = {
> .header = {
> .signature = JAILHOUSE_SYSTEM_SIGNATURE,
> .revision = JAILHOUSE_CONFIG_REVISION,
> .flags = JAILHOUSE_SYS_VIRTUAL_DEBUG_CONSOLE,
> .hypervisor_memory = {
> .phys_start = 0x7fc0,
> .size = 0x0040,
> },
> .debug_console = {
> .address = 0xff00,
> .size = 0x1000,
> .type = JAILHOUSE_CON_TYPE_XUARTPS,
> .flags = JAILHOUSE_CON_ACCESS_MMIO |
> JAILHOUSE_CON_REGDIST_4,
> },
> .platform_info = {
> .pci_mmconfig_base = 0xfc00,
> .pci_mmconfig_end_bus = 0,
> .pci_is_virtual = 1,
> .arm = {
> .gic_version = 2,
> .gicd_base = 0xf901, /*GIC distributor register base*/
> .gicc_base = 0xf902f000, /*GIC cpu interface register base*/
> .gich_base = 0xf904, /*GIC virtual interface control
> register base*/
> .gicv_base = 0xf906f000, /*GIC virtual cpu interface
> register base*/
> .maintenance_irq = 25,
> },
> },
> .root_cell = {
> .name = "ZCU104-root",
>
> .cpu_set_size = sizeof(config.cpus),
> .num_memory_regions = ARRAY_SIZE(config.mem_regions),
> .num_irqchips = ARRAY_SIZE(config.irqchips),
> .num_pci_devices = ARRAY_SIZE(config.pci_devices),
>
> .vpci_irq_base = 136-32,
> },
> },
>
> .cpus = {
> 0xf,
> },
>
> .mem_regions = {
> /* MMIO (permissive) */ {
> .phys_start = 0xfd00,
> .virt_start = 0xfd00,
> .size = 0x0300,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_IO,
> },
> /* RAM */ {
> .phys_start = 0x,
> .virt_start = 0x,
> .size = 0x7fb0,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_EXECUTE,
> },
> /* IVSHMEM shared memory region for 00:00.0 */ {
> .phys_start = 0x7fb0,
> .virt_start = 0x7fb0,
> .size = 0x0010,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
> },
You need more ivshmem regions here. See other ivshmem-enabled configs.
Jan
--
Siemens AG, Technology
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/629dbc73-e149-3e2d-0181-fcad1ee4b9d3%40siemens.com.
Re: Kernel panic on enabling root cell
On 11.05.22 13:20, Prabhakar Lad wrote: > To add further more details: > > I am using jailhouse-enabling/5.10 Linux branch [0] with -next branch > for jailhouse [1]. > > I added some debug prints and I see the panic is caused when entry() > function is called (in enter_hypervisor). The entry function lands into > assembly code (entry.S). I dont have a JTAG to see which exact > instruction is causing this issue. So, already the first instruction in the loaded hypervisor binary is not executable? That would explain why we see no hypervisor output at all. Was that memory region properly reserved from Linux (via DTB carve-out e.g.)? Jan -- Siemens AG, Technology 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/d22051fb-2c80-2d88-af8c-5f1ccdb69197%40siemens.com.
Re: Jailhouse 0.12 on i.MX8MQ EVK
On 11.05.22 09:16, vsun...@gmail.com wrote: > Hi All, > > I am building jailhouse 0.12 on kernel 5.4.147 i.MX8, but its failing > with below logs. I could successfully build jailhouse 0.11 on the same > kernel. Any suggestions on this, does 0.12 version support i.MX8? > > /*vipulkumar@A812DBLR:~/platform/AGL_lamprey/build$ bitbake -k > agl-demo-platform*/ > Are you using an AGL-provided integration here? Anyway, maybe Peng can provide guidance here. Jan -- Siemens AG, Technology 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/e4196998-4979-c4f8-bc45-52f0499a8033%40siemens.com.
Re: Jailhouse over ZCU-104
On 10.05.22 16:07, Daniele Ottaviano wrote: > Hi, > I'm trying to run Jailhouse over Zynq Ultrascale+ ZCU104. I have found a > guide showing the setup for ZCU102 but it doesn't work for me: > https://github.com/siemens/jailhouse/blob/master/Documentation/setup-on-zynqmp-zcu102.md > > > First I tried to compile jailhouse on a build created with petalinux > 2022 but it fails. > So I decided to use the old release of petalinux 2019.1 because it works > according to this guide: > https://www.erika-enterprise.com/wiki/index.php/Xilinx_ZCU102#Setup_of_the_GNU_Compiler_for_aarch64. > > In this case, I'm able to compile Jailhouse but when I start the board > the process stops at boot time. Before even enabling Jailhouse? Then it's a Petalinux topic, I assume. > > Has anyone successfully ported Jailhouse to zcu104 yet? Conceptually, it should be close to the Ultra96, thus the integration done in jailhouse-images - unless you really want or have to use petalinux as baseline. But even then, looking at configs can be helpful. Jan -- Siemens AG, Technology 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/9a81cc8e-3064-cad8-b66f-0711c2705111%40siemens.com.
Re: Linux and u-boot requirements
On 03.05.22 20:42, Lad, Prabhakar wrote: > Hi Jan, > > On Tue, May 3, 2022 at 11:47 AM Lad, Prabhakar > wrote: >> >> Hi Jan, >> >> On Mon, May 2, 2022 at 9:30 PM Jan Kiszka wrote: >>> >>> Hi Prabhakar, hi Chris, >>> >>> ok, now I understand your question last Thursday, Chris... ;) >>> >>> On 02.05.22 21:37, Lad, Prabhakar wrote: >>>> Hi Jan, >>>> >>>> On Mon, May 2, 2022 at 5:13 PM Jan Kiszka wrote: >>>>> >>>>> On 27.04.22 15:19, Prabhakar Lad wrote: >>>>>> Hi All, >>>>>> >>>>>> I recently tried to build the v0.12 tag with the upstream kernel >>>>>> (v5.18-rc4) for emconrzg1h, but the build failed due to api changes >>>>>> (cpu_up/cpu_down mainly). >>>>> >>>>> You want to use master or even next for very recent kernels. I haven't >>>>> done a release in a too-long-while, so patches to account for kernel >>>>> changes can only be found there. >>>>> >>>> I see. I came across the linux [0] tree which has >>>> jailhouse-enabling/x.x branches. Is this a good starting point for >>>> Linux? These branches merge Linux releases into the jailhouse kernel >>>> which makes it a bit difficult to track the changes specifically made >>>> to jailhouse. For example, for the 4.19 branch it's currently on >>>> v4.19.81 whereas I plan to work on 4.19.198 which makes porting things >>>> a bit difficult. >>> >>> Not at all: >>> >>> git log --no-merges --oneline v4.19.81..jailhouse-enabling/4.19 >>> >> Thanks for the hint. >> >>> The 4.19 branch was retired a while ago, so rebasing over latest stable >>> or merging that in would definitely be recommended. Actually, you likely >>> want to check the latest enabling branch or [1] for updates since 4.19 >>> was retired. >>> >> Great, I'll start with the latest enabling branch which you pointed to >> and use it with the v0.12 release (I'll have to port my platform to >> this though). And then later I consider either 5.10/4.19 kernel. >> >>>> >>>>>> >>>>>> So I wanted to check what are the strict requirements for Linux and >>>>>> u-boot as I plan to add new arm64 platform. >>>>>> >>>>>> Also is there any document/link that I can refer to porting on new >>>>>> platform? >>>>> >>>>> No written documents, but if you follow the commit history of >>>>> https://github.com/siemens/jailhouse-images you can see how new targets >>>>> were hooked up there (mostly Jailhouse-unrelated integration work). >>>>> Jailhouse also does not depend on U-Boot, first of all only a working >>>>> Linux / firmware integration, ideally from upstream. >>>>> > I followed the jailhouse-images repo with the master branch and > started with Linux first. For Linux it uses the > jailhouse-enabling/5.10 branch [1] (commit id: > eb6927f7eea77f823b96c0c22ad9d4a2d7ffdfce). In this kernel version the > cpu_up/down api are static [2] due to which the build of jailhouse > 0.12 is failing ( I tried to build for zynq platform just wanted to > make sure build passes before porting my platform) > > I looked at the kernel recipe and there aren't any patches which > exports cpu_up/down api and nor do I see any patch in > jailhouse_0.12.bb [3] which drops cpu_up/down api. Is there anything > I'm missing here? > https://github.com/siemens/jailhouse-images/commit/64c102a9df6f713170129ac0e8f7c94927a8592e Jan > [0] > https://github.com/siemens/jailhouse-images/blob/master/recipes-kernel/linux/linux-jailhouse_5.10.inc#L17 > [1] https://github.com/siemens/linux/tree/jailhouse-enabling/5.10 > [2] > https://github.com/siemens/linux/blob/jailhouse-enabling/5.10/kernel/cpu.c#L1253 > [3] > https://github.com/siemens/jailhouse-images/blob/master/recipes-jailhouse/jailhouse/jailhouse_0.12.bb > > > Cheers, > Prabhakar -- Siemens AG, Technology 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/e4e83117-c094-0bec-40f6-627ab1dcd776%40siemens.com.
Re: Linux and u-boot requirements
Hi Prabhakar, hi Chris, ok, now I understand your question last Thursday, Chris... ;) On 02.05.22 21:37, Lad, Prabhakar wrote: > Hi Jan, > > On Mon, May 2, 2022 at 5:13 PM Jan Kiszka wrote: >> >> On 27.04.22 15:19, Prabhakar Lad wrote: >>> Hi All, >>> >>> I recently tried to build the v0.12 tag with the upstream kernel >>> (v5.18-rc4) for emconrzg1h, but the build failed due to api changes >>> (cpu_up/cpu_down mainly). >> >> You want to use master or even next for very recent kernels. I haven't >> done a release in a too-long-while, so patches to account for kernel >> changes can only be found there. >> > I see. I came across the linux [0] tree which has > jailhouse-enabling/x.x branches. Is this a good starting point for > Linux? These branches merge Linux releases into the jailhouse kernel > which makes it a bit difficult to track the changes specifically made > to jailhouse. For example, for the 4.19 branch it's currently on > v4.19.81 whereas I plan to work on 4.19.198 which makes porting things > a bit difficult. Not at all: git log --no-merges --oneline v4.19.81..jailhouse-enabling/4.19 The 4.19 branch was retired a while ago, so rebasing over latest stable or merging that in would definitely be recommended. Actually, you likely want to check the latest enabling branch or [1] for updates since 4.19 was retired. > >>> >>> So I wanted to check what are the strict requirements for Linux and >>> u-boot as I plan to add new arm64 platform. >>> >>> Also is there any document/link that I can refer to porting on new platform? >> >> No written documents, but if you follow the commit history of >> https://github.com/siemens/jailhouse-images you can see how new targets >> were hooked up there (mostly Jailhouse-unrelated integration work). >> Jailhouse also does not depend on U-Boot, first of all only a working >> Linux / firmware integration, ideally from upstream. >> > I see the tf-a and u-boot do point to upstream with some tiny patches. > For example, for xilinx SDEI is enabled in TF-A. Is this required? > (I'm still reading through the docs so this nooby question!) SDEI is an optimization for interrupt delivery. Not needed, just faster. > >> Which SoC are you targeting? >> > My plan is to start with the Renesas RZ/V2L SoC (cortex a55 with > gic-v3), but will soon switch over to the Renesas RZ/G2M SoC (cortex > a57 with gic-400). > I see. The key steps in enabling will be - getting the patches applied to a tree that supports your board - writing a simple config (there is no "config create" on ARM, but you can more easily start with passing everything through) - jailhhouse config check - debugging remaining violations when starting Jailhouse - writing/adjusting non-root cell configs (for the pattern of recent enablings) Jan [1] https://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/jailhouse -- Siemens AG, Technology 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/aebdee8e-4074-b223-2cbe-42564624e7f6%40siemens.com.
Re: Linux and u-boot requirements
On 27.04.22 15:19, Prabhakar Lad wrote: > Hi All, > > I recently tried to build the v0.12 tag with the upstream kernel > (v5.18-rc4) for emconrzg1h, but the build failed due to api changes > (cpu_up/cpu_down mainly). You want to use master or even next for very recent kernels. I haven't done a release in a too-long-while, so patches to account for kernel changes can only be found there. > > So I wanted to check what are the strict requirements for Linux and > u-boot as I plan to add new arm64 platform. > > Also is there any document/link that I can refer to porting on new platform? No written documents, but if you follow the commit history of https://github.com/siemens/jailhouse-images you can see how new targets were hooked up there (mostly Jailhouse-unrelated integration work). Jailhouse also does not depend on U-Boot, first of all only a working Linux / firmware integration, ideally from upstream. Which SoC are you targeting? Jan -- Siemens AG, Technology 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/b7c5f1aa-e91c-3a9b-b74c-2255184d66a5%40siemens.com.
Re: [PATCH v2] driver: sysfs: Add compatibility for default_groups
On 27.04.22 20:18, Ralf Ramsauer wrote:
> Since Linux commit cdb4f26a63c3 ("kobject: kobj_type: remove
> default_attrs"), the deprecated kobj member default_attrs is gone. It is
> replaced by default_groups.
>
> Add a compatibility layer to support older, as well as latest kernel
> versions.
>
> Signed-off-by: Ralf Ramsauer
> ---
>
> Note: only compile-time tested!
>
> driver/sysfs.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/driver/sysfs.c b/driver/sysfs.c
> index a604afa4..a5a02831 100644
> --- a/driver/sysfs.c
> +++ b/driver/sysfs.c
> @@ -59,6 +59,14 @@ static const struct sysfs_ops cell_sysfs_ops = {
> };
> #define kobj_sysfs_ops cell_sysfs_ops
> #endif /* < 3.14 */
> +
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(5,2,0)
> +#define COMPAT_ATTRIBUTE_GROUPS(x) /* not used */
> +#define DEFAULT_GROUPS(x).default_attrs = x##_attrs
> +#else
> +#define COMPAT_ATTRIBUTE_GROUPS(x) ATTRIBUTE_GROUPS(x)
> +#define DEFAULT_GROUPS(x).default_groups = x##_groups
> +#endif /* < 5.2 */
> /* End of compatibility section - remove as version become obsolete */
>
> static struct kobject *cells_dir;
> @@ -180,10 +188,11 @@ static struct attribute *cell_stats_attrs[] = {
> #endif
> NULL
> };
> +COMPAT_ATTRIBUTE_GROUPS(cell_stats);
>
> static struct kobj_type cell_stats_type = {
> .sysfs_ops = _sysfs_ops,
> - .default_attrs = cell_stats_attrs,
> + DEFAULT_GROUPS(cell_stats),
> };
>
> static struct attribute *cpu_stats_attrs[] = {
> @@ -212,10 +221,11 @@ static struct attribute *cpu_stats_attrs[] = {
> #endif
> NULL
> };
> +COMPAT_ATTRIBUTE_GROUPS(cpu_stats);
>
> static struct kobj_type cell_cpu_type = {
> .sysfs_ops = _sysfs_ops,
> - .default_attrs = cpu_stats_attrs,
> + DEFAULT_GROUPS(cpu_stats),
> };
>
> static int print_cpumask(char *buf, size_t size, cpumask_t *mask, bool
> as_list)
> @@ -342,11 +352,12 @@ static struct attribute *cell_attrs[] = {
> _cpus_failed_list_attr.attr,
> NULL,
> };
> +COMPAT_ATTRIBUTE_GROUPS(cell);
>
> static struct kobj_type cell_type = {
> .release = jailhouse_cell_kobj_release,
> .sysfs_ops = _sysfs_ops,
> - .default_attrs = cell_attrs,
> + DEFAULT_GROUPS(cell),
> };
>
> static struct cell_cpu *find_cell_cpu(struct cell *cell, unsigned int cpu)
Thanks, applied.
Jan
--
Siemens AG, Technology
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/7a0052db-13ef-4b72-f0e2-50832146a374%40siemens.com.
Re: [EXT] Re: [PATCH] driver: sysfs: Replace default_attrs with default_groups
On 27.04.22 18:13, Ralf Ramsauer wrote:
>
>
> On 27/04/2022 08:26, Jan Kiszka wrote:
>> On 26.04.22 19:22, Ralf Ramsauer wrote:
>>> Since Linux commit cdb4f26a63c3 ("kobject: kobj_type: remove
>>> default_attrs"), the deprecated kobj member default_attrs is gone. It is
>>> replaced by default_groups.
>>>
>>> default_groups is available since 2013, so simply switch to
>>> default_groups, without (hopefully) breaking any older kernel.
>>>
>>> Signed-off-by: Ralf Ramsauer
>>> ---
>>> driver/sysfs.c | 9 ++---
>>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/driver/sysfs.c b/driver/sysfs.c
>>> index a604afa4..f91d5ac5 100644
>>> --- a/driver/sysfs.c
>>> +++ b/driver/sysfs.c
>>> @@ -180,10 +180,11 @@ static struct attribute *cell_stats_attrs[] = {
>>> #endif
>>> NULL
>>> };
>>> +ATTRIBUTE_GROUPS(cell_stats);
>>> static struct kobj_type cell_stats_type = {
>>> .sysfs_ops = _sysfs_ops,
>>> - .default_attrs = cell_stats_attrs,
>>> + .default_groups = cell_stats_groups,
>>> };
>>> static struct attribute *cpu_stats_attrs[] = {
>>> @@ -212,10 +213,11 @@ static struct attribute *cpu_stats_attrs[] = {
>>> #endif
>>> NULL
>>> };
>>> +ATTRIBUTE_GROUPS(cpu_stats);
>>> static struct kobj_type cell_cpu_type = {
>>> .sysfs_ops = _sysfs_ops,
>>> - .default_attrs = cpu_stats_attrs,
>>> + .default_groups = cpu_stats_groups,
>>> };
>>> static int print_cpumask(char *buf, size_t size, cpumask_t *mask,
>>> bool as_list)
>>> @@ -342,11 +344,12 @@ static struct attribute *cell_attrs[] = {
>>> _cpus_failed_list_attr.attr,
>>> NULL,
>>> };
>>> +ATTRIBUTE_GROUPS(cell);
>>> static struct kobj_type cell_type = {
>>> .release = jailhouse_cell_kobj_release,
>>> .sysfs_ops = _sysfs_ops,
>>> - .default_attrs = cell_attrs,
>>> + .default_groups = cell_groups,
>>> };
>>> static struct cell_cpu *find_cell_cpu(struct cell *cell, unsigned
>>> int cpu)
>>
>> Which kernel versions are compatible with the new API?
>
> With the latest v5.18 release, it becomes mandatory.
>
> I just successfully compile-tested v5.17, v5.16, v5.14, v5.10, v5.4 and
> v5.2 (the latest one that works). Latest LTS 4.19.y and downwards won't
> compile.
>
> The question is, if we want to demand at least v5.2, or introduce yet
> another workaround.
I think wrapping could be fairly simple in this case, and 4.19 may still
be used, and we actually wrap much further down, let's account for this
difference once again.
Jan
--
Siemens AG, Technology
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/179b997b-4830-fb3b-792d-79c25fb39788%40siemens.com.
Re: [PATCH] configs: arm64: add support initial support for AM625 Starter Kit platform
On 27.04.22 12:58, Matt Ranostay wrote: > On Wed, Apr 27, 2022 at 08:34:11AM +0200, Jan Kiszka wrote: >> On 27.04.22 04:54, 'Matt Ranostay' via Jailhouse wrote: >>> Add support for TI AM625 Starter Kit platform along with eMMC and non-eMMC >>> Linux inmate cell configurations. >>> >>> Signed-off-by: Matt Ranostay >>> --- >>> configs/arm64/dts/inmate-k3-am625-sk-emmc.dts | 28 ++ >>> configs/arm64/dts/inmate-k3-am625-sk.dts | 163 + >>> configs/arm64/k3-am625-inmate-demo.c | 72 >>> configs/arm64/k3-am625-sk-linux-demo.c| 220 >>> configs/arm64/k3-am625-sk.c | 317 ++ >>> 5 files changed, 800 insertions(+) >>> create mode 100644 configs/arm64/dts/inmate-k3-am625-sk-emmc.dts >>> create mode 100644 configs/arm64/dts/inmate-k3-am625-sk.dts >>> create mode 100644 configs/arm64/k3-am625-inmate-demo.c >> >> Why k3-am625-inmate-demo, rather than k3-am625-sk-inmate-demo? It's >> k3-am625-sk-linux-demo as well. Or is the inmate-demo not specific to >> the Starter Kit while the linux-demo is? >> > > No, it is and should have the sk in the file name. That was a oversight on my > part. > Should I send another revision, or will you rename it in your merge? > I've renamed it, result in next. Thanks, Jan -- Siemens AG, Technology 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/a538954f-de81-4585-90a0-d0b82921e782%40siemens.com.
Re: [PATCH] configs: arm64: add support initial support for AM625 Starter Kit platform
On 27.04.22 04:54, 'Matt Ranostay' via Jailhouse wrote: > Add support for TI AM625 Starter Kit platform along with eMMC and non-eMMC > Linux inmate cell configurations. > > Signed-off-by: Matt Ranostay > --- > configs/arm64/dts/inmate-k3-am625-sk-emmc.dts | 28 ++ > configs/arm64/dts/inmate-k3-am625-sk.dts | 163 + > configs/arm64/k3-am625-inmate-demo.c | 72 > configs/arm64/k3-am625-sk-linux-demo.c| 220 > configs/arm64/k3-am625-sk.c | 317 ++ > 5 files changed, 800 insertions(+) > create mode 100644 configs/arm64/dts/inmate-k3-am625-sk-emmc.dts > create mode 100644 configs/arm64/dts/inmate-k3-am625-sk.dts > create mode 100644 configs/arm64/k3-am625-inmate-demo.c Why k3-am625-inmate-demo, rather than k3-am625-sk-inmate-demo? It's k3-am625-sk-linux-demo as well. Or is the inmate-demo not specific to the Starter Kit while the linux-demo is? Rest looks good. Jan -- Siemens AG, Technology 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/5473ee5e-1891-dd00-db28-388dad40ee02%40siemens.com.
Re: [PATCH] driver: sysfs: Replace default_attrs with default_groups
On 26.04.22 19:22, Ralf Ramsauer wrote:
> Since Linux commit cdb4f26a63c3 ("kobject: kobj_type: remove
> default_attrs"), the deprecated kobj member default_attrs is gone. It is
> replaced by default_groups.
>
> default_groups is available since 2013, so simply switch to
> default_groups, without (hopefully) breaking any older kernel.
>
> Signed-off-by: Ralf Ramsauer
> ---
> driver/sysfs.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/driver/sysfs.c b/driver/sysfs.c
> index a604afa4..f91d5ac5 100644
> --- a/driver/sysfs.c
> +++ b/driver/sysfs.c
> @@ -180,10 +180,11 @@ static struct attribute *cell_stats_attrs[] = {
> #endif
> NULL
> };
> +ATTRIBUTE_GROUPS(cell_stats);
>
> static struct kobj_type cell_stats_type = {
> .sysfs_ops = _sysfs_ops,
> - .default_attrs = cell_stats_attrs,
> + .default_groups = cell_stats_groups,
> };
>
> static struct attribute *cpu_stats_attrs[] = {
> @@ -212,10 +213,11 @@ static struct attribute *cpu_stats_attrs[] = {
> #endif
> NULL
> };
> +ATTRIBUTE_GROUPS(cpu_stats);
>
> static struct kobj_type cell_cpu_type = {
> .sysfs_ops = _sysfs_ops,
> - .default_attrs = cpu_stats_attrs,
> + .default_groups = cpu_stats_groups,
> };
>
> static int print_cpumask(char *buf, size_t size, cpumask_t *mask, bool
> as_list)
> @@ -342,11 +344,12 @@ static struct attribute *cell_attrs[] = {
> _cpus_failed_list_attr.attr,
> NULL,
> };
> +ATTRIBUTE_GROUPS(cell);
>
> static struct kobj_type cell_type = {
> .release = jailhouse_cell_kobj_release,
> .sysfs_ops = _sysfs_ops,
> - .default_attrs = cell_attrs,
> + .default_groups = cell_groups,
> };
>
> static struct cell_cpu *find_cell_cpu(struct cell *cell, unsigned int cpu)
Which kernel versions are compatible with the new API?
Jan
--
Siemens AG, Technology
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/c2c4c771-6772-9511-4b47-49e2473d5531%40siemens.com.
Re: Jailhouse isolation test case
On 21.04.22 17:25, Jean de Bonfils wrote: > Hi everyone, > I am looking for scenarios/test cases that demonstrate isolation between > cells. > For example, test cases that demonstrates that an inmate can't access > peripheral devices it is not supposed to have access to or that it can't > read memory of another cell > Do you know where I can find this? > There are no specific tests in-tree at least. You can surely build some, e.g. on top of the QEMU integration available via jailhouse-images. Jan -- Siemens AG, Technology 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/06be1523-f4a2-80a1-a304-a76ea4e7bba6%40siemens.com.
Re: Kernel crash after exiting from enter_hypervisor
On 13.04.22 13:44, manliang tang wrote: > Based on Kernel 4.19, I tried to run Jailhouse on real ARM board. I > build the driver/firmware/tool/configuration file successfully, copy all > these files to ARM board, then set the bootargs(mem=) and inert the > driver module. I saw the Kernel crash when run the "jailhouse enable" > command. > 1. command > /data # insmod jailhouse.ko > /data # cp jailhouse.bin /lib/firmware/ > /data # ./jailhouse enable aml-c2.cell > > 2. Attached is the detailed log > The crash does not directly point to Jailhouse on first sight. Seems like some callback in ipv6_dev_get_saddr() is pointing to NULL, and the kernel tries to invoke it. Or do you have CONFIG_CRASH_CELL_ON_PANIC defined? I'm missing the output of Jailhouse itself. If it detects a violation and injects such a crash, that may explain the NULL as well. Jan -- Siemens AG, Technology 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/3c1ce5d2-fb60-a7eb-82df-5466e1320f92%40siemens.com.
Re: Cache coherency with the Linux and Inmate
On 12.04.22 12:18, Andreas Orfanos wrote: > Hello, > > I would like to use a shared memory region between an inmate and the > Linux in a way that is coherent. The memory region is a memory pool > partitioned to provide memory blocks to inmates and to the Linux > processes that have mmap'ed the region. The Linux process allocate > blocks of memory from that region for local data processing, and then > indicate to the inmate that a block of data is ready for further > processing. The inmate takes the indication and access the shared memory > block with a cookie to continue further processing on the block. > > I would like to keep cache coherent between the inmate and the Linux but > not sure if that would work in Jail house. Do I have to clean and > invalidate the cache from Linux all the time when I pass the processing > to the inmate? I am using a Xilinx SoC with a cluster of 4xCrotex A-53 Shared memory you configure between cells is just like shared memory between processing in the same cell - cache coherency is ensured. Just follow the existing examples for ivshmem devices. Jan -- Siemens AG, Technology 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/416c28fd-5904-0b77-ede8-da1199c27df8%40siemens.com.
Re: [PATCH v4] configs: arm64: add emmc inmate configuration for k3-am654-idk
On 14.03.22 16:22, 'Matt Ranostay' via Jailhouse wrote:
> Add eMMC support for k3-am654-idk in a linux inmate cell using
> CONFIG_AM654_INMATE_CELL_EMMC macro, and respective device tree
> changes.
>
> Signed-off-by: Matt Ranostay
> ---
>
> Changes from v1:
> * Split out eMMC enablement to its own inmate configuration
>
> Changes from v2:
> * Recombined eMMC enablement to one configuration that is enabled
> with ENABLE_INMATE_CELL_EMMC define
> * Dropped patches that were already merged
>
> Changes from v3:
> * Rename ENABLE_INMATE_CELL_EMMC to CONFIG_AM654_INMATE_CELL_EMMC
>
> .../arm64/dts/inmate-k3-am654-idk-emmc.dts| 45 +++
> configs/arm64/k3-am654-idk-linux-demo.c | 22 -
> 2 files changed, 66 insertions(+), 1 deletion(-)
> create mode 100644 configs/arm64/dts/inmate-k3-am654-idk-emmc.dts
>
> diff --git a/configs/arm64/dts/inmate-k3-am654-idk-emmc.dts
> b/configs/arm64/dts/inmate-k3-am654-idk-emmc.dts
> new file mode 100644
> index ..150e31fe
> --- /dev/null
> +++ b/configs/arm64/dts/inmate-k3-am654-idk-emmc.dts
> @@ -0,0 +1,45 @@
> +/dts-v1/;
> +
> +#include "inmate-k3-am654-idk.dts"
> +
> +/ {
> + sdhci0: mmc@4f8 {
> + compatible = "ti,am654-sdhci-5.1";
> + reg = <0x0 0x4f8 0x0 0x260>, <0x0 0x4f9 0x0 0x134>;
> + power-domains = <_pds 47 1>;
> + clocks = <_clks 47 0>, <_clks 47 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + interrupts = ;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + ti,otap-del-sel-legacy = <0x0>;
> + ti,otap-del-sel-mmc-hs = <0x0>;
> + ti,otap-del-sel-sd-hs = <0x0>;
> + ti,otap-del-sel-sdr12 = <0x0>;
> + ti,otap-del-sel-sdr25 = <0x0>;
> + ti,otap-del-sel-sdr50 = <0x8>;
> + ti,otap-del-sel-sdr104 = <0x7>;
> + ti,otap-del-sel-ddr50 = <0x5>;
> + ti,otap-del-sel-ddr52 = <0x5>;
> + ti,otap-del-sel-hs200 = <0x5>;
> + ti,otap-del-sel-hs400 = <0x0>;
> + ti,trm-icp = <0x8>;
> + dma-coherent;
> + };
> +};
> +
> +_uart0 {
> + power-domains = <_pds 149 1>;
> +};
> +
> +_pds {
> + #power-domain-cells = <2>;
> +};
> +
> + {
> + /* eMMC */
> + non-removable;
> + ti,driver-strength-ohm = <50>;
> + bus-width = <8>;
> + disable-wp;
> +};
> diff --git a/configs/arm64/k3-am654-idk-linux-demo.c
> b/configs/arm64/k3-am654-idk-linux-demo.c
> index fdf5fea8..3937dff3 100644
> --- a/configs/arm64/k3-am654-idk-linux-demo.c
> +++ b/configs/arm64/k3-am654-idk-linux-demo.c
> @@ -23,7 +23,7 @@
> struct {
> struct jailhouse_cell_desc cell;
> __u64 cpus[1];
> - struct jailhouse_memory mem_regions[17];
> + struct jailhouse_memory mem_regions[19];
> struct jailhouse_irqchip irqchips[3];
> struct jailhouse_pci_device pci_devices[2];
> } __attribute__((packed)) config = {
> @@ -112,6 +112,22 @@ struct {
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_IO,
> },
> +#ifdef CONFIG_AM654_INMATE_CELL_EMMC
> + /* sdhci0 */ {
> + .phys_start = 0x4f8,
> + .virt_start = 0x4f8,
> + .size = 0x1000,
> + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> + JAILHOUSE_MEM_IO,
> + },
> + /* sdhci0 */ {
> + .phys_start = 0x4f9,
> + .virt_start = 0x4f9,
> + .size = 0x1000,
> + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> + JAILHOUSE_MEM_IO,
> + },
> +#endif
> /* main sproxy target_data host_id=A53_3 */ {
> .phys_start = 0x3240f000,
> .virt_start = 0x3240f000,
> @@ -153,6 +169,10 @@ struct {
> .address = 0x0180,
> .pin_base = 160,
> .pin_bitmap = {
> +#ifdef CONFIG_AM654_INMATE_CELL_EMMC
> + /* sdhc */
> + 1 << (168 - 160) |
> +#endif
> /* vpci */
> 1 << (189 - 160) |
> 1 << (190 - 160),
Thanks, applied.
Jan
--
Siemens AG, Technology
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/4b4ef662-3658-b277-847d-55aa0a8dd1d0%40siemens.com.
Re: [PATCH] configs: arm64: resolve overlapping memory regions in k3-am654-idk cell
On 24.03.22 02:23, 'Matt Ranostay' via Jailhouse wrote:
> There were several memory regions overlapping in current k3-am654-idk
> configuration including GICD/GICR regions for the interrupt controller.
>
> These issues have been resolved by changing region sizes and adding
> addition regions to avoid conflicts.
>
> Signed-off-by: Matt Ranostay
> ---
> configs/arm64/k3-am654-idk.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/configs/arm64/k3-am654-idk.c b/configs/arm64/k3-am654-idk.c
> index ddd770fe..4e6857f8 100644
> --- a/configs/arm64/k3-am654-idk.c
> +++ b/configs/arm64/k3-am654-idk.c
> @@ -18,7 +18,7 @@
> struct {
> struct jailhouse_system header;
> __u64 cpus[1];
> - struct jailhouse_memory mem_regions[18];
> + struct jailhouse_memory mem_regions[20];
> struct jailhouse_irqchip irqchips[5];
> struct jailhouse_pci_device pci_devices[1];
> } __attribute__((packed)) config = {
> @@ -112,7 +112,21 @@ struct {
> /* Most MAIN domain peripherals */ {
> .phys_start = 0x0100,
> .virt_start = 0x0100,
> - .size = 0x0af04000,
> + .size = 0x0080,
> + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> + JAILHOUSE_MEM_IO,
> + },
> + {
> + .phys_start = 0x0181,
> + .virt_start = 0x0181,
> + .size = 0x0007,
> + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> + JAILHOUSE_MEM_IO,
> + },
> + {
> + .phys_start = 0x018a,
> + .virt_start = 0x018a,
> + .size = 0xa664000,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_IO,
> },
> @@ -140,7 +154,7 @@ struct {
> /* MCUSS */ {
> .phys_start = 0x4204,
> .virt_start = 0x4204,
> - .size = 0x03ac3000,
> + .size = 0x030c,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_IO,
> },
Thanks, rebased and applied over next.
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/6f2a091c-4617-4ffc-86c4-0c9b121349be%40web.de.
Re: Jetson TX2 - access to peripherals from inmate
On 25.03.22 16:11, 'johannes lex' via Jailhouse wrote: > Hello everybody, > > i'm investigating the jailhouse hypervisor for a research project of an > automotive company. > > As a first step, i want to set up the Jetson TX2 Board and add an inmate > which toggels one GPIO Pin. I used the VM from the ERIKA V3 > (https://www.erika-enterprise.com/index.php/download/virtual-machines.html) > as a base development platform. > So far, Jailhouse is running and my configs seem to work. > > However, I can't access (not even read) the registers of the GPIO or any > other peripheral which i assign to my cell, except the already > configured UART. > The cell config and assignment of the registers themself seems to work: > i can, for example, read the register 0x02210890 from the Linux host > before creating the cell. After creating the cell, a read attempt from > the Linux host leads to a system crash. > Unfortunately, i can't read that register from the inmate as well :/ > > Do you have a clue why i can't read the register in my setup? I've > attached my configs and the source code for the bare metal application > of the inmate. > > Or do you have any examples in which you access the GPIOs (or other > peripherals) of the Jetson TX2 from an inmate which you could share? Already checked your configs for undesired overlaps (jailhouse config check)? Looking at the jetson-tx2-demo.c config you shared, the GPIO range is exclusively assigned from the root cell to the non-root demo. So, any further accesses from the Linux root cell should indeed trigger a violation. But accesses from the demo cell must be possible. However, I'm not seeing any violation reports regarding that cell. 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/27e635ef-500f-6f19-a461-9a5e88d12c8d%40web.de.
Re: [PATCH v4] configs: arm64: add emmc inmate configuration for k3-am654-idk
On 14.03.22 16:22, 'Matt Ranostay' via Jailhouse wrote:
> Add eMMC support for k3-am654-idk in a linux inmate cell using
> CONFIG_AM654_INMATE_CELL_EMMC macro, and respective device tree
> changes.
>
> Signed-off-by: Matt Ranostay
> ---
>
> Changes from v1:
> * Split out eMMC enablement to its own inmate configuration
>
> Changes from v2:
> * Recombined eMMC enablement to one configuration that is enabled
> with ENABLE_INMATE_CELL_EMMC define
> * Dropped patches that were already merged
>
> Changes from v3:
> * Rename ENABLE_INMATE_CELL_EMMC to CONFIG_AM654_INMATE_CELL_EMMC
>
How about the memegion array size diff?
Jan
> .../arm64/dts/inmate-k3-am654-idk-emmc.dts| 45 +++
> configs/arm64/k3-am654-idk-linux-demo.c | 22 -
> 2 files changed, 66 insertions(+), 1 deletion(-)
> create mode 100644 configs/arm64/dts/inmate-k3-am654-idk-emmc.dts
>
> diff --git a/configs/arm64/dts/inmate-k3-am654-idk-emmc.dts
> b/configs/arm64/dts/inmate-k3-am654-idk-emmc.dts
> new file mode 100644
> index ..150e31fe
> --- /dev/null
> +++ b/configs/arm64/dts/inmate-k3-am654-idk-emmc.dts
> @@ -0,0 +1,45 @@
> +/dts-v1/;
> +
> +#include "inmate-k3-am654-idk.dts"
> +
> +/ {
> + sdhci0: mmc@4f8 {
> + compatible = "ti,am654-sdhci-5.1";
> + reg = <0x0 0x4f8 0x0 0x260>, <0x0 0x4f9 0x0 0x134>;
> + power-domains = <_pds 47 1>;
> + clocks = <_clks 47 0>, <_clks 47 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + interrupts = ;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + ti,otap-del-sel-legacy = <0x0>;
> + ti,otap-del-sel-mmc-hs = <0x0>;
> + ti,otap-del-sel-sd-hs = <0x0>;
> + ti,otap-del-sel-sdr12 = <0x0>;
> + ti,otap-del-sel-sdr25 = <0x0>;
> + ti,otap-del-sel-sdr50 = <0x8>;
> + ti,otap-del-sel-sdr104 = <0x7>;
> + ti,otap-del-sel-ddr50 = <0x5>;
> + ti,otap-del-sel-ddr52 = <0x5>;
> + ti,otap-del-sel-hs200 = <0x5>;
> + ti,otap-del-sel-hs400 = <0x0>;
> + ti,trm-icp = <0x8>;
> + dma-coherent;
> + };
> +};
> +
> +_uart0 {
> + power-domains = <_pds 149 1>;
> +};
> +
> +_pds {
> + #power-domain-cells = <2>;
> +};
> +
> + {
> + /* eMMC */
> + non-removable;
> + ti,driver-strength-ohm = <50>;
> + bus-width = <8>;
> + disable-wp;
> +};
> diff --git a/configs/arm64/k3-am654-idk-linux-demo.c
> b/configs/arm64/k3-am654-idk-linux-demo.c
> index fdf5fea8..3937dff3 100644
> --- a/configs/arm64/k3-am654-idk-linux-demo.c
> +++ b/configs/arm64/k3-am654-idk-linux-demo.c
> @@ -23,7 +23,7 @@
> struct {
> struct jailhouse_cell_desc cell;
> __u64 cpus[1];
> - struct jailhouse_memory mem_regions[17];
> + struct jailhouse_memory mem_regions[19];
> struct jailhouse_irqchip irqchips[3];
> struct jailhouse_pci_device pci_devices[2];
> } __attribute__((packed)) config = {
> @@ -112,6 +112,22 @@ struct {
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_IO,
> },
> +#ifdef CONFIG_AM654_INMATE_CELL_EMMC
> + /* sdhci0 */ {
> + .phys_start = 0x4f8,
> + .virt_start = 0x4f8,
> + .size = 0x1000,
> + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> + JAILHOUSE_MEM_IO,
> + },
> + /* sdhci0 */ {
> + .phys_start = 0x4f9,
> + .virt_start = 0x4f9,
> + .size = 0x1000,
> + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> + JAILHOUSE_MEM_IO,
> + },
> +#endif
> /* main sproxy target_data host_id=A53_3 */ {
> .phys_start = 0x3240f000,
> .virt_start = 0x3240f000,
> @@ -153,6 +169,10 @@ struct {
> .address = 0x0180,
> .pin_base = 160,
> .pin_bitmap = {
> +#ifdef CONFIG_AM654_INMATE_CELL_EMMC
> + /* sdhc */
> + 1 << (168 - 160) |
> +#endif
> /* vpci */
> 1 << (189 - 160) |
> 1 << (190 - 160),
--
Siemens AG, Technology
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/bda0b499-e98d-2207-6adb-5baa8d9811cc%40siemens.com.
Re: [PATCH v3] configs: arm64: add emmc inmate configuration for k3-am654-idk
On 14.03.22 07:19, 'Matt Ranostay' via Jailhouse wrote:
> Add eMMC support for k3-am654-idk in a linux inmate cell using
> ENABLE_INMATE_CELL_EMMC macro, and respective device tree changes
>
> Signed-off-by: Matt Ranostay
> ---
> Changes from v1:
> * Split out eMMC enablement to its own inmate configuration
>
> Changes from v2:
> * Recombined eMMC enablement to one configuration that is enabled
> with ENABLE_INMATE_CELL_EMMC define
> * Dropped patches that were already merged
>
> .../arm64/dts/inmate-k3-am654-idk-emmc.dts| 45 +++
> configs/arm64/k3-am654-idk-linux-demo.c | 22 -
> 2 files changed, 66 insertions(+), 1 deletion(-)
> create mode 100644 configs/arm64/dts/inmate-k3-am654-idk-emmc.dts
>
> diff --git a/configs/arm64/dts/inmate-k3-am654-idk-emmc.dts
> b/configs/arm64/dts/inmate-k3-am654-idk-emmc.dts
> new file mode 100644
> index ..150e31fe
> --- /dev/null
> +++ b/configs/arm64/dts/inmate-k3-am654-idk-emmc.dts
> @@ -0,0 +1,45 @@
> +/dts-v1/;
> +
> +#include "inmate-k3-am654-idk.dts"
> +
> +/ {
> + sdhci0: mmc@4f8 {
> + compatible = "ti,am654-sdhci-5.1";
> + reg = <0x0 0x4f8 0x0 0x260>, <0x0 0x4f9 0x0 0x134>;
> + power-domains = <_pds 47 1>;
> + clocks = <_clks 47 0>, <_clks 47 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + interrupts = ;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + ti,otap-del-sel-legacy = <0x0>;
> + ti,otap-del-sel-mmc-hs = <0x0>;
> + ti,otap-del-sel-sd-hs = <0x0>;
> + ti,otap-del-sel-sdr12 = <0x0>;
> + ti,otap-del-sel-sdr25 = <0x0>;
> + ti,otap-del-sel-sdr50 = <0x8>;
> + ti,otap-del-sel-sdr104 = <0x7>;
> + ti,otap-del-sel-ddr50 = <0x5>;
> + ti,otap-del-sel-ddr52 = <0x5>;
> + ti,otap-del-sel-hs200 = <0x5>;
> + ti,otap-del-sel-hs400 = <0x0>;
> + ti,trm-icp = <0x8>;
> + dma-coherent;
> + };
> +};
> +
> +_uart0 {
> + power-domains = <_pds 149 1>;
> +};
> +
> +_pds {
> + #power-domain-cells = <2>;
> +};
> +
> + {
> + /* eMMC */
> + non-removable;
> + ti,driver-strength-ohm = <50>;
> + bus-width = <8>;
> + disable-wp;
> +};
> diff --git a/configs/arm64/k3-am654-idk-linux-demo.c
> b/configs/arm64/k3-am654-idk-linux-demo.c
> index fdf5fea8..844554a7 100644
> --- a/configs/arm64/k3-am654-idk-linux-demo.c
> +++ b/configs/arm64/k3-am654-idk-linux-demo.c
> @@ -23,7 +23,7 @@
> struct {
> struct jailhouse_cell_desc cell;
> __u64 cpus[1];
> - struct jailhouse_memory mem_regions[17];
> + struct jailhouse_memory mem_regions[19];
This does not give warnings if emmc is off? If not, I'm still not sure
right now if Jailhouse handles Null memregions well. Should at least be
tested. configs/x86/linux-x86-demo.c does that differently, though.
> struct jailhouse_irqchip irqchips[3];
> struct jailhouse_pci_device pci_devices[2];
> } __attribute__((packed)) config = {
> @@ -112,6 +112,22 @@ struct {
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_IO,
> },
> +#ifdef ENABLE_INMATE_CELL_EMMC
CONFIG_AM654_INMATE_CELL_EMMC
> + /* sdhci0 */ {
> + .phys_start = 0x4f8,
> + .virt_start = 0x4f8,
> + .size = 0x1000,
> + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> + JAILHOUSE_MEM_IO,
> + },
> + /* sdhci0 */ {
> + .phys_start = 0x4f9,
> + .virt_start = 0x4f9,
> + .size = 0x1000,
> + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> + JAILHOUSE_MEM_IO,
> + },
> +#endif
> /* main sproxy target_data host_id=A53_3 */ {
> .phys_start = 0x3240f000,
> .virt_start = 0x3240f000,
> @@ -153,6 +169,10 @@ struct {
> .address = 0x0180,
> .pin_base = 160,
> .pin_bitmap = {
> +#ifdef ENABLE_INMATE_CELL_EMMC
> + /* sdhc */
> + 1 << (168 - 160) |
> +#endif
> /* vpci */
> 1 << (189 - 160) |
> 1 << (190 - 160),
Jan
--
Siemens AG, Technology
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/495ff8d1-23e1-6c5c-dceb-de7200eb05b5%40siemens.com.
Re: Porting Jailhouse to the STM32MP157
On 09.03.22 10:54, Philip Molloy wrote: > Good morning, > > I'm porting Jailhouse to a board with a STM32MP157 and have a few random > questions. > > Are folks still using the #jailhouse channel on Freenode?[1] I joined > briefly and didn't see anyone. It seems like most projects have moved to > LiberaChat, but I didn't see anyone there either. I also checked OFTC. I think the IRC channel was never very active. Moving to LiberaChat would be appropriate now, but without an audience...? > > It is a bit confusing what patches need to be applied to the kernel. I > initially saw the patch embedded in the CI script, which I applied to my > kernel, but then came across queues/jailhouse in git.kiszka.org and > applied that instead. queues/jailhouse is mainline tracking, https://github.com/siemens/linux/commits/jailhouse-enabling/5.15 is current "stable". You can also find branches for older LTS baselines there. In addition, you can find two reference integrations for 32-bit arm in https://github.com/siemens/jailhouse-images. > > It might be nice to update to README to clarify what should be applied. > And perhaps modify the CI so that it uses queues/jailhouse or tags based > on it. I'd be happy to make those changes. CI is using an older kernel to stress compat support. It only has to build, not work, thus this shorter queue. > > I believe one important difference between queues/jailhouse and the > embedded patch is that queues/jailhouse doesn't seem to revert > 15ff9a39cd5ebabdf704634ea58806f2d12bbc39. For more information on the > impact see 6e43fb65 on my development branch.[2] > > Feel free to take a look at my progress on Gitlab.[3] Note that I still > have a bunch of TODOs littered around, but feedback is always welcome. > > Also, if anyone from emtrion is active here, I noticed the emsBC-Argon > also uses a STM32MP157 and I'd be happy collaborate.[4] > > Best, > Philip > > [1]: https://github.com/siemens/jailhouse/blob/master/README.md?plain=1#L47 > [2]: > https://gitlab.com/pamolloy/jailhouse/-/commit/6e43fb65b01a7a622cd6c2195a3bcf763bcf84f4 > [3]: https://gitlab.com/pamolloy/jailhouse/-/commits/stm32mp157 > [4]: > https://www.emtrion.de/en/products/emsbc-argon-single-board-computer.html > Looking forward to the patches! Jan -- Siemens AG, Technology 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/bbccf6d7-479e-4e3d-7cf2-89d8687b9e16%40siemens.com.
