ci: Update the list of tests that we run in the Fedora Cirrus-CI
The "msr" test recently started failing since it got extended, but
the kernel of the CI machine is not new enough to handle the new
tests. Thus we have to disable it in the CI for now.
On the other hand, there are a couple of other tests which seem
to work now, so we can include those in the list instead.
Message-Id: <email address hidden>
Signed-off-by: Thomas Huth <email address hidden>
To decrypt the dump of a PV guest, the comm-key (CCK) is required. Until
now, no comm-key was provided to genprotimg, therefore decrypting the
dump of a kvm-unit-test under PV was not possible.
This patch makes sure that we create a random CCK if there's no
$(TEST_DIR)/comm.key file.
Also allow dumping of PV tests by passing the appropriate PCF to
genprotimg (bit 34). --x-pcf is used to be compatible with older
genprotimg versions, which don't support --enable-dump. 0xe0 is the
default PCF value and only bit 34 is added.
Unfortunately, recent versions of genprotimg removed the --x-comm-key
argument which was used by older versions to specify the CCK. To support
these versions, we need to parse the genprotimg help output and decide
which argument to use.
d05bf60...
by
Janis Schoetterl-Glausch <email address hidden>
s390x: Add strict mode to specification exception interpretation test
While specification exception interpretation is not required to occur,
it can be useful for automatic regression testing to fail the test if it
does not occur.
Add a `--strict` argument to enable this.
`--strict` takes a list of machine types (as reported by STIDP)
for which to enable strict mode, for example
`--strict 3931,8562,8561,3907,3906,2965,2964`
will enable it for models z16 - z13.
Alternatively, strict mode can be enabled for all but the listed machine
types by prefixing the list with a `!`, for example
`--strict !1090,1091,2064,2066,2084,2086,2094,2096,2097,2098,2817,2818,2827,2828`
will enable it for z/Architecture models except those older than z13.
`--strict !` will enable it always.
An invalid PSW causes a program interrupt. When an invalid PSW is
introduced in the pgm_new_psw, an interrupt loop occurs as soon as a
program interrupt is caused.
QEMU should detect that and panic the guest, hence add a test for it.
The CPU timer interrupt stays pending as long as the CPU timer value is
negative. This can lead to interruption loops when the ext_new_psw mask
has external interrupts enabled and the CPU timer subclass in CR0 is
enabled.
QEMU is able to detect this situation and panic the guest, so add a test
for it.
lib/s390x: add CPU timer related defines and functions
Upcoming changes will make use of the CPU timer, so add some defines and
functions to work with the CPU timer.
Since shifts for both CPU timer and TOD clock are the same, introduce a
new constant S390_CLOCK_SHIFT_US for this value. The respective shifts
for CPU timer and TOD clock reference it, so the semantic difference
between the two defines is kept.
Also add a constant for the CPU timer subclass mask.
QEMU supports a guest state "guest-panicked" which indicates something
in the guest went wrong. For example on s390x, when an external
interrupt loop was triggered.
Since the guest does not continue to run when it is in the
guest-panicked state, it is currently impossible to write panicking
tests in kvm-unit-tests. Support from the runtime is needed to check
that the guest enters the guest-panicked state.
Similar to migration tests, add a new "panic" group. Tests in this
group must enter the guest-panicked state to succeed.
The runtime will spawn a QEMU instance, connect to the QMP and listen
for events. To parse the QMP protocol, jq[1] is used. Same as with
netcat in the migration tests, panic tests won't run if jq is not
installed.
The guest is created in the stopped state and only is resumed when
connection to the QMP was successful. This ensures no events are missed
between QEMU start and the connect to the QMP.
e5ce7b9...
by
Claudio Imbrenda <email address hidden>
lib/s390x: fix SMP setup bug
The lowcore pointer pointing to the current CPU (THIS_CPU) was not
initialized for the boot CPU. The pointer is needed for correct
interrupt handling, which is needed in the setup process before the
struct cpu array is allocated.
The bug went unnoticed because some environments (like qemu/KVM) clear
all memory and don't write anything in the lowcore area before starting
the payload. The pointer thus pointed to 0, an area of memory also not
used. Other environments will write to memory before starting the
payload, causing the unit tests to crash at the first interrupt.
Fix by assigning a temporary struct cpu before the rest of the setup
process, and assigning the pointer to the correct allocated struct
during smp initialization.
