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>

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>

softmmu/datadir.c had its own implementation to find files in the
build tree, but now bundle mechanism provides the unified
implementation which works for datadir and the other files.

Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20220624145039.49929-4-akihiko.odaki@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

The binaries have been recompiled with the fixes from the previous patches.

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

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

Use the flags passed to the configure script for the ppc cross compiler,
which in fact default to those that are needed to get the 32-bit ISA.
Add the endianness flag so that it remains possible to use a ppc64le
compiler to compile VOF.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

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>

The optionrom build is disregarding the flags passed to the configure
script via --cross-cflags-i386.  Pass it down and add it to the Makefile.

This will make it possible to get the -m32 flag from $target_cflags to
force a 32-bit build on 64-bit hosts, instead of supplying manually the
arcane -Wa,-32 and linker emulation options.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Remove support for .code16gcc, all supported platforms have -m16.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

While container-based cross compilers are not supported, this already
makes it possible to build vof on any machine that has an installation
of GCC and binutils for 32- or 64-bit PowerPC.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20220517092616.1272238-16-pbonzini@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20220527153603.887929-27-alex.bennee@linaro.org>

While container-based cross compilers are not supported, this already makes
it possible to build x86 optionroms on any machine that has an installation
of GCC and binutils for 32- or 64-bit x86.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20220517092616.1272238-15-pbonzini@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20220527153603.887929-26-alex.bennee@linaro.org>

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>

This is useful because pc-bios/meson.build already has a list of all ROM
files, and thus does not need to use wildcards.  The problems with
wildcards are mentioned above the definition of the LINKS variable,
but then the recommendation is disattended.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20220517092616.1272238-6-pbonzini@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20220527153603.887929-17-alex.bennee@linaro.org>

Just hardcode $(CC) -E, it should be enough.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220517092616.1272238-2-pbonzini@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20220527153603.887929-13-alex.bennee@linaro.org>

Staring with SEABIOS_HPPA_VERSION 6 the serial ports are now emulated as
on physical hardware, with LASI UART being serial port #0 and DINO UART
as serial port #1. On older versions those ports were swapped.

This SeaBIOS-hppa fix is needed to allow fixing the qemu serial
pass-through from host to guest.

Signed-off-by: Helge Deller <deller@gmx.de>

New features and fixes in SeaBIOS for hppa/parisc:

* STI firmware now contains additional fonts built-in, which
  can be selected with qemu command-line options:
        -fw_cfg opt/font,string=1       - a HP 8x16 font
        -fw_cfg opt/font,string=2       - a HP 6x13 font
        -fw_cfg opt/font,string=3       - a HP 10x20 font
        -fw_cfg opt/font,string=4       - a Linux 16x32 font

* Fixed PS/2 keyboard emulation when running in graphical mode.
  This allows to type boot commands in the firmware boot menu if
  qemu was started with "-boot menu=on" (and no linux kernel was
  given on the qemu command line).

* Fix firmware rendenzvous code to clear all pending external intrrupts
  before entering the waiting loop.

Signed-off-by: Helge Deller <deller@gmx.de>

Avoids the following bogus warning:

pvh_main.c: In function ‘pvh_load_kernel’:
pvh_main.c:101:42: warning: array subscript 0 is outside array bounds of ‘uint16_t[0]’ {aka ‘short unsigned int[]’} [-Warray-bounds]
  101 |         uint32_t ebda_paddr = ((uint32_t)*((uint16_t *)EBDA_BASE_ADDR)) << 4;
      |                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Cc: qemu-stable@nongnu.org
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Do not rely on the detection that was done in the configure script,
since in the future we may want to cross-compile this file.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

This is skiboot 7.0 (commit 76b349cf7b40). Built using gcc 11.2.0 and
binutils 2.38.

Changes since the previous version:

Christophe Lombard (15):
      npu2: move opal api
      pau: introduce support
      rainier: detect pau devices
      pau: assign bars
      pau: create phb
      pau: enabling opencapi
      pau: translation layer configuration
      pau: enable interrupt on error
      pau: complete phb ops
      pau: hmi scom dump
      pau: phy init
      pau: link training
      pau: update current opal call functions
      pau: mmio invalidates
      pau: Add support for OpenCAPI Persistent Memory devices.

Cédric Le Goater (4):
      xive/p10: Fix xive_special_cache_check when DEBUG=1
      xive/p10: Fix mismatch errors when DEBUG=1
      interrupts: Do not advertise XICS support on P10
      skiboot v6.6.6 release notes

Frederic Barrat (6):
      phb4/5: Escalate page-level TCE kills
      npu3: Remove GPU support on Swift
      phb5: Remove obsolete capp-related properties
      xive/p10:: Declare xive2 DT node as an interrupt-controller
      skiboot v6.0.24 release notes
      opal-api: Drop diagnostics data type symbol for PHB5

Michael Ellerman (3):
      external/mambo: Print more info when the kernel is too big
      doc: Make it clear all existing platforms use Power9N
      docs: Add Swift, Mowgli & Rainier

Nicholas Piggin (12):
      external/mambo: Updates for POWER10 configuration for DD2.0
      external/mambo: Updates POWER9 SIM_CTRL1 to remove hardware atomic RC
      external/mambo: Add POWER10 small-core mode
      HBRT: fix clobbered r16 when host services handlers are called
      interrupts: add_opal_interrupts avoid NULL dereference on P10 mambo
      cpu: cpu_idle_job SMT priority fix
      cpu: add debug check in cpu_relax
      asm/head: Fix P10 HILE for little endian build
      phb4: annotate tbl_pest with endian types
      Remove support for POWER8 DD1
      phb3: make endian-clean
      flash: AST BMC endian fixes

Nick Child (1):
      secvar: Free md context on hash error

Ryan Grimm (1):
      AWAN simulator support for P10

Vasant Hegde (5):
      ci: Bump qemu version
      hello_world: Add p10 mambo tests
      skiboot v6.7.3 release notes
      skiboot v6.8.1 release notes
      skiboot v7.0 release notes

Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>

Some of the roms build with -march=i486 -m16 which is incompatible
with -fcf-protection. That in turn is can be set by default, for
example in Ubuntu [1].
That causes:
 cc1: error: ‘-fcf-protection’ is not compatible with this target

This won't work on -march=i486 -m16 and no matter if set or not we can
override it to "none" if the option is known to the compiler to be
able to build reliably.

Fixes: https://gitlab.com/qemu-project/qemu/-/issues/889

[1]: https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-fcf-protection



Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20220323090713.1002588-1-christian.ehrhardt@canonical.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

The switch to edk2 RELEASE builds changes the memory layout a bit,
resulting in a acpi table change.

 DefinitionBlock ("", "SSDT", 1, "BOCHS ", "NVDIMM", 0x00000001)
 {
     Scope (\_SB)
     {
         Device (NVDR)
         {
             Name (_HID, "ACPI0012" /* NVDIMM Root Device */)  // _HID: Hardware ID
             Method (NCAL, 5, Serialized)
             {
                 Local6 = MEMA /* \MEMA */
                 {
                     Return (NCAL (Arg0, Arg1, Arg2, Arg3, 0x02))
                 }
             }

             Device (NV02)
             {
                 Name (_ADR, 0x03)  // _ADR: Address
                 Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                 {
                     Return (NCAL (Arg0, Arg1, Arg2, Arg3, 0x03))
                 }
             }
         }
     }

-    Name (MEMA, 0x43D10000)
+    Name (MEMA, 0x43F50000)
 }

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

This installs VOF-related binaries (the firmware and the preformatted
NVRAM) as those were left out when the VOF was submitted initially.

Fixes: fc8c745d ("spapr: Implement Open Firmware client interface")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Message-Id: <20220208103751.1587902-1-aik@ozlabs.ru>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

New firmware features and fixes:

* Allow up to 16 CPUs

* Add TOC button support:
    To trigger a TOC, execute "nmi" in the qemu monitor (Ctrl-A C)

* New opt/hostid fw_cfg option to change hostid:
    -fw_cfg opt/hostid,string=334455

* Add opt/console fw_cfg option to select default console:
    -fw_cfg opt/console,string=serial
    -fw_cfg opt/console,string=graphics

* Add Linux TER16x32 font to STI firmware:
    -fw_cfg opt/font,string=2

* Leave IRQs disabled after rendevouz

Signed-off-by: Helge Deller <deller@gmx.de>

Now that all RISC-V machines can use OpenSBI BIN images, we remove
OpenSBI ELF images and also exclude these images from BIOS build.

Signed-off-by: Anup Patel <apatel@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>

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>