[hercules-390] But... There is another !

[Ivan Warren [e-mail] [hercules-390]]

Hey folks,

I had fun around with yet another z/architecture implementation.... It's
open source, but it is limited to running linux and limited to z/Arch...

It's the qemu s390x emulator which uses a technique called "tcg" (Tiny
Code Generator) - which is a sort of JIT (Just In Time) compiler, which
rely on generating and optimizing machine code from emulated code using
the GCC backend by converting the emulated instructions to INSN (The
intermediate code) and then compiling that code to native code.

It's slightly (significantly) faster than hercules when it comes to
running zLinux...

Here are some of the times I get from compiling hercules itself (same
rig (Xeon based), single emulated CPU) :

qemu-system-s390x
real    108m35.287s
user    90m50.142s
sys     16m56.053s

hercules
real    222m33.518s
user    202m52.797s
sys     19m5.514s

Not sure how or if some of those techniques could be applied to hercules
(most problematic I think would be self modifying code) - and qemu s390x
certainly doesn't do SIE...

--Ivan




[Non-text portions of this message have been removed]

[Rahim Azizarab [e-mail] [hercules-390]]

Were you able to actually IPL a system with  qemu-system-s390s?   I had played with it but I was not able to IPL anything with it.

Sent from Yahoo Mail on Android

On Fri, Feb 9, 2018 at 11:11 AM, Ivan Warren ***@vmfacility.fr [hercules-390]<hercules-***@yahoogroups.com> wrote:  
Hey folks,

I had fun around with yet another z/architecture implementation.... It's
open source, but it is limited to running linux and limited to z/Arch...

It's the qemu s390x emulator which uses a technique called "tcg" (Tiny
Code Generator) - which is a sort of JIT (Just In Time) compiler, which
rely on generating and optimizing machine code from emulated code using
the GCC backend by converting the emulated instructions to INSN (The
intermediate code) and then compiling that code to native code.

It's slightly (significantly) faster than hercules when it comes to
running zLinux...

Here are some of the times I get from compiling hercules itself (same
rig (Xeon based), single emulated CPU) :

qemu-system-s390x
real    108m35.287s
user    90m50.142s
sys     16m56.053s

hercules
real    222m33.518s
user    202m52.797s
sys     19m5.514s

Not sure how or if some of those techniques could be applied to hercules
(most problematic I think would be self modifying code) - and qemu s390x
certainly doesn't do SIE...

--Ivan

[Non-text portions of this message have been removed]


#yiv0455784016 #yiv0455784016 -- #yiv0455784016ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0455784016 #yiv0455784016ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0455784016 #yiv0455784016ygrp-mkp #yiv0455784016hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv0455784016 #yiv0455784016ygrp-mkp #yiv0455784016ads {margin-bottom:10px;}#yiv0455784016 #yiv0455784016ygrp-mkp .yiv0455784016ad {padding:0 0;}#yiv0455784016 #yiv0455784016ygrp-mkp .yiv0455784016ad p {margin:0;}#yiv0455784016 #yiv0455784016ygrp-mkp .yiv0455784016ad a {color:#0000ff;text-decoration:none;}#yiv0455784016 #yiv0455784016ygrp-sponsor #yiv0455784016ygrp-lc {font-family:Arial;}#yiv0455784016 #yiv0455784016ygrp-sponsor #yiv0455784016ygrp-lc #yiv0455784016hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0455784016 #yiv0455784016ygrp-sponsor #yiv0455784016ygrp-lc .yiv0455784016ad {margin-bottom:10px;padding:0 0;}#yiv0455784016 #yiv0455784016actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0455784016 #yiv0455784016activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0455784016 #yiv0455784016activity span {font-weight:700;}#yiv0455784016 #yiv0455784016activity span:first-child {text-transform:uppercase;}#yiv0455784016 #yiv0455784016activity span a {color:#5085b6;text-decoration:none;}#yiv0455784016 #yiv0455784016activity span span {color:#ff7900;}#yiv0455784016 #yiv0455784016activity span .yiv0455784016underline {text-decoration:underline;}#yiv0455784016 .yiv0455784016attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv0455784016 .yiv0455784016attach div a {text-decoration:none;}#yiv0455784016 .yiv0455784016attach img {border:none;padding-right:5px;}#yiv0455784016 .yiv0455784016attach label {display:block;margin-bottom:5px;}#yiv0455784016 .yiv0455784016attach label a {text-decoration:none;}#yiv0455784016 blockquote {margin:0 0 0 4px;}#yiv0455784016 .yiv0455784016bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv0455784016 .yiv0455784016bold a {text-decoration:none;}#yiv0455784016 dd.yiv0455784016last p a {font-family:Verdana;font-weight:700;}#yiv0455784016 dd.yiv0455784016last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv0455784016 dd.yiv0455784016last p span.yiv0455784016yshortcuts {margin-right:0;}#yiv0455784016 div.yiv0455784016attach-table div div a {text-decoration:none;}#yiv0455784016 div.yiv0455784016attach-table {width:400px;}#yiv0455784016 div.yiv0455784016file-title a, #yiv0455784016 div.yiv0455784016file-title a:active, #yiv0455784016 div.yiv0455784016file-title a:hover, #yiv0455784016 div.yiv0455784016file-title a:visited {text-decoration:none;}#yiv0455784016 div.yiv0455784016photo-title a, #yiv0455784016 div.yiv0455784016photo-title a:active, #yiv0455784016 div.yiv0455784016photo-title a:hover, #yiv0455784016 div.yiv0455784016photo-title a:visited {text-decoration:none;}#yiv0455784016 div#yiv0455784016ygrp-mlmsg #yiv0455784016ygrp-msg p a span.yiv0455784016yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv0455784016 .yiv0455784016green {color:#628c2a;}#yiv0455784016 .yiv0455784016MsoNormal {margin:0 0 0 0;}#yiv0455784016 o {font-size:0;}#yiv0455784016 #yiv0455784016photos div {float:left;width:72px;}#yiv0455784016 #yiv0455784016photos div div {border:1px solid #666666;min-height:62px;overflow:hidden;width:62px;}#yiv0455784016 #yiv0455784016photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv0455784016 #yiv0455784016reco-category {font-size:77%;}#yiv0455784016 #yiv0455784016reco-desc {font-size:77%;}#yiv0455784016 .yiv0455784016replbq {margin:4px;}#yiv0455784016 #yiv0455784016ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv0455784016 #yiv0455784016ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv0455784016 #yiv0455784016ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv0455784016 #yiv0455784016ygrp-mlmsg select, #yiv0455784016 input, #yiv0455784016 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv0455784016 #yiv0455784016ygrp-mlmsg pre, #yiv0455784016 code {font:115% monospace;}#yiv0455784016 #yiv0455784016ygrp-mlmsg * {line-height:1.22em;}#yiv0455784016 #yiv0455784016ygrp-mlmsg #yiv0455784016logo {padding-bottom:10px;}#yiv0455784016 #yiv0455784016ygrp-msg p a {font-family:Verdana;}#yiv0455784016 #yiv0455784016ygrp-msg p#yiv0455784016attach-count span {color:#1E66AE;font-weight:700;}#yiv0455784016 #yiv0455784016ygrp-reco #yiv0455784016reco-head {color:#ff7900;font-weight:700;}#yiv0455784016 #yiv0455784016ygrp-reco {margin-bottom:20px;padding:0px;}#yiv0455784016 #yiv0455784016ygrp-sponsor #yiv0455784016ov li a {font-size:130%;text-decoration:none;}#yiv0455784016 #yiv0455784016ygrp-sponsor #yiv0455784016ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv0455784016 #yiv0455784016ygrp-sponsor #yiv0455784016ov ul {margin:0;padding:0 0 0 8px;}#yiv0455784016 #yiv0455784016ygrp-text {font-family:Georgia;}#yiv0455784016 #yiv0455784016ygrp-text p {margin:0 0 1em 0;}#yiv0455784016 #yiv0455784016ygrp-text tt {font-size:120%;}#yiv0455784016 #yiv0455784016ygrp-vital ul li:last-child {border-right:none !important;}#yiv0455784016

[Ivan Warren [e-mail] [hercules-390]]

Were you able to actually IPL a system with  qemu-system-s390s? I had
played with it but I was not able to IPL anything with it.

Yes... a s390x debian... It's pretty easy...

--Ivan


[Non-text portions of this message have been removed]

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Nice numbers.

Did you try qemu-system-s390x with any other distro, beside zLinux?
I've a gentoo/s390x running under hercules, ready for a test.

Peppe.

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Hey folks,
I had fun around with yet another z/architecture implementation.... It's
open source, but it is limited to running linux and limited to z/Arch...
It's the qemu s390x emulator which uses a technique called "tcg" (Tiny
Code Generator) - which is a sort of JIT (Just In Time) compiler, which
rely on generating and optimizing machine code from emulated code using
the GCC backend by converting the emulated instructions to INSN (The
intermediate code) and then compiling that code to native code.
It's slightly (significantly) faster than hercules when it comes to
running zLinux...
Here are some of the times I get from compiling hercules itself (same
qemu-system-s390x
real    108m35.287s
user    90m50.142s
sys     16m56.053s
hercules
real    222m33.518s
user    202m52.797s
sys     19m5.514s
Not sure how or if some of those techniques could be applied to hercules
(most problematic I think would be self modifying code) - and qemu s390x
certainly doesn't do SIE...
--Ivan
[Non-text portions of this message have been removed]

[Ivan Warren [e-mail] [hercules-390]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Nice numbers.
Did you try qemu-system-s390x with any other distro, beside zLinux?
I've a gentoo/s390x running under hercules, ready for a test.
Peppe.

I tried with s390x debian... Haven't tried with either SuSe, RH or
gentoo yet (CentOS doesn't have a s390x build).

But it's pretty easy once you get the hang of qemu !

--Ivan



[Non-text portions of this message have been removed]

[Ivan Warren [e-mail] [hercules-390]]

https://wiki.qemu.org/Documentation/Platforms/S390X#TCG_.28non-KVM.29
It looks with version 2.10 (the one available on my gentoos hosting
systems) I'm going to have troubles ;-)
Peppe.

Peppe,

I haven't read that page... But besides setting up networking (which is
the tricky part), it's all straightforward...

- Create an empty disk image using "qemu-img create" (for example :
qemu-img create -f qcow2 DEB002.IMG 16G)
- Obtain a kernel and initrd image for install (from the debian.org website)
- Start qemu.. My start command is as follows - to install s390x debian :

qemu-system-s390x -drive file=DEB002.IMG -kernel kernel.debian -initrd
initrd.debian -m 4G -net nic -net tap,ifname=tap0,script=no -nographic
-accel tcg,thread=multi -smp 12

(That starts a 12 CPU instance with 4G of RAM... Adjust -m and -smp to
whatever you want)

tap0 is a tap network interface (created with : ip tuntap add mode tap
tap0 and then added it to a virtual bridge... use either brctl or
ovs-vsctl if using openvswitch - networking IS the tricky part).

Once the emulator is started - it's just a matter of following the
instructions...

--Ivan



[Non-text portions of this message have been removed]

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

https://wiki.qemu.org/Documentation/Platforms/S390X#TCG_.28non-KVM.29
It looks with version 2.10 (the one available on my gentoos hosting
systems) I'm going to have troubles ;-)
Peppe.

Peppe,
I haven't read that page... But besides setting up networking (which is
the tricky part), it's all straightforward...
qemu-img create -f qcow2 DEB002.IMG 16G)
- Obtain a kernel and initrd image for install (from the debian.org website)
qemu-system-s390x -drive file=DEB002.IMG -kernel kernel.debian -initrd
initrd.debian -m 4G -net nic -net tap,ifname=tap0,script=no -nographic
-accel tcg,thread=multi -smp 12
(That starts a 12 CPU instance with 4G of RAM... Adjust -m and -smp to
whatever you want)
tap0 is a tap network interface (created with : ip tuntap add mode tap
tap0 and then added it to a virtual bridge... use either brctl or
ovs-vsctl if using openvswitch - networking IS the tricky part).
Once the emulator is started - it's just a matter of following the
instructions...

Thanks for taking the time to write down the qemu arguments, Ivan.

This is ALWAYS the tricky part with qemu, for any arhitecture, the
main reason I use it with the help of "libvirt", under x86.

The problem described on the page I posted is related with kernel 4.x,
the kernel gentoo use in our days.

From what I'm reading it looks qemu-2.10 may give troubles with such
a linux kernel.

May I ask which qemu/kernel version you tested?

Peppe.

[Ivan Warren [e-mail] [hercules-390]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Thanks for taking the time to write down the qemu arguments, Ivan.
This is ALWAYS the tricky part with qemu, for any arhitecture, the
main reason I use it with the help of "libvirt", under x86.
The problem described on the page I posted is related with kernel 4.x,
the kernel gentoo use in our days.
From what I'm reading it looks qemu-2.10 may give troubles with such
a linux kernel.
May I ask which qemu/kernel version you tested?

Giuseppe,

Currently using QEMU version 2.11.50 (pulled from github and compiled
myself) and a 4.9.0 debian linux kernel

--Ivan



[Non-text portions of this message have been removed]

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Thanks for taking the time to write down the qemu arguments, Ivan.
This is ALWAYS the tricky part with qemu, for any arhitecture, the
main reason I use it with the help of "libvirt", under x86.
The problem described on the page I posted is related with kernel 4.x,
the kernel gentoo use in our days.
From what I'm reading it looks qemu-2.10 may give troubles with such
a linux kernel.
May I ask which qemu/kernel version you tested?

Giuseppe,
Currently using QEMU version 2.11.50 (pulled from github and compiled
myself) and a 4.9.0 debian linux kernel
--Ivan

Thank you Ivan, I had been able to boot the last
gentoo kernel using libvirt/virsh, with qemu-2.10.

My already defined bridged virtual network works
quite well and I had been able to ssh into the
emulated s390x machine:

Linux netboot 4.14.15-gentoo #1 SMP Sun Jan 28 14:37:52 UTC 2018 s390x GNU/Linux

and the libvirt emulated console seems to work
correctly.

Now I've to figure out how to install gentoo over
a virtio disk, as it looks the gentoo procedure
documented on wiki is for dasd, under the hercules
emulator, the one I already use.

Not sure if zipl is the way to go to get qemu
to IPL from a virtio-ccw disk.

May I ask if your debian use zipl and eventualy for
your /etc/zipl.conf file?

Peppe.

[Non-text portions of this message have been removed]

[Ivan Warren [e-mail] [hercules-390]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Now I've to figure out how to install gentoo over
a virtio disk, as it looks the gentoo procedure
documented on wiki is for dasd, under the hercules
emulator, the one I already use.
Not sure if zipl is the way to go to get qemu
to IPL from a virtio-ccw disk.
May I ask if your debian use zipl and eventualy for
your /etc/zipl.conf file?

That's what my /etc/zipl.conf looks like :

# cat /etc/zipl.conf
[defaultboot]
defaultmenu = menu

:menu
target = /boot
1 = debian
2 = old
default = 1
prompt = 1
timeout = 10

[debian]
target = /boot
image = /boot/vmlinuz
ramdisk = /boot/initrd.img
parameters = root=UUID=13763378-7dd3-4417-b148-3d9ba5f55279

[old]
target = /boot
image = /boot/vmlinuz.old
ramdisk = /boot/initrd.img.old
parameters = root=UUID=13763378-7dd3-4417-b148-3d9ba5f55279
optional = 1

*****************

That doesn't help much so ...

# blkid
/dev/vda1: UUID="13763378-7dd3-4417-b148-3d9ba5f55279" TYPE="ext4"
PARTUUID="534c4323-591f-4ec2-91a2-9cbc21a393e8"
/dev/vda2: UUID="86886b4b-2d15-4de5-90b5-0e944e5bf3b6" TYPE="swap"
PARTUUID="a3bcf764-02dd-4370-91af-ad994ccb64a3"

******************

So what is /dev/vda ?

/# find /sys -name 'vda*'
/sys/devices/css0/0.0.0001/0.0.0001/virtio1/block/vda
/sys/devices/css0/0.0.0001/0.0.0001/virtio1/block/vda/vda2
/sys/devices/css0/0.0.0001/0.0.0001/virtio1/block/vda/vda1
/sys/class/block/vda2
/sys/class/block/vda1
/sys/class/block/vda
/sys/fs/ext4/vda1
/sys/block/vda

*****************

lsmod shows :
# lsmod
Module                  Size  Used by
aes_s390               20480  0
des_s390               16384  0
des_generic            28672  1 des_s390
sha_common             16384  0
ip_tables              28672  0
x_tables               32768  1 ip_tables
autofs4                53248  2
ext4                  692224  1
crc16                  16384  1 ext4
jbd2                  126976  1 ext4
crc32c_generic         16384  2
fscrypto               28672  1 ext4
ecb                    16384  0
mbcache                16384  2 ext4
virtio_blk             24576  3
virtio_net             40960  0

(I suspect virtio_blk is the driver for the paravirtualized disk)

*****************

If you need further info and/or privileged access to a sandbox, just ask
off list !

--Ivan


[Non-text portions of this message have been removed]

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Now I've to figure out how to install gentoo over
a virtio disk, as it looks the gentoo procedure
documented on wiki is for dasd, under the hercules
emulator, the one I already use.
Not sure if zipl is the way to go to get qemu
to IPL from a virtio-ccw disk.
May I ask if your debian use zipl and eventualy for
your /etc/zipl.conf file?

# cat /etc/zipl.conf
[defaultboot]
defaultmenu = menu
:menu
target = /boot
1 = debian
2 = old
default = 1
prompt = 1
timeout = 10
[debian]
target = /boot
image = /boot/vmlinuz
ramdisk = /boot/initrd.img
parameters = root=UUID=13763378-7dd3-4417-b148-3d9ba5f55279
[old]
target = /boot
image = /boot/vmlinuz.old
ramdisk = /boot/initrd.img.old
parameters = root=UUID=13763378-7dd3-4417-b148-3d9ba5f55279
optional = 1
*****************
That doesn't help much so ...
# blkid
/dev/vda1: UUID="13763378-7dd3-4417-b148-3d9ba5f55279" TYPE="ext4"
PARTUUID="534c4323-591f-4ec2-91a2-9cbc21a393e8"
/dev/vda2: UUID="86886b4b-2d15-4de5-90b5-0e944e5bf3b6" TYPE="swap"
PARTUUID="a3bcf764-02dd-4370-91af-ad994ccb64a3"
******************
So what is /dev/vda ?
/# find /sys -name 'vda*'
/sys/devices/css0/0.0.0001/0.0.0001/virtio1/block/vda
/sys/devices/css0/0.0.0001/0.0.0001/virtio1/block/vda/vda2
/sys/devices/css0/0.0.0001/0.0.0001/virtio1/block/vda/vda1
/sys/class/block/vda2
/sys/class/block/vda1
/sys/class/block/vda
/sys/fs/ext4/vda1
/sys/block/vda
*****************
# lsmod
Module                  Size  Used by
aes_s390               20480  0
des_s390               16384  0
des_generic            28672  1 des_s390
sha_common             16384  0
ip_tables              28672  0
x_tables               32768  1 ip_tables
autofs4                53248  2
ext4                  692224  1
crc16                  16384  1 ext4
jbd2                  126976  1 ext4
crc32c_generic         16384  2
fscrypto               28672  1 ext4
ecb                    16384  0
mbcache                16384  2 ext4
virtio_blk             24576  3
virtio_net             40960  0
(I suspect virtio_blk is the driver for the paravirtualized disk)
*****************
If you need further info and/or privileged access to a sandbox, just ask
off list !
--Ivan

Thank your for the info, Ivan, very kind of you.

The problem I'm currently facing, with the gentoo
kernel/initrd, is that kernel doesn't seems to recognize
partitions on /dev/vda, although they are on disk
(created from another box, as fdisk on gentoo
initrd seems not functional).

You are correct, virtio_blk is the linux virtio
module and infact the disk itself is available
(and functional) on /dev/vda, but partions doesn't show up
and they are not accessible (with mknod created /dev/vdaN).

This may be a Gentoo kernel specific problem,
I'll do a test from debian, to get an idea of
how things should look.

But this message from the kernel:

The s390-virtio transport is deprecated. Please switch to a modern host
providing virtio-ccw

is weird.

At virsh level I asked qemu to start

<os>
<type arch='s390x' machine='s390-ccw-virtio-2.10'>hvm</type>
<kernel>/tmp/netboot-s390x-kernel-20180128T101221Z</kernel>
<initrd>/tmp/netboot-s390x-initramfs-20180128T101221Z</initrd>
<boot dev='hd'/>
</os>

which seeems what the kernel is looking for, isn't?

This thread

http://debian.2.n7.nabble.com/specifying-virtio-block-device-as-root-filesystem-for-Debin-S390X-install-td3683385.html

point in the same direction for the Debian kernel.

Thanks again, Ivan.

Peppe.

[Non-text portions of this message have been removed]

[Ivan Warren [e-mail] [hercules-390]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Thank your for the info, Ivan, very kind of you.
The problem I'm currently facing, with the gentoo
kernel/initrd, is that kernel doesn't seems to recognize
partitions on /dev/vda, although they are on disk
(created from another box, as fdisk on gentoo
initrd seems not functional).

Peppe,

I'm curious as to why fdisk wouldn't work on gentoo. The question is :
What form of partitioning is on the disk (gpt, msdos ?)

Apparently the gentoo dasd driver didn't recognize the partitionning
format/table (what shows in /sys/block ?)

The thing is that you can't take a hercules CKD (or CCKD) file and use
it directly on qemu. If you don't specify the file format to qemu, it
will assume it is a 'raw' file and it won't recognize any of the
internal AWS DASD structures used by hercules.

An exception if you were to wish to use under qemu a dasd created under
hercules would be to use a flat FBA file

--Ivan



[Non-text portions of this message have been removed]

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Thank your for the info, Ivan, very kind of you.
The problem I'm currently facing, with the gentoo
kernel/initrd, is that kernel doesn't seems to recognize
partitions on /dev/vda, although they are on disk
(created from another box, as fdisk on gentoo
initrd seems not functional).

Peppe,
What form of partitioning is on the disk (gpt, msdos ?)

The fdisk that is on gentoo-s390x initrd doesn't work because,
for what I can see, some shared lib is not present on the gentoo
s390x initrd. The fdisk on the gentoo-s390x stage3 works as expected.

This is probably due to the fact that gentoo is assumed to be
installed over a dasd (with dasdfmt) and not over a virtio
disk, with fdisk. Nobody apparently care to put on the gentoo
initrd tools that are not used for the installing gentoo :-)

But this doesn't matter, I partitioned the qcow2 disk from
an already installed kvm/qemu x86 virtual machine.

But the gentoo s390x kernel doesn't see them, where the x86
gentoo does.

I've still to check what Debian do, this may depends from
how the gentoo installation kernel has been configured.

Another problem come, I guess, from the qemu-system-s390 I've
installed on my gentoo host.

It looks that beside the "-smp N" argument of qemu, I always
see just one processor, beside starting qemu from command line
(with the same syntax you used) or from libvirt.

I also get a weird message about MTTG not supported from qemu when
I use "-accel tcg,thread=multi" (that "multi" is the problem).

It looks we are testing different version of qemu and
in this case the version differences really matter.

Peppe.

[Non-text portions of this message have been removed]

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Thank your for the info, Ivan, very kind of you.
The problem I'm currently facing, with the gentoo
kernel/initrd, is that kernel doesn't seems to recognize
partitions on /dev/vda, although they are on disk
(created from another box, as fdisk on gentoo
initrd seems not functional).

Peppe,
What form of partitioning is on the disk (gpt, msdos ?)

The fdisk that is on gentoo-s390x initrd doesn't work because,
for what I can see, some shared lib is not present on the gentoo
s390x initrd. The fdisk on the gentoo-s390x stage3 works as expected.
This is probably due to the fact that gentoo is assumed to be
installed over a dasd (with dasdfmt) and not over a virtio
disk, with fdisk. Nobody apparently care to put on the gentoo
initrd tools that are not used for the installing gentoo :-)
But this doesn't matter, I partitioned the qcow2 disk from
an already installed kvm/qemu x86 virtual machine.
But the gentoo s390x kernel doesn't see them, where the x86
gentoo does.
I've still to check what Debian do, this may depends from
how the gentoo installation kernel has been configured.
Another problem come, I guess, from the qemu-system-s390 I've
installed on my gentoo host.
It looks that beside the "-smp N" argument of qemu, I always
see just one processor, beside starting qemu from command line
(with the same syntax you used) or from libvirt.
I also get a weird message about MTTG not supported from qemu when
I use "-accel tcg,thread=multi" (that "multi" is the problem).
It looks we are testing different version of qemu and
in this case the version differences really matter.
Peppe.

Ok, the partitions problem is easy to solve,
partx is working from the gentoo installation initrd
and the command "partx -u - /dev/vda" do the trick
of asking the kernel to update the in-kernel copy
of partition tables.

That is a job normally udevd do automatically in our
days, unfortunately the gentoo initrd s390x installation
ramdisk doesn't start udevd ;-) And, ifact, the debian
initrd, which starts udevd, can see virtio partitions
without problems.

At the end, from the gentoo-s390x initrd, this couple
of commands:

modprobe virtio_blk
partx -u - /dev/vda

give access to a prepartitioned virtio disk, which
should be enough to install gentoo-s390x, following the
documented Wiki procedure (for anyone interested,
I guess a singleton set which basically contains {me} ;-) ),
under qemu-system-s390x (2.10 in my case).

What is left is the uniprocessor configuration, which,
I guess, depends from the qemu version.

Now, with the help you gave me, Ivan, I think I'm in the position
of installing a qemu-s390x gentoo.

Thank you so much, Peppe.

[Non-text portions of this message have been removed]

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Thank your for the info, Ivan, very kind of you.
The problem I'm currently facing, with the gentoo
kernel/initrd, is that kernel doesn't seems to recognize
partitions on /dev/vda, although they are on disk
(created from another box, as fdisk on gentoo
initrd seems not functional).

Peppe,
What form of partitioning is on the disk (gpt, msdos ?)

The fdisk that is on gentoo-s390x initrd doesn't work because,
for what I can see, some shared lib is not present on the gentoo
s390x initrd. The fdisk on the gentoo-s390x stage3 works as expected.
This is probably due to the fact that gentoo is assumed to be
installed over a dasd (with dasdfmt) and not over a virtio
disk, with fdisk. Nobody apparently care to put on the gentoo
initrd tools that are not used for the installing gentoo :-)
But this doesn't matter, I partitioned the qcow2 disk from
an already installed kvm/qemu x86 virtual machine.
But the gentoo s390x kernel doesn't see them, where the x86
gentoo does.
I've still to check what Debian do, this may depends from
how the gentoo installation kernel has been configured.
Another problem come, I guess, from the qemu-system-s390 I've
installed on my gentoo host.
It looks that beside the "-smp N" argument of qemu, I always
see just one processor, beside starting qemu from command line
(with the same syntax you used) or from libvirt.
I also get a weird message about MTTG not supported from qemu when
I use "-accel tcg,thread=multi" (that "multi" is the problem).
It looks we are testing different version of qemu and
in this case the version differences really matter.
Peppe.

Ok, the partitions problem is easy to solve,
partx is working from the gentoo installation initrd
and the command "partx -u - /dev/vda" do the trick
of asking the kernel to update the in-kernel copy
of partition tables.
That is a job normally udevd do automatically in our
days, unfortunately the gentoo initrd s390x installation
ramdisk doesn't start udevd ;-) And, ifact, the debian
initrd, which starts udevd, can see virtio partitions
without problems.
At the end, from the gentoo-s390x initrd, this couple
modprobe virtio_blk
partx -u - /dev/vda
give access to a prepartitioned virtio disk, which
should be enough to install gentoo-s390x, following the
documented Wiki procedure (for anyone interested,
I guess a singleton set which basically contains {me} ;-) ),
under qemu-system-s390x (2.10 in my case).
What is left is the uniprocessor configuration, which,
I guess, depends from the qemu version.
Now, with the help you gave me, Ivan, I think I'm in the position
of installing a qemu-s390x gentoo.
Thank you so much, Peppe.

Well, gentoo installation s390x kernel hasn't CONFIG_MSDOS_PARTITION
set ... of course ... that the reason why doesn't update by itself
the in-kernel partitions map. It has been built to IPL from a DASD
image ONLY or from the netboot images ;-)

Almost there ... Peppe.

[Non-text portions of this message have been removed]

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Well, gentoo installation s390x kernel hasn't CONFIG_MSDOS_PARTITION
set ... of course ... that the reason why doesn't update by itself
the in-kernel partitions map. It has been built to IPL from a DASD
image ONLY or from the netboot images ;-)
Almost there ... Peppe.

I'm there ;-)

gentoo-s390x is up and running as a qemu-system-s390x 2.10 emulated
system, uniprocessor only, as a guest of my gentoo-x86_64 hardware
desktop, managed by libvirtd, through the virsh interface (bridged
networking).

The only drawback, beside the uniprocessor-only configuration,
came again from qemu-2.10 (I guess). It doesn't handle nicely
to IPL using the zipl boot loader from a virtio disk, at least
when started from libvirtd. Weird enough zipl boot loader boots
correctly if I start "qemu" from command line ;-(

qemy-system-s390x hangs (it really hangs, it stops somewhere
after starting) when I try to boot from a virtio disk using the
zipl boot loader, asking libvirtd to spawn qemy-system-s390x
(if anyone has any idea about this problem, it is really welcome
to join my efforts).

It boots correctly if qemu reads the very same kernel from the linux
guest filesystem. Once the kernel is loaded the virtio disk
works as expected.

Beside that, everything seems to work nicely, I've now ahead
the usual gentoo "emerge war" which is familiar to any gentoo
user, on any architecture.

Peppe.

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Well, gentoo installation s390x kernel hasn't CONFIG_MSDOS_PARTITION
set ... of course ... that the reason why doesn't update by itself
the in-kernel partitions map. It has been built to IPL from a DASD
image ONLY or from the netboot images ;-)
Almost there ... Peppe.

I'm there ;-)
gentoo-s390x is up and running as a qemu-system-s390x 2.10 emulated
system, uniprocessor only, as a guest of my gentoo-x86_64 hardware
desktop, managed by libvirtd, through the virsh interface (bridged
networking).
The only drawback, beside the uniprocessor-only configuration,
came again from qemu-2.10 (I guess). It doesn't handle nicely
to IPL using the zipl boot loader from a virtio disk, at least
when started from libvirtd. Weird enough zipl boot loader boots
correctly if I start "qemu" from command line ;-(
qemy-system-s390x hangs (it really hangs, it stops somewhere
after starting) when I try to boot from a virtio disk using the
zipl boot loader, asking libvirtd to spawn qemy-system-s390x
(if anyone has any idea about this problem, it is really welcome
to join my efforts).
It boots correctly if qemu reads the very same kernel from the linux
guest filesystem. Once the kernel is loaded the virtio disk
works as expected.
Beside that, everything seems to work nicely, I've now ahead
the usual gentoo "emerge war" which is familiar to any gentoo
user, on any architecture.
Peppe.

For anyone interested, problems came from qemu-2.10. Now Gentoo has
a stable version of qemu-2.11. With version 2.11, multiprocessor
(manually adding "-accel tcg,thread=multi" through virsh) and zipl,
work as Ivan verified, with qemu-system-s390x spawned by libvirtd.

My test gentoo-s390x emulated system under a real gentoo-x86_64
seems to run nicely with 4 virtual CPU:

vendor_id : IBM/S390
# processors : 4
bogomips per cpu: 13370.00
max thread id : 0
features : esan3 zarch highgprs
facilities : 0 1 2
processor 0: version = 00, identification = 000000, machine = 2064
processor 1: version = 00, identification = 400000, machine = 2064
processor 2: version = 00, identification = 800000, machine = 2064
processor 3: version = 00, identification = C00000, machine = 2064

Thanks for your help, Ivan!

Peppe.

[Ivan Warren [e-mail] [hercules-390]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
May I ask if your debian use zipl and eventualy for

Also on a side note :

I've also IPLed a much later version : Linux deb002 4.14.0-3-s390x #1
SMP Debian 4.14.13-1 (2018-01-14) s390x GNU/Linux

And it works fine !

--Ivan



[Non-text portions of this message have been removed]