Announcement

Collapse
No announcement yet.

Jailhouse 0.12 Hypervisor Adds Raspberry Pi 4 Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Jailhouse 0.12 Hypervisor Adds Raspberry Pi 4 Support

    Phoronix: Jailhouse 0.12 Hypervisor Adds Raspberry Pi 4 Support

    Siemens continues investing in Jailhouse as a Linux-based simplicity-minded partitioning hypervisor catering to bare metal appliances. Jailhouse 0.12 is out today as their first feature update since last summer and comes with numerous hardware support improvements and new features...

    http://www.phoronix.com/scan.php?pag...-0.12-Released

  • #2
    They are also starting to port Jailhouse to RISC-V!

    Comment


    • #3
      Can someone name a few sample use cases? I understand this is a lightweight para-virtualization software, but what would I want to use it for, where it is preferable over both heavy-weight para-virtualization like Xen and actual virtualization like KVM?

      Comment


      • #4
        I wonder what is actual hardware support for virtualization on the RPi4. IIRC, the RPi3 had the CPU capabilities but a gimped interrupt controller which is quite limiting. In particular, the only thing that could be achieved was static partitioning - you dedicate specific cores to the VMs and hide them from the host. Did the RPi4 fix that?

        Comment


        • #5
          Originally posted by dwagner View Post
          Can someone name a few sample use cases?
          It's used in modern Siemens automation stuff afaik (they have a bunch of all-in-one Windows/HMI/PLC devices too). That's one of the reasons they are aiming for the lowest LoC possible, as they have to validate and certify that to a higher degree than KVM or Xen are.

          I understand this is a lightweight para-virtualization software, but what would I want to use it for, where it is preferable over both heavy-weight para-virtualization like Xen and actual virtualization like KVM?
          Both Jailhouse and Xen are type 1 hypervisors with full virtualization capability and both need hardware virtualization support to do any real work (VT-x or VT-d and AMD VI or IOMMU), I'm unsure why you are calling them para-virtualization.

          EDIT: Also KVM is in the same category

          EDIT2: also ARM and Power have virtualization capability, I don't know the name of the hardware features for that.
          Last edited by starshipeleven; 02-05-2020, 07:41 AM.

          Comment


          • #6
            Originally posted by kobblestown View Post
            I wonder what is actual hardware support for virtualization on the RPi4. IIRC, the RPi3 had the CPU capabilities but a gimped interrupt controller which is quite limiting. In particular, the only thing that could be achieved was static partitioning - you dedicate specific cores to the VMs and hide them from the host. Did the RPi4 fix that?
            Afaik yes, Raspi4 fixed that https://blog.cloudkernels.net/posts/rpi4-64bit-virt/

            What’s interesting about the RPI4, as far as virtualization is concerned, is that it now comes with ARM’s standard GIC (Generic Interrupt Controller). Thus, unlike previous RPI generations that were wired with custom interrupt handling, virtualization is supported natively without any patching needed for interrupt emulation (and the overhead that this can incur…).

            Comment


            • #7
              Originally posted by starshipeleven View Post
              Both Jailhouse and Xen are type 1 hypervisors with full virtualization capability and both need hardware virtualization support to do any real work (VT-x or VT-d and AMD VI or IOMMU), I'm unsure why you are calling them para-virtualization.
              If a guest VM requires specific virtualization support in its operating system to run in the virtualization environment, then that is called para-virtualization, and it is measurably different from (non-para) virtualization, where the operating system of the guest VM does not need to know anything about whether it runs as some VM, and will use its normal hardware drivers which are unspecific to the virtualization environment.

              Sure there are optimizations to (non-para) virtualization environments like "qemu" that blur the lines, as it helps performance if the guest VM has specifically optimized drivers. But qemu can run unaltered images of systems that previously ran on physical hardware, while Xen cannot.

              Comment


              • #8
                Originally posted by dwagner View Post
                that is called para-virtualization
                I know what that is. I still don't understand why you are seeing Jailhouse and Xen as para-virtualization.

                I mean, I might be wrong about Jailhouse, but I'm pretty dang sure about Xen that it is a fully fledged virtualization. They do offer paravirtualization but it's only for Linux/Unix guests that can actually be modified to work in a paravirtualized environment. If you run Windows you MUST have full virtualization, down to emulating a BIOS/UEFI firmware and straight up emulating some basic hardware interfaces for the sake of bringing up the guest OS far enough to be able to install dedicated drivers, for the very least.

                See their wiki for more info on that. https://wiki.xenproject.org/wiki/Und...ation_Spectrum

                qemu can run unaltered images of systems that previously ran on physical hardware, while Xen cannot.
                This is just because QEMU can emulate specific hardware (and CPU architectures and CPU features) while Xen (and probably Jailhouse) cannot, or not as well, so if you change the host system you are changing the hardware of the guest system too to some extent (mostly the CPU features, you cannot fake a different CPU outside of KVM/QEMU).

                This is completely tangential to being para-virtualized or not as the issue isn't the hypervisor. The OS in the VM would have the same issues at being ported from the old host hardware to the new host hardware.

                The issue here is that the hypervisor can't fake the hardware as well as QEMU so the VM interface changes if you change the hardware.

                With moderately modern Windows guest for example you should be able to do this porting by issuing a "sysprep generalize" in the Windows VM in the old host before you start the migration, so it will prepare itself to be moved to new hardware just as a normal Windows bare metal installation would.

                Comment

                Working...
                X