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

2018-04-11 Thread GitHub 
  Branch: refs/heads/coverity_scan
  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 


Compare: 
https://github.com/siemens/jailhouse/compare/086b4fbf91db...d7472246dffc

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

[siemens/jailhouse] 5df923: configs: x86: Expand inmate reservation

2018-04-11 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/siemens/jailhouse
  Commit: 5df9232178d3d854c5802466fbc87f02ea14752d
  
https://github.com/siemens/jailhouse/commit/5df9232178d3d854c5802466fbc87f02ea14752d
  Author: Jan Kiszka 
  Date:   2018-02-18 (Sun, 18 Feb 2018)

  Changed paths:
M README.md
M configs/x86/f2a88xm-hd3.c
M configs/x86/imb-a180.c
M configs/x86/linux-x86-demo.c
M configs/x86/qemu-x86.c
M tools/jailhouse-config-create

  Log Message:
  ---
  configs: x86: Expand inmate reservation

Add further 16 MB for inmates, using it for linux-x86-demo. This helps
starting standard, larger kernels that can also be used for the root
cell.

While adjusting the two remaining AMD configs, also update their
hypervisor size which makes them compatible with linux-x86-demo again.

Signed-off-by: Jan Kiszka 


  Commit: e7660f9983d943c7da8a2b731adb7c0c32bb2498
  
https://github.com/siemens/jailhouse/commit/e7660f9983d943c7da8a2b731adb7c0c32bb2498
  Author: Jan Kiszka 
  Date:   2018-02-28 (Wed, 28 Feb 2018)

  Changed paths:
M hypervisor/arch/arm/include/asm/sysregs.h
M hypervisor/arch/arm/mmio.c
M hypervisor/arch/arm/traps.c

  Log Message:
  ---
  arm: Fix name of HSR ISS field

It's called ISS according to the ARM manual, not ICC.

No functional changes.

Signed-off-by: Jan Kiszka 


  Commit: 9675814c6fe3e6953976b5299090a6abef555741
  
https://github.com/siemens/jailhouse/commit/9675814c6fe3e6953976b5299090a6abef555741
  Author: Jan Kiszka 
  Date:   2018-02-28 (Wed, 28 Feb 2018)

  Changed paths:
M hypervisor/arch/arm/traps.c
M hypervisor/arch/arm64/traps.c
M include/arch/arm/asm/jailhouse_hypercall.h
M include/arch/arm64/asm/jailhouse_hypercall.h

  Log Message:
  ---
  arm/arm64: Reject hypercalls with wrong immediate code

Jailhouse only supports hypercalls with the immediate code 0x4a48. Avoid
interpreting calls with other codes as ours.

Signed-off-by: Jan Kiszka 


  Commit: 5f4cca36212076a1157e140f7e0b196bff3012f5
  
https://github.com/siemens/jailhouse/commit/5f4cca36212076a1157e140f7e0b196bff3012f5
  Author: Jan Kiszka 
  Date:   2018-02-28 (Wed, 28 Feb 2018)

  Changed paths:
M hypervisor/arch/arm/include/asm/sysregs.h
M hypervisor/arch/arm64/include/asm/sysregs.h

  Log Message:
  ---
  arm/arm64: Replace HSR/ESR_ISS_MASK with BIT_MASK

Makes the mask more readable. There is also no need for a separate
define because only HSR/ESR_ISS makes use of it.

Signed-off-by: Jan Kiszka 


  Commit: bd5ad1e0f3dd4e0968ddc44e11975768e4ae9406
  
https://github.com/siemens/jailhouse/commit/bd5ad1e0f3dd4e0968ddc44e11975768e4ae9406
  Author: Jan Kiszka 
  Date:   2018-03-01 (Thu, 01 Mar 2018)

  Changed paths:
M hypervisor/include/jailhouse/utils.h

  Log Message:
  ---
  core: Provide GET_FIELD helper macro

This allows to extract the value of a bitfield from a variable, properly
shifted to the right for direct use.

Signed-off-by: Jan Kiszka 


  Commit: cf4c4691fd48c8b98f19ea01fdaa03f39d5fd7d3
  
https://github.com/siemens/jailhouse/commit/cf4c4691fd48c8b98f19ea01fdaa03f39d5fd7d3
  Author: Claudio Scordino 
  Date:   2018-03-05 (Mon, 05 Mar 2018)

  Changed paths:
M FAQ.md
M README.md

  Log Message:
  ---
  Documentation: supported free OSs; memory reservation through DT

Signed-off-by: Claudio Scordino 
Signed-off-by: Jan Kiszka 


  Commit: a85b0ebd1766704fa8d21b21e925d24149607977
  
https://github.com/siemens/jailhouse/commit/a85b0ebd1766704fa8d21b21e925d24149607977
  Author: Jan Kiszka 
  Date:   2018-03-05 (Mon, 05 Mar 2018)

  Changed paths:
M FAQ.md
M README.md

  Log Message:
  ---
  README/FAQ: Use consistent blank-line separations

Signed-off-by: Jan Kiszka 


  Commit: 28cc7ce508123fd21e3a1da0da561f7bd35a6244
  
https://github.com/siemens/jailhouse/commit/28cc7ce508123fd21e3a1da0da561f7bd35a6244
  Author: Adeel Ahmad 
  Date:   2018-03-06 (Tue, 06 Mar 2018)

  Changed paths:
M README.md

  Log Message:
  ---
  Documentation: update required QEMU version to be >= 2.8

The "x86 Demonstration in QEMU/KVM" section currently
lists QEMU version to be 2.7 or newer, as the
x-buggy-eim property was introduced in version 2.8,
this version won't work.

Signed-off-by: Adeel Ahmad 
Signed-off-by: Jan Kiszka 


  Commit: 2dfb4f518291d81db71223ab277e66315657076f
  
https://github.com/siemens/jailhouse/commit/2dfb4f518291d81db71223ab277e66315657076f
  Author: Adeel Ahmad

[siemens/jailhouse] e8370e: x86: svm: Intercept all SVM instructions

2018-04-11 Thread GitHub 
  Branch: refs/heads/next
  Home:   https://github.com/siemens/jailhouse
  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 in a GP and a reboot

do not allow enable if firmware has disabled VT-X on Intel VMX

Signed-off-by: Francois-Frederic Ozog 
[Jan: adjust includes and style]
Signed-off-by: Jan Kiszka 


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

  Changed paths:
M tools/jailhouse-hardware-check

  Log Message:
  ---
  tools: proper reporting of mandatory and optional VMXON features

on a VMX capable processor, firmware has the capability to block use of
it.
WHen it is the case, bits of IA32_FEATURE_CONTROL are cleared.
At a minimum, a jailhouse system need to be able to use VMX outside SMX.

Signed-off-by: Francois-Frederic Ozog 
Signed-off-by: Jan Kiszka 


  Commit: 765365f4c4868e0e9ad30d7ca6e2e094b0c405ce
  
https://github.com/siemens/jailhouse/commit/765365f4c4868e0e9ad30d7ca6e2e094b0c405ce
  Author: Claudio Scordino 
  Date:   2018-04-12 (Thu, 12 Apr 2018)

  Changed paths:
A configs/arm64/jetson-tx2.c

  Log Message:
  ---
  Jetson TX2: root cell config

Root cell config for Jetson TX2 using Nvidia's kernel 4.4 (not Vanilla).

Tested on the "next" branch by restoring the ABI for kernels < 4.7 in
hypervisor/arch/arm64/entry.S:
   /* install bootstrap_vectors */
  ldr x0, =bootstrap_vectors
  virt2phys x0

Signed-off-by: Claudio Scordino 
Signed-off-by: Jan Kiszka 


  Commit: 48c4909226cb1177083e48a665c7896160ece0cf
  
https://github.com/siemens/jailhouse/commit/48c4909226cb1177083e48a665c7896160ece0cf
  Author: Claudio Scordino 
  Date:   2018-04-12 (Thu, 12 Apr 2018)

  Changed paths:
M inmates/lib/arm64/include/mach.h

  Log Message:
  ---
  Jetson TX2: add inmate support

Signed-off-by: Claudio Scordino 
Signed-off-by: Jan Kiszka 


  Commit: 108d84d82be82bfbc23af3545515440f934599e9
  
https://github.com/siemens/jailhouse/commit/108d84d82be82bfbc23af3545515440f934599e9
  Author: Claudio Scordino 
  Date:   2018-04-12 (Thu, 12 Apr 2018)

  Changed paths:
A configs/arm64/jetson-tx2-demo.c

  Log Message:
  ---
  Jetson TX2: add demo cell config

Signed-off-by: Claudio Scordino 
Signed-off-by: Jan Kiszka 


  Commit: aad818e95fd65be73d6dd8bdffc20c04c6606467
  
https://github.com/siemens/jailhouse/commit/aad818e95fd65be73d6dd8bdffc20c04c6606467
  Author: Claudio Scordino 
  Date:   2018-04-12 (Thu, 12 Apr 2018)

  Changed paths:
M

Re: [PATCH] inmates: assume VMCALL for hypercalls, detect AMD to change

2018-04-11 Thread Jan Kiszka 
On 2018-04-11 15:16, f...@ozog.com wrote:
> inmates cannot use X86_FEATURE_VMX from regular cpuid
> as vcpu maks the bit explicitely on non-root cells.
> 
> use cpuid leaf 0 to detect AuthenticAMD and change to VMMCALL
> 
> Signed-off-by: Francois-Frederic Ozog 
> ---
>  inmates/lib/x86/hypercall.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/inmates/lib/x86/hypercall.c b/inmates/lib/x86/hypercall.c
> index ac99f0c3..2d7a96e1 100644
> --- a/inmates/lib/x86/hypercall.c
> +++ b/inmates/lib/x86/hypercall.c
> @@ -40,19 +40,19 @@
> 
>  #define X86_FEATURE_VMX    (1 << 5)
> 
> -bool jailhouse_use_vmcall;
> +bool jailhouse_use_vmcall = true;
> 
>  void hypercall_init(void)
>  {
> -   u32 eax = 1, ecx = 0;
> +   u32 eax = 0, ebx = 0, ecx = 0, edx = 0;
> 
>     asm volatile(
>     "cpuid"
>     : "=c" (ecx)
> -   : "a" (eax), "c" (ecx)
> -   : "rbx", "rdx", "memory"
> +   : "a" (eax), "b" (ebx), "c" (ecx), "d" (edx)
> +   : "memory"
>     );
> 
> -   if (ecx & X86_FEATURE_VMX)
> -   jailhouse_use_vmcall = true;
> +   if (ebx == 0x68747541 && ecx == 0x444d4163 && edx == 0x69746E65)
> +   jailhouse_use_vmcall = false;
>  }
> -- 
> 2.11.0
> 

This patch looks functionally fine now, but your mailer replaces tabs
with spaces. Please fix and resend.

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 an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH v2 0/4] Support for Nvidia Jetson TX2

2018-04-11 Thread Jan Kiszka 
On 2018-04-11 10:26, Claudio Scordino wrote:
> Tested on the "next" branch against Nvidia's kernel 4.4 (not Vanilla) by
> restoring the ABI for kernels < 4.7 in hypervisor/arch/arm64/entry.S:
> 
> /* install bootstrap_vectors */
> ldr x0, =bootstrap_vectors
> virt2phys x0

OK, merged, although I was expecting this information rather in
something that is shipped with the sources. But let's sort that out once
you are done with testing the vanilla kernel.

Jan

> 
> Claudio Scordino (4):
>   Jetson TX2: root cell config
>   Jetson TX2: add inmate support
>   Jetson TX2: add demo cell config
>   Documentation: Add TX2 to the list of supported hardware
> 
>  Documentation/hypervisor-configuration.md |   6 +-
>  README.md |   2 +-
>  configs/arm64/jetson-tx2-demo.c   |  51 
>  configs/arm64/jetson-tx2.c| 492 
> ++
>  inmates/lib/arm64/include/mach.h  |   8 +
>  5 files changed, 557 insertions(+), 2 deletions(-)
>  create mode 100644 configs/arm64/jetson-tx2-demo.c
>  create mode 100644 configs/arm64/jetson-tx2.c
> 

-- 
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: [PATCH 1/2] driver: ensure jailhouse is not enabled when VT-X is disabled by firmware

2018-04-11 Thread Jan Kiszka 
On 2018-04-10 10:55, f...@ozog.com wrote:
> Whithout the check,
> jailhouse enable configs/x86/sysconfig.cell
> results in a GP and a reboot
> 
> do not allow enable if firmware has disabled VT-X on Intel VMX
> 
> Signed-off-by: Francois-Frederic Ozog 
> ---
>  driver/main.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/driver/main.c b/driver/main.c
> index ee585848..723a9576 100644
> --- a/driver/main.c
> +++ b/driver/main.c
> @@ -40,6 +40,10 @@
>  #ifdef CONFIG_ARM
>  #include 
>  #endif
> +#ifdef CONFIG_X86
> +#include 
> +#include 
> +#endif
> 
>  #include "cell.h"
>  #include "jailhouse.h"
> @@ -392,6 +396,18 @@ static int jailhouse_cmd_enable(struct
> jailhouse_system __user *arg)
>     goto error_put_module;
>     }
>  #endif
> +#ifdef CONFIG_X86
> +   if (boot_cpu_has(X86_FEATURE_VMX)) {
> +   u64 features;
> +
> +   rdmsrl(MSR_IA32_FEATURE_CONTROL, features);
> +   if ((features &
> FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX) == 0) {
> +   pr_err("jailhouse: vt-x disabled by
> Firmware/BIOS\n");
> +   err = -ENODEV;
> +   goto error_put_module;
> +   }
> +   }
> +#endif
> 
>     /* Load hypervisor image */
>     err = request_firmware(, fw_name, jailhouse_dev);
> -- 
> 2.11.0
> 

Thanks, applied to next with minor adjustments. Also patch 2 is in next now.

Note that your patches are mangled so that I had to manually apply them.
Please check your email client settings.

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 an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Share memory among cells on arm64

2018-04-11 Thread Giovani Gracioli 
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?

> Hi Jan,
> 
> Thanks for the reply. I am using the uio driver and when I load it, the pci 
> devices become enabled. I suppose this part is ok:
> 
> lspci -v after the driver is loaded:
> 
> 00:00.0 Unassigned class [ff00]: Red Hat, Inc Inter-VM shared memory
> Subsystem: Red Hat, Inc Inter-VM shared memory
> Flags: bus master, fast devsel, latency 0, IRQ 38
> Memory at fc10 (64-bit, non-prefetchable) [size=256]
> Kernel driver in use: uio_ivshmem
> 
> 00:01.0 Unassigned class [ff01]: Red Hat, Inc Inter-VM shared memory
> Subsystem: Red Hat, Inc Inter-VM shared memory
> Flags: bus master, fast devsel, latency 0, IRQ 39
> Memory at fc100100 (64-bit, non-prefetchable) [size=256]
> Kernel driver in use: uio_ivshmem
> 
> I got the code available here 
> (https://github.com/evidence/linux-jailhouse-tx1) that has an ivshmem demo on 
> arm. I basically copied and pasted the pci_read_config and pci_write_config 
> functions in the inmates/lib/arm-common/pci.c (had to change some makefiles 
> to compile the code because of the pci.c file).
> 
> However, I am getting an Unhandled data read at 0xfc10, which is the 
> address of the 00:00.0 device, during the execution of the function 
> pci_find_device().
> 
> If a decrease the while value test in the pci_find_device() function (bdf < 
> 0x1), it does not find any PCI device (obviously) and there is no error.
> 
> start_bdf is initially defined as 0xfc00, as configured in the root cell 
> (.pci_mmconfig_base = 0xfc00).
> 
> Any suggestion?
> 
> Giovani
> 
> > On 2018-04-10 16:39, Giovani Gracioli wrote:
> > > Updating:
> > > 
> > > I added 
> > > 
> > > .num_msix_vectors = 1,
> > > .iommu = 1, 
> > > 
> > > to the root cell .pci_devices config, wrote a simple linux program to 
> > > write to the shared memory (0x80050) and a simple inmate cell code to 
> > > read from the shared memory. It was able to read the values that were 
> > > written.
> > > 
> > > The next step is how to generate interrupts among the cells. I tried to 
> > > use the pci functions (the same used in the ivshmem-demo) on the arm64 
> > > but got an error. The lib/pci.c is not compiled by arm64.
> > > 
> > > How should I discover the pci device and send/receive interrupts on arm64?
> > > 
> > 
> > ivshmem demo inmate for ARM/ARM64 is still work in progress. Henning, is
> > there any intermediate step we can point to?
> > 
> > You could start your tests between two Linux cells, meanwhile, using the
> > uio driver.
> > 
> > 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 an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH] inmates: assume VMCALL for hypercalls, detect AMD to change

2018-04-11 Thread ff 

inmates cannot use X86_FEATURE_VMX from regular cpuid
as vcpu maks the bit explicitely on non-root cells.

use cpuid leaf 0 to detect AuthenticAMD and change to VMMCALL

Signed-off-by: Francois-Frederic Ozog 
---
 inmates/lib/x86/hypercall.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/inmates/lib/x86/hypercall.c b/inmates/lib/x86/hypercall.c
index ac99f0c3..2d7a96e1 100644
--- a/inmates/lib/x86/hypercall.c
+++ b/inmates/lib/x86/hypercall.c
@@ -40,19 +40,19 @@

 #define X86_FEATURE_VMX(1 << 5)

-bool jailhouse_use_vmcall;
+bool jailhouse_use_vmcall = true;

 void hypercall_init(void)
 {
-   u32 eax = 1, ecx = 0;
+   u32 eax = 0, ebx = 0, ecx = 0, edx = 0;

asm volatile(
"cpuid"
: "=c" (ecx)
-   : "a" (eax), "c" (ecx)
-   : "rbx", "rdx", "memory"
+   : "a" (eax), "b" (ebx), "c" (ecx), "d" (edx)
+   : "memory"
);

-   if (ecx & X86_FEATURE_VMX)
-   jailhouse_use_vmcall = true;
+   if (ebx == 0x68747541 && ecx == 0x444d4163 && edx == 0x69746E65)
+   jailhouse_use_vmcall = false;
 }
--
2.11.0

--
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: [PATCH] core: ensure proper detection on VMX vs SVM from inmates

2018-04-11 Thread ff 

On 11.04.2018 14:18, Jan Kiszka wrote:

On 2018-04-11 11:35, f...@ozog.com wrote:

inmates cannot use X86_FEATURE_VMX from regular cpuid
as vcpu maks the bit explicitely on non-root cells.

create the equivalent bit (same register, same position)
in the JAILHOUSE_CPUID_FEATURES cpuid leaf

Signed-off-by: Francois-Frederic Ozog 
---
 hypervisor/arch/x86/vcpu.c | 13 +
 include/arch/x86/asm/jailhouse_hypercall.h |  5 +
 inmates/lib/x86/hypercall.c    |  2 +-
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/hypervisor/arch/x86/vcpu.c b/hypervisor/arch/x86/vcpu.c
index 21da0592..2bfbff94 100644
--- a/hypervisor/arch/x86/vcpu.c
+++ b/hypervisor/arch/x86/vcpu.c
@@ -331,6 +331,17 @@ bool vcpu_handle_msr_write(void)
    return true;
 }

+static bool is_vmx(void)
+{
+   u32 eax, ebx, ecx, edx;
+
+   eax=1;
+   ebx = ecx = edx =0;
+   cpuid(, , , );
+
+   return ecx & X86_FEATURE_VMX;
+}
+
 void vcpu_handle_cpuid(void)
 {
    static const char signature[12] = "Jailhouse";
@@ -350,6 +361,8 @@ void vcpu_handle_cpuid(void)
    guest_regs->rax = 0;
    guest_regs->rbx = 0;
    guest_regs->rcx = 0;
+   if (is_vmx())
+   guest_regs->rcx |= X86_FEATURE_VMX;
    guest_regs->rdx = 0;
    break;
    default:
diff --git a/include/arch/x86/asm/jailhouse_hypercall.h
b/include/arch/x86/asm/jailhouse_hypercall.h
index 3a52599f..052b9255 100644
--- a/include/arch/x86/asm/jailhouse_hypercall.h
+++ b/include/arch/x86/asm/jailhouse_hypercall.h
@@ -68,6 +68,11 @@
 #define JAILHOUSE_CPUID_SIGNATURE  0x4000
 #define JAILHOUSE_CPUID_FEATURES   0x4001

+/*
+ * ECX
+ * bit 5: 1=VMX
+*/
+#define JAILHOUSE_CPUID_FEATURE_VMX    (1ULL << 0)
 /**
  * @defgroup Hypercalls Hypercall Subsystem
  *
diff --git a/inmates/lib/x86/hypercall.c b/inmates/lib/x86/hypercall.c
index ac99f0c3..4a356390 100644
--- a/inmates/lib/x86/hypercall.c
+++ b/inmates/lib/x86/hypercall.c
@@ -44,7 +44,7 @@ bool jailhouse_use_vmcall;

 void hypercall_init(void)
 {
-   u32 eax = 1, ecx = 0;
+   u32 eax = JAILHOUSE_CPUID_FEATURES, ecx = 0;

    asm volatile(
    "cpuid"
--
2.11.0



That's neither what I meant nor how Linux (as guest) works. Just probe
for an AMD CPU and set jailhouse_use_vmcall to true if it's not found.

Jan

I am proposing another patch then rather than using this mail thread.

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

2018-04-11 Thread iallende 
El martes, 10 de abril de 2018, 16:44:45 (UTC+2), J. Kiszka  escribió:
> On 2018-04-10 15:12, Ralf Ramsauer wrote:
> > Hi,
> > 
> > On 04/10/2018 02:10 PM, iallende wrote:
> >> El martes, 10 de abril de 2018, 10:47:57 (UTC+2), Ralf Ramsauer  escribió:
> >>> Hi,
> >>>
> >>> On 04/10/2018 10:26 AM, iallende wrote:
>  El jueves, 22 de marzo de 2018, 16:33:02 (UTC+1), Ralf Ramsauer  
>  escribió:
> > On 03/22/2018 04:23 PM, iallende wrote:
> >> El miércoles, 21 de marzo de 2018, 15:25:02 (UTC+1), Ralf Ramsauer  
> >> escribió:
> >>> Hi,
> >>>
> >>> On 03/21/2018 02:54 PM, iallende wrote:
>  Hi everyone,
> 
>  I am trying to run Jailhouse in the ZynqMP, with Linux PREEMPT RT in 
>  another cell. However, I have some problems when I add the second 
>  Linux.
> 
>  root@xilinx-zcu102-2017_4:/# modprobe jailhouse
>  [   52.445169] jailhouse: loading out-of-tree module taints kernel.
>  root@xilinx-zcu102-2017_4:/# ls /dev/jailhouse ^C
>  root@xilinx-zcu102-2017_4:/# jailhouse enable zynqmp-zcu102.cell 
> 
>  Initializing Jailhouse hypervisor v0.7 (0-g5c13b64) on CPU 2
> >>> Please checkout next and try again. This might already fix your issue.
> >> With v0.8 i get this WARNING and I can load the module:
> >> WARNING: "__hyp_stub_vectors" [/jailhouse/driver/jailhouse.ko] 
> >> undefined!
> > Please switch to next, and not to v0.8. Compile your kernel with
> > CONFIG_KALLSYMS_ALL=y, or use this [1] patch.
> >
> >   Ralf
> >
> > [1]
> > http://git.kiszka.org/?p=linux.git;a=commit;h=2a681cb2213e3ea0f142fae7345fb80208a88a53
>  Code location: 0xc0200050
>  Page pool usage after early setup: mem 33/996, 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/996, remap 69/131072
>  Activating hypervisor
>  [   63.697232] jailhouse: CONFIG_OF_OVERLAY disabled
>  [   63.704029] jailhouse: failed to add virtual host controller
>  [   63.711610] The Jailhouse is opening.
> 
>  root@xilinx-zcu102-2017_4:/# jailhouse cell linux 
>  zynqmp-zcu102-linux-demo.cell Image -d system.dtb -i rootfs.cpio 
> 
>  FATAL: unhandled trap (exception class 0x17)
> >>> Exception class 0x17 is a SMC64 call.
> >>>
>  Cell state before exception:
>   pc: ff800808e390   lr: ff8008467504 spsr: 2145 EL1
>   sp: ffc87b927ab0  esr: 17 1 000
>   x0: c214   x1: fd1a0060   x2: 
> >>> Furthermore, it's a SIP_64.
> >>>
> >>> Commit 2482c47bc2d05f ("arm64: ignore SIPs used for low-power modes") 
> >>> on
> >>> next will probably fix your issue.
> >>>
> >>>   Ralf
>   x3:    x4:    x5: 
>   x6:    x7:    x8: ff8008d27ee0
>   x9: ffc87aaa4b5c  x10: ffc87b927b4c  x11: ff8008c8ccb2
>  x12:   x13: 0f93  x14: 0001
>  x15:   x16: ff8008193240  x17: 004128f0
>  x18: 00040900  x19: ffc87b927b28  x20: 0001
>  x21: 4784b740  x22: 4784b740  x23: fffa
>  x24: 000f4240  x25: 000f4240  x26: 000f4240
>  x27:   x28:   x29: ffc87b927ac0
> 
>  Parking CPU 2 (Cell: "ZynqMP-ZCU102")
> 
> 
>  Does anyone know why I have this problem? Am I missing any step?
> 
> >>
> 
>  Sorry Ralf, I did an error with the dtb. It works with the 
>  inmate-zynqmp-zcu102.dtb. However, I do not achieve to see the non-root 
>  linux console. I have tried with ttyS0 and ttyS1, but nothing appears. 
>  How can I access to the second cell?
> >>>
> >>> Sorry for the late response! Ok -- so the other issues are solved and
> >>> the rest works now?
> >>>
> >>> Try to enable the JAILHOUSE_DBCON [1] in your kernel config and allow
> >>> your cell to use it by adding the .flag JAILHOUSE_CELL_DEBUG_CONSOLE to
> >>> your inmate's cell config (see Documentation/debug-output.md), and use
> >>> jailhouse0 as output path. Then you should at least see the kernel 
> >>> booting.
> >>>
> >>> Maybe this already gives you a clue what's going on. As far as I can
> >>> see, the upstream inmate configs look fine.
> >>>
> >>> Are other inmates that use the same inmate config able to use the UART?
> >>>
> >>>   Ralf
> >>>
> >>> [1]
> >>>

Re: [PATCH] core: ensure proper detection on VMX vs SVM from inmates

2018-04-11 Thread Jan Kiszka 
On 2018-04-11 11:35, f...@ozog.com wrote:
> inmates cannot use X86_FEATURE_VMX from regular cpuid
> as vcpu maks the bit explicitely on non-root cells.
> 
> create the equivalent bit (same register, same position)
> in the JAILHOUSE_CPUID_FEATURES cpuid leaf
> 
> Signed-off-by: Francois-Frederic Ozog 
> ---
>  hypervisor/arch/x86/vcpu.c | 13 +
>  include/arch/x86/asm/jailhouse_hypercall.h |  5 +
>  inmates/lib/x86/hypercall.c    |  2 +-
>  3 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/hypervisor/arch/x86/vcpu.c b/hypervisor/arch/x86/vcpu.c
> index 21da0592..2bfbff94 100644
> --- a/hypervisor/arch/x86/vcpu.c
> +++ b/hypervisor/arch/x86/vcpu.c
> @@ -331,6 +331,17 @@ bool vcpu_handle_msr_write(void)
>     return true;
>  }
> 
> +static bool is_vmx(void)
> +{
> +   u32 eax, ebx, ecx, edx;
> +
> +   eax=1;
> +   ebx = ecx = edx =0;
> +   cpuid(, , , );
> +
> +   return ecx & X86_FEATURE_VMX;
> +}
> +
>  void vcpu_handle_cpuid(void)
>  {
>     static const char signature[12] = "Jailhouse";
> @@ -350,6 +361,8 @@ void vcpu_handle_cpuid(void)
>     guest_regs->rax = 0;
>     guest_regs->rbx = 0;
>     guest_regs->rcx = 0;
> +   if (is_vmx())
> +   guest_regs->rcx |= X86_FEATURE_VMX;
>     guest_regs->rdx = 0;
>     break;
>     default:
> diff --git a/include/arch/x86/asm/jailhouse_hypercall.h
> b/include/arch/x86/asm/jailhouse_hypercall.h
> index 3a52599f..052b9255 100644
> --- a/include/arch/x86/asm/jailhouse_hypercall.h
> +++ b/include/arch/x86/asm/jailhouse_hypercall.h
> @@ -68,6 +68,11 @@
>  #define JAILHOUSE_CPUID_SIGNATURE  0x4000
>  #define JAILHOUSE_CPUID_FEATURES   0x4001
> 
> +/*
> + * ECX
> + * bit 5: 1=VMX
> +*/
> +#define JAILHOUSE_CPUID_FEATURE_VMX    (1ULL << 0)
>  /**
>   * @defgroup Hypercalls Hypercall Subsystem
>   *
> diff --git a/inmates/lib/x86/hypercall.c b/inmates/lib/x86/hypercall.c
> index ac99f0c3..4a356390 100644
> --- a/inmates/lib/x86/hypercall.c
> +++ b/inmates/lib/x86/hypercall.c
> @@ -44,7 +44,7 @@ bool jailhouse_use_vmcall;
> 
>  void hypercall_init(void)
>  {
> -   u32 eax = 1, ecx = 0;
> +   u32 eax = JAILHOUSE_CPUID_FEATURES, ecx = 0;
> 
>     asm volatile(
>     "cpuid"
> -- 
> 2.11.0
> 

That's neither what I meant nor how Linux (as guest) works. Just probe
for an AMD CPU and set jailhouse_use_vmcall to true if it's not found.

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 an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC]: fixing cmdline and hypercall instruction detection

2018-04-11 Thread Jan Kiszka 
On 2018-04-11 11:24, Ralf Ramsauer wrote:
> Hi,
> 
> On 04/11/2018 11:17 AM, f...@ozog.com wrote:
>> On 11.04.2018 10:27, Jan Kiszka wrote:
>>> On 2018-04-11 09:55, f...@ozog.com wrote:
 In trying to get the tiny-demo send logs to jailhouse debug console I
 found that:
 - inmate lib handling of cmdline is broken
 - inmate lib detection whether to use VMCALL (Intel) or VMMCALL (AMD)
 instructions to do hypercalls is broken

 I found fixes but I'd like to discuss how to properly address the issues

 I -  cmdline

 I.1 - problem

 according to inmates/lib/x86/inmate.lds
 cmdline is located at offset 0x100 in the running inmate
 it contains one byte (a zero).
 inmate code starts at 0x101
>>>
>>> Well, that's the location of the text section if there is nothing in the
>>> inmate that otherwise uses the cmdline section. But if your inmate is
>>> using the command line (lib/cmdline.c), it will usually reserve another
>>> 256 bytes (CMDLINE_BUFFER_SIZE). If something else provides a
>>> CMDLINE_BUFFER, that will will and may change that value.
>>>

 according to Documentation/debug-output.md
 command line parameters are specified using -s 

 lastly, cell_shutdown_load() in tools/jailhouse.c considers "-s
 " as a second image to be loaded

 so the command

 jailhouse cell load --name tiny-demo inmates/demos/x86/tiny-demo.bin -s
 "con-type=JAILHOUSE"
>>>
>>> ...is wrong. It's missing the "-a 0x100" on x86 (would be 0x1000 on ARM
>>> architectures). The documentation above is listing this in the examples
>>> section.
>>>
>>> Please suggest better wording of that document that could help to avoid
>>> such misunderstanding.
>>>

 has the following effect:

 load_image() @ driver/cell.c uses the first available memory_region and
 copies inmates/demos/x86/tiny-demo.bin
 to that location
 then load_image() actually uses the same memory_region (same physical
 start but ioremapped at a different location)
 and overwrites the first bytes of inmates/demos/x86/tiny-demo.bin.

 Unexpectedly, the string "con-type=JAILHOUSE" happen to correspond to
 executable code bytes and it does "something" on my system.

 I.2 - possible solution

 the simplest way to solve this is:
 - reserve say the rest of the first page to boot code and command line:
 a inmate.lds patch can do the job
 - change jailhouse.c to load the fake image at offset 0x100 (updating
 target_address) so that driver.c does not override the .boot section

 If this is acceptable for now, I can publish patches.
>>>
>>> This is a documentation issue, at most. See above.
>>
>> I now understand.
>>
>> My reading of
>>    cell load { ID | [--name] NAME } { IMAGE | { -s | --string } "STRING" }
>>  [-a | --address ADDRESS] ...
>>
>> was either wrong or have to be improved
>>
>> adding {} seems clearer to me:
>>    cell load { ID | [--name] NAME } { { IMAGE | { -s | --string }
>> "STRING" }
>>  [-a | --address ADDRESS] } ...
>>
>> The following example is misleading:
>>
>>     jailhouse cell load foocell inmate.bin -s "con-type=JAILHOUSE" -a 0x100
>>
>> it looks like -s and -a are parameters to inmate.bin
>>
>> The following better shows that we are loading two images,
>> the second one patching the first one at offset 0x100
>>
>>     jailhouse cell load foocell
>>     inmate.bin -a 0 \
>>     -s "con-type=JAILHOUSE" -a 0x100
>>
>> which can be abbreviated to :
>>
>>     jailhouse cell load foocell
>>     inmate.bin \
>>     -s "con-type=JAILHOUSE" -a 0x100
>>
>> The following sample illustrate the overall concepts of multiple images
>> loading
>>
>>     jailhouse cell load foocell \
>>     inmate.bin \
>>     -s "con-type=JAILHOUSE" -a 0x100 \
>>     sharedobject.so -a 0x100 \
>>     ramfs.bin -a 0x200
>>
>> If this is correct, I'll propose a set of Documentation patches
> This is correct. You could also explicitly mention that the address is
> defaulted to 0x0.
> 
> And that images or strings are loaded in the same order as specified, if
> regions overlap, the latter will overwrite the content.

Maybe time for jailhouse.8...? :)

Jan

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

RFC: text for cell loading documentation

2018-04-11 Thread ff 

I am proposing to add a Documentation/cell-loading.md file.
Rather than proposing the .md directly, I prefer to propose raw text 
discussion,
then work on the cosmetics and links from other parts of the 
Documentation.


-FF

Jailhouse loading of images is pretty flexible but can be disconcerting.

The syntax is:

jailhouse cell load \
{ ID | [--name] NAME } \
{ { IMAGE | { -s | --string } "STRING" } [-a | --address ADDRESS] } ...

Valid forms are:

# loads inamte.bin (offset 0 assumed)
jailhouse cell load foocell inmate.bin

# same as above with explicit location
jailhouse cell load foocell inmate.bin -a 0

# load three binary objects (in order)
jailhouse cell load foocell \
inmate.bin \
sharedobject.so -a 0x100 \
ramfs.bin -a 0x200

The first example assumes "-a 0".

The last example, loads in the order specified, three binary objects,
the first one at offset 0, the second one at 0x100.
Should inmate.bin be larger than 0x100, the upper part will be 
overridden

by sharedobject.so.

Whatever load order, execution starts in the cell at offset 0.


This multi-image loading capability can be used to patch images and
pass parameters to the image. The following explains how parameters are 
passed

with the inmate library.

The inmate library assumes a command line string to be located at a 
fixed

location that is processor specific:
- On x86 this is offset 0x100 (see inmates/lib/x86/inmate.lds)
- On arm64, this is offset 0x1000 (see inmates/lib/arm64/inmate.lds.S)

The command line string capacity is fixed (256 bytes by defaylt) by 
CMDLINE_BUFFER_SIZE

in inmates/lib/cmdline.c.

Here is an example to pass  parameters stored in the file
commandline.txt to the last example on an x86 system:

OFFSET=0x100
jailhouse cell load foocell \
inmate.bin \
commanline.txt -a $OFFSET \
sharedobject.so -a 0x100 \
ramfs.bin -a 0x200

This command patches inmate.bin at offset 0x100 that happens to be char* 
cmdline for

inmates that uses Jailhouse inmates library.

Note: on an arm64 we would set OFFSET=0x1000

To be more practical and avoid using a text file, there is an 
image-as-string

option:

OFFSET=0x100
jailhouse cell load foocell \
inmate.bin \
-s "" -a $OFFSET \
sharedobject.so -a 0x100 \
ramfs.bin -a 0x200

The string in the -s need to be less than 255 characters long 
(CMDLINE_BUFFER_SIZE - terminatind \0)

otherwise it will silently overwrite existing code.

--
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] core: ensure proper detection on VMX vs SVM from inmates

2018-04-11 Thread ff 

inmates cannot use X86_FEATURE_VMX from regular cpuid
as vcpu maks the bit explicitely on non-root cells.

create the equivalent bit (same register, same position)
in the JAILHOUSE_CPUID_FEATURES cpuid leaf

Signed-off-by: Francois-Frederic Ozog 
---
 hypervisor/arch/x86/vcpu.c | 13 +
 include/arch/x86/asm/jailhouse_hypercall.h |  5 +
 inmates/lib/x86/hypercall.c|  2 +-
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/hypervisor/arch/x86/vcpu.c b/hypervisor/arch/x86/vcpu.c
index 21da0592..2bfbff94 100644
--- a/hypervisor/arch/x86/vcpu.c
+++ b/hypervisor/arch/x86/vcpu.c
@@ -331,6 +331,17 @@ bool vcpu_handle_msr_write(void)
return true;
 }

+static bool is_vmx(void)
+{
+   u32 eax, ebx, ecx, edx;
+
+   eax=1;
+   ebx = ecx = edx =0;
+   cpuid(, , , );
+
+   return ecx & X86_FEATURE_VMX;
+}
+
 void vcpu_handle_cpuid(void)
 {
static const char signature[12] = "Jailhouse";
@@ -350,6 +361,8 @@ void vcpu_handle_cpuid(void)
guest_regs->rax = 0;
guest_regs->rbx = 0;
guest_regs->rcx = 0;
+   if (is_vmx())
+   guest_regs->rcx |= X86_FEATURE_VMX;
guest_regs->rdx = 0;
break;
default:
diff --git a/include/arch/x86/asm/jailhouse_hypercall.h 
b/include/arch/x86/asm/jailhouse_hypercall.h

index 3a52599f..052b9255 100644
--- a/include/arch/x86/asm/jailhouse_hypercall.h
+++ b/include/arch/x86/asm/jailhouse_hypercall.h
@@ -68,6 +68,11 @@
 #define JAILHOUSE_CPUID_SIGNATURE  0x4000
 #define JAILHOUSE_CPUID_FEATURES   0x4001

+/*
+ * ECX
+ * bit 5: 1=VMX
+*/
+#define JAILHOUSE_CPUID_FEATURE_VMX(1ULL << 0)
 /**
  * @defgroup Hypercalls Hypercall Subsystem
  *
diff --git a/inmates/lib/x86/hypercall.c b/inmates/lib/x86/hypercall.c
index ac99f0c3..4a356390 100644
--- a/inmates/lib/x86/hypercall.c
+++ b/inmates/lib/x86/hypercall.c
@@ -44,7 +44,7 @@ bool jailhouse_use_vmcall;

 void hypercall_init(void)
 {
-   u32 eax = 1, ecx = 0;
+   u32 eax = JAILHOUSE_CPUID_FEATURES, ecx = 0;

asm volatile(
"cpuid"
--
2.11.0

--
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: [RFC]: fixing cmdline and hypercall instruction detection

2018-04-11 Thread Ralf Ramsauer 
Hi,

On 04/11/2018 11:17 AM, f...@ozog.com wrote:
> On 11.04.2018 10:27, Jan Kiszka wrote:
>> On 2018-04-11 09:55, f...@ozog.com wrote:
>>> In trying to get the tiny-demo send logs to jailhouse debug console I
>>> found that:
>>> - inmate lib handling of cmdline is broken
>>> - inmate lib detection whether to use VMCALL (Intel) or VMMCALL (AMD)
>>> instructions to do hypercalls is broken
>>>
>>> I found fixes but I'd like to discuss how to properly address the issues
>>>
>>> I -  cmdline
>>>
>>> I.1 - problem
>>>
>>> according to inmates/lib/x86/inmate.lds
>>> cmdline is located at offset 0x100 in the running inmate
>>> it contains one byte (a zero).
>>> inmate code starts at 0x101
>>
>> Well, that's the location of the text section if there is nothing in the
>> inmate that otherwise uses the cmdline section. But if your inmate is
>> using the command line (lib/cmdline.c), it will usually reserve another
>> 256 bytes (CMDLINE_BUFFER_SIZE). If something else provides a
>> CMDLINE_BUFFER, that will will and may change that value.
>>
>>>
>>> according to Documentation/debug-output.md
>>> command line parameters are specified using -s 
>>>
>>> lastly, cell_shutdown_load() in tools/jailhouse.c considers "-s
>>> " as a second image to be loaded
>>>
>>> so the command
>>>
>>> jailhouse cell load --name tiny-demo inmates/demos/x86/tiny-demo.bin -s
>>> "con-type=JAILHOUSE"
>>
>> ...is wrong. It's missing the "-a 0x100" on x86 (would be 0x1000 on ARM
>> architectures). The documentation above is listing this in the examples
>> section.
>>
>> Please suggest better wording of that document that could help to avoid
>> such misunderstanding.
>>
>>>
>>> has the following effect:
>>>
>>> load_image() @ driver/cell.c uses the first available memory_region and
>>> copies inmates/demos/x86/tiny-demo.bin
>>> to that location
>>> then load_image() actually uses the same memory_region (same physical
>>> start but ioremapped at a different location)
>>> and overwrites the first bytes of inmates/demos/x86/tiny-demo.bin.
>>>
>>> Unexpectedly, the string "con-type=JAILHOUSE" happen to correspond to
>>> executable code bytes and it does "something" on my system.
>>>
>>> I.2 - possible solution
>>>
>>> the simplest way to solve this is:
>>> - reserve say the rest of the first page to boot code and command line:
>>> a inmate.lds patch can do the job
>>> - change jailhouse.c to load the fake image at offset 0x100 (updating
>>> target_address) so that driver.c does not override the .boot section
>>>
>>> If this is acceptable for now, I can publish patches.
>>
>> This is a documentation issue, at most. See above.
> 
> I now understand.
> 
> My reading of
>    cell load { ID | [--name] NAME } { IMAGE | { -s | --string } "STRING" }
>  [-a | --address ADDRESS] ...
> 
> was either wrong or have to be improved
> 
> adding {} seems clearer to me:
>    cell load { ID | [--name] NAME } { { IMAGE | { -s | --string }
> "STRING" }
>  [-a | --address ADDRESS] } ...
> 
> The following example is misleading:
> 
>     jailhouse cell load foocell inmate.bin -s "con-type=JAILHOUSE" -a 0x100
> 
> it looks like -s and -a are parameters to inmate.bin
> 
> The following better shows that we are loading two images,
> the second one patching the first one at offset 0x100
> 
>     jailhouse cell load foocell
>     inmate.bin -a 0 \
>     -s "con-type=JAILHOUSE" -a 0x100
> 
> which can be abbreviated to :
> 
>     jailhouse cell load foocell
>     inmate.bin \
>     -s "con-type=JAILHOUSE" -a 0x100
> 
> The following sample illustrate the overall concepts of multiple images
> loading
> 
>     jailhouse cell load foocell \
>     inmate.bin \
>     -s "con-type=JAILHOUSE" -a 0x100 \
>     sharedobject.so -a 0x100 \
>     ramfs.bin -a 0x200
> 
> If this is correct, I'll propose a set of Documentation patches
This is correct. You could also explicitly mention that the address is
defaulted to 0x0.

And that images or strings are loaded in the same order as specified, if
regions overlap, the latter will overwrite the content.

  Ralf
> 
>>
>>>
>>> II - VMCALL
>>>
>>> II.1 - problem
>>> hypercall_init() @ checks for X86_FEATURE_VMX to use either VMCALL or
>>> VMMCALL.
>>> but vcpu_handle_cpuid() @ hypervisor/arch/x86/vcpu.c always clears this
>>> bit for non root cell.
>>> Thus, hypercalls in non AMD system do not work at all in non-root cells
>>> based on inmates demo code!
>>
>> Yeah, that's a regression of my commit 39dfc93aa472...
>>
>>>
>>> II.2 - possible solution
>>>
>>> Linux as a guest uses a "synthetic" bit, X86_FEATURE_VMMCALL,
>>> see
>>> https://elixir.bootlin.com/linux/v4.16.1/source/arch/x86/include/asm/cpufeatures.h#L225
>>>
>>>
>>> to detect proper alternative
>>> #define KVM_HYPERCALL \
>>>     ALTERNATIVE(".byte 0x0f,0x01,0xc1", ".byte 0x0f,0x01,0xd9",
>>> X86_FEATURE_VMMCALL)
>>>
>>> I would suggest the same, adding a bit in cpuid leaf
>>> (JAILHOUSE_CPUID_FEATURES).
>>>
>>
>> That

Re: [RFC]: fixing cmdline and hypercall instruction detection

2018-04-11 Thread ff 

On 11.04.2018 10:27, Jan Kiszka wrote:

On 2018-04-11 09:55, f...@ozog.com wrote:

In trying to get the tiny-demo send logs to jailhouse debug console I
found that:
- inmate lib handling of cmdline is broken
- inmate lib detection whether to use VMCALL (Intel) or VMMCALL (AMD)
instructions to do hypercalls is broken

I found fixes but I'd like to discuss how to properly address the 
issues


I -  cmdline

I.1 - problem

according to inmates/lib/x86/inmate.lds
cmdline is located at offset 0x100 in the running inmate
it contains one byte (a zero).
inmate code starts at 0x101


Well, that's the location of the text section if there is nothing in 
the

inmate that otherwise uses the cmdline section. But if your inmate is
using the command line (lib/cmdline.c), it will usually reserve another
256 bytes (CMDLINE_BUFFER_SIZE). If something else provides a
CMDLINE_BUFFER, that will will and may change that value.



according to Documentation/debug-output.md
command line parameters are specified using -s 

lastly, cell_shutdown_load() in tools/jailhouse.c considers "-s
" as a second image to be loaded

so the command

jailhouse cell load --name tiny-demo inmates/demos/x86/tiny-demo.bin 
-s

"con-type=JAILHOUSE"


...is wrong. It's missing the "-a 0x100" on x86 (would be 0x1000 on ARM
architectures). The documentation above is listing this in the examples
section.

Please suggest better wording of that document that could help to avoid
such misunderstanding.



has the following effect:

load_image() @ driver/cell.c uses the first available memory_region 
and

copies inmates/demos/x86/tiny-demo.bin
to that location
then load_image() actually uses the same memory_region (same physical
start but ioremapped at a different location)
and overwrites the first bytes of inmates/demos/x86/tiny-demo.bin.

Unexpectedly, the string "con-type=JAILHOUSE" happen to correspond to
executable code bytes and it does "something" on my system.

I.2 - possible solution

the simplest way to solve this is:
- reserve say the rest of the first page to boot code and command 
line:

a inmate.lds patch can do the job
- change jailhouse.c to load the fake image at offset 0x100 (updating
target_address) so that driver.c does not override the .boot section

If this is acceptable for now, I can publish patches.


This is a documentation issue, at most. See above.


I now understand.

My reading of
   cell load { ID | [--name] NAME } { IMAGE | { -s | --string } "STRING" 
}

 [-a | --address ADDRESS] ...

was either wrong or have to be improved

adding {} seems clearer to me:
   cell load { ID | [--name] NAME } { { IMAGE | { -s | --string } 
"STRING" }

 [-a | --address ADDRESS] } ...

The following example is misleading:

jailhouse cell load foocell inmate.bin -s "con-type=JAILHOUSE" -a 
0x100


it looks like -s and -a are parameters to inmate.bin

The following better shows that we are loading two images,
the second one patching the first one at offset 0x100

jailhouse cell load foocell
inmate.bin -a 0 \
-s "con-type=JAILHOUSE" -a 0x100

which can be abbreviated to :

jailhouse cell load foocell
inmate.bin \
-s "con-type=JAILHOUSE" -a 0x100

The following sample illustrate the overall concepts of multiple images 
loading


jailhouse cell load foocell \
inmate.bin \
-s "con-type=JAILHOUSE" -a 0x100 \
sharedobject.so -a 0x100 \
ramfs.bin -a 0x200

If this is correct, I'll propose a set of Documentation patches





II - VMCALL

II.1 - problem
hypercall_init() @ checks for X86_FEATURE_VMX to use either VMCALL or
VMMCALL.
but vcpu_handle_cpuid() @ hypervisor/arch/x86/vcpu.c always clears 
this

bit for non root cell.
Thus, hypercalls in non AMD system do not work at all in non-root 
cells

based on inmates demo code!


Yeah, that's a regression of my commit 39dfc93aa472...



II.2 - possible solution

Linux as a guest uses a "synthetic" bit, X86_FEATURE_VMMCALL,
see
https://elixir.bootlin.com/linux/v4.16.1/source/arch/x86/include/asm/cpufeatures.h#L225

to detect proper alternative
#define KVM_HYPERCALL \
    ALTERNATIVE(".byte 0x0f,0x01,0xc1", ".byte 0x0f,0x01,0xd9",
X86_FEATURE_VMMCALL)

I would suggest the same, adding a bit in cpuid leaf
(JAILHOUSE_CPUID_FEATURES).



That X86_FEATURE_VMMCALL is set by Linux itself. We should port that
logic over: wwitch to VMMCALL if and only if an AMD CPU is detected
(linux/arch/x86/kernel/cpu/amd.c), otherwise stick with Intel's VMCALL.
Patch welcome!

Jan


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

Re: [RFC]: fixing cmdline and hypercall instruction detection

2018-04-11 Thread Jan Kiszka 
On 2018-04-11 09:55, f...@ozog.com wrote:
> In trying to get the tiny-demo send logs to jailhouse debug console I
> found that:
> - inmate lib handling of cmdline is broken
> - inmate lib detection whether to use VMCALL (Intel) or VMMCALL (AMD)
> instructions to do hypercalls is broken
> 
> I found fixes but I'd like to discuss how to properly address the issues
> 
> I -  cmdline
> 
> I.1 - problem
> 
> according to inmates/lib/x86/inmate.lds
> cmdline is located at offset 0x100 in the running inmate
> it contains one byte (a zero).
> inmate code starts at 0x101

Well, that's the location of the text section if there is nothing in the
inmate that otherwise uses the cmdline section. But if your inmate is
using the command line (lib/cmdline.c), it will usually reserve another
256 bytes (CMDLINE_BUFFER_SIZE). If something else provides a
CMDLINE_BUFFER, that will will and may change that value.

> 
> according to Documentation/debug-output.md
> command line parameters are specified using -s 
> 
> lastly, cell_shutdown_load() in tools/jailhouse.c considers "-s
> " as a second image to be loaded
> 
> so the command
> 
> jailhouse cell load --name tiny-demo inmates/demos/x86/tiny-demo.bin -s
> "con-type=JAILHOUSE"

...is wrong. It's missing the "-a 0x100" on x86 (would be 0x1000 on ARM
architectures). The documentation above is listing this in the examples
section.

Please suggest better wording of that document that could help to avoid
such misunderstanding.

> 
> has the following effect:
> 
> load_image() @ driver/cell.c uses the first available memory_region and
> copies inmates/demos/x86/tiny-demo.bin
> to that location
> then load_image() actually uses the same memory_region (same physical
> start but ioremapped at a different location)
> and overwrites the first bytes of inmates/demos/x86/tiny-demo.bin.
> 
> Unexpectedly, the string "con-type=JAILHOUSE" happen to correspond to
> executable code bytes and it does "something" on my system.
> 
> I.2 - possible solution
> 
> the simplest way to solve this is:
> - reserve say the rest of the first page to boot code and command line:
> a inmate.lds patch can do the job
> - change jailhouse.c to load the fake image at offset 0x100 (updating
> target_address) so that driver.c does not override the .boot section
> 
> If this is acceptable for now, I can publish patches.

This is a documentation issue, at most. See above.

> 
> II - VMCALL
> 
> II.1 - problem
> hypercall_init() @ checks for X86_FEATURE_VMX to use either VMCALL or
> VMMCALL.
> but vcpu_handle_cpuid() @ hypervisor/arch/x86/vcpu.c always clears this
> bit for non root cell.
> Thus, hypercalls in non AMD system do not work at all in non-root cells
> based on inmates demo code!

Yeah, that's a regression of my commit 39dfc93aa472...

> 
> II.2 - possible solution
> 
> Linux as a guest uses a "synthetic" bit, X86_FEATURE_VMMCALL,
> see
> https://elixir.bootlin.com/linux/v4.16.1/source/arch/x86/include/asm/cpufeatures.h#L225
> 
> to detect proper alternative
> #define KVM_HYPERCALL \
>     ALTERNATIVE(".byte 0x0f,0x01,0xc1", ".byte 0x0f,0x01,0xd9",
> X86_FEATURE_VMMCALL)
> 
> I would suggest the same, adding a bit in cpuid leaf
> (JAILHOUSE_CPUID_FEATURES).
> 

That X86_FEATURE_VMMCALL is set by Linux itself. We should port that
logic over: wwitch to VMMCALL if and only if an AMD CPU is detected
(linux/arch/x86/kernel/cpu/amd.c), otherwise stick with Intel's VMCALL.
Patch welcome!

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 an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH v2 0/4] Support for Nvidia Jetson TX2

2018-04-11 Thread Claudio Scordino 
Tested on the "next" branch against Nvidia's kernel 4.4 (not Vanilla) by
restoring the ABI for kernels < 4.7 in hypervisor/arch/arm64/entry.S:

/* install bootstrap_vectors */
ldr x0, =bootstrap_vectors
virt2phys x0

Claudio Scordino (4):
  Jetson TX2: root cell config
  Jetson TX2: add inmate support
  Jetson TX2: add demo cell config
  Documentation: Add TX2 to the list of supported hardware

 Documentation/hypervisor-configuration.md |   6 +-
 README.md |   2 +-
 configs/arm64/jetson-tx2-demo.c   |  51 
 configs/arm64/jetson-tx2.c| 492 ++
 inmates/lib/arm64/include/mach.h  |   8 +
 5 files changed, 557 insertions(+), 2 deletions(-)
 create mode 100644 configs/arm64/jetson-tx2-demo.c
 create mode 100644 configs/arm64/jetson-tx2.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 v2 1/4] Jetson TX2: root cell config

2018-04-11 Thread Claudio Scordino 
Root cell config for Jetson TX2 using Nvidia's kernel 4.4 (not Vanilla).

Tested on the "next" branch by restoring the ABI for kernels < 4.7 in
hypervisor/arch/arm64/entry.S:

/* install bootstrap_vectors */
ldr x0, =bootstrap_vectors
virt2phys x0

Signed-off-by: Claudio Scordino 
---
 configs/arm64/jetson-tx2.c | 492 +
 1 file changed, 492 insertions(+)
 create mode 100644 configs/arm64/jetson-tx2.c

diff --git a/configs/arm64/jetson-tx2.c b/configs/arm64/jetson-tx2.c
new file mode 100644
index 000..0d23158
--- /dev/null
+++ b/configs/arm64/jetson-tx2.c
@@ -0,0 +1,492 @@
+/*
+ * Jailhouse, a Linux-based partitioning hypervisor
+ *
+ * Configuration for Jailhouse Jetson TX2 board
+ *
+ * Copyright (C) 2018 Evidence Srl
+ *
+ * Authors:
+ *  Claudio Scordino 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * NOTE: Add "mem=7808M vmalloc=512M" to the kernel command line.
+ *
+ * 2:7000: inmate (size: 100: = 16 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[57];
+   struct jailhouse_irqchip irqchips[2];
+} __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,
+   .flags = JAILHOUSE_CON1_TYPE_8250 |
+JAILHOUSE_CON1_ACCESS_MMIO |
+JAILHOUSE_CON1_REGDIST_4 |
+JAILHOUSE_CON2_TYPE_ROOTPAGE,
+   },
+   .platform_info = {
+
+   .arm = {
+   .gicd_base = 0x03881000,
+   .gicc_base = 0x03882000,
+   .gich_base = 0x03884000,
+   .gicv_base = 0x03886000,
+   .gic_version = 2,
+   .maintenance_irq = 25,
+   }
+   },
+   .root_cell = {
+   .name = "Jetson-TX2",
+   .cpu_set_size = sizeof(config.cpus),
+   .num_memory_regions = ARRAY_SIZE(config.mem_regions),
+   .num_irqchips = ARRAY_SIZE(config.irqchips),
+   },
+   },
+
+   .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,
+.virt_start = 0x0010,
+.size = 0x1,
+.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
+JAILHOUSE_MEM_EXECUTE,
+},
+
+   /* AXIP2P */ {
+   .phys_start = 0x0210,
+   .virt_start = 0x0210,
+   .size = 0x10,
+   .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
+   JAILHOUSE_MEM_EXECUTE,
+   },
+   /* GPIO_CTL */ {
+   .phys_start = 0x0220,
+   .virt_start = 0x0220,
+   .size = 0x10,
+   .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
+   JAILHOUSE_MEM_EXECUTE,
+   },
+   /* TSA */ {
+   .phys_start = 0x240,
+   .virt_start = 0x240,
+   .size = 0x2,
+   .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
+   JAILHOUSE_MEM_EXECUTE,
+   },
+   /* PADCTL_A (PINMUX) */ {
+   .phys_start = 0x0243,
+   .virt_start = 0x0243,
+   .size = 0x15000,
+   .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
+   JAILHOUSE_MEM_EXECUTE,
+   },
+   /* UFSHC

[PATCH v2 2/4] Jetson TX2: add inmate support

2018-04-11 Thread Claudio Scordino 
Signed-off-by: Claudio Scordino 
---
 inmates/lib/arm64/include/mach.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/inmates/lib/arm64/include/mach.h b/inmates/lib/arm64/include/mach.h
index 478e32d..498843c 100644
--- a/inmates/lib/arm64/include/mach.h
+++ b/inmates/lib/arm64/include/mach.h
@@ -70,6 +70,14 @@
 #define GICD_V2_BASE   ((void *)0x50041000)
 #define GICC_V2_BASE   ((void *)0x50042000)
 
+#elif defined(CONFIG_MACH_JETSON_TX2)
+#define CON_TYPE   "8250"
+#define CON_BASE   0x310
+
+#define GIC_VERSION2
+#define GICD_V2_BASE   ((void *)0x03881000)
+#define GICC_V2_BASE   ((void *)0x03882000)
+
 #elif defined(CONFIG_MACH_ZYNQMP_ZCU102)
 #define CON_TYPE   "XUARTPS"
 #define CON_BASE   0xff01
-- 
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 v2 3/4] Jetson TX2: add demo cell config

2018-04-11 Thread Claudio Scordino 
Signed-off-by: Claudio Scordino 
---
 configs/arm64/jetson-tx2-demo.c | 51 +
 1 file changed, 51 insertions(+)
 create mode 100644 configs/arm64/jetson-tx2-demo.c

diff --git a/configs/arm64/jetson-tx2-demo.c b/configs/arm64/jetson-tx2-demo.c
new file mode 100644
index 000..7cb8dbe
--- /dev/null
+++ b/configs/arm64/jetson-tx2-demo.c
@@ -0,0 +1,51 @@
+/*
+ * 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
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ */
+
+#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[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),
+   },
+
+   .cpus = {
+   0x1,
+   },
+
+   .mem_regions = {
+   /* UART */ {
+   .phys_start = 0x310,
+   .virt_start = 0x310,
+   .size = 0x1000,
+   .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
+   JAILHOUSE_MEM_IO,
+   },
+   /* RAM */ {
+   .phys_start = 0x27000,
+   .virt_start = 0,
+   .size = 0x100,
+   .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
+   JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_LOADABLE,
+   },
+   },
+};
-- 
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 v2 4/4] Documentation: Add TX2 to the list of supported hardware

2018-04-11 Thread Claudio Scordino 
Signed-off-by: Claudio Scordino 
---
 Documentation/hypervisor-configuration.md | 6 +-
 README.md | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/hypervisor-configuration.md 
b/Documentation/hypervisor-configuration.md
index 57b3c88..021093e 100644
--- a/Documentation/hypervisor-configuration.md
+++ b/Documentation/hypervisor-configuration.md
@@ -64,10 +64,14 @@ General configuration parameters
 
  ARM64
 
-# Nvidia Jetson TK1
+# Nvidia Jetson TX1
 
 #define CONFIG_MACH_JETSON_TX1 1
 
+# Nvidia Jetson TX2
+
+#define CONFIG_MACH_JETSON_TX2 1
+
 # Xilinx Zynq UltraScale+ MPSoC ZCU102
 
 #define CONFIG_MACH_ZYNQMP_ZCU102 1
diff --git a/README.md b/README.md
index a4fb59c..1e8433a 100644
--- a/README.md
+++ b/README.md
@@ -132,7 +132,7 @@ Hardware requirements (preliminary)
 
 - LeMaker HiKey
 
-- NVIDIA Jetson TX1
+- NVIDIA Jetson TX1 and TX2
 
 - Xilinx ZCU102 (ZynqMP evaluation board)
 
-- 
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.

[RFC]: fixing cmdline and hypercall instruction detection

2018-04-11 Thread ff 
In trying to get the tiny-demo send logs to jailhouse debug console I 
found that:

- inmate lib handling of cmdline is broken
- inmate lib detection whether to use VMCALL (Intel) or VMMCALL (AMD) 
instructions to do hypercalls is broken


I found fixes but I'd like to discuss how to properly address the issues

I -  cmdline

I.1 - problem

according to inmates/lib/x86/inmate.lds
cmdline is located at offset 0x100 in the running inmate
it contains one byte (a zero).
inmate code starts at 0x101

according to Documentation/debug-output.md
command line parameters are specified using -s 

lastly, cell_shutdown_load() in tools/jailhouse.c considers "-s 
" as a second image to be loaded


so the command

jailhouse cell load --name tiny-demo inmates/demos/x86/tiny-demo.bin -s 
"con-type=JAILHOUSE"


has the following effect:

load_image() @ driver/cell.c uses the first available memory_region and 
copies inmates/demos/x86/tiny-demo.bin

to that location
then load_image() actually uses the same memory_region (same physical 
start but ioremapped at a different location)

and overwrites the first bytes of inmates/demos/x86/tiny-demo.bin.

Unexpectedly, the string "con-type=JAILHOUSE" happen to correspond to 
executable code bytes and it does "something" on my system.


I.2 - possible solution

the simplest way to solve this is:
- reserve say the rest of the first page to boot code and command line: 
a inmate.lds patch can do the job
- change jailhouse.c to load the fake image at offset 0x100 (updating 
target_address) so that driver.c does not override the .boot section


If this is acceptable for now, I can publish patches.

II - VMCALL

II.1 - problem
hypercall_init() @ checks for X86_FEATURE_VMX to use either VMCALL or 
VMMCALL.
but vcpu_handle_cpuid() @ hypervisor/arch/x86/vcpu.c always clears this 
bit for non root cell.
Thus, hypercalls in non AMD system do not work at all in non-root cells 
based on inmates demo code!


II.2 - possible solution

Linux as a guest uses a "synthetic" bit, X86_FEATURE_VMMCALL,
see 
https://elixir.bootlin.com/linux/v4.16.1/source/arch/x86/include/asm/cpufeatures.h#L225

to detect proper alternative
#define KVM_HYPERCALL \
ALTERNATIVE(".byte 0x0f,0x01,0xc1", ".byte 0x0f,0x01,0xd9", 
X86_FEATURE_VMMCALL)


I would suggest the same, adding a bit in cpuid leaf 
(JAILHOUSE_CPUID_FEATURES).




-FF

--
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: [PATCH 1/4] Jetson TX2: root cell config

2018-04-11 Thread Claudio Scordino 
Hi Jan,

2018-04-10 18:30 GMT+02:00 Jan Kiszka :

> On 2018-04-10 15:00, Claudio Scordino wrote:
> >
> >
> > 2018-04-09 19:36 GMT+02:00 Jan Kiszka  > >:
> >
> > On 2018-04-09 16:35, Claudio Scordino wrote:
> > >
> > >
> > > 2018-04-09 16:28 GMT+02:00 Lokesh Vutla  
> > > >>:
> > >
> > >
> > >
> > > On Monday 09 April 2018 07:53 PM, Claudio Scordino wrote:
> > > > Signed-off-by: Claudio Scordino  
> > >  com>>>
> > > > ---
> > > >  configs/arm64/jetson-tx2.c | 492
> > > +
> > > >  1 file changed, 492 insertions(+)
> > > >  create mode 100644 configs/arm64/jetson-tx2.c
> > > >
> > > > diff --git a/configs/arm64/jetson-tx2.c
> b/configs/arm64/jetson-tx2.c
> > > > new file mode 100644
> > > > index 000..0d23158
> > > > --- /dev/null
> > > > +++ b/configs/arm64/jetson-tx2.c
> > > > @@ -0,0 +1,492 @@
> > > > +/*
> > > > + * Jailhouse, a Linux-based partitioning hypervisor
> > > > + *
> > > > + * Configuration for Jailhouse Jetson TX2 board
> > > > + *
> > > > + * Copyright (C) 2018 Evidence Srl
> > > > + *
> > > > + * Authors:
> > > > + *  Claudio Scordino 
> > >  com>>>
> > > > + *
> > > > + * This work is licensed under the terms of the GNU GPL,
> > version
> > > 2.  See
> > > > + * the COPYING file in the top-level directory.
> > > > + *
> > > > + * NOTE: Add "mem=7808M vmalloc=512M" to the kernel command
> > line.
> > > > + *
> > > > + *   2:7000: inmate (size: 100: = 16 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[57];
> > > > + struct jailhouse_irqchip irqchips[2];
> > > > +} __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,
> > > > + .flags = JAILHOUSE_CON1_TYPE_8250 |
> > > > +  JAILHOUSE_CON1_ACCESS_MMIO |
> > > > +  JAILHOUSE_CON1_REGDIST_4 |
> > > > +  JAILHOUSE_CON2_TYPE_ROOTPAGE,
> > > > + },
> > > > + .platform_info = {
> > > > +
> > > > + .arm = {
> > > > + .gicd_base = 0x03881000,
> > > > + .gicc_base = 0x03882000,
> > > > + .gich_base = 0x03884000,
> > > > + .gicv_base = 0x03886000,
> > > > + .gic_version = 2,
> > > > + .maintenance_irq = 25,
> > > > + }
> > > > + },
> > > > + .root_cell = {
> > > > + .name = "Jetson-TX2",
> > > > + .cpu_set_size = sizeof(config.cpus),
> > > > + .num_memory_regions =
> > > ARRAY_SIZE(config.mem_regions),
> > > > + .num_irqchips =
> > ARRAY_SIZE(config.irqchips),
> > > > + },
> > > > + },
> > > > +
> > > > + .cpus = {
> > > > + 0x39,
> > > > + },
> > >
> > > Out of curiosity, is it deliberate that cpu1,2 are skipped?
> > >
> > >
> > > By default, the Linux kernel shipped by Nvidia boots with those
> > two CPUs
> > > disabled.
> >