From: Damien Hedde <damien.hedde@greensocs.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Richard Henderson" <richard.henderson@linaro.org>,
qemu-arm <qemu-arm@nongnu.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH for-4.1] target/arm: Avoid bogus NSACR traps on M-profile without Security Extension
Date: Fri, 2 Aug 2019 09:51:07 +0200 [thread overview]
Message-ID: <569b96b1-e11a-59c5-4f67-1da2d592b8fc@greensocs.com> (raw)
In-Reply-To: <CAFEAcA87XdDJH5TO-AiDfSqudmwzuY0yoa0H60objxXp3Bh9LA@mail.gmail.com>
On 8/1/19 4:38 PM, Peter Maydell wrote:
> On Thu, 1 Aug 2019 at 15:20, Damien Hedde <damien.hedde@greensocs.com> wrote:
>>
>>
>> On 8/1/19 12:57 PM, Peter Maydell wrote:
>>> In Arm v8.0 M-profile CPUs without the Security Extension and also in
>>> v7M CPUs, there is no NSACR register. However, the code we have to handle
>>> the FPU does not always check whether the ARM_FEATURE_M_SECURITY bit
>>> is set before testing whether env->v7m.nsacr permits access to the
>>> FPU. This means that for a CPU with an FPU but without the Security
>>> Extension we would always take a bogus fault when trying to stack
>>> the FPU registers on an exception entry.
>>>
>>> We could fix this by adding extra feature bit checks for all uses,
>>> but it is simpler to just make the internal value of nsacr 0x3ff
>>
>> s/0x3ff/0xcff/ I think, given you put 0xcff after and in the code
>
> Yes, 0xcff is correct and the commit message is wrong. (Bits 8 and 9
> of the NSACR are RES0 in all situations.)
>
Reviewed-by: Damien Hedde <damien.hedde@greensocs.com>
next prev parent reply other threads:[~2019-08-02 7:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-01 10:57 [Qemu-devel] [PATCH for-4.1] target/arm: Avoid bogus NSACR traps on M-profile without Security Extension Peter Maydell
2019-08-01 14:20 ` Damien Hedde
2019-08-01 14:38 ` Peter Maydell
2019-08-02 7:51 ` Damien Hedde [this message]
2019-08-02 16:38 ` Peter Maydell
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=569b96b1-e11a-59c5-4f67-1da2d592b8fc@greensocs.com \
--to=damien.hedde@greensocs.com \
--cc=alex.bennee@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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).