Re: [PATCH 1/4] Jetson TX2: root cell config

[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  clau...@evidence.eu.com>
> > >  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.
> > > They can be easily enabled by echoing 1 into
> > > /sys/devices/system/cpu/cpu*/online.
> >
> > Are we targe

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

[Jan Kiszka]

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.

Thanks,
Jan

[1] http://lkml.iu.edu/hypermail/linux/kernel/1606.3/00072.html

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

[Giovani Gracioli]

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.

Re: Share memory among cells on arm64

[Jan Kiszka]

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.

Re: [PATCH 1/4] Jetson TX2: root cell config

[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  
> >     >>
> >     > ---
> >     >  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,
> >     > +     },
> >
> >     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.
> > They can be easily enabled by echoing 1 into
> > /sys/devices/system/cpu/cpu*/online.
> 
> Are we targeting a downstream kernel here? Because upstream is not
> booting at all, or because it is lacking some nice-to-have feature? If
> upstream is booting, what is its behavior in this regard? Seems we are
> lacking some documentation here.
> 
> 
> In my experienc

Re: Jailhouse zynqMP

[Jan Kiszka]

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]
>>> http://git.kiszka.org/?p=linux.git;a=commit;h=222ae01c41444f5bb8a8c6def3b8bd94ebede24a
>>
>> Hi,
>>
>> Perhaps I am not understanding well. But, do I need to know all that to have 
>> the console of the non-root cell?
>>
>> The zynqmp-zcu102-linux-demo.cell has the UART defined:
>> /* UART */ {
>>   .phys_start = 0xff01,
>> 

Re: Share memory among cells on arm64

[Giovani Gracioli]

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?

Thanks
Giovani

> Thanks for the answers.
> 
> So, I have changed the config. In the root cell I have the following now:
> 
> /* IVSHMEM shared memory region for 00:00.0 */ {
>   .phys_start = 0x80040,
>   .virt_start = 0x80040,
>   .size = 0x10,
>   .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | 
> JAILHOUSE_MEM_ROOTSHARED, //added MEM_ROOTSHARED
>   },
> 
> .pci_devices = {
>   /* 00:00.0 */ {
>   .type = JAILHOUSE_PCI_TYPE_IVSHMEM,
>   .bdf = 0 << 3,
>   .bar_mask = {
>   0xff00, 0x, 0x,
>   0x, 0x, 0x,
>   },
>   .shmem_region = 3,
>   .shmem_protocol = JAILHOUSE_SHMEM_PROTO_UNDEFINED, 
> //changed from JAILHOUSE_SHMEM_PROTO_VETH to JAILHOUSE_SHMEM_PROTO_UNDEFINED
>   },
>},
> 
> In the inmate cell, I have the following:
> 
> .mem_regions = {
>   ..
> .
> /* IVSHMEM shared memory region for 00:00.0 */ {
>   .phys_start = 0x80040,
>   .virt_start = 0x80040,
>   .size = 0x10,
>   .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | 
> JAILHOUSE_MEM_ROOTSHARED, //added JAILHOUSE_MEM_ROOTSHARED
>   },
>   },
> 
> Considering just the configuration of the cells, are they correct?
> 
> So correct me if I am wrong. I will need to write a driver in the root-cell 
> (Linux) to send and receive interrupts to/from the shared ivshmem region. The 
> mapped vpci region contains only the registers of the device:
> 
> 00:00.0 Unassigned class [ff00]: Red Hat, Inc Inter-VM shared memory
> Subsystem: Red Hat, Inc Inter-VM shared memory
> Flags: fast devsel, IRQ 38
> Memory at fc10 (64-bit, non-prefetchable) [size=256]
> 
> In this case, the address 0xfc10.
> 
> Is the address (0x80040) that I configured in the cell config file 
> actually the payload memory region?
> 
> Also, in the another inmate, how can I access the mapped region? I noticed 
> that there is an ivshmem-demo for x86, but there isn't for arm64. 
> 
> Thanks
> 
> > Hi,
> > 
> > what you see there are the registers of the ivshmem device, not the
> > payload memory region. You will have to map the paddr you have in your
> > cell-config. That paddr can be found in the config space as well, is
> > just not a regular PCI BAR.
> > 
> > I would suggest to write a uio driver and base it on
> > https://github.com/henning-schild-work/ivshmem-guest-code/tree/jailhouse
> > 
> > Here is the bit that finds the region
> > https://github.com/henning-schild-work/ivshmem-guest-code/blob/jailhouse/kernel_module/uio/uio_ivshmem.c#L96
> > 
> > Also see:
> > https://github.com/henning-schild-work/ivshmem-guest-code/blob/jailhouse/README.jailhouse
> > 
> > And you should not use JAILHOUSE_SHMEM_PROTO_VETH because you are not
> > running a network-device on top of your shmem. Use _UNDEFINED or
> > _CUSTOM instead.
> > 
> > Henning
> > 
> > Am Tue, 3 Apr 2018 10:47:31 -0700
> > schrieb Giovani Gracioli <>:
> > 
> > > Just another info, after enabling the root cell, I can see the
> > > virtual pci devices with lspci -v:
> > > 
> > > 00:00.0 Unassigned class [ff01]: Red Hat, Inc Inter-VM shared memory
> > > Subsystem: Red Hat, Inc Inter-VM shared memory
> > > Flags: fast devsel
> > > Memory at fc10 (64-bit, non-prefetchable) [disabled]
> > > [size=256] Memory at  (64-bit, non-prefetchable)
> > > [disabled] Capabilities: [50] MSI-X: Enable- Count=1 Masked-
> > > 
> > > 00:01.0 Unassigned class [ff01]: Red Hat, Inc Inter-VM shared memory
> > > Subsystem: Red Hat, Inc Inter-VM shared memory
> > > Flags: fast devsel
> > > Memory at fc100100 (64-bit, non-prefetchable) [disabled]
> > > [size=256]
> > > 
> > > 
> > > 
> > > > Hello,
> > > > 
> > > > I would like to share buffers among cells on arm64 (Xilinx
> > > > ultrascale+). The documentation suggests the use of the ivshmem.
> > > > 
> > > > In order to use ivshmem, I changed the root cell config as follows
> > > > (it is based on the zynqmp-zcu102.c original file):
> > > > 
> > > > - In the .mem

Re: Jailhouse zynqMP

[iallende]

El martes, 10 de abril de 2018, 15:12:25 (UTC+2), Ralf Ramsauer  escribió:
> 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]
> >> http://git.kiszka.org/?p=linux.git;a=commit;h=222ae01c41444f5bb8a8c6def3b8bd94ebede24a
> > 
> > Hi,
> > 
> > Perhaps I am not understanding well. But, do I need to know all th

Re: Jailhouse zynqMP

[Ralf Ramsauer]

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]
>> http://git.kiszka.org/?p=linux.git;a=commit;h=222ae01c41444f5bb8a8c6def3b8bd94ebede24a
> 
> Hi,
> 
> Perhaps I am not understanding well. But, do I need to know all that to have 
> the console of the non-root cell?
> 
> The zynqmp-zcu102-linux-demo.cell has the UART defined:
> /* UART */ {
>   .phys_start = 0xff01,
>   .virt_start = 0xff01,
>   .size = 0x1000,
>   .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
>JAILHOUSE_MEM_IO | JAILHOUSE_MEM_ROOTSHARED,
> },

Re: [PATCH 1/4] Jetson TX2: root cell config

[Claudio Scordino]

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  > >
> > > ---
> > >  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,
> > > + },
> >
> > 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.
> > They can be easily enabled by echoing 1 into
> > /sys/devices/system/cpu/cpu*/online.
>
> Are we targeting a downstream kernel here? Because upstream is not
> booting at all, or because it is lacking some nice-to-have feature? If
> upstream is booting, what is its behavior in this regard? Seems we are
> lacking some documentation here.
>

In my experience, most people with Nvidia hardware use the proprietary
kernel just because of the availability of the GPU stuff.
Therefore, it could make sense to allow the trampoline selection even for
the ABI < 4.7 (as already done for the next ABI change).
Nevertheless, I plan to try the Vanilla kernel in the next weeks and update
the Jailhouse support accordingly.

Regards,

   Claudio

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

[iallende]

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]
> http://git.kiszka.org/?p=linux.git;a=commit;h=222ae01c41444f5bb8a8c6def3b8bd94ebede24a

Hi,

Perhaps I am not understanding well. But, do I need to know all that to have 
the console of the non-root cell?

The zynqmp-zcu102-linux-demo.cell has the UART defined:
/* UART */ {
  .phys_start = 0xff01,
  .virt_start = 0xff01,
  .size = 0x1000,
  .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
   JAILHOUSE_MEM_IO | JAILHOUSE_MEM_ROOTSHARED,
},

The non-root cell DTB has the same UART defined:
uart: serial@ff01 {
  compatible =

[PATCH 2/2] tools: proper reporting of mandatory and optional VMXON features

[ff]

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 
---
 tools/jailhouse-hardware-check | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/jailhouse-hardware-check 
b/tools/jailhouse-hardware-check

index 67d3b078..2e3b818f 100755
--- a/tools/jailhouse-hardware-check
+++ b/tools/jailhouse-hardware-check
@@ -182,8 +182,8 @@ if cpu_vendor == 'GenuineIntel':
 check_feature('VT-x (VMX)', 'vmx' in cpu_features)

 feature = msr.read(MSR.IA32_FEATURE_CONTROL)
-check_feature('  VMX without TXT',
-  (feature & (1 << 0)) == 0 or feature & (1 << 2))
+check_feature('  VMX outside SMX', feature & (1 << 2))
+check_feature('  VMX inside SMX', feature & (1 << 1), True)
 check_feature('  IA32_TRUE_*_CLTS',
   msr.read(MSR.IA32_VMX_BASIC) & (1 << 55))

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

[PATCH 1/2] driver: ensure jailhouse is not enabled when VT-X is disabled by firmware

[ff]

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(&hypervisor, fw_name, jailhouse_dev);
--
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: Jailhouse zynqMP

[Ralf Ramsauer]

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]
http://git.kiszka.org/?p=linux.git;a=commit;h=222ae01c41444f5bb8a8c6def3b8bd94ebede24a

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

[iallende]

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?

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