From: Alexander Graf <agraf@csgraf.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org,
"Richard Henderson" <richard.henderson@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Andrei Warkentin" <andrey.warkentin@gmail.com>
Subject: Re: [PATCH] arm: Don't remove EL3 exposure for SMC conduit
Date: Mon, 15 Nov 2021 12:38:40 +0100 [thread overview]
Message-ID: <67c00a6a-e50a-3ea6-ef1d-98494fdbd729@csgraf.de> (raw)
In-Reply-To: <CAFEAcA_SzCtyDJfnJLLT57Xuf-TdJHRLEW00E7tQkdresxokMg@mail.gmail.com>
On 15.11.21 11:46, Peter Maydell wrote:
> On Sun, 14 Nov 2021 at 17:41, Alexander Graf <agraf@csgraf.de> wrote:
>>
>>
>>> Am 14.11.2021 um 18:20 schrieb Peter Maydell <peter.maydell@linaro.org>:
>>> This is tricky, because we use the cpu->isar values to determine whether
>>> we should be emulating things. So this change means we now create an
>>> inconsistent CPU which in some ways claims to have EL3 (the ISAR ID
>>> bits say so) and in some ways does not (the ARM_FEATURE_EL3 flag is
>>> unset), and depending on which of the two "do we have EL3?" methods
>>> any bit of the TCG code is using will give different results...
>> Do you think it would be sufficient to go through all readers of the isar bits and guard them behind an ARM_FEATURE_EL3 check in addition? I'll be happy to do so then! :)
> That would be a big reverse-course on a design choice we made that
> the preference is to look at the ID registers and phase out the
> use of ARM_FEATURE bits where possible.
I'm open to alternatives. As it stands, we're lying to the guest because
we tell it "SMC is not available" but ask it to call SMC for PSCI, which
is bad too.
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@csgraf.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
qemu-arm@nongnu.org,
"Richard Henderson" <richard.henderson@linaro.org>,
qemu-devel@nongnu.org,
"Andrei Warkentin" <andrey.warkentin@gmail.com>
Subject: Re: [PATCH] arm: Don't remove EL3 exposure for SMC conduit
Date: Mon, 15 Nov 2021 12:38:40 +0100 [thread overview]
Message-ID: <67c00a6a-e50a-3ea6-ef1d-98494fdbd729@csgraf.de> (raw)
In-Reply-To: <CAFEAcA_SzCtyDJfnJLLT57Xuf-TdJHRLEW00E7tQkdresxokMg@mail.gmail.com>
On 15.11.21 11:46, Peter Maydell wrote:
> On Sun, 14 Nov 2021 at 17:41, Alexander Graf <agraf@csgraf.de> wrote:
>>
>>
>>> Am 14.11.2021 um 18:20 schrieb Peter Maydell <peter.maydell@linaro.org>:
>>> This is tricky, because we use the cpu->isar values to determine whether
>>> we should be emulating things. So this change means we now create an
>>> inconsistent CPU which in some ways claims to have EL3 (the ISAR ID
>>> bits say so) and in some ways does not (the ARM_FEATURE_EL3 flag is
>>> unset), and depending on which of the two "do we have EL3?" methods
>>> any bit of the TCG code is using will give different results...
>> Do you think it would be sufficient to go through all readers of the isar bits and guard them behind an ARM_FEATURE_EL3 check in addition? I'll be happy to do so then! :)
> That would be a big reverse-course on a design choice we made that
> the preference is to look at the ID registers and phase out the
> use of ARM_FEATURE bits where possible.
I'm open to alternatives. As it stands, we're lying to the guest because
we tell it "SMC is not available" but ask it to call SMC for PSCI, which
is bad too.
Alex
next prev parent reply other threads:[~2021-11-15 11:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-14 10:56 [PATCH] arm: Don't remove EL3 exposure for SMC conduit Alexander Graf
2021-11-14 10:56 ` Alexander Graf
2021-11-14 17:20 ` Peter Maydell
2021-11-14 17:20 ` Peter Maydell
2021-11-14 17:41 ` Alexander Graf
2021-11-14 17:41 ` Alexander Graf
2021-11-14 21:35 ` Alexander Graf
2021-11-14 21:35 ` Alexander Graf
2021-11-15 10:46 ` Peter Maydell
2021-11-15 10:46 ` Peter Maydell
2021-11-15 11:38 ` Alexander Graf [this message]
2021-11-15 11:38 ` Alexander Graf
2021-11-15 12:08 ` Alex Bennée
2021-11-15 12:08 ` Alex Bennée
2021-11-15 12:54 ` Alexander Graf
2021-11-15 12:54 ` Alexander Graf
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=67c00a6a-e50a-3ea6-ef1d-98494fdbd729@csgraf.de \
--to=agraf@csgraf.de \
--cc=alex.bennee@linaro.org \
--cc=andrey.warkentin@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.