From: Peter Maydell <peter.maydell@linaro.org>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
Steven Price <steven.price@arm.com>,
kvm@vger.kernel.org, kvmarm@lists.linux.dev,
Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
James Morse <james.morse@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Joey Gouly <joey.gouly@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Christoffer Dall <christoffer.dall@arm.com>,
Fuad Tabba <tabba@google.com>,
linux-coco@lists.linux.dev,
Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
Subject: Re: [PATCH v3 02/14] arm64: Detect if in a realm and set RIPAS RAM
Date: Mon, 17 Jun 2024 11:27:31 +0100 [thread overview]
Message-ID: <CAFEAcA99bPtEr2OpE45wCgfSArZdtz4tu9rggLNb+=Rujh0ZvQ@mail.gmail.com> (raw)
In-Reply-To: <20240613105107.GC417776@myrica>
On Thu, 13 Jun 2024 at 11:50, Jean-Philippe Brucker
<jean-philippe@linaro.org> wrote:
>
> On Wed, Jun 12, 2024 at 11:59:22AM +0100, Suzuki K Poulose wrote:
> > On 12/06/2024 11:40, Jean-Philippe Brucker wrote:
> > > On Wed, Jun 05, 2024 at 10:29:54AM +0100, Steven Price wrote:
> > > > From: Suzuki K Poulose <suzuki.poulose@arm.com>
> > > >
> > > > Detect that the VM is a realm guest by the presence of the RSI
> > > > interface.
> > > >
> > > > If in a realm then all memory needs to be marked as RIPAS RAM initially,
> > > > the loader may or may not have done this for us. To be sure iterate over
> > > > all RAM and mark it as such. Any failure is fatal as that implies the
> > > > RAM regions passed to Linux are incorrect - which would mean failing
> > > > later when attempting to access non-existent RAM.
> > > >
> > > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > > > Co-developed-by: Steven Price <steven.price@arm.com>
> > > > Signed-off-by: Steven Price <steven.price@arm.com>
> > >
> > > > +static bool rsi_version_matches(void)
> > > > +{
> > > > + unsigned long ver_lower, ver_higher;
> > > > + unsigned long ret = rsi_request_version(RSI_ABI_VERSION,
> > > > + &ver_lower,
> > > > + &ver_higher);
> > >
> > > There is a regression on QEMU TCG (in emulation mode, not running under KVM):
> > >
> > > qemu-system-aarch64 -M virt -cpu max -kernel Image -nographic
> > >
> > > This doesn't implement EL3 or EL2, so SMC is UNDEFINED (DDI0487J.a R_HMXQS),
> > > and we end up with an undef instruction exception. So this patch would
> > > also break hardware that only implements EL1 (I don't know if it exists).
> >
> > Thanks for the report, Could we not check ID_AA64PFR0_EL1.EL3 >= 0 ? I
> > think we do this for kvm-unit-tests, we need the same here.
>
> Good point, it also fixes this case and is simpler. It assumes RMM doesn't
> hide this field, but I can't think of a reason it would.
>
> This command won't work anymore:
>
> qemu-system-aarch64 -M virt,secure=on -cpu max -kernel Image -nographic
>
> implements EL3 and SMC still treated as undef. QEMU has a special case for
> starting at EL2 in this case, but I couldn't find what this is for.
That's a bit of an odd config, because it says "emulate EL3 but
never use it". QEMU's boot loader starts the kernel at EL2 because
the kernel boot protocol requires that (this is more relevant on
boards other than virt where EL3 is not command-line disableable).
I have a feeling we've occasionally found that somebody's had some
corner case reason to use it, though. (eg
https://gitlab.com/qemu-project/qemu/-/issues/1899
is from somebody who says they use this when booting Windows 11 because
it asserts at boot time that EL3 is present and won't boot otherwise.)
Your underlying problem here seems to be that you don't have
a way for the firmware to say "hey, SMC works, you can use it" ?
-- PMM
next prev parent reply other threads:[~2024-06-17 10:27 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-05 9:29 [PATCH v3 00/14] arm64: Support for running as a guest in Arm CCA Steven Price
2024-06-05 8:37 ` Itaru Kitayama
2024-06-06 9:03 ` Steven Price
2024-06-05 9:29 ` [PATCH v3 01/14] arm64: rsi: Add RSI definitions Steven Price
2024-06-10 14:14 ` Catalin Marinas
2024-06-05 9:29 ` [PATCH v3 02/14] arm64: Detect if in a realm and set RIPAS RAM Steven Price
2024-06-10 14:11 ` Catalin Marinas
2024-06-10 14:16 ` Steven Price
2024-06-12 10:40 ` Jean-Philippe Brucker
2024-06-12 10:59 ` Suzuki K Poulose
2024-06-13 10:51 ` Jean-Philippe Brucker
2024-06-17 10:27 ` Peter Maydell [this message]
2024-06-17 11:23 ` Jean-Philippe Brucker
2024-06-26 0:12 ` Jeremy Linton
2024-06-14 18:57 ` Suzuki K Poulose
2024-06-05 9:29 ` [PATCH v3 03/14] arm64: realm: Query IPA size from the RMM Steven Price
2024-06-05 9:29 ` [PATCH v3 04/14] arm64: Mark all I/O as non-secure shared Steven Price
2024-06-05 9:29 ` [PATCH v3 05/14] fixmap: Allow architecture overriding set_fixmap_io Steven Price
2024-06-05 9:29 ` [PATCH v3 06/14] arm64: Override set_fixmap_io Steven Price
2024-06-10 17:49 ` Catalin Marinas
2024-06-27 13:56 ` Steven Price
2024-06-05 9:29 ` [PATCH v3 07/14] arm64: Make the PHYS_MASK_SHIFT dynamic Steven Price
2024-06-05 9:30 ` [PATCH v3 08/14] arm64: Enforce bounce buffers for realm DMA Steven Price
2024-06-05 9:30 ` [PATCH v3 09/14] arm64: Enable memory encrypt for Realms Steven Price
2024-06-10 17:27 ` Catalin Marinas
2024-06-27 14:34 ` Steven Price
2024-06-21 9:05 ` Catalin Marinas
2024-06-05 9:30 ` [PATCH v3 10/14] arm64: Force device mappings to be non-secure shared Steven Price
2024-06-17 3:33 ` Michael Kelley
2024-06-17 14:55 ` Suzuki K Poulose
2024-06-17 15:43 ` Catalin Marinas
2024-06-17 15:46 ` Michael Kelley
2024-06-05 9:30 ` [PATCH v3 11/14] efi: arm64: Map Device with Prot Shared Steven Price
2024-06-05 9:30 ` [PATCH v3 12/14] arm64: realm: Support nonsecure ITS emulation shared Steven Price
2024-06-05 13:39 ` Marc Zyngier
2024-06-05 15:08 ` Steven Price
2024-06-06 10:17 ` Marc Zyngier
2024-06-06 18:38 ` Catalin Marinas
2024-06-07 15:45 ` Steven Price
2024-06-07 16:46 ` Catalin Marinas
2024-06-07 17:55 ` Catalin Marinas
2024-06-18 16:04 ` Michael Kelley
2024-06-21 14:24 ` Catalin Marinas
2024-06-17 3:54 ` Michael Kelley
2024-06-28 9:59 ` Steven Price
2024-06-05 9:30 ` [PATCH v3 13/14] arm64: rsi: Interfaces to query attestation token Steven Price
2024-06-05 9:30 ` [PATCH v3 14/14] virt: arm-cca-guest: TSM_REPORT support for realms Steven Price
2024-06-07 1:38 ` [PATCH v3 00/14] arm64: Support for running as a guest in Arm CCA Michael Kelley
2024-06-07 15:12 ` Catalin Marinas
2024-06-07 16:36 ` Michael Kelley
2024-06-10 10:34 ` Catalin Marinas
2024-06-10 17:03 ` Michael Kelley
2024-06-10 17:46 ` Catalin Marinas
2024-06-17 4:06 ` Michael Kelley
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='CAFEAcA99bPtEr2OpE45wCgfSArZdtz4tu9rggLNb+=Rujh0ZvQ@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=alexandru.elisei@arm.com \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@arm.com \
--cc=gankulkarni@os.amperecomputing.com \
--cc=james.morse@arm.com \
--cc=jean-philippe@linaro.org \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=steven.price@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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).