There is an oddity that turns up with the float_convd and float_convs
tests, when running from different toolchains. As one example, the
expectation at the start of tests/tcg/ppc64/float_conv*.ref is:
### Rounding to nearest
from double: f64(nan:0x007ff4000000000000)
to single: f32(nan:0x7fe00000) (INVALID)
to int32: -2147483648 (INVALID)
to int64: -9223372036854775808 (INVALID)
to uint32: 0 (INVALID)
to uint64: -9223372036854775808 (INVALID)
But, other hosts offer a different response, e.g., this debian guest
on my laptop:
### Rounding to nearest
from double: f64(nan:0x007ff4000000000000)
to single: f32(nan:0x7fe00000) (INVALID)
to int32: -2147483648 (INVALID)
to int64: -9223372036854775808 (INVALID)
to uint32: 0 (INVALID)
to uint64: 0 (INVALID)
The explanation seems to be a behavior change when compiling to different
versions of power hardware. When building the arguments from the multiarch
directory, let's ensure these float tests offer a deterministic response
to these NaN tests by explicitly binding them to a CPU architecture.
Chose power8 for no real reason. This behavior change appears between
power6 and power7, but other tests that rely on a specific architecture
today pick either power8 or power10.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20261019185600.2031729-3-farman@linux.ibm.com
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Running make check-tcg-x86_64 on a big-endian host (e.g., s390x) fails due
to problems reading/parsing the ELF data:
qemu-system-x86_64: Error loading uncompressed kernel without PVH ELF Note
There already exists logic in include/hw/elf_ops.h.inc to handle byte-swaps
where necessary, but it does not perform this logic for ELF notes itself.
Fixing that improves matters, but yields other errors: most of the tests
timeout while some generate confusing assertions. Both appear to be related
to the data addresses in those notes, which are incorrect when running on a
big-endian host.
Adding tswap wrappers, which will conditionally swap if the host and target
endianness don't match, fixes that such that check-tcg-x86_64 runs cleanly
on an s390 host.
Acked-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20261019185600.2031729-2-farman@linux.ibm.com
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Running this test on s390 causes long python exception tracebacks
at the beginning of the system_reset loop. The problem appears to
be the same one described by commit ad302b21aa, in that QEMU
will exit on s390 without any kernel or boot disk.
In other tests, this is addressed by adding -no-shutdown to the
command line, and that does create a clean failure instead of a
long line of python exceptions:
--- /home/farman/git/qemu/tests/qemu-iotests/tests/iothreads-nbd-export.out
+++ /home/farman/git/qemu/build/scratch/qcow2-file-iothreads-nbd-export/iothreads-nbd-export.out.bad
@@ -16,4 +16,4 @@
{"return": {}}
{"return": {}}
Checking that it is still alive...
-{"return": {"running": true, "status": "running"}}
+{"return": {"running": false, "status": "prelaunch"}}
Failures: iothreads-nbd-export
Failed 1 of 1 iotests
...but obviously this isn't still a successful test, since it is
expected that the guest will be still be usable after the reset loop.
So, barring a solution to that, just skip this test on s390.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Message-ID: <20260925194409.716498-6-farman@linux.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Commit 951227d375 ("iotests: skip FUSE tests when FUSE is not usable")
reworked some of the fuse-related tests to skip where needed,
but the new test fuse-truncate raced with that and missed out on the
same treatment. Add that same python-esque skip logic to this test.
Fixes: 7d06bbb2d9 ("iotests: test O_TRUNC behavior for fuse exports")
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Message-ID: <20260925194409.716498-4-farman@linux.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Like nbd-in-qcow2-chain, this test assumes a q35 machine is
present, which might not be available on other hosts.
Unlike that test, simply allowing it to run with the default machine
still throws an errors. Fence this to PC-only machines for now.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Message-ID: <20260925194409.716498-3-farman@linux.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Some of the NBD tests explicitly specify `-machine q35` which won't work
when running against, say, qemu-system-s390x.
The nbd-in-qcow2-chain test runs fine with the default machine on a z16
host, so allow it to run in other configurations.
Fixes: 24fd6d75b3 ("iotests: Add coverage of recent NBD qio deadlock fix")
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Message-ID: <20260925194409.716498-2-farman@linux.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
An invalid length in an SCCB header correctly generates a specification
exception for the regular (non-PV) codepath that processes an SCLP
instruction intercept. The PV case doesn't, because the UV enforces
a valid length before getting to this point. The length is used to
allocate storage later down the line, so doublecheck the length here
in the (unlikely) case it is too short.
Cc: Janosch Frank <frankja@linux.ibm.com>
Cc: qemu-stable@nongnu.org
Fixes: c1db53a591 ("s390/sclp: read sccb from mem based on provided length")
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260922201526.2383047-10-farman@linux.ibm.com
[farman@linux.ibm.com: Updated commit/comment text, per Janosch]
Signed-off-by: Eric Farman <farman@linux.ibm.com>
The channel subsystem will reject channel programs that incorporate
256 CCWs without a data transfer, but the existing check to account
for this only does so for CCWs with a data address of zero. Other
valid CCWs that wouldn't transfer data are not accounted for.
Rather than re-inventing the wheel, use the output of the datastream
at the end of the entire CCW parsing tree to indicate whether data
was moved or not.
Cc: qemu-stable@nongnu.org
Fixes: e8601dd5d0 ("s390x/css: catch ccw sequence errors")
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260922201526.2383047-9-farman@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
The loop to store pending IRQs uses g_try_realloc() to expand the
buffer being used, but the returned address is stored in a
pointer-to-pointer, thus the check is supposed to be examining
the contents of the pointer, and not the pointer itself.
Define a temporary variable to catch and test the returned pointer.
If it's NULL, return to the caller to perform the free on the
unmodified buffer. If it's not NULL, store it in the caller's
pointer and restart the loop against the new struct.
Cc: qemu-stable@nongnu.org
Fixes: 3a553fc658 ("s390x/kvm: implement floating-interrupt controller device")
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260922201526.2383047-8-farman@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
The ioctl to determine whether KVM_DEV_FLIC_CLEAR_IO_IRQ is present
receives the contents of the attribute struct as its payload,
rather than a pointer to the payload itself as is convention.
This may result in erroneous errors from the ioctl, which would
result in clear_io_supported being false when it otherwise could
be used (which is helpful in device recovery).
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260922201526.2383047-7-farman@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Registering a new IRQ notifier will allocate an error object if needed,
and warn_report_err() will release that memory once it's finished.
The pointer remains, however, so subsequent errors after the non-fatal
errors in vfio_ap_realize() would cause an assertion failure for a
non-NULL pointer.
Fix this by clearing the pointer once the warning has been reported,
to reset the state of the error objects.
Cc: Anthony Krowiak <akrowiak@linux.ibm.com>
Cc: qemu-stable@nongnu.org
Fixes: 1360b2ad1f ("s390x/ap: Wire up the device request notifier interface")
Fixes: 0fb8a62fe4 ("hw/vfio/ap: notification handler for AP config changed event")
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260922201526.2383047-5-farman@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Both the read and write config paths use wrappers around cds->op_handler,
depending on the direction the I/O is flowing. But they expect opposite
values in the returned variable to indicate success.
Fix this by unifying those checks, where CCW_CMD_READ_CONF needs to
see !ret as success. The end result is some erroneous data in the
SCSW response data, but the overall success/failure is correct.
Cc: qemu-stable@nongnu.org
Fixes: d895d25ae2 ("s390x: css: report errors from ccw_dstream_read/write")
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260922201526.2383047-4-farman@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
The various indicators pointers allow them to be overwritten,
but leak any existing structs that might be there. If indicators
exist, ensure that they are released before setting the new ones.
Both the regular and adapter interrupt paths check that they
aren't being asked to enable interrupts when the other one is
enabled, so just do this release once all the potential checks
are completed.
Cc: qemu-stable@nongnu.org
Fixes: 7bca3892cb ("s390x/virtio-ccw: reference-counted indicators")
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260922201526.2383047-3-farman@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
When updating to capstone v6, the define CS_ARCH_SYSZ was replaced
with CS_ARCH_SYSTEMZ, except here. On systems without capstone-devel
installed, this causes a compile error:
../disas/disas-host.c: In function ‘initialize_debug_host’:
../disas/disas-host.c:78:24: error: ‘CS_ARCH_SYSZ’ undeclared (first use in this function); did you mean ‘CS_ARCH_SH’?
78 | s->info.cap_arch = CS_ARCH_SYSZ;
| ^~~~~~~~~~~~
| CS_ARCH_SH
../disas/disas-host.c:78:24: note: each undeclared identifier is reported only once for each function it appears in
Rather than making capstone required, replace the constant
with the same one used elsewhere after that change.
Fixes: c8220a096f ("target/s390x: Update capstone disassembly to v6")
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260824143033.306201-1-farman@linux.ibm.com>
The logic in css_interpret_ccw() correctly returns -EINVAL if a
Transfer-In-Channel (TIC) CCW is command chained to another TIC CCW.
The same routine also correctly returns -EINVAL if 256 CCWs do not
perform a data transfer as part of the I/O operation [0].
What is missing, however, is a combination of these two, where a loop
can be generated that will continue processing CCWs but without
providing an opportunity to catch a breath. Fix this by capping
the number of TIC CCWs in a channel program at the same limit as
the CCWs without data transfer.
[0] See "Invalid Sequence" in z/Architecture Principles of Operation
(SA22-7832-14), p16-27
Cc: qemu-stable@nongnu.org
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20260713074708.884282-1-borntraeger@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Commit 0b83acf2f0 stated:
Introduce a source set common to system / user. Start it
with the files built in both sets: 'cpu_models_user.c'
and 'gdbstub.c' No logical change intended.
Except that's not true:
git show 0b83acf2f0 | grep cpu_models
with the files built in both sets: 'cpu_models_user.c'
+ 'cpu_models_user.c',
- 'cpu_models_system.c',
- 'cpu_models_user.c',
Restore the s390x_user_ss section, move "cpu_models_user.c" back
into it, and re-add "cpu_models_system.c" to the common_system
section.
Reported-by: Cédric Le Goater <clg@redhat.com>
Fixes: 0b83acf2f0 ("target/s390x: Introduce common system/user meson source set")
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260511163541.192533-1-farman@linux.ibm.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
These are simple typos, since the directories don't exist but the
files themselves do in hw/s390x/
Fixes: 56e3483402 ("MAINTAINERS: split out s390x sections")
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Let's wait to mark the VCPU STOPPED until the possible
STORE STATUS operation is completed, so that we know the
CPU is fully stopped and done doing anything. (When we
also clear the possible sigp_order field for STOP orders.)
Suggested-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Message-Id: <20211213210919.856693-2-farman@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
According to the Principles of Operation, the SIGP Set Architecture
order will return Incorrect State if some CPUs are not stopped, but
only if the CZAM facility is not present. If it is, the order will
return Invalid Parameter because the architecture mode cannot be
changed.
Since CZAM always exists when S390_FEAT_ZARCH exists, which in turn
exists for every defined CPU model, we can simplify this code.
Fixes: 075e52b816 ("s390x/cpumodel: we are always in zarchitecture mode")
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Message-Id: <20211008203811.1980478-2-farman@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Wire in the subchannel callback for building the IRB
ESW and ECW space for passthrough devices, and copy
the hardware's ESW into the IRB we are building.
If the hardware presented concurrent sense, then copy
that sense data into the IRB's ECW space.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Message-Id: <20210617232537.1337506-5-farman@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Currently, all subchannel types have "sense data" copied into
the IRB.ECW space, and a couple flags enabled in the IRB.SCSW
and IRB.ESW. But for passthrough (vfio-ccw) subchannels,
this data isn't populated in the first place, so enabling
those flags leads to unexpected behavior if the guest tries to
process the sense data (zeros) in the IRB.ECW.
Let's add a subchannel callback that builds these portions of
the IRB, and move the existing code into a routine for those
virtual subchannels. The passthrough subchannels will be able
to piggy-back onto this later.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Message-Id: <20210617232537.1337506-4-farman@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
The Interrupt Response Block is comprised of several other
structures concatenated together, but only the 12-byte
Subchannel-Status Word (SCSW) is defined as a proper struct.
Everything else is a simple array of 32-bit words.
Let's define a proper struct for the 20-byte Extended-Status
Word (ESW) so that we can make good decisions about the sense
data that would go into the ECW area for virtual vs
passthrough devices.
[CH: adapted ESW definition to build with mingw, as discussed]
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Message-Id: <20210617232537.1337506-2-farman@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
The vfio_ccw_unrealize() routine makes an unconditional attempt to
unregister every IRQ notifier, though they may not have been registered
in the first place (when running on an older kernel, for example).
Let's mirror this behavior in the error cleanups in vfio_ccw_realize()
so that if/when new IRQs are added, it is less confusing to recognize
the necessary procedures. The worst case scenario would be some extra
messages about an undefined IRQ, but since this is an error exit that
won't be the only thing to worry about.
And regarding those messages, let's change it to a warning instead of
an error, to better reflect their severity. The existing code in both
paths handles everything anyway.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Acked-by: Matthew Rosato <mjrosato@linux.ibm.com>
Message-Id: <20210428143652.1571487-1-farman@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Commit 690e29b911 ("vfio-ccw: Refactor ccw irq handler") changed
one of the checks for the IRQ notifier registration from saying
"the host needs to recognize the only IRQ that exists" to saying
"the host needs to recognize ANY IRQ that exists."
And this worked fine, because the subsequent change to support the
CRW IRQ notifier doesn't get into this code when running on an older
kernel, thanks to a guard by a capability region. The later addition
of the REQ(uest) IRQ by commit b2f96f9e4f ("vfio-ccw: Connect the
device request notifier") broke this assumption because there is no
matching capability region. Thus, running new QEMU on an older
kernel fails with:
vfio: unexpected number of irqs 2
Let's adapt the message here so that there's a better clue of what
IRQ is missing.
Furthermore, let's make the REQ(uest) IRQ not fail when attempting
to register it, to permit running vfio-ccw on a newer QEMU with an
older kernel.
Fixes: b2f96f9e4f ("vfio-ccw: Connect the device request notifier")
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Message-Id: <20210421152053.2379873-1-farman@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
A pwrite() call returns the number of bytes written (or -1 on error),
and vfio-ccw compares this number with the size of the region to
determine if an error had occurred or not.
If they are not equal, this is a failure and the errno is used to
determine exactly how things failed. An errno of zero is possible
(though unlikely) in this situation and would be translated to a
successful operation.
If they ARE equal, the ret_code field is read from the region to
determine how to proceed. While the kernel sets the ret_code field
as necessary, the region and thus this field is not "written back"
to the user. So the value can only be what it was initialized to,
which is zero.
So, let's convert an unexpected length with errno of zero to a
return code of -EFAULT, and explicitly set an expected length to
a return code of zero. This will be a little safer and clearer.
Suggested-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Message-Id: <20210303160739.2179378-1-farman@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
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>
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>
We have a use case (vfio-ccw) where a CRW is already built and
ready to use. Rather than teasing out the components just to
reassemble it later, let's rework this code so we can queue a
fully-qualified CRW directly.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20200505125757.98209-6-farman@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
While we're at it, add a g_free() for the async_cmd_region that
is the last thing currently created. g_free() knows how to handle
NULL pointers, so this makes it easier to remember what cleanups
need to be performed when new regions are added.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20200505125757.98209-3-farman@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Eric Farman