From: Richard Henderson <richard.henderson@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm <qemu-arm@nongnu.org>, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH v4 1/7] target/arm: Improve masking of HCR RES0 bits
Date: Fri, 28 Feb 2020 14:24:19 -0800 [thread overview]
Message-ID: <08a6a113-4082-246c-2aeb-4424b921caa4@linaro.org> (raw)
In-Reply-To: <CAFEAcA96AZB765TizrPLJYfXhx=KUcb_feL3JK1WNmf5dRSR0w@mail.gmail.com>
On 2/28/20 11:03 AM, Peter Maydell wrote:
> It occurs to me that we should check what the required
> semantics are for the opposite half of the register
> if the guest writes to one half of it via hcr_writehigh()
> or hcr_writelow() -- is the un-accessed half supposed
> to stay exactly as it is, or is it ok for the
> RES0-for-aarch32 bits to get squashed in the process?
> That would seem at least a bit odd even if it's valid,
> so maybe better to do aarch32 RES0 masking in
> hcr_writehigh() and hcr_writelow()?
Hmm. You're thinking of a situation in which
1) EL3 invokes EL2 with aa64 which sets HCR_EL2,
2) EL3 invokes EL2 in aa32 which sets HCR which
as a side-effect clears some of the bits in HCR2
3) EL3 invokes EL2 with aa64 again and HCR_EL2
incorrectly has some high bits clear.
I can't find any language that explicitly says, but "architecturally mapped"
means that the bits backing the storage must be the same. So while it isn't
legal for aa32 to set HCR2 bit 8 (HCR_EL2.APK), I imagine that it would still
read as written.
So I think you're correct that we shouldn't alter the half B when writing to
half A.
Perhaps I should do some masking for aa32 in arm_hcr_el2_eff.
r~
next prev parent reply other threads:[~2020-02-28 22:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-25 18:08 [PATCH v4 0/7] target/arm: Honor more HCR_EL2 traps Richard Henderson
2020-02-25 18:08 ` [PATCH v4 1/7] target/arm: Improve masking of HCR RES0 bits Richard Henderson
2020-02-28 16:22 ` Peter Maydell
2020-02-28 16:57 ` Richard Henderson
2020-02-28 17:34 ` Peter Maydell
2020-02-28 18:55 ` Richard Henderson
2020-02-28 19:03 ` Peter Maydell
2020-02-28 22:24 ` Richard Henderson [this message]
2020-02-25 18:08 ` [PATCH v4 2/7] target/arm: Honor the HCR_EL2.{TVM,TRVM} bits Richard Henderson
2020-02-28 16:24 ` Peter Maydell
2020-02-25 18:08 ` [PATCH v4 3/7] target/arm: Honor the HCR_EL2.TSW bit Richard Henderson
2020-02-25 18:08 ` [PATCH v4 4/7] target/arm: Honor the HCR_EL2.TACR bit Richard Henderson
2020-02-25 18:08 ` [PATCH v4 5/7] target/arm: Honor the HCR_EL2.TPCP bit Richard Henderson
2020-02-28 16:25 ` Peter Maydell
2020-02-25 18:08 ` [PATCH v4 6/7] target/arm: Honor the HCR_EL2.TPU bit Richard Henderson
2020-02-28 16:25 ` Peter Maydell
2020-02-25 18:08 ` [PATCH v4 7/7] target/arm: Honor the HCR_EL2.TTLB bit Richard Henderson
2020-02-28 16:28 ` 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=08a6a113-4082-246c-2aeb-4424b921caa4@linaro.org \
--to=richard.henderson@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@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).