Re: getting the console output for s390 cdrom-test?

[Thomas Huth]

On 22/01/2021 21.32, Peter Maydell wrote:
> Hi; I've been looking at why the s390 cdrom test has an intermittent
> failure on my aarch64 box. Looking at some TCG debug log output
> I think what is happening is that sometimes execution diverges from
> a successful run inside virtio_scsi_setup() and we end up failing
> a vs_assert(), which triggers a "Guest crashed on cpu 0: disabled-wait"
> which then makes the qtest hang until its timeout.
>
> I think that vs_assert() ought to be printing some information
> to the console about which assert fails when it happens, but
> how do I need to tweak the qtest to get it to capture this
> console log somewhere?

 Hi!

Sorry for the late reply ... did you get any further with this already? 
Anyway, in case I need to get the console of a test, I normally modify the 
test case like this:

diff --git a/tests/qtest/cdrom-test.c b/tests/qtest/cdrom-test.c
index 5af944a5fb..52f7ed050d 100644
--- a/tests/qtest/cdrom-test.c
+++ b/tests/qtest/cdrom-test.c
@@ -120,7 +120,7 @@ static void test_cdboot(gconstpointer data)
 {
     QTestState *qts;

-    qts = qtest_initf("-accel kvm -accel tcg -no-shutdown %s%s", (const 
char *)data,
+    qts = qtest_initf("-serial file:/tmp/stdio.txt -accel kvm -accel tcg 
-no-shutdown %s%s", (const char *)data,
                       isoimage);
     boot_sector_test(qts);
     qtest_quit(qts);

> PS: it would be nice if "guest BIOS asserts and puts the
> system into a detected-guest-crash state" resulted in the
> test failing rather than hanging :-)

We could maybe check for panic events in boot_sector_test() ... I can have a 
try when time permits...

> (Annoyingly, most of my attempts to get more information about
> where things go wrong seem to cause the bug to stop manifesting
> itself: eg building the s390-ccw.img without -O2; enabling
> TCG 'exec' logging; enabling 'trace:virtio*' tracepoints.
> The failure itself started with commit 7a3d37a3f233 updating
> the s390 bios blobs, but the changes that went into the new
> blobs don't really look like they would be responsible.
> I am starting to have gloomy thoughts about potential missing
> memory barrier insns between the CPU thread and the iothread
> doing the virtio device end of things...)

A Heisen-bug ... ugh ... but I wonder whether it's maybe rather an issue in 
the aarch64 TCG backend, since we've never seen this on other architectures 
before?

 Thomas