RE: zephyr ARM64 SMP runs on Jailhouse

2020-11-19 Thread Peng Fan 
> Subject: Re: zephyr ARM64 SMP runs on Jailhouse
> 
> On 19.11.20 03:50, Peng Fan wrote:
> > Just share info, we have enabled zephyr ARM64 SMP on Jailhouse using
> > i.MX8M
> >
> 
> This is great news, indeed! Do you need patches against Zephyr, or is
> upstream ready for this? Would it work in qemuarm64 as well?

Current upstream zephyr not support SMP, and only runs in secure world.
So I have some patches to make it run in normal world and SMP support.

I only did this on i.MX8MM EVK board. Qemuarm64 needs some porting
effort. Jailhouse also needs one minor patch as below:

@@ -364,15 +365,21 @@ static enum mmio_result gicv3_handle_redist_access(void 
*arg,
case GICR_SYNCR:
mmio->value = 0;
return MMIO_HANDLED;
-   case GICR_CTLR:
-   case GICR_STATUSR:
-   case GICR_WAKER:
case GICR_SGI_BASE + GICR_ISENABLER:
case GICR_SGI_BASE + GICR_ICENABLER:
case GICR_SGI_BASE + GICR_ISPENDR:
case GICR_SGI_BASE + GICR_ICPENDR:
case GICR_SGI_BASE + GICR_ISACTIVER:
case GICR_SGI_BASE + GICR_ICACTIVER:
+   if (this_cell() != cpu_public->cell) {
+   /* ignore access to foreign redistributors */
+   return MMIO_HANDLED;
+   }
+   mmio->value &= ~(SGI_MASK | (1 << mnt_irq));
+   break;
+   case GICR_CTLR:
+   case GICR_STATUSR:
+   case GICR_WAKER:
case REG_RANGE(GICR_SGI_BASE + GICR_IPRIORITYR, 8, 4):
case REG_RANGE(GICR_SGI_BASE + GICR_ICFGR, 2, 4):
if (this_cell() != cpu_public->cell) {


I'll prepare my zephyr patches to zephyr PR.

Regards,
Peng.

> 
> 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/DB6PR0402MB276009F841DA2D085725319688FF0%40DB6PR0402MB2760.eurprd04.prod.outlook.com.

Re: one question about MSI-X support for vPCI

2020-11-19 Thread Peter pan 
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 
> > . 
> > 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

2020-11-19 Thread Jan Kiszka 
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-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
> .

-- 
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/803d46bb-b51a-6fba-7bfc-3e6d2145a8cd%40siemens.com.

Re: zephyr ARM64 SMP runs on Jailhouse

2020-11-19 Thread Jan Kiszka 
On 19.11.20 03:50, Peng Fan wrote:
> Just share info, we have enabled zephyr ARM64 SMP on Jailhouse using i.MX8M
> 

This is great news, indeed! Do you need patches against Zephyr, or is
upstream ready for this? Would it work in qemuarm64 as well?

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/fd4ed87a-58b1-2767-8a28-f1ba335582d3%40siemens.com.