aboutsummaryrefslogtreecommitdiff
path: root/pc-bios/s390-ccw
AgeCommit message (Collapse)AuthorFilesLines
2022-11-16s390x: Fix spelling errorsThomas Huth3-3/+3
Fix typos (discovered with the 'codespell' utility). Note: Though "migrateable" still seems to be a valid spelling, we change it to "migratable" since this is the way more common spelling here. Message-Id: <20221111182828.282251-1-thuth@redhat.com> Reviewed-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-10-06pc-bios/s390-ccw: Adopt meson style Make outputPaolo Bonzini2-16/+16
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220929114231.583801-31-alex.bennee@linaro.org>
2022-10-06pc-bios/s390-ccw: detect CC options just oncePaolo Bonzini2-13/+27
In preparation for adding Docker container support, detect compiler options just once rather than once per Make run; container startup overhead is substantial and doing the detection just once makes things faster. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220929114231.583801-15-alex.bennee@linaro.org>
2022-08-07pc-bios/s390-ccw: Fix booting with logical block size < physical block sizeThomas Huth1-1/+1
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>
2022-08-01misc: fix commonly doubled up wordsDaniel P. Berrangé1-1/+1
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20220707163720.1421716-5-berrange@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-07-13pc-bios/s390-ccw: add -Wno-array-boundsPaolo Bonzini1-0/+1
The option generates a lot of warnings for integers casted to pointers, for example: /home/pbonzini/work/upstream/qemu/pc-bios/s390-ccw/dasd-ipl.c:174:19: warning: array subscript 0 is outside array bounds of ‘CcwSeekData[0]’ [-Warray-bounds] 174 | seekData->cyl = 0x00; | ~~~~~~~~~~~~~~^~~~~~ Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-07-12Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into stagingPeter Maydell2-13/+13
* fuzzing fixes (Alexander) * fix cross compilation CFLAGS and compiler choice * do not specify -bios option for tests/vm * miscellaneous fixes * preparation for pre-install tree in the build directory (Akihiko) # gpg: Signature made Tue 12 Jul 2022 13:47:19 BST # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * tag 'for-upstream' of https://gitlab.com/bonzini/qemu: meson: place default firmware path under .../share qga: Relocate a path emitted in the help text build: Do not depend on pc-bios for config-host.mak accel: kvm: Fix memory leak in find_stats_descriptors audio/dbus: fix building fuzz: only use generic-fuzz targets on oss-fuzz build: improve -fsanitize-coverage-allowlist check build: try both native and cross compilers configure: pass whole target name to probe_target_compiler tests/tcg: compile system emulation tests as freestanding configure: write EXTRA_CFLAGS for all sub-Makefiles configure: allow more host/target combos to use the host compiler configure, pc-bios/vof: pass cross CFLAGS correctly configure, pc-bios/s390-ccw: pass cross CFLAGS correctly configure, pc-bios/optionrom: pass cross CFLAGS correctly pc-bios/optionrom: use -m16 unconditionally scsi/lsi53c895a: fix use-after-free in lsi_do_msgout (CVE-2022-0216) tests/vm: do not specify -bios option Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # pc-bios/s390-ccw/netboot.mak
2022-07-06pc-bios/s390-ccw/netboot.mak: Ignore Clang's warnings about GNU extensionsThomas Huth1-2/+5
When compiling the s390-ccw bios with Clang (v14.0), there is currently an unuseful warning like this: CC pc-bios/s390-ccw/ipv6.o ../../roms/SLOF/lib/libnet/ipv6.c:447:18: warning: variable length array folded to constant array as an extension [-Wgnu-folding-constant] unsigned short raw[ip6size]; ^ SLOF is currently GCC-only and cannot be compiled with Clang yet, so it is expected that such extensions sneak in there - and as long as we don't want to compile the code with a compiler that is neither GCC or Clang, it is also not necessary to avoid such extensions. Thus these GNU-extension related warnings are completely useless in the s390-ccw bios, especially in the code that is coming from SLOF, so we should simply disable the related warnings here now. Message-Id: <20220704111903.62400-13-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-07-06pc-bios/s390-ccw/virtio: Remove "extern" keyword from prototypesThomas Huth1-6/+6
All the other protytpes in the headers here do not use the "extern" keyword, so let's unify this by removing the "extern" from the misfits, too. Message-Id: <20220704111903.62400-12-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-07-06pc-bios/s390-ccw/virtio-blkdev: Request the right feature bitsThomas Huth1-0/+4
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>
2022-07-06pc-bios/s390-ccw: Split virtio-scsi code from virtio_blk_setup_device()Thomas Huth4-27/+38
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>
2022-07-06pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configurationThomas Huth1-3/+2
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "virtio device" instead of "block device", since this code is nowadays used for non-block (i.e. network) devices, too. Message-Id: <20220704111903.62400-9-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>
2022-07-06pc-bios/s390-ccw/virtio: Read device config after feature negotiationThomas Huth1-4/+3
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus should rather be read afterwards. While we're at it, also adjust the error message here a little bit (the code is nowadays used for non-block virtio devices, too). Message-Id: <20220704111903.62400-8-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>
2022-07-06pc-bios/s390-ccw/virtio: Set missing status bits while initializingThomas Huth1-4/+14
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has to set the ACKNOWLEDGE and DRIVER bits in the status field after resetting the device. The s390-ccw bios skipped these steps so far and seems like QEMU never cared. Anyway, it's better to follow the spec, so let's set these bits now in the right spots, too. Message-Id: <20220704111903.62400-7-thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-07-06pc-bios/s390-ccw/virtio-blkdev: Remove virtio_assume_scsi()Thomas Huth2-25/+0
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>
2022-07-06pc-bios/s390-ccw/virtio-blkdev: Simplify/fix virtio_ipl_disk_is_valid()Thomas Huth2-36/+7
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>
2022-07-06pc-bios/s390-ccw/bootmap: Improve the guessing logic in zipl_load_vblk()Thomas Huth1-4/+23
The logic of trying an final ISO or ECKD boot on virtio-block devices is very weird: Since the geometry hardly ever matches in virtio_disk_is_scsi(), virtio_blk_setup_device() always sets a "guessed" disk geometry via virtio_assume_scsi() (which is certainly also wrong in a lot of cases). zipl_load_vblk() then sees that there's been a "virtio_guessed_disk_nature" and tries to fix up the geometry again via virtio_assume_iso9660() before always trying to do ipl_iso_el_torito(). That's a very brain-twisting way of attempting to boot from ISO images, which won't work anymore after the following patches that will clean up the virtio_assume_scsi() mess (and thus get rid of the "virtio_guessed_disk_nature" here). Let's try a better approach instead: ISO files always have a magic string "CD001" at offset 0x8001 (see e.g. the ECMA-119 specification) which we can use to decide whether we should try to boot in ISO 9660 mode (which we should also try if we see a sector size of 2048). And if we were not able to boot in ISO mode here, the final boot attempt before panicking is to boot in ECKD mode. Since this is our last boot attempt anyway, simply always assume the ECKD geometry here (if the sector size was not 4096 yet), so that we also do not depend on the guessed disk geometry from virtio_blk_setup_device() here anymore. Message-Id: <20220704111903.62400-4-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-07-06pc-bios/s390-ccw/virtio: Introduce a macro for the DASD block sizeThomas Huth2-1/+2
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>
2022-07-06pc-bios/s390-ccw: Add a proper prototype for main()Thomas Huth2-2/+2
Older versions of Clang complain if there is no prototype for main(). Add one, and while we're at it, make sure that we use the same type for main.c and netmain.c - since the return value does not matter, declare the return type of main() as "void". Message-Id: <20220704111903.62400-2-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>
2022-07-06configure, pc-bios/s390-ccw: pass cross CFLAGS correctlyPaolo Bonzini2-13/+13
QEMU_CFLAGS is not available in pc-bios/s390-ccw/netboot.mak, but the Makefile needs to access the flags passed to the configure script for the s390x cross compiler. Fix everything and rename QEMU_CFLAGS to EXTRA_CFLAGS for consistency with tests/tcg. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-06-01configure: enable cross-compilation of s390-ccwPaolo Bonzini2-5/+6
While container-based cross compilers are not supported, this already makes it possible to build s390-ccw on any machine that has s390x GCC and binutils installed. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220517092616.1272238-14-pbonzini@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20220527153603.887929-25-alex.bennee@linaro.org>
2022-01-12configure: parse --enable/--disable-strip automatically, flip defaultPaolo Bonzini1-2/+0
Always include the STRIP variable in config-host.mak (it's only used by the s390-ccw firmware build, and it adds a default if configure omitted it), and use meson-buildoptions.sh to turn --enable/--disable-strip into -Dstrip. The default is now not to strip the binaries like for almost every other package that has a configure script. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-06-02docs: fix references to docs/devel/s390-dasd-ipl.rstStefano Garzarella1-1/+1
Commit cc3d15a5ea ("docs: rstfy s390 dasd ipl documentation") converted docs/devel/s390-dasd-ipl.txt to docs/devel/s390-dasd-ipl.rst. We still have several references to the old file, so let's fix them with the following command: sed -i s/s390-dasd-ipl.txt/s390-dasd-ipl.rst/ \ $(git grep -l docs/devel/s390-dasd-ipl.txt) Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20210517151702.109066-6-sgarzare@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-05-14pc-bios/s390-ccw: Fix inline assembly for older versions of ClangThomas Huth4-8/+8
Clang versions before v11.0 insist on having the %rX or %cX register names instead of just a number. Since our Travis-CI is currently still using Clang v6.0, we have to fix this to avoid failing jobs. Message-Id: <20210512171550.476130-2-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-05-09pc-bios/s390-ccw: Allow building with Clang, tooThomas Huth1-1/+2
Clang unfortunately does not support generating code for the z900 architecture level and starts with the z10 instead. Thus to be able to support compiling with Clang, we have to check for the supported compiler flags. The disadvantage is of course that the bios image will only run with z10 guest CPUs upwards (which is what most people use anyway), so just in case let's also emit a warning in that case (we will continue to ship firmware images that have been pre-built with GCC in future releases, so this should not impact normal users, too). Message-Id: <20210502174836.838816-5-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-05-09pc-bios/s390-ccw: Silence GCC 11 stringop-overflow warningPhilippe Mathieu-Daudé1-0/+1
When building on Fedora 34 (gcc version 11.0.0 20210210) we get: In file included from pc-bios/s390-ccw/main.c:11: In function ‘memset’, inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5, inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5: pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 28 | p[i] = c; | ~~~~~^~~ The offending code is: memset((char *)S390EP, 0, 6); where S390EP is a const address: #define S390EP 0x10008 The compiler doesn't know how big that pointed area is, so it assume that its length is zero. This has been reported as BZ#99578 to GCC: "gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 As this warning does us more harm than good in the BIOS code (where lot of direct accesses to low memory are done), silence this warning for all BIOS objects. Suggested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210422145911.2513980-1-philmd@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20210502174836.838816-4-thuth@redhat.com> [thuth: Use the pre-existing cc-option macro instead of adding a new one] Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-05-09pc-bios/s390-ccw: Fix the cc-option macro in the MakefileThomas Huth1-2/+2
The cc-option macro is not doing what it should - compared with the original from the rules.mak file that got removed with commit 660f793093 ("Makefile: inline the relevant parts of rules.mak"), the arguments got changed and thus the macro is rather doubling the QEMU_CFLAGS than adding the flag that should be tested. Message-Id: <20210502174836.838816-3-thuth@redhat.com> Fixes: 22fb2ab096 ("pc-bios/s390-ccw: do not use rules.mak") Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-05-09pc-bios/s390-ccw: Silence warning from Clang by marking panic() as noreturnThomas Huth1-0/+1
When compiling the s390-ccw bios with Clang, the compiler emits a warning: pc-bios/s390-ccw/main.c:210:5: warning: variable 'found' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized] default: ^~~~~~~ pc-bios/s390-ccw/main.c:214:16: note: uninitialized use occurs here IPL_assert(found, "Boot device not found\n"); ^~~~~ It's a false positive, it only happens because Clang is not smart enough to see that the panic() function in the "default:" case can never return. Anyway, let's explicitely mark panic() with "noreturn" to shut up the warning. Message-Id: <20210502174836.838816-2-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-05-09pc-bios/s390-ccw/netboot: Use "-Wl," prefix to pass parameter to the linkerThomas Huth1-1/+1
We are using the compiler to do the linking of the bios files. GCC still accepts the "-Ttext=..." linker flag directly and is smart enough to pass it to the linker, but in case we are compiling with Clang, we have to use the official way with the "-Wl," prefix instead. Message-Id: <20210423153646.593153-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-05-09pc-bios/s390-ccw: Use reset_psw pointer instead of hard-coded null pointerThomas Huth1-2/+2
When compiling the s390-ccw bios with clang, it emits a warning like this: pc-bios/s390-ccw/jump2ipl.c:86:9: warning: indirection of non-volatile null pointer will be deleted, not trap [-Wnull-dereference] if (*((uint64_t *)0) & RESET_PSW_MASK) { ^~~~~~~~~~~~~~~~ pc-bios/s390-ccw/jump2ipl.c:86:9: note: consider using __builtin_trap() or qualifying pointer with 'volatile' We could add a "volatile" here to shut it up, but on the other hand, we also have a pointer variable called "reset_psw" in this file already that points to the PSW at address 0, so we can simply use that pointer variable instead. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210423142440.582188-1-thuth@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-05-09pc-bios/s390-ccw/bootmap: Silence compiler warning from ClangThomas Huth1-1/+1
When compiling the s390-ccw bios with Clang, the compiler complains: pc-bios/s390-ccw/bootmap.c:302:9: warning: logical not is only applied to the left hand side of this comparison [-Wlogical-not-parentheses] if (!mbr->dev_type == DEV_TYPE_ECKD) { ^ ~~ The code works (more or less by accident), since dev_type can only be 0 or 1, but it's better of course to use the intended != operator here instead. Fixes: 5dc739f343 ("Allow booting in case the first virtio-blk disk is bad") Message-Id: <20210421163331.358178-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-05-09pc-bios/s390-ccw: don't try to read the next block if end of chunk is reachedMarc Hartmayer1-1/+1
Don't read the block if a null block number is reached, because this means that the end of chunk is reached. Reviewed-by: Collin Walling <walling@linux.ibm.com> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> Message-Id: <20210416074736.17409-1-mhartmay@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-11-23pc-bios: s390x: Clear out leftover S390EP stringEric Farman3-1/+10
A Linux binary will have the string "S390EP" at address 0x10008, which is important in getting the guest up off the ground. In the case of a reboot (specifically chreipl going to a new device), we should defer to the PSW at address zero for the new config, which will re-write "S390EP" from the new image. Let's clear it out at this point so that a reipl to, say, a DASD passthrough device drives the IPL path from scratch without disrupting disrupting the order of operations for other boots. Rather than hardcoding the address of this magic (again), let's define it somewhere so that the two users are visibly related. Signed-off-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20201120160117.59366-3-farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-11-23pc-bios: s390x: Ensure Read IPL memory is cleanEric Farman1-0/+3
If, for example, we boot off a virtio device and chreipl to a vfio-ccw device, the space at lowcore will be non-zero. We build a Read IPL CCW at address zero, but it will have leftover PSW data that will conflict with the Format-0 CCW being generated: 0x0: 00080000 80010000 ------ Ccw0.cda -- Ccw0.chainData -- Reserved bits The data address will be overwritten with the correct value (0x0), but the apparent data chain bit will cause subsequent memory to be used as the target of the data store, which may not be where we expect (0x0). Clear out this space when we boot from DASD, so that we know it exists exactly as we expect. Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@de.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20201120160117.59366-2-farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-11-04s390-bios: Skip writing iplb location to low core for ccw iplJason J. Herne1-1/+3
The architecture states that the iplb location is only written to low core for list directed ipl and not for traditional ccw ipl. If we don't skip this then operating systems that load by reading into low core memory may fail to start. We should also not write the iplb pointer for network boot as it might overwrite content that we got via network. Fixes: 9bfc04f9ef68 ("pc-bios: s390x: Save iplb location in lowcore") Signed-off-by: Jason J. Herne <jjherne@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201030122823.347140-1-borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-06pc-bios: s390x: Go into disabled wait when encountering a PGM exceptionJanosch Frank1-1/+4
Let's setup a PGM PSW, so we won't load 0s when a program exception happens. Instead we'll load a disabled wait PSW. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201006094249.50640-5-frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios: s390x: Use reset PSW if avaliableJanosch Frank3-9/+24
If a blob provides a reset PSW then we should use it instead of branching to the PSW address and using our own mask. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201006094249.50640-4-frankja@linux.ibm.com> [thuth: Use Elvis operator to shorten long line] Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios: s390x: Save PSW reworkJanosch Frank1-20/+13
We don't need to save the ipl_continue variable in lowcore and have it limited to 32 bits because of the lowcore layout. Let's move it to a new 64 bit variable and get rid of the reset info struct. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201006094249.50640-3-frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios: s390x: Fix bootmap.c zipl component entry data handlingJanosch Frank2-3/+9
The two main types of zipl component entries are execute and load/data. The last member of the component entry struct therefore denotes either a PSW or an address. Let's make this a bit more clear by introducing a union and cleaning up the code that uses that struct member. The execute type component entries written by zipl contain short PSWs, not addresses. Let's mask them and only pass the address part to jump_to_IPL_code(uint64_t address) because it expects an address as visible by the name of the argument. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201006094249.50640-2-frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios/s390-ccw: break loop if a null block number is reachedMarc Hartmayer1-1/+1
Break the loop if `cur_block_nr` is a null block number because this means that the end of chunk is reached. In this case we will try to boot the default entry. Fixes: ba831b25262a ("s390-ccw: read stage2 boot loader data to find menu") Reviewed-by: Collin Walling <walling@linux.ibm.com> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> Message-Id: <20200924085926.21709-3-mhartmay@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios/s390-ccw: fix off-by-one errorMarc Hartmayer1-1/+1
This error takes effect when the magic value "zIPL" is located at the end of a block. For example if s2_cur_blk = 0x7fe18000 and the magic value "zIPL" is located at 0x7fe18ffc - 0x7fe18fff. Fixes: ba831b25262a ("s390-ccw: read stage2 boot loader data to find menu") Reviewed-by: Collin Walling <walling@linux.ibm.com> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> Message-Id: <20200924085926.21709-2-mhartmay@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> [thuth: Use "<= ... - 4" instead of "< ... - 3"] Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios/s390-ccw/main: Remove superfluous call to enable_subchannel()Thomas Huth1-1/+0
enable_subchannel() is already done during is_dev_possibly_bootable() (which is called from find_boot_device() -> find_subch()), so there is no need to do this again in the main() function. Message-Id: <20200806105349.632-9-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios/s390-ccw: Allow booting in case the first virtio-blk disk is badThomas Huth2-12/+24
If you try to boot with two virtio-blk disks (without bootindex), and only the second one is bootable, the s390-ccw bios currently stops at the first disk and does not continue booting from the second one. This is annoying - and all other major QEMU firmwares succeed to boot from the second disk in this case, so we should do the same in the s390-ccw bios, too. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20200806105349.632-8-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios/s390-ccw: Scan through all devices if no boot device specifiedThomas Huth1-15/+31
If no boot device has been specified (via "bootindex=..."), the s390-ccw bios scans through all devices to find a bootable device. But so far, it stops at the very first block device (including virtio-scsi controllers without attached devices) that it finds, no matter whether it is bootable or not. That leads to some weird situatation where it is e.g. possible to boot via: qemu-system-s390x -hda /path/to/disk.qcow2 but not if there is e.g. a virtio-scsi controller specified before: qemu-system-s390x -device virtio-scsi -hda /path/to/disk.qcow2 While using "bootindex=..." is clearly the preferred way of booting on s390x, we still can make the life for the users at least a little bit easier if we look at all available devices to find a bootable one. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1846975 Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20200806105349.632-7-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios/s390-ccw: Do not bail out early if not finding a SCSI diskThomas Huth5-16/+37
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>
2020-10-06pc-bios/s390-ccw: Move the inner logic of find_subch() to a separate functionThomas Huth1-42/+57
Move the code to a separate function to be able to re-use it from a different spot later. Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20200806105349.632-5-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios/s390-ccw: Introduce ENODEV define and remove guards of othersThomas Huth1-4/+2
Remove the "#ifndef E..." guards from the defines here - the header guard S390_CCW_H at the top of the file should avoid double definition, and if the error code is defined in a different file already, we're in trouble anyway, then it's better to see the error at compile time instead of hunting weird behavior during runtime later. Also define ENODEV - we will use this in a later patch. Message-Id: <20200806105349.632-4-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios/s390-ccw: Move ipl-related code from main() into a separate functionThomas Huth1-8/+12
Let's move this part of the code into a separate function to be able to use it from multiple spots later. Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Message-Id: <20200806105349.632-3-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios/s390-ccw/Makefile: Compile with -std=gnu99, -fwrapv and -fno-commonThomas Huth1-3/+4
The main QEMU code is compiled with -std=gnu99, -fwrapv and -fno-common. We should use the same flags for the s390-ccw bios, too, to avoid that we get different behavior with different compiler versions that changed their default settings in the course of time (it happened at least with -std=... and -fno-common in the past already). While we're at it, also group the other flags here in a little bit nicer fashion: Move the two "-m" flags out of the "-f" area and specify them on a separate line. Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Message-Id: <20200806105349.632-2-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-09-01build: fix recurse-all targetPaolo Bonzini1-1/+2
The missing "/all" suffix prevents the pc-bios/ parts of the build from running. In the meanwhile, -Wall has moved from QEMU_CFLAGS to CFLAGS. Simplify everything by not passing down CFLAGS, and add -Wall in the recursive Makefiles. Reported-by: Miroslav Rezanina <mrezanin@redhat.com> Reviewed-by: Miroslav Rezanina <mrezanin@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Fixes: 5e6d1573b4 ("remove Makefile.target", 2020-08-21) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
generated by cgit v1.1 at 2024-12-28 19:36:23 +0000