Re: [PATCH v1 0/2] Add configure files and dts for NXP ls1043a RDB platform
Hi, Hongbo, Now ls1043a silicon v2.0 supports 64K alignment GIC address, we need to support silicon v2.0 but not v1.0 in opensource community, please update the patches. Jiafei. 在2020年12月10日星期四 UTC+8 下午6:48:42 写道： > From: "hongbo.wang" > > hongbo.wang (2): > configs: ls1043a-rdb: add cell configure files > configs: ls1043a-rdb: Add linux inmate dts demo > > configs/arm64/dts/inmate-ls1043a-rdb.dts | 176 > configs/arm64/ls1043a-rdb-inmate-demo.c | 137 +++ > configs/arm64/ls1043a-rdb-linux-demo.c | 165 > configs/arm64/ls1043a-rdb.c | 498 +++ > 4 files changed, 976 insertions(+) > create mode 100644 configs/arm64/dts/inmate-ls1043a-rdb.dts > create mode 100644 configs/arm64/ls1043a-rdb-inmate-demo.c > create mode 100644 configs/arm64/ls1043a-rdb-linux-demo.c > create mode 100644 configs/arm64/ls1043a-rdb.c > > -- > 2.17.1 > > -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/c33c208b-b94f-4764-9a35-722c0b43e483n%40googlegroups.com.
Re: [PATCH v3 2/2] configs: ls1046a-rdb: Add linux inmate dts demo
Thanks Jan.
Jiafei.
在2020年12月4日星期五 UTC+8 下午2:50:13 写道：
> On 04.12.20 04:45, Jiafei Pan wrote:
> > Add device tree demo for running Linux as an inmate on
> > NXP ls1046a RDB board.
> >
> > Signed-off-by: Jiafei Pan
> > ---
> > Change in v2:
> > - Added inmate dts
> >
> > configs/arm64/dts/inmate-ls1046a-rdb.dts | 177 +++
> > 1 file changed, 177 insertions(+)
> > create mode 100644 configs/arm64/dts/inmate-ls1046a-rdb.dts
> >
> > diff --git a/configs/arm64/dts/inmate-ls1046a-rdb.dts
> b/configs/arm64/dts/inmate-ls1046a-rdb.dts
> > new file mode 100644
> > index ..8dcda43c
> > --- /dev/null
> > +++ b/configs/arm64/dts/inmate-ls1046a-rdb.dts
> > @@ -0,0 +1,177 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Device Tree for inmate cell on NXP ls1046a RDB platform
> > + *
> > + * Copyright 2020 NXP
> > + *
> > + * Jiafei Pan
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include
> > +
> > +/ {
> > + compatible = "fsl,ls1046a-rdb", "fsl,ls1046a";
> > + model = "LS1046A RDB Board";
> > + interrupt-parent = <>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + aliases {
> > + serial0 =
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu2: cpu@2 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x2>;
> > + clocks = < 1 0>;
> > + next-level-cache = <>;
> > + cpu-idle-states = <_PH20>;
> > + #cooling-cells = <2>;
> > + enable-method = "psci";
> > + };
> > +
> > + cpu3: cpu@3 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x3>;
> > + clocks = < 1 0>;
> > + next-level-cache = <>;
> > + cpu-idle-states = <_PH20>;
> > + #cooling-cells = <2>;
> > + enable-method = "psci";
> > + };
> > +
> > + l2: l2-cache {
> > + compatible = "cache";
> > + };
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + idle-states {
> > + entry-method = "psci";
> > +
> > + CPU_PH20: cpu-ph20 {
> > + compatible = "arm,idle-state";
> > + idle-state-name = "PH20";
> > + arm,psci-suspend-param = <0x0>;
> > + entry-latency-us = <1000>;
> > + exit-latency-us = <1000>;
> > + min-residency-us = <3000>;
> > + };
> > + };
> > +
> > + sysclk: sysclk {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <1>;
> > + clock-output-names = "sysclk";
> > + };
> > +
> > + reboot {
> > + compatible ="syscon-reboot";
> > + regmap = <>;
> > + offset = <0xb0>;
> > + mask = <0x02>;
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + interrupts = > + IRQ_TYPE_LEVEL_LOW)>,
> > + > + IRQ_TYPE_LEVEL_LOW)>,
> > + > + IRQ_TYPE_LEVEL_LOW)>,
> > + > + IRQ_TYPE_LEVEL_LOW)>;
> > + };
> > +
> > + gic: interrupt-controller@141 {
> > + compatible = "arm,gic-400";
> > + #interrupt-cells = <3>;
> > + interrupt-controller;
> > + reg = <0x0 0x141 0 0x1>, /* GICD */
> > + <0x0 0x142f000 0 0x1000>, /* GICC */
> > + <0x0 0x144 0 0x2>, /* GICH */
> > + <0x0 0x146f000 0 0x1000>; /* GICV */
> > + interrupts = > + IRQ_TYPE_LEVEL_LOW)>;
> > + };
> > +
> > + soc: soc {
> > + compatible = "simple-bus";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > + dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
> > + dma-coherent;
> > +
> > +
> > + ddr: memory-controller@108 {
> > + compatible = "fsl,qoriq-memory-controller";
> > + reg = <0x0 0x108 0x0 0x1000>;
> > + interrupts = ;
> > + big-endian;
> > + };
> > +
> > + scfg: scfg@157 {
> > + compatible = "fsl,ls1046a-scfg", "syscon";
> > + reg = <0x0 0x157 0x0 0x1>;
> > + big-endian;
> > + };
> > +
> > + dcfg: dcfg@1ee {
> > + compatible = "fsl,ls1046a-dcfg", "syscon";
> > + reg = <0x0 0x1ee 0x0 0x1000>;
> > + big-endian;
> > + };
> > +
> > + clockgen: clocking@1ee1000 {
> > + compatible = "fsl,ls1046a-clockgen";
> > + reg = <0x0 0x1ee1000 0x0 0x1000>;
> > + #clock-cells = <2>;
> > + clocks = <>;
> > + };
> > +
> > + duart1: serial@21c0600 {
> > + compatible = "fsl,ns16550", "ns16550a";
> > + reg = <0x00 0x21c0600 0x0 0x100>;
> > + clocks = < 4 1>;
> > + status = "okay";
> > + };
> > +
> > + };
> > +
> > + pci@fb50 {
> > + compatible = "pci-host-ecam-generic";
> > + device_type = "pci";
> > + bus-range = <0 0>;
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + #interrupt-cells = <1>;
> > + interrupt-map-mask = <0 0 0 7>;
> > + interrupt-map = <0 0 0 1 GIC_SPI 28 IRQ_TYPE_EDGE_RISING>,
> > + <0 0 0 2 GIC_SPI 29 IRQ_TYPE_EDGE_RISING>,
> > + <0 0 0 3 GIC_SPI 30 IRQ_TYPE_EDGE_RISING>,
> > + <0 0 0 4 GIC_SPI 31 IRQ_TYPE_EDGE_RISING>;
> > + reg = <0x0 0xfb50 0x0 0x10>;
> > + ranges = <0x0200 0x00 0x1000 0x0 0x1000 0x00 0x1>;
> > + };
> > +
> > + psci {
> > + compatible = "arm,psci-1.0";
> > + method = "smc";
> > + };
> > +
> > +};
> > +
> >
>
> Both merged with minor tweaking.
>
> Thanks,
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>
Re: [PATCH v2 1/2] configs: ls1046a-rdb: add cell configure files
Jan Kiszka 于2020年12月3日周四 下午2:39写道： > On 02.12.20 03:09, Jiafei Pan wrote: > > Add root cell, inmate cell, ivshmem demo cell and Linux demo cell > > configure files for NXP ls1046a RDB platform. > > > > Signed-off-by: Jiafei Pan > > --- > > Change in v2: > > - Removed some annotated code > > > > configs/arm64/ls1046a-rdb-inmate-demo.c | 67 +++ > > configs/arm64/ls1046a-rdb-ivshmem-demo.c | 139 ++ > > Only realized now: Why separate inmate vs. ivshmem demo configs? Other > targets have them merged. > > Jan > > Yes, ivshmem demo includes inmate demo configs, will merge them together, thanks. Best Regards, Jiafei. > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux > > -- > You received this message because you are subscribed to the Google Groups > "Jailhouse" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jailhouse-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jailhouse-dev/f9072054-c4bb-a4b3-a186-5b82a2b48b07%40siemens.com > . > -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/CAJSojbZ9azXg14vEvZkUFthLumMf1tTnF4wkWr-Z58U8XxF%2Bjg%40mail.gmail.com.
Re: [PATCH] configs: add ls1046ardb linux demo
On Monday, November 30, 2020 at 6:20:37 PM UTC+8 j.kiszka...@gmail.com
wrote:
> On 30.11.20 08:19, Peter Pan wrote:
> >
> >
> > On Monday, November 30, 2020 at 3:02:12 PM UTC+8 j.kiszka...@gmail.com
> > wrote:
> >
> > On 30.11.20 08:05, Jiafei Pan wrote:
> > > Add root cell, inmate cell, ivshmem demo cell and Linux demo cell
> > > configure files for NXP ls1046a RDB platform.
> > >
> > > Signed-off-by: Jiafei Pan
> > > ---
> > > configs/arm64/ls1046a-rdb-inmate-demo.c | 67 +++
> > > configs/arm64/ls1046a-rdb-ivshmem-demo.c | 142 +++
> > > configs/arm64/ls1046a-rdb-linux-demo.c | 165
> > > configs/arm64/ls1046a-rdb.c | 517 +++
> > > 4 files changed, 891 insertions(+)
> > > create mode 100644 configs/arm64/ls1046a-rdb-inmate-demo.c
> > > create mode 100644 configs/arm64/ls1046a-rdb-ivshmem-demo.c
> > > create mode 100644 configs/arm64/ls1046a-rdb-linux-demo.c
> > > create mode 100644 configs/arm64/ls1046a-rdb.c
> > >
> > > diff --git a/configs/arm64/ls1046a-rdb-inmate-demo.c
> > b/configs/arm64/ls1046a-rdb-inmate-demo.c
> > > new file mode 100644
> > > index ..0f4f2395
> > > --- /dev/null
> > > +++ b/configs/arm64/ls1046a-rdb-inmate-demo.c
> > > @@ -0,0 +1,67 @@
> > > +/*
> > > + * ls1046a RDB - inmate demo
> > > + *
> > > + * Copyright NXP 2020
> > > + *
> > > + * Authors:
> > > + * Jiafei Pan
> > > + *
> > > + * This work is licensed under the terms of the GNU GPL, version
> > 2. See
> > > + * the COPYING file in the top-level directory.
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +
> > > +struct {
> > > + struct jailhouse_cell_desc cell;
> > > + __u64 cpus[1];
> > > + struct jailhouse_memory mem_regions[3];
> > > +} __attribute__((packed)) config = {
> > > + .cell = {
> > > + .signature = JAILHOUSE_CELL_DESC_SIGNATURE,
> > > + .revision = JAILHOUSE_CONFIG_REVISION,
> > > + .name = "inmate-demo",
> > > + .flags = JAILHOUSE_CELL_PASSIVE_COMMREG,
> > > +
> > > + .cpu_set_size = sizeof(config.cpus),
> > > + .num_memory_regions = ARRAY_SIZE(config.mem_regions),
> > > + .num_irqchips = 0,
> > > + .num_pci_devices = 0,
> > > +
> > > + .console = {
> > > + .address = 0x21c0600, /* Uart1 in DUART1 */
> > > + .divider = 0xbd, /* baudrate: 115200 */
> > > + .type = JAILHOUSE_CON_TYPE_8250,
> > > + .flags = JAILHOUSE_CON_ACCESS_MMIO |
> > > + JAILHOUSE_CON_REGDIST_1,
> > > + },
> > > + },
> > > +
> > > + .cpus = {
> > > + 0x8,
> > > + },
> > > +
> > > + .mem_regions = {
> > > + /* DUART1 */ {
> > > + .phys_start = 0x21c,
> > > + .virt_start = 0x21c,
> > > + .size = 0x1,
> > > + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> > > + JAILHOUSE_MEM_IO | JAILHOUSE_MEM_ROOTSHARED,
> > > + },
> > > + /* RAM: Top at 2GB DRAM1 Space */ {
> > > + .phys_start = 0xc000,
> > > + .virt_start = 0,
> > > + .size = 0x0001,
> > > + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> > > + JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_LOADABLE,
> > > + },
> > > + /* communication region */ {
> > > + .virt_start = 0x8000,
> > > + .size = 0x1000,
> > > + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> > > + JAILHOUSE_MEM_COMM_REGION,
> > > + },
> > > + }
> > > +};
> > > diff --git a/configs/arm64/ls1046a-rdb-ivshmem-demo.c
> > b/configs/arm64/ls1046a-rdb-ivshmem-demo.c
> > > new file mode 100644
> > > index ..907ba1f1
> > > --- /dev/null
> > > +++ b/configs/arm64/ls1046a-rdb-ivshmem-demo.c
> > > @@ -0,0 +1,142 @@
> > > +/*
> > > + * ls1046a RDB - ivshmem demo
> > > + *
> > > + * Copyright NXP 2020
> > > + *
> > > + * Authors:
> > > + * Jiafei Pan
> > > + *
> > > + * This work is licensed under the terms of the GNU GPL, version
> > 2. See
> > > + * the COPYING file in the top-level directory.
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +
> > > +struct {
&
Re: [PATCH] configs: add ls1046ardb linux demo
On Monday, November 30, 2020 at 3:02:12 PM UTC+8 j.kiszka...@gmail.com
wrote:
> On 30.11.20 08:05, Jiafei Pan wrote:
> > Add root cell, inmate cell, ivshmem demo cell and Linux demo cell
> > configure files for NXP ls1046a RDB platform.
> >
> > Signed-off-by: Jiafei Pan
> > ---
> > configs/arm64/ls1046a-rdb-inmate-demo.c | 67 +++
> > configs/arm64/ls1046a-rdb-ivshmem-demo.c | 142 +++
> > configs/arm64/ls1046a-rdb-linux-demo.c | 165
> > configs/arm64/ls1046a-rdb.c | 517 +++
> > 4 files changed, 891 insertions(+)
> > create mode 100644 configs/arm64/ls1046a-rdb-inmate-demo.c
> > create mode 100644 configs/arm64/ls1046a-rdb-ivshmem-demo.c
> > create mode 100644 configs/arm64/ls1046a-rdb-linux-demo.c
> > create mode 100644 configs/arm64/ls1046a-rdb.c
> >
> > diff --git a/configs/arm64/ls1046a-rdb-inmate-demo.c
> b/configs/arm64/ls1046a-rdb-inmate-demo.c
> > new file mode 100644
> > index ..0f4f2395
> > --- /dev/null
> > +++ b/configs/arm64/ls1046a-rdb-inmate-demo.c
> > @@ -0,0 +1,67 @@
> > +/*
> > + * ls1046a RDB - inmate demo
> > + *
> > + * Copyright NXP 2020
> > + *
> > + * Authors:
> > + * Jiafei Pan
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2. See
> > + * the COPYING file in the top-level directory.
> > + */
> > +
> > +#include
> > +#include
> > +
> > +struct {
> > + struct jailhouse_cell_desc cell;
> > + __u64 cpus[1];
> > + struct jailhouse_memory mem_regions[3];
> > +} __attribute__((packed)) config = {
> > + .cell = {
> > + .signature = JAILHOUSE_CELL_DESC_SIGNATURE,
> > + .revision = JAILHOUSE_CONFIG_REVISION,
> > + .name = "inmate-demo",
> > + .flags = JAILHOUSE_CELL_PASSIVE_COMMREG,
> > +
> > + .cpu_set_size = sizeof(config.cpus),
> > + .num_memory_regions = ARRAY_SIZE(config.mem_regions),
> > + .num_irqchips = 0,
> > + .num_pci_devices = 0,
> > +
> > + .console = {
> > + .address = 0x21c0600, /* Uart1 in DUART1 */
> > + .divider = 0xbd, /* baudrate: 115200 */
> > + .type = JAILHOUSE_CON_TYPE_8250,
> > + .flags = JAILHOUSE_CON_ACCESS_MMIO |
> > + JAILHOUSE_CON_REGDIST_1,
> > + },
> > + },
> > +
> > + .cpus = {
> > + 0x8,
> > + },
> > +
> > + .mem_regions = {
> > + /* DUART1 */ {
> > + .phys_start = 0x21c,
> > + .virt_start = 0x21c,
> > + .size = 0x1,
> > + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> > + JAILHOUSE_MEM_IO | JAILHOUSE_MEM_ROOTSHARED,
> > + },
> > + /* RAM: Top at 2GB DRAM1 Space */ {
> > + .phys_start = 0xc000,
> > + .virt_start = 0,
> > + .size = 0x0001,
> > + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> > + JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_LOADABLE,
> > + },
> > + /* communication region */ {
> > + .virt_start = 0x8000,
> > + .size = 0x1000,
> > + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> > + JAILHOUSE_MEM_COMM_REGION,
> > + },
> > + }
> > +};
> > diff --git a/configs/arm64/ls1046a-rdb-ivshmem-demo.c
> b/configs/arm64/ls1046a-rdb-ivshmem-demo.c
> > new file mode 100644
> > index ..907ba1f1
> > --- /dev/null
> > +++ b/configs/arm64/ls1046a-rdb-ivshmem-demo.c
> > @@ -0,0 +1,142 @@
> > +/*
> > + * ls1046a RDB - ivshmem demo
> > + *
> > + * Copyright NXP 2020
> > + *
> > + * Authors:
> > + * Jiafei Pan
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2. See
> > + * the COPYING file in the top-level directory.
> > + */
> > +
> > +#include
> > +#include
> > +
> > +struct {
> > + struct jailhouse_cell_desc cell;
> > + __u64 cpus[1];
> > + struct jailhouse_memory mem_regions[8];
> > + struct jailhouse_irqchip irqchips[2];
> > + struct jailhouse_pci_device pci_devices[1];
> > +} __attribute__((packed)) config = {
> > + .cell = {
> > + .signature = JAILHOUSE_CELL_DESC_SIGNATURE,
> > + .revision = JAILHOUSE_CONFIG_REVISION,
> > + .name = "ivshmem-demo",
> > + .flags = JAILHOUSE_CELL_PASSIVE_COMMREG,
> > +
> > + .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 = 60 - 32, /* vPCI INTx */
> > +
> > + .console = {
> > + .address = 0x21c0600, /* Uart1 in DUART1 */
> > + .divider = 0xbd, /* baudrate: 115200 */
> > + .type = JAILHOUSE_CON_TYPE_8250,
> > + .flags = JAILHOUSE_CON_ACCESS_MMIO |
> > + JAILHOUSE_CON_REGDIST_1,
> > + },
> > + },
> > +
> > + .cpus = {
> > + 0x8,
> > + },
> > +
> > + .mem_regions = {
> > + /* IVHSMEM shared memory region for 00:00.0 */ {
> > + .phys_start = 0xfb70,
> > + .virt_start = 0xfb70,
> > + .size = 0x1000,
> > + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_ROOTSHARED,
> > + },
> > + {
> > + .phys_start = 0xfb701000,
> > + .virt_start = 0xfb701000,
> > + .size = 0x9000,
> > + .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> > +
Re: [linux-kernel][PATCH 2/2] ivshmem-net: Fix and rework carrier management
Hi, Jan,
I tested patches on the branch queues/jailhouse, it works for me.
Best Regards,
Jiafei.
在2020年11月23日星期一 UTC+8 下午3:40:04 写道：
> On 23.11.20 08:37, Jan Kiszka wrote:
> > From: Jan Kiszka
> >
> > The carrier of our virtual link is supposed to go on only when both
> > sides are in RUN state. So far, it only went on when one side entered
> > RUN by being int READY before and not when RUN was reached via
> > ivshm_net_open().
> >
> > Fix this by moving the carrier management into ivshm_net_run and
> > ivshm_net_do_stop, respectively. Make sure that netif_carrier_on is only
> > called when the peer in in RUN state already.
> >
> > Reported-by: Jiafei Pan
> > Signed-off-by: Jan Kiszka
> > ---
> > drivers/net/ivshmem-net.c | 28 ++--
> > 1 file changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/net/ivshmem-net.c b/drivers/net/ivshmem-net.c
> > index 1b22b1cc5ea3..56c2c87e7498 100644
> > --- a/drivers/net/ivshmem-net.c
> > +++ b/drivers/net/ivshmem-net.c
> > @@ -549,6 +549,9 @@ static void ivshm_net_run(struct net_device *ndev)
> > if (!netif_running(ndev))
> > return;
> >
> > + if (in->last_peer_state == IVSHM_NET_STATE_RUN)
> > + netif_carrier_on(ndev);
> > +
> > if (test_and_set_bit(IVSHM_NET_FLAG_RUN, >flags))
> > return;
> >
> > @@ -567,6 +570,7 @@ static void ivshm_net_do_stop(struct net_device
> *ndev)
> > if (!test_and_clear_bit(IVSHM_NET_FLAG_RUN, >flags))
> > return;
> >
> > + netif_carrier_off(ndev);
> > netif_stop_queue(ndev);
> > napi_disable(>napi);
> > }
> > @@ -616,22 +620,18 @@ static void ivshm_net_state_change(struct
> work_struct *work)
> > break;
> >
> > case IVSHM_NET_STATE_READY:
> > - /*
> > - * Link is up and we are running once the remote is in READY or
> > - * RUN.
> > - */
> > + case IVSHM_NET_STATE_RUN:
> > if (peer_state >= IVSHM_NET_STATE_READY) {
> > - netif_carrier_on(ndev);
> > + /*
> > + * Link is up and we are running once the remote is in
> > + * READY or RUN.
> > + */
> > ivshm_net_run(ndev);
> > - break;
> > - }
> > - /* fall through */
> > - case IVSHM_NET_STATE_RUN:
> > - /*
> > - * If the remote goes to RESET, we need to follow immediately.
> > - */
> > - if (peer_state == IVSHM_NET_STATE_RESET) {
> > - netif_carrier_off(ndev);
> > + } else if (peer_state == IVSHM_NET_STATE_RESET) {
> > + /*
> > + * If the remote goes to RESET, we need to follow
> > + * immediately.
> > + */
> > ivshm_net_do_stop(ndev);
> > }
> > break;
> >
>
> 5.10-rc5 queue was updated on
> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/jailhouse
> .
> Once you can confirm that this works for you, I will also update
> jailhouse/enabling queues with the two patches.
>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/56f3d63c-03ec-49b1-ad5e-ffe4004a2e54n%40googlegroups.com.
Re: one question about MSI-X support for vPCI
Hi, Jan, The following is my debug log: On root cell, enable root cell: [ 267.783070] uio_ivshmem 0003:00:00.0: output_section at 0xfb70a000, size 0x2000 [ 267.792364] ivshmem-net 0003:00:01.0: enabling device ( -> 0002) [ 267.798798] ivshmem-net 0003:00:01.0: TX memory at 0xfb801000, size 0x0007f000 [ 267.807443] ivshmem-net 0003:00:01.0: RX memory at 0xfb88, size 0x0007f000 [ 267.816408] ivshm_net_state_change:state=0,peer_state=0 // Then root cell NIC state is changed to be INIT, inmate NIC is RESET [ 267.816471] The Jailhouse is opening. Then execute linux inmate cell loading: [ 673.503776] ivshm_net_state_change:state=1,peer_state=1 // Then root cell NIC state is changed to be READY, inmate NIC is INIT [ 673.510338] ivshm_net_state_change:state=2,peer_state=2 // Then root cell NIC state is changed to be READY, inmate NIC is READY, and then set carrior on [ 673.516315] *set carrier on For inmate Cell, during kernel boot up and driver probe: [1.649054] ivshmem-net :00:01.0: enabling device ( -> 0002) [1.655516] ivshmem-net :00:01.0: TX memory at 0xfb88, size 0x0007f000 [1.664142] ivshmem-net :00:01.0: RX memory at 0xfb801000, size 0x0007f000 [1.673180] ivshm_net_state_change:state=0,peer_state=1 // Then inmate cell NIC state is changed to be INIT, root cell NIC is INIT [1.673579] uio_ivshmem :00:00.0: enabling device ( -> 0002) [1.685477] ivshm_net_state_change:state=1,peer_state=2 // Then inmate cell NIC state is changed to be READY, root cell NIC is READY, but after that and before ifconfig NIC up, ivshm_net_state_change is not called anymore, so carrior is not set to be on. We can find that before ifconfig up (open) virtual NIC, although stats both for NIC in root cell and inmate cell are all READY, but carrior in root cell is on, but in inmate cell if off. So I don't think virtual NIC in root cell and inmate cell is whole symmetric Thanks. Jiafei. 在2020年11月19日星期四 UTC+8 下午4:28:48 写道： > On 19.11.20 08:52, Peter pan wrote: > > Hi, Jan, > > > > After some investigation, I found the root cause of the issue: the > > carrier is not > > changed to be on if we open virtual NIC in inmate firstly, attached > > patch can > > fix this issue, please help to review, by the way where I can upstream > > this patch? > > Thanks for the patch! > > I'm just wondering, given that ivshmem-net is conceptually fully > symmetric, what is causing this issue to only happen in one way. Guess I > need to study the scenario in details. > > Jan > > > Thanks. > > > > Best Regards, > > Jiafei. > > > > 在2020年11月18日星期三 UTC+8 下午6:01:51 写道： > > > > On 18.11.20 10:50, Peter pan wrote: > > > Hi, Jan, > > > > > > I have one new issue and not sure it is a know issue. > > > > > > The issue is: when I ifconfig up ivshmem-net NIC in root cell firstly > > > and then ifconfig up ivshmem NIC in inmate cell (runing Linux), I > > can > > > ping through between two NICs, but if I ifconfig up NIC in inmate > > cell > > > before ifconfig up the NIC in root cell, I can't ping through between > > > two NICs, and I found NIC in inmate can only receive packet > > sending from > > > root cell NIC, but NIC in root cell can't receive any packet and > > there > > > is also no irq received for ivshmem NIC. > > > > > > > The link states of both virtual NICs are up (ethtool)? Is there any > > ivshmem-net interrupt received at all on the root side? There should be > > a few during setup at least. > > > > Check that the interrupt line on the root side is really free, and also > > that GICD is properly intercepted by Jailhouse (check mappings). > > > > Jan > > > > -- > > Siemens AG, T RDA IOT > > Corporate Competence Center Embedded Linux > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Jailhouse" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to jailhouse-de...@googlegroups.com > > <mailto:jailhouse-de...@googlegroups.com>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/jailhouse-dev/581e32ac-d032-4108-b4fe-21286e6b2085n%40googlegroups.com > > > < > https://groups.google.com/d/msgid/jailhouse-dev/581e32ac-d032-4108-b4fe-21286e6b2085n%40googlegroups.com?utm_medium=email_source=footer>. > > > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux > -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/525f34ef-be0c-451d-b626-43763045008cn%40googlegroups.com.
Re: one question about MSI-X support for vPCI
Hi, Jan, After some investigation, I found the root cause of the issue: the carrier is not changed to be on if we open virtual NIC in inmate firstly, attached patch can fix this issue, please help to review, by the way where I can upstream this patch? Thanks. Best Regards, Jiafei. 在2020年11月18日星期三 UTC+8 下午6:01:51 写道： > On 18.11.20 10:50, Peter pan wrote: > > Hi, Jan, > > > > I have one new issue and not sure it is a know issue. > > > > The issue is: when I ifconfig up ivshmem-net NIC in root cell firstly > > and then ifconfig up ivshmem NIC in inmate cell (runing Linux), I can > > ping through between two NICs, but if I ifconfig up NIC in inmate cell > > before ifconfig up the NIC in root cell, I can't ping through between > > two NICs, and I found NIC in inmate can only receive packet sending from > > root cell NIC, but NIC in root cell can't receive any packet and there > > is also no irq received for ivshmem NIC. > > > > The link states of both virtual NICs are up (ethtool)? Is there any > ivshmem-net interrupt received at all on the root side? There should be > a few during setup at least. > > Check that the interrupt line on the root side is really free, and also > that GICD is properly intercepted by Jailhouse (check mappings). > > Jan > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux > -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/581e32ac-d032-4108-b4fe-21286e6b2085n%40googlegroups.com. >From 828eecf2c696410a30bfd7c5c7a0d384c4bec7c5 Mon Sep 17 00:00:00 2001 From: Jiafei Pan Date: Thu, 19 Nov 2020 15:34:47 +0800 Subject: [PATCH] ivshmem-net: set carrier on if device has been opened When virtual NIC is opened in inmate firstly, and then open virtual NIC in root cell, virtual NIC in inmate can't transmit packets out. The roor cause of this issue is although state has been changed to be RUN in process of "open", but carrier need to set to be on after state of peer is changed to be RUN, otherwise network stack will not transmit packet to virtual NIC. Signed-off-by: Jiafei Pan --- drivers/net/ivshmem-net.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ivshmem-net.c b/drivers/net/ivshmem-net.c index 18d5a15dbec2..8aab21b3febe 100644 --- a/drivers/net/ivshmem-net.c +++ b/drivers/net/ivshmem-net.c @@ -623,6 +623,12 @@ static void ivshm_net_state_change(struct work_struct *work) netif_carrier_off(ndev); ivshm_net_do_stop(ndev); } + /* In case of it has been already opened, so state is RUN, + * set Carrier on when remote goes to RUN. + */ + if (peer_state == IVSHM_NET_STATE_RUN) + netif_carrier_on(ndev); + break; } -- 2.17.1
Re: one question about MSI-X support for vPCI
Hi, Jan, I have one new issue and not sure it is a know issue. The issue is: when I ifconfig up ivshmem-net NIC in root cell firstly and then ifconfig up ivshmem NIC in inmate cell (runing Linux), I can ping through between two NICs, but if I ifconfig up NIC in inmate cell before ifconfig up the NIC in root cell, I can't ping through between two NICs, and I found NIC in inmate can only receive packet sending from root cell NIC, but NIC in root cell can't receive any packet and there is also no irq received for ivshmem NIC. Thanks. Best Regards, Jiafei. 在2020年11月13日星期五 UTC+8 下午5:55:52 写道： > Thanks Jan, now it works with INTx. > > Jiafei. > > 在2020年11月12日星期四 UTC+8 下午9:05:15 写道： > >> On 12.11.20 09:50, Peter pan wrote: >> > Dear Jailhouse Community, >> > >> > I am runing Jailhouse on kernel v5.4, and port some ivshmem patches >> > from http://git.kiszka.org/?p=linux.git;a=summary >> > <http://git.kiszka.org/?p=linux.git;a=summary> >> > >> > The issue I have is uio_shmem and ivshmem-net will probe failed when I >> > use MSI-X mode for vPCI after I run Jailhouse enable command. Please >> > find the folowing log: >> > >> > [ 21.581019] jailhouse: loading out-of-tree module taints kernel. >> > >> > [ 30.000988] pci-host-generic fb50.pci: host bridge /pci@0 >> ranges: >> > >> > [ 30.000997] pci-host-generic fb50.pci: MEM >> > 0xfb60..0xfb603fff -> 0xfb60 >> > >> > [ 30.001028] pci-host-generic fb50.pci: ECAM at [mem >> > 0xfb50-0xfb5f] for [bus 00] >> > >> > [ 30.001081] pci-host-generic fb50.pci: PCI host bridge to bus >> 0003:00 >> > >> > [ 30.001085] pci_bus 0003:00: root bus resource [bus 00] >> > >> > [ 30.001087] pci_bus 0003:00: root bus resource [mem >> > 0xfb60-0xfb603fff] >> > >> > [ 30.001105] pci 0003:00:00.0: [110a:4106] type 00 class 0xff >> > >> > [ 30.001128] pci 0003:00:00.0: reg 0x10: [mem 0x-0x0fff] >> > >> > [ 30.001136] pci 0003:00:00.0: reg 0x14: [mem 0x-0x01ff] >> > >> > [ 30.001340] pci 0003:00:01.0: [110a:4106] type 00 class 0xff0001 >> > >> > [ 30.001359] pci 0003:00:01.0: reg 0x10: [mem 0x-0x0fff] >> > >> > [ 30.001368] pci 0003:00:01.0: reg 0x14: [mem 0x-0x01ff] >> > >> > [ 30.002389] pci 0003:00:00.0: BAR 0: assigned [mem >> 0xfb60-0xfb600fff] >> > >> > [ 30.002397] pci 0003:00:01.0: BAR 0: assigned [mem >> 0xfb601000-0xfb601fff] >> > >> > [ 30.002403] pci 0003:00:00.0: BAR 1: assigned [mem >> 0xfb602000-0xfb6021ff] >> > >> > [ 30.002409] pci 0003:00:01.0: BAR 1: assigned [mem >> 0xfb602200-0xfb6023ff] >> > >> > [ 30.002478] uio_ivshmem 0003:00:00.0: enabling device ( -> 0002) >> > >> > [ 30.002505] uio_ivshmem 0003:00:00.0: state_table at >> > 0xfb70, size 0x1000 >> > >> > [ 30.002512] uio_ivshmem 0003:00:00.0: rw_section at >> > 0xfb701000, size 0x9000 >> > >> > [ 30.002520] uio_ivshmem 0003:00:00.0: input_sections at >> > 0xfb70a000, size 0x6000 >> > >> > [ 30.002524] uio_ivshmem 0003:00:00.0: output_section at >> > 0xfb70a000, size 0x2000 >> > >> > [ 30.002576] uio_ivshmem: probe of 0003:00:00.0 failed with error -28 >> > >> > [ 30.002620] ivshmem-net 0003:00:01.0: enabling device ( -> 0002) >> > >> > [ 30.002664] ivshmem-net 0003:00:01.0: TX memory at >> > 0xfb801000, size 0x0007f000 >> > >> > [ 30.002667] ivshmem-net 0003:00:01.0: RX memory at >> > 0xfb88, size 0x0007f000 >> > >> > [ 30.047630] ivshmem-net: probe of 0003:00:01.0 failed with error -28 >> > >> > [ 30.047714] The Jailhouse is opening. >> > >> > >> > After some investigation I found the dts node of vPIC is added to root >> > cell by using vpci_template.dts, the Jailhouse >> > driver create_vpci_of_overlay() in driver/pci.c can't add the handler >> of >> > "msi-parent" to this PCI node, but the kernel driver of the virtual >> PCI >> > device use the following function >> > ret = pci_alloc_irq_vectors(pdev, 1, 2,
Re: one question about MSI-X support for vPCI
Thanks Jan, now it works with INTx. Jiafei. 在2020年11月12日星期四 UTC+8 下午9:05:15 写道： > On 12.11.20 09:50, Peter pan wrote: > > Dear Jailhouse Community, > > > > I am runing Jailhouse on kernel v5.4, and port some ivshmem patches > > from http://git.kiszka.org/?p=linux.git;a=summary > > <http://git.kiszka.org/?p=linux.git;a=summary> > > > > The issue I have is uio_shmem and ivshmem-net will probe failed when I > > use MSI-X mode for vPCI after I run Jailhouse enable command. Please > > find the folowing log: > > > > [ 21.581019] jailhouse: loading out-of-tree module taints kernel. > > > > [ 30.000988] pci-host-generic fb50.pci: host bridge /pci@0 ranges: > > > > [ 30.000997] pci-host-generic fb50.pci: MEM > > 0xfb60..0xfb603fff -> 0xfb60 > > > > [ 30.001028] pci-host-generic fb50.pci: ECAM at [mem > > 0xfb50-0xfb5f] for [bus 00] > > > > [ 30.001081] pci-host-generic fb50.pci: PCI host bridge to bus > 0003:00 > > > > [ 30.001085] pci_bus 0003:00: root bus resource [bus 00] > > > > [ 30.001087] pci_bus 0003:00: root bus resource [mem > > 0xfb60-0xfb603fff] > > > > [ 30.001105] pci 0003:00:00.0: [110a:4106] type 00 class 0xff > > > > [ 30.001128] pci 0003:00:00.0: reg 0x10: [mem 0x-0x0fff] > > > > [ 30.001136] pci 0003:00:00.0: reg 0x14: [mem 0x-0x01ff] > > > > [ 30.001340] pci 0003:00:01.0: [110a:4106] type 00 class 0xff0001 > > > > [ 30.001359] pci 0003:00:01.0: reg 0x10: [mem 0x-0x0fff] > > > > [ 30.001368] pci 0003:00:01.0: reg 0x14: [mem 0x-0x01ff] > > > > [ 30.002389] pci 0003:00:00.0: BAR 0: assigned [mem > 0xfb60-0xfb600fff] > > > > [ 30.002397] pci 0003:00:01.0: BAR 0: assigned [mem > 0xfb601000-0xfb601fff] > > > > [ 30.002403] pci 0003:00:00.0: BAR 1: assigned [mem > 0xfb602000-0xfb6021ff] > > > > [ 30.002409] pci 0003:00:01.0: BAR 1: assigned [mem > 0xfb602200-0xfb6023ff] > > > > [ 30.002478] uio_ivshmem 0003:00:00.0: enabling device ( -> 0002) > > > > [ 30.002505] uio_ivshmem 0003:00:00.0: state_table at > > 0xfb70, size 0x1000 > > > > [ 30.002512] uio_ivshmem 0003:00:00.0: rw_section at > > 0xfb701000, size 0x9000 > > > > [ 30.002520] uio_ivshmem 0003:00:00.0: input_sections at > > 0xfb70a000, size 0x6000 > > > > [ 30.002524] uio_ivshmem 0003:00:00.0: output_section at > > 0xfb70a000, size 0x2000 > > > > [ 30.002576] uio_ivshmem: probe of 0003:00:00.0 failed with error -28 > > > > [ 30.002620] ivshmem-net 0003:00:01.0: enabling device ( -> 0002) > > > > [ 30.002664] ivshmem-net 0003:00:01.0: TX memory at > > 0xfb801000, size 0x0007f000 > > > > [ 30.002667] ivshmem-net 0003:00:01.0: RX memory at > > 0xfb88, size 0x0007f000 > > > > [ 30.047630] ivshmem-net: probe of 0003:00:01.0 failed with error -28 > > > > [ 30.047714] The Jailhouse is opening. > > > > > > After some investigation I found the dts node of vPIC is added to root > > cell by using vpci_template.dts, the Jailhouse > > driver create_vpci_of_overlay() in driver/pci.c can't add the handler of > > "msi-parent" to this PCI node, but the kernel driver of the virtual PCI > > device use the following function > > ret = pci_alloc_irq_vectors(pdev, 1, 2, PCI_IRQ_LEGACY | PCI_IRQ_MSIX); > > So the driver will probe MSIX irq for the device, because there is no > > msi controller is speficied to vPCI, the result is no irq-domain is > > provided to this PCI and irq allocated failed. > > > > so how to fix such issue? Appreciate any comments and suggestions, > thanks. > > The vPCI support in Jailhouse injects interrupts as legacy INTx. For > that, you need to provide up to 4 (less if you have less ivshmem > devices) consecutive SPIs that are not in use by real devices (in any > cell). See other arm64 configs, specifically look for vpci_irq_base. > > Jan > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux > > -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/650b2d0f-b721-44a4-9572-28c2a88a7559n%40googlegroups.com.
one question about MSI-X support for vPCI
Dear Jailhouse Community, I am runing Jailhouse on kernel v5.4, and port some ivshmem patches from http://git.kiszka.org/?p=linux.git;a=summary The issue I have is uio_shmem and ivshmem-net will probe failed when I use MSI-X mode for vPCI after I run Jailhouse enable command. Please find the folowing log: [ 21.581019] jailhouse: loading out-of-tree module taints kernel. [ 30.000988] pci-host-generic fb50.pci: host bridge /pci@0 ranges: [ 30.000997] pci-host-generic fb50.pci: MEM 0xfb60..0xfb603fff -> 0xfb60 [ 30.001028] pci-host-generic fb50.pci: ECAM at [mem 0xfb50-0xfb5f] for [bus 00] [ 30.001081] pci-host-generic fb50.pci: PCI host bridge to bus 0003:00 [ 30.001085] pci_bus 0003:00: root bus resource [bus 00] [ 30.001087] pci_bus 0003:00: root bus resource [mem 0xfb60-0xfb603fff] [ 30.001105] pci 0003:00:00.0: [110a:4106] type 00 class 0xff [ 30.001128] pci 0003:00:00.0: reg 0x10: [mem 0x-0x0fff] [ 30.001136] pci 0003:00:00.0: reg 0x14: [mem 0x-0x01ff] [ 30.001340] pci 0003:00:01.0: [110a:4106] type 00 class 0xff0001 [ 30.001359] pci 0003:00:01.0: reg 0x10: [mem 0x-0x0fff] [ 30.001368] pci 0003:00:01.0: reg 0x14: [mem 0x-0x01ff] [ 30.002389] pci 0003:00:00.0: BAR 0: assigned [mem 0xfb60-0xfb600fff] [ 30.002397] pci 0003:00:01.0: BAR 0: assigned [mem 0xfb601000-0xfb601fff] [ 30.002403] pci 0003:00:00.0: BAR 1: assigned [mem 0xfb602000-0xfb6021ff] [ 30.002409] pci 0003:00:01.0: BAR 1: assigned [mem 0xfb602200-0xfb6023ff] [ 30.002478] uio_ivshmem 0003:00:00.0: enabling device ( -> 0002) [ 30.002505] uio_ivshmem 0003:00:00.0: state_table at 0xfb70, size 0x1000 [ 30.002512] uio_ivshmem 0003:00:00.0: rw_section at 0xfb701000, size 0x9000 [ 30.002520] uio_ivshmem 0003:00:00.0: input_sections at 0xfb70a000, size 0x6000 [ 30.002524] uio_ivshmem 0003:00:00.0: output_section at 0xfb70a000, size 0x2000 [ 30.002576] uio_ivshmem: probe of 0003:00:00.0 failed with error -28 [ 30.002620] ivshmem-net 0003:00:01.0: enabling device ( -> 0002) [ 30.002664] ivshmem-net 0003:00:01.0: TX memory at 0xfb801000, size 0x0007f000 [ 30.002667] ivshmem-net 0003:00:01.0: RX memory at 0xfb88, size 0x0007f000 [ 30.047630] ivshmem-net: probe of 0003:00:01.0 failed with error -28 [ 30.047714] The Jailhouse is opening. After some investigation I found the dts node of vPIC is added to root cell by using vpci_template.dts, the Jailhouse driver create_vpci_of_overlay() in driver/pci.c can't add the handler of "msi-parent" to this PCI node, but the kernel driver of the virtual PCI device use the following function ret = pci_alloc_irq_vectors(pdev, 1, 2, PCI_IRQ_LEGACY | PCI_IRQ_MSIX); So the driver will probe MSIX irq for the device, because there is no msi controller is speficied to vPCI, the result is no irq-domain is provided to this PCI and irq allocated failed. so how to fix such issue? Appreciate any comments and suggestions, thanks. Best Regards, Jiafei. -- 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/e223356c-fc2c-4c3b-98c3-6d27fba1099an%40googlegroups.com.
Re: Jailhouse hang on NXP ls1046a ARM64 platform
Hi, Jan
在2020年10月29日星期四 UTC+8 下午6:38:08 写道：
> On 29.10.20 10:12, Peter pan wrote:
> > Thanks Jan for your help. Now I have fixe the issue, the issue is from I
> > mapped the whole DCSR space together, after removing it and adding some
> > memeroy region of IPs, now I run jailhouse enable without any errors.
>
> Perfect.
>
> >
> > One more questions, do we need to map memory regions of all the IPs in
> > SYSCONFIG? or only IPs to be used in cells? thanks again.
> >
>
> Only used one. You may even leave out IP from the root cell that was
> only configured during boot-up and will not longer be touched under
> normal conditions during runtime ("freeze" the IP, e.g. to prevent
> malicious misconfiguration).
>
> BTW, do you plan to activate the SMMU as well? We are current stressing
> the new implementation by your colleagues on the i.MX8 and the ZynqMP
> and could use more testers on other silicon.
>
> Yes, I indeed have plan to enable SMMU, please let me know what and how I
can do, thanks.\
Perer P.
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/28196abf-ab56-424d-9a27-9cc58f21f4dcn%40googlegroups.com.
Re: Jailhouse hang on NXP ls1046a ARM64 platform
Thanks Jan for your help. Now I have fixe the issue, the issue is from I
mapped the whole DCSR space together, after removing it and adding some
memeroy region of IPs, now I run jailhouse enable without any errors.
One more questions, do we need to map memory regions of all the IPs in
SYSCONFIG? or only IPs to be used in cells? thanks again.
Best Regards,
Peter P.
在2020年10月28日星期三 UTC+8 下午6:43:10 写道：
> On 28.10.20 11:06, Peter pan wrote:
> > Hello Jailhouse Community,
> >
> > I am trying to enable Jaihouse on NXP ls1046a platform which has four
> > ARM A72 CPU Cores, but now the system hangs after I execute "jailhouse
> > enable ls1046a.cell".
> >
> > root@localhost:~/jailhouse/jailhouse# jailhouse enable ls1046a.cell
> >
> >
> >
> > Initializing Jailhouse hypervisor v0.12 (73-gacdc9fcc-dirty) on CPU 2
> >
> > Code location: 0xc0200800
> >
> > Page pool usage after early setup: mem 39/992, remap 0/131072
> >
> > Initializing processors:
> >
> > CPU 2... OK
> >
> > CPU 0... OK
> >
> > CPU 1... OK
> >
> > CPU 3... OK
> >
> > Initializing unit: irqchip
> >
> > Initializing unit: ARM SMMU v3
> >
> > Initializing unit: ARM SMMU
> >
> > No SMMU
> >
> > Initializing unit: PVU IOMMU
> >
> > Initializing unit: PCI
> >
> > Adding virtual PCI device 00:00.0 to cell "ls1046"
> >
> > Adding virtual PCI device 00:01.0 to cell "ls1046"
> >
> > Page pool usage after late setup: mem 62/992, remap 5/131072
> >
> > Activating hypervisor
> >
> > WARN: unknown SGI received 5
> >
> > WARN: unknown SGI received 5
> >
> > //Linux hang here.
> >
> > After did some debuging, I found the issue is with the followng calling.
> >
> > on_each_cpu(enter_hypervisor, header, 0);
> >
> > The following is definition of on_each_cpu.
> >
> > 611 void on_each_cpu(void (*func) (void *info), void *info, int wait)
> >
> > 612 {
> >
> > 613 unsigned long flags;
> >
> > 614
> >
> > 615 preempt_disable();
> >
> > 616 smp_call_function(func, info, wait);
> >
> > 617 local_irq_save(flags);
> >
> > 618 func(info);
> >
> > //Can panic here if call panic("return from hypervisor\n");
> >
> > 619 local_irq_restore(flags);
> >
> > //System hang and can't panic here if call panic("return from
> > hypervisor\n");
> >
> > 620 preempt_enable();
> >
> > 621 }
> >
> > 622 EXPORT_SYMBOL(on_each_cpu);
> >
> > I found the system hangs just after execute local_irq_restore(flags),
> > because the system can panic if I call panic() just before
> > local_irq_restore(), but can't panic if add panic() just after
> > local_irq_restore().
> >
> > I attached ls1046a.c.
> >
> > I am a newbies of Jailhouse, how to debug such issue? any comments or
> > suggestion is Welcome, thanks.
> >
>
> Henning (in CC) did a lot of work on this platform, and IIRC one
> particular tricky issue was when the GIC was accidentally passed through
> rather than intercept (not mapped). That's probably worth to check again
> in your config.
>
> Reminds me that we need to enhance "jailhouse config check" in this
> regard...
>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/d66e8b2f-e499-40d2-8257-4d93597bfff9n%40googlegroups.com.
Jailhouse hang on NXP ls1046a ARM64 platform
Hello Jailhouse Community,
I am trying to enable Jaihouse on NXP ls1046a platform which has four ARM
A72 CPU Cores, but now the system hangs after I execute "jailhouse enable
ls1046a.cell".
root@localhost:~/jailhouse/jailhouse# jailhouse enable ls1046a.cell
Initializing Jailhouse hypervisor v0.12 (73-gacdc9fcc-dirty) on CPU 2
Code location: 0xc0200800
Page pool usage after early setup: mem 39/992, remap 0/131072
Initializing processors:
CPU 2... OK
CPU 0... OK
CPU 1... OK
CPU 3... OK
Initializing unit: irqchip
Initializing unit: ARM SMMU v3
Initializing unit: ARM SMMU
No SMMU
Initializing unit: PVU IOMMU
Initializing unit: PCI
Adding virtual PCI device 00:00.0 to cell "ls1046"
Adding virtual PCI device 00:01.0 to cell "ls1046"
Page pool usage after late setup: mem 62/992, remap 5/131072
Activating hypervisor
WARN: unknown SGI received 5
WARN: unknown SGI received 5
//Linux hang here.
After did some debuging, I found the issue is with the followng calling.
on_each_cpu(enter_hypervisor, header, 0);
The following is definition of on_each_cpu.
611 void on_each_cpu(void (*func) (void *info), void *info, int wait)
612 {
613 unsigned long flags;
614
615 preempt_disable();
616 smp_call_function(func, info, wait);
617 local_irq_save(flags);
618 func(info);
//Can panic here if call panic("return from hypervisor\n");
619 local_irq_restore(flags);
//System hang and can't panic here if call panic("return from
hypervisor\n");
620 preempt_enable();
621 }
622 EXPORT_SYMBOL(on_each_cpu);
I found the system hangs just after execute local_irq_restore(flags),
because the system can panic if I call panic() just before
local_irq_restore(), but can't panic if add panic() just after
local_irq_restore().
I attached ls1046a.c.
I am a newbies of Jailhouse, how to debug such issue? any comments or
suggestion is Welcome, thanks.
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/58057754-ee40-4583-bd44-db19a6706069n%40googlegroups.com.
/*
* ls1046a target - linux-demo
*
* Copyright 2020 NXP
*
* Authors:
* Jiafei Pan
*
* This work is licensed under the terms of the GNU GPL, version 2. See
* the COPYING file in the top-level directory.
*/
#include
#include
struct {
struct jailhouse_system header;
__u64 cpus[1];
struct jailhouse_memory mem_regions[16];
struct jailhouse_irqchip irqchips[2];
struct jailhouse_pci_device pci_devices[2];
} __attribute__((packed)) config = {
.header = {
.signature = JAILHOUSE_SYSTEM_SIGNATURE,
.revision = JAILHOUSE_CONFIG_REVISION,
.flags = JAILHOUSE_SYS_VIRTUAL_DEBUG_CONSOLE,
.hypervisor_memory = {
.phys_start = 0xfba0,
.size = 0x0040,
},
.debug_console = {
.address = 0x21c0500,
.size = 0x100,
.type = JAILHOUSE_CON_TYPE_8250,
.flags = JAILHOUSE_CON_ACCESS_MMIO |
JAILHOUSE_CON_REGDIST_1,
},
.platform_info = {
.pci_mmconfig_base = 0xfb50,
.pci_mmconfig_end_bus = 0,
.pci_is_virtual = 1,
.pci_domain = -1,
.arm = {
.gic_version = 2,
.gicd_base = 0x141,
.gicc_base = 0x142f000,
.gich_base = 0x144,
.gicv_base = 0x146f000,
.maintenance_irq = 25,
},
},
.root_cell = {
.name = "ls1046",
.num_pci_devices = ARRAY_SIZE(config.pci_devices),
.cpu_set_size = sizeof(config.cpus),
.num_memory_regions = ARRAY_SIZE(config.mem_regions),
.num_irqchips = ARRAY_SIZE(config.irqchips),
.vpci_irq_base = 102-32, /* Not include 32 base */
},
},
.cpus = {
0xf,
},
.mem_regions = {
/* IVHSMEM shared memory region for 00:00.0 */ {
.phys_start = 0xfb70,
.virt_start = 0xfb70,
.size = 0x1000,
.flags = JAILHOUSE_MEM_READ,
},
{
.phys_start = 0xfb701000,
.virt_start = 0xfb701000,
.size = 0x9000,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
},
{
.phys_start = 0xfb70a000,
.virt_start = 0xfb70a000,
.size = 0x2000,
.flags = JAILHOUSE_MEM_READ,
},
{
.phys_start = 0xfb70c000,
.virt_start = 0xfb70c000,
.size = 0x2000,
.flags = JAILHOUSE_MEM_READ,
},
{
.phys_start = 0xfb70e000,
.virt_start = 0xfb70e000,
.size = 0x2000,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
},
/* IVSHMEM shared memory regions for 00:01.0 (networking) */
JAILHOUSE_SHMEM_NET_REGIONS(0xfb80, 1),
/* RAM - 1GB - root cell */ {
.phys_start = 0x8000,
.virt_start = 0x8000,
.size = 0x4000,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE,
},
/* RAM: Inmate */ {
.phys_start = 0xc000,
.virt_start = 0xc000,
.size = 0x3b50,
.flags = JAILHOUSE_MEM_READ |
