Merge tag 'pull-request-2024-10-23' of https://gitlab.com/thuth/qemu into staging

* Allow multiple boot devices (via bootindex properties) on s390x
* Avoid TEXTREL relocations in the s390-ccw.img fi

Merge tag 'pull-request-2024-10-23' of https://gitlab.com/thuth/qemu into staging

* Allow multiple boot devices (via bootindex properties) on s390x
* Avoid TEXTREL relocations in the s390-ccw.img firmware

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmcY9vsRHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbWnBQ//eM0RPHgp3OCbCy42HYp569RdHvXE69BS
# 7iO8uu7MGRKIAHJqqmDwFDfhfMtoJkfjq9bQpb+pmIUe50r2NAC9na9+bjIc2bK+
# sxHvS5PTZiQcPOiGwAmp3lEheFPWi6sugYVruO+6syGLJdoa39Vnj71pF86lJ6dk
# HFltOqa0lG3YWzueKXInLQnpRaIvPzjJVEUuNRk5H6ai0woItWvrPK82HMcKXSu5
# mwJiGP2dmwvZw3nC8GsNKbxxZNc2gEM6tFFozbsaE/Yfzmg/S4kHexzjSGd7svT7
# kex65F9aqiK3x1WrWwuCCU6D8qEkNqzXezNlmedvgcMokkdd8Xwlqvw2Ng3sbF7i
# 466jEdq0CuAiEhO6AvSYrEDpI8trWxj4EtxcjfqltUVR/SYFcW9hRdx99VwrRCo2
# woazKmHz7Hu6uS5+JPtfD+KxalIDXNXevY6uGyaWJp8TahDkUCim/gJ+Zb7Mx1iq
# Vrx/rCm1oV8v1xrn8NWTGewA8emVjbLI3PuDtPh9FWRpER7ekn+dDUinzeUl2wWK
# +USqIE2ougo1etRm7FAkyWEv9F/GjGTd8OegIGD6etWBNBq/YVMNwX1gjw4Q0qhM
# +7KmXLBKkuEBYSo4scSGt6DcasIUL93sc6rnWgiH3S/qMAYyKempKPkoROYQI8yA
# 0EI+x1fxW1w=
# =mWW5
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 23 Oct 2024 14:15:39 BST
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5

* tag 'pull-request-2024-10-23' of https://gitlab.com/thuth/qemu: (23 commits)
pc-bios/s390-ccw: Update s390-ccw.img with the full boot order support feature
pc-bios/s390-ccw: Introduce `EXTRA_LDFLAGS`
pc-bios/s390-ccw: Don't generate TEXTRELs
pc-bios/s390-ccw: Clarify alignment is in bytes
tests/qtest: Add s390x boot order tests to cdrom-test.c
docs/system: Update documentation for s390x IPL
pc-bios/s390x: Enable multi-device boot loop
s390x: Rebuild IPLB for SCSI device directly from DIAG308
hw/s390x: Build an IPLB for each boot device
s390x: Add individual loadparm assignment to CCW device
include/hw/s390x: Add include files for common IPL structs
pc-bios/s390-ccw: Enable failed IPL to return after error
pc-bios/s390-ccw: Remove panics from Netboot IPL path
pc-bios/s390-ccw: Remove panics from DASD IPL path
pc-bios/s390-ccw: Remove panics from SCSI IPL path
pc-bios/s390-ccw: Remove panics from ECKD IPL path
pc-bios/s390-ccw: Remove panics from ISO IPL path
docs/system/s390x/bootdevices: Update the documentation about network booting
pc-bios/s390-ccw: Merge netboot.mak into the main Makefile
hw/s390x: Remove the possibility to load the s390-netboot.img binary
...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...

pc-bios/s390-ccw: Enable failed IPL to return after error

Remove panic-on-error from IPL functions such that a return code is propagated
back to the main IPL calling function (rather than terminatin

pc-bios/s390-ccw: Enable failed IPL to return after error

Remove panic-on-error from IPL functions such that a return code is propagated
back to the main IPL calling function (rather than terminating immediately),
which facilitates possible error recovery in the future.

A select few panics remain, which indicate fatal non-devices errors that must
result in termination.

Signed-off-by: Jared Rossi <jrossi@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20241020012953.1380075-13-jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

pc-bios/s390-ccw: Remove panics from SCSI IPL path

Remove panic-on-error from virtio-scsi IPL specific functions so that error
recovery may be possible in the future.

Functions that would previousl

pc-bios/s390-ccw: Remove panics from SCSI IPL path

Remove panic-on-error from virtio-scsi IPL specific functions so that error
recovery may be possible in the future.

Functions that would previously panic now provide a return code.

Signed-off-by: Jared Rossi <jrossi@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20241020012953.1380075-10-jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

pc-bios/s390-ccw: Use the libc from SLOF and remove sclp prints

We are already using the libc from SLOF for the s390-netboot.img, and
this libc implementation is way more complete and accurate than

pc-bios/s390-ccw: Use the libc from SLOF and remove sclp prints

We are already using the libc from SLOF for the s390-netboot.img, and
this libc implementation is way more complete and accurate than the
simple implementation that we currently use for the s390-ccw.img binary.
Since we are now always assuming that the SLOF submodule is available
when building the s390-ccw bios (see commit bf6903f6944f), we can drop
the simple implementation and use the SLOF libc for the s390-ccw.img
binary, too.

Additionally replace sclp_print calls with puts/printf now that it is
available.

Co-authored by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Jared Rossi <jrossi@linux.ibm.com>
Message-ID: <20241020012953.1380075-3-jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

Merge tag 'pull-request-2023-06-29' of https://gitlab.com/thuth/qemu into staging

* Fix a compilation issue in the s390-ccw bios with Clang + binutils 2.40
* Create an initial stack frame for the ma

Merge tag 'pull-request-2023-06-29' of https://gitlab.com/thuth/qemu into staging

* Fix a compilation issue in the s390-ccw bios with Clang + binutils 2.40
* Create an initial stack frame for the main() function of the s390-ccw bios
* Clean up type definitions in the s390-ccw bios

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmSd1MwRHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbUNAg//aO7pkzKPIUXG/g8PSzzgjYu9bDTketrQ
# P08wk1jj9CQMLN6dcnVnmzPhC4EqyrZqMYvRH4qFPLJmi0m+Jq3fEEkVzKbI3baO
# 0qQX6DNJVLn6qcgvZ8+ZjkLmuWn/lN4+MH92vdUgpkCcj5y7FB4FjoaG+Z0yZxsS
# YI6gG8D/i6fnq0zsKGMzmzHCswmN4s9qnY9a4nLV0YeMnrZJjUmUUKomWv0FP5jM
# qtLf6pRtgR4u/WD9ktwjISlOn7AKQeCYgZcMu1kBnrSWDjhLytUrv8h2JqRxGOap
# nRtdFzTvgeWKJbCX9v+XLb1bqzFj/LLgoCRzUOqV1CdBKf3JycIXyLMpTJ1+kV4J
# NnzCjnfq/LSDwwCjeg3cRBUFjGkuHBZwQzBh5m4xXBqae07UhMGpWBmhIh7qgPy2
# RXox0xK8Ot/vhYxtNojOiEW0Wp4KJElB9Wxn1Vz0kX4OXRcxHu9CDazZXTKBuBGA
# YWZ9HbsquvwNMV5pgCuXzVWW3FCzrhGgtVYREwYyBIInJaEGCWKCyMAuDXb4fkWL
# eS0Mryp3AMaJ6CidK2ELWygMkKA8xDF8pKm5jgQWRhs5jirydi1B4hPeGFsm1vUI
# TYs08XuC9p66O2Ffn2Sc/uAXbe/FQ7Ce6EbGUUetpafo9FxPhbP28hPUhkcHt68Y
# tmGzqAuwgxc=
# =oWSq
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 29 Jun 2023 09:00:28 PM CEST
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [undefined]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [undefined]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5

* tag 'pull-request-2023-06-29' of https://gitlab.com/thuth/qemu:
pc-bios: Update the s390 bios images with the recent changes
pc-bios/s390-ccw: Don't use __bss_start with the "larl" instruction
pc-bios/s390-ccw: Move the stack array into start.S
pc-bios/s390-ccw: Provide space for initial stack frame in start.S
pc-bios/s390-ccw: Fix indentation in start.S
pc-bios/s390-ccw/Makefile: Use -z noexecstack to silence linker warning
pc-bios/s390-ccw: Get rid of the the __u* types
s390-ccw: Getting rid of ulong

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

show more ...

s390-ccw: Getting rid of ulong

Any good reason why this still exist?
I can understand u* and __u* to be linux kernel like, but ulong?

Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Juan

s390-ccw: Getting rid of ulong

Any good reason why this still exist?
I can understand u* and __u* to be linux kernel like, but ulong?

Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Message-Id: <20230629104821.194859-2-thuth@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

Merge tag 'pull-request-2022-08-08' of https://gitlab.com/thuth/qemu into staging

* Fix booting in the s390-ccw bios when physical and logical block sizes differ
* Fix the replay-linux avocado test

Merge tag 'pull-request-2022-08-08' of https://gitlab.com/thuth/qemu into staging

* Fix booting in the s390-ccw bios when physical and logical block sizes differ
* Fix the replay-linux avocado test
* Relax a time constraint in iotest 264

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmLwmJsRHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbUuaw//XGlKYzjKHEsmSGGuwSEF/iW7BvHf8lAn
# X2loC7Fd1WzEoq1EX/s5jd/4+ZUVxDP4F2wO9Hzhi7GpEfd/Cr5cu3TPwWCGjQT8
# g6UFVPPzHeVU68GxQX6ufBAPk7Lc9S57GHZ9n4tzcN7Jvp63zAXEFXe4lVLnAmzJ
# ykDz1Ir1bCDEl1AIbVp1umpIAh4MkbY1XfZeXWRkbGtQolH1y/F6sZWw3i72G30b
# JOM1pmu89KjnxWPoz1J142jOx53/XpSSlrqpFeqieykbU59rilBTIwi+k7K0KMOd
# 0DbrPDuU0EQ7JRkWzAlTT/IfNPbQB5gOjw6zFr+0L5S+3LcPM/p8XszNk4j3XQWt
# Bps3HDU13LDQpydRyZajY4iCQl6tzBDVXCoY+LUgrYjkP6OM5UpbakZgXJWNw9Nu
# Juu3kQ7imtLtMlKZQGSvhsy6gyUXjVlZxTZFspTQsMoOp/BDZdIwG+mKxk786hgr
# 32RxingXv6SWFYS+zrKsRJePtleLJr/RcySZFHNboJt9RIGf6W/IdROEjgZeYLce
# QDnlfi6AbwnP37nWmah5Iu2PeoZwDgr3jL81otdWlU8bc7G+gjwrnN/E77y3jJvH
# Auhj9YBNttQH6O8L4juMaD9+8/KtO47FfVfXojmPoicEB9NeWLChlUovVz47LC/U
# olsgxmuoDac=
# =JZmF
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 07 Aug 2022 10:01:15 PM PDT
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [undefined]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [undefined]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5

* tag 'pull-request-2022-08-08' of https://gitlab.com/thuth/qemu:
tests/qemu-iotests/264: Allow up to 5s for the BLOCK_JOB_CANCEL event to arrive
tests/avocado: fix replay-linux test
pc-bios/s390-ccw: Update the s390-ccw.img with the block size fix
pc-bios/s390-ccw: Fix booting with logical block size < physical block size

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

show more ...

pc-bios/s390-ccw: Fix booting with logical block size < physical block size

For accessing single blocks during boot, it's the logical block size that
matters. (Physical block sizes are rather intere

pc-bios/s390-ccw: Fix booting with logical block size < physical block size

For accessing single blocks during boot, it's the logical block size that
matters. (Physical block sizes are rather interesting e.g. for creating
file systems with the correct alignment for speed reasons etc.).
So the s390-ccw bios has to use the logical block size for calculating
sector numbers during the boot phase, the "physical_block_exp" shift
value must not be taken into account. This change fixes the boot process
when the guest hast been installed on a disk where the logical block size
differs from the physical one, e.g. if the guest has been installed
like this:

qemu-system-s390x -nographic -accel kvm -m 2G \
-drive if=none,id=d1,file=fedora.iso,format=raw,media=cdrom \
-device virtio-scsi -device scsi-cd,drive=d1 \
-drive if=none,id=d2,file=test.qcow2,format=qcow2
-device virtio-blk,drive=d2,physical_block_size=4096,logical_block_size=512

Linux correctly uses the logical block size of 512 for the installation,
but the s390-ccw bios tries to boot from a disk with 4096 block size so
far, as long as this patch has not been applied yet (well, it used to work
by accident in the past due to the virtio_assume_scsi() hack that used to
enforce 512 byte sectors on all virtio-block disks, but that hack has been
well removed in commit 5447de2619050a0a4d to fix other scenarios).

Fixes: 5447de2619 ("pc-bios/s390-ccw/virtio-blkdev: Remove virtio_assume_scsi()")
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2112303
Message-Id: <20220805094214.285223-1-thuth@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

Merge tag 'pull-request-2022-07-07' of https://gitlab.com/thuth/qemu into staging

* Check validity of the address in the SET PREFIX instruction
* Fix booting from devices that use 4k sectors, but ar

Merge tag 'pull-request-2022-07-07' of https://gitlab.com/thuth/qemu into staging

* Check validity of the address in the SET PREFIX instruction
* Fix booting from devices that use 4k sectors, but are not like DASDs
* Re-evaluate pending interrupts after EXECUTE of certain instructions

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmLGhkURHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbU76Q//Y4mEXxWZDpJTg7tL5SZP+UzBVttnCifv
# 6q+2I0keOUs6wFhPq8TzBqkazT9wlv51cNrY2Q3fU9I3dpDeRbAXZR34UD4kw5an
# Q+ZQcebuGSKLjzMrIb1DLAieq8OmZR5FvDUu16BbeJr6GIQIE80lMRfWh9j30UfW
# tlxkXr15BnyPx6m0rSGwzkZD2vgfj5zSUrDtYJcUsfypIA9OOBMA7yNGNlO+d94V
# UZiKgNQtAoBNm4hZh2M86nsUtem+WpMTZQnDnCpMLYvFV/u9jRQBFSR+Ay41hcEN
# WYuLK61rkjc9gPWSjeNNT28x8RMvFJU4YNn1UDiMRSzrigxeui6MOW3SI/h3y6tI
# 94yXmXV2IuDMibvOjK07nkDaEItqPxfj6zuM2xW1Nc+l8Sk12korFBpk/AZiD0Jo
# R3u36efci3zNqDRDJvhGUv8sGcv0mwO7Agq1Bm3h5941gYwzQKILHCShL7DPzvQa
# h+K1MsT7vWfh5++unkGUrN/Zd9CazEylbDuWtywK8lgQcTGDO/9rab8GeXfH/5es
# Tp0RGJwxmalgrAHZPK9lqgpQaGw92ct2G5odvc82EXQhgccnN9mh54BHPfdKs95E
# JZVrXtZH3Gtgl5MGZ+yJevWSc9h1iRnRF4a7QC3UlVBjA/9yAWzQUAnNGZOamE/s
# F+pi89oWLn8=
# =UsTi
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 07 Jul 2022 12:37:49 PM +0530
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [undefined]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [undefined]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5

* tag 'pull-request-2022-07-07' of https://gitlab.com/thuth/qemu:
target/s390x: Exit tb after executing ex_value
target/s390x: Remove DISAS_PC_STALE_NOCHAIN
target/s390x: Remove DISAS_PC_STALE
target/s390x: Remove DISAS_GOTO_TB
pc-bios/s390-ccw: Update the s390-ccw bios binaries with the virtio-blk fixes
pc-bios/s390-ccw/netboot.mak: Ignore Clang's warnings about GNU extensions
pc-bios/s390-ccw/virtio: Remove "extern" keyword from prototypes
pc-bios/s390-ccw/virtio-blkdev: Request the right feature bits
pc-bios/s390-ccw: Split virtio-scsi code from virtio_blk_setup_device()
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
pc-bios/s390-ccw/virtio-blkdev: Remove virtio_assume_scsi()
pc-bios/s390-ccw/virtio-blkdev: Simplify/fix virtio_ipl_disk_is_valid()
pc-bios/s390-ccw/bootmap: Improve the guessing logic in zipl_load_vblk()
pc-bios/s390-ccw/virtio: Introduce a macro for the DASD block size
pc-bios/s390-ccw: Add a proper prototype for main()
target/s390x/tcg: SPX: check validity of new prefix

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

show more ...

pc-bios/s390-ccw/virtio-blkdev: Request the right feature bits

The virtio-blk code uses the block size and geometry fields in the
config area. According to the virtio-spec, these have to be negotiat

pc-bios/s390-ccw/virtio-blkdev: Request the right feature bits

The virtio-blk code uses the block size and geometry fields in the
config area. According to the virtio-spec, these have to be negotiated
with the right feature bits during initialization, otherwise they
might not be available. QEMU is so far very forgiving and always
provides them, but we should not rely on this behavior, so let's
better request them properly via the VIRTIO_BLK_F_GEOMETRY and
VIRTIO_BLK_F_BLK_SIZE feature bits.

Message-Id: <20220704111903.62400-11-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

pc-bios/s390-ccw: Split virtio-scsi code from virtio_blk_setup_device()

The next patch is going to add more virtio-block specific code to
virtio_blk_setup_device(), and if the virtio-scsi code is al

pc-bios/s390-ccw: Split virtio-scsi code from virtio_blk_setup_device()

The next patch is going to add more virtio-block specific code to
virtio_blk_setup_device(), and if the virtio-scsi code is also in
there, this is more cumbersome. And the calling function virtio_setup()
in main.c looks at the device type already anyway, so it's more
logical to separate the virtio-scsi stuff into a new function in
virtio-scsi.c instead.

Message-Id: <20220704111903.62400-10-thuth@redhat.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

pc-bios/s390-ccw/virtio-blkdev: Remove virtio_assume_scsi()

The virtio_assume_scsi() function is very questionable: First, it
is only called for virtio-blk, and not for virtio-scsi, so the naming
is

pc-bios/s390-ccw/virtio-blkdev: Remove virtio_assume_scsi()

The virtio_assume_scsi() function is very questionable: First, it
is only called for virtio-blk, and not for virtio-scsi, so the naming
is already quite confusing. Second, it is called if we detected a
"invalid" IPL disk, trying to fix it by blindly setting a sector
size of 512. This of course won't work in most cases since disks
might have a different sector size for a reason.

Thus let's remove this strange function now. The calling code can
also be removed completely, since there is another spot in main.c
that does "IPL_assert(virtio_ipl_disk_is_valid(), ...)" to make
sure that we do not try to IPL from an invalid device.

Message-Id: <20220704111903.62400-6-thuth@redhat.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

pc-bios/s390-ccw/virtio-blkdev: Simplify/fix virtio_ipl_disk_is_valid()

The s390-ccw bios fails to boot if the boot disk is a virtio-blk
disk with a sector size of 4096. For example:

dasdfmt -b 40

pc-bios/s390-ccw/virtio-blkdev: Simplify/fix virtio_ipl_disk_is_valid()

The s390-ccw bios fails to boot if the boot disk is a virtio-blk
disk with a sector size of 4096. For example:

dasdfmt -b 4096 -d cdl -y -p -M quick /dev/dasdX
fdasd -a /dev/dasdX
install a guest onto /dev/dasdX1 using virtio-blk
qemu-system-s390x -nographic -hda /dev/dasdX1

The bios then bails out with:

! Cannot read block 0 !

Looking at virtio_ipl_disk_is_valid() and especially the function
virtio_disk_is_scsi(), it does not really make sense that we expect
only such a limited disk geometry (like a block size of 512) for
our boot disks. Let's relax the check and allow everything that
remotely looks like a sane disk.

Message-Id: <20220704111903.62400-5-thuth@redhat.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

pc-bios/s390-ccw/virtio: Introduce a macro for the DASD block size

Use VIRTIO_DASD_DEFAULT_BLOCK_SIZE instead of the magic value 4096.

Message-Id: <20220704111903.62400-3-thuth@redhat.com>
Reviewed

pc-bios/s390-ccw/virtio: Introduce a macro for the DASD block size

Use VIRTIO_DASD_DEFAULT_BLOCK_SIZE instead of the magic value 4096.

Message-Id: <20220704111903.62400-3-thuth@redhat.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

Merge remote-tracking branch 'remotes/huth-gitlab/tags/pull-request-2020-10-06' into staging

* Don't stop at the first unbootable device, continue scanning
* Fix corner cases in booting from ECKD
*

Merge remote-tracking branch 'remotes/huth-gitlab/tags/pull-request-2020-10-06' into staging

* Don't stop at the first unbootable device, continue scanning
* Fix corner cases in booting from ECKD
* s390x-ccw bios cleanup part 2​

# gpg: Signature made Tue 06 Oct 2020 19:17:46 BST
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5

* remotes/huth-gitlab/tags/pull-request-2020-10-06:
tests/qtest/cdrom: Add more s390x-related boot tests
pc-bios/s390: Update the s390-ccw bios binaries
pc-bios: s390x: Go into disabled wait when encountering a PGM exception
pc-bios: s390x: Use reset PSW if avaliable
pc-bios: s390x: Save PSW rework
pc-bios: s390x: Fix bootmap.c zipl component entry data handling
pc-bios/s390-ccw: break loop if a null block number is reached
pc-bios/s390-ccw: fix off-by-one error
pc-bios/s390-ccw/main: Remove superfluous call to enable_subchannel()
pc-bios/s390-ccw: Allow booting in case the first virtio-blk disk is bad
pc-bios/s390-ccw: Scan through all devices if no boot device specified
pc-bios/s390-ccw: Do not bail out early if not finding a SCSI disk
pc-bios/s390-ccw: Move the inner logic of find_subch() to a separate function
pc-bios/s390-ccw: Introduce ENODEV define and remove guards of others
pc-bios/s390-ccw: Move ipl-related code from main() into a separate function
pc-bios/s390-ccw/Makefile: Compile with -std=gnu99, -fwrapv and -fno-common

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...

pc-bios/s390-ccw: Do not bail out early if not finding a SCSI disk

In case the user did not specify a boot device, we want to continue
looking for other devices if there are no valid SCSI disks on a

pc-bios/s390-ccw: Do not bail out early if not finding a SCSI disk

In case the user did not specify a boot device, we want to continue
looking for other devices if there are no valid SCSI disks on a virtio-
scsi controller. As a first step, do not panic in this case and let
the control flow carry the error to the upper functions instead.

Message-Id: <20200806105349.632-6-thuth@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

Merge remote-tracking branch 'remotes/borntraeger/tags/s390x-20170714' into staging

s390x/kvm/migration/cpumodel: fixes, enhancements and cleanups

- add a network boot rom for s390 (Thomas Huth)
-

Merge remote-tracking branch 'remotes/borntraeger/tags/s390x-20170714' into staging

s390x/kvm/migration/cpumodel: fixes, enhancements and cleanups

- add a network boot rom for s390 (Thomas Huth)
- migration of storage attributes like the CMMA used/unused state
- PCI related enhancements - full support for aen, ais and zpci
- migration support for css with vmstates (Halil Pasic)
- cpu model enhancements for cpu features
- guarded storage support

# gpg: Signature made Fri 14 Jul 2017 11:33:04 BST
# gpg: using RSA key 0x117BBC80B5A61C7C
# gpg: Good signature from "Christian Borntraeger (IBM) <borntraeger@de.ibm.com>"
# Primary key fingerprint: F922 9381 A334 08F9 DBAB FBCA 117B BC80 B5A6 1C7C

* remotes/borntraeger/tags/s390x-20170714: (40 commits)
s390x/gdb: add gs registers
s390x/arch_dump: also dump guarded storage control block
s390x/kvm: enable guarded storage
s390x/kvm: Enable KSS facility for nested virtualization
s390x/cpumodel: add esop/esop2 to z12 model
s390x/cpumodel: we are always in zarchitecture mode
s390x/cpumodel: wire up new hardware features
s390x/flic: migrate ais states
s390x/cpumodel: add zpci, aen and ais facilities
s390x: initialize cpu firstly
pc-bios/s390: rebuild s390-ccw.img
pc-bios/s390: add s390-netboot.img
pc-bios/s390-ccw: Link libnet into the netboot image and do the TFTP load
pc-bios/s390-ccw: Add virtio-net driver code
pc-bios/s390-ccw: Add core files for the network bootloading program
roms/SLOF: Update submodule to latest status
pc-bios/s390-ccw: Add code for virtio feature negotiation
pc-bios/s390-ccw: Remove unused structs from virtio.h
pc-bios/s390-ccw: Move byteswap functions to a separate header
pc-bios/s390-ccw: Add a write() function for stdio
...

Conflicts:
target/s390x/kvm.c

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...

pc-bios/s390-ccw: Move virtio-block related functions into a separate file

The netboot code is going to link against the code from virtio.c, too, so
we've got to move the virtio-block and -scsi rela

pc-bios/s390-ccw: Move virtio-block related functions into a separate file

The netboot code is going to link against the code from virtio.c, too, so
we've got to move the virtio-block and -scsi related code out of the way.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1499863793-18627-4-git-send-email-thuth@redhat.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>

show more ...