From: Thomas Huth <thuth@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>,
Cornelia Huck <cohuck@redhat.com>
Cc: qemu-s390x <qemu-s390x@nongnu.org>,
Eric Farman <farman@linux.ibm.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: getting the console output for s390 cdrom-test?
Date: Fri, 12 Feb 2021 12:44:55 +0100 [thread overview]
Message-ID: <97770e1f-0b18-98fb-5b65-4211ff5465f7@redhat.com> (raw)
In-Reply-To: <CAFEAcA99CxOv9UnzS7sehHhB5mi9P5CtchopqhwyAv=are1y7A@mail.gmail.com>
On 09/02/2021 19.25, Peter Maydell wrote:
> On Tue, 9 Feb 2021 at 17:24, Cornelia Huck <cohuck@redhat.com> wrote:
>>
>> On Tue, 9 Feb 2021 17:17:19 +0000
>> Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>>> On Tue, 9 Feb 2021 at 17:10, Cornelia Huck <cohuck@redhat.com> wrote:
>>>>
>>>> On Tue, 9 Feb 2021 14:58:53 +0000
>>>> Peter Maydell <peter.maydell@linaro.org> wrote:
>>>>> This change significantly reduces the frequency with which I see
>>>>> the hang; but it doesn't get rid of it altogether. Also I couldn't
>>>>> really figure out from the virtio spec exactly where barriers
>>>>> were required: I think I would need to read the whole thing in
>>>>> more detail rather than trying to fish out the information by
>>>>> just reading small pieces of it.
>>>>
>>>> The Linux virtio-ccw code uses 'weak barriers', i.e. the heavy bcr15
>>>> should not be needed. We might well miss other (lightweight) barriers
>>>> in other parts of the code part, though.
>>>
>>> Is that the version the Linux kernel has as
>>> /* Fast-BCR without checkpoint synchronization */
>>> #define __ASM_BARRIER "bcr 14,0\n"
>>>
>>> ?
>>
>> No, just a simple memory barrier in most places (bcr15 and bcr14 do
>> serialization).
>
> OK; if you let me know how that's written for s390 I can give
> it a test...
I guess Cornelia simply meant a:
asm volatile("nop":::"memory");
Anyway, I've now succeeded in getting my hands on an aarch64 host and tried
to reproduce the issue, but even after running it in a loop like this:
for ((x=0;x<200;x++)) ; do \
QTEST_QEMU_BINARY=./qemu-system-s390x tests/qtest/cdrom-test \
|| break ; \
done
... I was not able to reproduce the issue. What kind of host distro are you
using there? Could the exact host CPU type matter here, too? (I was running
my code on an HPE Apollo system, with Fedora 33, gcc 10.2)
Thomas
next prev parent reply other threads:[~2021-02-12 11:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-22 20:32 getting the console output for s390 cdrom-test? Peter Maydell
2021-02-04 16:08 ` Thomas Huth
2021-02-08 10:27 ` Peter Maydell
2021-02-08 11:34 ` Thomas Huth
2021-02-08 12:08 ` Peter Maydell
2021-02-09 14:58 ` Peter Maydell
2021-02-09 17:10 ` Cornelia Huck
2021-02-09 17:17 ` Peter Maydell
2021-02-09 17:24 ` Cornelia Huck
2021-02-09 18:25 ` Peter Maydell
2021-02-12 11:44 ` Thomas Huth [this message]
2021-02-12 12:05 ` Peter Maydell
2021-02-12 14:10 ` Thomas Huth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=97770e1f-0b18-98fb-5b65-4211ff5465f7@redhat.com \
--to=thuth@redhat.com \
--cc=cohuck@redhat.com \
--cc=farman@linux.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).