Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

[Jan Kiszka]

On 2018-04-24 00:38, Frank Rowand wrote:
> Hi Jan,
> 
> + Alan Tull for fpga perspective
> 
> On 04/22/18 03:30, Jan Kiszka wrote:
>> On 2018-04-11 07:42, Jan Kiszka wrote:
>>> On 2018-04-05 23:12, Rob Herring wrote:
 On Thu, Apr 5, 2018 at 2:28 PM, Frank Rowand  
 wrote:
> On 04/05/18 12:13, Jan Kiszka wrote:
>> On 2018-04-05 20:59, Frank Rowand wrote:
>>> Hi Jan,
>>>
>>> On 04/04/18 15:35, Jan Kiszka wrote:
 Hi Frank,

 On 2018-03-04 01:17, frowand.l...@gmail.com wrote:
> From: Frank Rowand 
>
> Move duplicating and unflattening of an overlay flattened devicetree
> (FDT) into the overlay application code.  To accomplish this,
> of_overlay_apply() is replaced by of_overlay_fdt_apply().
>
> The copy of the FDT (aka "duplicate FDT") now belongs to devicetree
> code, which is thus responsible for freeing the duplicate FDT.  The
> caller of of_overlay_fdt_apply() remains responsible for freeing the
> original FDT.
>
> The unflattened devicetree now belongs to devicetree code, which is
> thus responsible for freeing the unflattened devicetree.
>
> These ownership changes prevent early freeing of the duplicated FDT
> or the unflattened devicetree, which could result in use after free
> errors.
>
> of_overlay_fdt_apply() is a private function for the anticipated
> overlay loader.

 We are using of_fdt_unflatten_tree + of_overlay_apply in the
 (out-of-tree) Jailhouse loader driver in order to register a virtual
 device during hypervisor activation with Linux. The DT overlay is
 created from a a template but modified prior to application to account
 for runtime-specific parameters. See [1] for the current 
 implementation.

 I'm now wondering how to model that scenario best with the new API.
 Given that the loader lost ownership of the unflattened tree but the
 modification API exist only for the that DT state, I'm not yet seeing a
 clear solution. Should we apply the template in disabled form (status =
 "disabled"), modify it, and then activate it while it is already 
 applied?
>>>
>>> Thank you for the pointer to the driver - that makes it much easier to
>>> understand the use case and consider solutions.
>>>
>>> If you can make the changes directly on the FDT instead of on the
>>> expanded devicetree, then you could move to the new API.
>>
>> Are there some examples/references on how to edit FDTs in-place in the
>> kernel? I'd like to avoid writing the n-th FDT parser/generator.
>
> I don't know of any existing in-kernel edits of the FDT (but they might
> exist).  The functions to access an FDT are in libfdt, which is in
> scripts/dtc/libfdt/.

 Let's please not go down that route of doing FDT modifications. There
 is little reason to other than for early boot changes. And it is much
 easier to work on unflattened trees.
>>>
>>> I just briefly looked into libfdt, and it would have meant building it
>>> into the module as there are no library functions exported by the kernel
>>> either. Another reason to drop that.
>>>
>>> What's apparently working now is the pattern I initially suggested:
>>> Register template with status = "disabled" as overlay, then prepare and
>>> apply changeset that contains all needed modifications and sets the
>>> status to "ok". I might be leaking additional resources, but to find
>>> that out, I will now finally have to resolve clean unbinding of the
>>> generic PCI host controller [1] first.
>>
>> static void free_overlay_changeset(struct overlay_changeset *ovcs)
>> {
>>  [...]
>>  /*
>>   * TODO
>>   *
>>   * would like to: kfree(ovcs->overlay_tree);
>>   * but can not since drivers may have pointers into this data
>>   *
>>   * would like to: kfree(ovcs->fdt);
>>   * but can not since drivers may have pointers into this data
>>   */
>>
>>  kfree(ovcs);
>> }
>>
>> What's this? I have kmemleak now jumping at me over this. Who is suppose
>> to plug these leaks? The caller of of_overlay_fdt_apply has no pointers
>> to those objects. I would say that's a regression of the new API.
> 
> The problem already existed but it was hidden.  We have never been able to
> kfree() these object because we do not know if there are any pointers into
> these objects.  The new API makes the problem visible to kmemleak.

My old code didn't have the problem because there was no one steeling
pointers to my overlay, and I was able to safely release all the
resources that I or the core on my behalf allocated. In fact, I recently
even dropped the duplication the fdt prior to unflattening it because I
got its lifecycle under control 

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

[Frank Rowand]

Hi Jan,

+ Alan Tull for fpga perspective

On 04/22/18 03:30, Jan Kiszka wrote:
> On 2018-04-11 07:42, Jan Kiszka wrote:
>> On 2018-04-05 23:12, Rob Herring wrote:
>>> On Thu, Apr 5, 2018 at 2:28 PM, Frank Rowand  wrote:
 On 04/05/18 12:13, Jan Kiszka wrote:
> On 2018-04-05 20:59, Frank Rowand wrote:
>> Hi Jan,
>>
>> On 04/04/18 15:35, Jan Kiszka wrote:
>>> Hi Frank,
>>>
>>> On 2018-03-04 01:17, frowand.l...@gmail.com wrote:
 From: Frank Rowand 

 Move duplicating and unflattening of an overlay flattened devicetree
 (FDT) into the overlay application code.  To accomplish this,
 of_overlay_apply() is replaced by of_overlay_fdt_apply().

 The copy of the FDT (aka "duplicate FDT") now belongs to devicetree
 code, which is thus responsible for freeing the duplicate FDT.  The
 caller of of_overlay_fdt_apply() remains responsible for freeing the
 original FDT.

 The unflattened devicetree now belongs to devicetree code, which is
 thus responsible for freeing the unflattened devicetree.

 These ownership changes prevent early freeing of the duplicated FDT
 or the unflattened devicetree, which could result in use after free
 errors.

 of_overlay_fdt_apply() is a private function for the anticipated
 overlay loader.
>>>
>>> We are using of_fdt_unflatten_tree + of_overlay_apply in the
>>> (out-of-tree) Jailhouse loader driver in order to register a virtual
>>> device during hypervisor activation with Linux. The DT overlay is
>>> created from a a template but modified prior to application to account
>>> for runtime-specific parameters. See [1] for the current implementation.
>>>
>>> I'm now wondering how to model that scenario best with the new API.
>>> Given that the loader lost ownership of the unflattened tree but the
>>> modification API exist only for the that DT state, I'm not yet seeing a
>>> clear solution. Should we apply the template in disabled form (status =
>>> "disabled"), modify it, and then activate it while it is already 
>>> applied?
>>
>> Thank you for the pointer to the driver - that makes it much easier to
>> understand the use case and consider solutions.
>>
>> If you can make the changes directly on the FDT instead of on the
>> expanded devicetree, then you could move to the new API.
>
> Are there some examples/references on how to edit FDTs in-place in the
> kernel? I'd like to avoid writing the n-th FDT parser/generator.

 I don't know of any existing in-kernel edits of the FDT (but they might
 exist).  The functions to access an FDT are in libfdt, which is in
 scripts/dtc/libfdt/.
>>>
>>> Let's please not go down that route of doing FDT modifications. There
>>> is little reason to other than for early boot changes. And it is much
>>> easier to work on unflattened trees.
>>
>> I just briefly looked into libfdt, and it would have meant building it
>> into the module as there are no library functions exported by the kernel
>> either. Another reason to drop that.
>>
>> What's apparently working now is the pattern I initially suggested:
>> Register template with status = "disabled" as overlay, then prepare and
>> apply changeset that contains all needed modifications and sets the
>> status to "ok". I might be leaking additional resources, but to find
>> that out, I will now finally have to resolve clean unbinding of the
>> generic PCI host controller [1] first.
> 
> static void free_overlay_changeset(struct overlay_changeset *ovcs)
> {
>   [...]
>   /*
>* TODO
>*
>* would like to: kfree(ovcs->overlay_tree);
>* but can not since drivers may have pointers into this data
>*
>* would like to: kfree(ovcs->fdt);
>* but can not since drivers may have pointers into this data
>*/
> 
>   kfree(ovcs);
> }
> 
> What's this? I have kmemleak now jumping at me over this. Who is suppose
> to plug these leaks? The caller of of_overlay_fdt_apply has no pointers
> to those objects. I would say that's a regression of the new API.

The problem already existed but it was hidden.  We have never been able to
kfree() these object because we do not know if there are any pointers into
these objects.  The new API makes the problem visible to kmemleak.

The reason that we do not know if there are any pointers into these objects
is that devicetree access APIs return pointers into the devicetree internal
data structures (that is, into the overlay unflattened devicetree).  If we
want to be able to do the kfree()s, we could change the devicetree access
APIs.

The reason that pointers into the overlay flattened tree (ovcs->fdt) are
also exposed is that the overlay unflattened devicetree property values
are pointers 

[siemens/jailhouse] 5b0953: build: Cosmetic improvements for COMMON_OBJECTS va...

[GitHub]

  Branch: refs/heads/next
  Home:   https://github.com/siemens/jailhouse
  Commit: 5b0953df77d0e1dfde15b6cf3865529375cd21d5
  
https://github.com/siemens/jailhouse/commit/5b0953df77d0e1dfde15b6cf3865529375cd21d5
  Author: Jan Kiszka 
  Date:   2018-04-20 (Fri, 20 Apr 2018)

  Changed paths:
M hypervisor/arch/arm-common/Kbuild
M hypervisor/arch/arm/Kbuild
M hypervisor/arch/arm64/Kbuild
M hypervisor/arch/x86/Kbuild
M inmates/lib/arm-common/Makefile.lib
M inmates/lib/arm/Makefile
M inmates/lib/arm64/Makefile

  Log Message:
  ---
  build: Cosmetic improvements for COMMON_OBJECTS variables

Rename COMMON_OBJECTS to common-objs-y so that optional objects can more
easily be appended. Also decapitalize OBJS-y to be visually more
friendly.

No functional changes.

Signed-off-by: Jan Kiszka 


  Commit: 26390874d6484be0c70ce542f2db83ac7539fc84
  
https://github.com/siemens/jailhouse/commit/26390874d6484be0c70ce542f2db83ac7539fc84
  Author: Jan Kiszka 
  Date:   2018-04-20 (Fri, 20 Apr 2018)

  Changed paths:
M hypervisor/Makefile

  Log Message:
  ---
  build: Add a dummy recipe to ensure evaluation of arch subdir results

Without this, make may skip over relinking the core against the arch
subdir results while the latter is still being built. This was
reproducible by touching an architecture file and then rebuild with -j.

Fixes: f5a0a36601c2 ("core: Rework architecture subdir build")
Signed-off-by: Jan Kiszka 


  Commit: 8fb439f864dcdd59cdafaa54324adcd3a89879a4
  
https://github.com/siemens/jailhouse/commit/8fb439f864dcdd59cdafaa54324adcd3a89879a4
  Author: Jan Kiszka 
  Date:   2018-04-20 (Fri, 20 Apr 2018)

  Changed paths:
M hypervisor/arch/x86/Kbuild
A hypervisor/arch/x86/test-device.c
M include/jailhouse/cell-config.h

  Log Message:
  ---
  x86: Add MMIO access test device

On x86, we unfortunately need to parse the guest instruction that
triggered an MMIO access interception. This parser started to be small
and simple - and then real life bit. It already passed the point where
we should have added systematic tests.

This is the hypervisor-located building block for such tests. The test
creates a MMIO target page right after the Communication Page. Write
accesses to the virtual registers 0xff8..0xfff are stored per cell, read
accesses reproduce that written value. The virtual registers are backed
by the Communication Page of the same cell at the same address, thus
create a second channel to validate accesses.

This test device is optional, configured in during build time by setting
CONFIG_TEST_DEVICE in config.h and during runtime by adding
JAILHOUSE_CELL_TEST_DEVICE to the cell's config flags.

Signed-off-by: Jan Kiszka 


  Commit: bba1d4a082e34ff6295064e85c33bcf0fc4d7bf3
  
https://github.com/siemens/jailhouse/commit/bba1d4a082e34ff6295064e85c33bcf0fc4d7bf3
  Author: Jan Kiszka 
  Date:   2018-04-23 (Mon, 23 Apr 2018)

  Changed paths:
M configs/x86/tiny-demo.c
M inmates/Makefile
A inmates/tests/arm/Makefile
A inmates/tests/arm64/Makefile
A inmates/tests/x86/Makefile
A inmates/tests/x86/mmio-access.c

  Log Message:
  ---
  inmates: x86: Add test case for MMIO accessing instructions

This lays the ground for systematic tests of the MMIO instruction parser
in x86. The test-case inmate uses the new MMIO access test device for
writing and reading with yet a small number of instructions variants.
This is supposed to expanded later on with further patterns - but it
already revealed several bugs in the handling of immediate writes.

Signed-off-by: Jan Kiszka 


  Commit: adbcf414b6705353eeafe553622d5da0f374935c
  
https://github.com/siemens/jailhouse/commit/adbcf414b6705353eeafe553622d5da0f374935c
  Author: Jan Kiszka 
  Date:   2018-04-23 (Mon, 23 Apr 2018)

  Changed paths:
M hypervisor/arch/x86/mmio.c

  Log Message:
  ---
  x86: mmio: Fix instruction length calculation for write-immediate

This fixes one case around mov imm,: We read the immediate value
to be written, but we forgot to update inst_len. This fixes that issue
by moving the update from ctx.count to inst.inst_len to the very end
of the parser.

Fixes: 95202a038b9e ("x86,mmio: Add support for 1 more instructions on
the MMIO dispatcher")
Signed-off-by: Jan Kiszka 


  Commit: 40d3e67932e4fdc7de7bb0d6db608eee52a84152
  
https://github.com/siemens/jailhouse/commit/40d3e67932e4fdc7de7bb0d6db608eee52a84152
  Author: Jan Kiszka 
  Date:   2018-04-23 (Mon, 23 Apr 2018)

  Changed paths:
M hypervisor/arch/x86/mmio.c

  Log Message:
  ---
  x86: mmio: Fix handling of displacement bytes when writing immediates

We only skipped over 

[siemens/jailhouse] 822f76: arm-common: gic-v3: Mark last CPUs GICR as last

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/siemens/jailhouse
  Commit: 822f7697cfaa5ac492356d24feb273565f04ac45
  
https://github.com/siemens/jailhouse/commit/822f7697cfaa5ac492356d24feb273565f04ac45
  Author: Lokesh Vutla 
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
M hypervisor/arch/arm-common/gic-v3.c

  Log Message:
  ---
  arm-common: gic-v3: Mark last CPUs GICR as last

There are scenarios where Linux boots up with less number of cores
than the SoC supports. In such cases, finding GICR region marked with
GICR_TYPER_Last is not possible for any non-root cell. This is
because hypervisor gives an unhandled trap to any access of GICR
region that does not correspond to system CPU set.

Fix this by emulating GICR region as last that corresponds to the
last available CPU in the system CPU set.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Jan Kiszka 


  Commit: d540edca6e7d94d9e72476bfb9e51d274be79a67
  
https://github.com/siemens/jailhouse/commit/d540edca6e7d94d9e72476bfb9e51d274be79a67
  Author: Henning Schild 
  Date:   2018-03-26 (Mon, 26 Mar 2018)

  Changed paths:
M tools/jailhouse-config-create

  Log Message:
  ---
  tools: config-create: update iomem parser to work on recent kernels

More recent kernels (did not try to identify which version) spell the
string "reserved" with a capital letter in front. Allow any case-
representation of the string.

Reported-by: Anil Kumar 
Signed-off-by: Henning Schild 
Signed-off-by: Jan Kiszka 


  Commit: a667538fb8ef1287f5dd4d5a934a431e3dc97ac2
  
https://github.com/siemens/jailhouse/commit/a667538fb8ef1287f5dd4d5a934a431e3dc97ac2
  Author: Jan Kiszka 
  Date:   2018-03-27 (Tue, 27 Mar 2018)

  Changed paths:
M tools/jailhouse-cell-linux

  Log Message:
  ---
  tools: cell-linux: Add support for compressed arm64 kernel images

The arm64 Linux boot protocol allows compressed images but they have to
be decompressed by the bootloader, and that's jailhouse-cell-linux in
our case. Detect those images by trying to decompress them and use the
decompressed version from then on.

Signed-off-by: Jan Kiszka 


  Commit: a7c5161ada079db274eb1f2df94d153cd203afe3
  
https://github.com/siemens/jailhouse/commit/a7c5161ada079db274eb1f2df94d153cd203afe3
  Author: Jan Kiszka 
  Date:   2018-03-27 (Tue, 27 Mar 2018)

  Changed paths:
M tools/jailhouse-cell-linux

  Log Message:
  ---
  tools: cell-linux: Use cached kernel image on x86

Now that we read the kernel image completely, use that image for
X86ZeroPage and X86SetupHeader, rather than reading from the file again.

Signed-off-by: Jan Kiszka 


  Commit: e8370e9d85492c1897ed248a76e08b577b498f23
  
https://github.com/siemens/jailhouse/commit/e8370e9d85492c1897ed248a76e08b577b498f23
  Author: Jan Kiszka 
  Date:   2018-04-03 (Tue, 03 Apr 2018)

  Changed paths:
M hypervisor/arch/x86/svm.c

  Log Message:
  ---
  x86: svm: Intercept all SVM instructions

Not doing so can have undesirable side effects, like clearing GIF on
the calling CPU.

Signed-off-by: Jan Kiszka 


  Commit: d7472246dffc1fbe4f5ee0da7c4bae981cf3f3a1
  
https://github.com/siemens/jailhouse/commit/d7472246dffc1fbe4f5ee0da7c4bae981cf3f3a1
  Author: Ralf Ramsauer 
  Date:   2018-04-03 (Tue, 03 Apr 2018)

  Changed paths:
M inmates/lib/arm-common/include/inmate.h
M inmates/lib/arm/include/arch/inmate.h
M inmates/lib/arm64/include/arch/inmate.h

  Log Message:
  ---
  inmates: arm: fix broken heartbeat

Since 9675814c6fe3e6 ("arm/arm64: Reject hypercalls with wrong immediate
code"), Jailhouse rejects all HVCs with immediate codes other than
0x4a48.

This breaks the assumption that the heartbeat() pseudo HVC makes on all
ARM platforms.

We must provide 0x4a48 as immediate code, but use an invalid function
argument in order to return to our cell. 0xdeadbeef sounds reasonable.

Let's use this cance to consolidate arm and arm64 code and use our
common jailhouse_call interface.

Fixes: 9675814c6fe3e6 ("arm/arm64: Reject hypercalls with wrong immediate code")
Signed-off-by: Ralf Ramsauer 
Signed-off-by: Jan Kiszka 


  Commit: 152738bbb72c9f584fe6bc9d618ba72f3354ae84
  
https://github.com/siemens/jailhouse/commit/152738bbb72c9f584fe6bc9d618ba72f3354ae84
  Author: f...@ozog.com 
  Date:   2018-04-12 (Thu, 12 Apr 2018)

  Changed paths:
M driver/main.c

  Log Message:
  ---
  driver: ensure jailhouse is not enabled when VT-X is disabled by firmware

Whithout the check,
jailhouse enable configs/x86/sysconfig.cell
results 

[PATCH 06/16] x86: Add MMIO access test device

[Jan Kiszka]

From: Jan Kiszka 

On x86, we unfortunately need to parse the guest instruction that
triggered an MMIO access interception. This parser started to be small
and simple - and then real life bit. It already passed the point where
we should have added systematic tests.

This is the hypervisor-located building block for such tests. The test
creates a MMIO target page right after the Communication Page. Write
accesses to the virtual registers 0xff8..0xfff are stored per cell, read
accesses reproduce that written value. The virtual registers are backed
by the Communication Page of the same cell at the same address, thus
create a second channel to validate accesses.

This test device is optional, configured in during build time by setting
CONFIG_TEST_DEVICE in config.h and during runtime by adding
JAILHOUSE_CELL_TEST_DEVICE to the cell's config flags.

Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/x86/Kbuild|   4 +-
 hypervisor/arch/x86/test-device.c | 110 ++
 include/jailhouse/cell-config.h   |   1 +
 3 files changed, 114 insertions(+), 1 deletion(-)
 create mode 100644 hypervisor/arch/x86/test-device.c

diff --git a/hypervisor/arch/x86/Kbuild b/hypervisor/arch/x86/Kbuild
index 476f9c1cc..8ab8d5636 100644
--- a/hypervisor/arch/x86/Kbuild
+++ b/hypervisor/arch/x86/Kbuild
@@ -26,9 +26,11 @@ common-objs-y := apic.o dbg-write.o entry.o setup.o 
control.o mmio.o iommu.o \
 paging.o pci.o i8042.o vcpu.o vga.o ivshmem.o
 
 # units initialization order as defined by linking order:
-# iommu, ioapic, [cat], 
+# iommu, ioapic, [test-device], [cat], 
 
 common-objs-y += ioapic.o
 
+common-objs-$(CONFIG_TEST_DEVICE) += test-device.o
+
 built-in-amd-y := svm.o amd_iommu.o svm-vmexit.o $(common-objs-y)
 built-in-intel-y := vmx.o vtd.o vmx-vmexit.o $(common-objs-y) cat.o
diff --git a/hypervisor/arch/x86/test-device.c 
b/hypervisor/arch/x86/test-device.c
new file mode 100644
index 0..081dad9f2
--- /dev/null
+++ b/hypervisor/arch/x86/test-device.c
@@ -0,0 +1,110 @@
+/*
+ * Jailhouse, a Linux-based partitioning hypervisor
+ *
+ * Copyright (c) Siemens AG, 2018
+ *
+ * Authors:
+ *  Jan Kiszka 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static unsigned int testdev_mmio_count_regions(struct cell *cell)
+{
+   return cell->config->flags & JAILHOUSE_CELL_TEST_DEVICE ? 1 : 0;
+}
+
+static enum mmio_result testdev_handle_mmio_access(void *arg,
+  struct mmio_access *mmio)
+{
+   void *test_reg = _cell()->comm_page.padding[mmio->address];
+
+   if (mmio->address < 0xff8)
+   goto invalid_access;
+
+   switch (mmio->size) {
+   case 1:
+   if (mmio->is_write)
+   *(u8 *)test_reg = mmio->value;
+   else
+   mmio->value = *(u8 *)test_reg;
+   break;
+   case 2:
+   if (mmio->address > 0x1000-2)
+   goto invalid_access;
+   if (mmio->is_write)
+   *(u16 *)test_reg = mmio->value;
+   else
+   mmio->value = *(u16 *)test_reg;
+   break;
+   case 4:
+   if (mmio->address > 0x1000-4)
+   goto invalid_access;
+   if (mmio->is_write)
+   *(u32 *)test_reg = mmio->value;
+   else
+   mmio->value = *(u32 *)test_reg;
+   break;
+   case 8:
+   if (mmio->address > 0x1000-8)
+   goto invalid_access;
+   if (mmio->is_write)
+   *(u64 *)test_reg = mmio->value;
+   else
+   mmio->value = *(u64 *)test_reg;
+   break;
+   }
+   return MMIO_HANDLED;
+
+invalid_access:
+   printk("testdev: invalid %s, register %lx, size %d\n",
+  mmio->is_write ? "write" : "read", mmio->address, mmio->size);
+   return MMIO_ERROR;
+}
+
+static unsigned long testdev_get_mmio_base(struct cell *cell)
+{
+   const struct jailhouse_memory *mem;
+   unsigned int n;
+
+   for_each_mem_region(mem, cell->config, n)
+   if (mem->flags & JAILHOUSE_MEM_COMM_REGION)
+   return mem->virt_start + PAGE_SIZE;
+
+   return INVALID_PHYS_ADDR;
+}
+
+static int testdev_cell_init(struct cell *cell)
+{
+   unsigned long comm_base;
+
+   if (cell->config->flags & JAILHOUSE_CELL_TEST_DEVICE) {
+   comm_base = testdev_get_mmio_base(cell);
+   if (comm_base == INVALID_PHYS_ADDR)
+   return trace_error(-EINVAL);
+
+   mmio_region_register(cell, comm_base, PAGE_SIZE,
+

[PATCH 01/16] arm: Remove empty and dead struct pci_cell

[Jan Kiszka]

From: Jan Kiszka 

Probably a left-over from earlier versions of 018f4afa844b.

Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/arm/include/asm/cell.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/hypervisor/arch/arm/include/asm/cell.h 
b/hypervisor/arch/arm/include/asm/cell.h
index a935eb337..29c1ac3ee 100644
--- a/hypervisor/arch/arm/include/asm/cell.h
+++ b/hypervisor/arch/arm/include/asm/cell.h
@@ -24,9 +24,5 @@ struct arch_cell {
u32 irq_bitmap[1024/32];
 };
 
-/** PCI-related cell states. */
-struct pci_cell {
-};
-
 #endif /* !__ASSEMBLY__ */
 #endif /* !_JAILHOUSE_ASM_CELL_H */
-- 
2.13.6

-- 
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 03/16] arm-common: Drop __ASSEMBLY__ guard from asm/cell.h

[Jan Kiszka]

From: Jan Kiszka 

Header is not pulled by assembler sources.

Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/arm-common/include/asm/cell.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/hypervisor/arch/arm-common/include/asm/cell.h 
b/hypervisor/arch/arm-common/include/asm/cell.h
index 11dba73df..5b1e42070 100644
--- a/hypervisor/arch/arm-common/include/asm/cell.h
+++ b/hypervisor/arch/arm-common/include/asm/cell.h
@@ -13,8 +13,6 @@
 #ifndef _JAILHOUSE_ASM_CELL_H
 #define _JAILHOUSE_ASM_CELL_H
 
-#ifndef __ASSEMBLY__
-
 #include 
 
 struct arch_cell {
@@ -23,5 +21,4 @@ struct arch_cell {
u32 irq_bitmap[1024/32];
 };
 
-#endif /* !__ASSEMBLY__ */
 #endif /* !_JAILHOUSE_ASM_CELL_H */
-- 
2.13.6

-- 
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 02/16] arm/arm64: Use common asm/cell.h

[Jan Kiszka]

From: Jan Kiszka 

It's now identical.

Signed-off-by: Jan Kiszka 
---
 .../arch/{arm => arm-common}/include/asm/cell.h|  1 -
 hypervisor/arch/arm64/include/asm/cell.h   | 27 --
 2 files changed, 28 deletions(-)
 rename hypervisor/arch/{arm => arm-common}/include/asm/cell.h (94%)
 delete mode 100644 hypervisor/arch/arm64/include/asm/cell.h

diff --git a/hypervisor/arch/arm/include/asm/cell.h 
b/hypervisor/arch/arm-common/include/asm/cell.h
similarity index 94%
rename from hypervisor/arch/arm/include/asm/cell.h
rename to hypervisor/arch/arm-common/include/asm/cell.h
index 29c1ac3ee..11dba73df 100644
--- a/hypervisor/arch/arm/include/asm/cell.h
+++ b/hypervisor/arch/arm-common/include/asm/cell.h
@@ -17,7 +17,6 @@
 
 #include 
 
-/** ARM-specific cell states. */
 struct arch_cell {
struct paging_structures mm;
 
diff --git a/hypervisor/arch/arm64/include/asm/cell.h 
b/hypervisor/arch/arm64/include/asm/cell.h
deleted file mode 100644
index 091a983f8..0
--- a/hypervisor/arch/arm64/include/asm/cell.h
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * Jailhouse AArch64 support
- *
- * Copyright (C) 2015 Huawei Technologies Duesseldorf GmbH
- *
- * Authors:
- *  Antonios Motakis 
- *
- * This work is licensed under the terms of the GNU GPL, version 2.  See
- * the COPYING file in the top-level directory.
- */
-
-#ifndef _JAILHOUSE_ASM_CELL_H
-#define _JAILHOUSE_ASM_CELL_H
-
-#ifndef __ASSEMBLY__
-
-#include 
-
-struct arch_cell {
-   struct paging_structures mm;
-
-   u32 irq_bitmap[1024/32];
-};
-
-#endif /* !__ASSEMBLY__ */
-#endif /* !_JAILHOUSE_ASM_CELL_H */
-- 
2.13.6

-- 
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 05/16] build: Add a dummy recipe to ensure evaluation of arch subdir results

[Jan Kiszka]

From: Jan Kiszka 

Without this, make may skip over relinking the core against the arch
subdir results while the latter is still being built. This was
reproducible by touching an architecture file and then rebuild with -j.

Fixes: f5a0a36601c2 ("core: Rework architecture subdir build")
Signed-off-by: Jan Kiszka 
---
 hypervisor/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hypervisor/Makefile b/hypervisor/Makefile
index 4ba2df6af..5d441a035 100644
--- a/hypervisor/Makefile
+++ b/hypervisor/Makefile
@@ -93,6 +93,7 @@ define BUILD_JAILHOUSE_template
 always += jailhouse$(1).bin
 
 $$(obj)/arch/$$(SRCARCH)/built-in$(1).o: $$(obj)/arch/$$(SRCARCH)
+   @true
 
 hypervisor$(1)-y := arch/$$(SRCARCH)/built-in$(1).o $$(CORE_OBJECTS) \
hypervisor.lds
-- 
2.13.6

-- 
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 09/16] x86: mmio: Fix handling of displacement bytes when writing immediates

[Jan Kiszka]

From: Jan Kiszka 

We only skipped over 32-bit displacements in mod 0 so far. But mod 1 and
2 can bring them as well. Moreover, we incremented inst_len even when
skipping via ctx_update, which accounted the displacement twice.

Fix this by pulling out the displacement skip, moving it before the
immediate retrieval. If there is no immediate to read, directly add the
displacement length to inst_len.

Fixes: 95202a038b9e ("x86,mmio: Add support for 1 more instructions on
  the MMIO dispatcher")
Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/x86/mmio.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/hypervisor/arch/x86/mmio.c b/hypervisor/arch/x86/mmio.c
index 8139a462d..c30f69b5c 100644
--- a/hypervisor/arch/x86/mmio.c
+++ b/hypervisor/arch/x86/mmio.c
@@ -77,12 +77,12 @@ struct mmio_instruction x86_mmio_parse(unsigned long pc,
 .count = 1 };
union registers *guest_regs = _cpu_data()->guest_regs;
struct mmio_instruction inst = { .inst_len = 0 };
+   unsigned int n, skip_len = 0;
bool has_immediate = false;
union opcode op[4] = { };
bool does_write = false;
bool has_rex_w = false;
bool has_rex_r = false;
-   unsigned int n;
 
if (!ctx_update(, , 0, pg_structs))
goto error_noinst;
@@ -151,29 +151,24 @@ restart:
switch (op[2].modrm.mod) {
case 0:
if (op[2].modrm.rm == 5) { /* 32-bit displacement */
-   inst.inst_len += 4;
-   /* walk displacement bytes, to point to immediate */
-   if (has_immediate &&
-   !ctx_update(, , 4, pg_structs))
-   goto error_noinst;
+   skip_len = 4;
break;
} else if (op[2].modrm.rm != 4) { /* no SIB */
break;
}
 
-
if (!ctx_update(, , 1, pg_structs))
goto error_noinst;
 
op[3].raw = *ctx.inst;
if (op[3].sib.base == 5)
-   inst.inst_len += 4;
+   skip_len = 4;
break;
case 1:
case 2:
if (op[2].modrm.rm == 4) /* SIB */
goto error_unsupported;
-   inst.inst_len += op[2].modrm.mod == 1 ? 1 : 4;
+   skip_len = op[2].modrm.mod == 1 ? 1 : 4;
break;
default:
goto error_unsupported;
@@ -186,14 +181,22 @@ restart:
else
inst.in_reg_num = 15 - op[2].modrm.reg;
 
-   if (has_immediate)
+   if (has_immediate) {
+   /* walk any not yet retrieved displacement bytes */
+   if (!ctx_update(, , skip_len, pg_structs))
+   goto error_noinst;
+
+   /* retrieve immediate value */
for (n = 0; n < IMMEDIATE_SIZE; n++) {
if (!ctx_update(, , 1, pg_structs))
goto error_noinst;
inst.out_val |= (unsigned long)*ctx.inst << (n * 8);
}
-   else if (does_write)
-   inst.out_val = guest_regs->by_index[inst.in_reg_num];
+   } else {
+   inst.inst_len += skip_len;
+   if (does_write)
+   inst.out_val = guest_regs->by_index[inst.in_reg_num];
+   }
 
 final:
if (does_write != is_write)
-- 
2.13.6

-- 
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 08/16] x86: mmio: Fix instruction length calculation for write-immediate

[Jan Kiszka]

From: Jan Kiszka 

This fixes one case around mov imm,: We read the immediate value
to be written, but we forgot to update inst_len. This fixes that issue
by moving the update from ctx.count to inst.inst_len to the very end
of the parser.

Fixes: 95202a038b9e ("x86,mmio: Add support for 1 more instructions on
  the MMIO dispatcher")
Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/x86/mmio.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/hypervisor/arch/x86/mmio.c b/hypervisor/arch/x86/mmio.c
index d7a6c0019..8139a462d 100644
--- a/hypervisor/arch/x86/mmio.c
+++ b/hypervisor/arch/x86/mmio.c
@@ -1,7 +1,7 @@
 /*
  * Jailhouse, a Linux-based partitioning hypervisor
  *
- * Copyright (c) Siemens AG, 2013
+ * Copyright (c) Siemens AG, 2013-2018
  * Copyright (c) Valentine Sinitsyn, 2014
  *
  * Authors:
@@ -130,12 +130,12 @@ restart:
does_write = true;
break;
case X86_OP_MOV_MEM_TO_AX:
-   inst.inst_len = ctx.count + 4;
+   inst.inst_len += 4;
inst.access_size = has_rex_w ? 8 : 4;
inst.in_reg_num = 15;
goto final;
case X86_OP_MOV_AX_TO_MEM:
-   inst.inst_len = ctx.count + 4;
+   inst.inst_len += 4;
inst.access_size = has_rex_w ? 8 : 4;
inst.out_val = guest_regs->by_index[15];
does_write = true;
@@ -179,7 +179,6 @@ restart:
goto error_unsupported;
}
 
-   inst.inst_len += ctx.count;
if (has_rex_r)
inst.in_reg_num = 7 - op[2].modrm.reg;
else if (op[2].modrm.reg == 4)
@@ -200,6 +199,8 @@ final:
if (does_write != is_write)
goto error_inconsitent;
 
+   inst.inst_len += ctx.count;
+
return inst;
 
 error_noinst:
-- 
2.13.6

-- 
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 10/16] x86: mmio: Reliably identify mov immediate instructions

[Jan Kiszka]

From: Jan Kiszka 

The opcode of mov imm, also consists of reg=0 in the ModR/M byte.
Make sure that we do not misinterpret an instruction.

Fixes: 95202a038b9e ("x86,mmio: Add support for 1 more instructions on
  the MMIO dispatcher")
Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/x86/mmio.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/hypervisor/arch/x86/mmio.c b/hypervisor/arch/x86/mmio.c
index c30f69b5c..8890fedb7 100644
--- a/hypervisor/arch/x86/mmio.c
+++ b/hypervisor/arch/x86/mmio.c
@@ -148,6 +148,11 @@ restart:
goto error_noinst;
 
op[2].raw = *ctx.inst;
+
+   /* ensure that we are actually talking about mov imm, */
+   if (op[0].raw == X86_OP_MOV_IMMEDIATE_TO_MEM && op[2].modrm.reg != 0)
+   goto error_unsupported;
+
switch (op[2].modrm.mod) {
case 0:
if (op[2].modrm.rm == 5) { /* 32-bit displacement */
-- 
2.13.6

-- 
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 15/16] x86: mmio: Fix parsing for mov ax to/from mem in 64-bit mode

[Jan Kiszka]

From: Jan Kiszka 

In long mode, we have 64-bit addresses by default, and so we need to
skip over 8 bytes of address for that instruction.

Fixes: ea43ce86f4e3 ("x86,mmio: Add support for 2 more instructions on
  the MMIO dispatcher")
Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/x86/mmio.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hypervisor/arch/x86/mmio.c b/hypervisor/arch/x86/mmio.c
index b96fbcf42..c1b9f10e8 100644
--- a/hypervisor/arch/x86/mmio.c
+++ b/hypervisor/arch/x86/mmio.c
@@ -75,6 +75,7 @@ x86_mmio_parse(const struct guest_paging_structures 
*pg_structs, bool is_write)
struct parse_context ctx = { .remaining = X86_MAX_INST_LEN,
 .count = 1 };
union registers *guest_regs = _cpu_data()->guest_regs;
+   bool addr64 = !!(vcpu_vendor_get_efer() & EFER_LMA);
struct mmio_instruction inst = { .inst_len = 0 };
u64 pc = vcpu_vendor_get_rip();
unsigned int n, skip_len = 0;
@@ -130,12 +131,12 @@ restart:
does_write = true;
break;
case X86_OP_MOV_MEM_TO_AX:
-   inst.inst_len += 4;
+   inst.inst_len += addr64 ? 8 : 4;
inst.access_size = has_rex_w ? 8 : 4;
inst.in_reg_num = 15;
goto final;
case X86_OP_MOV_AX_TO_MEM:
-   inst.inst_len += 4;
+   inst.inst_len += addr64 ? 8 : 4;
inst.access_size = has_rex_w ? 8 : 4;
inst.out_val = guest_regs->by_index[15];
does_write = true;
-- 
2.13.6

-- 
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 11/16] x86: mmio: Sign-extend immediate of 64-bit mov

[Jan Kiszka]

From: Jan Kiszka 

The immediate value of mov imm, is still 32-bit in case of a 64-bit
write, but it has to be sign-extended in that case. Add the missing
logic.

Fixes: 95202a038b9e ("x86,mmio: Add support for 1 more instructions on
  the MMIO dispatcher")
Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/x86/mmio.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hypervisor/arch/x86/mmio.c b/hypervisor/arch/x86/mmio.c
index 8890fedb7..b76b5356b 100644
--- a/hypervisor/arch/x86/mmio.c
+++ b/hypervisor/arch/x86/mmio.c
@@ -197,6 +197,10 @@ restart:
goto error_noinst;
inst.out_val |= (unsigned long)*ctx.inst << (n * 8);
}
+
+   /* sign-extend immediate if the target is 64-bit */
+   if (has_rex_w)
+   inst.out_val = (s64)(s32)inst.out_val;
} else {
inst.inst_len += skip_len;
if (does_write)
-- 
2.13.6

-- 
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 07/16] inmates: x86: Add test case for MMIO accessing instructions

[Jan Kiszka]

From: Jan Kiszka 

This lays the ground for systematic tests of the MMIO instruction parser
in x86. The test-case inmate uses the new MMIO access test device for
writing and reading with yet a small number of instructions variants.
This is supposed to expanded later on with further patterns - but it
already revealed several bugs in the handling of immediate writes.

Signed-off-by: Jan Kiszka 
---
 configs/x86/tiny-demo.c |   3 +-
 inmates/Makefile|   7 +-
 inmates/tests/arm/Makefile  |   1 +
 inmates/tests/arm64/Makefile|   1 +
 inmates/tests/x86/Makefile  |  19 +
 inmates/tests/x86/mmio-access.c | 149 
 6 files changed, 176 insertions(+), 4 deletions(-)
 create mode 100644 inmates/tests/arm/Makefile
 create mode 100644 inmates/tests/arm64/Makefile
 create mode 100644 inmates/tests/x86/Makefile
 create mode 100644 inmates/tests/x86/mmio-access.c

diff --git a/configs/x86/tiny-demo.c b/configs/x86/tiny-demo.c
index 9666bf63c..0556cd88a 100644
--- a/configs/x86/tiny-demo.c
+++ b/configs/x86/tiny-demo.c
@@ -28,7 +28,8 @@ struct {
.signature = JAILHOUSE_CELL_DESC_SIGNATURE,
.revision = JAILHOUSE_CONFIG_REVISION,
.name = "tiny-demo",
-   .flags = JAILHOUSE_CELL_PASSIVE_COMMREG,
+   .flags = JAILHOUSE_CELL_PASSIVE_COMMREG |
+   JAILHOUSE_CELL_TEST_DEVICE,
 
.cpu_set_size = sizeof(config.cpus),
.num_memory_regions = ARRAY_SIZE(config.mem_regions),
diff --git a/inmates/Makefile b/inmates/Makefile
index 29b6236c6..2f26bf55d 100644
--- a/inmates/Makefile
+++ b/inmates/Makefile
@@ -35,7 +35,8 @@ endif
 OBJCOPYFLAGS := -O binary
 LDFLAGS += --gc-sections -T
 
-subdir-y := lib/$(SRCARCH) demos/$(SRCARCH) tools/$(SRCARCH)
+subdir-y := lib/$(SRCARCH) demos/$(SRCARCH) tests/$(SRCARCH) tools/$(SRCARCH)
 
-# demos and tools depend on the library
-$(obj)/demos/$(SRCARCH) $(obj)/tools/$(SRCARCH): $(obj)/lib/$(SRCARCH)
+# demos, tests and tools depend on the library
+$(obj)/demos/$(SRCARCH) $(obj)/tests/$(SRCARCH) $(obj)/tools/$(SRCARCH): \
+   $(obj)/lib/$(SRCARCH)
diff --git a/inmates/tests/arm/Makefile b/inmates/tests/arm/Makefile
new file mode 100644
index 0..7ae637a7b
--- /dev/null
+++ b/inmates/tests/arm/Makefile
@@ -0,0 +1 @@
+# nothing to do for now
diff --git a/inmates/tests/arm64/Makefile b/inmates/tests/arm64/Makefile
new file mode 100644
index 0..7ae637a7b
--- /dev/null
+++ b/inmates/tests/arm64/Makefile
@@ -0,0 +1 @@
+# nothing to do for now
diff --git a/inmates/tests/x86/Makefile b/inmates/tests/x86/Makefile
new file mode 100644
index 0..ba276eb87
--- /dev/null
+++ b/inmates/tests/x86/Makefile
@@ -0,0 +1,19 @@
+#
+# Jailhouse, a Linux-based partitioning hypervisor
+#
+# Copyright (c) Siemens AG, 2013-2018
+#
+# Authors:
+#  Jan Kiszka 
+#
+# This work is licensed under the terms of the GNU GPL, version 2.  See
+# the COPYING file in the top-level directory.
+#
+
+include $(INMATES_LIB)/Makefile.lib
+
+INMATES := mmio-access.bin
+
+mmio-access-y := mmio-access.o
+
+$(eval $(call DECLARE_TARGETS,$(INMATES)))
diff --git a/inmates/tests/x86/mmio-access.c b/inmates/tests/x86/mmio-access.c
new file mode 100644
index 0..243e975b4
--- /dev/null
+++ b/inmates/tests/x86/mmio-access.c
@@ -0,0 +1,149 @@
+/*
+ * Jailhouse, a Linux-based partitioning hypervisor
+ *
+ * Copyright (c) Siemens AG, 2018
+ *
+ * Authors:
+ *  Jan Kiszka 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ */
+
+#include 
+
+#define EXPECT_EQUAL(a, b) evaluate(a, b, __LINE__)
+
+#define COMM_REGION_BASE   0x10
+
+static bool all_passed = true;
+
+static void evaluate(u64 a, u64 b, int line)
+{
+   bool passed = (a == b);
+
+   printk("Test at line #%d %s\n", line, passed ? "passed" : "FAILED");
+   if (!passed) {
+   printk(" %llx != %llx\n", a, b);
+   all_passed = false;
+   }
+}
+
+void inmate_main(void)
+{
+   volatile u64 *comm_page_reg = (void *)(COMM_REGION_BASE + 0xff8);
+   void *mmio_reg = (void *)(COMM_REGION_BASE + 0x1ff8);
+   u64 pattern, reg64;
+
+   printk("\n");
+
+   /* --- Read Tests --- */
+
+   pattern = 0x1122334455667788;
+   mmio_write64(mmio_reg, pattern);
+   EXPECT_EQUAL(*comm_page_reg, pattern);
+
+   /* MOV_FROM_MEM (8b), 64-bit data, mod=0, reg=0, rm=3 */
+   asm volatile("movq (%%rbx), %%rax"
+   : "=a" (reg64) : "a" (0), "b" (mmio_reg));
+   EXPECT_EQUAL(reg64, pattern);
+
+   /* MOV_FROM_MEM (8b), 32-bit data */
+   asm volatile("movl (%%rbx), %%eax"
+   : "=a" (reg64) : "a" (0), "b" (mmio_reg));
+   EXPECT_EQUAL(reg64, (u32)pattern);
+
+   /* MOVZXB (0f b6), to 64-bit, mod=0, 

[PATCH 04/16] build: Cosmetic improvements for COMMON_OBJECTS variables

[Jan Kiszka]

From: Jan Kiszka 

Rename COMMON_OBJECTS to common-objs-y so that optional objects can more
easily be appended. Also decapitalize OBJS-y to be visually more
friendly.

No functional changes.

Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/arm-common/Kbuild   | 10 +-
 hypervisor/arch/arm/Kbuild  |  4 ++--
 hypervisor/arch/arm64/Kbuild|  4 ++--
 hypervisor/arch/x86/Kbuild  | 10 +-
 inmates/lib/arm-common/Makefile.lib | 12 ++--
 inmates/lib/arm/Makefile|  2 +-
 inmates/lib/arm64/Makefile  |  4 ++--
 7 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/hypervisor/arch/arm-common/Kbuild 
b/hypervisor/arch/arm-common/Kbuild
index 127bc5987..95c5123e5 100644
--- a/hypervisor/arch/arm-common/Kbuild
+++ b/hypervisor/arch/arm-common/Kbuild
@@ -14,9 +14,9 @@
 
 ccflags-$(CONFIG_JAILHOUSE_GCOV) += -fprofile-arcs -ftest-coverage
 
-OBJS-y += dbg-write.o lib.o psci.o control.o paging.o mmu_cell.o setup.o
-OBJS-y += irqchip.o pci.o ivshmem.o uart-pl011.o uart-xuartps.o uart-mvebu.o
-OBJS-y += uart-hscif.o uart-scifa.o uart-imx.o
-OBJS-y += gic-v2.o gic-v3.o
+objs-y += dbg-write.o lib.o psci.o control.o paging.o mmu_cell.o setup.o
+objs-y += irqchip.o pci.o ivshmem.o uart-pl011.o uart-xuartps.o uart-mvebu.o
+objs-y += uart-hscif.o uart-scifa.o uart-imx.o
+objs-y += gic-v2.o gic-v3.o
 
-COMMON_OBJECTS = $(addprefix ../arm-common/,$(OBJS-y))
+common-objs-y = $(addprefix ../arm-common/,$(objs-y))
diff --git a/hypervisor/arch/arm/Kbuild b/hypervisor/arch/arm/Kbuild
index ed29417ad..bdbb88ea2 100644
--- a/hypervisor/arch/arm/Kbuild
+++ b/hypervisor/arch/arm/Kbuild
@@ -17,9 +17,9 @@ KBUILD_AFLAGS := $(subst -include 
asm/unified.h,,$(KBUILD_AFLAGS))
 always := built-in.o
 
 # units initialization order as defined by linking order:
-# irqchip (COMMON_OBJECTS), [vexpress], 
+# irqchip (common-objs-y), [vexpress], 
 
-obj-y := $(COMMON_OBJECTS)
+obj-y := $(common-objs-y)
 obj-y += entry.o setup.o control.o traps.o mmio.o lib.o
 obj-y += mmu_hyp.o caches.o
 
diff --git a/hypervisor/arch/arm64/Kbuild b/hypervisor/arch/arm64/Kbuild
index 54cf6f015..d659392ba 100644
--- a/hypervisor/arch/arm64/Kbuild
+++ b/hypervisor/arch/arm64/Kbuild
@@ -17,7 +17,7 @@ include $(src)/../arm-common/Kbuild
 always := built-in.o
 
 # units initialization order as defined by linking order:
-# irqchip (COMMON_OBJECTS), 
+# irqchip (common-objs-y), 
 
-obj-y := $(COMMON_OBJECTS)
+obj-y := $(common-objs-y)
 obj-y += entry.o setup.o control.o mmio.o caches.o traps.o
diff --git a/hypervisor/arch/x86/Kbuild b/hypervisor/arch/x86/Kbuild
index 829e8f870..476f9c1cc 100644
--- a/hypervisor/arch/x86/Kbuild
+++ b/hypervisor/arch/x86/Kbuild
@@ -22,13 +22,13 @@ always := $(BUILT_IN_OBJECTS)
 
 obj-y := $(BUILT_IN_OBJECTS)
 
-COMMON_OBJECTS := apic.o dbg-write.o entry.o setup.o control.o mmio.o iommu.o \
- paging.o pci.o i8042.o vcpu.o vga.o ivshmem.o
+common-objs-y := apic.o dbg-write.o entry.o setup.o control.o mmio.o iommu.o \
+paging.o pci.o i8042.o vcpu.o vga.o ivshmem.o
 
 # units initialization order as defined by linking order:
 # iommu, ioapic, [cat], 
 
-COMMON_OBJECTS += ioapic.o
+common-objs-y += ioapic.o
 
-built-in-amd-y := svm.o amd_iommu.o svm-vmexit.o $(COMMON_OBJECTS)
-built-in-intel-y := vmx.o vtd.o vmx-vmexit.o $(COMMON_OBJECTS) cat.o
+built-in-amd-y := svm.o amd_iommu.o svm-vmexit.o $(common-objs-y)
+built-in-intel-y := vmx.o vtd.o vmx-vmexit.o $(common-objs-y) cat.o
diff --git a/inmates/lib/arm-common/Makefile.lib 
b/inmates/lib/arm-common/Makefile.lib
index 4c35cdc60..fb3b6585f 100644
--- a/inmates/lib/arm-common/Makefile.lib
+++ b/inmates/lib/arm-common/Makefile.lib
@@ -36,10 +36,10 @@
 # THE POSSIBILITY OF SUCH DAMAGE.
 #
 
-OBJS-y := ../string.o ../cmdline.o
-OBJS-y += printk.o gic.o timer.o
-OBJS-y += uart-jailhouse.o uart-pl011.o uart-8250.o uart-8250-8.o
-OBJS-y += uart-xuartps.o uart-mvebu.o uart-hscif.o uart-scifa.o uart-imx.o
-OBJS-y += gic-v2.o gic-v3.o
+objs-y := ../string.o ../cmdline.o
+objs-y += printk.o gic.o timer.o
+objs-y += uart-jailhouse.o uart-pl011.o uart-8250.o uart-8250-8.o
+objs-y += uart-xuartps.o uart-mvebu.o uart-hscif.o uart-scifa.o uart-imx.o
+objs-y += gic-v2.o gic-v3.o
 
-COMMON_OBJECTS = $(addprefix ../arm-common/,$(OBJS-y))
+common-objs-y = $(addprefix ../arm-common/,$(objs-y))
diff --git a/inmates/lib/arm/Makefile b/inmates/lib/arm/Makefile
index daabd635d..ed07d230d 100644
--- a/inmates/lib/arm/Makefile
+++ b/inmates/lib/arm/Makefile
@@ -43,5 +43,5 @@ always := lib.a inmate.lds
 
 ccflags-y := -ffunction-sections
 
-lib-y := $(COMMON_OBJECTS)
+lib-y := $(common-objs-y)
 lib-y += header.o
diff --git a/inmates/lib/arm64/Makefile b/inmates/lib/arm64/Makefile
index 842e954d8..2cc0c658c 100644
--- a/inmates/lib/arm64/Makefile
+++ b/inmates/lib/arm64/Makefile
@@ -41,5 +41,5 @@ include $(INMATES_LIB)/../arm-common/Makefile.lib
 
 always := lib.a inmate.lds
 

[PATCH 12/16] x86: mmio: Complete SIB + displacement support

[Jan Kiszka]

From: Jan Kiszka 

The case of mod=1 or 2 and rm = 4 (SIB) is easy to handle because we do
not need to evaluate the SIB byte and can simply skip over it.

Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/x86/mmio.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hypervisor/arch/x86/mmio.c b/hypervisor/arch/x86/mmio.c
index b76b5356b..93f62f29e 100644
--- a/hypervisor/arch/x86/mmio.c
+++ b/hypervisor/arch/x86/mmio.c
@@ -171,9 +171,9 @@ restart:
break;
case 1:
case 2:
-   if (op[2].modrm.rm == 4) /* SIB */
-   goto error_unsupported;
skip_len = op[2].modrm.mod == 1 ? 1 : 4;
+   if (op[2].modrm.rm == 4) /* SIB */
+   skip_len++;
break;
default:
goto error_unsupported;
@@ -187,7 +187,7 @@ restart:
inst.in_reg_num = 15 - op[2].modrm.reg;
 
if (has_immediate) {
-   /* walk any not yet retrieved displacement bytes */
+   /* walk any not yet retrieved SIB or displacement bytes */
if (!ctx_update(, , skip_len, pg_structs))
goto error_noinst;
 
-- 
2.13.6

-- 
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 16/16] x86: Remove misleading brackets from mmio instruction dump

[Jan Kiszka]

From: Jan Kiszka 

The parser my bail out on opcode byte 0-2.

Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/x86/mmio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hypervisor/arch/x86/mmio.c b/hypervisor/arch/x86/mmio.c
index c1b9f10e8..775ec4b7b 100644
--- a/hypervisor/arch/x86/mmio.c
+++ b/hypervisor/arch/x86/mmio.c
@@ -219,7 +219,7 @@ error_noinst:
 
 error_unsupported:
panic_printk("FATAL: unsupported instruction "
-"(0x%02x [0x%02x] 0x%02x 0x%02x)\n",
+"(0x%02x 0x%02x 0x%02x 0x%02x)\n",
 op[0].raw, op[1].raw, op[2].raw, op[3].raw);
goto error;
 
-- 
2.13.6

-- 
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 13/16] x86: mmio: Refactor code for mod=0 handling

[Jan Kiszka]

From: Jan Kiszka 

This just improves readability and makes the code more compact. The
rm cases are now dispatched in ascending order.

Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/x86/mmio.c | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/hypervisor/arch/x86/mmio.c b/hypervisor/arch/x86/mmio.c
index 93f62f29e..d4589d60d 100644
--- a/hypervisor/arch/x86/mmio.c
+++ b/hypervisor/arch/x86/mmio.c
@@ -155,19 +155,16 @@ restart:
 
switch (op[2].modrm.mod) {
case 0:
-   if (op[2].modrm.rm == 5) { /* 32-bit displacement */
-   skip_len = 4;
-   break;
-   } else if (op[2].modrm.rm != 4) { /* no SIB */
-   break;
-   }
-
-   if (!ctx_update(, , 1, pg_structs))
-   goto error_noinst;
+   if (op[2].modrm.rm == 4) { /* SIB */
+   if (!ctx_update(, , 1, pg_structs))
+   goto error_noinst;
 
-   op[3].raw = *ctx.inst;
-   if (op[3].sib.base == 5)
+   op[3].raw = *ctx.inst;
+   if (op[3].sib.base == 5)
+   skip_len = 4;
+   } else if (op[2].modrm.rm == 5) { /* 32-bit displacement */
skip_len = 4;
+   }
break;
case 1:
case 2:
-- 
2.13.6

-- 
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 14/16] x86: Split up vcpu_vendor_get_execution_state

[Jan Kiszka]

From: Jan Kiszka 

Rather than always pulling the four fields of vcpu_execution_state at
once, introduce individual accessor functions. This allows to reduce the
number of expensive vmcs_read operations on Intel to 2 for typical
hypercalls and all MMIO interceptions.

Signed-off-by: Jan Kiszka 
---
 hypervisor/arch/x86/apic.c |  5 ++---
 hypervisor/arch/x86/include/asm/apic.h |  3 +--
 hypervisor/arch/x86/include/asm/mmio.h |  5 ++---
 hypervisor/arch/x86/include/asm/vcpu.h | 13 +
 hypervisor/arch/x86/mmio.c |  8 
 hypervisor/arch/x86/svm.c  | 22 +-
 hypervisor/arch/x86/vcpu.c | 20 ++--
 hypervisor/arch/x86/vmx.c  | 21 +
 8 files changed, 46 insertions(+), 51 deletions(-)

diff --git a/hypervisor/arch/x86/apic.c b/hypervisor/arch/x86/apic.c
index 91a38b23a..3bc31d460 100644
--- a/hypervisor/arch/x86/apic.c
+++ b/hypervisor/arch/x86/apic.c
@@ -483,8 +483,7 @@ static bool apic_invalid_lvt_delivery_mode(unsigned int 
reg, u32 val)
return true;
 }
 
-unsigned int apic_mmio_access(unsigned long rip,
- const struct guest_paging_structures *pg_structs,
+unsigned int apic_mmio_access(const struct guest_paging_structures *pg_structs,
  unsigned int reg, bool is_write)
 {
struct mmio_instruction inst;
@@ -495,7 +494,7 @@ unsigned int apic_mmio_access(unsigned long rip,
return 0;
}
 
-   inst = x86_mmio_parse(rip, pg_structs, is_write);
+   inst = x86_mmio_parse(pg_structs, is_write);
if (inst.inst_len == 0)
return 0;
if (inst.access_size != 4) {
diff --git a/hypervisor/arch/x86/include/asm/apic.h 
b/hypervisor/arch/x86/include/asm/apic.h
index d2cd632a5..41534393e 100644
--- a/hypervisor/arch/x86/include/asm/apic.h
+++ b/hypervisor/arch/x86/include/asm/apic.h
@@ -162,8 +162,7 @@ void apic_send_irq(struct apic_irq_message irq_msg);
 
 void apic_irq_handler(void);
 
-unsigned int apic_mmio_access(unsigned long rip,
- const struct guest_paging_structures *pg_structs,
+unsigned int apic_mmio_access(const struct guest_paging_structures *pg_structs,
  unsigned int reg, bool is_write);
 
 bool x2apic_handle_write(void);
diff --git a/hypervisor/arch/x86/include/asm/mmio.h 
b/hypervisor/arch/x86/include/asm/mmio.h
index 2b66114a9..756c84a88 100644
--- a/hypervisor/arch/x86/include/asm/mmio.h
+++ b/hypervisor/arch/x86/include/asm/mmio.h
@@ -34,14 +34,13 @@ struct mmio_instruction {
 
 /**
  * Parse instruction causing an intercepted MMIO access on a cell CPU.
- * @param pc   Program counter of the access instruction.
  * @param pg_structs   Currently active guest (cell) paging structures.
  * @param is_write True if write access, false for read.
  *
  * @return MMIO instruction information. mmio_instruction::inst_len is 0 on
  *invalid or unsupported access.
  */
-struct mmio_instruction x86_mmio_parse(unsigned long pc,
-   const struct guest_paging_structures *pg_structs, bool is_write);
+struct mmio_instruction
+x86_mmio_parse(const struct guest_paging_structures *pg_structs, bool 
is_write);
 
 /** @} */
diff --git a/hypervisor/arch/x86/include/asm/vcpu.h 
b/hypervisor/arch/x86/include/asm/vcpu.h
index 0782d50d7..429c735e0 100644
--- a/hypervisor/arch/x86/include/asm/vcpu.h
+++ b/hypervisor/arch/x86/include/asm/vcpu.h
@@ -30,13 +30,6 @@ struct vcpu_io_bitmap {
u32 size;
 };
 
-struct vcpu_execution_state {
-   u64 efer;
-   u64 rflags;
-   u16 cs;
-   u64 rip;
-};
-
 struct vcpu_io_intercept {
u16 port;
unsigned int size;
@@ -100,7 +93,11 @@ void vcpu_skip_emulated_instruction(unsigned int inst_len);
 void vcpu_vendor_get_cell_io_bitmap(struct cell *cell,
struct vcpu_io_bitmap *out);
 
-void vcpu_vendor_get_execution_state(struct vcpu_execution_state *x_state);
+u64 vcpu_vendor_get_efer(void);
+u64 vcpu_vendor_get_rflags(void);
+u64 vcpu_vendor_get_rip(void);
+u16 vcpu_vendor_get_cs(void);
+
 void vcpu_vendor_get_io_intercept(struct vcpu_io_intercept *io);
 void vcpu_vendor_get_mmio_intercept(struct vcpu_mmio_intercept *mmio);
 
diff --git a/hypervisor/arch/x86/mmio.c b/hypervisor/arch/x86/mmio.c
index d4589d60d..b96fbcf42 100644
--- a/hypervisor/arch/x86/mmio.c
+++ b/hypervisor/arch/x86/mmio.c
@@ -51,8 +51,7 @@ struct parse_context {
const u8 *inst;
 };
 
-static bool ctx_update(struct parse_context *ctx,
-  unsigned long *pc, unsigned int advance,
+static bool ctx_update(struct parse_context *ctx, u64 *pc, unsigned int 
advance,
   const struct guest_paging_structures *pg)
 {
ctx->inst += advance;
@@ -70,13 +69,14 @@ static bool ctx_update(struct parse_context *ctx,
return true;
 }
 

Re: Sharing Memory region between root and non-root cell

[Jan Kiszka]

On 2018-04-23 16:21, moyin...@gmail.com wrote:
> On Friday, April 20, 2018 at 12:07:58 PM UTC+5:30, J. Kiszka wrote:
>> On 2018-04-20 07:01, moyin...@gmail.com wrote:
>>> On Thursday, April 19, 2018 at 8:17:18 PM UTC+5:30, J. Kiszka wrote:
 On 2018-04-19 09:51, moyin...@gmail.com wrote:
> Hi,
>
>   I am trying some experiments in Shared memory, 
> CASE 1:
> I have shared some common memory region between root and non-root cell. 
> using this mem-region i am able to communicate between root and non-root 
> cell(if i write data from root cell to that mem-region i am able to read 
> the same data in non-root cell). I have added shared memory in the root 
> cell at the end-of mem-region(last-index of mem-region).
>
> CASE 2:
>  But when i add this shared mem-region in the middle of root cell 
> mem-region, i am not able to communicate between root and non-root 
> cell(read and write is not happening from root-cell to non-root cell). 
>
> Can someone please explain me why CASE 2 is not working, is that 
> mandatory to add shared memory config at the end-of mem-region(last 
> index)?  
>
> * I am not linked any PCI device to shared mem-region in both the cases.
>
> * For reading and writing from shared mem-region we are using our 
> application.
>
>>> Thanks for the replay Jan,
>>>
 It's hard to give you any good suggestion without seeing the configs in
 question. 
>>> I am attaching both root and non-root cell configs can you please take look 
>>> at it once.
>>>
 Maybe you didn't split up that larger mem region properly into
 two regions, 
>>>
>>>  My inmate starting address is: 0x40400, and my inmate high RAM starts 
>>> from 0x40430, I am adding below region into both root and non-root 
>>> cell(non-root cell i added JAILHOUSE_MEM_ROOTSHARED flag). 
>>>
>>> /* MemRegion: 40410 : IVSHMEM :JH-added */
>>> {
>>> .phys_start = 0x40410,
>>> .virt_start = 0x40410,
>>> .size = 0x10,
>>> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
>>> },
>>>
>>>
 maybe the reference from the ivshmem device to the share
 memory region by index is not longer correct, 
>>>
>>> i am not linking PCI config to mem-region, index is only matter when we 
>>> link PCI and mem-region is that correct?
>>
>> Your configs do not contain any shared memory device.
> I agreed my config do not contain any shared memory device but my config 
> contain 
> shared memory region. The below region i am sharing both root and non-root 
> cell, but i am not linking any PCI device to these region.
> 
> /* MemRegion: 40410 : IVSHMEM :JH-added */
> {
> .phys_start = 0x40410,
> .virt_start = 0x40410,
> .size = 0x10,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
> },
> 
> 
>> Look at
>> configs/[x86/]qemu-x86.c and .../linux-x86-demo.c to see what is
>> missing. 
> As you suggested i comapred my configs and above mentioned configs(qemu-x86.c 
> and linux-x86-demo.c), In this configs they are using PCI device to link 
> between root and non-root cell.
>  { /* IVSHMEM (networking) */
> .type = JAILHOUSE_PCI_TYPE_IVSHMEM,
> .domain = 0x,
> .bdf = 0x0e << 3,
> .bar_mask = {
> 0xff00, 0x, 0x,
> 0x, 0xffe0, 0x,
> },
> .num_msix_vectors = 1,
> .shmem_region = 14,
> .shmem_protocol = JAILHOUSE_SHMEM_PROTO_VETH,
> },
> 
>  But i don't want to add above PCI configuration to my configs,  Without 
> adding this configuration to my config i can communicate between root and 
> non-root cell, but only problem is i need to add my shared-region at the end 
> of my config(in mem-region). is that mandatory to add the shared-region at 
> the end-of my config(mem-region)?
> 

The configuration of shared memory regions at Jailhouse level is indeed
independent of the shared memory device. They work, irrespective of
their position in the config (if the config is otherwise correct, didn't
check for details in yours).

However, you do not get any information to your guest where these
regions are located, nor will you have event signaling (interrupts).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT 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 

Re: Jailhouse zynqMP

[iallende]

El lunes, 23 de abril de 2018, 16:12:18 (UTC+2), J. Kiszka  escribió:
> On 2018-04-23 15:48, iallende wrote:
> > El miércoles, 18 de abril de 2018, 16:05:13 (UTC+2), iallende  escribió:
> >> El miércoles, 18 de abril de 2018, 8:38:43 (UTC+2), J. Kiszka  escribió:
>  El lunes, 16 de abril de 2018, 14:45:45 (UTC+2), J. Kiszka  escribió:
> > On 2018-04-16 14:21, iallende wrote:
> >> El viernes, 13 de abril de 2018, 9:14:46 (UTC+2), J. Kiszka  escribió:
> >>> On 2018-04-12 15:15, iallende wrote:
>  It still does not work. I have the following:
> 
>  root@xilinx-zcu102-2017_4:~# modprobe jailhouse
>  [   20.762034] jailhouse: loading out-of-tree module taints kernel.
>  root@xilinx-zcu102-2017_4:~# cd /cells/
>  root@xilinx-zcu102-2017_4:/cells# jailhouse enable 
>  zynqmp-zcu102.cell 
> 
>  Initializing Jailhouse hypervisor v0.8 on CPU 2
>  Code location: 0xc0200060
>  Page pool usage after early setup: mem 33/993, remap 64/131072
>  Initializing processors:
>   CPU 2... OK
>   CPU 0... OK
>   CPU 3... OK
>   CPU 1... OK
>  Adding virtual PCI device 00:00.0 to cell "ZynqMP-ZCU102"
>  Adding virtual PCI device 00:01.0 to cell "ZynqMP-ZCU102"
>  Page pool usage after late setup: mem 42/993, remap 69/131072
>  Activating hypervisor
>  [   29.825496] The Jailhouse is opening.
>  root@xilinx-zcu102-2017_4:/cells# 
>  root@xilinx-zcu102-2017_4:/cells# 
>  root@xilinx-zcu102-2017_4:/cells# jailhouse cell linux 
>  zynqmp-zcu102-linux-demo.cell Image -d inmate-zynqmp-zcu102.dtb -i 
>  rootfs.cpio -c "console=ttyPS0,115200"
>  [   65.192135] Read fail divider address: fd1a0060
>  [   65.198616] Read fail divider address: fd1a0060
>  [   65.205473] CPU2: shutdown
>  [   65.210069] psci: CPU2 killed.
>  [   65.248402] CPU3: shutdown
>  [   65.252999] psci: CPU3 killed.
>  Adding virtual PCI device 00:00.0 to cell "ZynqMP-linux-demo"
>  Shared memory connection established: "ZynqMP-linux-demo" <--> 
>  "ZynqMP-ZCU102"
>  Adding virtual PCI device 00:02.0 to cell "ZynqMP-linux-demo"
>  Created cell "ZynqMP-linux-demo"
>  Page pool usage after cell creation: mem 59/993, remap 69/131072
>  [   65.299294] Created Jailhouse cell "ZynqMP-linux-demo"
>  Cell "ZynqMP-linux-demo" can be loaded
>  Started cell "ZynqMP-linux-demo"
>  root@xilinx-zcu102-2017_4:/cells# jailhouse cell list 
>  ID  NameState   Assigned CPUs
> Failed CPUs 
>  0   ZynqMP-ZCU102   running 0-1  
> 
>  1   ZynqMP-linux-demo   running 2-3  
> 
>  However, the UART does not show anything. I have tried with a 
>  different Linux image and the same problem. I generate the images 
>  with Petalinux. 
> 
> >>>
> >>> Try debugging the non-root boot by using the Jailhouse console for the
> >>> cell (con-type=JAILHOUSE, cell flag JAILHOUSE_CELL_DEBUG_CONSOLE, see
> >>> Documentation/debug-output.md). Check if the UART is detected by the
> >>> guest. Maybe the kernel is not configured as needed.
> >>>
> >>> Jan
> >>> -- 
> >>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >>> Corporate Competence Center Embedded Linux
> >>
> >> I have applied the patches for JAILHOUSE_DBCON  and I added 
> >> JAILHOUSE_CELL_DEBUG_CONSOLE to zynqmp-zcu102-linux-demo.c. I load the 
> >> cell like this:
> >> jailhouse cell linux zynqmp-zcu102-linux-demo.cell Image -d 
> >> inmate-zynqmp-zcu102.dtb -i rootfs.cpio -c "con-type=jailhouse"
> >>
> >> However, the booting does not appear. To see the debug output I have 
> >> to do "cat /dev/jailhouse", no?
> >>
> >
> > Rather "jailhouse console". If that only lists output of the hypervisor
> > itself, the guest does not start up. You then have some other issue. Is
> > there anything you modified, compared to upstream Jailhouse
> > configurations? Try reducing that to zero first.
> >
> > I can look up the setup on our ZCU102 to give you exact references to a
> > known-to-work setup. Definitely working was vanilla Jailhouse v0.8 (I
> > tested that prior to the release). I've also attached a reference config
> > for the Linux inmate kernel.
> >
> > I hope we can eventually handle such setup questions via the
> > jailhouse-image project, but right now that's not yet there.
> >
> > Jan
> >
> > -- 
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux
> 
>  I did 

Re: Sharing Memory region between root and non-root cell

[moyin431]

On Friday, April 20, 2018 at 12:07:58 PM UTC+5:30, J. Kiszka wrote:
> On 2018-04-20 07:01, moyin...@gmail.com wrote:
> > On Thursday, April 19, 2018 at 8:17:18 PM UTC+5:30, J. Kiszka wrote:
> >> On 2018-04-19 09:51, moyin...@gmail.com wrote:
> >>> Hi,
> >>>
> >>>   I am trying some experiments in Shared memory, 
> >>> CASE 1:
> >>> I have shared some common memory region between root and non-root cell. 
> >>> using this mem-region i am able to communicate between root and non-root 
> >>> cell(if i write data from root cell to that mem-region i am able to read 
> >>> the same data in non-root cell). I have added shared memory in the root 
> >>> cell at the end-of mem-region(last-index of mem-region).
> >>>
> >>> CASE 2:
> >>>  But when i add this shared mem-region in the middle of root cell 
> >>> mem-region, i am not able to communicate between root and non-root 
> >>> cell(read and write is not happening from root-cell to non-root cell). 
> >>>
> >>> Can someone please explain me why CASE 2 is not working, is that 
> >>> mandatory to add shared memory config at the end-of mem-region(last 
> >>> index)?  
> >>>
> >>> * I am not linked any PCI device to shared mem-region in both the cases.
> >>>
> >>> * For reading and writing from shared mem-region we are using our 
> >>> application.
> >>>
> > Thanks for the replay Jan,
> > 
> >> It's hard to give you any good suggestion without seeing the configs in
> >> question. 
> > I am attaching both root and non-root cell configs can you please take look 
> > at it once.
> > 
> >> Maybe you didn't split up that larger mem region properly into
> >> two regions, 
> > 
> >  My inmate starting address is: 0x40400, and my inmate high RAM starts 
> > from 0x40430, I am adding below region into both root and non-root 
> > cell(non-root cell i added JAILHOUSE_MEM_ROOTSHARED flag). 
> > 
> > /* MemRegion: 40410 : IVSHMEM :JH-added */
> > {
> > .phys_start = 0x40410,
> > .virt_start = 0x40410,
> > .size = 0x10,
> > .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
> > },
> > 
> > 
> >> maybe the reference from the ivshmem device to the share
> >> memory region by index is not longer correct, 
> > 
> > i am not linking PCI config to mem-region, index is only matter when we 
> > link PCI and mem-region is that correct?
> 
> Your configs do not contain any shared memory device.
I agreed my config do not contain any shared memory device but my config 
contain 
shared memory region. The below region i am sharing both root and non-root 
cell, but i am not linking any PCI device to these region.

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


> Look at
> configs/[x86/]qemu-x86.c and .../linux-x86-demo.c to see what is
> missing. 
As you suggested i comapred my configs and above mentioned configs(qemu-x86.c 
and linux-x86-demo.c), In this configs they are using PCI device to link 
between root and non-root cell.
 { /* IVSHMEM (networking) */
.type = JAILHOUSE_PCI_TYPE_IVSHMEM,
.domain = 0x,
.bdf = 0x0e << 3,
.bar_mask = {
0xff00, 0x, 0x,
0x, 0xffe0, 0x,
},
.num_msix_vectors = 1,
.shmem_region = 14,
.shmem_protocol = JAILHOUSE_SHMEM_PROTO_VETH,
},

 But i don't want to add above PCI configuration to my configs,  Without adding 
this configuration to my config i can communicate between root and non-root 
cell, but only problem is i need to add my shared-region at the end of my 
config(in mem-region). is that mandatory to add the shared-region at the end-of 
my config(mem-region)?


Moyin


> There is also a tutorial at ELC-E 2016 where I addressed the
> topic (slides and video [1]). It just misses one addtional important
> point: .iommu has to be set as well on real machines, in your case
> likely to 1.
> 
> Jan
> 
> [1] https://elinux.org/ELC_Europe_2016_Presentations
> 
> -- 
> Siemens AG, Corporate Technology, CT RDA IOT 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.

Re: Jailhouse zynqMP

[Jan Kiszka]

On 2018-04-23 15:48, iallende wrote:
> El miércoles, 18 de abril de 2018, 16:05:13 (UTC+2), iallende  escribió:
>> El miércoles, 18 de abril de 2018, 8:38:43 (UTC+2), J. Kiszka  escribió:
 El lunes, 16 de abril de 2018, 14:45:45 (UTC+2), J. Kiszka  escribió:
> On 2018-04-16 14:21, iallende wrote:
>> El viernes, 13 de abril de 2018, 9:14:46 (UTC+2), J. Kiszka  escribió:
>>> On 2018-04-12 15:15, iallende wrote:
 It still does not work. I have the following:

 root@xilinx-zcu102-2017_4:~# modprobe jailhouse
 [   20.762034] jailhouse: loading out-of-tree module taints kernel.
 root@xilinx-zcu102-2017_4:~# cd /cells/
 root@xilinx-zcu102-2017_4:/cells# jailhouse enable zynqmp-zcu102.cell 

 Initializing Jailhouse hypervisor v0.8 on CPU 2
 Code location: 0xc0200060
 Page pool usage after early setup: mem 33/993, remap 64/131072
 Initializing processors:
  CPU 2... OK
  CPU 0... OK
  CPU 3... OK
  CPU 1... OK
 Adding virtual PCI device 00:00.0 to cell "ZynqMP-ZCU102"
 Adding virtual PCI device 00:01.0 to cell "ZynqMP-ZCU102"
 Page pool usage after late setup: mem 42/993, remap 69/131072
 Activating hypervisor
 [   29.825496] The Jailhouse is opening.
 root@xilinx-zcu102-2017_4:/cells# 
 root@xilinx-zcu102-2017_4:/cells# 
 root@xilinx-zcu102-2017_4:/cells# jailhouse cell linux 
 zynqmp-zcu102-linux-demo.cell Image -d inmate-zynqmp-zcu102.dtb -i 
 rootfs.cpio -c "console=ttyPS0,115200"
 [   65.192135] Read fail divider address: fd1a0060
 [   65.198616] Read fail divider address: fd1a0060
 [   65.205473] CPU2: shutdown
 [   65.210069] psci: CPU2 killed.
 [   65.248402] CPU3: shutdown
 [   65.252999] psci: CPU3 killed.
 Adding virtual PCI device 00:00.0 to cell "ZynqMP-linux-demo"
 Shared memory connection established: "ZynqMP-linux-demo" <--> 
 "ZynqMP-ZCU102"
 Adding virtual PCI device 00:02.0 to cell "ZynqMP-linux-demo"
 Created cell "ZynqMP-linux-demo"
 Page pool usage after cell creation: mem 59/993, remap 69/131072
 [   65.299294] Created Jailhouse cell "ZynqMP-linux-demo"
 Cell "ZynqMP-linux-demo" can be loaded
 Started cell "ZynqMP-linux-demo"
 root@xilinx-zcu102-2017_4:/cells# jailhouse cell list 
 ID  NameState   Assigned CPUs  
  Failed CPUs 
 0   ZynqMP-ZCU102   running 0-1
  
 1   ZynqMP-linux-demo   running 2-3  

 However, the UART does not show anything. I have tried with a 
 different Linux image and the same problem. I generate the images with 
 Petalinux. 

>>>
>>> Try debugging the non-root boot by using the Jailhouse console for the
>>> cell (con-type=JAILHOUSE, cell flag JAILHOUSE_CELL_DEBUG_CONSOLE, see
>>> Documentation/debug-output.md). Check if the UART is detected by the
>>> guest. Maybe the kernel is not configured as needed.
>>>
>>> Jan
>>> -- 
>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>>> Corporate Competence Center Embedded Linux
>>
>> I have applied the patches for JAILHOUSE_DBCON  and I added 
>> JAILHOUSE_CELL_DEBUG_CONSOLE to zynqmp-zcu102-linux-demo.c. I load the 
>> cell like this:
>> jailhouse cell linux zynqmp-zcu102-linux-demo.cell Image -d 
>> inmate-zynqmp-zcu102.dtb -i rootfs.cpio -c "con-type=jailhouse"
>>
>> However, the booting does not appear. To see the debug output I have to 
>> do "cat /dev/jailhouse", no?
>>
>
> Rather "jailhouse console". If that only lists output of the hypervisor
> itself, the guest does not start up. You then have some other issue. Is
> there anything you modified, compared to upstream Jailhouse
> configurations? Try reducing that to zero first.
>
> I can look up the setup on our ZCU102 to give you exact references to a
> known-to-work setup. Definitely working was vanilla Jailhouse v0.8 (I
> tested that prior to the release). I've also attached a reference config
> for the Linux inmate kernel.
>
> I hope we can eventually handle such setup questions via the
> jailhouse-image project, but right now that's not yet there.
>
> Jan
>
> -- 
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

 I did both images with Petalinux 2017.4 and its default bsp. The Kernel 
 version is 4.9. How do you build your images? Yocto with meta-xilinx 
 layer? 
>>>
>>> No Yocto. Custom kernel config, mainline kernel, built via Linaro
>>> cross-toolchain, standard distro image. It's 

Re: Jailhouse zynqMP

[iallende]

El miércoles, 18 de abril de 2018, 16:05:13 (UTC+2), iallende  escribió:
> El miércoles, 18 de abril de 2018, 8:38:43 (UTC+2), J. Kiszka  escribió:
> > > El lunes, 16 de abril de 2018, 14:45:45 (UTC+2), J. Kiszka  escribió:
> > >> On 2018-04-16 14:21, iallende wrote:
> > >>> El viernes, 13 de abril de 2018, 9:14:46 (UTC+2), J. Kiszka  escribió:
> >  On 2018-04-12 15:15, iallende wrote:
> > > It still does not work. I have the following:
> > >
> > > root@xilinx-zcu102-2017_4:~# modprobe jailhouse
> > > [   20.762034] jailhouse: loading out-of-tree module taints kernel.
> > > root@xilinx-zcu102-2017_4:~# cd /cells/
> > > root@xilinx-zcu102-2017_4:/cells# jailhouse enable zynqmp-zcu102.cell 
> > >
> > > Initializing Jailhouse hypervisor v0.8 on CPU 2
> > > Code location: 0xc0200060
> > > Page pool usage after early setup: mem 33/993, remap 64/131072
> > > Initializing processors:
> > >  CPU 2... OK
> > >  CPU 0... OK
> > >  CPU 3... OK
> > >  CPU 1... OK
> > > Adding virtual PCI device 00:00.0 to cell "ZynqMP-ZCU102"
> > > Adding virtual PCI device 00:01.0 to cell "ZynqMP-ZCU102"
> > > Page pool usage after late setup: mem 42/993, remap 69/131072
> > > Activating hypervisor
> > > [   29.825496] The Jailhouse is opening.
> > > root@xilinx-zcu102-2017_4:/cells# 
> > > root@xilinx-zcu102-2017_4:/cells# 
> > > root@xilinx-zcu102-2017_4:/cells# jailhouse cell linux 
> > > zynqmp-zcu102-linux-demo.cell Image -d inmate-zynqmp-zcu102.dtb -i 
> > > rootfs.cpio -c "console=ttyPS0,115200"
> > > [   65.192135] Read fail divider address: fd1a0060
> > > [   65.198616] Read fail divider address: fd1a0060
> > > [   65.205473] CPU2: shutdown
> > > [   65.210069] psci: CPU2 killed.
> > > [   65.248402] CPU3: shutdown
> > > [   65.252999] psci: CPU3 killed.
> > > Adding virtual PCI device 00:00.0 to cell "ZynqMP-linux-demo"
> > > Shared memory connection established: "ZynqMP-linux-demo" <--> 
> > > "ZynqMP-ZCU102"
> > > Adding virtual PCI device 00:02.0 to cell "ZynqMP-linux-demo"
> > > Created cell "ZynqMP-linux-demo"
> > > Page pool usage after cell creation: mem 59/993, remap 69/131072
> > > [   65.299294] Created Jailhouse cell "ZynqMP-linux-demo"
> > > Cell "ZynqMP-linux-demo" can be loaded
> > > Started cell "ZynqMP-linux-demo"
> > > root@xilinx-zcu102-2017_4:/cells# jailhouse cell list 
> > > ID  NameState   Assigned CPUs 
> > >   Failed CPUs 
> > > 0   ZynqMP-ZCU102   running 0-1   
> > >   
> > > 1   ZynqMP-linux-demo   running 2-3  
> > >
> > > However, the UART does not show anything. I have tried with a 
> > > different Linux image and the same problem. I generate the images 
> > > with Petalinux. 
> > >
> > 
> >  Try debugging the non-root boot by using the Jailhouse console for the
> >  cell (con-type=JAILHOUSE, cell flag JAILHOUSE_CELL_DEBUG_CONSOLE, see
> >  Documentation/debug-output.md). Check if the UART is detected by the
> >  guest. Maybe the kernel is not configured as needed.
> > 
> >  Jan
> >  -- 
> >  Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >  Corporate Competence Center Embedded Linux
> > >>>
> > >>> I have applied the patches for JAILHOUSE_DBCON  and I added 
> > >>> JAILHOUSE_CELL_DEBUG_CONSOLE to zynqmp-zcu102-linux-demo.c. I load the 
> > >>> cell like this:
> > >>> jailhouse cell linux zynqmp-zcu102-linux-demo.cell Image -d 
> > >>> inmate-zynqmp-zcu102.dtb -i rootfs.cpio -c "con-type=jailhouse"
> > >>>
> > >>> However, the booting does not appear. To see the debug output I have to 
> > >>> do "cat /dev/jailhouse", no?
> > >>>
> > >>
> > >> Rather "jailhouse console". If that only lists output of the hypervisor
> > >> itself, the guest does not start up. You then have some other issue. Is
> > >> there anything you modified, compared to upstream Jailhouse
> > >> configurations? Try reducing that to zero first.
> > >>
> > >> I can look up the setup on our ZCU102 to give you exact references to a
> > >> known-to-work setup. Definitely working was vanilla Jailhouse v0.8 (I
> > >> tested that prior to the release). I've also attached a reference config
> > >> for the Linux inmate kernel.
> > >>
> > >> I hope we can eventually handle such setup questions via the
> > >> jailhouse-image project, but right now that's not yet there.
> > >>
> > >> Jan
> > >>
> > >> -- 
> > >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > >> Corporate Competence Center Embedded Linux
> > > 
> > > I did both images with Petalinux 2017.4 and its default bsp. The Kernel 
> > > version is 4.9. How do you build your images? Yocto with meta-xilinx 
> > > layer? 
> > 
> > No Yocto. Custom kernel config, mainline kernel, built via 

Re: IVSHMEM-NET probe initialization failed

[prajwal06 . desai]

On Friday, April 20, 2018 at 10:51:01 AM UTC-4, prajwal...@gmail.com wrote:
> Hi all,
> 
> I am trying to bring  virtual network interface in non-root cell and also i 
> am trying to understand how virtual network will initialize while loading 
> non-root cell, i am putting some print statements in ivshmem-net.c file i.e 
> present in kernel source[drivers/net/ivshmem-net.c]. 
> 
> In ivshm_net_state_change function we have couple of cases like 
> IVSHM_NET_STATE_RESET, IVSHM_NET_STATE_INIT, IVSHM_NET_STATE_READY etc.. i 
> added some of print statements in this cases, i am able to see logs from case 
> IVSHM_NET_STATE_RESET after that i am not able to see any logs from other 
> cases.
> 
> Assumption:
> From the above behavior i assume my ivshmem-net is not brought up properly, 
> because i am not able to see the logs from IVSHM_NET_STATE_INIT, 
> IVSHM_NET_STATE_READY cases. 
> 
> Can anyone please tell me my assumption is correct or not? 
> I am attaching my ivshmem-net.c file[added with logs], and also my non-root 
> cell logs[search RH in non-root cell logs, that line is from ivshmem-net.c]
> 
> I am adding below configuration to both root and non-root cell. the non-root 
> cell have JAILHOUSE_MEM_ROOTSHARED flag. shmem_region has changed based on 
> the index value in non-root cell.
> 
> {
> .type = JAILHOUSE_PCI_TYPE_IVSHMEM,
> .iommu = 1,
> .domain = 0x0,
> .bdf = 0x0e << 3,
> .bar_mask = {
> 0xff00, 0x, 0x,
> 0x, 0xffe0, 0x,
> },
> .num_msix_vectors = 1,
> .shmem_region = 75,
> .shmem_protocol = JAILHOUSE_SHMEM_PROTO_VETH,
> },
> 
> /* MemRegion: 3f20 : IVSHMEM-net*/
> {
> .phys_start = 0x3f20,
> .virt_start = 0x3f20,
> .size = 0x10,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
> },
> 
> After loading non-root cell i am able to see the virtual network interfaces 
> is coming up by issuing command like ifconfig -a, and i can pci device is 
> also added. I can see interrupt is registered with ivshmem-net.
> 
> But i am not able to do any operation using these virtual network interface[ 
> if i try to ping any other network or root-cell network, i am not able to 
> ping, i am not seeing any changes in the interrupt number].
> 
> I have another question regarding interrupts, how can i know interrupt is 
> working or not? whether i need to trigger the interrupt externally?-> if it 
> is yes means how can i trigger the interrupts   
> 
> Thanks
> Prajwal

Hi Henning,
I also observed state set to IVSHM_NET_STATE_RESET and its not changed to 
IVSHM_NET_STATE_INIT. so I don't think that driver is not initialized 
properly.Is there any dependency on non rootcell config to change the state?
If yes, which config parameter has dependency on this.

Thanks
Prajwal

-- 
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-NET probe initialization failed

[prajwal06 . desai]

 
> What you describe could mean that your configuration is somehow
> incorrect and the two shared memory regions are not correctly connected.
> 
> You will see the PCI devices and the drivers will bind to them. But you
> will not be able to get interrupts or packets across.
> 
> Make sure that the hypervisor says
> "Shared memory connection established: " with your two cell names once
> the second cell comes up. If you do not see that line, your
> configuration is somehow incorrect.
>

While loading non-root cell i am getting below line from the logs[shared memory 
connection established]

Shared memory connection established: "Linux 4.9.47 non root" <--> "RootCell"

>From the above line we can confirm connection has been established from 
>non-root-cell to root-cell.

 
> Make sure to actually "ifconfig ... up" both sides, just in case you
> forgot about something that trivial.
> 

After booting non-root cell i tried to assign static ip and brought up virtual 
network interface, but it got failed. I am following below steps to assign ip, 
can you please check this.

[root@localhost ~]# ifconfig -a
enp0s14: flags=4163  mtu 16384
ether 36:28:b8:54:46:c4  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

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1  (Local Loopback)
RX packets 192  bytes 15552 (15.1 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 192  bytes 15552 (15.1 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@localhost ~]# ifconfig enp0s14 192.168.1.59 netmask 255.255.255.0 up
[root@localhost ~]# dmesg
[  142.650058] IPv6: ADDRCONF(NETDEV_UP): enp0s14: link is not ready
[root@localhost ~]#


 



-- 
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.