From: Richard Henderson <richard.henderson@linaro.org>
To: David Hildenbrand <david@redhat.com>, qemu-devel@nongnu.org
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org, Cornelia Huck <cohuck@redhat.com>,
Thomas Huth <thuth@redhat.com>
Subject: Re: [PATCH v1] s390x/tcg: Implement MONITOR CALL
Date: Thu, 17 Sep 2020 08:33:44 -0700 [thread overview]
Message-ID: <17b2cca5-f21d-1323-1003-3d9731a698cc@linaro.org> (raw)
In-Reply-To: <20200917115447.10503-1-david@redhat.com>
On 9/17/20 4:54 AM, David Hildenbrand wrote:
> Recent upstream Linux uses the MONITOR CALL instruction for things like
> BUG_ON() and WARN_ON(). We currently inject an operation exception when
> we hit a MONITOR CALL instruction - which is wrong, as the instruction
> is not glued to specific CPU features.
>
> Doing a simple WARN_ON_ONCE() currently results in a panic:
> [ 18.162801] illegal operation: 0001 ilc:2 [#1] SMP
> [ 18.162889] Modules linked in:
> [...]
> [ 18.165476] Kernel panic - not syncing: Fatal exception: panic_on_oops
>
> With a proper implementation, we now get:
> [ 18.242754] ------------[ cut here ]------------
> [ 18.242855] WARNING: CPU: 7 PID: 1 at init/main.c:1534 [...]
> [ 18.242919] Modules linked in:
> [...]
> [ 18.246262] ---[ end trace a420477d71dc97b4 ]---
> [ 18.259014] Freeing unused kernel memory: 4220K
>
> To be able to translate it to a NOP easily, mangle the 16 monitor masks
> bits from the cr8 into the TB flags.
This is a rare situation that does not warrant the use of TB flags. Better to
unconditionally call helper_monitor_event, and have the helper function test
the runtime value of cr8. If the event is disabled, the helper simply returns.
It should be simpler to write, as well, not having to do this:
> + /* Copy over the monitor mask bits (16) as two separate bytes. */
> + byte = (env->cregs[8] & CR8_MONITOR_MASK) >> 8;
> + *flags |= (uint32_t)byte << FLAG_SHIFT_MM0_7;
> + byte = env->cregs[8] & CR8_MONITOR_MASK;
> + *flags |= (uint32_t)byte << FLAG_SHIFT_MM8_15;
> +
> + QEMU_BUILD_BUG_ON((FLAG_MASK_AFP | FLAG_MASK_VECTOR | FLAG_MASK_MM0_7 |
> + FLAG_MASK_MM8_15) & FLAG_MASK_PSW);
r~
next prev parent reply other threads:[~2020-09-17 15:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-17 11:54 [PATCH v1] s390x/tcg: Implement MONITOR CALL David Hildenbrand
2020-09-17 15:33 ` Richard Henderson [this message]
2020-09-17 15:57 ` David Hildenbrand
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=17b2cca5-f21d-1323-1003-3d9731a698cc@linaro.org \
--to=richard.henderson@linaro.org \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=thuth@redhat.com \
/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).