| f612e211 | 10-May-2021 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390: Update the s390-ccw bios binaries with the Clang and other fixes
Rebuild the s390-ccw firmware with my Clang fixes and the ECKD null
block number fix from Marc.
Signed-off-by: Thomas
pc-bios/s390: Update the s390-ccw bios binaries with the Clang and other fixes
Rebuild the s390-ccw firmware with my Clang fixes and the ECKD null
block number fix from Marc.
Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
| a5b2afd5 | 02-May-2021 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw: Allow building with Clang, too
Clang unfortunately does not support generating code for the z900
architecture level and starts with the z10 instead. Thus to be able
to support comp
pc-bios/s390-ccw: Allow building with Clang, too
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>
show more ...
|
| da231910 | 22-Apr-2021 |
Philippe Mathieu-Daudé <philmd@redhat.com> |
pc-bios/s390-ccw: Silence GCC 11 stringop-overflow warning
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
pc-bios/s390-ccw: Silence GCC 11 stringop-overflow warning
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>
show more ...
|
| 3462ff35 | 02-May-2021 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw: Fix the cc-option macro in the Makefile
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
pc-bios/s390-ccw: Fix the cc-option macro in the Makefile
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>
show more ...
|
| 679196a6 | 02-May-2021 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw: Silence warning from Clang by marking panic() as noreturn
When compiling the s390-ccw bios with Clang, the compiler emits a warning:
pc-bios/s390-ccw/main.c:210:5: warning: varia
pc-bios/s390-ccw: Silence warning from Clang by marking panic() as noreturn
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>
show more ...
|
| b460a220 | 23-Apr-2021 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/netboot: Use "-Wl," prefix to pass parameter to the linker
We are using the compiler to do the linking of the bios files. GCC still
accepts the "-Ttext=..." linker flag directly and
pc-bios/s390-ccw/netboot: Use "-Wl," prefix to pass parameter to the linker
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>
show more ...
|
| ff77712a | 23-Apr-2021 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw: Use reset_psw pointer instead of hard-coded null pointer
When compiling the s390-ccw bios with clang, it emits a warning like this:
pc-bios/s390-ccw/jump2ipl.c:86:9: warning: ind
pc-bios/s390-ccw: Use reset_psw pointer instead of hard-coded null pointer
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>
show more ...
|
| d08a6494 | 21-Apr-2021 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/bootmap: Silence compiler warning from Clang
When compiling the s390-ccw bios with Clang, the compiler complains:
pc-bios/s390-ccw/bootmap.c:302:9: warning: logical not is only ap
pc-bios/s390-ccw/bootmap: Silence compiler warning from Clang
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>
show more ...
|
| 4b956a39 | 31-Jan-2021 |
Sergei Trofimovich <slyfox@gentoo.org> |
pc-bios/descriptors: fix paths in json files
Before the change /usr/share/qemu/firmware/50-edk2-x86_64-secure.json
contained the relative path:
"filename": "share/qemu/edk2-x86_64-secure
pc-bios/descriptors: fix paths in json files
Before the change /usr/share/qemu/firmware/50-edk2-x86_64-secure.json
contained the relative path:
"filename": "share/qemu/edk2-x86_64-secure-code.fd",
"filename": "share/qemu/edk2-i386-vars.fd",
After then change the paths are absolute:
"filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd",
"filename": "/usr/share/qemu/edk2-i386-vars.fd",
The regression appeared in qemu-5.2.0 (seems to be related
to meson port).
CC: Paolo Bonzini <pbonzini@redhat.com>
CC: "Marc-André Lureau" <marcandre.lureau@redhat.com>
CC: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Bug: https://bugs.gentoo.org/766743
Bug: https://bugs.launchpad.net/qemu/+bug/1913012
Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Message-Id: <20210131143434.2513363-1-slyfox@gentoo.org>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| 45b545dd | 14-Jan-2021 |
Philippe Mathieu-Daudé <philmd@redhat.com> |
meson.build: Detect bzip2 program
The --enable-bzip2/--disable-bzip2 configure arguments are
somehow misleading, they check for the bzip2 library, not
the bzip2 program.
We need the bzip2 program t
meson.build: Detect bzip2 program
The --enable-bzip2/--disable-bzip2 configure arguments are
somehow misleading, they check for the bzip2 library, not
the bzip2 program.
We need the bzip2 program to install the EDK2 firmware blobs
(see commit 623ef637a2e "configure: Check bzip2 is available").
Check if the bzip2 program in the global meson.build to avoid
the configuration to succeed, but a later when trying to install
the firmware blobs:
../pc-bios/meson.build:5:2: ERROR: Program 'bzip2' not found
Reported-by: John Snow <jsnow@redhat.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Fixes: c8d5450bba3 ("configure: move install_blobs from configure to meson")
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210114174509.2944817-3-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| 3d651996 | 20-Nov-2020 |
Eric Farman <farman@linux.ibm.com> |
pc-bios: s390x: Clear out leftover S390EP string
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 (
pc-bios: s390x: Clear out leftover S390EP string
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>
show more ...
|
| d8e5bbdd | 20-Nov-2020 |
Eric Farman <farman@linux.ibm.com> |
pc-bios: s390x: Ensure Read IPL memory is clean
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 addre
pc-bios: s390x: Ensure Read IPL memory is clean
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>
show more ...
|