This release is an important milestone for Jailhouse because it comes
with a reworked inter-cell communication device with better driver
support and even an experimental virtio transport model for this.
While this shared memory device model is still in discussion with virtio
and QEMU communities, thus may undergo some further smaller changes, it
was important to move forward with it because there is an increasing
demand for it on the Jailhouse side. We now support multi-peer
connection, have a secure (unprivileged) and efficient UIO driver and
can even start working on virtio integration - without having to touch
the hypervisor any further. More information also in [1].
The release has another important new, and that is SMMUv3 for ARM64
target, as well as the TI-specific MPU-like Peripheral Virtualization
Unit (PVU). SMMUv2 support is unfortunately still waiting in some NXP
downstream branch for being pushed upstream.
Note that there are several changes to the configuration format that
require adjustments of own configs. Please study related changes in our
reference configurations or, on x86, re-generate the system configuration.
Due to all these significant changes, statistics for this release look
about more heavyweight than usual:
195 files changed, 7185 insertions(+), 2612 deletions(-)
- New targets:
- Texas Instruments J721E-EVM
- Raspberry Pi 4 Model B
- Cross-arch changes:
- rework of ivshmem inter-cell communication device
- fix hugepage splitting in paging_destroy
- allow to disable hugepage creation
(to statically mitigate CVE-2018-12207)
- ARM / ARM64:
- SMMUv3 support
- TI PVU support
- fix race several conditions in IRQ injection
- add support for PCI in bare-metal inmates
- x86:
- model PIO access via whitelist regions, rather than bitmaps
- vtd: Protect against invalid IQT register values
- fix 1024x768 mode of EFI framebuffer
- permit root cell to enable CR4.UMIP
You can download the new release from
https://github.com/siemens/jailhouse/archive/v0.12.tar.gz
then follow the README.md for first steps on recommended evaluation
platforms and check the tutorial session from ELC-E 2016 [2][3]. To try
out Jailhouse in a virtual environment or on a few reference boards,
there is an image generator available [4]. It will soon be updated to
the new release as well. Drop us a note on the mailing list if you run
into trouble.
A quick forecast of what is being worked on: One of the next major
changes will be a rework of the CPU selection in configs (selection by
stable physical IDs), along with support for L2 CAT on Intel processors.
There is also ongoing discussion to extend sub-page memory regions with
access bitmaps, on byte or even register bit-level. That will make
access control more scalable, e.g. to pass pinmux registers to different
cells.
Last but not least: We are starting a port of Jailhouse to RISC-V, first
against QEMU, then against an FPGA model that will be developed within
the EU-funded SELENE project. Stay tuned, there will be more behind it!
Thanks to all the contributors and supporters!
Jan
[1]
https://static.sched.com/hosted_files/kvmforum2019/4b/KVM-Forum19_ivshmem2.pdf
[2]
https://events.static.linuxfound.org/sites/events/files/slides/ELCE2016-Jailhouse-Tutorial.pdf
[3] https://youtu.be/7fiJbwmhnRw?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q
[4] https://github.com/siemens/jailhouse-images
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
> Subject: [ANNOUNCE] Jailhouse 0.12 released
>
> This release is an important milestone for Jailhouse because it comes with a
> reworked inter-cell communication device with better driver support and
> even an experimental virtio transport model for this.
Great to know this.
>
> While this shared memory device model is still in discussion with virtio and
> QEMU communities, thus may undergo some further smaller changes, it was
> important to move forward with it because there is an increasing demand for
> it on the Jailhouse side. We now support multi-peer connection, have a secure
> (unprivileged) and efficient UIO driver and can even start working on virtio
> integration - without having to touch the hypervisor any further. More
> information also in [1].
Do we need to use qemu for virtio backend?
>
> The release has another important new, and that is SMMUv3 for ARM64
> target, as well as the TI-specific MPU-like Peripheral Virtualization Unit (PVU).
> SMMUv2 support is unfortunately still waiting in some NXP downstream
> branch for being pushed upstream.
Alice in Cc is doing this effort together with i.MX8QM upstreaming.
>
> Note that there are several changes to the configuration format that require
> adjustments of own configs. Please study related changes in our reference
> configurations or, on x86, re-generate the system configuration.
>
> Due to all these significant changes, statistics for this release look about more
> heavyweight than usual:
> 195 files changed, 7185 insertions(+), 2612 deletions(-)
Yeah!! Besides this, any people still interested in booting jailhouse before Linux?
I have achieved this on i.MX8MM with Linux + gic-demo cell, with a baremetal
program and using U-Boot FIT to load all images.
Regards,
Peng.
>
> - New targets:
> - Texas Instruments J721E-EVM
> - Raspberry Pi 4 Model B
> - Cross-arch changes:
> - rework of ivshmem inter-cell communication device
> - fix hugepage splitting in paging_destroy
> - allow to disable hugepage creation
> (to statically mitigate CVE-2018-12207)
> - ARM / ARM64:
> - SMMUv3 support
> - TI PVU support
> - fix race several conditions in IRQ injection
> - add support for PCI in bare-metal inmates
> - x86:
> - model PIO access via whitelist regions, rather than bitmaps
> - vtd: Protect against invalid IQT register values
> - fix 1024x768 mode of EFI framebuffer
> - permit root cell to enable CR4.UMIP
>
> You can download the new release from
>
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2Fsiemens%2Fjailhouse%2Farchive%2Fv0.12.tar.gz&data=02%7C0
> 1%7Cpeng.fan%40nxp.com%7Cebb3042a71144b074ec108d7a98171c6%7C6
> 86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637164245729737210&
> amp;sdata=maPE%2FCI8qJmIYhKCzFdnzn9rnpNgHmXjksAHRd6sEA0%3D&am
> p;reserved=0
>
> then follow the README.md for first steps on recommended evaluation
> platforms and check the tutorial session from ELC-E 2016 [2][3]. To try out
> Jailhouse in a virtual environment or on a few reference boards, there is an
> image generator available [4]. It will soon be updated to the new release as
> well. Drop us a note on the mailing list if you run into trouble.
>
> A quick forecast of what is being worked on: One of the next major changes
> will be a rework of the CPU selection in configs (selection by stable physical
> IDs), along with support for L2 CAT on Intel processors.
> There is also ongoing discussion to extend sub-page memory regions with
> access bitmaps, on byte or even register bit-level. That will make access
> control more scalable, e.g. to pass pinmux registers to different cells.
>
> Last but not least: We are starting a port of Jailhouse to RISC-V, first against
> QEMU, then against an FPGA model that will be developed within the
> EU-funded SELENE project. Stay tuned, there will be more behind it!
>
> Thanks to all the contributors and supporters!
>
> Jan
>
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstatic.
> sched.com%2Fhosted_files%2Fkvmforum2019%2F4b%2FKVM-Forum19_ivsh
> mem2.pdf&data=02%7C01%7Cpeng.fan%40nxp.com%7Cebb3042a7114
> 4b074ec108d7a98171c6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C1%7C637164245729737210&sdata=2u04ZeAIHTKI0KiPAGUHKWUKKV8
> IRFyULilkB%2B0Ycxg%3D&reserved=0
> [2]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevents
> .static.linuxfound.org%2Fsites%2Fevents%2Ffiles%2Fslides%2FELCE2016-Jailh
> ouse-Tutorial.pdf&data=02%7C01%7Cpeng.fan%40nxp.com%7Cebb304
> 2a71144b074ec108d7a98171c6%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C1%7C637164245729737210&sdata=4kexuNYjdhEV2w1RearsgdZ
> jzlgocno%2FKc9CjBEtf7s%3D&reserved=0
> [3]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.
> be%2F7fiJbwmhnRw%3Flist%3DPLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q&
> amp;data=02%7C01%7Cpeng.fan%40nxp.com%7Cebb3042a71144b074ec108
> d7a98171c6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63716
> 4245729737210&sdata=kALnVcxFlaAo%2Fva8wYeab34onOZs8v7HFZVrt
> AQzDGE%3D&reserved=0
> [4]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2Fsiemens%2Fjailhouse-images&data=02%7C01%7Cpeng.fan%40
> nxp.com%7Cebb3042a71144b074ec108d7a98171c6%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C1%7C637164245729737210&sdata=SFzfugp
> o%2FjrtpIsIIdOyuvMwXJCX2Tp%2BPlTZ9%2Fc7h20%3D&reserved=0
>
> --
> 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 [email protected].
> To view this discussion on the web visit
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups
> .google.com%2Fd%2Fmsgid%2Fjailhouse-dev%2Fdd4344b9-ca04-0ef2-0810-6
> b98e30f68b4%2540siemens.com&data=02%7C01%7Cpeng.fan%40nxp.c
> om%7Cebb3042a71144b074ec108d7a98171c6%7C686ea1d3bc2b4c6fa92cd
> 99c5c301635%7C0%7C1%7C637164245729737210&sdata=sAJu0I4USC
> T%2FiWN%2B0UhH3ddunIN6%2BtkF9r350x%2Fuaxs%3D&reserved=0.
On 20.02.20 03:39, Peng Fan wrote:
>> Subject: [ANNOUNCE] Jailhouse 0.12 released
>>
>> This release is an important milestone for Jailhouse because it comes with a
>> reworked inter-cell communication device with better driver support and
>> even an experimental virtio transport model for this.
>
> Great to know this.
If there is interest, please provide feedback, ideally also in the
circle where I started spec discussions and QEMU implementation.
>
>>
>> While this shared memory device model is still in discussion with virtio and
>> QEMU communities, thus may undergo some further smaller changes, it was
>> important to move forward with it because there is an increasing demand for
>> it on the Jailhouse side. We now support multi-peer connection, have a secure
>> (unprivileged) and efficient UIO driver and can even start working on virtio
>> integration - without having to touch the hypervisor any further. More
>> information also in [1].
>
> Do we need to use qemu for virtio backend?
>
Nope, in fact there are only primitive demo backends for block and
console available that make use of UIO, see
http://git.kiszka.org/?p=linux.git;a=blob;f=tools/virtio/virtio-ivshmem-block.c;h=c97aa5076a6d22ccd01862f3e4db0e12641825c3;hb=refs/heads/queues/ivshmem2
and
http://git.kiszka.org/?p=linux.git;a=blob;f=tools/virtio/virtio-ivshmem-console.c;h=c79be22c6a7aa4c2eb49561e8c0d7c9a052e393d;hb=refs/heads/queues/ivshmem2
I was hoping to find something useful in ACRN but didn't succeed. So I
hacked up these two (basically in two evenings, that's why these two are
copy&paste). For the future, when the transport is more stable, looking
into a vhost mapping could be beneficial, specifically for networking.
Another direction could be https://github.com/rust-vmm/vm-virtio.
>>
>> The release has another important new, and that is SMMUv3 for ARM64
>> target, as well as the TI-specific MPU-like Peripheral Virtualization Unit (PVU).
>> SMMUv2 support is unfortunately still waiting in some NXP downstream
>> branch for being pushed upstream.
>
> Alice in Cc is doing this effort together with i.MX8QM upstreaming.
>
Great, looking forward!
>>
>> Note that there are several changes to the configuration format that require
>> adjustments of own configs. Please study related changes in our reference
>> configurations or, on x86, re-generate the system configuration.
>>
>> Due to all these significant changes, statistics for this release look about more
>> heavyweight than usual:
>> 195 files changed, 7185 insertions(+), 2612 deletions(-)
>
> Yeah!! Besides this, any people still interested in booting jailhouse before Linux?
> I have achieved this on i.MX8MM with Linux + gic-demo cell, with a baremetal
> program and using U-Boot FIT to load all images.
Yes, there is definitely interest, for various reasons. One can be cache
coloring. We are also considering to look into this boot mode in the
context of the just started RISC-V port. And there might be a case on
x86 again, but the boot environment is still not clear to me there
(likely not UEFI).
If you have a prototype for ARM64 and U-Boot, that would be great to see
it, maybe let more people play with it. Eventually, I want to start
discussing requirements and potentially required new interfaces.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux