from:"Luca Cuomo"

Re: Issue with large inmates on TX2

2018-11-05 Thread Luca Cuomo

Ok, i'll try to move  some virtual address in order to avoid overlapping.
Thanks for the moment.
I'll let you know.

Il giorno lun 5 nov 2018 alle ore 11:31 Jan Kiszka 
ha scritto:

> On 05.11.18 11:25, Luca Cuomo wrote:
> >   .mem_regions = {
> >   /* UART */ {
> >   .phys_start = 0x310,
> >   .virt_start = 0x310,
> >   .size = 0x2,
> >   .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> >   JAILHOUSE_MEM_IO |
> JAILHOUSE_MEM_ROOTSHARED,
> >   },
> >   /* RAM */ {
> >   .phys_start = 0x26d00,
> >   .virt_start = 0,
> >   .size = 0x400,
> >   .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> >   JAILHOUSE_MEM_EXECUTE |
> JAILHOUSE_MEM_LOADABLE,
> >   },
>
> Now I see it: Your memory regions is overlapping the UART region in
> guest-physical address space. That's why we tend to split that for the
> Linux
> cells into two regions, having only a tiny boot-up region at address 0.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>


-- 
Luca Cuomo.
Software Engineer

Evidence Srl
Via Carducci 56
56010 S.Giuliano Terme - Pisa - Italy
Phone:  +39 050 99 11 122
Mail: l.cu...@evidence.eu.com
Web: http://www.evidence.eu.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.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with large inmates on TX2

2018-11-05 Thread Luca Cuomo

The version was alread at v0.10
(commit  f596aa7355bc2134650544bdf1e13f1f55d3f2fc).
While porting the cell from v0.9.1, i forgot to add console configuration
in the inmate. Now i've added it but the behaviour is the same.



Il giorno lun 5 nov 2018 alle ore 10:57 Jan Kiszka 
ha scritto:

> What's your Jailhouse version? Seems it's not the last release because you
> are
> not defining the console of the non-root cell. Please update Jailhouse
> first,
> specifically due to
>
> https://github.com/siemens/jailhouse/commit/932556921b07121e6ce19573ba3efa97615a41ff
> .
>
> Jan
>
> On 05.11.18 10:49, Luca Cuomo wrote:
> > Of course,
> >
> > Il giorno lun 5 nov 2018 alle ore 09:40 Jan Kiszka <
> jan.kis...@siemens.com
> > <mailto:jan.kis...@siemens.com>> ha scritto:
> >
> > On 05.11.18 09:22, Luca Cuomo wrote:
> >  > Hi Jan,
> >  > Il giorno mer 31 ott 2018 alle ore 19:23 Jan Kiszka
> > mailto:jan.kis...@siemens.com>
> >  > <mailto:jan.kis...@siemens.com <mailto:jan.kis...@siemens.com>>>
> ha scritto:
> >  >
> >  > On 31.10.18 16:42, Luca Cuomo wrote:
> >  >  > Dear all,
> >  >  >
> >  >  > we've encountered an issue when running inmates with more
> than 32
> > MB of RAM
> >  >  > (e.g. 64 MB) on Jetson TX2.
> >  >  >
> >  >  > We've tried using the Linux kernel 4.16.7 Vanilla, the
> latest
> > version of
> >  >  > jailhouse (v0.10) and gic-demo.
> >  >  >
> >  >  > We've attached a JTAG debugger and we've seen that the
> inmate is
> > running but
> >  >  > there are two problems:
> >  >  >   - No output is sent to the serial console
> >  >  >   - No interrupts arrives to the cell (checked with both
> cell
> > stats and the
> >  >  > checking the program counter)
> >  >  >
> >  >  > No error messages on the Jailhouse console nor on the
> dmesg.
> >  >  >
> >  >  > Is anybody able of running large inmates ?
> >  >  >
> >  >
> >  > What did you change? The cell configurations? The image size
> you load
> > (larger
> >  > initrd etc.)?
> >  >
> >  > Maybe there is an issue with the loader
> (jailhouse-cell-linux) in
> > calculating
> >  > where to put things. Try playing with the
> --kernel-decomp-factor in
> > case you
> >  > increased the size of the loaded images.
> >  >
> >  > The kernel attributes i described are referred to the system
> kernel (root
> > cell).
> >  > I've no tried a linux inmate  but a simple bare metal demo which
> doesn't work
> >  > when the RAM in the .cell is 64MB. I've updated the map_range
> call on the
> > RAM
> >  > in  mem.c indeed.
> >
> > Can you share your configs, or even just the diff to the upstream
> configs?
> >
> > Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux
> >
> >
> >
> > --
> > Luca Cuomo.
> > Software Engineer
> >
> > Evidence Srl
> > Via Carducci 56
> > 56010 S.Giuliano Terme - Pisa - Italy
> > Phone:  +39 050 99 11 122
> > Mail: l.cu...@evidence.eu.com <mailto:l.cu...@evidence.eu.com>
> > Web:http://www.evidence.eu.com <http://www.evidence.eu.com/>
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>


-- 
Luca Cuomo.
Software Engineer

Evidence Srl
Via Carducci 56
56010 S.Giuliano Terme - Pisa - Italy
Phone:  +39 050 99 11 122
Mail: l.cu...@evidence.eu.com
Web: http://www.evidence.eu.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.
For more options, visit https://groups.google.com/d/optout.
/*
 * Jailhouse, a Linux-based partitioning hypervisor
 *
 * Configuration for gic-demo or uart-demo inmate on Nvidia Jetson TX2:
 * 1 CPU, 64 MB RAM, serial port 0
 */

#include 
#include 

#define ARRAY_SIZE(a) sizeof(a) / sizeof(a[0])

struct {
	struct jailhouse_cell_desc cell;
	__u64 cpus[1];
	struct jailhouse_memory mem_regions[4];
	struct jailhouse_irqc

Re: Issue with large inmates on TX2

2018-11-05 Thread Luca Cuomo

Of course,

Il giorno lun 5 nov 2018 alle ore 09:40 Jan Kiszka 
ha scritto:

> On 05.11.18 09:22, Luca Cuomo wrote:
> > Hi Jan,
> > Il giorno mer 31 ott 2018 alle ore 19:23 Jan Kiszka <
> jan.kis...@siemens.com
> > <mailto:jan.kis...@siemens.com>> ha scritto:
> >
> > On 31.10.18 16:42, Luca Cuomo wrote:
> >  > Dear all,
> >  >
> >  > we've encountered an issue when running inmates with more than 32
> MB of RAM
> >  > (e.g. 64 MB) on Jetson TX2.
> >  >
> >  > We've tried using the Linux kernel 4.16.7 Vanilla, the latest
> version of
> >  > jailhouse (v0.10) and gic-demo.
> >  >
> >  > We've attached a JTAG debugger and we've seen that the inmate is
> running but
> >  > there are two problems:
> >  >   - No output is sent to the serial console
> >  >   - No interrupts arrives to the cell (checked with both cell
> stats and the
> >  > checking the program counter)
> >  >
> >  > No error messages on the Jailhouse console nor on the dmesg.
> >  >
> >  > Is anybody able of running large inmates ?
> >  >
> >
> > What did you change? The cell configurations? The image size you
> load (larger
> > initrd etc.)?
> >
> > Maybe there is an issue with the loader (jailhouse-cell-linux) in
> calculating
> > where to put things. Try playing with the --kernel-decomp-factor in
> case you
> > increased the size of the loaded images.
> >
> > The kernel attributes i described are referred to the system kernel
> (root cell).
> > I've no tried a linux inmate  but a simple bare metal demo which doesn't
> work
> > when the RAM in the .cell is 64MB. I've updated the map_range call on
> the RAM
> > in  mem.c indeed.
>
> Can you share your configs, or even just the diff to the upstream configs?
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>


-- 
Luca Cuomo.
Software Engineer

Evidence Srl
Via Carducci 56
56010 S.Giuliano Terme - Pisa - Italy
Phone:  +39 050 99 11 122
Mail: l.cu...@evidence.eu.com
Web: http://www.evidence.eu.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.
For more options, visit https://groups.google.com/d/optout.
/*
 * Jailhouse, a Linux-based partitioning hypervisor
 *
 * Configuration for Jailhouse Jetson TX2 board
 *
 * Copyright (C) 2018 Evidence Srl
 *
 * Authors:
 *  Claudio Scordino 
 *  Luca Cuomo 
 *
 *
 * NOTE: Add "mem=7808M vmalloc=512M" to the kernel command line.
 *
 *	2:7800: inmate (size: 400: = 64 MB)
 *	2:7100: hypervisor (size: 400: = 64 MB)
 *
 */

#include 
#include 

#define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))

struct {
	struct jailhouse_system header;
	__u64 cpus[1];
	struct jailhouse_memory mem_regions[64];
	struct jailhouse_irqchip irqchips[3];
} __attribute__((packed)) config = {
	.header = {
		.signature = JAILHOUSE_SYSTEM_SIGNATURE,
		.revision = JAILHOUSE_CONFIG_REVISION,
		.hypervisor_memory = {
			.phys_start = 0x27100,
			.size = 0x400,
		},
		.debug_console = {
			.address = 0x310,
			.size = 0x1,
			.type = JAILHOUSE_CON_TYPE_8250,
			.flags = JAILHOUSE_CON_ACCESS_MMIO |
 JAILHOUSE_CON_REGDIST_4,
		},

		.platform_info = {
			/* .pci_mmconfig_base is fixed; if you change it,
 update the value in inmates/lib/arm-common/pci.c
 (PCI_CFG_BASE) and regenerate the inmate library*/
.pci_mmconfig_base = 0x4000, 
.pci_mmconfig_end_bus = 0x0,
.pci_is_virtual = 1,

			.arm = {
.gicd_base = 0x03881000,
.gicc_base = 0x03882000,
.gich_base = 0x03884000,
.gicv_base = 0x03886000,
.gic_version = 2,
.maintenance_irq = 25,
			}
		},
		.root_cell = {
			.name = "jetson-tx2-root",
			.cpu_set_size = sizeof(config.cpus),
			.num_memory_regions = ARRAY_SIZE(config.mem_regions),
			.num_irqchips = ARRAY_SIZE(config.irqchips),
			.vpci_irq_base = 288,
		},
	},

	.cpus = {
		0x39,
	},


	.mem_regions = {
		/* BPMP_ATCM */ {
.phys_start = 0x,
.virt_start = 0x,
.size = 0x4,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE,
},

		/* MISC */ {
.phys_start = 0x0010,

Re: Issue with large inmates on TX2

2018-11-05 Thread Luca Cuomo

Hi Jan,
Il giorno mer 31 ott 2018 alle ore 19:23 Jan Kiszka 
ha scritto:

> On 31.10.18 16:42, Luca Cuomo wrote:
> > Dear all,
> >
> > we've encountered an issue when running inmates with more than 32 MB of
> RAM
> > (e.g. 64 MB) on Jetson TX2.
> >
> > We've tried using the Linux kernel 4.16.7 Vanilla, the latest version of
> > jailhouse (v0.10) and gic-demo.
> >
> > We've attached a JTAG debugger and we've seen that the inmate is running
> but
> > there are two problems:
> >   - No output is sent to the serial console
> >   - No interrupts arrives to the cell (checked with both cell stats and
> the
> > checking the program counter)
> >
> > No error messages on the Jailhouse console nor on the dmesg.
> >
> > Is anybody able of running large inmates ?
> >
>
> What did you change? The cell configurations? The image size you load
> (larger
> initrd etc.)?
>
> Maybe there is an issue with the loader (jailhouse-cell-linux) in
> calculating
> where to put things. Try playing with the --kernel-decomp-factor in case
> you
> increased the size of the loaded images.
>
> The kernel attributes i described are referred to the system kernel (root
cell). I've no tried a linux inmate  but a simple bare metal demo which
doesn't work
when the RAM in the .cell is 64MB. I've updated the map_range call on the
RAM in  mem.c indeed.

Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

Regards,

-- 
Luca Cuomo.
Software Engineer

Evidence Srl
Via Carducci 56
56010 S.Giuliano Terme - Pisa - Italy
Phone:  +39 050 99 11 122
Mail: l.cu...@evidence.eu.com
Web: http://www.evidence.eu.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.
For more options, visit https://groups.google.com/d/optout.

Issue with large inmates on TX2

2018-10-31 Thread Luca Cuomo

Dear all,

we've encountered an issue when running inmates with more than 32 MB of RAM
(e.g. 64 MB) on Jetson TX2.

We've tried using the Linux kernel 4.16.7 Vanilla, the latest version of
jailhouse (v0.10) and gic-demo.

We've attached a JTAG debugger and we've seen that the inmate is running
but there are two problems:
 - No output is sent to the serial console
 - No interrupts arrives to the cell (checked with both cell stats and the
checking the program counter)

No error messages on the Jailhouse console nor on the dmesg.

Is anybody able of running large inmates ?

Many thanks and best regards,

   Luca

-- 
Luca Cuomo.
Software Engineer

Evidence Srl
Via Carducci 56
56010 S.Giuliano Terme - Pisa - Italy
Phone:  +39 050 99 11 122
Mail: l.cu...@evidence.eu.com
Web: http://www.evidence.eu.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.
For more options, visit https://groups.google.com/d/optout.

[PATCH 0/2] IVSHMEM support for arm64

2018-05-10 Thread Luca Cuomo

This patchset adds the support for IVSHMEM on arm64 platforms.
The mechanism has been succesfully tested on a Jetson TX2 platform.
The patch is a porting of the previous work by Jonas Westaker
(https://groups.google.com/forum/#!topic/jailhouse-dev/IqwQsQ9JEno).

Luca Cuomo (2):
  Added IVSHMEM support to arm/aarch64
  Jetson TX2: IVSHMEM support in cells

 configs/arm64/jetson-tx2-demo.c |  65 ++-
 configs/arm64/jetson-tx2.c  |  66 +++-
 inmates/demos/arm/Makefile  |   3 +-
 inmates/demos/arm/ivshmem-demo.c| 185 
 inmates/demos/arm64/Makefile|   3 +-
 inmates/lib/arm-common/Makefile.lib |   1 +
 inmates/lib/arm-common/include/inmate.h |  41 +++
 inmates/lib/arm-common/pci.c| 119 
 inmates/lib/pci.c   |   9 +-
 9 files changed, 483 insertions(+), 9 deletions(-)
 create mode 100644 inmates/demos/arm/ivshmem-demo.c
 create mode 100644 inmates/lib/arm-common/pci.c

-- 
2.7.4

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

[PATCH 2/2] Jetson TX2: IVSHMEM support in cells

2018-05-10 Thread Luca Cuomo

Signed-off-by: Luca Cuomo <l.cu...@evidence.eu.com>
---
 configs/arm64/jetson-tx2-demo.c | 65 ++--
 configs/arm64/jetson-tx2.c  | 66 ++---
 2 files changed, 125 insertions(+), 6 deletions(-)

diff --git a/configs/arm64/jetson-tx2-demo.c b/configs/arm64/jetson-tx2-demo.c
index 93b3fbf..0fbbac8 100644
--- a/configs/arm64/jetson-tx2-demo.c
+++ b/configs/arm64/jetson-tx2-demo.c
@@ -16,16 +16,20 @@
 struct {
struct jailhouse_cell_desc cell;
__u64 cpus[1];
-   struct jailhouse_memory mem_regions[3];
+   struct jailhouse_memory mem_regions[5];
+   struct jailhouse_irqchip irqchips[1];
+   struct jailhouse_pci_device pci_devices[2];
 } __attribute__((packed)) config = {
.cell = {
.signature = JAILHOUSE_CELL_DESC_SIGNATURE,
.revision = JAILHOUSE_CONFIG_REVISION,
.name = "jetson-tx2-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 = 300,
},
 
.cpus = {
@@ -47,6 +51,21 @@ struct {
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_LOADABLE,
},
+   /* IVHSMEM  1*/ {
+.phys_start = 0x27500,
+.virt_start = 0x27500,
+.size = 0x1000,
+.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
+   JAILHOUSE_MEM_ROOTSHARED,
+
+},
+/* IVHSMEM  2*/ {
+.phys_start = 0x27520,
+.virt_start = 0x27520,
+.size = 0x1000,
+.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
+   JAILHOUSE_MEM_ROOTSHARED,
+},
/* communication region */ {
.virt_start = 0x8000,
.size = 0x1000,
@@ -54,4 +73,46 @@ struct {
JAILHOUSE_MEM_COMM_REGION,
},
},
+   .irqchips = {
+   /* GIC */
+   {
+   .address = 0x03881000,
+   .pin_base = 288,
+   .pin_bitmap = {
+   0,
+   3 << (332 - 320) /* irq 332 and 333 */
+   },
+   },
+   },
+   .pci_devices = {
+{
+.type = JAILHOUSE_PCI_TYPE_IVSHMEM,
+.bdf = 0x0 << 3,
+.bar_mask = {
+0xff00, 0x, 0x,
+0x, 0x, 0x,
+},
+
+/*num_msix_vectors needs to be 0 for INTx operation*/
+.num_msix_vectors = 0,
+.shmem_region = 2,
+.shmem_protocol = JAILHOUSE_SHMEM_PROTO_UNDEFINED,
+.domain = 0x0,
+},
+
+{
+.type = JAILHOUSE_PCI_TYPE_IVSHMEM,
+.bdf = 0xf << 3,
+.bar_mask = {
+0xff00, 0x, 0x,
+0x, 0x, 0x,
+},
+
+/*num_msix_vectors needs to be 0 for INTx operation*/
+.num_msix_vectors = 0,
+.shmem_region = 3,
+.shmem_protocol = JAILHOUSE_SHMEM_PROTO_UNDEFINED,
+   .domain = 0x0,
+},
+},
 };
diff --git a/configs/arm64/jetson-tx2.c b/configs/arm64/jetson-tx2.c
index 2350362..1d29426 100644
--- a/configs/arm64/jetson-tx2.c
+++ b/configs/arm64/jetson-tx2.c
@@ -26,8 +26,9 @@
 struct {
struct jailhouse_system header;
__u64 cpus[1];
-   struct jailhouse_memory mem_regions[61];
+   struct jailhouse_memory mem_regions[64];
struct jailhouse_irqchip irqchips[3];
+   struct jailhouse_pci_device pci_devices[2];
 } __attribute__((packed)) config = {
.header = {
.signature = JAILHOUSE_SYSTEM_SIGNATURE,
@@ -45,6 +46,12 @@ struct {
 JAILHOUSE_CON2_TYPE_ROOTPAGE,
},
.platform_info = {
+   /* .pci_mmconfig_base is fixed; if you change it,
+ update the val

Re: Share memory among cells on arm64

2018-04-16 Thread Luca Cuomo

Hi,
at a first look the configuration looks ok for me.

Il giorno giovedì 12 aprile 2018 19:49:09 UTC+2, Giovani Gracioli ha scritto:
> Hello,
> 
> Thank you for the answers.
> 
> My comments are below.
> 
> 1) The root config is defined as follows (copied only the relevant parts):
> 
> .platform_info = {
> .pci_mmconfig_base = 0xfc00,
> .pci_mmconfig_end_bus = 0,
> .pci_is_virtual = 1,
> .arm = {
> .gic_version = 2,
> .gicd_base = 0xf901,
> .gicc_base = 0xf902f000,
> .gich_base = 0xf904,
> .gicv_base = 0xf906f000,
> .maintenance_irq = 25,
> },
> },
> 
> .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 = 0x0,
> .virt_start = 0x0,
> .size = 0x8000,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_EXECUTE,
> },
> /* RAM */ {
> .phys_start = 0x80060,
> .virt_start = 0x80060,
> .size = 0x7fa0,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_EXECUTE,
> },
> /* IVSHMEM shared memory region for 00:00.0 */ {
> .phys_start = 0x80040,
> .virt_start = 0x80040,
> .size = 0x10,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | 
> JAILHOUSE_MEM_ROOTSHARED,
> },
> /* IVSHMEM shared memory region for 00:01.0 */ {
> .phys_start = 0x80050,
> .virt_start = 0x80050,
> .size = 0x10,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | 
> JAILHOUSE_MEM_ROOTSHARED,
> },
> },
> 
> 
> .pci_devices = {
> /* 00:00.0 */ {
> .type = JAILHOUSE_PCI_TYPE_IVSHMEM,
> .bdf = 0 << 3,
> .bar_mask = {
> 0xff00, 0x, 0x,
> 0x, 0x, 0x,
> },
> .shmem_region = 3,
> .shmem_protocol = JAILHOUSE_SHMEM_PROTO_UNDEFINED, 
> .num_msix_vectors = 0, 
> .domain = 0x,
> },
> /* 00:01.0 */ {
> .type = JAILHOUSE_PCI_TYPE_IVSHMEM,
> .bdf = 1 << 3,
> .bar_mask = {
> 0xff00, 0x, 0x,
> 0x, 0x, 0x,
> },
> .shmem_region = 4,
> .shmem_protocol = JAILHOUSE_SHMEM_PROTO_UNDEFINED,
> .num_msix_vectors = 0,
> .domain = 0x,
> },
> },
> 
> For the other inmate cell, the config is defined as follows:
> 
> .mem_regions = {
> /* UART */ {
> .phys_start = 0xff01,
> .virt_start = 0xff01,
> .size = 0x1000,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_IO | JAILHOUSE_MEM_ROOTSHARED,
> },
> /* RAM */ {
> .phys_start = 0x80060,
> .virt_start = 0,
> .size = 0x0001,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_EXECUTE | 
> JAILHOUSE_MEM_LOADABLE,
> },
> /* IVSHMEM shared memory region for 00:00.0 */ {
> .phys_start = 0x80040,
> .virt_start = 0x80040,
> .size = 0x10,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | 
> JAILHOUSE_MEM_ROOTSHARED,
> },
> },
> 
>

Re: Share memory among cells on arm64

2018-04-12 Thread Luca Cuomo

Il giorno giovedì 12 aprile 2018 08:51:39 UTC+2, Claudio Scordino ha scritto:
> Hi Giovani,
> 
> 
> 
> 
> 2018-04-12 8:01 GMT+02:00 Jan Kiszka :
> On 2018-04-11 19:40, Giovani Gracioli wrote:
> 
> > Here is the output of the unhandled data read:
> 
> >
> 
> > Unhandled data read at 0xfc10(2)
> 
> >
> 
> > FATAL: unhandled trap (exception class 0x24)
> 
> > Cell state before exception:
> 
> >  pc: 1828   lr: 15f0 spsr: 6005     EL1
> 
> >  sp: 3f30  esr: 24 1 146
> 
> >  x0: fc10   x1:    x2: 0002
> 
> >  x3: fc00   x4:    x5: 
> 
> >  x6: 1000   x7:    x8: 
> 
> >  x9:   x10:   x11: 
> 
> > x12:   x13:   x14: 
> 
> > x15:   x16:   x17: 
> 
> > x18:   x19: 1000  x20: 
> 
> > x21: 1af4  x22: 1110  x23: 1000
> 
> > x24: 2660  x25:   x26: 
> 
> > x27:   x28:   x29: 
> 
> >
> 
> > Parking CPU 3 (Cell: "gic-demo-ivshmem")
> 
> >
> 
> > Am I missing something in the configuration?
> 
> 
> 
> Possibly. As this is code of Claudio and his colleagues, he may answer
> 
> this better.
> 
> 
> 
> A collegue of mine is looking at your issue.
> 
> 
> BTW, we plan to have a version of the PCI stuff rebased upstream in a couple 
> of weeks.
> 
> We'll post it on the ML once ready.
> 
> 
> Regards,
> 
> 
>    Claudio

Hi all,

i'm trying to understand what's wrong in the configuration.
1. The PCI configuration of the root cell (and its relative shared memory 
region ) needs a counterpart in the inmate configuration. The two PCI must have 
the same bdf. In fact when the configuration is ok, jailhouse prints on the 
screen che binding between the PCI devices.

2. The starting search address of the inmate library (#define PCI_CFG_BASE in 
inmates/lib/arm-common/pci.c) must be the same of the platform_info section in 
the root cell configuration (  
.platform_info = {
.pci_mmconfig_base = 0x4800,
.pci_mmconfig_end_bus = 0x0,
.pci_is_virtual = 1,
.
)

3. The best way to access the shared memory region from linux is using the 
uio_ivshmem driver. It works correctly on ARM64. It just needs the UIO kernel 
module as dependency. Once loaded, you can see memory infos in 
/sys/class/uio/uio0/maps[0,1] which are shmem informations and bar information. 

Regards,

--Luca

-- 
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: Running ivshmem-demo in Jetson TK1.

2017-12-22 Thread Luca Cuomo

Il giorno venerdì 22 dicembre 2017 12:54:52 UTC+1, jonas ha scritto:
> Den fredag 22 december 2017 kl. 10:32:12 UTC+1 skrev Luca Cuomo:
> > Il giorno giovedì 21 dicembre 2017 23:47:39 UTC+1, jonas ha scritto:
> > > Den torsdag 21 december 2017 kl. 17:24:30 UTC+1 skrev Jan Kiszka:
> > > > On 2017-12-21 16:32, Luca Cuomo wrote:
> > > > > Il giorno giovedì 21 dicembre 2017 14:19:48 UTC+1, Jan Kiszka ha 
> > > > > scritto:
> > > > >> On 2017-12-21 10:05, Luca Cuomo wrote:
> > > > >>> Il giorno domenica 10 dicembre 2017 17:34:24 UTC+1, jonas ha 
> > > > >>> scritto:
> > > > >>>> Hi,
> > > > >>>>
> > > > >>>> I'll be making an effort to contribute my work to the master 
> > > > >>>> branch of Jailhouse within the next couple of weeks.
> > > > >>>>
> > > > >>>> /Jonas
> > > > >>>>
> > > > >>>> Den fredag 8 december 2017 kl. 06:47:33 UTC+1 skrev Constantin 
> > > > >>>> Petra:
> > > > >>>>> Hi,
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> I'm resending the patch(es) that were shared by Jonas a while ago.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> Best Regards,
> > > > >>>>> Constantin
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> On Thu, Dec 7, 2017 at 10:08 PM, Henning Schild 
> > > > >>>>> <henning...@siemens.com> wrote:
> > > > >>>>> Hi Claudio,
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> Am Thu, 7 Dec 2017 17:29:45 +0100
> > > > >>>>>
> > > > >>>>> schrieb Claudio Scordino <cla...@evidence.eu.com>:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>> Hi guys,
> > > > >>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>> 2017-08-09 15:23 GMT+02:00 Henning Schild
> > > > >>>>>
> > > > >>>>>> <henning...@siemens.com>:
> > > > >>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>>> Hey,
> > > > >>>>>
> > > > >>>>>>>
> > > > >>>>>
> > > > >>>>>>> unfortunately Jonas never published his overall changes, maybe 
> > > > >>>>>>> now
> > > > >>>>>
> > > > >>>>>>> he understands why i kindly asked him to do so.
> > > > >>>>>
> > > > >>>>>>> I think Jonas maybe ran into every single problem one could
> > > > >>>>>
> > > > >>>>>>> encounter on the way, so if you read the thread you will 
> > > > >>>>>>> probably
> > > > >>>>>
> > > > >>>>>>> be able to come up with a similar patch at some point. That 
> > > > >>>>>>> would
> > > > >>>>>
> > > > >>>>>>> be the duplication of efforts, getting a first working patch 
> > > > >>>>>>> into a
> > > > >>>>>
> > > > >>>>>>> mergeable form is another story.
> > > > >>>>>
> > > > >>>>>>>
> > > > >>>>>
> > > > >>>>>>> If there are legal reasons to not publish code on the list i 
> > > > >>>>>>> suggest
> > > > >>>>>
> > > > >>>>>>> you exchange patches between each other. But of cause i would 
> > > > >>>>>>> like
> > > > >>>>>
> > > > >>>>>>> to see contributions eventually ;).
> > > > >>>>>
> > > > >

Re: Running ivshmem-demo in Jetson TK1.

2017-12-22 Thread Luca Cuomo

Il giorno giovedì 21 dicembre 2017 23:47:39 UTC+1, jonas ha scritto:
> Den torsdag 21 december 2017 kl. 17:24:30 UTC+1 skrev Jan Kiszka:
> > On 2017-12-21 16:32, Luca Cuomo wrote:
> > > Il giorno giovedì 21 dicembre 2017 14:19:48 UTC+1, Jan Kiszka ha scritto:
> > >> On 2017-12-21 10:05, Luca Cuomo wrote:
> > >>> Il giorno domenica 10 dicembre 2017 17:34:24 UTC+1, jonas ha scritto:
> > >>>> Hi,
> > >>>>
> > >>>> I'll be making an effort to contribute my work to the master branch of 
> > >>>> Jailhouse within the next couple of weeks.
> > >>>>
> > >>>> /Jonas
> > >>>>
> > >>>> Den fredag 8 december 2017 kl. 06:47:33 UTC+1 skrev Constantin Petra:
> > >>>>> Hi,
> > >>>>>
> > >>>>>
> > >>>>> I'm resending the patch(es) that were shared by Jonas a while ago.
> > >>>>>
> > >>>>>
> > >>>>> Best Regards,
> > >>>>> Constantin
> > >>>>>
> > >>>>>
> > >>>>> On Thu, Dec 7, 2017 at 10:08 PM, Henning Schild 
> > >>>>> <henning...@siemens.com> wrote:
> > >>>>> Hi Claudio,
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Am Thu, 7 Dec 2017 17:29:45 +0100
> > >>>>>
> > >>>>> schrieb Claudio Scordino <cla...@evidence.eu.com>:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> Hi guys,
> > >>>>>
> > >>>>>>
> > >>>>>
> > >>>>>> 2017-08-09 15:23 GMT+02:00 Henning Schild
> > >>>>>
> > >>>>>> <henning...@siemens.com>:
> > >>>>>
> > >>>>>>
> > >>>>>
> > >>>>>>> Hey,
> > >>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>>> unfortunately Jonas never published his overall changes, maybe now
> > >>>>>
> > >>>>>>> he understands why i kindly asked him to do so.
> > >>>>>
> > >>>>>>> I think Jonas maybe ran into every single problem one could
> > >>>>>
> > >>>>>>> encounter on the way, so if you read the thread you will probably
> > >>>>>
> > >>>>>>> be able to come up with a similar patch at some point. That would
> > >>>>>
> > >>>>>>> be the duplication of efforts, getting a first working patch into a
> > >>>>>
> > >>>>>>> mergeable form is another story.
> > >>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>>> If there are legal reasons to not publish code on the list i suggest
> > >>>>>
> > >>>>>>> you exchange patches between each other. But of cause i would like
> > >>>>>
> > >>>>>>> to see contributions eventually ;).
> > >>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>> We need to run IVSHMEM on the TX1.
> > >>>>>
> > >>>>>> Any chance of upstreaming those patches to not waste time
> > >>>>>
> > >>>>>> re-inventing the wheel ?
> > >>>>>
> > >>>>>> If that's not possible, please send me a copy privately.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Unfortunately i do not have those patches either. I am afraid someone
> > >>>>>
> > >>>>> will have to do that over again.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> But the whole thread is basically about enabling the demo, which is
> > >>>>>
> > >>>>> interesting for people just getting started with ivshmem. And for
> > >>>>>
> > >>>>> people that want to implement their own protocol on top of it

Re: Running ivshmem-demo in Jetson TK1.

2017-12-21 Thread Luca Cuomo

Il giorno giovedì 21 dicembre 2017 14:19:48 UTC+1, Jan Kiszka ha scritto:
> On 2017-12-21 10:05, Luca Cuomo wrote:
> > Il giorno domenica 10 dicembre 2017 17:34:24 UTC+1, jonas ha scritto:
> >> Hi,
> >>
> >> I'll be making an effort to contribute my work to the master branch of 
> >> Jailhouse within the next couple of weeks.
> >>
> >> /Jonas
> >>
> >> Den fredag 8 december 2017 kl. 06:47:33 UTC+1 skrev Constantin Petra:
> >>> Hi,
> >>>
> >>>
> >>> I'm resending the patch(es) that were shared by Jonas a while ago.
> >>>
> >>>
> >>> Best Regards,
> >>> Constantin
> >>>
> >>>
> >>> On Thu, Dec 7, 2017 at 10:08 PM, Henning Schild <henning...@siemens.com> 
> >>> wrote:
> >>> Hi Claudio,
> >>>
> >>>
> >>>
> >>> Am Thu, 7 Dec 2017 17:29:45 +0100
> >>>
> >>> schrieb Claudio Scordino <cla...@evidence.eu.com>:
> >>>
> >>>
> >>>
> >>>> Hi guys,
> >>>
> >>>>
> >>>
> >>>> 2017-08-09 15:23 GMT+02:00 Henning Schild
> >>>
> >>>> <henning...@siemens.com>:
> >>>
> >>>>
> >>>
> >>>>> Hey,
> >>>
> >>>>>
> >>>
> >>>>> unfortunately Jonas never published his overall changes, maybe now
> >>>
> >>>>> he understands why i kindly asked him to do so.
> >>>
> >>>>> I think Jonas maybe ran into every single problem one could
> >>>
> >>>>> encounter on the way, so if you read the thread you will probably
> >>>
> >>>>> be able to come up with a similar patch at some point. That would
> >>>
> >>>>> be the duplication of efforts, getting a first working patch into a
> >>>
> >>>>> mergeable form is another story.
> >>>
> >>>>>
> >>>
> >>>>> If there are legal reasons to not publish code on the list i suggest
> >>>
> >>>>> you exchange patches between each other. But of cause i would like
> >>>
> >>>>> to see contributions eventually ;).
> >>>
> >>>>>
> >>>
> >>>>>
> >>>
> >>>> We need to run IVSHMEM on the TX1.
> >>>
> >>>> Any chance of upstreaming those patches to not waste time
> >>>
> >>>> re-inventing the wheel ?
> >>>
> >>>> If that's not possible, please send me a copy privately.
> >>>
> >>>
> >>>
> >>> Unfortunately i do not have those patches either. I am afraid someone
> >>>
> >>> will have to do that over again.
> >>>
> >>>
> >>>
> >>> But the whole thread is basically about enabling the demo, which is
> >>>
> >>> interesting for people just getting started with ivshmem. And for
> >>>
> >>> people that want to implement their own protocol on top of it.
> >>>
> >>> If you are just looking at running ivshmem-net you are good to go, that
> >>>
> >>> code is in a working state.
> >>>
> >>>
> >>>
> >>> Henning
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> Many thanks and best regards,
> >>>
> >>>>
> >>>
> >>>>               Claudio
> > 
> > Hi all,
> > 
> > i've applied the provided patch and i'm trying to connect the linux root 
> > cell with the bare metal cell running the inmate/demo/arm/ivshmem-demo.c. 
> > I've attached the used configurations (jetson-tx1-ivshmem for the root cell 
> > and the other one for the bare metal). 
> > When i create the bare metal cell the connection between pci devices is 
> > correctly up.
> > - 
> > Initializing Jailhouse hypervisor  on CPU 2
> > Code location: 0xc0200050
> > Page pool usage after early setup: mem 63/16358, remap 64/131072
> > Initializing processors:
> >  CPU 2... OK
> >  CPU 1... OK
> >  CPU 3... OK
> >  CPU 0... OK
> > Adding virtual PCI device 00:0f.0 to cell "Jetson-TX1-ivshmem&quo

Re: Running ivshmem-demo in Jetson TK1.

2017-12-21 Thread Luca Cuomo

Il giorno domenica 10 dicembre 2017 17:34:24 UTC+1, jonas ha scritto:
> Hi,
> 
> I'll be making an effort to contribute my work to the master branch of 
> Jailhouse within the next couple of weeks.
> 
> /Jonas
> 
> Den fredag 8 december 2017 kl. 06:47:33 UTC+1 skrev Constantin Petra:
> > Hi,
> > 
> > 
> > I'm resending the patch(es) that were shared by Jonas a while ago.
> > 
> > 
> > Best Regards,
> > Constantin
> > 
> > 
> > On Thu, Dec 7, 2017 at 10:08 PM, Henning Schild  
> > wrote:
> > Hi Claudio,
> > 
> > 
> > 
> > Am Thu, 7 Dec 2017 17:29:45 +0100
> > 
> > schrieb Claudio Scordino :
> > 
> > 
> > 
> > > Hi guys,
> > 
> > >
> > 
> > > 2017-08-09 15:23 GMT+02:00 Henning Schild
> > 
> > > :
> > 
> > >
> > 
> > > > Hey,
> > 
> > > >
> > 
> > > > unfortunately Jonas never published his overall changes, maybe now
> > 
> > > > he understands why i kindly asked him to do so.
> > 
> > > > I think Jonas maybe ran into every single problem one could
> > 
> > > > encounter on the way, so if you read the thread you will probably
> > 
> > > > be able to come up with a similar patch at some point. That would
> > 
> > > > be the duplication of efforts, getting a first working patch into a
> > 
> > > > mergeable form is another story.
> > 
> > > >
> > 
> > > > If there are legal reasons to not publish code on the list i suggest
> > 
> > > > you exchange patches between each other. But of cause i would like
> > 
> > > > to see contributions eventually ;).
> > 
> > > >
> > 
> > > >
> > 
> > > We need to run IVSHMEM on the TX1.
> > 
> > > Any chance of upstreaming those patches to not waste time
> > 
> > > re-inventing the wheel ?
> > 
> > > If that's not possible, please send me a copy privately.
> > 
> > 
> > 
> > Unfortunately i do not have those patches either. I am afraid someone
> > 
> > will have to do that over again.
> > 
> > 
> > 
> > But the whole thread is basically about enabling the demo, which is
> > 
> > interesting for people just getting started with ivshmem. And for
> > 
> > people that want to implement their own protocol on top of it.
> > 
> > If you are just looking at running ivshmem-net you are good to go, that
> > 
> > code is in a working state.
> > 
> > 
> > 
> > Henning
> > 
> > 
> > 
> > 
> > 
> > > Many thanks and best regards,
> > 
> > >
> > 
> > >              Claudio

Hi all,

i've applied the provided patch and i'm trying to connect the linux root cell 
with the bare metal cell running the inmate/demo/arm/ivshmem-demo.c. I've 
attached the used configurations (jetson-tx1-ivshmem for the root cell and the 
other one for the bare metal). 
When i create the bare metal cell the connection between pci devices is 
correctly up.
- 
Initializing Jailhouse hypervisor  on CPU 2
Code location: 0xc0200050
Page pool usage after early setup: mem 63/16358, remap 64/131072
Initializing processors:
 CPU 2... OK
 CPU 1... OK
 CPU 3... OK
 CPU 0... OK
Adding virtual PCI device 00:0f.0 to cell "Jetson-TX1-ivshmem"
Page pool usage after late setup: mem 74/16358, remap 69/131072
Activating hypervisor
Adding virtual PCI device 00:0f.0 to cell "jetson-tx1-demo-shmem"
Shared memory connection established: "jetson-tx1-demo-shmem" <--> 
"Jetson-TX1-ivshmem"
---

1st problem: no PCI device appears in linux (lspci does not return anything)

Then i launch the ivshmem-demo.bin. I've made some modification:
* in inmate/lib/arm-common/pci.c the #define PCI_CFG_BASE(0x4800)
  as defined in jetson-tx-ivshmem.c: 
   config.header.platform_info.pci_mmconfig_base.
  In the same file i've enabled the print of pci_read/write_config
* in inmate/demos/arm/ivshmem-demo.c i've removed the filter on 
  class/revision in order to get a suitable pci device with proper 
  deviceId:vendorId

When the bare metal starts, it iterate on the memory with a lot of read 

pci_read_config(bdf:0x0, addr:0x, size:0x2), reg_addr0x4800
pci_read_config(bdf:0x1, addr:0x, size:0x2), reg_addr0x48000100
pci_read_config(bdf:0x2, addr:0x, size:0x2), reg_addr0x48000200
pci_read_config(bdf:0x3, addr:0x, size:0x2), reg_addr0x48000300

 after a while something happens (follow <---)

IVSHMEM: Found 1af4:1110 at 07:10.0 <---
pci_read_config(bdf:0x780, addr:0x0008, size:0x4), 
reg_addr0x48078008
IVSHMEM: class/revision ff01, not supported skipping device <--- //IGNORED
pci_read_config(bdf:0x780, addr:0x0006, size:0x2), 
reg_addr0x48078004
pci_read_config(bdf:0x780, addr:0x0034, size:0x1), 
reg_addr0x48078034
IVSHMEM ERROR: device is not MSI-X capable <---
pci_read_config(bdf:0x780, addr:0x004c, size:0x4), 
reg_addr0x4807804c
pci_read_config(bdf:0x780, addr:0x0048, size:0x4),

Re: questions related to IVSHMEM/uio_ivshmem

2017-12-20 Thread Luca Cuomo

Il giorno lunedì 18 dicembre 2017 17:13:41 UTC+1, Henning Schild ha scritto:
> Am Mon, 18 Dec 2017 07:41:34 -0800
> schrieb Luca Cuomo <l.cu...@evidence.eu.com>:
> 
> > Il giorno lunedì 18 dicembre 2017 16:22:37 UTC+1, Henning Schild ha
> > scritto:
> > > Am Mon, 18 Dec 2017 05:58:11 -0800
> > > schrieb Luca Cuomo <l.cu...@evidence.eu.com>:
> > >   
> > > > > > Hi,
> > > > > > 
> > > > > > I can now confirm that the patch 87fbf1f works and interrupts
> > > > > > are received correctly, /dev/uiox is accessible and works as
> > > > > > expected. Without it, I got a: "FATAL: forbidden access
> > > > > > (exception class 0x24)" but I don't remember if this was
> > > > > > triggered by Jailhouse or Linux.
> > > > > 
> > > > > Thanks, applied to "jailhouse" and removed "jailhouse-next".
> > > > > 
> > > > > Henning
> > > > > 
> > > > > > Best Regards,
> > > > > > Constantin
> > > > > >
> > > > 
> > > > Hi all,
> > > > 
> > > > i've got a strange situation. I'm using the latest jailhouse
> > > > branch on x86 with a linux root cell and a Bare Metal cell
> > > > connected via 2 pci device (bdf e.00 and f.00).
> > > > 
> > > > Two Ivshmem device are correctly mapped to /dev/uio0
> > > > and /dev/uio1. But if on /dev/uio0 i can correctly map registers
> > > > ( offset 0, size 0x1000) and shmem  (offset 0x1000, size 0x1000),
> > > > for /dev/uio1 the first mapping fails with the ENODEV errno set
> > > > (shmem mapping is done correctly). Parameters of mapping are the
> > > > same for uio0 and uio1.
> > > > 
> > > > Here i list a dmesg snippet of the root cell kernel:
> > > > 
> > > > [  302.092280] pci :00:0e.0: [1af4:1110] type 00 class
> > > > 0xff [  302.092622] pci :00:0e.0: reg 0x10: [mem
> > > > 0x-0x00ff 64bit] [  302.092776]
> > > > hpet_rtc_timer_reinit: 39 callbacks suppressed [  302.092777]
> > > > hpet1: lost 62 rtc interrupts [  302.093025] pci :00:0e.0:
> > > > reg 0x20: [mem 0x-0x001f 64bit] [  302.093634] pci
> > > > :00:0e.0: BAR 0: assigned [mem 0xc000-0xc0ff 64bit]
> > > > [  302.093765] pci :00:0e.0: BAR 4: assigned [mem
> > > > 0xc100-0xc11f 64bit] [  302.093982] virtio-pci
> > > > :00:0e.0: enabling device ( -> 0002) [  302.094169]
> > > > uio_ivshmem :00:0e.0: using jailhouse mode [  302.094625]
> > > > uio_ivshmem :00:0e.0: MSI-X enabled [  302.094918] pci
> > > > :00:0f.0: [1af4:1110] type 00 class 0xff [  302.095259]
> > > > pci :00:0f.0: reg 0x10: [mem 0x-0x00ff 64bit]
> > > > [  302.095725] pci :00:0f.0: reg 0x20: [mem
> > > > 0x-0x001f 64bit] [  302.096468] pci :00:0f.0: BAR
> > > > 0: assigned [mem 0xc200-0xc2ff 64bit] [  302.096667] pci
> > > > :00:0f.0: BAR 4: assigned [mem 0xc120-0xc13f 64bit]
> > > > [  302.096962] virtio-pci :00:0f.0: enabling device ( ->
> > > > 0002) [  302.097139] uio_ivshmem :00:0f.0: using jailhouse
> > > > mode [  302.097568] uio_ivshmem :00:0f.0: MSI-X enabled  
> > > 
> > > I do not remember whether i tested the uio-driver with multiple
> > > devices, i can not rule out a hidden bug in there. The output looks
> > > pretty much the same for both instances and does not seem too
> > > useful. 
> >  
> > Even the /sys/class/uio/uiox ... directories seem to be ok.
> > 
> > > What would be interesting is which call fails and where it fails in
> > > the kernel? Could you "unbind" the two devices from the driver and
> > > "bind" them the other way around, does that make the "second" work
> > > and the "first" fail?  
> > 
> > This could be a good idea but how do you suggest to unbind them?
> 
> # echo :00:0f.0 > /sys/bus/pci/drivers/uio_ivshmem/unbind
> # echo :00:0e.0 > /sys/bus/pci/drivers/uio_ivshmem/unbind
> 
> # echo :00:0f.0 > /sys/bus/pci/drivers/uio_ivshmem/bind
> 
> Now 0f should be your uio0.

I've tried and now the problem in on /dev/uio0. So the problem in on the same 
device (the one that previously was /de

Re: questions related to IVSHMEM/uio_ivshmem

2017-12-18 Thread Luca Cuomo

Il giorno lunedì 18 dicembre 2017 16:22:37 UTC+1, Henning Schild ha scritto:
> Am Mon, 18 Dec 2017 05:58:11 -0800
> schrieb Luca Cuomo <l.cu...@evidence.eu.com>:
> 
> > > > Hi,
> > > > 
> > > > I can now confirm that the patch 87fbf1f works and interrupts are
> > > > received correctly, /dev/uiox is accessible and works as expected.
> > > > Without it, I got a: "FATAL: forbidden access (exception class
> > > > 0x24)" but I don't remember if this was triggered by Jailhouse or
> > > > Linux.  
> > > 
> > > Thanks, applied to "jailhouse" and removed "jailhouse-next".
> > > 
> > > Henning
> > >   
> > > > Best Regards,
> > > > Constantin
> > > >  
> > 
> > Hi all,
> > 
> > i've got a strange situation. I'm using the latest jailhouse branch
> > on x86 with a linux root cell and a Bare Metal cell connected via 2
> > pci device (bdf e.00 and f.00).
> > 
> > Two Ivshmem device are correctly mapped to /dev/uio0 and /dev/uio1.
> > But if on /dev/uio0 i can correctly map registers ( offset 0, size
> > 0x1000) and shmem  (offset 0x1000, size 0x1000), for /dev/uio1 the
> > first mapping fails with the ENODEV errno set (shmem mapping is done
> > correctly). Parameters of mapping are the same for uio0 and uio1.
> > 
> > Here i list a dmesg snippet of the root cell kernel:
> > 
> > [  302.092280] pci :00:0e.0: [1af4:1110] type 00 class 0xff
> > [  302.092622] pci :00:0e.0: reg 0x10: [mem 0x-0x00ff
> > 64bit] [  302.092776] hpet_rtc_timer_reinit: 39 callbacks suppressed
> > [  302.092777] hpet1: lost 62 rtc interrupts
> > [  302.093025] pci :00:0e.0: reg 0x20: [mem 0x-0x001f
> > 64bit] [  302.093634] pci :00:0e.0: BAR 0: assigned [mem
> > 0xc000-0xc0ff 64bit] [  302.093765] pci :00:0e.0: BAR 4:
> > assigned [mem 0xc100-0xc11f 64bit] [  302.093982] virtio-pci
> > :00:0e.0: enabling device ( -> 0002) [  302.094169]
> > uio_ivshmem :00:0e.0: using jailhouse mode [  302.094625]
> > uio_ivshmem :00:0e.0: MSI-X enabled [  302.094918] pci
> > :00:0f.0: [1af4:1110] type 00 class 0xff [  302.095259] pci
> > :00:0f.0: reg 0x10: [mem 0x-0x00ff 64bit]
> > [  302.095725] pci :00:0f.0: reg 0x20: [mem 0x-0x001f
> > 64bit] [  302.096468] pci :00:0f.0: BAR 0: assigned [mem
> > 0xc200-0xc2ff 64bit] [  302.096667] pci :00:0f.0: BAR 4:
> > assigned [mem 0xc120-0xc13f 64bit] [  302.096962] virtio-pci
> > :00:0f.0: enabling device ( -> 0002) [  302.097139]
> > uio_ivshmem :00:0f.0: using jailhouse mode [  302.097568]
> > uio_ivshmem :00:0f.0: MSI-X enabled
> 
> I do not remember whether i tested the uio-driver with multiple
> devices, i can not rule out a hidden bug in there. The output looks
> pretty much the same for both instances and does not seem too useful.
>
 
Even the /sys/class/uio/uiox ... directories seem to be ok.

> What would be interesting is which call fails and where it fails in the
> kernel? Could you "unbind" the two devices from the driver and "bind"
> them the other way around, does that make the "second" work and the
> "first" fail?

This could be a good idea but how do you suggest to unbind them?

> What test-code are you using, if anyone wanted to reproduce the setup
> for further assistance.

The same result using both the uio_send test which is in the repo and a self 
made test which basically does:

int firstFd = open(/dev/uio0, O_RDWR) //ok
mmap( NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, firstFd, 0) //regs ok
mmap( NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, firstFd, 4096) //shmem ok

int secondFd = open(/dev/uio1, O_RDWR) //ok
mmap( NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, secondFd, 0) //regs FAIL
mmap( NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, secondFd, 4096) //shmem ok

The way i can overcome the problem for the second device is reading the address 
from /sys/class/uio/uio1/maps/map0/addr and then mmapping from /dev/mem with 
the proper offset (/sys/class/uio/uio1/maps/map0/offset)


> 
> Henning
> 
> > What i'm doing wrong? I do exactly the same things on /dev/uio0
> > and /dev/uio1
 
Thanks,
 
--Luca


-- 
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: questions related to IVSHMEM/uio_ivshmem

2017-12-18 Thread Luca Cuomo

> > Hi,
> > 
> > I can now confirm that the patch 87fbf1f works and interrupts are
> > received correctly, /dev/uiox is accessible and works as expected.
> > Without it, I got a: "FATAL: forbidden access (exception class 0x24)"
> > but I don't remember if this was triggered by Jailhouse or Linux.
> 
> Thanks, applied to "jailhouse" and removed "jailhouse-next".
> 
> Henning
> 
> > Best Regards,
> > Constantin
> >

Hi all,

i've got a strange situation. I'm using the latest jailhouse branch on x86 with 
a linux root cell and a Bare Metal cell connected via 2 pci device (bdf e.00 
and f.00).

Two Ivshmem device are correctly mapped to /dev/uio0 and /dev/uio1.
But if on /dev/uio0 i can correctly map registers ( offset 0, size 0x1000) and 
shmem  (offset 0x1000, size 0x1000), for /dev/uio1 the first mapping fails with 
the ENODEV errno set (shmem mapping is done correctly). Parameters of mapping 
are the same for uio0 and uio1.

Here i list a dmesg snippet of the root cell kernel:

[  302.092280] pci :00:0e.0: [1af4:1110] type 00 class 0xff
[  302.092622] pci :00:0e.0: reg 0x10: [mem 0x-0x00ff 64bit]
[  302.092776] hpet_rtc_timer_reinit: 39 callbacks suppressed
[  302.092777] hpet1: lost 62 rtc interrupts
[  302.093025] pci :00:0e.0: reg 0x20: [mem 0x-0x001f 64bit]
[  302.093634] pci :00:0e.0: BAR 0: assigned [mem 0xc000-0xc0ff 
64bit]
[  302.093765] pci :00:0e.0: BAR 4: assigned [mem 0xc100-0xc11f 
64bit]
[  302.093982] virtio-pci :00:0e.0: enabling device ( -> 0002)
[  302.094169] uio_ivshmem :00:0e.0: using jailhouse mode
[  302.094625] uio_ivshmem :00:0e.0: MSI-X enabled
[  302.094918] pci :00:0f.0: [1af4:1110] type 00 class 0xff
[  302.095259] pci :00:0f.0: reg 0x10: [mem 0x-0x00ff 64bit]
[  302.095725] pci :00:0f.0: reg 0x20: [mem 0x-0x001f 64bit]
[  302.096468] pci :00:0f.0: BAR 0: assigned [mem 0xc200-0xc2ff 
64bit]
[  302.096667] pci :00:0f.0: BAR 4: assigned [mem 0xc120-0xc13f 
64bit]
[  302.096962] virtio-pci :00:0f.0: enabling device ( -> 0002)
[  302.097139] uio_ivshmem :00:0f.0: using jailhouse mode
[  302.097568] uio_ivshmem :00:0f.0: MSI-X enabled

What i'm doing wrong? I do exactly the same things on /dev/uio0 and /dev/uio1

Thanks,

--Luca

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

Re: [IVSHMEM]: Best way to discover BDF in IRQ handler

2017-12-18 Thread Luca Cuomo

Il giorno lunedì 11 dicembre 2017 18:18:50 UTC+1, J. Kiszka ha scritto:
> On 2017-12-11 16:32, Luca Cuomo wrote:
> > Il giorno lunedì 11 dicembre 2017 15:47:01 UTC+1, J. Kiszka ha scritto:
> >> On 2017-12-11 14:58, Luca Cuomo wrote:
> >>> Hi,
> >>>
> >>> i'm running a ivshmem-demo with a Linux root-cell and a BM cell which are 
> >>> connected via multiple PCI device.
> >>
> >> What is a "BM cell"?
> > 
> > Sorry, BARE METAL
> >>
> >>>
> >>>LINUXBM
> >>>
> >>> PCI dev (bdf: 00e.0) <->  PCI dev (bdf: 00e.0)
> >>> PCI dev (bdf: 00f.0) <->  PCI dev (bdf: 00f.0)
> >>>
> >>> and so on..
> >>>
> >>> The link between devices is correctly established and i can see interrupt 
> >>> handled in both cell.
> >>>
> >>> But, if in the root cell i can distinguish the device which received IRQ 
> >>> using UIO driver, in the BM cell the IRQ handler does not give any kind 
> >>> of information.
> >>>
> >>> Which is the best way (clean and fast) to acquire such information?
> >>
> >> Which architecture are you on? Depending on that, you either get
> >> separate MSI-X interrupts anyway (x86, and only on few ARM64 systems) or
> >> need to assign separate legacy INTx to the devices. So there should be
> >> no dispatching problem from that point of view.
> >>
> > Currently i'm on x86, but i'll do the same thing on ARM64.
> 
> OK, BM means you need to hard-code things or provide the inmate other
> forms of configuration information to match devices with connections and
> select free IRQ vectors.
> 
> Jan
> -- 
> Siemens AG, Corporate Technology, CT RDA ITP SES-DE
> Corporate Competence Center Embedded Linux

Ok, first of all thanks for your reply and i apologize for the delay of my 
answer. 
What you say is correct indeed.
But i'm wondering if is suitable a scenario like the one i'm going to describe 
(for the moment on x86 platform) :

* Let's suppose there are several PCI devices which connect the root cell 
(Linux) with the Bare Metal Cell
* Let's suppose that the Bare Metal cell can discover how many devices are 
mapped as ivshmem memories (in the same way that is now performed by 
ivshmem-demo)
* as you said before i can install the same routine on different IRQ and in the 
end this routine is the only one that is called
* In the context of this routine can i discover which device received the 
interrupt by inspecting the IntrStatus of the ivhsmem registers of each device?
* If yes, which is the best way to reach this register? mmio_read32()?

Thanks in advance, again.

--Luca

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

Re: [IVSHMEM]: Best way to discover BDF in IRQ handler

2017-12-11 Thread Luca Cuomo

Il giorno lunedì 11 dicembre 2017 15:47:01 UTC+1, J. Kiszka ha scritto:
> On 2017-12-11 14:58, Luca Cuomo wrote:
> > Hi,
> > 
> > i'm running a ivshmem-demo with a Linux root-cell and a BM cell which are 
> > connected via multiple PCI device.
> 
> What is a "BM cell"?

Sorry, BARE METAL
> 
> > 
> >LINUXBM
> > 
> > PCI dev (bdf: 00e.0) <->  PCI dev (bdf: 00e.0)
> > PCI dev (bdf: 00f.0) <->  PCI dev (bdf: 00f.0)
> > 
> > and so on..
> > 
> > The link between devices is correctly established and i can see interrupt 
> > handled in both cell.
> > 
> > But, if in the root cell i can distinguish the device which received IRQ 
> > using UIO driver, in the BM cell the IRQ handler does not give any kind of 
> > information.
> > 
> > Which is the best way (clean and fast) to acquire such information?
> 
> Which architecture are you on? Depending on that, you either get
> separate MSI-X interrupts anyway (x86, and only on few ARM64 systems) or
> need to assign separate legacy INTx to the devices. So there should be
> no dispatching problem from that point of view.
> 
Currently i'm on x86, but i'll do the same thing on ARM64.

> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT RDA ITP SES-DE
> Corporate Competence Center Embedded Linux

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

[IVSHMEM]: Best way to discover BDF in IRQ handler

2017-12-11 Thread Luca Cuomo

Hi,

i'm running a ivshmem-demo with a Linux root-cell and a BM cell which are 
connected via multiple PCI device.

   LINUXBM

PCI dev (bdf: 00e.0) <->  PCI dev (bdf: 00e.0)
PCI dev (bdf: 00f.0) <->  PCI dev (bdf: 00f.0)

and so on..

The link between devices is correctly established and i can see interrupt 
handled in both cell.

But, if in the root cell i can distinguish the device which received IRQ using 
UIO driver, in the BM cell the IRQ handler does not give any kind of 
information.

Which is the best way (clean and fast) to acquire such information?

Thanks in advance.

Best regards,

--Luca 

-- 
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: Issue with large inmates on TX2

Re: Issue with large inmates on TX2

Re: Issue with large inmates on TX2

Re: Issue with large inmates on TX2

Issue with large inmates on TX2

[PATCH 0/2] IVSHMEM support for arm64

[PATCH 2/2] Jetson TX2: IVSHMEM support in cells

Re: Share memory among cells on arm64

Re: Share memory among cells on arm64

Re: Running ivshmem-demo in Jetson TK1.

Re: Running ivshmem-demo in Jetson TK1.

Re: Running ivshmem-demo in Jetson TK1.

Re: Running ivshmem-demo in Jetson TK1.

Re: questions related to IVSHMEM/uio_ivshmem

Re: questions related to IVSHMEM/uio_ivshmem

Re: questions related to IVSHMEM/uio_ivshmem

Re: [IVSHMEM]: Best way to discover BDF in IRQ handler

Re: [IVSHMEM]: Best way to discover BDF in IRQ handler

[IVSHMEM]: Best way to discover BDF in IRQ handler

19 matches

Site Navigation

Mail list logo

Footer information