Implement >=z10 (s390x) support to QEMU
a project by mbenes
Updated over 3 years ago. 10 hacker ♥️.

Last time I checked QEMU lacked support for >= z10 processors. Thus one cannot run SLE12 and newer in a virtual machine on non-s390x host. I'd like to improve the situation during Hackweeks.

Join this project

Looking for hackers with the skills:

s390 qemu

This project is part of:

Hack Week 14 Hack Week 15 Hack Week 16

Activity

  • about 7 years ago: e_bischoff left this project.
  • about 7 years ago: ldevulder liked this project.
  • about 7 years ago: mkubecek liked this project.
  • almost 8 years ago: michal-m liked this project.
  • almost 8 years ago: michal-m disliked this project.
  • almost 8 years ago: e_bischoff added keyword "s390" to this project.
  • almost 8 years ago: e_bischoff added keyword "qemu" to this project.
  • almost 8 years ago: sparschauer liked this project.
  • almost 8 years ago: michal-m joined this project.
  • about 8 years ago: e_bischoff joined this project.
  • about 8 years ago: e_bischoff liked this project.
  • over 8 years ago: michal-m liked this project.
  • over 8 years ago: adamm liked this project.
  • over 8 years ago: dsterba liked this project.
  • over 8 years ago: mbenes started this project.
  • over 8 years ago: vimacs liked this project.
  • over 8 years ago: algraf liked this project.
  • over 8 years ago: a_faerber liked this project.
  • over 8 years ago: mbenes originated this project.


    • Comments

    • e_bischoff
      almost 8 years ago by e_bischoff | Reply

      I have submitted upstream a first patch to support the s/390 instructions LPD and LPDG (LOAD PAIR DISJOINT).

      Unfortunately, these instructions are not needed for SLE12 to boot, but it was a way for me to learn how qemu works and to do a first contribution.

    • michal-m
      almost 8 years ago by michal-m | Reply

      I fixed the emulation of the STFL (STORE FACILITY LIST) instruction and implemented STFLE. So we now indicate the proper facility bits to the kernel. The next problem is that the kernel is trying to use the advertised facilities and crashes :-). Miroslav implemented the LPP (LOAD PROGRAM PARAMETER) instruction, which means that the kernel lives a bit longer. I'm now studying the s390x memory model and the qemu mmu code to implement the IDTE (INVALIDATE DAT TABLE ENTRY) instruction, which is what is needed to boot the kernel under z990 emulation. We all learned a lot about the architecture and about qemu internals, but the stated goal of booting the SLE12 kernel unmodified (means z196 emulation) is still a distant one.

    • mbenes
      about 7 years ago by mbenes | Reply

      A lot has changed in qemu and upstream kernel since the last hackweek in Feb 2017. Lots of instructions were implemented in qemu and couple of facilities are supported. Maximum supported cpu model was changed from z900 to a stripped down z12 (this should get to qemu 2.12). At the same time, kernel's arch support was improved a lot. ALS (architecture level set) was rewritten from assembly to C code. Much more importantly a set of facilities required to run the kernel was reduced significantly. All this means that it is straightforward to run s390x upstream kernel on non-s390x host. SLE15 4.12 kernel contains all those important changes and thus we can run complete s390x SLE15 installation on non-s390x host.

      I deem the hackweek project done. We can of course improve qemu implementation to support also SLE12 in the future, but I think it is not necessary.

    Similar Projects

    terraform-provider-feilong by e_bischoff

    Project Description

    People need to test operating systems and applications on s390 platform.

    Installation from scratch solutions include:

    • just deploy and provision manually add-emoji (with the help of ftpboot script, if you are at SUSE)
    • use s3270 terminal emulation (used by openQA people?)
    • use LXC from IBM to start CP commands and analyze the results
    • use zPXE to do some PXE-alike booting (used by the orthos team?)
    • use tessia to install from scratch using autoyast
    • use libvirt for s390 to do some nested virtualization on some already deployed z/VM system
    • directly install a Linux kernel on a LPAR and use kvm + libvirt from there

    Deployment from image solutions include:

    • use ICIC web interface (openstack in disguise, contributed by IBM)
    • use ICIC from the openstack terraform provider (used by Rancher QA)
    • use zvm_ansible to control SMAPI
    • connect directly to SMAPI low-level socket interface

    IBM Cloud Infrastructure Center (ICIC) harnesses the Feilong API, but you can use Feilong without installing ICIC, provided you set up a "z/VM cloud connector" into one of your VMs following this schema.

    What about writing a terraform Feilong provider, just like we have the terraform libvirt provider? That would allow to transparently call Feilong from your main.tf files to deploy and destroy resources on your system/z.

    Other Feilong-based solutions include:

    • make libvirt Feilong-aware
    • simply call Feilong from shell scripts with curl
    • use zvmconnector client python library from Feilong
    • use zthin part of Feilong to directly command SMAPI.

    Goal for Hackweek 23

    My final goal is to be able to easily deploy and provision VMs automatically on a z/VM system, in a way that people might enjoy even outside of SUSE.

    My technical preference is to write a terraform provider plugin, as it is the approach that involves the least software components for our deployments, while remaining clean, and compatible with our existing development infrastructure.

    Goals for Hackweek 24

    Feilong provider works and is used internally by SUSE Manager team. Let's push it forward!

    Let's add support for fiberchannel disks and multipath.

    Goals for Hackweek 25

    • Finish support for fiberchannel disks and multipath
    • Fix problems with registration on hashicorp providers registry