Re: virtual network interface on x86

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

Re: virtual network interface on x86

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

Hi Jan,

>From the above config, pci_mmconfig_base = 0x8000(2GB)  & phys_start = 
>0x40430, size is 0xC000 (1GB)Our hypervisor start addresses is 
>0x4(16Gb).
How will they conflict?
Regards,
Anil

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop

Re: virtual network interface on x86

2018-04-07 Thread Jan Kiszka 
On 2018-04-07 06:01, anilapp...@gmail.com wrote:
> Hi Henning,
> Thanks for understanding our issue for ready to help us. I want to inform one 
> more failure which we observed we after non rootcell bootup( it shows io 
> remap failed).
> 
> 
> 
> 0.403714] cpuidle: using governor ladder
> [0.412705] cpuidle: using governor menu
> [0.416813] PCI: Using configuration type 1 for base access
> [0.422401] PCI: ashok JH PCI MMCONFIG
> [0.426159] PCI: MMCONFIG for domain  [bus 00-ff] at [mem 
> 0x8000-0x8fff] (base 0x8000)
> [0.435469] [ cut here ]
> [0.440098] WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:121 
> __ioremap_caller+0x286/0x360
> [0.448536] ioremap on RAM at 0x8000 - 0x8fff
> [0.454974] Modules linked in:
> [0.458050] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> 4.9.47-rt37+-RedHawk-7.4-custom #27
> [0.466216]  c962bd10 8155da23 c962bd60 
> 
> [0.473666]  c962bd50 81077d1b 0079 
> 1000
> [0.481119]  0002 81d95e3f 8000 
> 
> [0.488573] Call Trace:
> [0.491021]  [] dump_stack+0x85/0xc2
> [0.496159]  [] __warn+0xcb/0xf0
> [0.500945]  [] ? pci_mmcfg_arch_map+0x2f/0x70
> [0.506947]  [] warn_slowpath_fmt+0x4f/0x60
> [0.512685]  [] __ioremap_caller+0x286/0x360
> [0.518510]  [] ? vprintk_default+0x29/0x40
> [0.524249]  [] ? printk+0x48/0x50
> [0.529213]  [] ? pcibios_resource_survey+0x70/0x70
> [0.535641]  [] ioremap_nocache+0x17/0x20
> [0.541205]  [] pci_mmcfg_arch_map+0x2f/0x70
> [0.547029]  [] pci_mmcfg_arch_init+0x1d/0x42
> [0.552941]  [] jailhouse_pci_arch_init+0x40/0x44
> [0.559197]  [] pci_arch_init+0x3b/0x66
> [0.564588]  [] do_one_initcall+0x50/0x190
> [0.570238]  [] ? parse_args+0x26a/0x3f0
> [0.575717]  [] kernel_init_freeable+0x1cf/0x257
> [0.581887]  [] ? rest_init+0x90/0x90
> [0.587102]  [] kernel_init+0xe/0x120
> [0.592321]  [] ret_from_fork+0x2a/0x40
> [0.597728] ---[ end trace 38a36dc7a73d77e3 ]---
> [0.602349] PCI: can't map MMCONFIG at [mem 0x8000-0x8fff]
> [0.609402] kworker/u4:4 (63) used greatest stack depth: 13512 bytes left
> 
> 
> I attached complete logs for your reference. we will try with what ever the 
> inputs you gave to us and will let you know. I am also sharing rootcell and 
> non root cell configs which we are using.

You configured a conflict here: The shared memory region is also a RAM
region for the cell.

Jan

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: virtual network interface on x86

2018-04-06 Thread Henning Schild 
Am Fri, 6 Apr 2018 09:12:00 -0700
schrieb :

> Hi Jan,
>   We are trying to establish the connection between root cell to
> non-root cell on x86 using ivshmem-net driver.
> 
> 
> we did below modifications in root cell and non root cell
> configurations.
> 
>   // PCI device
> {
> .type = JAILHOUSE_PCI_TYPE_IVSHMEM,
> .domain = 0x0,
> .bdf = 0x0e << 3,
> .bar_mask = {
> 0xff00, 0x, 0x,
> 0x, 0xffe0, 0x,
> },
> .num_msix_vectors = 1,
> .shmem_region = 3,

make sure that number is correct in the root-cell as well

Or actually make sure the hypervisor says
"Shared memory connection established"
After it said
"Adding virtual PCI device ..."

> .shmem_protocol = JAILHOUSE_SHMEM_PROTO_VETH,
> },
> 
> /* MemRegion: 40410 : IVSHMEM :JH-added */
> {
> .phys_start = 0x40410,
> .virt_start = 0x40410,
> .size = 0x10,
> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_ROOTSHARED,
> },

ROOTSHARED will only be required in the non-root cell, but should not
hurt the root cell either.

> After adding above changes, we are able to see the virtual network
> interface in non-root cell but it is not working(ping is not
> happening and we are not able to see the interrupts).
> 
> I am adding below logs for your reference.
> 
> 
> [root@localhost ~]# cat /proc/iomem
> .
>   0001-000100ff : ivshmem-net
> 00010100-0001011f : :00:0e.0
> 00040410-0004041f : ivshmem-net
> .
> 
> [root@localhost ~]# cat /proc/interrupts
>CPU0   CPU1
>   4:   1271  0   IO-APIC-4-fasteoi   serial
>  24:404  0   PCI-MSI-524288-edge  enp1s0f0
>  25:  0  0   PCI-MSI-229376-edge
> ivshmem-net[:00:0e.0]
> 
> 
> [rooot@localhost ~]# lspci -s 0e -vvv
> 00:0e.0 Unassigned class [ff01]: Red Hat, Inc Inter-VM shared memory
> Subsystem: Red Hat, Inc Inter-VM shared memory
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF-
> FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-  INTx- Latency: 0 Region 0: Memory at 1 (64-bit,
> non-prefetchable) [size=256] Region 4: Memory at 10100 (64-bit,
> non-prefetchable) [size=32] Capabilities: [50] MSI-X: Enable+ Count=1
> Masked- Vector table: BAR=4 offset=
> PBA: BAR=4 offset=0010
> Kernel driver in use: ivshmem-net
> lspci: Unable to load libkmod resources: error -12
> 
> 
> [root@localhost ~]# ifconfig -a
> enp0s14: flags=4163  mtu 16384
> inet 192.168.1.55  netmask 255.255.0.0  broadcast
> 192.168.255.255 ether 9a:28:41:e8:3b:14  txqueuelen 1000  (Ethernet)
> 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
> 
> enp1s0f0: flags=4163  mtu 1500
> inet 192.168.1.35  netmask 255.255.0.0  broadcast
> 192.168.255.255 inet6 fe80::21b:78ff:fe56:abec  prefixlen 64  scopeid
> 0x20 ether 00:1b:78:56:ab:ec  txqueuelen 1000  (Ethernet)
> RX packets 457  bytes 46827 (45.7 KiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 7  bytes 596 (596.0 B)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> device interrupt 11  memory 0xc72a-c72c  

Mhh two times on the same subnet and even a /16 one. Actually is one
of the two the one from ivshmem-net? enp0s14 looks like it

First make sure that one of the interfaces is added by ivshmem-net. You
should find information in "dmesg"
and /sys/bus/pci/drivers/ivshmem-net and you can compare with the state
before jailhouse startet.

Once you know which one is which, put it onto a different subnet before
pinging the non-root cell.
choose i.e. 192.168.1.0/24 and 192.168.2/24

Now the remote side should look similar. The mtu and packet counts look
weird, i guess it is not up yet. That could be because the non-root
side is not up and running or the configuration is not correct.

> Can you please help us to resolve.
> 
> we have below points which we need some input 
> 
> a. we want to know are we missing any configuration? 
> b. we used external NIC and configured to non rootcell. should we
> assign any physical NIC to non rootcell to make virtual network
> interface working?

No, you either assign hardware or use a

virtual network interface on x86

2018-04-06 Thread anilappana 
Hi Jan,
  We are trying to establish the connection between root cell to non-root cell 
on x86 using ivshmem-net driver.


we did below modifications in root cell and non root cell configurations.

  // PCI device
{
.type = JAILHOUSE_PCI_TYPE_IVSHMEM,
.domain = 0x0,
.bdf = 0x0e << 3,
.bar_mask = {
0xff00, 0x, 0x,
0x, 0xffe0, 0x,
},
.num_msix_vectors = 1,
.shmem_region = 3,
.shmem_protocol = JAILHOUSE_SHMEM_PROTO_VETH,
},

/* MemRegion: 40410 : IVSHMEM :JH-added */
{
.phys_start = 0x40410,
.virt_start = 0x40410,
.size = 0x10,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
 JAILHOUSE_MEM_ROOTSHARED,
},


After adding above changes, we are able to see the virtual network interface in 
non-root cell but it is not working(ping is not happening and we are not able 
to see the interrupts).

I am adding below logs for your reference.


[root@localhost ~]# cat /proc/iomem
.
  0001-000100ff : ivshmem-net
00010100-0001011f : :00:0e.0
00040410-0004041f : ivshmem-net
.

[root@localhost ~]# cat /proc/interrupts
   CPU0   CPU1
  4:   1271  0   IO-APIC-4-fasteoi   serial
 24:404  0   PCI-MSI-524288-edge  enp1s0f0
 25:  0  0   PCI-MSI-229376-edge  ivshmem-net[:00:0e.0]


[rooot@localhost ~]# lspci -s 0e -vvv
00:0e.0 Unassigned class [ff01]: Red Hat, Inc Inter-VM shared memory
Subsystem: Red Hat, Inc Inter-VM shared memory
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-   mtu 16384
inet 192.168.1.55  netmask 255.255.0.0  broadcast 192.168.255.255
ether 9a:28:41:e8:3b:14  txqueuelen 1000  (Ethernet)
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

enp1s0f0: flags=4163  mtu 1500
inet 192.168.1.35  netmask 255.255.0.0  broadcast 192.168.255.255
inet6 fe80::21b:78ff:fe56:abec  prefixlen 64  scopeid 0x20
ether 00:1b:78:56:ab:ec  txqueuelen 1000  (Ethernet)
RX packets 457  bytes 46827 (45.7 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 7  bytes 596 (596.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 11  memory 0xc72a-c72c  

Can you please help us to resolve.

we have below points which we need some input 

a. we want to know are we missing any configuration? 
b. we used external NIC and configured to non rootcell. should we assign any 
physical NIC to non rootcell to make virtual network interface working?
c.we didn't see that increment in interrupt count. Are we missing any thing 
here?

Regards,
Anil 




-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.