aboutsummaryrefslogtreecommitdiff
path: root/pc-bios/s390-ccw
AgeCommit message (Collapse)Author
2024-11-18pc-bios/s390-ccw: Re-initialize receive queue index before each boot attemptThomas Huth
Now that we can boot from multiple boot devices, we have to make sure to reinitialize static variables like rx_last_idx to avoid that they contain garbage data during the second boot attempt (which can lead to crashes when the code tries to access the wrong ring data). Message-ID: <20241111131120.317796-1-thuth@redhat.com> Reviewed-by: Jared Rossi <jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-11-18pc-bios/s390x: Initialize machine loadparm before probing IPL devicesJared Rossi
Commit bb185de423 ("s390x: Add individual loadparm assignment to CCW device") allowed boot devices to be assigned a loadparm value independent of the machine value, however, when no boot devices are defined, the machine loadparm becomes ignored. Therefore, let's check the machine loadparm prior to probing the devices. Signed-off-by: Jared Rossi <jrossi@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20241114161952.3508554-1-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-11-18pc-bios/s390x: Initialize cdrom type to false for each IPL deviceJared Rossi
Clear information about cdrom type so that current IPL device isn't tainted by stale data from previous devices. Signed-off-by: Jared Rossi <jrossi@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20241108194136.2833932-1-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23pc-bios/s390-ccw: Introduce `EXTRA_LDFLAGS`Marc Hartmayer
Some packaging tools want to override `LDFLAGS` when building QEMU, this will result in a build error as most likely no `-nostdlib` flag is passed. Introduce `EXTRA_LDFLAGS` so that the packager can override `LDFLAGS` without breaking the build. Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> Message-ID: <20241001153618.17791-4-mhartmay@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> [thuth: Drop the hunk to netbook.mak which is not necessary anymore] Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23pc-bios/s390-ccw: Don't generate TEXTRELsJens Remus
Commit 7cd50cbe4ca3 ("pc-bios/s390-ccw: Don't use __bss_start with the "larl" instruction") introduced the address constant bss_start_literal for __bss_start in the .text section, which introduced a relocation in code (i.e. TEXTREL). The dedicated constant is required, as __bss_start may not necessarily be aligned on a 2-byte boundary (see subject commit for details). Move the constant to the .data section to get rid of the relocation in the .text section. Add the linker option -z text to prevent TEXTRELs to get introduced in the future. Note that the R_390_RELATIVE relocations are taken care of by function glue() in include/hw/elf_ops.h.inc introduced by commit 5dce07e1cb67 ("elf-loader: Provide the possibility to relocate s390 ELF files"). Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com> Message-ID: <20241001153618.17791-3-mhartmay@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23pc-bios/s390-ccw: Clarify alignment is in bytesJens Remus
The assembler directive .align [1] has architecture-dependent behavior, which may be ambiguous for the reader. Some architectures perform the alignment in bytes, others in power of two. s390 does in bytes. Use the directive .balign [2] instead, to clarify that the alignment request is in bytes. No functional change. [1] https://sourceware.org/binutils/docs/as/Align.html [2] https://sourceware.org/binutils/docs/as/Balign.html Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com> Message-ID: <20241001153618.17791-2-mhartmay@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23pc-bios/s390x: Enable multi-device boot loopJared Rossi
Allow attempts to boot from multiple IPL devices. If the first device fails to IPL, select the pre-built IPLB for the next device in the boot order and attempt to IPL from it. Continue this process until IPL is successful or there are no devices left to try. Signed-off-by: Jared Rossi <jrossi@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20241020012953.1380075-18-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23s390x: Rebuild IPLB for SCSI device directly from DIAG308Jared Rossi
Because virtio-scsi type devices use a non-architected IPLB pbt code they cannot be set and stored normally. Instead, the IPLB must be rebuilt during re-ipl. As s390x does not natively support multiple boot devices, the devno field is used to store the position in the boot order for the device. Handling the rebuild as part of DIAG308 removes the need to check the devices for invalid IPLBs later in the IPL. Signed-off-by: Jared Rossi <jrossi@linux.ibm.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-ID: <20241020012953.1380075-17-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23s390x: Add individual loadparm assignment to CCW deviceJared Rossi
Add a loadparm property to the VirtioCcwDevice object so that different loadparms can be defined on a per-device basis for CCW boot devices. The machine/global loadparm is still supported. If both a global and per-device loadparm are defined, the per-device value will override the global value for that device, but any other devices that do not specify a per-device loadparm will still use the global loadparm. It is invalid to assign a loadparm to a non-boot device. Signed-off-by: Jared Rossi <jrossi@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20241020012953.1380075-15-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23include/hw/s390x: Add include files for common IPL structsJared Rossi
Currently, structures defined in both hw/s390x/ipl.h and pc-bios/s390-ccw/iplb.h must be kept in sync, which is prone to error. Instead, create a new directory at include/hw/s390x/ipl/ to contain the definitions that must be shared. Signed-off-by: Jared Rossi <jrossi@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20241020012953.1380075-14-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23pc-bios/s390-ccw: Enable failed IPL to return after errorJared Rossi
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>
2024-10-23pc-bios/s390-ccw: Remove panics from Netboot IPL pathJared Rossi
Remove panic-on-error from Netboot 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-12-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23pc-bios/s390-ccw: Remove panics from DASD IPL pathJared Rossi
Remove panic-on-error from DASD 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-11-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23pc-bios/s390-ccw: Remove panics from SCSI IPL pathJared Rossi
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>
2024-10-23pc-bios/s390-ccw: Remove panics from ECKD IPL pathJared Rossi
Remove panic-on-error from ECKD block device 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-9-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23pc-bios/s390-ccw: Remove panics from ISO IPL pathJared Rossi
Remove panic-on-error from IPL ISO El Torito 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-8-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23pc-bios/s390-ccw: Merge netboot.mak into the main MakefileThomas Huth
Now that the netboot code has been merged into the main s390-ccw.img, it also does not make sense to keep the build rules in a separate file. Thus let's merge netboot.mak into the main Makefile. Message-Id: <20240621082422.136217-7-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23pc-bios/s390-ccw: Link the netboot code into the main s390-ccw.img binaryJared Rossi
We originally built a separate binary for the netboot code since it was considered as experimental and we could not be sure that the necessary SLOF module had been checked out. Time passed, the code proved its usefulness, and the build system nowadays makes sure that the SLOF module is checked out if you have a s390x compiler available for building the s390-ccw bios. So there is no real compelling reason anymore to keep the netboot code in a separate binary. Linking the code together with the main s390-ccw.img will make future enhancements much easier, like supporting more than one boot device. Co-authored by: Thomas Huth <thuth@redhat.com> Signed-off-by: Jared Rossi <jrossi@linux.ibm.com> Message-ID: <20241020012953.1380075-4-jrossi@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-10-23pc-bios/s390-ccw: Use the libc from SLOF and remove sclp printsJared Rossi
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>
2024-07-02pc-bios/s390-ccw: Remove duplicated LDFLAGSThomas Huth
The -Wl,-pie and -nostdlib flags are added to LDFLAGS twice. Merge the two lines to get rid of the duplicates. Message-ID: <20240621082422.136217-2-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-06-29pc-bios/s390-ccw: Don't use __bss_start with the "larl" instructionThomas Huth
start.S currently cannot be compiled with Clang 16 and binutils 2.40: ld: start.o(.text+0x8): misaligned symbol `__bss_start' (0xc1e5) for relocation R_390_PC32DBL According to the built-in linker script of ld, the symbol __bss_start can actually point *before* the .bss section and does not need to have any alignment, so in certain situations (like when using the internal assembler of Clang), the __bss_start symbol can indeed be unaligned and thus it is not suitable for being used with the "larl" instruction that needs an address that is at least aligned to halfwords. The problem went unnoticed so far since binutils <= 2.39 did not check the alignment, but starting with binutils 2.40, such unaligned addresses are now refused. Fix it by loading the address indirectly instead. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2216662 Reported-by: Miroslav Rezanina <mrezanin@redhat.com> Suggested-by: Andreas Krebbel <andreas.krebbel@de.ibm.com> Message-Id: <20230629104821.194859-8-thuth@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-06-29pc-bios/s390-ccw: Move the stack array into start.SThomas Huth
The stack array is only referenced from the start-up code (which is shared between the s390-ccw.img and the s390-netboot.img), but it is currently declared twice, once in main.c and once in netmain.c. It makes more sense to declare this in start.S instead - which will also be helpful in the next patch, since we need to mention the .bss section in start.S in that patch. While we're at it, let's also drop the huge alignment of the stack, since there is no technical requirement for aligning it to page boundaries. Message-Id: <20230627074703.99608-4-thuth@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-06-29pc-bios/s390-ccw: Provide space for initial stack frame in start.SThomas Huth
Providing the space of a stack frame is the duty of the caller, so we should reserve 160 bytes before jumping into the main function. Otherwise the main() function might write past the stack array. While we're at it, add a proper STACK_SIZE macro for the stack size instead of using magic numbers (this is also required for the following patch). Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-Id: <20230627074703.99608-3-thuth@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-06-29pc-bios/s390-ccw: Fix indentation in start.SThomas Huth
start.S is currently indented with a mixture of spaces and tabs, which is quite ugly. QEMU coding style says indentation should be 4 spaces, and this is also what we are using in the assembler files in the tests/tcg/s390x/ folder already, so let's adjust start.S accordingly. Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-Id: <20230627074703.99608-2-thuth@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-06-29pc-bios/s390-ccw/Makefile: Use -z noexecstack to silence linker warningThomas Huth
Recent versions of ld complain when linking the s390-ccw bios: /usr/bin/ld: warning: start.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker We can silence the warning by telling the linker to mark the stack as not executable. Message-Id: <20230622130822.396793-1-thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-06-29pc-bios/s390-ccw: Get rid of the the __u* typesThomas Huth
The types starting with double underscores have likely been introduced into the s390-ccw bios to be able to re-use structs from the Linux kernel in the past, but the corresponding structs in cio.h have been changed there a long time ago already to not use the variants with the double underscores anymore: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/s390/cio/cio.h?id=cd6b4f27b9bb2a So it would be good to replace these in the s390-ccw bios now, too. Message-Id: <20230627114101.122231-1-thuth@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-06-29s390-ccw: Getting rid of ulongJuan Quintela
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>
2023-06-06pc-bios/s390-ccw: always build network bootloaderPaolo Bonzini
In the beginning, the network bootloader was considered experimental and thus optional, but it is well established nowadays and configure always checks for roms/SLOF before compiling pc-bios/s390-ccw. Therefore, it makes sense to always build it together with the other part of the s390-ccw bios. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-06configure: move SLOF submodule handling to pc-bios/s390-ccwPaolo Bonzini
Move the handling of the roms/SLOF submodule out of the main Makefile, since we are going to remove submodules from the build process of QEMU. Acked-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-03-08pc-bios: Add support for List-Directed IPL from ECKD DASDJared Rossi
Check for a List Directed IPL Boot Record, which would supersede the CCW type entries. If the record is valid, proceed to use the new style pointers and perform LD-IPL. Each block pointer is interpreted as either an LD-IPL pointer or a legacy CCW pointer depending on the type of IPL initiated. In either case CCW- or LD-IPL is transparent to the user and will boot the same image regardless of which set of pointers is used. Because the interactive boot menu is only written with the old style pointers, the menu will be disabled for List Directed IPL from ECKD DASD. If the LD-IPL fails, retry the IPL using the CCW type pointers. If no LD-IPL boot record is found, simply perform CCW type IPL as usual. Signed-off-by: Jared Rossi <jrossi@linux.ibm.com> Message-Id: <20230221174548.1866861-2-jrossi@linux.ibm.com> [thuth: Drop some superfluous parantheses] Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-11-16s390x: Fix spelling errorsThomas Huth
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 Bonzini
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 Bonzini
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 Huth
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é
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 Bonzini
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 Maydell
* 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 Huth
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 Huth
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 Huth
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 Huth
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 Huth
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 Huth
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 Huth
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 Huth
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 Huth
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 Huth
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 Huth
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 Huth
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 Bonzini
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>